Audit d'accessibilité IA pour la préparation aux agents

Les systèmes d’IA ne peuvent pas citer, recommander ou agir sur un contenu qu’ils ne peuvent pas récupérer de manière fiable. Cette phase teste cette base avant que l’équipe ne mesure la visibilité ou ne commande du contenu destiné aux moteurs de réponse.

Phase : P4, Stade A — Comprendre. Durée : 3 à 5 jours ouvrés pour un site marketing typique ; 5 à 10 pour un grand site e-commerce, une marketplace ou une application fortement rendue côté client. Responsable : le responsable SEO technique est redevable, avec l’ingénierie qui exécute les tests de récupération et de rendu, le responsable contenu qui examine l’extractibilité, et un responsable métier ou juridique qui décide de la politique des robots.

Pourquoi cette phase intervient ici

Un audit technique classique vérifie si les moteurs de recherche peuvent explorer, rendre, indexer et classer le site. Cette phase vérifie si les robots d’IA, les systèmes de récupération et les agents orientés tâches peuvent atteindre et interpréter les mêmes informations utiles. Ils peuvent utiliser des agents utilisateur différents, des chemins de récupération, des capacités de rendu, des délais d’attente et des méthodes d’extraction différents. Une page indexable peut toujours renvoyer une coquille vide, un mur de consentement, un défi robot ou des fragments déconnectés à un client IA.

Un audit d’accessibilité IA a donc sa place aux côtés de l’audit de base technique , et non à la fin de la production de contenu. Le rendu côté client fait que JavaScript construit un contenu important après l’arrivée du HTML initial. Les systèmes de récupération peuvent ne pas exécuter ce code, s’arrêter avant sa fin, ou extraire uniquement la réponse initiale. Si le nom du produit, la réponse, le prix, la disponibilité ou la preuve n’existent qu’après l’exécution de JavaScript, l’optimisation ultérieure du contenu ne peut pas réparer l’échec d’accès.

Cette phase consomme les comptes vérifiés, les analyses, les journaux des robots, les sources de sitemap, l’ensemble d’URL critiques et la cartographie des propriétaires issus de la phase d’accès, de suivi et de sources de données . La réaliser plus tôt empêche l’équipe de distinguer une absence réelle d’un manque d’accès. La réaliser après la mesure de référence contamine la référence : zéro citation peut refléter un site inaccessible, et non un contenu faible ou une demande insuffisante.

Sauter cette phase gaspille du travail : les rédacteurs améliorent des passages qu’un robot ne reçoit jamais, les développeurs ajoutent du schéma derrière un défi, ou l’équipe confond un fichier llms.txt valide avec une préparation à l’échelle du site. L’accès, l’extraction, la compréhension et l’action sont des capacités distinctes.

Entrées et sorties

Les entrées rendent les tests reproductibles. Les sorties forment un contrat avec P5 : la mesure ne commence qu’après que les échecs d’accès connus sont corrigés ou explicitement acceptés.

La liste de vérification

Testez l’ensemble d’URL représentatives, pas seulement la page d’accueil, et conservez des preuves reproductibles.

1. Décider délibérément de l’accès des robots

Quoi faire : inventorier les règles relatives aux robots d’IA dans robots.txt , les contrôles de robots du CDN, les pare-feu d’applications web, les couches de consentement et la configuration d’origine. Pourquoi c’est important : une autorisation dans robots.txt n’est qu’une préférence ; un service périphérique peut toujours bloquer la requête, tandis qu’un blocage générique accidentel n’est pas une politique. Comment faire : comparez les règles en production avec la matrice de politique, récupérez les URL représentatives avec les agents utilisateur applicables et enregistrez le compromis. Outil : AmICited Robots.txt & Sitemaps, un client de requête approuvé, et les journaux CDN/origine. Terminé quand : chaque famille de robots a une décision approuvée (autoriser, bloquer ou conditionnel) et le comportement en production y correspond.

2. Comparer la réponse sans JavaScript avec la page utile

Quoi faire : comparer le HTML initial avec la page du navigateur normal. Pourquoi c’est important : un client de récupération peut ne pas exécuter les scripts qui insèrent des réponses, offres, liens ou données produits. Comment faire : testez chaque modèle important avant l’hydratation, le processus qui attache le comportement applicatif au HTML serveur. Outil : un navigateur sans script ou un client HTTP ainsi que la page rendue. Terminé quand : la réponse initiale contient le titre, le H1, le contenu principal, les faits essentiels et les liens de découverte ; toute exception a une preuve et un responsable.

