Audit de site web par IA : auditer un site avec des agents IA, des preuves jusqu’à un correctif vérifié

1. Ce qu’est un audit de site web par IA

Un audit de site web vérifie comment un site est construit, délivré et connecté : s’il est protégé, si les moteurs de recherche et les systèmes d’IA peuvent le lire, si les personnes peuvent l’utiliser, sa rapidité, et quels services tiers il charge. Un audit de site web par IA ajoute un agent IA à ce travail. L’agent lance les contrôles, lit les résultats, les explique en langage clair, décide avec vous quoi corriger en premier et rédige la demande de modification pour la personne ou l’agent de code qui fera le correctif.

Trois approches assez différentes sont décrites avec les mêmes mots :

Ce guide porte sur la troisième approche, car c’est là que l’IA fait gagner un vrai temps tout en gardant chaque constat lié à une preuve vérifiable. Les contrôles restent reproductibles ; l’agent apporte du jugement, du contexte et la transmission aux personnes et outils qui livrent les changements. Si MCP est nouveau pour vous, le guide de MCP explique hôtes, clients, serveurs et outils simplement.

2. Ce qu’un agent IA peut et ne peut pas faire seul

Un modèle de langage est très bon pour lire, résumer et écrire. Ce n’est pas un outil réseau. Sans outil fourni par l’application, il ne voit pas ce que voient un navigateur ou un robot d’exploration sous la page visible. Le tableau compare un agent seul, avec au mieux un outil de navigation web, et le même agent travaillant à partir de contrôles structurés.

Les agents de code dotés d’un terminal, comme Claude Code, Codex ou Cursor, peuvent aussi exécuter eux-mêmes curl, dig ou openssl. C’est utile pour confirmer un constat, mais l’agent choisit ses commandes au fil de l’eau : la couverture dépend de ce qu’il pense à vérifier, les résultats varient d’une exécution à l’autre, et rien ne limite ses sondes aux domaines que vous avez vérifiés.

Le risque de la colonne du milieu a un nom. La liste OWASP des risques des applications LLM décrit la désinformation comme une sortie fausse ou trompeuse qui semble crédible, l’hallucination en étant l’une des causes majeures, aggravée quand on s’y fie sans vérifier. Dans un audit, cela donne « votre politique DMARC est à none » pour un domaine dont le modèle n’a jamais lu l’enregistrement, ou un en-tête déclaré absent alors que le serveur l’envoie.

Un second risque vient des pages elles-mêmes. Un agent qui lit un site lit du texte non fiable, et une page peut contenir des instructions destinées au modèle, parfois cachées aux visiteurs humains. L’OWASP appelle cela l’injection de prompt indirecte. Une configuration d’audit prudente traite le contenu des pages comme des données à rapporter, jamais comme des instructions, et garde une personne pour approuver toute action de l’agent.

L’agent excelle dans tout ce qui entoure la preuve : expliquer ce qu’un constat signifie pour ce site précis, regrouper les constats liés, poser des questions sur un contexte que les contrôles ne peuvent pas connaître (ce vieux sous-domaine de préproduction est-il encore utilisé ?) et rédiger une demande de correctif assez précise pour un agent de code. Cette répartition du travail est le cœur d’un bon audit de site web par IA.

3. Les six domaines à couvrir, avec une checklist pour chacun

Un audit de site web approfondi examine six couches. Chacune répond à une question différente et produit un autre type de preuve. Le guide de l’audit de site web suit un même parcours client à travers les six ; voici la checklist de travail.

Sécurité

• HTTPS et TLS : une chaîne de certificats de confiance, aucune expiration dans les prochaines semaines, TLS 1.2 ou 1.3, et HTTP redirigé vers HTTPS.
• En-têtes de sécurité : Strict-Transport-Security, Content-Security-Policy, X-Content-Type-Options, protection contre l’inclusion en cadre et Referrer-Policy sur les réponses HTML.
• CORS : pas de Access-Control-Allow-Origin: * sur les réponses qui portent des données privées, et pas d’origines réfléchies combinées à des identifiants.
• DNS et DNS de messagerie : des enregistrements SPF et DMARC valides pour chaque domaine qui envoie du courrier, et restrictifs (v=spf1 -all, p=reject) pour les domaines qui n’en envoient jamais.
• Fichiers et secrets exposés : rien d’accessible à des chemins comme /.env, /.git/ ou d’anciennes sauvegardes, et aucune clé d’API dans le JavaScript front-end.
• Sous-domaines : aucun enregistrement DNS pointant vers des ressources cloud supprimées que quelqu’un d’autre pourrait réclamer (subdomain takeover).
• Surface d’attaque : seulement les ports ouverts et méthodes HTTP voulus, des pages de connexion et d’administration connues, et un CMS et des extensions à jour si vous utilisez WordPress.
• Chaîne d’approvisionnement : des scripts tiers chargés uniquement depuis des sources que vous avez choisies.

