Douze. C’est le nombre de gabarits de page « établissement » retrouvés dans le thème bloc d’une chaîne hôtelière lors d’une reprise de projet. Douze fichiers HTML de template quasiment identiques, chacun copié-collé pour un hôtel différent, avec pour seule variation le nom de la ville et parfois l’ordre des blocs.
Ce genre de situation ne naît jamais d’un choix délibéré. Elle se construit progressivement, gabarit après gabarit, chaque fois qu’un nouvel établissement ouvre et qu’il est plus rapide de dupliquer l’existant que de comprendre pourquoi une Query Loop paramétrée n’a pas été mise en place dès le départ.
Ce qu’on observe sur le terrain
Le motif se répète presque toujours de la même façon : un premier gabarit « hôtel-paris.html » est créé proprement, avec ses blocs Groupe, ses images et son texte de présentation en dur. Puis, pour le deuxième établissement, quelqu’un duplique ce fichier, change les textes, et l’enregistre sous « hotel-lyon.html ». La méthode se répète, encore et encore, jusqu’à ce que la chaîne compte une dizaine d’hôtels et autant de gabarits à synchroniser manuellement au moindre changement de charte graphique.
- Un ajustement du bloc d’appel à l’action doit être répété douze fois, avec un risque d’oubli à chaque itération.
- Le contenu spécifique (adresse, horaires, équipements) est saisi en dur dans le gabarit plutôt que rattaché à une fiche de contenu.
- Aucun des douze gabarits ne peut être mis à jour depuis l’écran de gestion des templates sans tout reprendre un par un.
Pourquoi c’est un problème réel
Le coût ne se voit pas tout de suite. Sur un ou deux établissements, la duplication reste gérable. Le problème surgit lorsqu’un treizième hôtel ouvre et qu’il faut retrouver, dans la pile de gabarits, celui qui sert de référence la plus à jour, souvent au prix d’une comparaison fastidieuse entre plusieurs versions divergentes.
Pire encore : chaque gabarit dupliqué a vécu sa propre vie depuis sa création. L’un a reçu une correction d’accessibilité que les onze autres n’ont jamais eue. Un autre a un bloc Image mal configuré depuis des mois, invisible tant que personne ne va vérifier cette page précise. La dette technique se disperse et devient invisible depuis la liste des gabarits, qui semble pourtant complète et fonctionnelle.
Ce qu’une Query Loop paramétrée aurait permis
Avec un type de contenu personnalisé « établissement » et une Query Loop filtrée sur ce type, un seul gabarit de page suffit. Le contenu propre à chaque hôtel (nom, ville, adresse, équipements) vit dans les champs de la fiche, tandis que la mise en page reste unique et centralisée.
register_post_type( 'etablissement', array(
'public' => true,
'show_in_rest' => true,
'supports' => array( 'title', 'editor', 'custom-fields' ),
'has_archive' => true,
'template' => array(
array( 'core/query', array(
'query' => array(
'postType' => 'etablissement',
'perPage' => 1,
),
) ),
),
) );Un seul modèle single-etablissement.html suffit alors pour tous les hôtels de la chaîne. La Query Loop, combinée à un bloc Titre du contenu et un bloc Contenu du contenu placés dans le gabarit d’archive, affiche automatiquement les informations propres à chaque fiche, sans jamais dupliquer la structure visuelle.
Comment sortir du piège une fois qu’il est installé
Reconstruire depuis les douze gabarits existants demande une méthode : choisir le plus complet comme référence, migrer son contenu texte vers des champs personnalisés exposés dans le gabarit (les block bindings prévus avec WordPress 6.5 permettront bientôt de les lier directement aux blocs), puis supprimer les onze autres un par un après vérification. L’opération prend du temps, mais elle transforme douze points de défaillance en un seul gabarit à surveiller.
Un gabarit dupliqué n’est jamais un problème le jour où on le crée. Il devient un problème le jour où il faut le corriger pour la treizième fois.
Ce qu’on retient
La duplication de gabarits par établissement, par ville ou par agence part toujours d’une bonne intention : aller vite. Mais elle transforme un projet en une collection de variantes non synchronisées, où chaque correction doit être répétée manuellement. Une Query Loop paramétrée sur un type de contenu dédié coûte plus cher à mettre en place au démarrage, mais elle évite justement cette dérive dès le deuxième établissement, pas seulement au douzième.