3. Tester l’extractibilité du DOM rendu

Quoi faire : extraire le contenu principal du modèle d’objet de document (DOM) rendu, la représentation structurée de la page par le navigateur, sans navigation, texte de consentement ou variantes cachées. Pourquoi c’est important : recevoir du texte n’est pas la même chose qu’identifier le bon texte ; le bruit des modèles peut corrompre la récupération. Comment faire : comparez le titre, la réponse, l’éditeur, les dates, les faits et les liens extraits avec la source visible sur des pages longues, denses et commerciales. Outil : inspection du navigateur, extraction de texte et code source de la page. Terminé quand : l’enregistrement préserve le sens principal et les faits sans position visuelle ni sélecteurs non documentés.

4. Inspecter l’arbre d’accessibilité

Quoi faire : examiner l’arbre d’accessibilité : rôles, noms, états, titres, points de repère et contrôles. Pourquoi c’est important : la sémantique distingue les titres de la décoration, les boutons des icônes et le contenu principal de la navigation. Comment faire : testez les modèles critiques pour un H1, des titres ordonnés, des contrôles nommés, des points de repère, des liens descriptifs et des alternatives d’image pertinentes. Outil : vérificateur d’arbre d’accessibilité AmICited et inspection du navigateur. Terminé quand : le score atteint le seuil, aucun contrôle critique n’est sans nom, et la région principale ainsi que la prochaine action sont identifiables.

5. Valider la couverture et la véracité des données structurées

Quoi faire : comparer les faits visibles avec les données structurées , un balisage standardisé tel que Schema.org JSON-LD. Pourquoi c’est important : le balisage clarifie les entités, les offres, la paternité et les dates, mais un balisage inexact communique le mauvais fait. Comment faire : validez les schémas applicables et reconciliez les noms, URL, prix, devises, disponibilité, dates, évaluations et identifiants avec les systèmes sources. Outil : validateur, HTML rendu et enregistrements sources. Terminé quand : les modèles critiques ont un balisage applicable valide, les valeurs correspondent aux faits visibles, et tout avertissement important est résolu ou expliqué.

6. Examiner llms.txt comme guide, pas comme barrière

Quoi faire : vérifier si /llms.txt résume précisément l’organisation et renvoie vers les ressources publiques canoniques. Il s’agit d’un guide textuel proposé, pas d’un contrôle d’accès ni d’un signal de classement garanti. Pourquoi c’est important : une carte concise réduit l’ambiguïté ; une carte obsolète induit les agents en erreur. Comment faire : vérifiez le statut, la structure Markdown, la description, les destinations, les URL canoniques et le responsable. Outil : vérification llms.txt d’AmICited et récupération directe. Terminé quand : le fichier, s’il est utilisé, n’a aucun lien cassé/privé et a un responsable de maintenance ; l’absence est une piste d’amélioration, pas une preuve d’invisibilité.

7. Échantillonner des passages autonomes

Quoi faire : examiner des définitions, réponses, faits, comparaisons, étapes et limitations récupérés indépendamment. Pourquoi c’est important : la récupération peut séparer un paragraphe de son titre ; « ça marche mieux pour eux » perd alors son sujet et sa comparaison. Comment faire : lisez au moins 20 passages sans leur titre ni leur paragraphe précédent. Outil : sortie d’extraction et révision éditoriale. Terminé quand : chacun nomme son sujet, répond à une question identifiable, préserve les conditions ou unités, et évite les références non résolues.

8. Confirmer la clarté de l’entité canonique

Quoi faire : vérifier que le site indique clairement qui est l’organisation, ce qu’elle propose, et comment ses marques, produits, personnes, lieux et profils sont liés. Une entité canonique est la chose réelle principale à laquelle un nom fait référence. Pourquoi c’est important : des noms incohérents, des anciens logos, des descriptions contradictoires et des URL de profil déconnectées facilitent la fusion de deux entités ou la division d’une entité en plusieurs. Comment faire : comparez la page d’accueil, la page À propos, les coordonnées, les données structurées, les profils sociaux, les pages d’auteur, le nom légal et les profils tiers importants. Outil : fiche d’information sur l’entité, pages rendues et sortie des données structurées. Terminé quand : une fiche d’information approuvée résout le nom officiel, les alias, l’URL canonique, le logo, la description, la propriété, les offres principales et les profils de la même entité, avec les conflits enregistrés pour correction.

