Le site d’un groupe hôtelier comptait douze gabarits distincts : accueil, page établissement, page restaurant, page offres, archives d’actualités, et ainsi de suite. Chacun devait afficher le même menu principal de navigation. La question d’architecture posée dès le départ était simple à formuler mais structurante pour la suite : fallait-il insérer douze fois un bloc Navigation configuré à l’identique, ou existait-il un mécanisme de partage réel ?
La réponse tient dans la nature même du bloc core/navigation depuis son intégration au cœur de WordPress : il ne stocke pas sa configuration dans le contenu du gabarit où il est inséré, mais dans une entité dédiée, un article du type de contenu wp_navigation, référencé par son identifiant depuis chaque template.
Comment fonctionne réellement cette entité partagée
Quand on insère un bloc Navigation dans un gabarit puis qu’on le configure — ajout de liens, sous-menus, réglages visuels — WordPress enregistre cette configuration dans un article caché de type wp_navigation, consultable en interne via l’API REST sous /wp/v2/navigation. Le bloc placé dans le gabarit ne contient, lui, qu’une référence à cet identifiant via l’attribut ref.
Conséquence directe : si l’on insère le même bloc Navigation, en choisissant la même entité existante plutôt que d’en créer une nouvelle, dans les douze gabarits du site, une seule modification suffit à propager le changement partout instantanément, sans repasser gabarit par gabarit.
La mise en œuvre concrète sur ce projet
Sur le premier gabarit configuré, celui de la page d’accueil, la navigation a été construite entièrement : lien vers chaque établissement, sous-menu déroulant pour les offres, lien externe vers la page de réservation. Sur les onze gabarits suivants, plutôt que de reconstruire ce menu, l’option « Choisir une navigation existante » a été sélectionnée dans l’inspecteur du bloc, pointant vers l’entité déjà créée.
Le piège rencontré : une suppression accidentelle aux conséquences larges
Quelques semaines après la mise en ligne, un membre de l’équipe éditoriale a supprimé ce qu’il pensait être un menu obsolète depuis l’écran de gestion des navigations, sans réaliser qu’il s’agissait de l’entité partagée par les douze gabarits actifs. Résultat immédiat : plus aucun menu ne s’affichait sur l’ensemble du site, une panne large pour une action qui semblait pourtant anodine.
- Documenter clairement, dans un espace visible par toute l’équipe éditoriale, la liste des navigations actives et leur usage réel.
- Renommer chaque entité de navigation avec un intitulé explicite, plutôt que de laisser le nom générique par défaut proposé par WordPress.
- Restreindre, si possible, l’accès à l’écran de gestion des navigations aux seuls profils techniques du projet.
Ce que cette architecture ne permet pas facilement
Partager une même instance signifie aussi qu’il devient impossible d’afficher une variante légèrement différente du menu sur un seul gabarit sans casser le partage pour les onze autres. Sur ce projet, la page d’un établissement fermé temporairement aurait mérité un lien supplémentaire vers une page d’information, ce qui a nécessité de dupliquer volontairement l’entité pour ce seul cas particulier, en acceptant la divergence de maintenance que cela implique.
Partager une entité de navigation est une force tant qu’on documente clairement où elle est utilisée. Sans cette documentation, c’est une bombe à retardement pour toute équipe éditoriale nombreuse.
Notre verdict
Cette architecture centralisée a fait gagner un temps considérable sur la maintenance du menu principal, avec une seule vraie contrainte : documenter et protéger l’entité partagée aussi sérieusement qu’on protégerait un fichier de configuration critique du serveur. Une leçon simple, mais qui mérite d’être répétée sur chaque nouveau projet à gabarits multiples.
Depuis cet incident, nous ajoutons systématiquement une restriction de rôle sur l’écran de gestion des navigations pour tout nouveau projet reposant sur cette architecture partagée, réservant la suppression d’une entité de navigation aux seuls comptes administrateurs techniques, plutôt qu’à l’ensemble de l’équipe éditoriale du client.
