Étape 3 d’un cocon sémantique : dessiner l’architecture en mindmap

L’étape 3 transforme la liste de sujets posée à l’étape 2 en architecture concrète : un pilier, des têtes de famille, des pages filles rattachées à chacune selon une logique de hiérarchie claire. Cette architecture prend la forme d’un mindmap visuel, qui montre d’un coup d’œil la structure du cocon et le maillage prévu entre ses pages, bien avant que la moindre ligne de contenu ne soit rédigée. Cette étape ne se limite pas à un exercice de mise en forme agréable à présenter au client. Elle fixe des décisions qui engagent tout le reste du projet : combien de niveaux comptera l’arbre, combien de sujets figureront à chaque niveau, et comment chaque page se reliera concrètement à ses voisines une fois publiée. Cette page complète Gestion d’un projet cocon sémantique en 9 étapes.

Du pilier aux pages filles : la hiérarchie du cocon

Un cocon sémantique s’organise en niveaux successifs. Au sommet, le pilier porte le sujet le plus général et le mot-clé le plus disputé sur le marché visé. Sous lui, des têtes de famille déclinent le sujet en sous-thèmes cohérents, chacune pouvant à son tour rattacher des pages filles plus précises qui approfondissent un aspect particulier.

Cette hiérarchie n’a rien d’arbitraire : chaque niveau descend du général vers le particulier, et chaque sujet reprend un terme de son parent pour rester lisible même hors du contexte de l’arbre. Une page fille qui ne se comprend pas seule, sans le reste de la structure, signale presque toujours un sujet mal placé dans la hiérarchie retenue. Le nombre de sujets par niveau se situe entre 2 et 9, l’idéal se tenant entre 3 et 6 selon la richesse réelle du champ sémantique concerné.

Un niveau trop chargé perd en lisibilité pour le lecteur comme pour l’équipe ; un niveau trop pauvre ne justifie tout simplement pas la branche qu’il prétend ouvrir.

Varier les angles et valider niveau par niveau

Au sein d’un même niveau, les sujets retenus varient leurs angles : qui, quoi, où, quand, comment, pourquoi. Cette variation évite que 2 sujets voisins ne répondent en réalité à la même question sous un titre légèrement différent, ce qui créerait une concurrence interne inutile entre 2 pages du même cocon sur la même intention. Chaque niveau se valide avant de dessiner le niveau suivant, jamais après.

Cette validation, portée par un humain et non laissée à la seule génération automatique, vérifie que les sujets retenus restent cohérents entre eux et avec le pilier, avant que l’équipe n’investisse du temps à détailler un niveau plus profond sur des bases encore fragiles. Sauter cette validation intermédiaire pour gagner du temps produit généralement l’effet inverse de celui recherché : un défaut découvert au niveau 3 de l’arbre oblige souvent à revoir aussi le niveau 2 qui l’a engendré, ce qui coûte finalement plus de temps que la validation qu’on avait cru pouvoir économiser.

Penser le maillage dès l’architecture

Le maillage interne reste plus lisible, pour un humain comme pour un moteur de recherche, quand il respecte la hiérarchie dessinée au même moment que l’arbre. Une mindmap qui intègre ce maillage dès l’étape 3 donne à l’équipe de production, à l’étape suivante, une feuille de route complète et déjà arbitrée : plus besoin d’improviser les liens internes pendant la rédaction, ni de les redistribuer une fois plusieurs pages déjà publiées et citées ailleurs.

Les erreurs fréquentes dans une architecture de cocon

Cette hiérarchie trop plate complique le maillage, puisqu’aucune page ne peut jouer le rôle de relais entre le pilier et ces pages filles trop nombreuses. La troisième erreur touche la variation des angles au sein d’un même niveau : 2 sujets qui semblent distincts dans leur formulation, mais qui répondent en réalité à la même question du lecteur. Cette redondance se repère en se demandant, pour chaque paire de sujets voisins, si un même lecteur chercherait réellement les 2 séparément, ou si une seule page suffirait à répondre aux 2 intentions à la fois.

Ces 3 erreurs se corrigent plus facilement sur un mindmap que sur des pages déjà rédigées, d’où l’intérêt de la validation niveau par niveau décrite plus haut. Un œil extérieur au projet, qui découvre l’arbre pour la première fois, repère souvent ces défauts plus vite qu’une équipe déjà immergée dans le sujet depuis plusieurs semaines de travail. Un dernier repère aide à juger la qualité d’une architecture avant même de la soumettre à validation : un lecteur extérieur au projet doit pouvoir deviner, en regardant seulement les titres du mindmap, de quoi traite chaque page sans avoir besoin de lire son contenu.

Si plusieurs titres se ressemblent trop ou restent trop vagues pour qu’on les distingue les uns des autres, l’architecture mérite d’être retravaillée avant de passer à l’étape suivante. Ce test simple, mené en quelques minutes avec une personne qui découvre le projet pour la première fois, repère souvent des défauts qu’une équipe plongée dans le sujet depuis plusieurs semaines ne voit plus. Ce test se répète à chaque niveau ajouté, pas seulement une fois l’arbre entièrement terminé : un niveau validé selon ce principe au moment de sa création reste rarement remis en cause plus tard, alors qu’un niveau validé trop vite demande souvent une reprise une fois l’ensemble de l’arbre visible.

Questions fréquentes

Testez vos connaissances

Stéphane Jambu LinkedIn ↗

Consultant e-commerce / visibilité / IA, fondateur de Hi-Commerce. Praticien du cocon sémantique depuis 2012, auteur de cette page dans le cadre du méta-cocon de référence Hi-Commerce sur le sujet.

Sources :

• Hi-Commerce — méthode cocon sémantique
• Hi-Commerce — formation Stéphane Jambu, Cocon sémantique