Comment fonctionne le score de maturité IA

Les études sur la recherche agentique montrent que les termes de fraîcheur comme 2024 et 2025 dominent les requêtes fan-out. Des dates récentes et structurées aident les agents à faire confiance à l'actualité des conseils saisonniers, des tarifs et des disponibilités.

Réussi : dates structurées mises à jour dans les 12 derniers mois. Partiel : des dates existent mais sont obsolètes ou incohérentes. Échoué : aucun signal de fraîcheur fiable.

Les bonnes pratiques : Un hôtel maintient ses pages chambre, forfait, restaurant et événement marquées avec dateModified de la saison en cours.

Des recherches sur les citations montrent que ChatGPT est bien plus susceptible de citer des pages contenant de vrais tableaux HTML. Les tableaux aident les agents à comparer équipements, saisons, niveaux, tarifs et politiques sans devoir inférer depuis du texte libre.

Réussi : les données clés à la décision apparaissent dans des tableaux HTML sémantiques. Partiel : des comparaisons structurées existent mais sont incomplètes ou uniquement en image. Échoué : aucune structure de comparaison lisible par machine.

Les bonnes pratiques : Une destination publie les saisons d'activités, l'accessibilité, les durées et les fourchettes de prix dans un tableau avec des en-têtes de colonnes clairs.

Les agents opèrent dans des fenêtres de contexte finies et tronquent souvent les pages longues. Les pages dépassant environ 30 000 tokens risquent de perdre les faits précis dont un assistant a besoin pour recommander ou réserver avec confiance.

Réussi : les pages clés s'inscrivent confortablement dans le budget de tokens. Partiel : certaines pages sont lourdes mais encore extractibles. Échoué : les pages importantes sont trop volumineuses ou répétitives pour être lues entièrement.

Les bonnes pratiques : Une page de restaurant présente menu, horaires, réservation, adresse et informations diététiques de façon concise, sans les noyer sous du contenu de mise en page répétitif.

Des alternatives Markdown propres réduisent la surcharge en tokens et suppriment la navigation superflue. Les agents analysent plus vite les titres, listes, liens et faits lorsqu'une route .md reflète la page canonique.

Réussi : les pages importantes exposent des versions .md propres. Partiel : seules certaines pages ou une partie du contenu sont disponibles. Échoué : aucune alternative Markdown n'est découvrable.

Les bonnes pratiques : Une page d'attraction propose /visit.md avec résumé, horaires, liens de billetterie, accessibilité, localisation et FAQ.

Les interfaces IA peuvent promouvoir les entités sous forme de fiches visuelles enrichies lorsque le schéma inclut les propriétés minimales nécessaires à l'affichage. L'absence d'un champ critique — souvent image ou aggregateRating — peut réduire l'entité à une simple mention textuelle.

Réussi : le schéma inclut image, notation ou prix, localisation et URL d'action canonique. Partiel : un champ de fiche non critique est faible ou absent. Échoué : des champs critiques de fiche sont absents.

Les bonnes pratiques : Un hôtel dispose d'image, adresse, geo, aggregateRating, priceRange et ReserveAction sur la page canonique de l'établissement.

Le schéma ne nourrit pas le LLM directement — il nourrit ce que le LLM appelle (Google Places, Maps, le Knowledge Graph). Les propriétés sont évaluées sur trois niveaux d'impact, et ne comptent que si elles sont renseignées sous la forme typée que les moteurs IA analysent réellement — un starRating primitif de 4 échoue au filtre de catégorisation qu'un objet Rating typé réussit.

Réussi : les propriétés du niveau critique (name, description, url, address, identifiant principal) sont toutes renseignées et correctement typées. Partiel : le niveau critique est en ordre mais une ou plusieurs propriétés à fort impact manquent ou sont mal formées. Échoué : des propriétés du niveau critique manquent ou sont mal typées.

Les hôtels bénéficient d'un sous-signal de réconciliation sameAs — posséder l'URL canonique sur 2 plateformes parmi

Les bonnes pratiques : Un hôtel publie name, description, url, address, un objet Rating typé pour starRating, image, aggregateRating, priceRange, sameAs vers Wikidata + Booking + Google Maps, alternateName pour les marques antérieures, et des entrées containsPlace pour les types de chambres.

