Checklist site web avant mise en ligne : les 23 points d'un site prêt à lancer

J'ai donné le même prompt minimaliste à trois outils — Claude, Lovable et une IA open source — pour générer un site, puis je leur ai envoyé la même checklist de 23 points avec une seule consigne : « auditez le site, dites ce qui est déjà couvert, corrigez le reste. » Verdict de terrain : ce n'est pas l'outil qui fait un site qui se classe, c'est la grille. Voici la checklist complète à passer avant chaque mise en ligne, et ce que chaque IA en a réellement fait.

Avertissement avant de commencer : ceci est un retour d'expérience, pas un audit de laboratoire. J'ai mené ce test avec mes propres outils, sur un cas concret, à un instant T — les modèles évoluent vite. Prenez la méthode et la grille (elles, elles restent), pas le classement (il bougera).

Pourquoi l'outil compte moins que la grille d'évaluation ?

Quand on génère un site avec une IA, on croit que tout se joue dans le choix de l'outil. C'est une erreur. Ce qui sépare un site qui se classe d'un site invisible, ce n'est pas le générateur : c'est la grille d'évaluation qu'on utilise pour piloter l'IA.

La raison est simple. Un outil « produit » arrive préconfiguré : il embarque des instructions implicites pour livrer un site propre, et il en couvre une partie sans qu'on lui demande. Un outil plus brut vous rend exactement ce que vous avez prompté, ni plus ni moins. Dans les deux cas, le résultat « par défaut » a des trous — différents selon l'outil, mais réels. Et quand on n'est ni développeur ni architecte technique, on n'a aucun moyen de les repérer à l'œil nu.

D'où l'intérêt d'une checklist exhaustive qu'on fournit à l'IA après la génération : « voici les 23 points d'un site prêt à lancer, dis-moi lesquels sont déjà couverts et corrige le reste. » L'outil change ; la checklist reste. C'est ce que cette expérience démontre, et l'objet de cet article est de vous donner la grille.

Pourquoi un site généré par IA est-il souvent beau mais invisible ?

Avant la grille, l'avertissement central qui justifie toute la démarche : ce que vous voyez à l'écran n'est pas ce que voit le robot d'un moteur ou d'une IA.

Un site peut être superbe visuellement et rester quasi invisible pour le crawler de Google, d'OpenAI ou d'Anthropic, parce que ses informations ne lui sont pas rendues lisibles : pas de schema structuré, pas de balises de partage, langue mal déclarée, liens morts. C'est le piège classique des générateurs orientés design : ils optimisent le rendu humain, pas la lecture machine. La checklist sert précisément à combler cet écart entre « beau » et « indexable ».

Quels sont les 23 points à vérifier avant de mettre un site en ligne ?

Cette grille couvre ce qu'un site devrait avoir avant sa mise en ligne. Elle se range en quatre blocs : découvrabilité, accessibilité, conformité RGPD, sécurité & robustesse.

Bloc A — Découvrabilité (SEO + GEO + partage social)

Tout ce qui rend un site trouvable par les moteurs et citable par les IA génératives :

• Structure des titres : un seul H1, une hiérarchie Hn cohérente.
• title et meta description : la carte d'identité de la page dans les résultats.
• canonical : la balise qui désigne l'URL de référence et évite le contenu dupliqué.
• robots.txt : autoriser les crawlers, y compris ceux des IA (GPTBot, PerplexityBot, ClaudeBot).
• hreflang : la déclaration de langue (un contenu français doit dire lang="fr").
• sitemap.xml : la carte de toutes vos URL pour les crawlers.
• llms.txt : le fichier dédié aux crawlers d'IA génératives (le levier GEO le plus récent).
• schema JSON-LD : les données structurées (Organization, WebSite, Product, FAQPage…) qui rendent votre contenu citable.
• Open Graph & Twitter Card : l'aperçu qui s'affiche quand on partage votre lien.
• favicon, textes alternatifs des images, fil d'Ariane, liens sociaux.
• Performance : mesurable avec PageSpeed Insights (images lentes, redirections, ressources qui alourdissent le chargement et pénalisent le classement).

