Le schéma n'est pas un levier de citation, c'est une infrastructure d'entité

Votre balisage JSON-LD ne vous fera pas davantage citer par une intelligence artificielle. C'est ce qu'a mesuré une étude d'Ahrefs publiée en mai 2026 : près de 1 900 pages ayant ajouté des données structurées, suivies sur trois interfaces (AI Overviews, AI Mode et ChatGPT). L'ajout de schema n'y a produit aucune hausse de citations qui sorte du bruit statistique. Le résultat a vite circulé sous une forme raccourcie : « le schema ne sert plus à rien pour l'IA. »

Cette lecture est fausse, l'étude elle-même ne va pas si loin. Ce qu'elle teste est précis et étroit : ajouter du JSON-LD à des pages déjà abondamment citées ne fait pas grimper leurs citations à court terme. C'est utile à savoir et cela invalide la promesse, répétée depuis deux ans, d'un balisage qui serait un levier de visibilité qu'on actionne à volonté.

Mais entre « le schema n'amplifie pas des pages déjà visibles » et « le schema ne sert à rien », il y a un raccourci. On reproche au balisage de ne pas faire une chose pour laquelle il n'a jamais été conçu.

Le schema n'est pas un levier de citation : c'est une infrastructure d'entité. Gianluca Fiorelli en donne la comparaison la plus juste : l'immatriculation d'une entreprise. On ne s'enregistre pas auprès des autorités pour un pic de ventes immédiat, mais pour exister comme entité reconnaissable dans les systèmes qui, ensuite, décideront de vous mettre en avant. Le retour ne se lit pas sur trente jours.

Reste à savoir où ce travail se fait vraiment. Le balisage agit à trois moments distincts de la vie d'une page, et l'étude n'en a mesuré qu'un : celui où il pèse le moins.

Résumé exécutif

• L'étude Ahrefs (près de 1 900 pages, trois interfaces) n'a mesuré aucune hausse de citations après ajout de JSON-LD. Elle invalide la promesse du balisage comme levier de visibilité, pas le balisage lui-même.
• Le schema agit à trois moments : à l'indexation, où il désambiguïse votre entité dans le Knowledge Graph ; au pré-entraînement, où il a alimenté pendant des années la mémoire des modèles ; et presque pas au moment de la réponse, la seule couche que l'étude a regardée.
• Ce qui fait citer une page se joue à la récupération : des passages explicites, auto-portants, ancrés sur leurs entités. Le comportement de citation est en aval de la compétitivité au retrieval (Andrea Volpini).
• Traitez le JSON-LD comme une infrastructure d'identité : une entité déclarée une fois (@id stable, sameAs), des relations cohérentes, une confirmation de ce que la page dit déjà. Pas comme une étiquette qui réclame des citations.
• Exception : le commerce. Pour vendre à un agent, la donnée structurée redevient le canal obligatoire (Product, offers, GTIN) ; pour être cité dans une réponse éditoriale, c'est le langage qui décide.

Sommaire

1. L'erreur de catégorie
2. Les trois contextes du schema
3. Ce qui fait vraiment citer une page
4. Que faire, concrètement, de votre JSON-LD
5. Le cas du commerce : quand le balisage redevient nécessaire
6. Le vrai levier n'est pas une couche de plus

L'erreur de catégorie

Un modèle de langage lit du texte, pas du balisage. Il n'analyse pas vos balises <script type="application/ld+json"> : il lit une suite de tokens. Le JSON-LD, quand il lui parvient, n'est qu'une suite de caractères parmi d'autres, pas une couche privilégiée qu'il saurait distinguer du reste.

C'est ce qu'a observé l'expérience reprise par Ahrefs : au moment où un assistant récupère une page pour répondre, il extrait le HTML visible et laisse de côté le JSON-LD, le Microdata et le RDFa. Les cinq systèmes testés se comportent ainsi. Votre balisage ne « parle » donc pas au modèle qui rédige la réponse.

