Un développeur qui rejoint mon équipe en janvier m’a posé une question simple en apparence : « Pour afficher un prix, une date d’événement ou une note sur cinq, je pars sur quoi maintenant, ACF ou les nouveaux Block Bindings ? » La question méritait une vraie réponse comparative plutôt qu’un réflexe d’habitude, tant le paysage a changé depuis l’arrivée de l’API de Block Bindings en avril dernier.
Voici le comparatif que je lui ai présenté, basé sur des cas réels rencontrés en projet plutôt que sur la documentation seule.
Les trois approches en présence
Les Custom Fields legacy désignent le mécanisme historique de métadonnées WordPress, disponible depuis toujours via add_post_meta() et affiché traditionnellement avec the_meta() ou un shortcode. ACF, gratuit dans sa version de base et payant en Pro, ajoute une interface d’administration riche et des types de champs avancés. Les Block Bindings natifs, arrivés en 6.5, connectent directement un attribut de bloc à une source de données, y compris post-meta nativement, sans dépendance externe.
Tableau comparatif
| Critère | Custom Fields legacy | ACF (gratuit ou Pro) | Block Bindings natifs |
|---|---|---|---|
| Coût | Gratuit | Gratuit / payant en Pro | Gratuit, natif |
| Interface d’édition | Basique, peu conviviale | Riche, très ergonomique | Intégrée à l’éditeur de blocs |
| Champs répéteur / relation | Possible mais fastidieux | Excellent support | Non supporté nativement |
| Dépendance à un plugin tiers | Aucune | Forte (surtout en Pro) | Aucune |
| Affichage dans un bloc natif | Nécessite un shortcode ou bloc dynamique | Nécessite un shortcode ou bloc dynamique | Natif, sans code d’affichage |
| Portabilité si changement de site | Excellente | Bonne si export des groupes de champs | Excellente, tout est natif |
Quand les Custom Fields legacy restent le bon choix
Pour un champ unique et ponctuel, sans besoin d’interface d’administration élaborée, les Custom Fields legacy restent parfaitement adaptés. Un développeur à l’aise avec register_post_meta() peut exposer un champ proprement dans l’API REST et dans l’éditeur de blocs, avec un contrôle total du typage et de la validation, sans dépendance externe :
register_post_meta( 'evenement', 'date_evenement', array(
'type' => 'string',
'single' => true,
'show_in_rest' => true,
'sanitize_callback' => 'sanitize_text_field',
) );Quand ACF conserve un avantage réel
Sur un projet nécessitant des champs répéteur (plusieurs intervenants pour un événement, plusieurs caractéristiques techniques pour un produit) ou des champs relation (lier une fiche à plusieurs autres contenus), ACF Pro reste la solution la plus rapide à mettre en œuvre. Son interface de configuration de groupes de champs, avec logique conditionnelle intégrée, n’a pas d’équivalent natif à ce jour dans le cœur de WordPress.
Le vrai coût caché d’ACF Pro
Le coût de licence n’est pas le seul facteur à considérer : la dépendance à un plugin tiers pour afficher du contenu structuré pose un vrai risque de portabilité si le plugin venait à être abandonné par son éditeur, un risque à évaluer selon l’horizon de vie prévu du projet.
Quand les Block Bindings natifs suffisent
Pour des champs simples de type texte, nombre ou sélection, affichés directement dans un bloc natif (Paragraphe, Titre, Image), les Block Bindings natifs couvrent désormais l’essentiel du besoin sans dépendance, avec une interface d’édition qui reste dans l’éditeur de blocs plutôt que dans un écran séparé.
- Un prix affiché dans un Paragraphe : Block Bindings natifs suffisent largement.
- Une liste de caractéristiques techniques avec plusieurs valeurs : ACF Pro reste plus rapide à configurer.
- Un champ texte unique sans interface riche nécessaire : Custom Fields legacy fait très bien l’affaire.
Le bon choix n’est jamais universel : c’est la complexité du champ, pas l’habitude de l’équipe, qui doit dicter l’outil retenu sur un nouveau projet.
Notre verdict
Sur un projet FSE démarré aujourd’hui, je recommande de commencer par les Block Bindings natifs pour tout champ simple, de réserver ACF Pro aux structures de données réellement complexes (répéteurs, relations), et de garder les Custom Fields legacy pour les cas où un contrôle total du code, sans aucune dépendance, prime sur le confort d’interface.
Un dernier point mérite d’être ajouté à ce comparatif : la question du typage des données exposées dans l’API REST. Les Custom Fields legacy, correctement déclarés via register_post_meta() avec un show_in_rest structuré, offrent un contrôle total du schéma retourné, ce qu’ACF ne propose que depuis ses versions les plus récentes et de façon moins granulaire. Les Block Bindings natifs, eux, ne changent rien à ce niveau : ils consomment la même donnée que celle exposée par le mécanisme de métadonnées sous-jacent, qu’il s’agisse d’un champ ACF ou d’un champ natif. Ce détail a son importance dès qu’un site expose ses contenus à une application tierce, un site mobile ou un tableau de bord externe consommant l’API REST de WordPress : mieux vaut alors soigner le typage dès la déclaration du champ, quelle que soit la méthode d’affichage choisie ensuite dans l’éditeur.
