# Antipatterns 2020 : coder en dur un template part avant que le sol soit stable

> Certains projets ont adopté trop tôt les gabarits en blocs et se retrouvent avec des fichiers qui se cassent à chaque mise à jour du plugin Gutenberg.

- Auteur : WordPress Développement
- Publié le : 2020-10-10
- Mis à jour le : 2020-10-10
- Catégorie : Éditeur de site (FSE)
- URL : https://www.wpmoderne.fr/fse/antipatterns-2020-template-part-code-dur/

## L’essentiel

- Ne pas figer un identifiant de bloc encore instable
- Séparer clairement le code de production du code d'expérimentation
- Documenter chaque dépendance à une version précise du plugin

Un fichier `header.html` qui fonctionnait parfaitement la semaine dernière et qui affiche soudain un bloc vide après une mise à jour de routine du plugin Gutenberg : ce scénario s'est répété sur plusieurs projets qui ont voulu prendre de l'avance sur les gabarits en blocs avant que quoi que ce soit ne soit stabilisé côté cœur de WordPress.

Ce constat n'est pas une critique de la direction prise par le projet Gutenberg, qui assume pleinement son statut expérimental à ce stade. C'est plutôt un avertissement adressé aux équipes qui ont confondu « disponible dans une version de développement » avec « prêt pour la production ». Voici les antipatterns les plus fréquents observés sur ce type de chantier prématuré, et ce qu'il aurait fallu faire à la place.

## Antipattern n°1 : livrer un site client sur une branche instable

Le cas le plus radical consiste à livrer un site en production directement construit sur la version de développement du plugin, sans thème classique de secours. Dès qu'une mise à jour renomme un attribut de bloc ou modifie la structure attendue d'un fichier de gabarit, le site casse sans avertissement, et le client découvre le problème avant l'agence elle-même.

**Pourquoi c'est un problème :** à ce stade, aucune garantie de compatibilité ascendante n'est donnée par le projet. Chaque version peut légitimement modifier la syntaxe interne des gabarits.

**Ce qu'il faut faire à la place :** réserver ces expérimentations à des environnements de test isolés, jamais exposés à un vrai visiteur.

## Antipattern n°2 : copier des exemples trouvés dans des tickets non fusionnés

Plusieurs équipes ont récupéré des extraits de syntaxe de blocs directement depuis des discussions ouvertes sur le dépôt du projet, sans vérifier si la proposition avait été acceptée ou abandonnée. Le résultat : des attributs qui n'existent tout simplement pas dans la version installée.

- Toujours vérifier qu'une syntaxe provient d'une version fusionnée, pas d'une proposition en discussion.
- Tester chaque extrait sur l'installation réelle avant de le considérer comme acquis.
- Garder une note de la version exacte du plugin sur laquelle un exemple a été validé.

> L'essentiel à retenir : Ne pas figer un identifiant de bloc encore instable ; Séparer clairement le code de production du code d'expérimentation ; Documenter chaque dépendance à une version précise du plugin

## Antipattern n°3 : ne garder aucune trace de la version testée

Sur un projet observé, personne n'avait noté la version précise du plugin Gutenberg utilisée lors de la création des premiers fichiers de gabarits. Six semaines plus tard, impossible de savoir si un dysfonctionnement venait d'une régression du plugin ou d'une erreur de configuration locale.

```
# Un simple fichier de suivi, versionné avec le thème
2020-09-02 — Gutenberg 8.9 — header.html fonctionnel
2020-09-18 — Gutenberg 9.1 — footer.html : le bloc de navigation change d'attribut
2020-10-05 — Gutenberg 9.2 — reprise complète du fichier index.html
```

Un journal aussi simple que celui-ci, tenu à jour dans le dépôt du thème, aurait permis de gagner un temps précieux au moment du diagnostic.

## Antipattern n°4 : mélanger gabarits expérimentaux et thème de production

Le dernier cas concerne des équipes qui ont ajouté un dossier de gabarits expérimentaux directement dans le thème principal utilisé en production, sans branche ni séparation claire. Résultat : une mise à jour anodine du thème pour corriger un bug sans rapport a réactivé, par erreur, la totalité de l'éditeur de gabarits expérimental sur le site client.

### La bonne pratique associée

- Isoler tout code expérimental dans un thème enfant ou une branche dédiée, jamais fusionnée sans revue explicite.
- Activer les fonctionnalités expérimentales via une constante clairement identifiable, facile à désactiver d'un coup.

## Ce que ces quatre cas ont en commun

Dans chacun de ces projets, le problème de fond n'était pas la fonctionnalité elle-même, encore jeune et légitimement mouvante, mais l'absence de frontière claire entre exploration technique et engagement client. Une expérimentation mal isolée finit toujours par se comporter comme une dette technique, avec un taux d'intérêt qui grimpe à chaque nouvelle version du plugin.

> Explorer une fonctionnalité expérimentale est sain ; l'exposer à un client sans filet ne l'est jamais, quelle que soit la promesse annoncée par le projet.

## En résumé

Les quatre antipatterns présentés ici ne relèvent pas d'un manque de compétence technique, mais d'un manque de discipline dans la gestion du risque. Sur des gabarits encore mouvants, la meilleure protection reste l'isolement strict entre ce qui sert à apprendre et ce qui sert réellement le client, en attendant qu'une base stable justifie enfin de lever cette frontière.