Le fil d'Ariane : balisage, données structurées et cohérence d'URL

Le fil d'Ariane paraît être un détail d'interface : une ligne de liens en haut de page, indiquant où l'on se trouve. Il joue en réalité trois rôles distincts, dont deux sont invisibles à l'écran. Il oriente le visiteur, il déclare au moteur la place de la page dans l'arborescence, et il peut remplacer l'adresse affichée dans les résultats de recherche par un chemin lisible. Ces trois fonctions supposent qu'il soit construit correctement, balisé selon le vocabulaire attendu et surtout cohérent avec la structure réelle des adresses, condition qui est loin d'être toujours remplie.

Trois rôles pour une seule ligne

Distinguer les trois fonctions du fil d'Ariane aide à comprendre pourquoi certaines implantations paraissent correctes et ne produisent rien. La première fonction est ergonomique et se juge à l'écran. Les deux autres sont techniques et se jugent dans le code et dans les résultats de recherche. Une équipe qui ne pense qu'à la première produit un fil visuellement satisfaisant et sans effet, ce qui est le cas le plus courant. La définition et les usages de cet élément sont détaillés dans notre article sur le fil d'Ariane Web et son intérêt en SEO.

Le rôle ergonomique consiste à répondre à deux questions que se pose un visiteur arrivé depuis un moteur de recherche : où suis je, et que puis je faire d'autre ici. Un visiteur atterrissant sur une fiche produit précise n'a aucune idée de la structure du catalogue, et le fil lui donne en une ligne l'accès à la catégorie et à la famille. C'est particulièrement utile sur les sites profonds, catalogues, documentations, bases de connaissances, où la page d'accueil n'est pas un point de passage. Sur un site de dix pages, l'apport est nul et l'élément peut être omis sans regret. La question à se poser est simple : existe t il des pages qu'un visiteur peut atteindre sans jamais passer par un niveau supérieur. Si la réponse est non, le fil n'apporte rien que le menu ne fasse déjà.

Le rôle structurel consiste à déclarer explicitement la position de la page dans une hiérarchie. Un moteur reconstitue cette hiérarchie à partir des liens et des adresses, avec une part d'interprétation. Le fil balisé supprime cette interprétation en énonçant le chemin. Cette déclaration prend d'autant plus de valeur que la structure des adresses est plate, cas fréquent sur les publications où toutes les pages vivent à la racine. Elle constitue alors la seule indication de hiérarchie disponible. Sur un blog dont tous les articles vivent directement sous la racine, le fil est littéralement le seul endroit où la rubrique d'appartenance est déclarée de façon exploitable. Le supprimer revient à aplatir entièrement la structure aux yeux du moteur.

Le rôle d'affichage consiste à remplacer, dans les résultats de recherche, l'adresse complète par le chemin de navigation. Ce remplacement améliore la lisibilité et il n'est jamais garanti : le moteur décide au cas par cas. Le balisage augmente la probabilité sans la certifier, ce qui doit être annoncé lorsque l'on présente le travail à un client. Promettre un affichage que l'on ne contrôle pas conduit à des discussions désagréables quelques semaines plus tard. La formulation honnête consiste à dire que le balisage rend l'affichage possible, la décision restant du côté du moteur. Ce cadrage préserve la relation et il correspond à la réalité observée.

La structure HTML attendue

La construction du fil obéit à une convention simple et régulièrement mal appliquée. L'ensemble se place dans un élément de navigation portant une étiquette accessible, et les éléments du chemin forment une liste ordonnée. Cette structure n'est pas décorative : elle permet aux technologies d'assistance d'annoncer qu'il s'agit d'un fil d'Ariane et de restituer la position dans le chemin. Une succession de liens séparés par des chevrons dans un paragraphe fonctionne visuellement et ne transmet aucune de ces informations. Le coût de la correction est nul, puisqu'il s'agit de remplacer quelques balises, et le bénéfice porte à la fois sur l'accessibilité et sur la clarté du code. C'est typiquement le genre de reprise que l'on fait en même temps qu'une autre intervention sur le gabarit.

Chaque niveau du chemin est un lien, à l'exception du dernier. La page courante ne doit pas être un lien vers elle même, convention établie qui évite un comportement déroutant et qui se marque par un attribut indiquant la page en cours. Beaucoup d'implantations lient le dernier élément par simple uniformité de traitement dans la boucle d'affichage, ce qui est un défaut mineur et facile à corriger. Le premier niveau pointe vers l'accueil, soit par son nom, soit par une icône accompagnée d'un intitulé accessible. Une icône seule, sans texte de remplacement, prive une partie des visiteurs de ce premier lien et supprime l'intitulé du balisage. Le texte peut être masqué visuellement tout en restant présent dans le document, technique éprouvée et sans inconvénient.

Le séparateur visuel entre les niveaux doit être produit par une règle de style plutôt que par un caractère inséré dans le contenu. Un chevron écrit en dur dans le balisage est lu par les technologies d'assistance, ce qui produit une restitution pénible. Le déplacer dans une pseudo classe règle la question et permet de le changer sans toucher au contenu. Ce détail revient dans presque toutes les revues d'accessibilité. Il coûte deux lignes de style et il évite qu'un lecteur d'écran n'annonce un caractère parasite entre chaque niveau du chemin.

