Combien coûte réellement le choix d’une source de liaison personnalisée plutôt qu’un champ ACF classique ? La question s’est posée sur un site vitrine multi-pages pour un fabricant de literie, où un même bandeau de garantie devait afficher une donnée technique liée au produit affiché — un cas d’usage strictement identique aurait pu être couvert par les deux approches. Ce n’est pas la mise en place technique de l’une ou l’autre qui nous intéresse ici, déjà traitée ailleurs, mais l’arbitrage qui doit précéder le choix.
Le raisonnement mérite d’être posé sur trois axes : la performance au rendu, le coût de maintenance dans le temps, et la dépendance à une extension tierce. Sur les trois, les réponses ne vont pas toutes dans le même sens.
Performance : où se joue vraiment la différence
Un champ ACF classique s’appuie sur get_field(), qui interroge en interne get_post_meta() — un accès déjà mis en cache par WordPress via le cache d’objets pour la requête en cours, donc peu coûteux en soi. Une source de liaison personnalisée, elle, exécute un callback PHP arbitraire à chaque affichage du bloc concerné : si ce callback interroge une API externe sans mise en cache, il devient largement plus lent qu’un simple champ ACF.
La différence de performance ne vient donc pas de la nature de l’API utilisée, mais de la discipline de mise en cache appliquée par le développeur. Sur le projet du fabricant de literie, le passage à une source de liaison avec cache en transient a réduit de trois le nombre de requêtes SQL par page, en évitant une jointure supplémentaire que l’implémentation ACF précédente exécutait à chaque chargement.
Maintenance : ce que chaque choix engage sur la durée
ACF impose une dépendance à une extension tierce, gratuite dans sa version de base mais dont l’évolution ne dépend pas de l’équipe du projet. Une source de liaison personnalisée, elle, repose entièrement sur le cœur de WordPress via register_block_bindings_source() — aucune mise à jour d’extension à surveiller, mais un code entièrement à la charge de l’équipe, y compris sa documentation et ses tests.
| Critère | Champ ACF | Source de liaison maison |
|---|---|---|
| Dépendance à une extension tierce | Oui | Non |
| Interface de saisie prête à l’emploi | Oui, native à ACF | Non, à construire ou à saisir en base directement |
| Contrôle total sur la logique de mise en cache | Limité aux réglages ACF | Total, à la charge du développeur |
| Coût si l’extension ACF disparaît un jour | Migration nécessaire | Aucun impact |
Le vrai point de bascule : la complexité de la source de données
Pour une donnée simple, un champ texte ou un nombre saisi manuellement, ACF reste imbattable en rapidité de mise en œuvre : une équipe déjà formée configure un champ en quelques minutes, avec une interface de saisie éprouvée. Dès que la donnée provient d’une source externe complexe — un flux, une API, un calcul dérivé de plusieurs autres champs —, la source de liaison personnalisée reprend l’avantage, car elle évite de stocker une donnée dupliquée qui pourrait diverger de sa source d’origine.
Le bon critère n’est pas « ACF ou binding maison », mais « la donnée a-t-elle besoin d’être stockée, ou seulement affichée à partir d’ailleurs ? ».
Un troisième facteur souvent oublié : le poids de l’équipe
Une petite agence sans développeur PHP dédié en permanence tirera davantage bénéfice d’ACF, dont l’écosystème de documentation et de tutoriels reste plus large que celui, plus récent, des sources de liaison personnalisées. Une équipe technique plus mature, en revanche, gagnera à réduire ses dépendances externes sur le long terme, quitte à investir un peu plus de temps initial dans l’écriture du callback.
Ce que ce comparatif ne tranche pas
Ce choix ne concerne que l’affichage de données déjà simples à modéliser. Il ne remet pas en cause l’intérêt d’ACF pour des champs répétables complexes, des relations entre contenus ou une interface de saisie avancée que les sources de liaison personnalisées ne couvrent pas encore nativement — l’API Block Bindings reste, à ce jour, orientée lecture plutôt que saisie riche.
Notre verdict
Sur un projet où la donnée provient d’une source externe et où l’équipe maîtrise déjà PHP, une source de liaison personnalisée bien mise en cache coûte moins cher en performance et en dépendances qu’un champ ACF équivalent. Pour une saisie manuelle simple par une équipe non technique, ACF reste le choix le plus rapide à mettre en œuvre et à faire vivre au quotidien.
