Une IA a évalué notre site sans rien mesurer. Un simple script y a trouvé douze fois le même défaut.

Nous avons posé à Gemini une question simple sur notre propre site : quel est ton avis sur sa qualité technique ? La réponse était longue, structurée, plutôt élogieuse, et elle citait nos pages comme sources. Elle nous décrivait comme une entreprise de développement web toulousaine spécialisée dans le sur mesure en PHP et MySQL, ce qui est exactement notre positionnement.

Elle contenait aussi deux mots sur lesquels nous appliquons une règle. Le premier est « agence », employé deux fois pour nous désigner. Nous l'utilisons volontairement dans les titres et les descriptions de nos pages locales, parce que c'est le terme que tape un prospect toulousain et qu'un titre sert à être trouvé. Nous ne l'employons jamais dans une phrase qui décrit ce que nous sommes, parce que là il promet une équipe et des locaux qui n'existent pas. Le mot par lequel on vous trouve n'est pas la description de ce que vous êtes.

Le second est « propriétaire », dans l'expression « code propriétaire propre ». Celui-là nous l'écartons partout, parce qu'il évoque l'enfermement d'un client dans une technologie qu'il ne maîtrise pas, ce qui est exactement l'inverse de ce que nous livrons.

Nous avons donc écrit un petit script qui parcourt les quatre cent dix-sept fichiers du site et classe chaque occurrence selon son emplacement, un titre n'ayant pas le même statut qu'un paragraphe. Le résultat n'est pas celui que nous attendions.

Il a d'abord confirmé l'usage attendu, dans les titres et les métadonnées. Puis il a trouvé « agence » là où le mot n'avait rien à faire : dans les instructions de notre propre assistant conversationnel, qui se présente depuis des mois comme l'assistant d'une agence web toulousaine. Nous avions corrigé cette formulation à un endroit et pas à l'autre, sans nous en apercevoir. Quant à « propriétaire », il apparaît en en-tête de chaque fichier d'un de nos outils, sous la forme d'une mention de licence non libre, un usage juridique sans rapport avec le sens commercial du mot.

Le modèle n'a donc rien inventé sur le premier mot. Il a lu ce que nous mettons délibérément dans nos titres. Sur le second, il a extrapolé depuis une mention technique. La leçon ne parle pas d'intelligence artificielle : nous ne savions pas ce que notre propre site déclarait, et il a fallu un script pour l'apprendre.

La réponse flatteuse, et ce qu'elle vaut

Ce n'est pas un reproche adressé au modèle. C'est ce qu'il fait, et il le fait bien. À partir d'un ensemble de pages qui parlent de développement sur mesure, de refus des surcouches et de plateformes conçues pour durer, il produit un résumé cohérent en comblant les vides avec le vocabulaire le plus probable. Une entreprise de services web est appelée une agence dans la grande majorité des textes qu'il a vus, donc nous devenons une agence. Du code écrit spécifiquement pour un client est souvent qualifié de propriétaire, donc notre code le devient.

Le résultat se lit comme un constat, alors qu'il mélange sans le dire ce qui vient de nos pages, ce qui traînait dans un fichier oublié, et ce que le modèle a déduit tout seul. Rien dans la mise en forme ne les distingue, et les sources citées sous chaque affirmation renforcent l'impression que tout a été vérifié. C'est le point qui nous intéresse ici, parce que la même mécanique s'applique quand on lui demande d'évaluer un balisage.

Lire n'est pas mesurer

La réponse de Gemini s'ouvrait sur un avertissement que nous n'avions pas demandé : en tant qu'intelligence artificielle, il ne peut pas exécuter d'analyse de code en temps réel ni lancer d'outil de diagnostic technique sur le serveur. C'est exact, et c'est la phrase la plus utile de toute sa réponse. Elle décrit précisément la limite du procédé.

Vérifier un balisage de données structurées ne demande aucune intelligence. Ça demande de récupérer le code servi par la page, d'y trouver les blocs de balisage, de les analyser, puis de faire des comparaisons ennuyeuses. Cet identifiant que la page référence, existe-t-il quelque part ? Cette entreprise déclarée trois fois porte-t-elle les mêmes propriétés à chaque fois ? Ce texte annoncé dans le balisage figure-t-il dans ce que le visiteur lit ? Cette date respecte-t-elle le format attendu ? Il n'y a là que du comptage et de la comparaison de chaînes.