Certains de ces contrôles ne lisent que des informations publiques. D’autres, comme la requête de chemins sensibles ou le scan de ports, envoient des requêtes auxquelles le propriétaire doit consentir, c’est pourquoi un outil d’audit ne devrait les lancer que sur des cibles dont vous avez vérifié la propriété. Le guide de l’audit de sécurité d’un site web couvre le côté application : comptes, permissions et connexion.

SEO technique

• Exploration : robots.txt ne bloque pas les pages ou ressources que vous voulez indexer.
• Indexation : pas de noindex égaré sur des pages importantes, et un sitemap qui liste les URL canoniques.
• Titres et meta descriptions : présents, uniques et décrivant la page.
• Intertitres : un titre principal clair et un plan logique.
• Canonicals : chaque page pointe vers son URL préférée, jamais vers une redirection ou une page d’erreur.
• Données structurées : du JSON-LD valide, cohérent avec le contenu visible.
• Liens internes et redirections : pages importantes accessibles depuis la navigation ou le contenu, et pas de chaînes de plusieurs redirections.
• Données Search Console : pages à nombreuses impressions mais faible taux de clic, et requêtes où vous êtes classé juste sous les premiers résultats. Ce sont souvent les gains les plus rapides.

Une limite compte ici. Google exécute le JavaScript avant d’indexer une page, mais ses bases du SEO JavaScript recommandent toujours le rendu côté serveur ou le pré-rendu, en partie parce que certains robots ne savent pas exécuter le JavaScript. Un audit qui lit le HTML statique voit la page comme ces robots ; sur un site qui construit son contenu dans le navigateur, comparez ses constats avec la page rendue. Le guide de l’audit SEO technique va plus loin.

Préparation à la visibilité IA

• Politique des robots IA : les règles robots.txt pour chaque robot IA correspondent à ce que vous avez décidé, pas à un réglage par défaut d’une extension que personne n’a choisi. Plusieurs fournisseurs documentent des jetons distincts pour leurs robots de recherche et d’entraînement ; Google décrit par exemple Google-Extended à côté de ses robots de recherche.
• llms.txt : facultatif. Un court index Markdown de vos pages les plus utiles, surtout pertinent pour les sites riches en documentation ; le guide llms.txt explique ce qu’il fait et ne fait pas.
• Clarté de l’entité : mêmes nom d’entreprise, description, localisation et coordonnées partout, appuyés par des données structurées Organization.
• Capacité à répondre : des pages qui répondent directement aux vraies questions des clients, en haut, en texte plutôt qu’en images.
• Couverture des prompts : la liste des questions que les acheteurs posent à un assistant et, pour chacune, la page de votre site qui y répond.
• Signaux de source : un auteur ou une organisation nommés, des dates et des citations qui facilitent la citation et l’attribution d’une page.

Ce sont des contrôles de préparation sur votre propre contenu. Ils ne montrent pas si un assistant vous cite aujourd’hui ; cela demande un journal séparé de questions et de réponses. Google indique que ses fonctionnalités d’IA n’ont aucune exigence supplémentaire au-delà de l’éligibilité normale à la recherche, donc l’accès d’exploration et un contenu clair passent en premier. Le guide de l’audit de visibilité IA montre comment construire l’ensemble de questions.

Accessibilité

• Alternatives textuelles : chaque image informative a un texte alternatif pertinent, et les images décoratives un texte vide.
• Formulaires : chaque champ a un libellé programmatique, pas seulement un texte d’exemple (placeholder).
• Structure : intertitres dans l’ordre, repères comme main et nav, et un lien d’évitement.
• Noms : chaque bouton et lien a un nom accessible, et il n’y a pas de liens vides.
• Langue : la page déclare sa langue avec l’attribut lang.
• Contrôles manuels : usage au clavier seul, focus visible, contraste des couleurs, zoom et reflow, et un passage avec un lecteur d’écran.