9. Tester le temps de réponse et la fiabilité de la récupération

Quoi faire : mesurer le statut, le Time to First Byte (TTFB), les redirections, les délais d’attente et la cohérence des réponses dans des conditions normales et avec des agents utilisateur de robots pertinents. Le TTFB est l’intervalle entre le début de la requête et l’arrivée du premier octet de réponse. Pourquoi c’est important : des 403, 429, 5xx intermittents, de longues chaînes de redirection ou des origines lentes rendent le contenu peu fiable même lorsqu’une seule visite de navigateur réussit. Comment faire : exécutez l’échantillon reproductible défini dans le tableau des seuils depuis plus d’un emplacement réseau lorsque la géographie importe, puis reconciliez les échecs avec les journaux et les Core Web Vitals. Outil : moniteur de requêtes, journaux CDN/origine et AmICited Web Vitals. Terminé quand : les URL critiques satisfont les seuils de fiabilité et de latence, ou ont une gravité, une cause, un responsable et une date de nouveau test.

10. Évaluer WebMCP et les protocoles commerciaux là où ils créent de la valeur

Quoi faire : tester la préparation WebMCP et commerce uniquement là où le modèle d’entreprise prend en charge les actions des agents. WebMCP est une manière émergente pour un site web d’exposer des outils appelables, tels que la recherche, la réservation ou l’ajout d’un article à un panier. Le commerce agentique couvre la découverte de produits et les transactions assistées par des agents, y compris des protocoles tels que ACP ou UCP. Pourquoi c’est important : un contenu lisible prend en charge les réponses ; des outils explicites et des données commerciales permettent des actions fiables sans écran de scraping. Comment faire : cartographiez les tâches utilisateur utiles, inspectez les outils ou protocoles déclarés, validez les descriptions d’entrée et de sortie, et vérifiez la confirmation, l’authentification, les autorisations, le prix, les stocks et le comportement en cas d’erreur. Outil : vérifications WebMCP et Commerce Agentique d’AmICited plus un environnement de test contrôlé. Terminé quand : les capacités applicables sont détectées et testables en toute sécurité, ou la vérification est marquée comme non applicable avec une raison de modèle d’entreprise approuvée et un déclencheur de révision.

Outils dans AmICited

Ouvrez https://app.amicited.com/accessibility pour l’audit consolidé et l’explication de la fonctionnalité Accessibilité IA et préparation aux agents . Le produit rapporte des lectures indépendantes plutôt que de cacher différents types d’échecs dans un seul score composite.

1. Utilisez le résumé pour vérifier le score d’accessibilité aux agents et enregistrer chaque composant, pas seulement l’état global.
2. Utilisez Robots.txt & Sitemaps pour vérifier la couverture robots.txt et sitemap , puis comparez la règle énoncée avec une récupération en conditions réelles par un robot.
3. Utilisez la vérification de fichier pour examiner llms.txt et ouvrez chaque destination listée.
4. Utilisez le vérificateur de page pour inspecter l’arbre d’accessibilité d’une page pour chaque modèle critique.
5. Utilisez les vérifications de préparation pour vérifier la préparation WebMCP et vérifier la préparation au commerce agentique lorsque ces capacités s’appliquent.
6. Ouvrez https://app.amicited.com/audit/web-vitals pour vérifier les Core Web Vitals et connecter la performance sur le terrain avec les tests de requêtes en conditions de robot.

Règles de décision

Ce sont des seuils d’acceptation opérationnelle, pas des affirmations sur les algorithmes de classement. Resserrez-les pour les parcours critiques en termes de revenus ou le contenu réglementé, et enregistrez toute alternative avant les tests afin que le résultat ne soit pas ajusté après coup.

Les scores ne remplacent jamais les preuves concrètes. Un score d’accessibilité de 85 n’excuse pas un bouton de paiement non étiqueté, et une autorisation robots.txt ne l’emporte pas sur une page de défi retournée à la véritable requête. « Non vérifié » est inconnu, pas un succès ni un zéro.