La vérification s'adapte au type d'entité. Pour les destinations, elle est reformulée en « Liaison d'entités » et évalue la résolution Wikidata QID (50) + sameAs Wikipedia (25) + schéma geo (15) + signal de localité (10) — le QID est résolu côté serveur par requête SPARQL inverse à partir de votre Google Place ID, donc une destination obtient les points même quand l'éditeur ne déclare pas de sameAs. Pour les hôtels et autres lieux, elle se décompose en trois sous-signaux proportionnels : Structure d'adresse (50) + Réconciliation d'entité (30, optionnelle) + Coordonnées géo (20).

Réussi : preuve solide de résolution d'entité pour le type d'entité. Partiel : présent mais incomplet — destination avec geo mais sans QID résolu ; hôtel avec adresse mais sans réconciliation. Échoué : l'IA ne peut ni vous localiser ni vous relier.

Les destinations sont pondérées à 0,08 dans le Socle lisible par machine (contre 0,16 auparavant) parce que « cette ville est-elle localisable ? » est trivialement vrai pour n'importe quel OGD. Le poids libéré est redistribué vers l'exhaustivité du schéma et le schéma rendu côté serveur. Les hôtels conservent les 0,16 — l'adresse compte vraiment pour un établissement précis.

Les bonnes pratiques : Une destination se résout vers son Q-id Wikidata, publie un sameAs Wikipedia et des coordonnées geo, et porte un signal de localité containedInPlace ou addressRegion. Un hôtel publie un PostalAddress typé, un sameAs vers Wikidata ou Booking, et des coordonnées geo.

Les agents doivent distinguer une entité locale d'une chaîne, d'une organisation parente ou d'une marque de gestion. Une hiérarchie claire évite que les recommandations ou liens de réservation soient attribués au mauvais établissement.

Réussi : entité locale, marque parente, adresse et URL de réservation sont distincts. Partiel : la hiérarchie est déductible mais incomplète. Échoué : l'identité de la marque et de l'établissement local sont confondues.

Les bonnes pratiques : Une page de restaurant distingue l'établissement, le groupe hôtelier parent, l'adresse locale et l'URL de réservation.

Les signaux d'avis constituent une référence de confiance pour les agents qui décident de recommander ou non un lieu. Les scores évaluent la profondeur et la fraîcheur plutôt que de se contenter de tout extrait de notation.

Réussi : aggregateRating structuré avec au moins 20 avis et une activité récente. Partiel : des données d'avis existent mais sont insuffisantes, obsolètes ou pas entièrement structurées. Échoué : aucun signal d'avis fiable.

Les bonnes pratiques : Une destination ou un hôtel renvoie vers des plateformes d'avis de confiance et expose aggregateRating avec reviewCount et des données de notation actuelles.

Presque tous les autres contrôles lisent votre propre site : un éditeur déterminé peut les réussir en modifiant son balisage. Celui-ci interroge Wikipédia. Nous résolvons votre destination vers son entité Wikidata — depuis votre schéma quand vous la déclarez, par son nom sinon — puis nous lisons les liens externes de son article, en langue locale et en anglais, et vérifions si votre domaine s'y trouve. Ce sont les contributeurs de Wikipédia qui tranchent, les liens ajoutés par soi-même sont systématiquement annulés, et Wikipédia est une source primaire à la fois pour l'entraînement des IA et pour la citation en direct.

100 si l'article renvoie vers votre domaine, 0 sinon. Exister dans Wikidata est un prérequis, pas des points — presque toutes les destinations y figurent, le noter ne distinguerait personne. La propriété « site officiel » de l'entité et le nombre de langues de son article sont affichés dans votre rapport et ne valent rien.

Si nous ne parvenons pas à résoudre votre entité, ou si Wikipédia est injoignable au moment de l'audit, ce contrôle est ignoré plutôt que noté zéro — une question que nous n'avons pas pu poser ne doit pas se lire comme une réponse à votre défaveur.

Les bonnes pratiques : L'article Wikipédia de la destination cite le site de l'office de tourisme parmi ses liens externes ou ses références.

llms.txt est plus utile lorsqu'il fournit aux agents des routes organisées par tâche, des descriptions et des indications sur les tokens. La qualité est évaluée plutôt que la simple existence du fichier.

Réussi : les entrées incluent descriptions, comptages de tokens et sections par tâche. Partiel : le fichier existe mais est superficiel ou désorganisé. Échoué : aucun signal llms.txt utile.