Bloc B — Accessibilité

Le viewport et le responsive, puis la conformité WCAG : aria-label, aria-expanded, labels de formulaire, lien d'évitement, contrastes suffisants. Un site accessible est aussi un site mieux lu par les machines — les deux objectifs se renforcent.

Bloc C — Conformité RGPD

Le consentement aux cookies (aucun traceur chargé avant accord) et les pages légales obligatoires : mentions légales, politique de confidentialité. Non négociables en France dès qu'il y a une activité commerciale.

Bloc D — Sécurité & robustesse

Le HTTPS, les en-têtes de sécurité (HSTS, CSP…), une vraie page 404, l'absence de liens cassés, l'analytics et la Search Console pour mesurer et corriger après le lancement.

Comment j'ai testé la grille sur Claude, Lovable et une IA open source ?

Pour que la comparaison soit honnête, j'ai imposé les mêmes conditions aux trois outils :

• Un prompt volontairement minimaliste, identique pour tous — le genre de demande que ferait n'importe quel utilisateur pressé : « crée-moi un site pour mon activité : je vends des ventilateurs pour studio de streaming. »
• Aucune aide pendant la génération. On laisse l'outil produire son site « par défaut ».
• La grille des 23 points envoyée après coup, avec une consigne unique : auditer le site produit, dire ce qui était couvert, corriger ce qui manquait.

Les trois outils représentent trois philosophies différentes :

Claude vs Lovable vs open source : qu'a vraiment fait chaque outil ?

À partir du même prompt, les trois sites se ressemblaient sur le fond. C'est sur la rigueur technique — et surtout sur la manière de la rétablir — que tout les a séparés.

L'open source (GLM 5.2) : il exécute sans auditer

Le modèle open source a la mentalité du faiseur. Une fois la checklist reçue, sa réponse n'est pas une analyse mais une liste de modifications appliquées directement.

Bloc A : canonical, Open Graph, Twitter Card, favicon SVG inline, schema JSON-LD complet (Organization, WebSite, trois Products, FAQPage), textes alternatifs améliorés avec loading="lazy", plus la création de robots.txt, sitemap.xml et llms.txt. Bloc B : aria-label et aria-expanded sur la FAQ et le menu. Bloc C : pages mentions légales et confidentialité, liées dans le footer.

Vraie surprise pour un modèle open source : il livre du code prêt à l'emploi, marque honnêtement les points dépendants de l'hébergeur d'un « manuel » plutôt que de prétendre les avoir réglés, et pense même à rappeler de remplacer le domaine placeholder partout (canonical, sitemap, robots, llms, Open Graph).

Sa limite : il fait, mais il n'audite pas. Il vous dit ce qu'il a ajouté, jamais ce qui n'allait pas avant ni à quel point c'était grave. Pour un débutant, c'est rassurant et efficace. Pour qui veut comprendre l'état réel de son site, c'est une boîte noire.

Lovable : il diagnostique avant de toucher

Lovable prend le problème par l'autre bout. Au lieu d'appliquer, il audite d'abord — point par point, avec un statut et un constat motivé pour chacun. Il va jusqu'à donner un score chiffré : 6/19 (les 4 points manuels exclus du décompte). Il ne se contente pas de signaler « manquant », il explique pourquoi et à quel point ça pèse :

• Schema JSON-LD absent : il liste exactement ce qu'il faudrait ajouter (Organization, WebSite, Product avec son prix, AggregateRating, avis clients) — preuve qu'il a lu le contenu réel de la page.
• Open Graph incomplet : « og:title et og:description présents, mais pas d'og:image, og:url ni twitter:card → aperçu de partage cassé ».
• Langue mal déclarée : <html lang="en"> sur un contenu français — exactement le type d'erreur invisible qui sabote le référencement.
• Le bouton « Commander » pointait vers un lien mort : « le bouton qui vend ne mène nulle part. »