De là à conclure que le schema ne sert à rien, il y a un glissement, une erreur de catégorie. « L'IA a ignoré mon JSON-LD en lisant cette page » ne signifie pas « le JSON-LD n'a aucun effet sur la façon dont l'IA comprend cette entité ». Le premier énoncé décrit un instant précis : celui où le modèle va chercher une page en direct. Le second prétend décrire tout le cycle.

Or le balisage n'a jamais travaillé à cet instant-là. La récupération d'une page pour répondre est l'étape finale d'un parcours qui en compte plusieurs, et le schema agit bien plus tôt. Mesurer son effet au moment de la réponse, c'est l'attendre là où il n'a rien à faire. Pour voir ce qu'il fait vraiment, il faut séparer les moments.

Les trois contextes du schema

Gianluca Fiorelli, prolongeant un cadre de Suganthan Mohanadasan, distingue trois moments où le balisage intervient ou reste inerte. Les nommer fait disparaître la contradiction apparente entre « le schema est une infrastructure d'entité » et « l'étude n'a rien mesuré ».

Contexte 1 : l'indexation, là où le schema travaille le plus

C'est à l'indexation que le balisage compte le plus. Googlebot extrait le JSON-LD et s'en sert pour identifier l'entité dont parle la page (quelle entreprise, quelle personne), suivre ses liens sameAs, et créer ou mettre à jour sa fiche dans le Knowledge Graph. Un balisage Organization ou Person, avec ses sameAs vers Wikidata, LinkedIn ou le site officiel, fait ce que la prose seule ne peut pas. Il déclare, en termes que la machine résout sans ambiguïté, qui est l'auteur d'une affirmation.

Ce travail ne reste pas confiné aux Knowledge Panels. Quand Google génère une AI Overview, il ne se contente pas de récupérer des pages : il s'appuie sur le Knowledge Graph pour identifier et vérifier les entités d'une requête. Une marque qui n'est pas clairement établie comme entité (signaux cohérents sur son site, données structurées, sources tierces qui corroborent) risque d'être absente non seulement des SERP classiques, mais aussi des réponses IA.

L'enjeu n'a fait que monter. En juin 2025, lors de ce que Jason Barnard a nommé le Great Clarity Cleanup, Google a retiré plus de 3 milliards d'entités de son Knowledge Graph en une semaine. Une contraction de 6,26 %, destinée à obtenir un socle plus propre pour ses fonctionnalités IA. La leçon : la popularité ne suffit plus. La clarté et la cohérence de votre entité décident.

Une précision honnête s'impose. Google répète qu'aucun balisage spécial n'est requis pour apparaître dans ses fonctionnalités IA, et que l'éligibilité y passe par l'indexation et par les extraits de la recherche classique. Le schema n'est donc pas un bouton qu'on actionne « pour l'IA ». Il fait son travail d'entité en amont, à l'indexation, et c'est précisément ce qui le rend invisible à une étude qui mesure l'effet au moment de la réponse.

Contexte 2 : le pré-entraînement, l'effet composé invisible

À l'entraînement, le schema agit indirectement, et sur des années. Le code JSON-LD lui-même ne survit pas au nettoyage des corpus : les pipelines qui préparent les données d'entraînement isolent le texte visible et écartent le balisage. Mais pendant plus d'une décennie, les données structurées ont alimenté les knowledge graphs publics, dont ceux de Google et de Wikidata. Les fiches d'entité et knowledge panels qui en résultent sont massivement représentés dans les corpus, donc absorbés dans la mémoire du modèle.

Conséquence : ce qu'un modèle « sait » de votre marque quand il répond sans aller chercher sur le web (visibilité paramétrique) dépend de la force de votre entité dans ces données. Une force que le schema a contribué à construire, fiche après fiche. L'effet est réel, composé, et par nature invisible à toute mesure de court terme.

Contexte 3 : le moment de la réponse, là où le schema pèse le moins

