Après deux ans d’usage de l’éditeur de site sur des projets d’agence, une question revient souvent en interne comme chez mes clients partenaires : comment organiser le travail entre développeur et intégrateur quand tout le monde touche potentiellement au même éditeur ? Sans workflow clair, on se retrouve vite avec des conflits de versions, des modifications écrasées, ou un thème dont personne ne sait plus s’il faut le modifier en code ou depuis l’interface.
Voici l’organisation que j’ai fini par stabiliser sur mes projets, testée sur plusieurs cycles de production avec des équipes mêlant développeurs et intégrateurs non-développeurs. Elle repose sur une idée simple : séparer clairement ce qui relève du code versionné de ce qui relève du contenu géré depuis l’éditeur.
Répartir le travail entre développeur et intégrateur
Le développeur possède le thème de blocs : la structure du theme.json, les templates de base, les template parts principales (en-tête, pied de page), et l’enregistrement des patterns via register_block_pattern(). Ce périmètre reste en code, versionné, testé, revu en pull request comme n’importe quel développement PHP classique.
L’intégrateur ou le client, lui, travaille exclusivement dans l’éditeur de site une fois le thème livré : assemblage des pages à partir des patterns disponibles, ajustements de styles via le panneau Styles (dans les limites autorisées par le theme.json), gestion du contenu. Cette frontière évite le principal écueil du FSE en équipe : deux personnes qui modifient la même chose par deux canaux différents, code d’un côté, interface de l’autre, sans savoir laquelle des deux versions fera foi.
Versionner un thème de blocs avec Git
Le thème de blocs se versionne comme n’importe quel projet PHP : un dépôt Git, des branches de fonctionnalité, des pull requests revues avant fusion sur la branche principale. Les templates HTML générés par WordPress (fichiers .html dans templates/ et parts/) sont du texte, donc parfaitement diffable, ce qui permet de suivre précisément qui a modifié quoi dans la structure du thème.
mon-theme/
├── theme.json
├── style.css
├── functions.php
├── templates/
│ ├── index.html
│ ├── single.html
│ └── page.html
├── parts/
│ ├── header.html
│ └── footer.html
├── patterns/
│ ├── hero-accueil.php
│ └── cta-newsletter.php
└── styles/
└── contraste.json
Le point de vigilance : dès que le client personnalise un template depuis l’éditeur de site, WordPress enregistre cette version modifiée en base de données, indépendamment du fichier du thème. Le code source et la production divergent alors silencieusement. Pour éviter cet écueil, je fixe une règle claire avec chaque client : les templates structurels (en-tête, pied de page, gabarits d’archive) restent gérés en code, seuls le contenu des pages et les patterns restent librement modifiables depuis l’éditeur.
Export du thème depuis l’éditeur ou code source
WordPress permet d’exporter directement un thème modifié depuis l’éditeur de site (Outils → Exporter), ce qui génère une archive contenant les templates tels qu’enregistrés en base. C’est pratique pour récupérer rapidement des ajustements faits en urgence par un client pressé, mais ce n’est pas un mode de développement à part entière : aucune revue de code n’est possible, aucun historique de modification n’est conservé, et le fichier exporté peut contenir des réglages orphelins accumulés au fil des essais du client.
Ma règle sur ce point : l’export depuis l’éditeur sert uniquement de filet de sécurité ponctuel, jamais de méthode de travail. Tout développement structurant repose sur le code source versionné dans Git, et les exports occasionnels sont examinés puis réintégrés manuellement dans le dépôt, jamais copiés tels quels.
La recette avant mise en production
Même avec un éditeur de site aujourd’hui stable, je maintiens une étape de recette systématique avant chaque mise en ligne, sur un environnement de préproduction fidèle à la production. Cette étape vérifie trois choses : la cohérence visuelle sur l’ensemble des pages types (via le Style Book pour un premier passage rapide), le comportement des template parts verrouillées face aux modifications du client, et l’absence de divergence entre les templates du dépôt Git et ceux enregistrés en base sur l’environnement de recette.
Voici les quatre étapes de ce cycle complet, du développement à la mise en production :
- Développement : le développeur construit le thème de blocs en local, theme.json, templates, patterns, versionné dans Git.
- Intégration : l’intégrateur ou le client assemble les pages depuis l’éditeur de site sur l’environnement de recette, avec les patterns fournis.
- Recette : contrôle visuel via le Style Book, vérification des verrouillages de template part, comparaison code et base de données.
- Mise en production : déploiement du thème via Git, migration du contenu validé, dernière vérification en conditions réelles.
Mon conseil maison : formalisez cette répartition des rôles par écrit dès le brief de projet, avant même le premier sprint de développement. La majorité des frictions que j’ai vues venir d’un flou initial sur qui a le droit de toucher à quoi dans l’éditeur, pas d’un problème technique.
En résumé
Un workflow agence solide autour de l’éditeur de site repose moins sur des outils que sur une frontière claire entre code versionné et contenu géré depuis l’interface. Le développeur possède la structure, l’intégrateur assemble le contenu, et une recette systématique avant mise en production absorbe les divergences qui apparaissent malgré tout entre les deux mondes.
Ce n’est pas un workflow figé : il s’ajuste selon la taille de l’équipe et la complexité du projet. Mais les quatre étapes qui le structurent, développement, intégration, recette, mise en production, restent le socle sur lequel je construis tous mes projets FSE depuis plusieurs mois maintenant, avec des résultats nettement plus prévisibles qu’au début du FSE.
