API REST WordPress : wp-json, auth et intégrations réelles

L’API REST WordPress n’est pas une option, c’est devenu le standard

Cinq ans en arrière, personne ne parlait de /wp-json/ dans les agences. Aujourd’hui, j’ai trois clients qui ont leurs applications mobiles connectées à leur WordPress, deux qui automatisent leurs publications via N8N, et un qui synchronise son CRM avec les posts de blog. L’API REST WordPress est passée de fonctionnalité expérimentale à infrastructure de production.

Si vous développez encore sur WordPress en 2026 sans comprendre comment fonctionne cette API, vous allez buter sur des projets qui auraient pris deux heures au lieu de deux jours.

wp-json : votre WordPress est déjà une API

Tapez votresite.com/wp-json/ dans votre navigateur. Vous obtenez du JSON. Pas besoin d’installer un plugin, pas besoin de coder quoi que ce soit. WordPress expose déjà vos posts, pages, catégories, utilisateurs, médias via des endpoints standardisés.

C’est le truc que beaucoup de développeurs ne réalisent pas : votre WordPress tourne déjà comme une API REST complète depuis la version 4.7 (décembre 2016). Vous pouvez récupérer la liste de vos posts avec un simple GET sur /wp-json/wp/v2/posts.

Exemple de réponse :

GET https://monsite.com/wp-json/wp/v2/posts?per_page=5

[
  {
    "id": 42,
    "title": { "rendered": "Mon article" },
    "content": { "rendered": "
Contenu...
" },
    "link": "https://monsite.com/mon-article/",
    "date": "2026-04-09T10:30:00"
  }
]

Pas de magie. Du HTTP standard qui retourne du JSON. C’est ça que les applications mobiles consomment, c’est ça que N8N peut lire, c’est ça qu’un site en React peut afficher.

Application Password : la vraie solution d’authentification

L’authentification sur l’API REST WordPress a longtemps été un bordel. OAuth1, JWT custom, cookies de session. Depuis WordPress 5.6 (décembre 2020), il y a Application Passwords en natif.

Voici comment ça marche : vous allez dans votre profil utilisateur WordPress, vous générez un mot de passe d’application (genre abcd efgh ijkl mnop), et vous l’utilisez en Basic Auth.

curl -X POST https://monsite.com/wp-json/wp/v2/posts \
  -u "utilisateur:abcd efgh ijkl mnop" \
  -H "Content-Type: application/json" \
  -d '{
    "title": "Article créé via API",
    "content": "Contenu de mon article",
    "status": "draft"
  }'

Pas de plugin, pas de configuration compliquée. Ça fonctionne. C’est sécurisé (HTTPS obligatoire). Et ça se révoque en un clic dans l’interface WordPress.

Le piège que j’ai vu trois fois ce mois-ci : sur certains hébergements (LiteSpeed notamment), le header Authorization est strippé par Apache. Si vos requêtes authentifiées retournent 401 alors que les credentials sont bons, ajoutez ça dans votre .htaccess :

SetEnvIf Authorization "(.*)" HTTP_AUTHORIZATION=$1

Ça réinjecte le header que le serveur vient de virer.

Créer ses propres endpoints custom

Les endpoints par défaut (/posts, /pages, /users) couvrent 70% des cas. Pour les 30% restants, vous devez créer vos propres routes.

Voici un endpoint custom qui retourne les articles d’un auteur donné avec leurs ACF :

add_action('rest_api_init', function() {
  register_rest_route('mon-api/v1', '/auteur/(?P<id>\d+)/posts', [
    'methods' => 'GET',
    'callback' => 'recuperer_posts_auteur',
    'permission_callback' => function() {
      return current_user_can('read');
    }
  ]);
});

function recuperer_posts_auteur($request) {
  $auteur_id = $request['id'];
  
  $posts = get_posts([
    'author' => $auteur_id,
    'numberposts' => 20
  ]);
  
  $resultats = [];
  foreach ($posts as $post) {
    $resultats[] = [
      'id' => $post->ID,
      'title' => $post->post_title,
      'excerpt' => get_the_excerpt($post),
      'champs_custom' => get_fields($post->ID) // ACF
    ];
  }
  
  return rest_ensure_response($resultats);
}

Maintenant vous pouvez faire GET /wp-json/mon-api/v1/auteur/12/posts et récupérer tous les posts de l’auteur 12 avec leurs champs ACF inclus.

Notez que ce code vérifie les permissions avec current_user_can('read'), valide l’ID avec un regex dans la route ((?P<id>\d+)), et utilise rest_ensure_response() pour le formatage. Sans ces vérifications, vous ouvrez des failles de sécurité.

Permissions et sécurité : ne jamais exposer sans contrôle

L’erreur que je vois le plus souvent : des développeurs qui créent des endpoints custom avec 'permission_callback' => '__return_true'. Ça veut dire « tout le monde peut appeler cette route, même sans être connecté ».

Si votre endpoint retourne des données sensibles (emails, métadonnées privées, brouillons), vous devez vérifier les capacités de l’utilisateur :

'permission_callback' => function() {
  return current_user_can('edit_posts');
}

Pour les endpoints en POST/PUT/DELETE qui modifient des données, vous devez aussi vérifier le nonce pour éviter les CSRF :

'permission_callback' => function($request) {
  $nonce = $request->get_header('X-WP-Nonce');
  return wp_verify_nonce($nonce, 'wp_rest');
}

