Face à Advanced Custom Fields, la référence la plus citée du secteur, deux alternatives reviennent régulièrement dans les discussions entre développeurs qui cherchent à s’affranchir d’une dépendance devenue quasi incontournable : Meta Box, plus proche philosophiquement d’ACF, et Pods, qui pousse la logique plus loin en gérant aussi la création des types de contenus eux-mêmes.
Le choix entre les deux dépend moins d’une qualité technique supérieure de l’une par rapport à l’autre que de la façon dont l’équipe souhaite organiser la définition de sa structure de contenu : uniquement les champs, ou l’ensemble du modèle de données.
Meta Box : une logique de groupes de champs proche d’ACF
add_filter( 'rwmb_meta_boxes', function( $meta_boxes ) {
$meta_boxes[] = array(
'title' => 'Détails de la formation',
'post_types' => 'formation',
'fields' => array(
array(
'name' => 'Durée en heures',
'id' => 'duree_heures',
'type' => 'number',
),
array(
'name' => 'Formateur',
'id' => 'formateur',
'type' => 'text',
),
),
);
return $meta_boxes;
} );Un développeur venu d’ACF retrouve rapidement ses repères avec Meta Box : la structure en tableau, la notion de groupe de champs rattaché à un type de contenu, et une bibliothèque d’extensions officielles pour les besoins avancés (galeries, champs conditionnels, relations entre contenus).
Pods : gérer le type de contenu et les champs ensemble
Pods propose une approche différente dès la création du type de contenu personnalisé : l’interface graphique de Pods permet de définir à la fois register_post_type() et les champs associés dans un même écran, avec la possibilité d’exporter cette définition en code PHP pour la verser au contrôle de version.
// Exemple de code généré par Pods pour un champ
pods_api()->save_field( array(
'pod' => 'formation',
'name' => 'duree_heures',
'type' => 'number',
) );La table personnalisée en option chez Pods
Une particularité de Pods mérite d’être soulignée : au-delà des champs personnalisés classiques stockés en métadonnées, Pods permet aussi de créer des « pods » basés sur des tables entièrement personnalisées plutôt que sur la structure native des articles, ce qui ouvre des possibilités de performance sur de gros volumes, au prix d’une intégration moins transparente avec certaines extensions tierces qui attendent une structure d’article classique.
Portabilité des données à la désinstallation
Dans les deux cas, les valeurs restent stockées dans la table wp_postmeta standard tant que Pods n’est pas configuré pour utiliser une table personnalisée, ce qui signifie que désactiver l’une ou l’autre extension ne fait pas disparaître les données déjà enregistrées, contrairement à une crainte fréquente chez les équipes qui hésitent à changer de bibliothèque.
| Critère | Meta Box | Pods |
|---|---|---|
| Création de types de contenus | Manuelle, en code | Intégrée à l’interface |
| Proximité avec ACF | Élevée | Modérée |
| Stockage optionnel en table dédiée | Non | Oui |
| Export en code PHP | Via extensions officielles | Natif |
Deux profils d’équipe, deux choix logiques
Une équipe déjà à l’aise avec la déclaration de types de contenus en code, qui cherche uniquement une bibliothèque de champs performante et bien documentée, trouve dans Meta Box une transition naturelle depuis ACF. Une équipe qui préfère centraliser la définition complète du modèle de données dans une seule interface, y compris pour les profils moins habitués au code PHP, se tournera plus naturellement vers Pods.
Ni Meta Box ni Pods ne s’imposent d’eux-mêmes : le vrai critère de choix reste de savoir qui, dans l’équipe, doit pouvoir modifier la structure de contenu sans dépendre systématiquement d’un développeur.
Notre verdict
Les deux bibliothèques constituent des alternatives crédibles et matures à ACF, avec des philosophies suffisamment distinctes pour justifier de les tester sur un petit projet avant de généraliser leur usage. Meta Box séduit par sa proximité avec des habitudes déjà acquises, Pods par sa capacité à couvrir l’ensemble du cycle de vie d’un type de contenu personnalisé dans un flux unifié.
