# Champs personnalisés : API native ou Advanced Custom Fields, comment choisir

> register_meta suffit parfois largement là où beaucoup dégainent ACF par réflexe. Voici comment trancher selon le vrai besoin du projet et l'autonomie souhaitée.

- Auteur : Clément Hadrot
- Publié le : 2024-06-11
- Mis à jour le : 2024-06-11
- Catégorie : Tips
- URL : https://wpmoderne.dev.wordpress-developpement.fr/tips/champs-personnalises-api-native-ou-acf-wordpress/

## L’essentiel

- register_meta expose un champ proprement, y compris en API REST
- ACF apporte une interface visuelle et des champs avancés
- Le choix dépend surtout de l'autonomie des rédacteurs

Advanced Custom Fields s'est imposé comme un standard de fait dans l'écosystème WordPress pour ajouter des champs personnalisés. Mais cette extension, aussi pratique soit-elle, n'est pas toujours nécessaire : l'API native de WordPress, avec `register_meta()` et les métaboxes classiques, couvre très bien des besoins simples, sans dépendance externe ni poids supplémentaire sur l'administration.

Cet article compare les deux approches sur des critères concrets, pour aider à trancher selon le contexte réel d'un projet plutôt que par habitude.

## Déclarer un champ avec l'API native

La fonction `register_meta()` enregistre un champ personnalisé de façon structurée, avec un type de donnée défini et, si besoin, une exposition automatique dans l'API REST :

```
add_action( 'init', function() {
    register_meta( 'post', 'reference_produit', array(
        'type'              => 'string',
        'single'            => true,
        'show_in_rest'      => true,
        'sanitize_callback' => 'sanitize_text_field',
        'auth_callback'     => function() {
            return current_user_can( 'edit_posts' );
        },
    ) );
} );
```

Cette déclaration seule ne crée aucune interface dans l'administration : elle ne fait qu'enregistrer proprement le champ auprès de WordPress. Pour l'éditeur classique, une métabox reste nécessaire pour permettre sa saisie visuelle.

## Ajouter une métabox pour la saisie

```
add_action( 'add_meta_boxes', function() {
    add_meta_box(
        'reference_produit_box',
        'Référence produit',
        'afficher_champ_reference',
        'produit'
    );
} );

function afficher_champ_reference( $post ) {
    $valeur = get_post_meta( $post->ID, 'reference_produit', true );
    wp_nonce_field( 'sauvegarde_reference', 'reference_nonce' );
    printf(
        '<input type="text" name="reference_produit" value="%s" class="widefat" />',
        esc_attr( $valeur )
    );
}

add_action( 'save_post', function( $post_id ) {
    if ( ! isset( $_POST['reference_nonce'] ) || ! wp_verify_nonce( $_POST['reference_nonce'], 'sauvegarde_reference' ) ) {
        return;
    }
    if ( isset( $_POST['reference_produit'] ) ) {
        update_post_meta( $post_id, 'reference_produit', sanitize_text_field( $_POST['reference_produit'] ) );
    }
} );
```

Cette approche demande davantage de code qu'ACF pour un champ simple, mais reste totalement transparente : aucune dépendance, aucune structure de données propriétaire à maintenir, un contrôle total sur chaque étape.

> L'essentiel à retenir : register_meta expose un champ proprement, y compris en API REST ; ACF apporte une interface visuelle et des champs avancés ; Le choix dépend surtout de l'autonomie des rédacteurs

## Ce qu'ACF apporte concrètement

Advanced Custom Fields prend tout son sens dès que les besoins se complexifient : des champs répétables, des groupes de champs conditionnels (affichés seulement si une autre valeur est cochée), des relations entre contenus, ou une galerie d'images dédiée. Recréer ces comportements avec l'API native demande un volume de code bien plus important, avec un risque d'erreur plus élevé.

L'interface visuelle de configuration des groupes de champs est aussi un vrai atout pour une équipe qui doit itérer rapidement sur la structure des contenus sans repasser systématiquement par un développeur.

## Tableau comparatif

| Critère | API native (register_meta) | Advanced Custom Fields |
| --- | --- | --- |
| Dépendance externe | Aucune | Une extension à maintenir |
| Champ simple (texte, nombre) | Rapide à mettre en place | Rapide, avec interface visuelle |
| Champs répétables ou conditionnels | Développement conséquent | Natif et bien documenté |
| Autonomie de l'équipe éditoriale | Limitée sans interface dédiée | Bonne, via l'interface de configuration |
| Exposition API REST | Native avec show_in_rest | Nécessite un réglage ou du code additionnel |
| Portabilité entre projets | Totale, code source uniquement | Dépend de la présence de l'extension |

## Un critère souvent négligé : l'exposition en API REST

Sur un projet headless ou consommant l'API REST de WordPress depuis un frontend séparé, l'API native a un avantage réel : `register_meta()` avec `show_in_rest` à `true` expose le champ automatiquement, sans configuration supplémentaire. Avec ACF, cette exposition demande un réglage explicite ou un filtre dédié pour apparaître correctement dans les réponses de l'API.

## Comment trancher en pratique

- Un ou deux champs simples, sur un projet sans dépendance à ajouter : l'API native suffit largement
- Une structure de champs complexe, avec des répéteurs ou des relations, sur un projet où l'équipe éditoriale doit rester autonome : ACF apporte une vraie valeur
- Un projet déjà équipé d'ACF pour d'autres besoins : rester cohérent avec l'existant plutôt que mélanger les deux approches sans raison

> Installer ACF pour un unique champ texte, c'est ajouter une dépendance entière à maintenir pour un besoin que quinze lignes de code natif auraient couvert tout aussi bien.

## En résumé

Ni l'API native ni ACF ne sont une solution universellement supérieure : le choix dépend du volume et de la complexité réelle des champs nécessaires, ainsi que de l'autonomie attendue de l'équipe éditoriale. Sur un projet simple, l'API native évite une dépendance pour un gain de temps marginal ; sur un projet aux besoins structurants et évolutifs, ACF reste souvent le choix le plus pragmatique.