Vérifier un site fait avec une IA

L'aperçu montre la page, pas ce que le serveur envoie

L'outil vous montre la page telle que votre navigateur l'affiche, une fois tout chargé. C'est ce que voit un visiteur arrivé par l'accueil. Ce n'est ni ce que lit un robot qui télécharge la page sans exécuter ses scripts, ni ce qui arrive à quelqu'un qui suit un lien vers une page supprimée, ni ce que le navigateur envoie à des tiers pendant l'affichage.

Une demande faite à un outil de création porte d'abord sur ce qui se voit : les textes, les sections, les couleurs. Un en-tête de sécurité, une page de mentions légales ou un bandeau qui bloque vraiment les traceurs ne s'affichent pas dans l'aperçu. Ils se lisent dans les réponses du serveur, dans les fichiers publiés et dans ce qui part pendant la visite, et c'est là qu'il faut les faire vérifier.

Le cadre presque vide que reçoivent les moteurs

Quand l'outil produit une application JavaScript, le serveur peut n'envoyer qu'un cadre presque vide et des scripts. C'est le navigateur qui fabrique ensuite le texte, le titre, la description et l'adresse canonique, celle que le moteur doit retenir. La documentation de Google sur le JavaScript précise que les pages passent par une file d'attente de rendu avant d'être indexées, et que si Google trouve une consigne noindex dans la page envoyée, il peut ne jamais exécuter le JavaScript qui la retirerait.

Faites donc comparer la réponse brute du serveur et la page affichée, au moins sur l'accueil : sur une application de ce type, les balises viennent en général d'un gabarit commun, et ce qui est faux sur une page l'est souvent sur les autres. L'adresse canonique et la consigne noindex doivent être présentes et identiques des deux côtés, et placées dans l'en-tête de chaque page. Quand elles diffèrent, ou que seul le navigateur les pose, le moteur peut retenir la mauvaise version. Le guide sur le référencement d'un site en JavaScript explique ce que Google fait de ces pages.

Faites aussi vérifier ce que répond une adresse qui n'existe pas. Quand l'hébergement renvoie la même page pour toutes les adresses et laisse le script décider quoi afficher, une page inconnue répond « 200 », comme une vraie, avec un message d'erreur dessiné à l'écran. Google consacre une section de la même documentation à ces erreurs dans les applications à page unique, et le guide sur ce qu'une adresse inconnue doit répondre dit pourquoi ce code compte.

Si le fichier robots.txt ou le plan du site manquent, ils s'ajoutent sans toucher au site. Les balises construites par le navigateur et le code d'erreur demandent de reprendre l'application : c'est un projet, à confier à la personne qui en reprend le code, avec la liste des pages concernées.

Clés, cartes de sources, bibliothèques : le code que tout visiteur peut lire

Tout le JavaScript qu'une page charge est public : n'importe quel visiteur peut le lire. Les clés qui relient le site à ses services y sont visibles dès qu'elles ont été placées dans le code de la page.

Certaines n'ont rien à y faire : la clé secrète d'un service de paiement, la clé d'accès à un compte d'hébergement, un jeton d'accès, une clé privée. Si l'une d'elles s'y trouve, considérez-la comme connue : faites-la remplacer, pas seulement retirer du code. Les clés publiques par nature, comme la clé de publication d'un service de paiement, sont faites pour être lues.

Les cartes de sources (source maps) relient le code compressé servi aux visiteurs au code d'origine, avec son arborescence et ses commentaires. Elles servent au développement ; publiées avec le site, elles donnent à n'importe qui le code tel qu'il a été écrit. Demandez qu'elles restent hors ligne.

Le code généré assemble aussi des bibliothèques écrites par d'autres, dans la version retenue le jour de la génération. Quand des vulnérabilités sont publiées ensuite pour cette version, elles restent dans le code servi tant que personne ne met la bibliothèque à jour. Demandez qui suit ces mises à jour une fois le site en ligne.

Les en-têtes de sécurité dépendent de l'hébergement plus que de l'outil : un site généré hérite des réglages de la plateforme qui le publie. La question se pose donc à cette plateforme, ou à qui gère l'hébergement : le site envoie-t-il l'en-tête HSTS, qui oblige le navigateur à rester en HTTPS, et une politique de sécurité du contenu (CSP), qui limite les scripts qu'une page peut exécuter ? Le guide sur les en-têtes de sécurité HTTP dit ce que chacun protège.

Mentions, traceurs, hébergeur : ce que l'outil ignorait de vous

Un site d'entreprise doit dire qui l'édite et qui l'héberge. Un outil de création ne connaît ni votre raison sociale, ni votre numéro d'immatriculation, ni le nom de votre hébergeur : ces informations manquent tant que vous ne les avez pas données. Vérifiez que la page existe, qu'elle est liée depuis le site et qu'elle porte tout ce qui est exigé ; le guide sur les mentions légales d'un site internet en donne la liste.

Une mesure d'audience, une police chargée depuis un service tiers, une carte ou une vidéo intégrée s'ajoutent en une phrase. Elles peuvent déposer un cookie ou transmettre l'adresse IP du visiteur dès l'affichage, avant qu'il ait répondu au bandeau de consentement, quand il y en a un. La présence d'un bandeau ne suffit pas : ce qui compte, c'est ce qui part avant la réponse du visiteur, et cela se constate sur une page chargée sans aucun clic.