Livrable : le registre des constats de préparation aux agents

Remettez un seul registre de constats, pas une présentation et un backlog IA séparé. Ajoutez chaque constat à la liste de priorités P2 avec ces champs :

ID et titre :
URL/modèles affectés :
Vérification et condition observée :
Condition/seuil attendu :
Preuve : horodatage, agent utilisateur, statut, capture ou référence de journal
Conséquence métier :
Gravité : Critique | Majeure | Consultatif
Action recommandée :
Responsable et approbateur :
Effort et dépendance :
Date d'échéance et date de nouveau test :
Décision politique, le cas échéant :
Impact sur la mesure P5 :
Statut : Ouvert | Risque accepté | Corrigé | Vérifié

Critique signifie que l’échec empêche un accès fiable, modifie matériellement le sens extrait ou permet une action non sécurisée. Majeure signifie que l’accès ou la compréhension est dégradé mais qu’un client représentatif peut toujours récupérer le contenu principal. Consultatif signifie une amélioration utile sans preuve d’échec actuel. Risque accepté nécessite le responsable métier nommé, la justification, le périmètre affecté, la date d’expiration ou de révision, et un moyen de détecter des conditions modifiées.

Dédupliquez par cause racine : un défi CDN affectant les robots conventionnels et d’IA est un seul élément avec plusieurs preuves.

Ce qui peut mal tourner

Traiter la phase comme facultative. Le suivi des invites et les réécritures de contenu ne peuvent pas compenser un échec de récupération. Faites de P4 une condition d’entrée pour une référence interprétable.

Bloquer par défaut et appeler ça rétroactivement une politique. Une règle sans décideur, justification ni date de révision est une configuration, pas une politique. Présentez le compromis découverte-contrôle et obtenez une décision explicite.

Ajouter llms.txt et déclarer la phase terminée. Le fichier ne peut pas outrepasser les règles robots, les blocages CDN, le HTML initial vide, le balisage trompeur, les passages faibles ou les délais d’attente. Traitez-le comme un guide parmi l’ensemble plus large des preuves.

Tester uniquement un agent utilisateur amical ou la page d’accueil. Les contrôles périphériques varient selon le chemin, la géographie, le taux et l’identité. Testez chaque modèle à forte valeur et chaque agent utilisateur dans la matrice de politique.

Confondre apparence et extractibilité. Une page soignée peut exposer des doublons cachés, des noms de contrôle insignifiants ou une réponse blanche sans script. Préservez séparément la source, le DOM, l’arbre d’accessibilité et le texte extrait comme preuves.

Traiter l’inconnu comme un échec ou un succès. Retestez les délais d’attente et les robots non vérifiés ; ne convertissez jamais une preuve manquante en un score commode.

Installer des capacités agentiques expérimentales sans cas d’usage. WebMCP ou les protocoles commerciaux devraient exposer des actions utiles et autorisées. Livrer une action non sécurisée ou inexacte est pire que de marquer la capacité comme non applicable.

Transmission à la mesure de référence

La phase de mesure de référence reçoit la liste de priorités fusionnée, le pack de preuves de test, l’enregistrement de la politique des robots, l’ensemble d’URL représentatives et la note de préparation. Le responsable P4 doit identifier toute limitation qui changerait l’interprétation : familles de robots bloquées, modèles inaccessibles, régions intermittentes, passages manquants ou correctif récent dont l’effet ne s’est pas encore propagé.

P5 peut procéder lorsque les URL critiques sont intentionnellement accessibles aux familles de robots incluses dans la mesure, que le contenu principal valide est extractible et qu’aucun constat Critique non résolu ne rendrait un score nul ou faible impossible à interpréter. Il peut procéder avec annotations lorsqu’un blocage délibéré exclut un robot connu ou qu’un problème Majeure affecte un modèle délimité. Il doit attendre lorsque l’intention d’accès est inconnue, que des pages critiques échouent à la récupération ou que le contenu extrait contredit matériellement la source visible.

La transmission est complète lorsque le responsable P5 peut répondre à trois questions sans rouvrir l’audit : quels agents étaient censés avoir accès, quelles pages et quels faits ils pouvaient récupérer de manière fiable, et quelles limitations connues doivent figurer à côté de la référence.

FAQ

Questions fréquentes