ACF Pro ou l’API native de liaison de blocs, disponible depuis WordPress 6.5 sorti en avril 2024 : la question revient sur presque tous les nouveaux projets de thème sur mesure depuis quelques mois, et la réponse par défaut « on prend ACF, comme d’habitude » mérite d’être challengée maintenant que WordPress propose une alternative native pour une partie des cas d’usage.
Les deux approches répondent au même besoin de base : afficher une valeur de champ personnalisé dans un attribut d’un bloc, sans coder un bloc entièrement sur mesure pour chaque variation. Elles divergent en revanche fortement sur la maintenabilité à long terme, l’ergonomie côté rédacteur, et la dépendance créée pour l’agence qui livre le projet.
Ce que fait Block Bindings, nativement
L’API Block Bindings permet de lier un attribut de bloc core à une source de données personnalisée, déclarée via register_block_bindings_source(), sans passer par une extension tierce :
register_block_bindings_source( 'monagence/meta-produit', array(
'label' => __( 'Champ produit', 'monagence' ),
'get_value_callback' => function( $args, $block_instance ) {
return get_post_meta( $block_instance->context['postId'], $args['key'], true );
},
) );Le rédacteur, dans l’éditeur, associe alors un attribut de bloc (le texte d’un titre, la source d’une image) à cette source via l’interface native, sans champ ACF déclaré au préalable, et sans dépendance de licence.
Ce que fait encore mieux ACF, en pratique
Advanced Custom Fields, de son côté, dispose depuis longtemps d’une intégration comparable via ses champs liés aux blocs, avec un avantage décisif pour les équipes déjà formées : l’interface de déclaration de champs (groupes, conditions d’affichage, types de champs riches) reste bien plus rapide à manier pour un développeur qui l’utilise au quotidien depuis des années. Le gain de Block Bindings en coût de licence se paie souvent en temps de configuration pour des cas un peu plus riches que « un attribut, une valeur ».
| Critère | Block Bindings (natif) | ACF Pro |
|---|---|---|
| Coût de licence | Aucun | Licence annuelle par site |
| Types de champs disponibles | Limité aux attributs de blocs core pris en charge | Très large (image, relation, groupe, etc.) |
| Dépendance externe | Aucune, natif au cœur | Oui, extension tierce active requise |
| Ergonomie de configuration | Nécessite du code PHP pour chaque source | Interface graphique pour les cas courants |
| Pérennité si le projet change de mainteneur | Élevée, dépend uniquement du cœur WordPress | Dépend de la licence et du support tiers |
Le vrai critère de décision : la durée de vie du projet
Pour un site vitrine simple, à quelques champs, sans intention de repasser dessus dans les cinq prochaines années, Block Bindings élimine une dépendance de licence et un point de défaillance externe. Pour un projet d’agence transmis d’une équipe à une autre au fil des années, avec des besoins de champs qui vont grandir (répéteurs, relations entre contenus, groupes conditionnels), ACF reste souvent le choix le plus pragmatique : la courbe d’apprentissage de l’équipe suivante est plus courte, et la richesse de configuration évite d’écrire du code PHP pour chaque nouveau besoin de champ.
Ce que cette comparaison ne couvre pas
Les champs répéteurs, disponibles nativement dans ACF Pro et absents de l’API Block Bindings en l’état, sortent volontairement du cadre de cette comparaison : ils mériteraient un article à part, tant leur absence côté natif change la donne dès qu’un projet a besoin de listes de données structurées répétées.
Sur les projets qu’on livre aujourd’hui, la règle qui se dégage : Block Bindings pour les sites simples et pérennes sans budget de licence récurrent, ACF Pro dès que le projet est amené à grossir avec une équipe qui tourne. Les deux coexistent d’ailleurs très bien sur un même site.
Notre verdict
Il n’y a pas de gagnant universel entre les deux approches : Block Bindings gagne en indépendance et en coût nul, ACF Pro gagne en richesse fonctionnelle et en rapidité de configuration pour une équipe déjà formée. Le bon réflexe, avant de trancher, consiste à estimer la durée de vie probable du projet et la stabilité de l’équipe qui le maintiendra, plutôt que de reproduire par habitude le choix fait sur le projet précédent.