Ou si vous utilisez Application Passwords (cas le plus courant pour les intégrations externes), laissez WordPress gérer l’authentification Basic Auth automatiquement.

Cas d’usage concrets que je vois en production

Application mobile iOS pour un magazine : l’app appelle /wp-json/wp/v2/posts toutes les heures pour récupérer les nouveaux articles. Aucun code WordPress custom, juste l’API standard.

Automatisation N8N pour un client e-learning : un workflow N8N surveille un Google Sheet, et dès qu’une ligne est ajoutée, il crée un post WordPress via POST /wp-json/wp/v2/posts avec les métadonnées ACF. Zéro intervention manuelle.

Synchronisation CRM-WordPress pour une agence : quand un deal passe en « Gagné » dans Pipedrive, un webhook appelle un endpoint custom WordPress qui crée une case study draft avec les infos du client. Le commercial reçoit une notif Slack, il ajoute deux paragraphes, il publie.

Site headless en Next.js : le frontend Next.js appelle /wp-json/wp/v2/posts et /wp-json/wp/v2/categories au build time pour générer les pages statiques. WordPress devient juste le backoffice de gestion de contenu. L’utilisateur final ne voit jamais WordPress.

Postman, Insomnia, ou curl : testez vos endpoints avant de coder

Avant de coder une intégration complexe, testez vos requêtes API dans Postman ou Insomnia. Vous allez perdre moins de temps à débugger.

Configuration Postman pour WordPress avec Application Password :

• Méthode : POST
• URL : https://monsite.com/wp-json/wp/v2/posts
• Auth : Basic Auth avec votre username WordPress et le mot de passe d’application
• Headers : Content-Type: application/json
• Body (raw JSON) : {"title": "Test", "content": "Contenu", "status": "draft"}

Si la requête retourne 201 Created avec l’objet post, vous êtes bon. Si elle retourne 401, vérifiez votre .htaccess (voir plus haut). Si elle retourne 403, vérifiez les permissions de l’utilisateur.

Plugins qui facilitent le boulot

Quelques plugins que j’utilise régulièrement pour étendre l’API REST :

ACF to REST API : expose les champs ACF dans les endpoints standards. Au lieu de faire get_fields() manuellement dans chaque endpoint custom, les champs ACF apparaissent directement dans la réponse JSON de /wp-json/wp/v2/posts.

JWT Authentication for WP-API : si vous avez besoin de tokens JWT au lieu de Basic Auth (cas des SPAs qui stockent le token en localStorage). Plus complexe qu’Application Passwords, mais nécessaire pour certaines architectures.

WP REST Cache : met en cache les réponses API pour éviter de recalculer les mêmes requêtes GET 500 fois par minute. Utile si vous avez une app mobile avec beaucoup d’utilisateurs.

Custom Post Type UI : pas spécifique à l’API, mais si vous créez des CPT avec ce plugin, ils sont automatiquement exposés sur l’API REST avec l’option show_in_rest => true.

L’API REST WordPress vs GraphQL : lequel choisir

GraphQL (via WPGraphQL) permet de récupérer exactement les champs dont vous avez besoin en une seule requête. REST vous oblige à faire plusieurs appels ou à sur-fetcher des données.

Mon avis après deux ans à faire les deux : utilisez REST par défaut. GraphQL apporte de la complexité (courbe d’apprentissage, debugging, mise en cache) que vous ne voulez pas sauf si vous optimisez vraiment les requêtes d’un site headless avec beaucoup de relations.

REST fonctionne avec curl. Fonctionne avec N8N, Zapier, Make. Fonctionne avec n’importe quel langage sans client spécifique. GraphQL vous demande de comprendre le schema, d’installer un client GraphQL, et de débugger des requêtes qui peuvent devenir incompréhensibles.

Pour la majorité des projets (app mobile, intégration CRM, automatisations), REST fait le job.

Documentation et debug : vos meilleurs alliés

La documentation officielle de l’API REST WordPress est complète : developer.wordpress.org/rest-api/. Elle liste tous les endpoints par défaut, les paramètres acceptés, les codes de retour.

Pour explorer l’API de votre site en mode interactif, installez le plugin « REST API Toolbox » ou utilisez directement la route /wp-json/ dans votre navigateur qui affiche le schema complet.

Pour debugger les erreurs 401/403/500, activez WP_DEBUG et WP_DEBUG_LOG dans votre wp-config.php. Les erreurs PHP qui cassent vos endpoints custom apparaîtront dans wp-content/debug.log.

Ce que l’API REST change dans votre façon de penser WordPress

Avant, WordPress était un CMS avec un backoffice et un frontend couplés. Vous installiez un thème, vous personnalisiez, vous publiiez.

Avec l’API REST, WordPress devient une base de données exposée via HTTP. Le frontend peut être un site React, une app mobile Swift, un tableau de bord Vue.js, un workflow N8N. WordPress gère juste la data.

Ça change tout quand votre client veut un site web, une app mobile, et un espace admin custom. Vous construisez un WordPress qui expose tout via l’API, et trois frontends qui consomment. Pas besoin de reconstruire trois systèmes complets.

C’est pour ça que je vous dis : si vous développez sur WordPress en 2026 et que vous n’avez jamais touché à l’API REST, vous allez galérer. Le prochain projet qui demande une intégration externe, vous allez buter dessus. Ou vous allez mettre trois fois plus de temps qu’il faudrait.