Sur un projet récent, le délai ne permettait pas le déroulé habituel. On a donc changé l’ordre des étapes, avec Claude Code en appui. Voici ce qu’on a gagné, et ce que ça demande.
Le déroulé habituel
Sur un site WordPress, les étapes s’enchaînent dans cet ordre :
- briefs, spécifications fonctionnelles, maquettes et validations ;
- développement ;
- validation des gabarits, un par un ;
- traitement des retours ;
- ouverture du staging à la cheffe de projet, qui commence la saisie ;
- ajustement des gabarits, compositions et blocs pour faciliter la saisie ;
- accès au staging pour le client : recette et saisie ;
- mise en ligne.
C’est sûr, mais tout est séquentiel. La saisie, souvent l’étape la plus longue, ne commence qu’une fois le développement terminé. Et c’est seulement là qu’on découvre ce qui gêne vraiment à la saisie.
Ce qu’on a fait à la place
Le projet : deux sites en multisite, un délai serré. On a lancé la saisie avant la fin du développement :
- validation des maquettes, specs et briefs ;
- développement, avec des contenus factices réalistes dès le départ ;
- ouverture du staging à la cheffe de projet ;
- traitement des retours en même temps que la saisie, et donc que le développement ;
- livraison du staging au client.
Du premier commit à la livraison du staging, il s’est passé un peu plus d’un mois, pour environ 200 commits.
Ce que ça impose
Le staging devient la référence
Dès que la saisie commence sur le staging, c’est lui qui fait foi. On ne pousse plus jamais une base locale par-dessus. Le sens s’inverse : on récupère la base du staging, on travaille en local, et les changements de contenu repartent par script.
Chaque script est d’abord testé en local, sur une copie fraîche du staging. Il est ensuite lancé sur le staging, après une sauvegarde de la base, puis on vide les caches.
Des scripts pour corriger le contenu déjà saisi
Le développement continuait pendant la saisie, et le contenu déjà saisi devait suivre. Par exemple :
- un style de titre change : les titres déjà saisis sont mis à jour ;
- une section est recentrée : toutes les pages concernées le sont aussi ;
- un bloc est remplacé par une version plus simple : son contenu est converti.
On a même migré la structure technique du site en cours de route, vers notre socle commun et un nouveau système de champs, sans perdre une ligne saisie. Un script réécrivait les références internes des blocs ; il a été lancé à blanc d’abord, puis pour de vrai.
Écrire ces scripts coûtait autrefois trop cher pour en faire une méthode de travail. Avec Claude Code, ils sont produits, testés à blanc, puis vérifiés en comparant le rendu des pages avant et après. C’est ce qui rend la méthode possible.
Des compositions plutôt que des blocs en vrac
Pour que le contenu reste corrigeable, il doit rester lié au thème. Les pages sont donc construites à partir de compositions (sections types) plutôt qu’avec des blocs posés un par un.
En cours de route, on a fait l’inventaire des sections déjà saisies : plus de 200 ont été reconnues et rattachées à leur composition. Quand une mise en page revenait souvent sans composition, on en créait une : huit en une journée. Une page exemple sert de catalogue : la cheffe de projet y voit toutes les sections disponibles.
La saisie guide le développement
La cheffe de projet a saisi des contenus réels très tôt. Ses difficultés sont donc remontées pendant le développement, et pas après. Ça a donné :
- un éditeur limité aux seuls blocs que les pages utilisent ;
- un guide de saisie directement dans l’administration ;
- une fonction native de WordPress mise en forme plutôt qu’un bloc sur mesure, quand c’était plus souple pour elle ;
- ses retouches faites dans l’éditeur (pied de page, page 404) reprises dans le thème, pour qu’elles ne restent pas isolées en base.
Des décisions écrites, une recette suivie
Pendant l’intégration, on a dû trancher là où la maquette et le contenu ne disaient rien. Ces choix ont été listés dans un document à valider : ce qui a été décidé, ce qui reste à trancher, les contenus à fournir.
La recette tenait dans un simple tableur partagé. Les retours y étaient traités par petits lots, chacun dans sa propre demande de fusion (une douzaine certains jours). Les questions repartaient en commentaires dans ce même tableur.
Un staging prêt à être ouvert
Pour ouvrir le staging à d’autres personnes, il a fallu quelques réglages :
- les e-mails partent vraiment, mais seulement vers une liste d’adresses autorisées : on teste les formulaires et les comptes sans risquer d’écrire à de vrais destinataires ;
- les éditeurs peuvent créer des comptes, ce qui évite de passer par nous pour chaque accès ;
- les administrateurs de chaque site peuvent modifier la politique de confidentialité.
Toutes ces améliorations sont reportées dans notre socle commun : le projet suivant en profite.
Les limites
- De la discipline sur la base. Sauvegarde avant chaque script, copie avant chaque récupération, et jamais d’écrasement. Une erreur ferait perdre du contenu saisi.
- Claude Code n’écrit pas seul sur le staging. Il prépare et teste les scripts, mais c’est un humain qui les lance sur le serveur.
- Une cheffe de projet disponible. Le flux tendu ne marche que si les retours arrivent vite et qu’elle accepte de saisir sur un site encore en chantier.
- Les imprévus d’environnement arrivent plus tôt. Accès protégé du staging, adresses e-mail refusées, relais d’envoi bloqué : on règle en pleine saisie ce qu’on aurait découvert plus tard.
Quand le refaire
Quand le délai est serré, les maquettes sont validées et quelqu’un est disponible côté contenus. Pas quand le contenu est encore à écrire, ni quand le périmètre n’est pas stabilisé.
Au fond, on n’a pas tant accéléré le développement que supprimé une attente : celle entre « le site est prêt » et « le contenu est prêt ».
Questions fréquentes
Peut-on saisir les contenus pendant que le site est encore en développement ?
Oui, si le staging devient la base de référence : on ne l’écrase plus, et chaque évolution du site qui touche au contenu déjà saisi passe par un script testé en local puis lancé sur le staging après une sauvegarde.
Comment garder le contenu saisi à jour quand le design change ?
En construisant les pages à partir de compositions (sections types) du thème. Le contenu reste rattaché à sa composition : un script retrouve toutes les sections concernées et les met à jour.
Quel est le rôle de Claude Code dans cette méthode ?
Il écrit et teste à blanc les scripts de correction du contenu, puis compare le rendu des pages avant et après. Il ne les lance pas lui-même sur le staging : c’est un humain qui le fait.
Un projet au délai serré, ou envie de lancer la saisie plus tôt sur votre prochain site WordPress FSE sur mesure ? Écrivez-moi à contact@juzed.dev.
Stack : WordPress FSE · Multisite · WP-CLI · Claude Code · DDEV · GitLab CI/CD