Quand un graphe de données structurées vaut-il mieux que dix blocs ?

Une même page peut décrire ses données structurées de deux manières radicalement différentes : en empilant plusieurs blocs indépendants, chacun décrivant un objet, ou en produisant un ensemble unique de nœuds reliés entre eux par des identifiants. Les deux sont valides, les deux passent les outils de test, et pourtant elles ne disent pas la même chose. Choisir entre un graphe de données structurées et des blocs séparés n'est pas une question de style mais de ce que l'on veut faire comprendre au moteur : une page qui déclare dix objets sans relation entre eux laisse celui ci deviner ce qui va avec quoi, là où un graphe l'énonce. Sur un site de quelques pages, la différence reste faible et le débat théorique ; sur un site qui décrit des entités récurrentes, auteurs, marques, lieux, produits, elle devient structurante et se voit dans ce que le moteur associe à quoi.

Ce que change réellement l'imbrication

La distinction se comprend mieux en regardant ce que le moteur reçoit dans chaque cas, plutôt qu'en comparant deux syntaxes. C'est un point de fond que nous abordons régulièrement dans la rubrique référencement naturel quand un site doit décrire autre chose que des articles.

Des objets isolés contre des entités identifiées

Un bloc autonome décrit un objet complet, avec toutes ses propriétés imbriquées les unes dans les autres : l'article contient son auteur, qui contient sa description, qui contient son image. Rien n'indique que cet auteur est la même personne que celui d'une autre page, ni que l'organisation citée ici est l'éditeur du site. Un graphe fait l'inverse : chaque entité reçoit un identifiant stable, elle n'est décrite qu'une fois, et tout ce qui a besoin d'elle la désigne par cet identifiant. La page cesse d'être une fiche autonome pour devenir un extrait d'un ensemble cohérent, ce qui correspond exactement à la manière dont un moteur construit sa représentation du monde.

La redondance supprimée

Avec des blocs séparés, la description de l'organisation, du site et de l'auteur se répète dans chaque objet qui en a besoin. Sur une page qui déclare un article, un fil d'Ariane, une page web et une organisation, la même adresse et le même nom peuvent apparaître quatre fois. Le graphe supprime cette répétition, ce qui allège la page de quelques kilooctets et, surtout, supprime le risque d'incohérence : quatre copies d'une même information finissent toujours par diverger, l'une étant mise à jour et pas les autres. Sur un site de plusieurs milliers de pages, cette économie devient mesurable, et la cohérence garantie compte davantage encore.

L'entité principale de la page

Le graphe permet de dire explicitement de quoi la page parle, en désignant l'un de ses nœuds comme sujet principal. C'est une information que la juxtaposition de blocs ne transporte pas : une page qui déclare un produit, une organisation et un fil d'Ariane ne dit nulle part que c'est du produit qu'il s'agit. Le moteur le devine correctement dans la plupart des cas, et se trompe précisément dans les cas ambigus, ceux où l'on aurait justement eu besoin d'être compris. Cette désignation coûte une propriété et lève une ambiguïté réelle.

Ce que les deux formes ne changent pas

Sur l'éligibilité aux affichages enrichis, la différence est nulle. Un balisage produit correct et complet donne le même résultat sous les deux formes, et il serait malhonnête de laisser croire qu'un graphe fait mieux ranker. Ce qu'il apporte se situe ailleurs, dans la compréhension des relations entre entités et dans la maintenance du site, deux bénéfices réels mais indirects qu'il faut présenter comme tels plutôt que de promettre un gain de position que rien ne viendrait étayer.

La lisibilité, argument des blocs séparés

Il faut reconnaître au format en blocs un avantage sérieux : il se lit. Un développeur qui ouvre le code source d'une page comprend immédiatement un bloc de quinze lignes décrivant un produit, alors qu'un graphe de quarante nœuds reliés par des identifiants demande un effort. Sur une équipe où plusieurs personnes interviennent sans être spécialistes du sujet, cette lisibilité a une valeur pratique réelle qui compense une bonne partie de ce que le graphe apporte, et il serait de mauvaise foi de la balayer.

Le format n'impose rien

Il faut souligner que le choix n'est ni prescrit ni recommandé par les moteurs. La documentation officielle décrit les propriétés attendues pour chaque type de résultat enrichi et reste muette sur l'organisation générale du document, ce qui laisse les deux formes parfaitement légitimes. Les affirmations péremptoires que l'on croise sur le sujet, dans un sens comme dans l'autre, ne s'appuient sur aucune source vérifiable. La seule contrainte réelle vient de la spécification du format lui même, qui prévoit explicitement la notion d'ensemble de nœuds et celle d'identifiant : ce sont des mécanismes standards, pas une invention d'éditeur. Savoir cela évite deux erreurs symétriques, celle de croire qu'un graphe est obligatoire et celle de le considérer comme exotique.