Un outil de création publie le site sur l'hébergement qu'il a choisi, et peut le relier aux services qu'il intègre : base de données, envoi d'emails, mesure d'audience. Sachez qui sont ces fournisseurs, dans quel pays ils opèrent et quel droit s'applique à eux. Un serveur situé en Europe ne suffit pas à trancher, et le guide sur la portée du CLOUD Act explique pourquoi.

Demandez aussi ce que vous emporteriez en partant. Les exemples que nous publions montrent les deux cas. Le rapport d'un site vitrine B2B, construit avec Webflow, un outil de création sans code, note que le site vit sur une plateforme hébergée dont l'export ne reprend pas toutes les fonctions. Celui d'une boutique en ligne, une application maison, la juge portable d'un hébergeur à l'autre. Changer d'hébergeur ou de base de données est un projet, qui se décide en sachant de qui le site dépend : c'est la question que pose l'audit de l'hébergement et des dépendances.

D'abord les clés, ensuite ce qui ne touche pas à l'application

L'ordre suit deux questions : ce qui vous expose le plus, et ce qui se corrige sans reprendre l'application.

1. Faites vérifier le site publié par quelqu'un d'extérieur au projet, avant d'y envoyer du trafic ou dès sa mise en ligne, et obtenez le résultat par écrit, page par page.
2. Si une clé secrète apparaît dans le code public, faites-la remplacer sans attendre.
3. Corrigez ce qui ne touche pas à l'application : mentions légales, blocage des traceurs jusqu'au consentement, robots.txt et plan du site.
4. Confiez à la personne qui reprend le code ce qui demande de reprendre l'application : les balises que seul le navigateur construit, le code renvoyé à une adresse inconnue, les cartes de sources publiées, les bibliothèques à mettre à jour.
5. Faites vérifier à part ce qui ne se voit pas de l'extérieur, comme les droits d'accès à votre base de données, par une personne qui a accès au projet.
6. Choisissez l'hébergement et les services branchés en connaissant leur pays et leur droit, puis faites revérifier le site une fois les corrections faites.

Les mêmes défauts, quel que soit l'outil

Ces pourcentages portent sur une trentaine de sites audités entre le 14 août 2026 et le 24 septembre 2026. Chacun ne compte que les sites où le point a pu être vérifié. Beaucoup ont été audités parce qu'un défaut s'y voyait vite : ces chiffres décrivent nos audits, pas l'ensemble des sites.

Ces chiffres ne distinguent pas les sites selon la façon dont ils ont été faits : aucun de ces défauts n'est propre aux outils de création par IA. Ce sont ceux qu'aucun aperçu ne montre, quel que soit l'outil.

Dans la boutique publiée en exemple, le script principal embarque axios 1.7.7, une bibliothèque qui compte 30 vulnérabilités publiées, dont 15 de gravité haute ou critique. Le rapport précise qu'une seule mise à jour les supprime toutes. Le contrôle sait aussi rendre l'autre verdict : dans les deux rapports publiés, aucun secret et aucune carte de sources n'ont été trouvés dans le code servi.

Ni accès à l'outil, ni code : l'adresse du site suffit

Un site fait avec une IA reçoit le même examen que les autres, un audit sur 9 piliers : sécurité et chiffrement, performance, référencement, accessibilité, conformité et vie privée, domaine et réseau, indépendance et résilience, contenu et confiance, expérience et fiabilité. Les listes de contrôle proposées pour les sites générés portent le plus souvent sur les textes, les formulaires ou la sécurité du code. L'audit lit le site publié, et chaque point de cette page figure dans le même rapport.

Chaque page analysée est chargée dans un navigateur. Sur la page de référence, en général l'accueil, la réponse du serveur avant tout script et la page affichée sont conservées dans une même visite, et les balises qui décident de l'indexation sont confrontées ; sur toutes les pages, leur place dans l'en-tête est vérifiée. Une adresse inventée est demandée, et le code renvoyé noté. Les scripts des pages analysées sont téléchargés, avec leurs bibliothèques et leurs versions, et l'on y cherche les clés qui ne doivent jamais se trouver chez le visiteur, sans compter les clés publiques par nature. La page est ouverte sans aucun clic, pour relever ce qui s'est déjà déposé et ce qui est déjà parti vers des tiers. Chaque couche est rattachée à son fournisseur, à son pays et au droit dont il relève.

Le rapport cite, pour chaque constat, la page et la valeur observée, et vous pouvez le remettre, sans le réécrire, à la personne qui reprendra le site. L'audit porte sur ce qui est observable depuis l'extérieur du site. Chaque limite de l'examen est indiquée dans le rapport. Un point non vérifiable n'est jamais présenté comme conforme. Si un prestataire a construit le site pour vous, le guide pour vérifier le travail d'une agence web traite ce cas.

Les forfaits commencent à 200 € HT ; seuls changent le nombre de pages analysées et le prix. Ils sont détaillés sur la page des tarifs. Le rapport est livré en 5 jours ouvrés jusqu'à 60 pages, paiement encaissé à la livraison. Avant de commander, vous pouvez lire les rapports d'exemple, tirés de deux audits réels.