Rendre le headless invisible pour les éditeurs.
Un plugin WordPress interne que j’ai construit progressivement pour simplifier la prévisualisation, le déploiement et le quotidien des éditeurs qui travaillent sur des sites headless.
Défi
L’architecture headless améliore les performances du frontend, mais crée des frictions pour les éditeurs autour de la prévisualisation, du déploiement et de la publication au quotidien.
Solution
Partir du plus petit déclencheur de déploiement utile, puis l’étendre par itérations en un outil WordPress interne plus large, couvrant la prévisualisation, les environnements et l’administration des sites headless.
Résultat
Les éditeurs travaillent sur un site headless dans une expérience WordPress familière, tandis que la complexité technique de la prévisualisation et du déploiement reste en dessous.
Contexte
L’architecture headless apporte beaucoup aux sites modernes, en particulier pour les performances et l’architecture du frontend.
Mais elle pose aussi un problème aux éditeurs.
Le frontend ne se trouve plus directement dans WordPress.
Un site de production statique, un environnement de prévisualisation et le back-office WordPress peuvent donc devenir des expériences séparées.
Le but de ce plugin interne était de supprimer cette friction.
Les éditeurs devaient pouvoir travailler depuis WordPress sans avoir à comprendre les branches, les déploiements, les URL de prévisualisation ou l’architecture headless sous-jacente.
Le problème de départ
La première version était très simple.
J’avais besoin de déclencher un déploiement de production depuis WordPress.
Grâce à l’API Vercel, le plugin pouvait déclencher la branche principale et déployer le site de production statique.
À ce stade, la prévisualisation était encore gérée à part, via la configuration de WordPress.
Cette première implémentation est devenue la base de ce qui allait finir par être un outil de workflow interne bien plus large.
Évolution
Le plugin a évolué progressivement, au fil de projets réels.
Plutôt que de tout concevoir à l’avance, j’ai ajouté des fonctionnalités chaque fois que je rencontrais une friction récurrente dans le workflow.
L’outil de déploiement initial est peu à peu devenu une interface plus large pour prévisualiser, déployer et gérer des sites headless depuis WordPress.
Prévisualisation
L’une des plus grosses améliorations a été de changer le fonctionnement de la prévisualisation.
Plutôt que d’envoyer les éditeurs vers une URL de prévisualisation séparée, je voulais que l’expérience reste dans WordPress.
L’action de prévisualisation standard de WordPress a été remplacée par une interface qui affiche l’aperçu directement par-dessus le back-office.
L’expérience est bien plus familière pour les éditeurs, tout en gardant l’architecture headless en dessous.
L’interface de prévisualisation peut proposer des actions comme :
- recharger l’aperçu
- vider les caches
- redimensionner l’aperçu pour vérifier le responsive
- suivre l’état du déploiement en cours
Déploiement
Le plugin peut déclencher des déploiements via l’API Vercel.
L’interface donne aussi un retour sur le déroulement du déploiement.
Elle peut afficher :
- l’état du déploiement
- la fin du build
- des notifications internes
- le temps écoulé
- l’état de Vercel
Le but est de rendre le déploiement compréhensible sans exposer le workflow technique sous-jacent.
Environnements
Pendant le développement, le workflow passe en général par plusieurs environnements :
- le back-office WordPress
- la prévisualisation
- la production
Le plugin aide à réduire les frictions entre ces environnements.
Il intègre aussi un workflow de recherche-remplacement pour les URL.
Quand un projet passe en production, on peut renseigner l’URL de production et nettoyer la base de données en conséquence.
Cela évite de corriger à la main les URL de prévisualisation enregistrées pendant le développement.
Administration WordPress
À mesure que l’architecture headless a évolué, le back-office WordPress est devenu volontairement plus restreint.
Certaines zones standard de WordPress n’étaient plus adaptées au workflow éditorial.
Le plugin ajoute donc des fonctionnalités directement dans l’interface sur mesure.
Par exemple, les éditeurs peuvent créer des pages modèles directement depuis le plugin.
L’objectif est de garder le back-office WordPress centré sur le vrai travail éditorial.
Direction design
L’interface s’inspire en partie de l’expérience éditoriale de Sanity.
Plutôt que de traiter la prévisualisation comme une page à part, je voulais que l’éditeur reste dans le back-office et interagisse avec le frontend à travers une couche visuelle intégrée.
L’interface devait donc ressembler à un outil intégré à WordPress plutôt qu’à une application externe.
Choix techniques
API Vercel
Utiliser l’API Vercel pour déclencher les déploiements depuis l’environnement WordPress.
Architecture de prévisualisation
Garder la prévisualisation reliée au frontend headless, tout en l’affichant directement dans le back-office WordPress.
Développement progressif
Le plugin n’a pas été conçu dès le départ comme un système complet.
Il a évolué fonctionnalité par fonctionnalité, au fil des nouveaux besoins et des problèmes de workflow rencontrés sur les projets.
Démarche
- 1
Repérer les frictions
Quand un problème récurrent apparaissait dans le workflow headless, je cherchais un moyen de le supprimer plutôt que de le régler à la main à chaque fois.
- 2
Construire la plus petite solution utile
La fonctionnalité de déploiement initiale était volontairement simple.
- 3
Itérer
À mesure que le workflow évoluait, de nouvelles fonctionnalités se sont ajoutées autour de la prévisualisation, des déploiements, des environnements, de la gestion des URL et des actions éditoriales.
- 4
Tout réunir
Le résultat est devenu une interface interne unique, qui cache aux éditeurs une grande partie de la complexité technique.
Résultats
Ce qui a commencé comme un simple déclencheur de déploiement est progressivement devenu un outil de workflow interne plus large.
Les éditeurs peuvent travailler sur un site headless sans avoir à comprendre l’architecture technique sous-jacente.
La complexité reste en dessous.
L’expérience éditoriale reste familière.
Conclusion
Le but n’a jamais été de cacher complètement la technique.
Il s’agissait de retirer la part de technique à laquelle les éditeurs ne devraient jamais avoir à penser.
Le headless me donne plus de contrôle sur le frontend.
Le plugin veille à ce que ce contrôle ne se fasse pas au détriment de l’expérience éditoriale.
