Site créé avec l'IA : les vérifications qui font la différence à la livraison
Une page convaincante dans un aperçu peut cacher un lien mal dirigé ou un contenu remplacé par JavaScript. La livraison d'un site créé avec l'IA doit s'appuyer sur des résultats vérifiables.
Un site s’affiche, ses couleurs sont cohérentes et son menu semble fonctionner. Peut-on le considérer comme terminé ? Pour un entrepreneur qui prépare sa présence en ligne, cette impression est rassurante. Elle laisse pourtant plusieurs questions ouvertes : les boutons mènent-ils au bon endroit ? Une page intérieure reste-t-elle correcte lorsqu’on l’ouvre directement ? Les moteurs peuvent-ils accéder au contenu publié ?
Un projet de site statique hébergé sur Netlify, avec un domaine acheté chez Namecheap, fournit deux exemples concrets. Les contrôles du 14 octobre 2026 ont révélé des erreurs discrètes à l’écran, mais significatives pour la navigation. Leur intérêt dépasse le choix de l’outil de génération : ils montrent ce qu’un compte rendu de livraison devrait démontrer.
Partir de l’action attendue, pas de l’apparence du bouton
Le premier défaut concernait un bouton annonçant l’accès à huit modules. Il rechargeait le haut de la page qui les présentait. Le lien fonctionnait techniquement et ne produisait aucune erreur visible ; son résultat ne correspondait simplement pas à son intitulé.
La correction a consisté à viser une ancre située au début des modules, puis à vérifier l’arrivée dans le navigateur. Ce contrôle est facile à généraliser : écrire ce que le visiteur doit obtenir, effectuer l’action et comparer le résultat. Pour un formulaire, une confirmation à l’écran ne prouve pas à elle seule que la demande a été reçue. Pour une vidéo, la présence d’un bouton de lecture ne prouve pas que le média démarre.
Une recette utile décrit donc un parcours et son résultat. "Les boutons ont été vérifiés" apporte moins d’information que "le lien vers le programme ouvre le début des modules, sur ordinateur et en affichage mobile".
Ouvrir les pages autrement que depuis l’accueil
Le second défaut était plus trompeur. À l’adresse /formation/index.html, le serveur fournissait le contenu attendu. Le script exécuté ensuite dans le navigateur affichait pourtant l’accueil. Une vérification limitée à la réponse du serveur aurait laissé passer cette contradiction.
La correction a porté sur la reconnaissance des adresses par le code et sur la redirection des variantes connues vers leur page correspondante. Une adresse inconnue devait, elle, rester introuvable : la remplacer systématiquement par l’accueil aurait masqué le problème.
Pour un petit site, quelques essais ciblés permettent de détecter cette famille d’erreurs : ouvrir une page intérieure directement, la recharger, tester une ancienne variante et saisir une adresse inexistante. Il faut comparer le contenu principal et le titre obtenus, puis contrôler les réponses HTTP. Le bon résultat associe une adresse cohérente, le bon contenu et un statut adapté.
Cette distinction compte également pour le référencement : Google explique que le traitement des pages JavaScript comporte des étapes d’exploration, de rendu et d’indexation. Vérifier le HTML initial ne remplace donc pas l’examen du résultat après exécution des scripts. Documentation Google sur le SEO JavaScript.
Donner aux contrôles mobiles un périmètre précis
Sur ce projet, un article a été contrôlé à une largeur de 390 pixels, sans défilement horizontal. C’est un constat utile, à condition de conserver sa portée : il décrit une page, une largeur et une version du site.
La suite de la recette doit inclure les éléments qui bougent ou se superposent : menu ouvert, bandeau fixe, lecteur vidéo et bouton de fermeture. Un écran propre au chargement peut devenir difficile à utiliser après une interaction. Tester le clavier apporte un autre éclairage, notamment sur l’accès aux commandes et le retour du focus après fermeture d’un menu.
Le compte rendu peut préciser les conditions testées et les parcours restant à examiner. Cette transparence aide à planifier les corrections et évite de transformer quelques captures réussies en promesse de compatibilité universelle.
Séparer mise en ligne, indexation et acquisition
Lors d’un contrôle initial, le sitemap était accepté dans Search Console alors que l’accueil était encore indiqué comme détecté mais non indexé. Cette observation décrit un état daté, pas le statut actuel du site.
Elle rappelle surtout que plusieurs étapes doivent être suivies séparément. La mise en ligne se contrôle en ouvrant les pages. L’indexation se vérifie dans les outils du moteur. Les impressions et les clics permettent ensuite d’observer la visibilité. Une demande d’exploration ne garantit pas l’indexation, comme le précise Google Search Central.
La livraison gagne ainsi à inclure une liste de pages contrôlées, les anomalies corrigées, les limites connues et la date des vérifications. Le cas pratique et sa checklist détaillent les constats présentés ici. L’objectif de ces contrôles est de rendre le fonctionnement observable ; ils ne démontrent ni des ventes ni une position dans les résultats de recherche.
Transparence : cet article a été préparé avec une assistance IA à partir des vérifications documentées du projet. Le site cité est celui de son porteur et comporte une activité d’affiliation. Le texte ne constitue pas un avis indépendant sur la formation qui y est présentée.