La longueur du chemin mérite enfin une décision explicite. Un fil de six niveaux devient illisible sur mobile et il vaut mieux replier les niveaux intermédiaires derrière un élément dépliable, à condition que les liens restent présents dans le document. Masquer par une règle de style est acceptable, supprimer du balisage ne l'est pas, puisque cela retire l'information structurelle. C'est un cas où le traitement visuel et le contenu doivent être traités séparément. La règle générale s'applique ici comme ailleurs : ce qui relève de la place disponible à l'écran se règle par le style, ce qui relève de l'information se conserve dans le document. Une largeur d'écran ne devrait jamais faire disparaître une donnée structurelle.

Le balisage en données structurées

Le vocabulaire prévoit un type dédié qui décrit une liste ordonnée d'éléments, chacun portant sa position, son nom et son adresse. Ce balisage se place de préférence dans un bloc dédié en tête de page plutôt qu'en attributs répartis dans le balisage visible, format nettement plus facile à produire et à contrôler. Il doit décrire exactement ce que le fil affiche, ni plus ni moins, tout écart entre les deux relevant de la même famille d'erreurs que les balisages inventés. Le bloc dédié présente en outre l'avantage de rester lisible par un humain, ce qui facilite considérablement les contrôles rapides. Les attributs répartis dans le balisage visible fonctionnent tout aussi bien et se relisent beaucoup moins facilement.

La position se numérote à partir de un et doit être continue. Une numérotation partant de zéro ou comportant un trou invalide l'ensemble, erreur classique lorsque le tableau source est parcouru avec un index de programmation. Le dernier élément, correspondant à la page courante, doit figurer dans la liste même s'il n'est pas cliquable à l'écran. Son adresse peut être omise, la spécification l'admettant pour le dernier élément, et la renseigner ne pose aucun problème non plus. Dans le doute, la renseigner est le choix le plus sûr, puisqu'il ne produit aucun avertissement dans les outils de validation.

Les noms déclarés doivent correspondre aux intitulés affichés. Un fil affichant une version courte du titre et déclarant la version longue crée une incohérence détectable. La règle générale, ici comme partout en matière de données structurées, veut que le balisage décrive ce que le visiteur voit. Cette règle unique résout la plupart des questions que l'on se pose en cours d'implantation. Elle tranche notamment le cas des intitulés raccourcis pour tenir sur une ligne : si le raccourci est ce qui s'affiche, c'est lui qu'il faut déclarer.

La duplication des sources est le défaut le plus répandu sur les sites construits avec un système de gestion de contenu. Le thème produit un balisage, une extension de référencement en produit un second, et les deux se contredisent parfois sur les intitulés ou sur le nombre de niveaux. Le contrôle consiste à rechercher le type concerné dans le code rendu et à compter les occurrences. Le remède consiste à n'en conserver qu'une, opération triviale une fois la source identifiée. Les extensions de référencement proposent en général un réglage pour désactiver leur propre production, ce qui évite de modifier le thème. Ce contrôle mérite d'être refait après chaque changement de thème ou d'extension majeure.

La cohérence avec l'arborescence des adresses

C'est le point qui distingue un fil d'Ariane utile d'une décoration. Le chemin déclaré doit correspondre à la structure réelle du site, telle qu'elle apparaît dans les adresses et dans le maillage interne. Un fil annonçant un chemin en quatre niveaux sur un site dont toutes les adresses vivent à la racine n'est pas faux en soi, il devient faux si les catégories annoncées ne correspondent à aucune page réelle. Déclarer un niveau intermédiaire vers une page qui n'existe pas produit un lien mort dans le chemin, défaut immédiatement visible et pourtant fréquent sur les sites dont l'organisation a évolué sans reprise du fil.

Le cas le plus problématique concerne les contenus rattachés à plusieurs catégories. Un article classé dans trois rubriques peut afficher trois fils différents selon le chemin emprunté par le visiteur, ce qui donne au moteur des signaux contradictoires. La solution consiste à désigner une catégorie principale par contenu et à construire le fil sur elle, indépendamment du parcours. Cette désignation demande un champ supplémentaire et un peu de discipline éditoriale, et elle stabilise durablement la structure déclarée. Sur un site existant, la désignation rétroactive de cette catégorie principale se mène en général par famille de contenus plutôt que page par page, ce qui la rend praticable même sur plusieurs centaines d'articles.

Le fil construit sur l'historique de navigation constitue l'erreur symétrique. Afficher le chemin par lequel le visiteur est arrivé, plutôt que la position de la page, produit un fil différent à chaque visite et un balisage instable. Cette confusion entre chemin de navigation et position hiérarchique est fréquente sur les catalogues où l'on cherche à faciliter le retour vers la liste filtrée. Le besoin est légitime et il se traite par un lien de retour distinct, jamais par le fil d'Ariane. Les deux éléments peuvent parfaitement coexister sur la même page, à condition d'être visuellement distincts pour ne pas induire le visiteur en erreur.

