WordPress Gutenberg
Ce que ça change vraiment dans la gestion de projet web
Crédit photo : Milad Fakurian (via Unsplash)
Un éditeur qui a redistribué les cartes
Pendant longtemps, WordPress a été synonyme de friction entre les équipes. Les développeurs livraient un thème, les clients découvraient l’interface d’édition classique, et tout le monde finissait par se battre avec des shortcodes illisibles ou des plugins constructeurs de pages qui généraient du code difficile à maintenir.
En 2018, WordPress a remplacé son éditeur historique par Gutenberg. La transition a été secouée — une partie de la communauté a protesté, des forks ont vu le jour. Mais sept ans plus tard, les effets concrets sur la gestion de projet commencent à être bien mesurables.
Ce n’est pas que Gutenberg soit parfait. C’est qu’il a résolu des problèmes qui coûtaient du temps et de l’argent à presque tous les projets WordPress.
Ce que « gestion de projet » veut dire ici
Avant d’aller plus loin, une clarification utile.
La gestion de projet web, c’est l’ensemble des décisions et des processus qui permettent de livrer un site dans les délais, dans le budget, et dans un état suffisamment solide pour durer. Ça couvre : la définition des besoins, la répartition des rôles, le cycle de développement, la recette client, la formation, et la maintenance dans le temps.
WordPress Gutenberg n’est pas un outil de gestion de projet au sens strict. Il ne remplace pas un Trello, un Notion ou un Jira. Ce qu’il fait, c’est modifier les conditions dans lesquelles le projet se déroule — en particulier la façon dont les équipes travaillent, dont les clients valident, et dont les sites évoluent après la livraison.
La séparation du contenu et de la mise en forme
Le problème central de l’ancien éditeur WordPress était simple : le contenu et la mise en forme étaient mélangés. Un rédacteur qui voulait créer une section avec deux colonnes et une image devait soit connaître le HTML, soit installer un plugin comme Visual Composer ou Elementor.
Ces plugins ont rendu service, mais ils ont aussi créé une dépendance : si le plugin disparaît, le site perd une partie de sa structure. Et leur code généré était souvent difficile à déboguer.
Gutenberg introduit une approche différente : le contenu est découpé en blocs. Chaque bloc a un type précis — paragraphe, image, titre, citation, liste, vidéo — et chaque bloc dispose de ses propres options de mise en forme. Cette architecture repose sur un format standardisé stocké en base de données sous forme de commentaires HTML enrichis.
Concrètement, ça veut dire qu’un projet peut être conçu avec une séparation claire entre ce qui relève du design (les thèmes, les styles globaux) et ce qui relève du contenu (les blocs). Cette séparation est un avantage direct pour la gestion de projet : les deux parties du travail peuvent avancer en parallèle, avec moins de risques de collision.
Crédit photo : Annie Spratt (via Unsplash)
WordPress Gutenberg : l’impact sur la collaboration entre équipes
Dans un projet web, les profils qui interviennent sont souvent variés : un chef de projet, un ou deux développeurs, un designer, parfois un rédacteur ou un consultant SEO. Historiquement, ces profils travaillaient en silo, en se passant des fichiers et en espérant que les ajustements de dernière minute resteraient gérables.
Gutenberg facilite un mode de travail plus itératif. Voici pourquoi.
- Le designer peut travailler directement dans l’éditeur. L’outil Styles global de Gutenberg (disponible via les thèmes compatibles Full Site Editing) permet de définir les typographies, les couleurs et l’espacement à un seul endroit. Le designer n’a plus à traduire ses choix graphiques en variables CSS dans un fichier à part : il peut les configurer via une interface visuelle, que le développeur vient ensuite affiner ou verrouiller.
- Le développeur peut créer des blocs sur mesure. L’API de blocs Gutenberg est construite sur React. Un développeur peut créer un bloc personnalisé pour n’importe quel besoin métier spécifique — un composant de carte produit, un bandeau d’alerte, un tableau de tarifs — et l’exposer aux rédacteurs de façon contrôlée. Le rédacteur voit un bloc propre avec des champs de saisie. Il ne touche jamais au code.
- Le rédacteur travaille dans l’environnement final. L’éditeur de blocs donne une prévisualisation très proche du rendu public. Ça réduit les surprises lors de la recette client et le nombre de retours en développement pour « ce n’est pas ce que j’avais imaginé ».
La recette client : moins de va-et-vient
La phase de recette est souvent celle qui coûte le plus en heures non budgétées. Le client voit le site pour la première fois dans son état quasi-final, identifie des problèmes, et les demandes de modification s’accumulent.
Une partie de ces allers-retours vient d’un problème de représentation : le client a du mal à se projeter à partir de maquettes statiques ou d’un site développé sur un environnement de staging peu accessible.
Gutenberg atténue ce problème de deux façons.
D’abord, en permettant des recettes progressives. Puisque l’éditeur est visuel et accessible depuis un navigateur, le chef de projet peut inviter le client à consulter le contenu en cours de construction, bloc par bloc. Pas besoin d’attendre que tout soit « fini » pour montrer quelque chose. Le client peut valider la page d’accueil pendant que la page Services est encore en chantier.
Ensuite, en donnant au client une autonomie immédiate. Si la recette révèle une formulation à changer ou une image à remplacer, le client peut le faire lui-même dans l’éditeur. Plus besoin de passer par un ticket, d’attendre la disponibilité du développeur, et de vérifier que la modification est bien en ligne. Cette autonomie réduit le nombre d’itérations et libère du temps de développement pour des tâches à plus haute valeur.
La formation : moins longue, plus efficace
Former un client à l’utilisation de son site est une étape souvent sous-estimée dans la planification de projet. Elle prend du temps, elle génère de l’anxiété de part et d’autre, et ses effets s’estompent vite si l’interface est trop complexe.
L’éditeur Gutenberg a une courbe d’apprentissage plus douce que les anciens constructeurs de pages pour une raison simple : il est conceptuellement cohérent. Tout fonctionne par blocs. Ajouter du contenu, c’est ajouter un bloc. Modifier du contenu, c’est sélectionner un bloc et utiliser ses options. Réorganiser, c’est déplacer des blocs.
Cette cohérence rend la formation plus courte et les clients plus autonomes après livraison. En pratique, une session de formation de deux à trois heures suffit pour couvrir les cas d’usage courants — là où les anciens constructeurs nécessitaient souvent des sessions plus longues et des documentations internes spécifiques à chaque projet.
L’autonomie post-livraison a aussi un effet sur la relation client. Un client qui sait modifier son site seul est moins dépendant de l’agence pour des tâches de contenu basiques. Ça libère la relation pour des missions à plus forte valeur ajoutée : évolutions fonctionnelles, SEO, performance, nouvelle fonctionnalité.
La maintenance et l’évolutivité dans le temps
Un site web n’est jamais vraiment terminé. Il évolue avec les besoins de l’entreprise, les changements de stratégie, les nouvelles réglementations. La maintenance à long terme est une dimension souvent négligée dans l’évaluation d’un CMS.
Gutenberg améliore la situation sur ce point pour plusieurs raisons.
- Le format de contenu est plus stable. Les blocs sont stockés dans un format ouvert, documenté, lisible sans le plugin qui les a créés. Si un thème est remplacé dans deux ans, le contenu reste accessible et réutilisable. C’est un avantage par rapport aux anciens constructeurs de pages qui enfermaient parfois le contenu dans des structures propriétaires.
- Les mises à jour sont mieux encadrées. WordPress a intégré Gutenberg dans le cœur du logiciel. Ça signifie que l’éditeur est maintenu par une large communauté, avec des cycles de mise à jour réguliers et prévisibles. Les projets qui utilisent des blocs natifs ou des blocs bien maintenus ont un profil de risque plus bas sur le long terme.
- L’ajout de fonctionnalités est plus modulaire. Quand un client veut ajouter une nouvelle section à son site un an après la livraison, l’agence peut créer un nouveau bloc et le déployer sans toucher au reste du site. La modification est ciblée, testable, et réversible. C’est plus sûr qu’une intervention dans un template monolithique.
Ce que ça change pour le chef de projet
Jusqu’ici, les avantages évoqués touchent surtout les développeurs, les designers et les clients. Mais Gutenberg a aussi des effets directs sur la façon dont un chef de projet peut structurer et piloter un projet.
- La définition des livrables devient plus précise. Avec un éditeur par blocs, il est possible de définir explicitement, en phase de cadrage, quels blocs seront développés sur mesure et lesquels utiliseront des composants natifs ou existants. Ce découpage donne une meilleure visibilité sur l’effort de développement réel.
- La gestion des priorités est simplifiée. Puisque chaque page est composée de blocs indépendants, il est possible de livrer une page « à 80% » avec les blocs prioritaires, puis de compléter avec les blocs secondaires dans une deuxième itération. Cette granularité rend le backlog plus concret et les sprints plus prévisibles.
- Le risque de blocage diminue. Avec les anciens outils, un problème sur un composant central pouvait bloquer la livraison d’une page entière. Avec une architecture par blocs, un problème sur un bloc spécifique n’empêche pas de livrer le reste. Le projet avance même quand un point précis est en discussion.
Ce que Gutenberg ne résout pas
Il serait inexact de présenter Gutenberg comme une solution universelle. Quelques limites méritent d’être nommées.
Les projets très complexes — avec des interfaces d’administration sur mesure, des workflows de publication avancés, ou des structures de données non standards — dépassent rapidement le cadre de l’éditeur de blocs. Pour ces cas, d’autres approches (headless WordPress, ACF avec des interfaces dédiées, ou un autre CMS) peuvent être plus adaptées.
La qualité de l’expérience Gutenberg dépend aussi beaucoup du thème et des blocs utilisés. Un thème mal conçu peut rendre l’éditeur confus pour le client. La sélection des composants et du thème reste une décision technique importante qui ne se délègue pas.
Enfin, la maturité de l’écosystème Full Site Editing — la couche qui permet d’éditer l’intégralité du site par blocs, y compris l’en-tête et le pied de page — est encore inégale selon les thèmes et les extensions. Certains projets bénéficient pleinement de cette approche, d’autres doivent encore composer avec des thèmes classiques.
En conclusion
Gutenberg n’est pas une révolution conceptuelle. C’est une amélioration structurelle qui résout des problèmes concrets : le cloisonnement des équipes, la dépendance au développeur pour des modifications de contenu, la complexité de formation, et la fragilité des sites dans le temps.
Pour un chef de projet web, ces améliorations ne sont pas anodines. Elles se traduisent par des projets plus prévisibles, des recettes moins douloureuses, et des clients plus autonomes après livraison. C’est rarement spectaculaire. Mais c’est durable — et c’est souvent ce qui fait la différence entre un projet réussi et un projet qui traîne.