Le W3C est explicite : les outils ne peuvent pas vérifier automatiquement tous les aspects de l’accessibilité et un jugement humain est nécessaire. Un contrôle automatique trouve le libellé manquant ; seule une personne peut dire s’il a du sens. Le guide de l’audit d’accessibilité décrit le passage manuel selon les WCAG 2.2.

Performance

• Core Web Vitals : Largest Contentful Paint sous 2,5 secondes, Interaction to Next Paint sous 200 millisecondes et Cumulative Layout Shift de 0,1 ou moins, au 75e centile des chargements de page (web.dev).
• Données terrain d’abord : les données du Chrome UX Report montrent ce que les vrais utilisateurs de Chrome ont vécu sur les 28 derniers jours, quand la page ou le site a assez de trafic pour être inclus ; les résultats labo de Lighthouse aident à trouver la cause.
• Mobile d’abord : testez la version mobile des pages qui comptent, comme la page d’accueil, une page produit ou service et le paiement ou le formulaire de contact.
• Causes habituelles : une image principale surdimensionnée, des scripts et polices bloquant le rendu, des décalages de mise en page dus à des images sans dimensions ou à des bandeaux tardifs, et des balises tierces lourdes.

La documentation de PageSpeed Insights note que les données labo et terrain peuvent différer, et qu’un bon score labo ne signifie pas que les vrais visiteurs ont eu une bonne expérience. Le guide de l’audit de performance d’un site web montre comment relier une métrique lente à l’élément qui la cause.

Intégrations

• Inventaire : tous les outils d’analyse, gestionnaires de balises, pixels publicitaires, outils de consentement et balises de vérification de site présents sur la page, et le responsable de chacun.
• Doublons et restes : deux copies de la même balise d’analyse, ou un pixel d’une campagne terminée l’an dernier.
• Consentement : un outil de consentement là où il en faut un, et des balises qui l’attendent.
• Données personnelles : aucune adresse e-mail, aucun numéro de téléphone ni nom dans le data layer, les URL ou les titres de page que lisent les balises. L’aide Google Analytics demande par exemple aux propriétaires de sites de tenir les informations personnelles identifiables hors des URL, titres et événements.

Les contrôles statiques montrent ce que le balisage déclare. Savoir si une balise attend réellement le consentement, ou quels événements se déclenchent après un clic, demande une session de navigateur avec les outils de développement ouverts. Le guide de l’audit des intégrations d’un site web détaille cette trace.

4. Comment auditer un site web avec l’IA, pas à pas

Le Model Context Protocol (MCP) est un moyen courant pour une application d’IA d’appeler les outils d’autres services. Avec un service d’audit connecté, l’agent de votre chat ou de votre outil de code peut lancer des contrôles et travailler directement avec les résultats. Le workflow compte neuf étapes ; les deux premières se font une fois par site, les autres se répètent à chaque audit.

