Comment afficher un champ ACF simple — un numéro de téléphone, une citation, une image de fond — dans un template de thème bloc, sans écrire un bloc personnalisé complet en JavaScript ? C’est la question qui revient sur presque tous les projets qui migrent une vitrine vers un thème bloc tout en gardant Advanced Custom Fields pour les données métier.
En septembre 2023, deux chemins sont réellement praticables sur un projet en production. Le premier existe depuis des années et fonctionne dès aujourd’hui. Le second, une API de liaison de champs directement dans l’éditeur de blocs, est en cours de discussion dans le développement du cœur WordPress mais n’est pas encore disponible : il faut donc s’appuyer sur ce qui fonctionne réellement, tout en gardant un œil sur ce chantier.
Le bloc dynamique ACF : la solution qui marche aujourd’hui
La fonction acf_register_block_type(), disponible depuis ACF PRO, permet de déclarer un bloc dont le rendu est entièrement calculé côté serveur, en PHP, via un template classique :
add_action( 'acf/init', function() {
if ( ! function_exists( 'acf_register_block_type' ) ) {
return;
}
acf_register_block_type( [
'name' => 'citation-client',
'title' => __( 'Citation client', 'mon-theme' ),
'render_template' => 'template-parts/blocks/citation-client.php',
'category' => 'mon-theme',
'icon' => 'format-quote',
'supports' => [ 'align' => true ],
] );
} );
Dans citation-client.php, les champs se récupèrent avec les fonctions ACF habituelles, exactement comme dans un thème classique :
<?php
$citation = get_field( 'texte_citation' );
$auteur = get_field( 'nom_auteur' );
?>
<blockquote class="citation-client">
<p><?php echo esc_html( $citation ); ?></p>
<cite><?php echo esc_html( $auteur ); ?></cite>
</blockquote>
Cette approche a un avantage décisif dans un thème bloc : elle reste insérable directement dans un template .html ou un modèle de partie via le tag de bloc généré, tout en gardant toute la logique métier côté PHP, familière à qui maintient déjà des thèmes classiques avec ACF.

Ce qui se prépare dans le cœur : la liaison de blocs
Un chantier est en cours sur le Trac de WordPress et sur les canaux de développement de Gutenberg : une API de liaison (« block bindings ») permettrait, à terme, de connecter directement un attribut de bloc natif — le texte d’un paragraphe, la source d’une image — à une source de données externe, sans passer par un bloc dynamique dédié. L’idée serait de pouvoir lier, depuis l’interface de l’éditeur, un simple bloc Paragraphe à une métadonnée d’article, potentiellement une valeur ACF via un registre de sources personnalisé.
Au moment de la rédaction, cette API n’est pas encore intégrée dans une version stable de WordPress : elle fait l’objet de tickets Trac et de discussions actives sur le dépôt GitHub de Gutenberg, sans calendrier de sortie stabilisé. Il serait donc prématuré de bâtir un projet client dessus aujourd’hui ; elle mérite en revanche d’être suivie de près, car elle changerait la donne pour les cas simples.
Ce que cette future API ne devrait pas remplacer
Même une fois disponible, une liaison de blocs native ne semble pas destinée à couvrir les cas complexes : champs répétables, groupes de champs conditionnels, galeries avec logique métier. Le bloc dynamique ACF garde alors tout son intérêt pour ces scénarios, quelle que soit l’évolution du cœur.
Tableau comparatif
| Critère | Bloc dynamique ACF | Liaison de blocs (à venir) |
|---|---|---|
| Disponibilité | Oui, dès aujourd’hui | En discussion, non stabilisée |
| Complexité de mise en œuvre | Moyenne (PHP + enregistrement de bloc) | Inconnue, dépend du design final de l’API |
| Champs répétables | Géré nativement par ACF | Non prévu dans les discussions actuelles |
| Édition visuelle dans l’éditeur | Limitée au rendu du template PHP | Pensée pour une édition inline plus directe |
| Dépendance à ACF PRO | Oui, pour acf_register_block_type | À confirmer selon l’implémentation finale |
Verdict pour un projet en cours
Pour toute livraison entre maintenant et les prochains mois, le bloc dynamique reste le choix responsable : il est stable, documenté, et son comportement ne dépendra pas de l’issue d’une discussion encore ouverte dans le cœur. La liaison de blocs mérite une veille active, en particulier pour les projets dont le calendrier de livraison s’étend sur plusieurs mois, mais construire une dépendance de production sur une API non stabilisée expose à des changements de comportement d’une version à l’autre de Gutenberg.
Suivre un chantier en discussion est utile ; bâtir un livrable client dessus avant sa stabilisation est un pari, pas une décision d’architecture.
En résumé
Le bloc dynamique ACF répond dès aujourd’hui à l’essentiel des besoins d’affichage de champs personnalisés dans un thème bloc, avec une mise en œuvre connue et prévisible. La future API de liaison de blocs, encore en gestation dans le développement du cœur WordPress, promet une expérience d’édition plus fluide pour les cas simples, mais son calendrier et son périmètre définitif restent à confirmer avant toute adoption en production.