# Carbon Fields contre ACF pour des champs traduisibles en contexte B2B

> Deux extensions de champs personnalisés, deux façons différentes de gérer la traduction des champs répétables. Comparatif technique pour un site B2B multilingue.

- Auteur : WordPress Développement
- Publié le : 2021-02-01
- Mis à jour le : 2021-02-01
- Catégorie : Multilingue
- URL : https://www.wpmoderne.fr/multilingue/carbon-fields-acf-champs-traduisibles-b2b/

## L’essentiel

- Les deux extensions délèguent la traduction à un plugin multilingue tiers
- La déclaration en code de Carbon Fields facilite le suivi en gestion de version
- ACF Pro reste plus rapide à mettre en place pour une équipe non technique

« Un système de champs personnalisés d'abord pensé pour le code » : c'est ainsi que la documentation officielle de Carbon Fields résume sa philosophie. Cette approche par le code, plutôt que par l'interface, change beaucoup de choses dès qu'il faut gérer des champs répétables traduisibles pour un catalogue B2B de fiches produit technique.

Le projet concerné consistait à structurer des fiches produit pour un fabricant d'équipements industriels vendant en France et en Allemagne, chaque fiche comportant des champs répétables : caractéristiques techniques, variantes disponibles, documents téléchargeables. Ni Carbon Fields ni Advanced Custom Fields ne gèrent nativement la traduction : les deux délèguent cette tâche à une extension multilingue tierce, mais avec des conséquences pratiques différentes.

## Déclaration des champs : code contre interface

Carbon Fields impose une déclaration entièrement en PHP, ce qui a un effet direct sur la traduction : chaque champ répétable est décrit une seule fois dans le code, versionné avec Git, identique quelle que soit la langue active :

```
Container::make( 'post_meta', 'Caractéristiques techniques' )
    ->where( 'post_type', '=', 'fiche_produit' )
    ->add_fields( array(
        Field::make( 'complex', 'caracteristiques', 'Caractéristiques' )
            ->add_fields( array(
                Field::make( 'text', 'nom', 'Nom' ),
                Field::make( 'text', 'valeur', 'Valeur' ),
            ) ),
    ) );
```

ACF, à l'inverse, permet une déclaration par interface graphique, plus accessible à une équipe non technique, mais qui complique le suivi en gestion de version : chaque modification de structure de champ transite par une exportation JSON ou une comparaison de base de données, plus difficile à relire dans une revue de code qu'un simple diff PHP.

## Comportement face à la traduction des champs répétables

| Critère | Carbon Fields | ACF (Pro) |
| --- | --- | --- |
| Déclaration des champs | Code PHP uniquement | Interface ou code |
| Suivi en gestion de version | Direct, diff lisible | Nécessite export JSON |
| Compatibilité champs répétables + WPML | Fonctionnelle avec configuration manuelle | Prise en charge documentée officiellement |
| Courbe d'apprentissage pour un non-développeur | Élevée | Faible |

Le point le plus significatif du comparatif concerne le champ de type `complex` de Carbon Fields, équivalent du champ répéteur d'ACF : sa prise en charge par une extension multilingue demande une configuration manuelle plus poussée, faute de documentation officielle aussi détaillée que celle publiée pour les champs répéteurs d'ACF Pro.

> L'essentiel à retenir : Les deux extensions délèguent la traduction à un plugin multilingue tiers ; La déclaration en code de Carbon Fields facilite le suivi en gestion de version ; ACF Pro reste plus rapide à mettre en place pour une équipe non technique

## Ce que cela change en pratique pour une équipe B2B

Une équipe technique habituée à Git, avec un flux de déploiement structuré, tire un vrai bénéfice de Carbon Fields : la structure des champs devient un artefact de code comme un autre, revu et testé au même titre que le reste du thème. Une équipe éditoriale plus autonome, en revanche, souffre de devoir passer par un développeur pour la moindre modification de structure, alors qu'ACF permet à un profil moins technique d'ajuster lui-même certains champs.

- Carbon Fields convient à un projet piloté entièrement par une équipe de développement
- ACF Pro convient mieux quand l'équipe éditoriale doit gagner en autonomie sur la structure des contenus
- dans les deux cas, la traduction des champs répétables reste un point de configuration à tester tôt dans le projet, jamais à supposer acquis

Un point supplémentaire, souvent négligé au moment du choix, concerne la taille de l'équipe amenée à intervenir sur le site dans la durée : un cabinet qui recrute régulièrement de nouveaux profils techniques trouvera plus simple d'onboarder un développeur sur une base de code Carbon Fields entièrement versionnée, quand une petite structure interne préférera la souplesse d'interface d'ACF pour ses ajustements ponctuels sans recourir systématiquement à un prestataire.

> Avant de choisir entre les deux extensions pour un projet multilingue, testez la traduction d'un champ répétable complet dès la phase de maquette technique : c'est souvent là, et non sur les champs simples, que les limites de chaque solution apparaissent.

## Notre verdict

Pour ce projet B2B précis, Carbon Fields a été retenu en raison de la maîtrise technique de l'équipe et du besoin de suivi rigoureux en gestion de version, la configuration multilingue manuelle des champs répétables ayant été jugée acceptable au regard des autres bénéfices. Une équipe moins outillée techniquement, ou pressée par les délais, tirerait sans doute davantage parti de la prise en charge multilingue plus documentée d'ACF Pro.