Comment un graphe se construit

La mécanique est simple une fois posée, et elle repose entièrement sur la manière de nommer les entités. C'est le point que nous détaillons pour l'implémentation la plus répandue dans notre article sur la façon de comprendre et étendre le graphe JSON-LD de Yoast.

Un tableau de nœuds plutôt qu'un objet

Le document ne contient plus un objet unique mais un tableau, dont chaque entrée décrit une entité avec son type et ses propriétés. L'ordre n'a aucune importance, et le nombre de nœuds varie selon le gabarit. Cette structure est prévue par la spécification du format et parfaitement comprise par les moteurs, qui la traitent comme un ensemble de faits plutôt que comme une hiérarchie. Elle permet aussi d'ajouter un nœud sans toucher aux autres, ce qui est précisément ce qui rend le dispositif extensible sans réécriture.

Les identifiants, ciment de l'ensemble

Chaque nœud porte un identifiant, construit par convention à partir de l'adresse de la page suivie d'un fragment court désignant son rôle. Cet identifiant n'a pas besoin de correspondre à une adresse réellement accessible, il sert uniquement de nom unique. La convention retenue doit être stricte et appliquée partout : deux nœuds portant le même identifiant sur des pages différentes sont considérés comme la même entité, ce qui est souhaitable pour l'organisation et catastrophique pour un article. C'est l'erreur la plus fréquente quand un graphe est écrit à la main, et elle ne produit aucun message d'alerte : le balisage reste valide, il décrit simplement autre chose que ce qu'on croyait.

Les entités partagées entre pages

Certaines entités doivent porter un identifiant identique sur toutes les pages : l'organisation qui édite le site, le site lui même, les auteurs récurrents. C'est ce partage qui produit l'essentiel du bénéfice, puisqu'il permet au moteur de relier plusieurs centaines de pages à une même entité. La convention consiste alors à construire ces identifiants à partir de l'adresse de la page de référence de l'entité, page d'accueil pour le site, page d'auteur pour un auteur, plutôt qu'à partir de la page courante, ce qui garantit leur stabilité quel que soit l'endroit où le nœud est produit.

Les références plutôt que les copies

À l'intérieur du graphe, une propriété qui désigne une autre entité ne la redécrit pas : elle donne son identifiant. Un article désigne ainsi son auteur, son image et la page dont il fait partie par trois références de deux mots chacune. Cette discipline est ce qui distingue un vrai graphe d'un ensemble de blocs simplement rangés dans un tableau, forme intermédiaire que l'on rencontre très souvent, qui coûte la lisibilité des blocs séparés et n'apporte aucun des bénéfices du graphe.

Le nœud de page, souvent oublié

Un graphe complet décrit aussi la page elle même comme une entité, distincte de ce qu'elle contient. Cette distinction paraît byzantine et rend pourtant possibles plusieurs choses utiles : rattacher le fil d'Ariane à la page et non au contenu, dater la page indépendamment de l'article, et désigner l'entité principale. Sans elle, le graphe décrit un contenu qui flotte sans support, ce qui fonctionne mais laisse de côté une partie de ce que le format permet d'exprimer, notamment tout ce qui distingue le document de son sujet.

Générer plutôt qu'écrire

Un graphe s'écrit très mal à la main, et c'est probablement la raison pour laquelle il effraie. La bonne approche consiste à ne jamais produire le document directement mais à construire une structure de données en mémoire, un nœud après l'autre, puis à la sérialiser en une seule opération à la fin. Chaque partie du site ajoute le ou les nœuds qui la concernent, une fonction pour le site, une pour la page, une pour le contenu, une pour le fil d'Ariane, et l'assemblage final n'a plus qu'à vérifier qu'aucun identifiant n'apparaît deux fois avant de produire le document. Cette organisation rend l'ajout d'un nouveau type trivial et supprime la principale source d'erreurs, à savoir la production de texte par concaténation.

Choisir selon le site

La question ne se tranche pas dans l'absolu. Trois critères suffisent à décider, et ils portent sur le site réel plutôt que sur les mérites théoriques de chaque forme.

Le nombre d'entités récurrentes

Un site qui ne décrit qu'une organisation et des articles anonymes n'a presque rien à gagner au graphe. Un site qui fait intervenir des auteurs identifiés, des marques, des lieux, des personnes citées ou des produits reliés entre eux en tire un bénéfice immédiat, parce que ces entités reviennent et méritent d'être reconnues comme les mêmes d'une page à l'autre. Le décompte se fait en quelques minutes : au delà de trois ou quatre entités récurrentes réellement identifiables, le graphe s'impose de lui même.

