Comment transformer un site en Knowledge Hub

La plupart des sites professionnels ont une page « blog » qui liste tous les articles dans l’ordre antéchronologique. Le lecteur qui arrive sur un article isolé n’a pas de chemin évident vers les quatre autres pièces qui s’y articulent, vers le service que cet article soutient, ni vers la question à laquelle la pièce suivante de la séquence répondra. Le site a du contenu mais pas d’architecture, et au bout de cinquante articles, l’archive paraît moins cohérente plutôt que plus, parce que chaque nouvelle pièce ajoute de l’entropie à une structure qui n’a jamais été porteuse.

Un Knowledge Hub résout un autre problème. C’est une architecture de l’information dans laquelle articles, pages thématiques et pages services sont organisés autour d’un petit nombre de piliers que le cabinet revendique crédiblement, et où chaque pièce est reliée à une structure qui permet à un lecteur sérieux (ou à un moteur de recherche) de remonter de l’argument le plus large jusqu’au conseil le plus précis, et inversement. Le hub n’est pas une refonte du gabarit de blog ; c’est une refonte de la manière dont le site décide où vont les choses et de ce qui pointe vers quoi.

Cet article prend la suite des articles sur la marque et le contenu. Le système de marque maintient la position cohérente sur toutes les surfaces ; l’article sur la stratégie de contenu décide de ce qu’il faut publier ; cet article-ci traite de la couche structurelle qui transforme les pièces publiées en un corpus que l’acheteur peut réellement parcourir.

La plus petite architecture de l’information qui soutienne un Knowledge Hub a trois couches, ni quatre, ni sept. Les topics sont les deux à quatre piliers que le cabinet possède publiquement (par exemple « communication digitale et systèmes de marque », « stratégie IA et automatisation », « architecture web et plateformes »). Les clusters sont les sous-zones d’un topic dans lesquelles le cabinet a assez à dire pour publier plus d’une pièce (par exemple, à l’intérieur de « communication digitale et systèmes de marque », les clusters peuvent être « branding », « content », « visibility », « systems »). Les articles sont les feuilles, chacun rattaché à un seul cluster.

Cette structure fonctionne parce qu’elle est assez petite pour tenir dans la tête d’un lecteur, et assez explicite pour que chaque nouvelle pièce ait une place évidente. Le mode d’échec, c’est de multiplier les taxonomies (catégories, étiquettes, thèmes, focus, piliers, sous-piliers, services, sous-services) jusqu’à ce que personne dans l’équipe ne se rappelle quel axe compte. Un lecteur qui arrive sur un article doit voir, en deux clics, le cluster auquel il appartient, le topic au-dessus de ce cluster, et le service que ce topic soutient. Si ce chemin n’est pas clair, la structure n’est pas un hub.

Le type de page le plus sous-construit sur les petits sites d’experts, c’est la page pilier. C’est la page qui répond, en 800 à 1 500 mots, à la question « que pense ce cabinet de X », qui pointe vers chaque article et chaque service pertinents, et qui est elle-même pointée par chaque article appartenant au topic. Les moteurs de recherche la lisent comme la preuve que le cabinet a une position cohérente sur X plutôt qu’une pile de billets ; les lecteurs la lisent comme un moyen d’apprendre le point de vue du cabinet sur un topic sans avoir à reconstituer ce point de vue à partir de vingt pièces dans le bon ordre.

Une page pilier utile fait trois choses. Elle énonce une position avec laquelle l’acheteur peut être en désaccord, pas une revue des « cinq tendances de X ». Elle pointe vers les quatre à huit articles qui développent cette position, avec un libellé d’ancre qui nomme ce que chaque article soutient réellement. Et elle pointe vers le service que le topic soutient, en mots clairs, pour que l’acheteur qui finit la page ait un chemin vers le travail plutôt qu’un nouveau lien vers un article suivant. Pages piliers et articles qui pointent en retour vers elles forment le triangle structurel sur lequel s’appuient à la fois les moteurs et les lecteurs.

Un hub tient ou tombe sur la couche de maillage interne. Deux schémas font presque tout le travail en pratique. D’abord, chaque article pointe en aval vers la page service qu’il soutient, et latéralement vers un ou deux articles voisins du même cluster, avec un libellé d’ancre qui nomme ce que la pièce liée soutient. Ensuite, chaque article pointe en amont vers la page pilier de son topic, et la page pilier pointe en retour. Ce triangle (article, voisin, pilier, service) est ce qui dit au moteur que l’article est l’une des quinze pièces d’une position cohérente, et au lecteur que l’étape suivante se trouve sur la page plutôt qu’à côté.