Cette dernière remarque est la plus importante de toute l'expérience, et Lovable est le seul à l'avoir formulée aussi nettement. Il a même hiérarchisé ses correctifs par impact : d'abord les bloquants pour publier en France (pages légales + brancher le bouton d'achat sur un vrai paiement), ensuite les quick wins SEO/social, enfin le gros gain GEO (le schema produit).

Sa limite : il dit plutôt qu'il ne fait. Il vous remet un diagnostic remarquable, classé par urgence, mais c'est à vous d'appliquer la majorité des correctifs — et chaque étape consomme des tokens.

Claude (Opus 4.8) : il audite, applique et produit les annexes

Claude combine les deux postures précédentes. Il commence comme Lovable, par l'audit : il constate ce qui est déjà conforme (langue, viewport, title, meta description, un seul H1) et liste ce qui manque. Détail révélateur : avant même de modifier le code, il s'arrête pour poser une question — quel domaine canonique, quelles mentions légales — parce que ces réponses conditionnent le sitemap, les balises de partage et les pages légales. Il prend un placeholder en attendant et poursuit.

Puis il applique, comme l'open source, mais plus loin : head réécrit, schema JSON-LD complet (jusqu'au BreadcrumbList), Open Graph et Twitter Card avec image au bon format, jeu de favicons, fil d'Ariane à la fois visuel et structuré, liens sociaux sécurisés. Côté accessibilité : lien d'évitement, focus clavier visible, landmark <main>, icônes décoratives masquées aux lecteurs d'écran, labels ARIA. Côté RGPD : un bandeau cookies qui ne charge aucun traceur avant consentement, avec une fonction d'analytics prête à brancher, plus les deux pages légales.

Enfin, il fait ce que les deux autres ne poussent pas aussi loin : il crée tous les fichiers annexes — robots.txt (autorisant explicitement GPTBot, PerplexityBot, ClaudeBot), sitemap.xml, llms.txt, une page 404.html, les pages légales — puis il vérifie la validité du HTML et du JSON-LD avant de conclure.

Sa limite : son exhaustivité a un coût (en temps, en allers-retours, en interruptions pour poser des questions). Mais le résultat est le plus complet des trois.

Comment reproduire ce test sur votre propre site ?

La méthode est simple à répliquer. Générez votre site avec l'outil de votre choix, puis fournissez-lui la checklist des 23 points en lui demandant d'abord un audit sans modification, simplement pour mesurer l'écart. Ensuite seulement, demandez les corrections. Vous pouvez aussi passer votre site déployé dans des outils tiers pour confirmer le diagnostic :

• Ahrefs : score SEO, liens et descriptions cassés.
• PageSpeed Insights : performance réelle et accessibilité.

Et n'oubliez pas : certains des 23 points dépendront toujours de votre hébergeur (HTTPS, en-têtes HTTP, code de la page 404…). Ils se règlent au moment du déploiement, pas dans le code.

Faut-il chercher le meilleur outil ou la meilleure grille ?

Aucun outil ne gagne sur tous les tableaux, et c'est exactement ce que l'expérience révèle. L'open source est l'exécutant rapide et complet ; Lovable est le meilleur diagnosticien ; Claude est le plus exhaustif. Mais le vrai enseignement dépasse le classement : ne cherchez pas l'outil parfait, construisez la grille parfaite et appliquez-la systématiquement, quel que soit l'outil.

Et au fond, tout ce travail repose sur une seule compétence : savoir piloter l'IA générative pour produire et auditer un livrable de qualité — un site, un article, un visuel — sans se contenter du « par défaut » qui rend invisible. C'est exactement ce que nous enseignons dans notre formation certifiante « Création de contenus rédactionnels et visuels par l'usage responsable de l'IA générative » (RS6776), éligible CPF et OPCO. Générer un site prêt à lancer n'est qu'une des applications concrètes de cette maîtrise.