Zéro écran d’administration pour configurer un champ : c’est la différence la plus visible entre Carbon Fields et Advanced Custom Fields, deux bibliothèques qui répondent au même besoin – ajouter des champs personnalisés à un contenu WordPress – avec des philosophies presque opposées.
ACF a construit sa popularité sur une interface graphique qui permet à quiconque, développeur ou non, de créer un groupe de champs en quelques clics. Carbon Fields part du principe inverse : tout se déclare en code PHP, sans jamais passer par un écran de configuration, ce qui change profondément la façon de travailler sur un projet.
Déclarer un champ dans chaque bibliothèque
// Avec Carbon Fields
use Carbon_Fields\Container;
use Carbon_Fields\Field;
add_action( 'carbon_fields_register_fields', function() {
Container::make( 'post_meta', 'Détails du produit' )
->where( 'post_type', '=', 'produit' )
->add_fields( array(
Field::make( 'text', 'reference', 'Référence' ),
Field::make( 'checkbox', 'en_promotion', 'En promotion' ),
) );
} );Avec ACF, la même structure se construit soit via l’écran « Groupes de champs », soit via acf_add_local_field_group() si l’équipe préfère garder la définition en code, une option souvent négligée par les utilisateurs qui découvrent l’extension par son interface graphique.
Ce que Carbon Fields apporte concrètement
- Une définition des champs entièrement versionnée dans Git, sans export/import JSON à synchroniser
- Aucune dépendance à une extension tierce active en production : Carbon Fields s’installe via Composer et s’intègre au code du thème ou de l’extension
- Une API orientée développeur, cohérente avec un flux de travail basé sur des espaces de noms et de l’autoloading
Ce que Carbon Fields ne propose pas
L’absence d’interface graphique représente un choix assumé, pas une lacune, mais elle a un coût réel pour certains profils : un client qui souhaiterait ajouter lui-même un champ sans solliciter un développeur ne le peut tout simplement pas avec Carbon Fields. Toute modification de structure passe par une modification de code et un déploiement.
Le champ répéteur, un point de comparaison révélateur
// Carbon Fields
Field::make( 'complex', 'caracteristiques', 'Caractéristiques' )
->add_fields( array(
Field::make( 'text', 'libelle', 'Libellé' ),
Field::make( 'text', 'valeur', 'Valeur' ),
) );Le champ complexe de Carbon Fields joue un rôle équivalent au champ répéteur d’ACF Pro, à ceci près qu’il fait partie du cœur gratuit de la bibliothèque, alors qu’ACF réserve les champs répéteurs à sa version payante.
Tableau comparatif
| Critère | Carbon Fields | ACF |
|---|---|---|
| Interface graphique | Aucune | Oui, complète |
| Champ répéteur | Inclus gratuitement | Version Pro payante |
| Installation | Composer, dans le projet | Extension activée séparément |
| Accessible à un non-développeur | Non | Oui |
| Versionnage de la structure | Nativement, en code | Nécessite export JSON discipliné |
Quel profil de projet pour chaque bibliothèque
Carbon Fields convainc sur des projets où toute la structure de contenu reste sous le contrôle d’une équipe de développement, sans besoin d’autonomie côté client sur la création de champs. ACF garde l’avantage dès qu’un client ou un rédacteur doit pouvoir ajuster lui-même la structure sans repasser par un développeur, ou quand une équipe valorise la rapidité de mise en place via l’interface graphique.
Le critère qui tranche n’est jamais la qualité technique de l’une ou l’autre bibliothèque, mais la question : qui, dans l’équipe projet, doit pouvoir modifier la structure des champs sans déploiement de code ?
Notre verdict
Carbon Fields mérite sa place chez une équipe de développement qui privilégie un flux entièrement versionné et refuse toute dépendance à une interface de configuration graphique. ACF reste néanmoins le choix par défaut le plus sûr dès qu’un acteur non technique doit intervenir sur la structure des contenus, ce qui reste le cas le plus fréquent sur les projets confiés à un client final.