C'est la couche que l'étude a mesurée, et celle où le balisage fait le moins. Quand un assistant récupère votre page en direct pour rédiger sa réponse, il lit le HTML visible et laisse le JSON-LD de côté. Le balisage est traité comme du texte, pas comme une structure interprétée. Le résultat nul n'a donc rien d'étonnant : l'étude a observé le seul des trois contextes où le schema n'a jamais eu de prise.

Vu ainsi, ce résultat se lit autrement. L'étude n'a pas montré que le schema ne sert à rien ; elle a montré qu'il n'amplifie pas les citations de pages déjà bien citées, et seulement au contexte 3.

Un second biais le confirme : elle a regroupé des balisages qui ne font pas le même métier. Un balisage Article décrit un contenu ; un balisage Organization déclare une identité. Mesurer l'effet « citation » d'un balisage d'identité sur trente jours, c'est se tromper d'instrument. Autant se demander si le numéro de TVA d'une entreprise pousse ses clients à faire davantage confiance à ses avis.

Ce qui fait vraiment citer une page

Si ce n'est pas le schema, alors quoi ? La citation commence par la récupération. J'ai décrit le parcours complet d'une réponse d'IA, de l'analyse de l'intention à la synthèse finale, dans L'AI Search, deux mécanismes ; c'est sa première moitié qui décide ici.

Pour qu'une page soit citée, un de ses passages doit d'abord entrer dans l'ensemble des candidats que le système rassemble, puis y être compétitif. Le goulet est là, en amont de la réponse. Andrea Volpini le résume d'une formule : le comportement de citation est en aval de la compétitivité au retrieval.

Cela déplace la question de l'écriture. Un passage cité est explicite, se suffit à lui-même, et reste ancré sur ses entités. Concrètement :

• réintroduire le nom de l'entité plutôt que de laisser un « cette approche » flotter en début de phrase ;
• préférer le déclaratif aux questions rhétoriques ;
• appuyer ses affirmations sur des éléments vérifiables : chiffres, dates, standards nommés.

Cette exigence rejoint ce que Kevin Indig a observé à grande échelle : les passages cités viennent surtout du début de page, et sont denses en entités, factuels.

Le constat est d'autant plus net qu'il vient d'un promoteur de longue date des données structurées. Volpini ne décrit pas de nouveaux leviers « GEO » : il décrit l'extension du bon SEO, rendue simplement plus détectable par les machines. La clarté sémantique, l'auto-portance, l'ancrage sur l'entité, la vérifiabilité ne sont pas des astuces, ce sont les qualités d'un contenu utile, désormais lisibles dans l'espace vectoriel.

C'est là que le débat se déplace pour de bon : du balisage qu'on ajoute autour des mots, vers les mots eux-mêmes.

Pour aller plus loin : pourquoi l'essentiel doit passer en tête

Deux mécanismes éclairent l'intuition « mettez l'important d'abord ».

Le premier tient à la façon dont les embeddings encodent le sens. Les modèles récents, dont ceux d'OpenAI, sont entraînés pour concentrer l'information la plus importante dans les premières dimensions du vecteur. On peut ramener un embedding de 3 072 dimensions à 256 sans perdre le concept central. Volpini en tire une image, le paragraphe Matryoshka : commencez par la réponse, déclarez votre entité dès la première phrase.

Ce n'est pas que le modèle tronque vos paragraphes, c'est qu'un système qui balaye vite capte d'abord ce qui est en tête, et qu'une thèse enfouie au quatrième paragraphe dilue son signal.

Le second tient à une asymétrie de l'espace vectoriel de Google, que Volpini décode : un texte n'y est pas représenté de la même façon selon qu'il joue le rôle de document ou de requête. Un contenu qui recopie la formulation exacte de la question se range du côté « requête » plutôt que « document faisant autorité », et perd en compétitivité. Le geste qui suit : cessez de paraphraser la question, écrivez en déclaratif.

Que faire, concrètement, de votre JSON-LD