Sur un site où les adresses reflètent l'arborescence, le fil se construit naturellement à partir du chemin de l'adresse, ce qui garantit la cohérence par construction. C'est l'un des arguments en faveur d'adresses structurées, sujet que nous développons dans notre article sur le rôle des URLs dans une stratégie de siloing. Sur un site à adresses plates, le fil doit être alimenté par les relations enregistrées entre contenus, ce qui demande que ces relations existent réellement et soient tenues à jour. C'est souvent en construisant le fil que l'on découvre que ces relations n'avaient jamais été renseignées correctement, le travail révélant alors un problème d'organisation plus profond.

Les cas particuliers à traiter

Quelques situations sortent du modèle simple et méritent une décision explicite plutôt qu'un comportement par défaut. Les traiter dès la conception évite des incohérences qui se découvrent plus tard, souvent lors d'un audit. Une demi heure de discussion au moment des maquettes économise plusieurs heures de reprise ensuite.

Les pages de résultats de recherche interne et les listes filtrées n'ont pas de position stable dans l'arborescence. Leur afficher un fil complet suggère une hiérarchie qui n'existe pas. Le plus simple consiste à ne pas en afficher, ou à se limiter au niveau de la catégorie parente sans déclarer de balisage. Ces pages n'ayant en général pas vocation à être indexées, l'enjeu porte surtout sur la cohérence de l'expérience. Afficher un fil complet sur une page de résultats donne d'ailleurs au visiteur l'impression trompeuse qu'il se trouve dans une rubrique du site.

Les contenus multilingues demandent que le fil soit traduit dans son intégralité, intitulés et adresses. Un chemin mêlant des libellés dans deux langues révèle une traduction partielle et dégrade la perception du site. Les adresses des niveaux intermédiaires doivent pointer vers les versions correspondantes, ce qui suppose que les catégories elles mêmes soient traduites. Cette vérification est rapide et régulièrement oubliée après l'ajout d'une langue. Elle consiste simplement à ouvrir une page profonde dans chaque langue et à parcourir chaque niveau du chemin.

Les pages orphelines, rattachées à aucune catégorie, posent la question de ce qu'il faut afficher. Les faire pointer vers l'accueil directement est correct et honnête. Leur inventer un rattachement pour remplir le fil crée une hiérarchie fictive que rien d'autre ne confirme. Ces pages méritent surtout d'être rattachées réellement, le fil signalant ici un défaut d'organisation plus large. Une page qu'aucune rubrique ne réclame est souvent une page dont personne ne se souvient, ce qui pose la question de son maintien.

Les sites WordPress disposent enfin de plusieurs moyens de produire cet élément, par le thème, par une extension de référencement ou par un développement dédié. Le choix se fait selon ce que le site utilise déjà, la seule règle étant de n'avoir qu'une source active. La méthode sans extension est décrite dans notre article sur la manière de créer un fil d'Ariane sans plugin dans WordPress, et elle convient bien aux thèmes sur mesure.

Contrôler et maintenir

La vérification se mène à trois niveaux, et elle prend moins de temps que la mise en place. L'outil de test des données structurées valide une adresse et signale les erreurs de position, d'intitulé ou d'adresse. L'employer sur trois pages représentatives, un contenu profond, un contenu à catégorie unique et une page de liste, couvre la plupart des cas de figure rencontrés sur un site. Y ajouter une page traduite lorsque le site est multilingue complète utilement l'échantillon.

Les rapports des outils pour webmasters donnent ensuite la vision d'ensemble, avec le nombre de pages valides et la liste des anomalies. Ces rapports se mettent à jour avec un décalage de plusieurs jours, ce qui impose d'attendre avant de conclure qu'une correction n'a pas fonctionné. Ils constituent la source de référence pour mesurer l'effet d'une intervention sur un site important. Une hausse soudaine du nombre d'erreurs signale en général une mise à jour d'extension plutôt qu'une dérive progressive.

Une exploration complète avec extraction du fil permet enfin de repérer les incohérences de masse, pages sans fil, chemins trop longs, intitulés vides. Ce contrôle révèle presque toujours une famille de contenus mal alimentée, ce qui est une bonne nouvelle : corriger la source règle d'un coup plusieurs dizaines de pages. Il se mène une fois après la mise en place, puis une fois par an. Les outils d'exploration savent extraire ce type d'élément et l'exporter dans un tableau, ce qui rend le tri par anomalie immédiat.

La maintenance repose sur un principe unique : le fil se génère depuis les mêmes relations que la navigation, jamais depuis une liste tenue à part. Dès qu'un chemin est saisi manuellement quelque part, sa divergence avec la structure réelle n'est plus qu'une question de temps. Sur un site géré par un système de gestion de contenu, cette règle est respectée par construction et le travail consiste à vérifier qu'aucune source concurrente ne s'y superpose. Sur un développement sur mesure, elle doit être posée explicitement dès la conception des gabarits.