Google n'utilise pas llms.txt pour Google Search ; nous l'évaluons parce que d'autres moteurs et crawlers IA peuvent l'utiliser. Nous le pondérons comme un signal complémentaire, pas principal.

Les bonnes pratiques : Une destination regroupe les URLs Markdown par catégories planifier un voyage, réserver un hôtel, trouver des événements et informations pratiques, avec de courtes descriptions pour chaque entrée.

Les manifestes lisibles par machine comme llms.txt et les specs JSON permettent aux agents de découvrir quelles entités, tâches et routes ils peuvent utiliser en toute sécurité. Une couverture plus large signifie que les agents ont moins à deviner pour agir.

Réussi : les manifestes décrivent entités, tâches et routes canoniques avec détail structuré. Partiel : une couverture existe mais est superficielle ou manque de surfaces de tâches clés. Échoué : aucune spécification agent utilisable n'est exposée.

Les bonnes pratiques : Un hôtel expose llms.txt ainsi que des manifestes JSON pointant vers les données d'entité canoniques, les points d'accès de réservation et les pages Markdown spécifiques aux tâches.

Les agents ont besoin d'un chemin structuré pour effectuer des transactions au nom d'un utilisateur. Le pilier applique une sous-vérification universelle de point d'accès programmatique sur chaque entité, plus deux sous-vérifications réservées aux hébergements (ReserveAction structuré et URL de politique d'annulation) qui se déclenchent sur les hôtels et les campings.

Réussi : toutes les sous-vérifications applicables sont réussies pour le type d'entité. Partiel : certaines surfaces d'action existent mais sont incomplètes. Échoué : aucun chemin d'action lisible par les agents n'est présent.

Les bonnes pratiques : Un hôtel expose un point d'accès de réservation programmatique (well-known mcp.json / a2a.json ou potentialAction schema.org), un ReserveAction structuré et une URL de politique d'annulation sur la page canonique de l'établissement.

Détermine votre visibilité dans les moteurs de réponse — quand ChatGPT, Claude, Gemini ou Perplexity récupèrent votre site en direct pour le citer dans leurs réponses, c'est cet ensemble de bots qui compte. Bloquer Googlebot pénalise aussi le SEO classique. Nous testons robots.txt et un fetch simulé pour OAI-SearchBot, ChatGPT-User, Claude-User, Googlebot et PerplexityBot.

Réussi : ≥ 80 % des robots de collecte autorisés par robots.txt ET accessibles. Partiel : 50–80 % sur l'un des axes. Échoué : < 50 % sur l'un des axes.

Les bonnes pratiques : robots.txt autorise explicitement OAI-SearchBot, ChatGPT-User, Claude-User, Googlebot et PerplexityBot, et les règles anti-bot du CDN ne les défient pas.

Les crawlers d'entraînement constituent la connaissance long terme que les modèles ont de votre marque. C'est une décision de contrôle de marque à plus long horizon : refuser est légitime, mais les éditeurs utilisent de plus en plus des bots dédiés à la récupération qui respectent ce signal — bloquer l'entraînement ne casse donc plus les citations en direct. Nous testons GPTBot, ClaudeBot, Google-Extended et PerplexityBot.

Réussi : ≥ 80 % des bots d'entraînement autorisés par robots.txt ET accessibles. Partiel : 50–80 % sur l'un des axes. Échoué : < 50 % sur l'un des axes.

Les bonnes pratiques : robots.txt autorise explicitement GPTBot, ClaudeBot, Google-Extended et PerplexityBot — ou vous avez choisi un refus délibéré et documenté pour l'entraînement tout en laissant passer les robots de collecte.

Au-delà du HTML brut, les agents s'appuient sur l'arbre d'accessibilité, l'association des étiquettes de formulaire, la sémantique des éléments interactifs et la stabilité de la mise en page. Un widget de réservation invisible pour l'arbre d'accessibilité est invisible pour les agents qui réservent au nom des voyageurs.

Composite de quatre sous-scores (Arbre A11y 40 / Étiquettes formulaire 25 / Sémantique interactive 20 / Stabilité de mise en page 15). Pass ≥ 80, Partiel 40–79, Échec < 40.

Les bonnes pratiques : Les CTA de réservation sont des <button> avec des attributs ARIA appropriés, chaque champ de formulaire a une étiquette, les rôles ARIA sont valides et le CLS est inférieur à 0,1.