Le principe directeur tient en une phrase : cessez de traiter le schema comme une étiquette qui réclame des citations, traitez-le comme la surface d'un graphe d'entité. Le contenu visible, votre HTML, porte ce que l'IA lit et cite. Le JSON-LD, lui, déclare une autre chose : qui vous êtes, à quelles entités vous vous reliez, et comment. Gianluca Fiorelli résume la division du travail : le HTML pour être lu, le JSON-LD pour être calculé.

Déclarez votre entité une seule fois, proprement, et reliez-la au reste du web. Un identifiant stable, le pattern @id, donne à votre organisation ou à votre personne une adresse unique que la machine peut suivre d'une page à l'autre. Les liens sameAs vers Wikidata, LinkedIn ou votre site officiel font le reste : ils disent à Google de quelle entité vous parlez, sans ambiguïté. C'est le geste qui sert le premier contexte du schema, la désambiguïsation.

Exprimez de vraies relations plutôt qu'une collection de balises éparses. Un graphe imbriqué, avec les propriétés about et mention (sous-utilisées), relie votre contenu aux entités qu'il traite et qu'il cite. La valeur n'est pas dans le nombre de types déclarés, mais dans la cohérence du graphe que vous dessinez.

Faites confirmer par le balisage ce que le contenu dit déjà, sans chercher à le remplacer. Le schema, selon la formule de Pedro Dias, apporte une confirmation, pas une révélation : il ne fait pas comprendre à la machine un sens absent du texte. Un balisage qui contredit la page, ou qui déclare ce qu'elle ne montre pas, n'aide personne.

N'optimisez pas non plus pour des rich results qui peuvent disparaître. Google a déprécié l'affichage enrichi des FAQ en mai 2026, celui des HowTo plus tôt. Les marques qui avaient déployé ces balises pour le seul gain visuel l'ont perdu du jour au lendemain, et ont conclu un peu vite que « le schema est mort ». Implémentez pour l'entité, pas pour le pixel. L'entité, elle, ne se déprécie pas.

Reste à savoir pour qui cet effort compte le plus. Pour une entité pas encore établie dans le Knowledge Graph (une marque jeune, un auteur peu référencé), le schema accélère réellement la reconnaissance : il aide Google à vous inscrire comme une entité distincte. Pour une page déjà performante d'une marque déjà reconnue, n'attendez pas du balisage un surcroît de citations : le travail d'entité est largement fait.

À quoi cela ressemble en pratique ? Sur ce blog, je déclare un Person une seule fois, via un @id stable, relié à Wikidata et à mes profils par sameAs, et consolidé par rel="me". Les balises d'article ne redéclarent jamais cette personne : elles y font référence par son identifiant.

Rien de plus. C'est exactement ce que veut dire « traiter le schema comme une infrastructure d'entité » : un socle d'identité posé une fois, que tout le reste vient pointer.

Pour les organisations qui vont plus loin, Duane Forrester propose un cadre utile : le JSON-LD comme couche de faits machine plutôt que comme rich-snippet. Les attributs, les états de disponibilité et la provenance y sont tirés de la source de vérité. C'est un horizon d'implémentation, pas un minimum. Et il pointe vers un terrain où le balisage change carrément de statut : le commerce.

Le cas du commerce : quand le balisage redevient nécessaire

La règle vaut pour le contenu éditorial. Côté produit, elle s'inverse. Quand un agent compare des références, vérifie un prix ou une disponibilité, il ne lit pas une prose qu'il faudrait interpréter. Il a besoin de données fiables, normalisées : c'est précisément ce que portent les balises produit.

Ici, le JSON-LD n'est plus un signal d'entité parmi d'autres. Il devient le canal par lequel l'information circule : Product, offers, identifiants GTIN, flux marchands. Un prix faux ou absent dans ces données, et l'agent répond faux, ou ne vous retient pas.

Cette asymétrie explique une apparente contradiction. Les mêmes experts qui appellent à la prudence sur le balisage éditorial restent des défenseurs convaincus des données structurées côté commerce. Andrea Volpini est de ceux-là.