Deux pièges valent la peine d’être nommés. Trop lier (chaque article pointe vers tous les autres) écrase le signal ; la structure devient plate et le moteur ne distingue plus ce qui est central. Trop peu lier (chaque article est un essai autonome) gaspille le corpus ; le lecteur doit quitter le site pour trouver la pièce suivante. La voie médiane consiste à pointer uniquement vers les rares pièces qu’un lecteur sérieux voudrait vraiment voir ensuite, et à le faire avec un libellé d’ancre qui dit pourquoi.

La plupart des sites placent leurs services et leur contenu dans des navigations de premier rang séparées, comme si la question d’un acheteur sur un article et la décision d’achat de ce même acheteur vivaient dans deux mondes. Ce n’est pas le cas. Les meilleurs Knowledge Hubs traitent les pages services comme le nœud de conversion de chaque topic et lient l’article et le service dans les deux sens : chaque article qui soutient un service pointe vers ce service en mots clairs, et la page service pointe en retour vers deux ou trois pièces qui démontrent la position derrière le service. L’acheteur qui arrive par un article sur la visibilité qualifiée a un chemin clair vers le service qui la livre, et la page service se lit comme une position plutôt que comme une plaquette.

La même logique vaut pour les pages d’atterrissage de pilier ou d’insight. La page de cluster sur communication digitale et systèmes de marque est l’endroit juste pour faire apparaître la relation entre le topic, les articles, et les services qu’il soutient, dans une vue structurée. Le site qui fait cela bien n’a pas plus de pages que ses concurrents ; il a les mêmes pages, plus honnêtement reliées.

Une erreur courante consiste à plaquer la structure du hub sur une archive existante sans rien retirer. Le résultat, c’est un hub avec une façade nette et une longue queue faible de billets hérités qui contredisent la position que le hub cherche à établir. Les moteurs de recherche aplatissent la visibilité sur l’ensemble de l’archive, et les pièces les plus faibles tirent vers le bas le reste, même quand les lecteurs ne les voient jamais.

Construire le hub est le bon moment pour faire la consolidation. Trois actions comptent surtout : fusionner en une pièce plus forte les billets minces qui se recoupent (et rediriger les autres), retirer les pièces qui ne représentent plus la position actuelle du cabinet (avec des redirections vers l’article le plus proche qui la représente), et rafraîchir le petit ensemble de pièces héritées qui apportent encore du trafic qualifié mais ont été écrites dans une autre voix. L’audit prend quelques jours ; le gain de visibilité qui s’ensuit, conjugué à la discipline éditoriale que le hub impose désormais, dépasse souvent trois mois de publication neuve.

La décision honnête devant la plupart des cabinets est de savoir s’il faut refondre l’architecture de l’information et y migrer le contenu existant, ou conserver l’architecture actuelle en acceptant que le hub ne s’appliquera qu’aux pièces neuves. La première option est plus coûteuse à court terme et plus utile sur la durée ; la seconde est moins chère maintenant et bornée dans ce qu’elle peut produire. Les sites de moins de cinquante articles trouvent en général que la refonte se rembourse en un an. Les sites à plusieurs centaines de pièces héritées font parfois mieux avec un hybride : un hub propre pour les topics actifs, une « archive » assumée pour le reste, et un plan de redirections clair pour les pièces qui doivent migrer.

Quel que soit le chemin choisi, la décision d’architecture doit être prise avant que le design et les gabarits ne soient touchés. Concevoir un hub sur une architecture non résolue produit en général un beau site qui organise toujours le contenu par date.

Un site devient un Knowledge Hub quand l’architecture de l’information (topics, clusters, articles, pages piliers, pages services) est petite, explicite et porteuse, et quand le maillage interne transforme les pièces publiées en structure plutôt qu’en liste. Le travail est surtout une suite de décisions : quels piliers le cabinet possède, quels clusters vivent sous chacun, où se logent les pages services, ce qu’on retire ou fusionne, et quels liens portent le poids. La couche visuelle est le vernis, pas le système.

Ce travail structurel, c’est précisément le terrain de mon accompagnement SEO technique et performance web et de mon accompagnement développement applicatif et plateforme web, en lien étroit avec la couche éditoriale. Si la question est passée de « il faut publier plus souvent » à « le site doit se lire comme un corpus, pas comme un fil », c’est cette conversation qu’il vaut la peine d’ouvrir.