Le débat ACF vs blocs Gutenberg divise la communauté WordPress depuis des années. Certains affirment que Gutenberg est l’avenir et qu’ACF est dépassé. D’autres restent fidèles à ACF et considèrent Gutenberg trop immature pour une utilisation sérieuse en production. La vérité, comme souvent, se situe entre les deux — et dépend du contexte du projet.
Dans cet article, je partage ma position technique, fondée sur de vrais projets réalisés ces dernières années. Sur la grande majorité de mes projets, j’utilise encore ACF. Mais pas par nostalgie — pour des raisons concrètes que j’explique ci-dessous.
Le débat ACF vs Gutenberg, sans idéologie
Posons ce débat en termes pratiques. ACF (Advanced Custom Fields) est un plugin qui vous permet de créer des champs personnalisés pour les CPT, les pages et les taxonomies, avec une UX soigneusement pensée pour les éditeurs. Gutenberg est l’éditeur natif de WordPress, qui repose sur un système de blocs et inclut le FSE (Full Site Editing).
Ce ne sont pas exactement la même chose. ACF est avant tout destiné à structurer le contenu (champs répétables, relations, galeries, données spécifiques). Gutenberg est avant tout destiné à composer la mise en page visuelle. Ils se recoupent dans la gestion de contenu dynamique sur des pages à mises en page flexibles.
Quand ACF l’emporte (et pourquoi je l’utilise encore sur la plupart des projets)
1. Contenu structuré et répétable
Pour les CPT avec des données bien définies (projets, produits, membres de l’équipe, événements), ACF est incomparablement supérieur. Les champs sont explicites, validés, et l’UX pour les éditeurs est claire. Avec Gutenberg, il faudrait implémenter tout cela sous forme de blocs personnalisés, ce qui représente un travail inutile pour des données structurées.
2. Relations entre contenus
Les champs Relationship et Post Object d’ACF permettent de construire facilement des relations complexes entre types de contenu (un projet appartient à un client, implique plusieurs membres de l’équipe, est lié à d’autres projets). Avec Gutenberg, cette logique est beaucoup plus difficile à modéliser proprement.
3. UX pour les clients non techniques
C’est l’argument décisif. Un client qui ouvre le back-office pour modifier le prix d’un service, le nombre d’employés ou la date d’un événement veut un seul champ clair. Il ne veut pas naviguer à travers des blocs — il veut cliquer sur un champ « Prix » et saisir la valeur.
Gutenberg, même s’il s’est amélioré, offre encore une expérience déroutante pour les utilisateurs non techniques sur du contenu structuré. ACF est, en comparaison, d’une simplicité radicale.
4. Performance et contrôle
Avec ACF, le développeur écrit le HTML qu’il souhaite dans le template, avec un contrôle total sur la structure et les performances. Avec Gutenberg, le HTML est généré par le système de blocs, et un contrôle fin est plus difficile à obtenir.
5. Maturité et écosystème
ACF existe depuis plus d’une décennie, dispose d’un écosystème mature, d’une documentation solide et d’un modèle économique pérenne (désormais détenu par WP Engine). Les blocs Gutenberg continuent de subir des changements cassants entre les versions, la documentation est éparpillée, et l’écosystème de blocs tiers manque de cohérence.
Quand Gutenberg est pertinent
Je ne suis pas dogmatique. Il existe des scénarios où Gutenberg est le bon choix.
Pages de contenu éditorial à mises en page variables
Articles de blog longs, landing pages expérimentales, pages de campagne, où l’éditeur doit composer visuellement une séquence de sections différentes dans chaque publication. Pour cela, l’éditeur Gutenberg avec un ensemble soigneusement sélectionné de blocs personnalisés est excellent.
Petits projets avec un client autonome
Si le client gère le site seul, dispose d’une certaine aisance numérique et a besoin de flexibilité pour créer de nouvelles pages sans faire appel à un développeur, Gutenberg avec un thème compatible FSE peut être pertinent.
Blocs réutilisables dans de multiples contextes
Si la même unité de contenu (témoignage, CTA, carte de fonctionnalité) doit apparaître à des dizaines d’endroits différents sur le site, un bloc Gutenberg réutilisable est plus élégant que de dupliquer des champs ACF sur plusieurs pages.
Le scénario hybride que j’utilise sur la plupart des projets
En pratique, mes projets sont rarement 100 % ACF ou 100 % Gutenberg. L’architecture que j’utilise est la suivante :
- CPT avec données structurées : ACF (projets, produits, équipe, événements)
- Pages institutionnelles fixes (accueil, à propos, contact) : ACF Flexible Content ou un template rigide avec ACF
- Articles de blog : Gutenberg, avec un ensemble limité de blocs personnalisés (pullquote, citation, image légendée, CTA)
- Landing pages : Gutenberg avec des blocs personnalisés spécifiques
Cette approche offre au client la bonne UX pour chaque type de contenu : des champs clairs pour les données structurées, une flexibilité visuelle pour le contenu éditorial.
Ce qu’Automattic ne vous dit pas
Le discours officiel veut que Gutenberg et le FSE soient l’avenir inévitable de WordPress. C’est en partie vrai. Mais certaines réalités n’y figurent pas :
- Gutenberg introduit fréquemment des changements cassants, ce qui augmente le coût de maintenance à long terme
- Le FSE (Full Site Editing) présente encore de sérieuses limitations pour les sites d’entreprise aux exigences complexes
- De nombreux développeurs expérimentés continuent d’utiliser ACF parce que la productivité réelle y est supérieure
- La courbe d’apprentissage pour créer des blocs Gutenberg personnalisés est nettement plus abrupte que la création de groupes de champs ACF
- La compatibilité avec les thèmes plus anciens et les migrations est plus complexe avec Gutenberg
Qu’en est-il des ACF Blocks ?
Une solution intermédiaire que j’utilise de plus en plus est ACF Blocks. Elle permet de créer des blocs Gutenberg en utilisant la syntaxe et l’UX d’ACF. Vous bénéficiez ainsi de la flexibilité de composition de Gutenberg avec la simplicité d’implémentation d’ACF.
Ce n’est pas parfait — les performances peuvent être légèrement inférieures à celles des blocs React natifs, et il existe des limitations dans certains cas d’usage avancés. Mais pour la plupart des scénarios où j’ai besoin d’un bloc personnalisé, c’est l’option la plus productive.
Conclusion : ce n’est pas Gutenberg contre ACF, c’est le contexte du projet
La bonne question n’est pas « lequel est le meilleur ». C’est « de quoi ce projet spécifique a-t-il besoin, et qui gérera le contenu ». La réponse varie d’un projet à l’autre.
Si vous envisagez de refondre votre site et n’êtes pas sûr de l’approche à adopter, parlons-en. Je peux vous aider à cartographier les besoins et à proposer l’architecture la mieux adaptée à votre cas.