1. Connecter. Ajoutez le service d’audit comme connexion MCP dans votre client IA et connectez-vous via le navigateur. Les serveurs MCP distants qui exigent un compte utilisent généralement OAuth, comme décrit dans la spécification d’autorisation MCP : vous approuvez l’accès dans une fenêtre de connexion et ne collez jamais de mot de passe ni de clé d’API dans le chat. Sitelemetry se connecte ainsi dans ChatGPT, Claude, Claude Code, Codex et Cursor ; le guide de connexion MCP détaille les étapes pour chaque client.
2. Définir le périmètre et l’autorisation. Décidez quels sites et pages sont concernés, et n’auditez que des sites dont vous êtes propriétaire ou que vous avez l’autorisation écrite de tester. Les contrôles passifs lisent ce que tout visiteur peut voir ; les contrôles de sécurité actifs envoient des requêtes de sondage, ils ne doivent donc être lancés qu’après avoir vérifié le contrôle du domaine. Donnez le périmètre à l’agent en termes simples : production uniquement, ces trois URL, aucun envoi de formulaire.
3. Lancer l’audit. Demandez un audit complet ou d’un seul domaine : « Lance un audit complet de https://www.example.com et liste les constats par gravité. » Les longs audits peuvent tourner en tâche de fond ; laissez l’agent attendre le résultat au lieu de lancer un second scan.
4. Lire les preuves. Chaque constat doit venir avec une gravité, la preuve observée, l’impact et une remédiation. Demandez à l’agent de citer la preuve de tout constat jugé élevé, et reproduisez un ou deux constats vous-même avec curl -sI ou dig. Un constat que vous pouvez reproduire est un constat que vous pouvez corriger en confiance.
5. Prioriser. Triez par gravité, puis par exposition (la page est-elle publique, gère-t-elle la connexion ou le paiement ?), puis par effort. Regroupez les constats qui partagent un même correctif, comme plusieurs en-têtes définis dans la même configuration serveur, et demandez à l’agent lesquels comptent pour ce site et lesquels présentent peu de risque ici.
6. Transmettre un prompt de correctif prêt pour l’agent au agent de code. Transformez les constats retenus en une demande de modification précise, avec preuve, contraintes, critères d’acceptation et étapes de nouveau test (exemple plus bas). Donnez-la à l’agent de code qui travaille dans votre dépôt, ou laissez le même client faire les deux s’il a accès au dépôt.
7. Livrer via votre processus habituel. Relisez le diff, testez en préproduction et déployez comme pour tout changement. L’audit ne remplace pas la revue de code, et un agent de code ne doit pas déployer sans l’accord d’une personne.
8. Relancer l’audit pour vérifier. Lancez le même contrôle sur la même cible après le déploiement. Un constat est clos quand un résultat tout frais ne le montre plus, pas quand l’agent dit avoir modifié un fichier.
9. Surveiller. Planifiez la répétition de l’audit pour qu’une mise à jour d’extension, une nouvelle balise ou un certificat sur le point d’expirer apparaisse avant que les visiteurs ne s’en aperçoivent. Une fois par semaine convient à la plupart des petits sites ; les sites qui déploient tous les jours gagnent à un rythme quotidien.

La spécification MCP recommande une personne dans la boucle pouvant refuser les appels d’outils, et l’OWASP classe l’autonomie excessive, c’est-à-dire le risque d’actions dommageables quand un agent dispose de plus de fonctions, de permissions ou d’autonomie que sa tâche n’en demande, comme un risque à part entière. En pratique : laissez les outils d’audit en lecture, et gardez une personne qui approuve les changements de code et les déploiements.

Un prompt de correctif qu’un agent de code peut exécuter sans deviner a cette forme (exemple illustratif) :

Fix: Strict-Transport-Security header missing
Target: https://www.example.com (all HTTPS responses)
Evidence: GET / over HTTPS returned 200 without a
Strict-Transport-Security header.
Constraints:
- Change only the header configuration of the web server or CDN.
- Use max-age=300 for now (first rollout stage); no preload.
- Do not change redirects, cookies or other headers.
Acceptance criteria:
- curl -sI https://www.example.com/ shows a
  Strict-Transport-Security header with max-age=300.
- The header is present on HTML, CSS and JavaScript responses.
Retest:
- Re-run the security audit for www.example.com and confirm
  the finding no longer appears.

Chaque partie a son rôle. La preuve indique à l’agent de code ce qui a été observé, pour qu’il n’ait pas à redécouvrir le problème. Les contraintes gardent le changement petit ; démarrer HSTS avec un max-age court et l’augmenter par étapes est la voie prudente décrite dans le guide HSTS. Les critères d’acceptation sont des commandes que n’importe qui peut exécuter, et l’étape de nouveau test boucle la boucle avec le contrôle même qui a trouvé le problème.

5. Comment évaluer un outil d’audit de site web par IA

Cherchez le meilleur outil IA pour auditer un site web et vous trouverez de longues listes. Le bon choix dépend de votre site, mais les questions qui distinguent un vrai outil d’audit par IA d’un chatbot flanqué d’un scanner sont les mêmes pour tous les produits.

Testez ensuite tout candidat sur votre propre site avant de vous y fier :

• Lancez-le deux fois sur la même page sans changement. Les constats et les gravités doivent concorder.
• Vérifiez trois constats à la main, un en sécurité, un en SEO et un en accessibilité, avec curl, dig ou le code source de la page.
• Installez un problème connu en préproduction, comme une image sans texte alternatif ou un titre en double, et voyez s’il est signalé.
• Corrigez un constat et relancez l’audit. Il doit disparaître, et rien d’autre ne doit changer.
• Lisez les limites. Un outil qui dit ce qu’il ne vérifie pas inspire plus confiance que celui qui prétend tout vérifier.

La section 8 liste ce que couvre Sitelemetry, comment il transmet les correctifs et où sont ses limites.

6. Pièges courants et comment les éviter