Ce n'est pas une incohérence : c'est une question de domaine. La donnée structurée ne sert pas à se faire citer dans une réponse de fond ; elle sert à être correctement représentée dans une transaction.

Le commerce agentique a sa propre logique, ses protocoles de panier et de paiement, ses exigences de flux. J'y consacre un article dédié. Retenez la frontière : pour vendre un produit à un agent, structurez vos données ; pour être cité dans une réponse éditoriale, travaillez votre langage. Et pour l'immense majorité des pages, qui sont éditoriales, c'est cette seconde voie qui décide.

Le vrai levier n'est pas une couche de plus

Si le langage décide au moment de la récupération, le prolongement logique n'est pas d'ajouter encore du balisage. C'est d'écrire un langage que la machine peut exploiter sans surcouche. Ramon Eijkemans formule ce déplacement de cadre : le successeur des données structurées n'est pas plus de données structurées, c'est le langage structuré.

L'idée est simple et exigeante. Une phrase qui nomme ses entités, énonce leurs relations et préserve ses conditions est déjà lisible par un graphe de connaissances, qui y lit des triples. Elle l'est aussi par un système qui découpe le sens en affirmations atomiques, sans qu'aucune balise n'intervienne.

La structure dont la machine a besoin ne s'ajoute pas par-dessus le texte, elle est dans le texte. D'où la formule d'Eijkemans : ajouter de la structure au langage, pas l'inverse.

Cela ne veut pas dire appauvrir. Écrire « pour les LLM » en simplifiant à l'excès échoue presque aussi mal qu'inventer : un contenu dense, spécifique, qui préserve ses nuances l'emporte sur la prose marketing vague comme sur la donnée nue. La langue exploitable par la machine n'est pas une langue dégradée. C'est une langue précise.

Le plus intéressant est que cette précision sert d'abord le lecteur humain. La phrase qui se suffit à elle-même, celle qu'on peut coller dans un document vide et qui reste compréhensible, est exactement l'unité que retient le lecteur pressé. C'est aussi celle que la machine extrait pour la citer.

Les deux lecteurs convergent. C'est pourquoi le bon ordre reste celui que ce blog défend depuis le début : on écrit pour l'humain d'abord, et la machine suit.

Le langage structuré mérite son propre traitement, et j'y reviendrai. Mais l'essentiel, pour conclure sur le schema, tient là : l'effort que vous ne mettez pas dans une balise de plus, mettez-le dans une phrase qui n'en a pas besoin.

Conclure : le schema n'est pas mort, vous lui demandiez la mauvaise chose

Le schema n'est pas mort. Il fait un travail réel, simplement pas celui qu'on lui prêtait. L'étude qui a déclenché ce débat reste précieuse, justement parce qu'elle a tué une promesse fausse : non, ajouter du JSON-LD à une page déjà citée ne lui vaudra pas plus de citations à court terme. Mais entre cette mesure étroite et le verdict « le schema ne sert plus à rien », il y avait un raccourci que les trois contextes du balisage suffisent à défaire.

Le schema agit à l'indexation, où il désambiguïse votre entité. Il agit au pré-entraînement, où il a alimenté pendant des années la mémoire des modèles. Il ne fait presque rien au moment de la réponse, et c'est cette seule couche que l'étude a regardée.

La posture qui en découle n'a rien d'exceptionnel. Vous implémentez le schéma proprement pour ce qu'il fait vraiment : déclarer une entité reconnaissable et reliée au reste du web. Vous n'en attendez pas de citations. Et vous mettez l'effort là où il décide : la clarté de votre langage, l'auto-portance de vos passages, la solidité de votre entité.

Reprenez l'image de l'immatriculation. On ne s'immatricule pas pour vendre demain, mais parce qu'aucune des choses qu'on veut faire ensuite n'est possible sans exister, d'abord, comme une entité que les systèmes savent nommer.