Un modèle de langage ne fait rien de tout ça. Il travaille sur ce qu'il a lu de vos pages, éventuellement sur ce qu'un robot en a récupéré, et il formule. Demander à un modèle si votre balisage est correct revient à demander à quelqu'un de juger un moteur en lisant la brochure. La réponse sera plausible, articulée, et sans lien avec l'état du moteur.

C'est la même distinction que celle que nous décrivions dans l'article sur notre site vu comme deux entreprises, à propos du test des résultats enrichis de Google. Ce test juge une page sur un critère précis, son éligibilité à un affichage enrichi, et reste muet sur la cohérence des entités qu'elle déclare. Chaque instrument répond à la question qu'il sait traiter, et le problème commence quand on lui en pose une autre.

Douze articles, douze fois le même défaut

Nous avons construit un analyseur de données structurées, et nous l'avons d'abord retourné contre nous. En juillet 2026, douze articles de ce magazine portaient un balisage de foire aux questions. Les douze annonçaient à Google des questions que la page ne posait pas.

Le mécanisme est celui d'un gabarit recopié d'un article au suivant. Chaque article déclarait trois paires de questions et réponses, les réponses reprenant des paragraphes du texte, mais les questions n'existaient que dans le balisage. Un lecteur arrivant sur la page ne voyait aucune question, seulement des paragraphes suivis. Le balisage affirmait donc la présence d'une rubrique qui n'existait pas, ce que les consignes de Google appellent du contenu balisé non visible.

Un script d'audit, distinct de l'outil public et volontairement plus sévère que lui, a trouvé les douze cas en une seconde : il normalise chaque question du balisage et la cherche dans le texte affiché. Aucun modèle interrogé sur nos pages ne l'aurait signalé, non par négligence mais parce que le constat exige une comparaison exacte entre deux textes, l'un caché dans du code et l'autre visible à l'écran. C'est trivial pour une machine qui compare, impossible pour une machine qui résume.

La correction a consisté à rendre les questions visibles, en réécrivant les réponses pour qu'elles se lisent comme des paragraphes plutôt que comme des notes destinées à un moteur. Précisons l'enjeu réel, parce qu'il est modeste : Google a retiré l'affichage enrichi des foires aux questions en mai 2026, donc plus personne n'en tire de bénéfice visible en recherche. La consigne de correspondance subsiste, et le balisage reste lu par Bing et par les robots des moteurs de réponse. Nous avons corrigé pour cette raison, pas pour un gain de position que nous ne pouvions pas promettre.

Ce qu'un outil qui mesure sait de ses propres limites

Notre analyseur s'est trompé deux fois pendant cette campagne, et les deux erreurs sont plus instructives que les réussites.

La première est une détection partielle, et elle concerne l'outil public. Sur le premier article corrigé, sa règle chargée de vérifier la correspondance des textes n'a signalé qu'une des trois questions manquantes, là où le script d'audit en trouvait trois. Elle mesure la proportion de mots du balisage retrouvés dans la page, avec un seuil, et les mots des deux autres questions, « donnée structurée », « comment savoir », « site », « problème », se trouvaient partout ailleurs dans un article qui traite exactement de ce sujet. Le seuil était franchi par coïncidence de vocabulaire.

C'est exactement pourquoi les deux outils existent. Le script d'audit cherche la question comme une phrase entière, ce qui ne laisse rien passer et convient sur un site que nous connaissons. Le même réglage dans l'outil public crierait au loup dès qu'un mot ou une apostrophe diffère entre le balisage et l'affichage, et un outil qui accuse à tort ne sert à personne.

La seconde est un faux positif franc. Notre page d'accueil ressortait avec un avertissement sur une adresse d'image relative, alors que cette adresse est parfaitement absolue. En regardant le code de la règle, la cause était bête : quand le logo est déclaré comme un objet plutôt que comme une simple adresse, ce qui est la pratique recommandée par Google, la règle parcourait les valeurs de cet objet et tombait sur le nom du type. Ce n'est pas une adresse, ça ne commence pas par « http », donc elle le déclarait relatif. Tous les sites correctement balisés auraient déclenché cet avertissement.