Le volume de pages

Sur dix pages, la redondance ne coûte rien et la lisibilité prime. Sur quinze cents pages, la répétition d'une même description devient un poids réel et un risque d'incohérence certain, d'autant que ces descriptions sont générées et qu'une modification doit se propager partout. Le seuil se situe quelque part au delà de quelques centaines de pages, mais c'est moins le nombre brut que la régularité de la production qui compte : un site qui publie chaque jour a tout intérêt à ce que ses entités soient définies à un seul endroit et propagées automatiquement.

Ce que produit déjà l'outillage

Le critère le plus concret est souvent le plus simple : si le système de gestion de contenu ou l'extension de référencement produit déjà un graphe, la question est tranchée, et il vaut infiniment mieux s'y raccorder par les filtres prévus que de poser un second dispositif à côté du premier. Inversement, sur un site sur mesure où tout est à écrire, le choix reste ouvert et doit être arrêté avant d'écrire la première ligne, un changement ultérieur imposant de reprendre l'ensemble des gabarits.

Le cas des sites à plusieurs marques

Une situation tranche nettement en faveur du graphe : un groupe qui exploite plusieurs enseignes sur un même domaine, ou un site qui parle d'organisations tierces. La juxtaposition de blocs indépendants y produit une confusion permanente sur l'identité de l'éditeur, alors que le graphe permet de distinguer clairement l'organisation qui publie, celle dont on parle et celle qui vend. C'est le seul cas où la forme choisie change réellement ce que le moteur comprend, et il justifie à lui seul l'effort de mise en place.

Vérifier et maintenir

Quelle que soit la forme retenue, le balisage se dégrade silencieusement, et la vérification demande une méthode plutôt qu'un coup d'œil. Elle rejoint les contrôles décrits dans notre article sur les données structurées d'une fiche produit e-commerce.

Compter les blocs avant tout

Le premier contrôle, valable dans les deux cas, consiste à compter les blocs de données structurées présents dans le code source servi par le serveur. Il ne doit y en avoir qu'un. Deux blocs signifient deux sources concurrentes, en général le thème et l'extension de référencement, situation qui produit des déclarations contradictoires et que l'on rencontre sur une majorité de sites. Ce contrôle prend dix secondes et devrait précéder toute réflexion sur la forme du balisage, puisqu'un doublon rend la question de la structure parfaitement secondaire.

Valider la résolution des références

Sur un graphe, la vérification propre consiste à s'assurer que chaque identifiant référencé correspond bien à un nœud présent, et qu'aucun nœud n'est orphelin. Un script d'une vingtaine de lignes fait ce travail en quelques secondes, là où les outils de test se contentent de valider la syntaxe et laissent passer une référence vers un identifiant inexistant. C'est le contrôle spécifique au format, et il attrape la quasi totalité des erreurs introduites par une extension écrite trop vite ou par une modification faite sans comprendre la convention.

Confronter au contenu affiché

La règle qui prime sur toutes les autres reste que le balisage doit décrire ce que la page affiche réellement. Un prix, une note, une date ou un auteur déclarés dans le balisage et absents de la page constituent un manquement, sanctionnable par une pénalité manuelle. Cette vérification ne s'automatise pas facilement et doit être faite à la main sur un échantillon, ce qui est un excellent argument pour limiter le balisage à ce que la page dit vraiment plutôt que de chercher à cocher toutes les propriétés possibles.

Documenter la convention

Le dernier travail est d'écrire, en une page, la convention d'identifiants retenue, la liste des nœuds produits par gabarit, et l'endroit du code où chacun est généré. Sans ce document, le premier intervenant extérieur ajoutera un bloc indépendant à côté du graphe, parce que c'est plus simple que de comprendre la convention existante, et le site se retrouvera avec les deux formes en même temps. C'est exactement la situation que ce choix cherchait à éviter, et elle se produit systématiquement en l'absence de note écrite.

Le coût de bascule d'une forme à l'autre

Passer de blocs séparés à un graphe n'est pas une opération anodine, et il vaut mieux le savoir avant de s'engager. Techniquement, l'opération se limite à réécrire la couche qui produit le balisage, ce qui représente une journée sur un site sur mesure. Ce qui coûte, c'est la vérification : chaque gabarit doit être contrôlé, chaque type de contenu revalidé, et les rapports de résultats enrichis mettent plusieurs semaines à refléter le nouvel état, période pendant laquelle il est difficile de savoir si tout va bien. La prudence commande donc de basculer en une fois plutôt que progressivement, les deux formes ne devant jamais cohabiter sur un même site, et de conserver l'ancien balisage sous forme de copie pour pouvoir revenir en arrière si un type de résultat enrichi disparaissait sans explication.