Depuis qu’Advanced Custom Fields propose acf_register_block_type(), il existe deux chemins bien distincts pour créer un bloc Gutenberg : la voie native, avec registerBlockType en JavaScript et block.json, ou la voie ACF, où l’on déclare un bloc en PHP et où les champs sont gérés par l’interface familière d’ACF. Les deux fonctionnent, les deux sont utilisées en production sur des milliers de sites, mais elles ne répondent pas aux mêmes besoins.
Cet article compare les deux approches sur des critères concrets : courbe d’apprentissage, performance, portabilité, et écosystème, pour aider à trancher selon le contexte de chaque projet plutôt que par habitude.
Deux philosophies de déclaration
Un bloc natif se déclare via block.json, avec un fichier JavaScript qui décrit l’expérience d’édition (edit) et éventuellement l’affichage statique (save), ou un fichier render.php pour un rendu dynamique. Un bloc ACF, lui, se déclare entièrement en PHP :
acf_register_block_type( [
'name' => 'temoignage',
'title' => __( 'Témoignage', 'wpmoderne' ),
'category' => 'formatting',
'icon' => 'testimonial',
'render_template' => 'blocks/temoignage.php',
'enqueue_style' => get_template_directory_uri() . '/blocks/temoignage.css',
] );Les champs du bloc (texte, image, relation) se créent ensuite avec l’interface graphique ACF, exactement comme pour un champ personnalisé classique, et sont accessibles dans le template via get_field(). Aucun JavaScript n’est requis pour un bloc simple.
Courbe d’apprentissage
C’est là que l’écart est le plus net. Un développeur WordPress qui maîtrise déjà PHP et les templates classiques peut produire un bloc ACF fonctionnel en moins d’une heure, sans jamais toucher à React ni à un outil de build. Un bloc natif, en revanche, suppose de comprendre @wordpress/element, le cycle edit/save, la gestion des attributs côté JavaScript, et souvent un outillage de build comme @wordpress/scripts.
Pour une agence qui doit former rapidement de nouveaux développeurs, ou pour un projet avec un budget de développement serré, cet écart pèse lourd dans la balance. À l’inverse, une équipe qui maîtrise déjà React ne gagne quasiment rien à passer par ACF, et perd même en contrôle sur l’expérience d’édition.
Performance et poids des dépendances
Un bloc ACF dépend, par définition, du plugin Advanced Custom Fields (gratuit ou Pro selon les fonctionnalités utilisées). Cela ajoute une dépendance externe au projet, avec son propre cycle de mises à jour et ses propres requêtes en base pour la configuration des champs. Sur un site avec plusieurs dizaines de blocs ACF, l’overhead reste généralement négligeable, mais il existe.
Un bloc natif n’a aucune dépendance runtime en dehors du cœur de WordPress. L’expérience d’édition dans l’éditeur repose uniquement sur les paquets @wordpress/*, déjà chargés par l’éditeur lui-même. Côté front, un bloc statique (avec save) ne charge même aucun PHP supplémentaire au rendu, le HTML étant déjà stocké dans le contenu de l’article.
Portabilité et pérennité
Un bloc natif reste fonctionnel même si ACF est désactivé, désinstallé, ou si le projet change un jour de stratégie de champs personnalisés. Un bloc ACF, lui, cesse immédiatement de fonctionner sans le plugin : le contenu existant peut même devenir illisible dans l’éditeur si ACF n’est plus actif, bien que le rendu front continue généralement de s’afficher tant que le HTML est déjà en base.
Ce point mérite d’être anticipé dès la phase de cahier des charges : un client qui prévoit de changer d’agence de maintenance, ou qui souhaite garder la main sur ses licences de plugins premium, peut légitimement préférer des blocs natifs pour ne dépendre d’aucun plugin tiers payant.
Tableau comparatif
| Critère | Blocs ACF | Blocs natifs |
|---|---|---|
| Compétences requises | PHP, interface ACF | PHP, JavaScript, React |
| Temps de mise en place | Rapide | Plus long au départ |
| Dépendance externe | Plugin ACF requis | Aucune |
| Expérience d’édition | Formulaire de champs classique | Personnalisable à volonté (React) |
| Portabilité entre projets | Limitée sans ACF | Totale |
| Cas d’usage idéal | Sites de contenu, équipes PHP | Produits, plugins publics, SaaS WordPress |
Des cas d’usage complémentaires plutôt qu’opposés
Dans la pratique, beaucoup de projets combinent les deux approches sans difficulté. Un thème sur mesure, livré à un client avec une équipe de contenu autonome, utilise souvent des blocs ACF pour les sections de mise en page courantes (témoignage, chiffres clés, bannière), rapides à produire et faciles à maintenir pour l’agence. Un plugin destiné à être distribué publiquement sur le répertoire WordPress.org, en revanche, privilégie presque toujours des blocs natifs, ACF ne pouvant pas être imposé comme dépendance à tous les utilisateurs.
- Site vitrine ou blog géré par une seule équipe interne : ACF convient très bien.
- Plugin ou thème destiné à un public large : les blocs natifs s’imposent.
- Produit avec une expérience d’édition sophistiquée (prévisualisation en direct, interactions riches) : les blocs natifs offrent bien plus de liberté.
La question à se poser n’est jamais « ACF ou natif dans l’absolu », mais « qui va maintenir ce bloc dans deux ans, et avec quelles compétences ». La réponse tranche presque toujours le débat.
Notre verdict
Aucune des deux approches n’est universellement meilleure. ACF reste imbattable pour aller vite sur des blocs de mise en page avec une équipe majoritairement PHP, tandis que les blocs natifs s’imposent dès que la portabilité, la performance front ou une expérience d’édition avancée entrent en jeu. Sur un projet mixte, il n’est pas rare, ni problématique, de voir cohabiter les deux types de blocs au sein du même thème.