Ce faux positif ne se serait jamais montré dans nos tests, parce que nous écrivions nos cas d'essai avec des logos déclarés en chaîne simple. Il a fallu un balisage réel, écrit sans penser à notre outil, pour le révéler. Voilà ce qui sépare un instrument d'une opinion : ses erreurs sont localisables, reproductibles et corrigeables. Un modèle qui vous décrit comme une agence au code propriétaire n'annonce aucune limite, et rien dans sa réponse ne permet de séparer ce qu'il a lu de ce qu'il a supposé.

Ce que l'analyseur fait, et ce qu'il ne fait pas

L'outil est en ligne, gratuit et sans inscription. Vous collez l'adresse d'une page, il récupère le code servi au chargement et vous rend un rapport. Il compte les blocs de balisage et les entités déclarées, nomme la cause exacte d'une faute de syntaxe avec sa ligne et sa colonne, repère les entités déclarées sans identifiant et celles qui renvoient vers un identifiant introuvable, compare le texte d'un balisage de questions avec le texte affiché, et vérifie que le balisage n'est pas bloqué par la politique de sécurité de votre propre serveur, un cas courant que personne ne signale.

Ce qu'il ne fait pas mérite autant d'attention. Il ne voit que le code servi au chargement : un balisage ajouté ensuite par du JavaScript ou par un gestionnaire de balises lui échappe, alors que les moteurs de recherche exécutent le JavaScript et peuvent en voir davantage. Il n'examine qu'une page à la fois, donc un identifiant défini sur une autre page du site est signalé comme à vérifier, pas comme fautif. Il ne dit pas si vous avez balisé les bonnes choses, seulement si ce que vous avez balisé se tient. Et il ne corrige rien.

Cette dernière limite est la vraie. Reprendre le balisage d'un site entier sans toucher aux positions déjà acquises demande de savoir ce qu'on déplace, et c'est là que notre travail commence. Le constat, lui, vous appartient : l'analyseur de données structurées vous dira sur votre propre page ce qu'aucune conversation avec un modèle ne peut vous apprendre.

Un dernier point, pour éviter un contresens. Rien de tout ceci ne plaide contre les moteurs de réponse, et nous ne les bloquons pas. Nous avons même expliqué pourquoi dans notre article sur les robots d'IA : être lu et cité par ces systèmes est devenu un canal de visibilité qu'il serait absurde de refuser. Un modèle est excellent pour expliquer à quoi sert un balisage, pour vous aider à en rédiger un, pour dégrossir un sujet que vous ne connaissez pas. Il est simplement inadapté à la seule question qui compte quand le balisage est déjà en place : est-ce que le mien est juste ?

Questions fréquentes

Peut-on demander à une IA de vérifier son balisage Schema.org ?

Pour comprendre à quoi sert le balisage, oui. Pour savoir si le vôtre est correct, non. Un modèle de langage ne récupère pas votre page pour la comparer à son balisage, il lit ce qui est écrit et le reformule. La réponse sera cohérente et souvent flatteuse, sans qu'aucune vérification n'ait eu lieu.

Qu'est-ce qu'un outil de mesure voit qu'un modèle ne voit pas ?

Tout ce qui demande de comparer deux choses caractère par caractère. Un identifiant référencé qui n'est défini nulle part, une même entreprise déclarée quatre fois sous des formes différentes, une réponse balisée absente du texte affiché, une date au mauvais format. Ce sont des faits, pas des impressions, et ils se vérifient.

Faut-il encore corriger un balisage FAQ maintenant que Google a retiré l'affichage enrichi ?

Le résultat enrichi FAQ n'apparaît plus dans Google depuis mai 2026, donc l'enjeu d'affichage a disparu. La consigne de correspondance avec le texte visible reste, et le balisage continue d'être lu par Bing et par les robots des moteurs de réponse. Décrire une page qui n'existe pas reste donc à éviter, sans urgence.