Le client, une petite maison d’édition indépendante, voulait un site « moderne et facile à modifier lui-même ». L’équipe a proposé, pour la première fois, un chantier entièrement construit sur l’éditeur de site du plugin Gutenberg, alors que WordPress 5.9 n’était même pas encore sorti. Un pari risqué, assumé collectivement, dont voici le bilan sans filtre.
Ce choix reposait sur une conviction : mieux valait affronter les difficultés maintenant, sur un projet au périmètre raisonnable, plutôt que de découvrir les mêmes pièges plus tard sur un chantier plus critique. Le résultat a confirmé cette intuition, au prix de plusieurs semaines de retard.
Premier blocage : l’instabilité entre deux versions du plugin
À mi-parcours du chantier, une mise à jour du plugin Gutenberg a modifié le comportement de verrouillage des template parts, rendant modifiable un en-tête que nous avions pourtant figé pour le client. Ce changement silencieux, non documenté dans le changelog de manière explicite, a nécessité une journée complète de vérification de l’ensemble des gabarits du site.
Nous avons depuis pris l’habitude de figer la version du plugin utilisée pendant toute la durée d’un chantier, quitte à retarder volontairement une mise à jour prometteuse, pour éviter ce genre de surprise en pleine phase de recette client.
Deuxième blocage : la formation du client à un outil encore jeune
La maison d’édition souhaitait pouvoir modifier elle-même la page d’accueil pour mettre en avant ses nouveautés. L’interface de l’éditeur de site, encore peu intuitive à ce stade de son développement, a demandé une session de formation bien plus longue que prévu, le client confondant régulièrement modification d’un template global et modification d’une simple page.
Nous avons fini par verrouiller plus strictement certaines zones sensibles via l’attribut templateLock, en ne laissant modifiable que le contenu réellement destiné à changer souvent. Cette décision, prise en cours de projet plutôt qu’anticipée dès le départ, aurait mérité d’être posée bien plus tôt dans le cahier des charges.
Troisième blocage : des extensions tierces pas prêtes
Un plugin de formulaire de contact, largement utilisé et a priori fiable, affichait un rendu cassé une fois inséré dans un gabarit de l’éditeur de site, à cause d’un conflit de styles avec les feuilles de style générées automatiquement par le thème expérimental. Il a fallu une correction CSS ciblée, documentée dans un plugin maison, pour rétablir un affichage correct.
- Vérifier systématiquement la compatibilité annoncée d’une extension avec les thèmes blocs avant de l’intégrer à un chantier de ce type.
- Prévoir un budget de correction CSS spécifique, même pour des extensions réputées stables sur les thèmes classiques.
- Tester chaque extension sur un environnement isolé avant de l’ajouter à l’environnement de recette partagé avec le client.
Ce qui, à l’inverse, a dépassé nos attentes
La rapidité de mise en page a été un vrai bon point : composer une nouvelle page d’atterrissage pour une opération commerciale ponctuelle a pris moins de deux heures, contre une demi-journée habituelle avec un thème classique nécessitant l’intervention d’un développeur pour le moindre ajustement de structure.
Un chantier pionnier coûte toujours plus cher en temps qu’un chantier standard. La vraie question n’est pas d’éviter ce coût, mais de décider consciemment de le payer maintenant plutôt que plus tard, sur un projet plus exigeant.
En résumé
Ce premier site entièrement construit sur l’éditeur de site a coûté trois semaines de retard supplémentaires par rapport au planning initial, mais il a livré une autonomie éditoriale réelle au client et une expérience précieuse à l’équipe technique. Nous ne referions pas ce choix sur n’importe quel projet, mais nous ne le regrettons pas sur celui-ci.
La prochaine étape consistera à consolider les leçons tirées ici dans une checklist interne, pour ne plus reproduire les mêmes erreurs sur les chantiers similaires qui suivront inévitablement.