Le fil conducteur est le même partout. Traitez l’agent comme un collègue rapide et éloquent qui n’a pas vu le serveur : donnez-lui des preuves, gardez ses permissions étroites, et vérifiez le résultat sur le site en ligne.

7. Un exemple concret : le site d’un petit cabinet

Un cabinet dentaire exploite un site WordPress à www.example-clinic.com avec un formulaire de réservation en ligne. La responsable administrative connecte un service d’audit à son assistant IA, vérifie le domaine et demande un audit complet de la page d’accueil et de la page de réservation. Parmi les résultats (illustratifs, pas des données réelles) :

L’agent explique pourquoi les deux premiers passent en tête : la sauvegarde expose des données à quiconque devine le chemin, et l’adresse dans le code de suivi est transmise à chaque balise tierce qui lit le data layer. Il demande si le blocage des robots IA était voulu. Personne n’avait décidé, ce qui en fait une décision du propriétaire plutôt qu’un correctif.

Pour la sauvegarde, le correctif n’est pas du code : supprimer le fichier, chercher d’autres copies sur le serveur et trouver quel processus l’a créé. Puis consulter les journaux d’accès pour d’éventuels téléchargements antérieurs, changer les mots de passe ou clés que contenait la sauvegarde et, si des données de patients ont pu être exposées, suivre la procédure de violation de données du cabinet. Pour les libellés du formulaire, l’agent rédige un prompt de correctif qui nomme les cinq champs et la page de réservation concernée, avec la contrainte que le design visuel reste identique et le critère d’acceptation qu’un lecteur d’écran annonce un libellé pour chaque champ. L’agent de code du développeur fait la modification, le développeur la relit et la déploie, et un nouvel audit montre que le constat a disparu. L’enregistrement DMARC revient à la personne qui gère le DNS, en commençant par p=none avec des rapports, comme l’explique le guide du déploiement de DMARC. Chaque point se termine de la même façon : modifié, déployé et revérifié avec l’audit qui l’avait trouvé.

8. Appliquer ce workflow avec Sitelemetry

Sitelemetry est un outil d’audit de site web par IA conçu pour le workflow de ce guide :

• Six domaines. La sécurité, avec jusqu’à 27 modules dans l’offre Enterprise : DNS, SPF et DMARC, TLS, posture HTTPS, en-têtes de sécurité, CORS, fichiers exposés, exposition d’API et de secrets, subdomain takeover, chaîne d’approvisionnement, surface d’authentification, ports ouverts, méthodes HTTP, WordPress et plus. Le SEO technique, avec clics, CTR, position et gains rapides de Google Search Console. La préparation à la visibilité IA, l’accessibilité, la performance via PageSpeed Insights, Lighthouse et les données terrain CrUX, et les intégrations.
• Preuves et correctifs. Les constats portent gravité, preuve, impact et remédiation, et chaque audit peut produire un prompt de correctif prêt pour l’agent avec contraintes, critères d’acceptation et étapes de nouveau test.
• Dans vos outils d’IA. Il fonctionne via MCP avec connexion OAuth dans ChatGPT, Claude, Claude Code, Codex et Cursor ; le guide de connexion MCP montre comment se connecter. La connexion OAuth signifie que vous approuvez l’accès dans une fenêtre de navigateur et ne collez jamais de mot de passe ni de clé d’API dans le chat.
• Vérifier et surveiller. Relancez l’audit après un correctif pour le confirmer sur le site en ligne. Selon l’offre, la surveillance s’exécute chaque semaine, chaque jour ou chaque heure. Les rapports s’exportent en JSON ou PDF, avec des rapports en marque blanche dans Enterprise.
• Offres. Starter à 49 $/mois, Professional à 149 $/mois et Enterprise à 249 $/mois ; la page des tarifs détaille ce que chacune inclut.

Ses limites sont celles que ce guide vous invite à chercher. Les audits hébergés observent la cible sans la modifier, et les contrôles de sécurité actifs ne s’exécutent que sur des cibles vérifiées. Les contrôles SEO, visibilité IA, accessibilité et intégrations lisent le HTML statique sans exécuter de JavaScript. La visibilité IA vérifie la préparation du contenu et n’interroge pas les assistants IA. Les contrôles d’accessibilité sont statiques et orientés WCAG 2.2, pas une évaluation manuelle complète, et l’audit de sécurité n’est pas un test d’intrusion. Gardez les contrôles manuels de la section 3 pour ce que l’analyse statique ne voit pas.