WordPress REST API : guide pratique pour développeurs et webmasters

L’API REST de WordPress, ça fait peur. Des endpoints, des requêtes HTTP, du JSON, de l’authentification… Ça sonne "développeur" à plein nez. Et pourtant, en 2026, c’est un outil que tout le monde devrait connaître, même si vous ne codez pas. Pourquoi ? Parce que c’est ce qui fait tourner les sites headless, les apps mobiles connectées à WordPress, et l’automatisation de contenu. J’ai longtemps hésité avant de plonger dedans… et je regrette de ne pas l’avoir fait plus tôt.

Sur wpformation.com, on utilise l’API REST quotidiennement : le frontend Next.js récupère les articles via l’API, les sauvegardes sont pilotées par API, les mises à jour de contenu passent par l’API. En tant que co-créateur de plugins WordPress totalisant plus de 2 millions d’installations et fondateur de WPServeur (hébergement WordPress géré), j’utilise l’API REST depuis son introduction dans WordPress 4.7 (décembre 2016). Voici le guide pratique, sans jargon inutile.

L’API REST WordPress, c’est quoi ?

Bon. Simplifions. L’API REST, c’est une porte d’entrée dans votre site WordPress. Au lieu de passer par l’interface d’administration (wp-admin) pour créer un article… vous envoyez une requête HTTP à une URL et WordPress fait le travail.

Concrètement, si votre site est sur monsite.com, l’API est accessible à l’adresse monsite.com/wp-json/wp/v2/. Et vous pouvez :

• GET /wp/v2/posts : récupérer la liste des articles publiés
• GET /wp/v2/posts/123 : récupérer l’article avec l’ID 123
• POST /wp/v2/posts : créer un nouvel article
• PUT /wp/v2/posts/123 : modifier un article existant
• DELETE /wp/v2/posts/123 : mettre un article à la corbeille (ajoutez ?force=true pour le supprimer définitivement)

Ça vous parle ? C’est le même principe que quand vous utilisez une appli bancaire sur votre téléphone : l’appli ne contient pas vos données, elle les demande au serveur de la banque via une API. WordPress fonctionne pareil.

Quels sont les endpoints principaux de l’API REST ?

WordPress expose nativement une dizaine d’endpoints. Voici les plus utilisés :

Endpoint	Description	Auth requise
/wp/v2/posts	Articles (CRUD complet)	Lecture : non. Écriture : oui
/wp/v2/pages	Pages (CRUD complet)	Lecture : non. Écriture : oui
/wp/v2/media	Médias (images, fichiers)	Lecture : non. Upload : oui
/wp/v2/categories	Catégories	Lecture : non. Écriture : oui
/wp/v2/tags	Étiquettes	Lecture : non. Écriture : oui
/wp/v2/users	Utilisateurs	Liste : selon config. Détail : oui
/wp/v2/comments	Commentaires	Lecture : non. Écriture : oui
/wp/v2/search	Recherche globale	Non
/wp/v2/block-patterns/patterns	Compositions de blocs (leurs catégories : /wp/v2/block-patterns/categories)	Oui
/wp/v2/settings	Réglages du site	Oui (admin)

Chaque endpoint supporte des paramètres de filtrage. Par exemple, pour récupérer les 5 derniers articles de la catégorie 3 :

GET /wp/v2/posts?categories=3&per_page=5&orderby=date&order=desc

Le paramètre _fields filtre les champs retournés et allège fortement la réponse JSON :

GET /wp/v2/posts?_fields=id,title,slug,date&per_page=100

Comment s’authentifier sur l’API REST WordPress ?

Lire des données publiques (articles publiés, catégories) ne nécessite aucune authentification. Mais pour créer, modifier ou supprimer du contenu, il faut s’authentifier. WordPress propose plusieurs méthodes :

Application Passwords (recommandé)

Intégré nativement depuis WordPress 5.6 (décembre 2020). C’est la méthode que je recommande pour les intégrations serveur-à-serveur, et de loin la plus simple à mettre en place.

Procédure :

1. Dans wp-admin, allez dans Utilisateurs > votre profil
2. En bas de page, section "Mots de passe d’application"
3. Entrez un nom (ex: "Mon Script Backup") et cliquez "Ajouter"
4. WordPress génère un mot de passe unique (24 caractères avec espaces)
5. Notez-le, il ne sera plus affiché

Utilisation avec curl :

curl -X POST "https://monsite.com/wp-json/wp/v2/posts" \
  -H "Authorization: Basic $(echo -n 'user:motdepasse' | base64)" \
  -H "Content-Type: application/json" \
  -d '{"title":"Mon article","content":"Le contenu","status":"draft"}'

Cookie Nonce (pour les thèmes et plugins)

Si vous faites des appels API depuis le front-end de votre site (JavaScript dans un thème ou un plugin), WordPress utilise le système de nonce :

// En PHP, localiser le script avec le nonce
wp_localize_script('mon-script', 'wpApiSettings', array(
    'root' => esc_url_raw(rest_url()),
    'nonce' => wp_create_nonce('wp_rest')
));

// En JavaScript
fetch(wpApiSettings.root + 'wp/v2/posts', {
    headers: { 'X-WP-Nonce': wpApiSettings.nonce }
});

Le nonce a une durée de vie de 12 à 24 heures (par défaut, le paramètre nonce_life est de 86 400 secondes, mais WordPress utilise un système de "ticks" qui divise cette durée en deux périodes de 12 heures). C’est la méthode utilisée par Gutenberg lui-même pour communiquer avec l’API.

JWT (JSON Web Tokens)

Pour les applications mobiles ou les SPA (Single Page Applications), JWT est souvent préféré. Il nécessite un plugin comme "JWT Authentication for WP REST API" ou "Simple JWT Login". Le principe : vous envoyez vos identifiants une fois, vous recevez un token… et vous utilisez ce token pour toutes les requêtes suivantes.

Avez-vous besoin de JWT ? Si votre cas d’usage est un script serveur ou une intégration back-end, non. Les Application Passwords suffisent. JWT est utile quand l’authentification se fait depuis un client (navigateur, app mobile) où stocker un mot de passe en clair serait risqué.

Quels sont les 5 cas d’usage concrets de l’API REST ?

L’API REST, c’est bien joli en théorie. Mais à quoi ça sert en pratique ? Voici 5 exemples réels, dont certains que j’utilise quotidiennement sur wpformation.com :

1. WordPress headless

C’est le cas le plus en vogue. WordPress sert de back-end (gestion de contenu), et un framework JavaScript (Next.js, Nuxt, Astro) gère le front-end. L’API REST est le pont entre les deux. C’est exactement ce qu’on fait sur wpformation.com, et j’en parle en détail dans mon guide complet sur le headless. Résultat au dernier contrôle (juillet 2026) : PageSpeed Mobile à 97, et une réponse serveur autour de 20 ms.

2. Applications mobiles

Votre blog WordPress peut alimenter une app iOS ou Android. L’app consomme l’API REST pour afficher les articles, les catégories, les commentaires. Des frameworks comme React Native ou Flutter s’y connectent facilement.

3. Automatisation de contenu

Publier automatiquement des articles depuis un tableur, un CRM, ou un workflow Zapier/Make… Un script Python ou Node.js qui crée des brouillons à partir de données structurées, c’est 20 lignes de code avec l’API REST. J’ai testé les trois approches, et dans mon cas, un script Node.js reste le plus flexible.

4. Sauvegardes et migrations

Extraire le contenu d’un site WordPress pour le sauvegarder en JSON, le migrer vers un autre CMS, ou l’archiver. Sur wpformation.com, les sauvegardes de contenu passent par l’API REST : le JSON se manipule bien plus facilement que le XML quand il s’agit de rejouer les données ailleurs. Une mise en garde, parce que la confusion coûte cher : ce n’est pas une sauvegarde complète. L’API ne vous rend ni les fichiers médias, ni les réglages, ni les tables de vos extensions, et l’export natif (WXR) reste plus complet sur les taxonomies, les commentaires, les champs personnalisés et les utilisateurs. L’API REST est un excellent export de contenu. Pas un plan de sauvegarde.

5. Tableaux de bord personnalisés

Construire un dashboard externe qui agrège les données de plusieurs sites WordPress : nombre d’articles, statistiques, commentaires en attente, mises à jour disponibles. Les agences qui gèrent 50+ sites WordPress utilisent ça quotidiennement.

Créer un endpoint personnalisé

Les endpoints natifs ne couvrent pas tous les besoins. Bonne nouvelle : WordPress vous laisse créer les vôtres avec register_rest_route().

Exemple : un endpoint qui retourne les 5 articles les plus lus (si vous avez un compteur de vues) :

add_action('rest_api_init', function() {
    register_rest_route('mon-plugin/v1', '/populaires', array(
        'methods' => 'GET',
        'callback' => function() {
            $posts = get_posts(array(
                'meta_key' => 'post_views',
                'orderby' => 'meta_value_num',
                'order' => 'DESC',
                'posts_per_page' => 5
            ));
            return array_map(function($post) {
                return array(
                    'id' => $post->ID,
                    'title' => $post->post_title,
                    'slug' => $post->post_name,
                    'views' => get_post_meta($post->ID, 'post_views', true)
                );
            }, $posts);
        },
        'permission_callback' => '__return_true'
    ));
});

L’endpoint est alors accessible sur /wp-json/mon-plugin/v1/populaires. C’est la base de toutes les extensions REST : WooCommerce, Yoast SEO, et quasiment tous les plugins modernes exposent leurs propres endpoints.

Comment sécuriser l’API REST de votre site WordPress ?

L’API REST est une surface d’attaque. On l’oublie trop souvent, mais par défaut, WordPress expose des informations que vous ne voulez peut-être pas rendre publiques. Et combinée aux failles de sécurité des plugins… le risque est réel.

Les risques concrets :

• /wp/v2/users expose la liste des utilisateurs (noms, slugs). Un attaquant peut récupérer les identifiants pour une attaque brute force
• Les endpoints non protégés peuvent être utilisés pour du scraping massif de contenu
• Sans rate limiting, l’API peut être abusée pour du DDoS applicatif

Ce que tu devrais faire :

1. Restreindre /wp/v2/users : soit le désactiver si vous n’en avez pas besoin, soit le limiter aux utilisateurs authentifiés
2. Limiter les namespaces exposés : chaque extension installée ajoute son propre namespace, et la liste s’allonge sans que vous vous en rendiez compte. Tapez votresite.com/wp-json/ et lisez le tableau namespaces en haut de la réponse : c’est l’inventaire réel de ce que votre site expose. Faites-le maintenant, le résultat surprend souvent. Ne gardez ensuite que ce qui vous sert, via un mu-plugin si besoin
3. Ajouter du rate limiting : WordPress n’a pas de rate limiting natif. Utilisez un plugin de sécurité WordPress ou configurez-le au niveau du serveur (mod_evasive, fail2ban)
4. Surveiller les logs : les requêtes API apparaissent dans les logs serveur. Surveillez les patterns anormaux (milliers de GET /wp/v2/posts en quelques minutes)

WPGraphQL : l’alternative à connaître

GraphQL est un langage de requête développé par Facebook en 2012, rendu open source en 2015. Au lieu de multiples endpoints REST, GraphQL utilise un seul endpoint où vous décrivez exactement les données que vous voulez.

WPGraphQL (v2.17.0) est le plugin qui ajoute GraphQL à WordPress. Maintenu par Jason Bahl, il est très utilisé dans l’écosystème headless et reste le standard de facto pour les projets Faust.js et Atlas.

Exemple : récupérer le titre et le slug des 5 derniers articles :

query {
  posts(first: 5) {
    nodes {
      title
      slug
      date
    }
  }
}

REST API vs GraphQL, lequel choisir ?

• REST API : natif (aucun plugin), plus simple à comprendre, mieux documenté, compatible avec tout (Zapier, Make, scripts shell). Le choix par défaut
• WPGraphQL : plus efficace pour les front-ends complexes (une seule requête au lieu de 5), typage fort, meilleure introspection. Le choix pour les projets headless ambitieux

Sur wpformation.com, je préfère l’API REST classique : plus simple à déboguer, mieux documentée. Pour un site headless avec des pages complexes nécessitant des données croisées (article + auteur + catégories + articles liés en une seule requête), WPGraphQL devient plus pertinent.

Comment tester l’API REST avec Postman ou curl ?

Pour débuter, pas besoin de coder. Deux outils suffisent :

1. Votre navigateur : tapez votresite.com/wp-json/wp/v2/posts dans la barre d’adresse. Vous verrez le JSON brut des articles. C’est moche mais ça prouve que l’API fonctionne.

2. Postman (gratuit) : une interface graphique pour envoyer des requêtes HTTP. Importez l’URL de base, configurez l’authentification (Basic Auth avec votre Application Password), et testez GET, POST, PUT, DELETE visuellement.

3. curl en ligne de commande : pour les adeptes du terminal. Simple, rapide, scriptable :

# Lire les 3 derniers articles (public, pas d'auth)
curl -s "https://monsite.com/wp-json/wp/v2/posts?per_page=3&_fields=id,title,slug"

# Créer un brouillon (authentifié)
curl -X POST "https://monsite.com/wp-json/wp/v2/posts" \
  -u "user:xxxx xxxx xxxx xxxx xxxx xxxx" \
  -H "Content-Type: application/json" \
  -d '{"title":"Test API","content":"Contenu test","status":"draft"}'

Bref. En 10 minutes avec curl, vous savez si votre API fonctionne, si l’authentification est en place, et ce que retournent vos endpoints. Personnellement, je commence toujours par curl avant de passer à Postman ou au code. C’est la première étape avant tout développement.

Les pièges à éviter

Après des années d’utilisation quotidienne de l’API REST WordPress, voici les erreurs qui font perdre des heures :

1. Oublier le Content-Type. Pour les requêtes POST/PUT, le header Content-Type: application/json est obligatoire. Sans lui, WordPress ne parse pas le body JSON et retourne une erreur 400 cryptique.

2. Ne pas utiliser _fields. Récupérer 100 articles avec tout le contenu HTML quand vous n’avez besoin que des titres, c’est envoyer plusieurs mégaoctets pour rien : 6,3 Mo sur mon site, contre 15 Ko avec _fields. Utilisez-le systématiquement.

3. Ignorer la pagination. L’API retourne 10 résultats par défaut (per_page=10), maximum 100. Pour récupérer tous les articles d’un site de 300+ articles, il faut paginer (paramètre page). Les headers de réponse X-WP-Total et X-WP-TotalPages donnent le total.

4. Confondre slug et ID. L’API utilise les IDs numériques, pas les slugs. Pour récupérer un article par slug, utilisez : /wp/v2/posts?slug=mon-article. Ça retourne un tableau (pas un objet), même si un seul article correspond.

5. Trop de requêtes. Les hébergeurs, les mutualisés en tête, ont un pare-feu qui prend une rafale de requêtes pour une attaque par force brute. Ça m’est arrivé sur mon propre site : un script lancé en boucle sur mon API, et mon adresse IP fixe bannie dans la foulée. Plusieurs heures pour reprendre la main, et un ticket au support. Espacez les requêtes, utilisez per_page=100 pour en faire moins, et regroupez les opérations.

L’API REST, c’est un peu comme un passage secret dans WordPress… une fois qu’on l’a trouvé, on ne peut plus s’en passer. En 2026, que ce soit pour un projet headless, de l’automatisation ou simplement pour comprendre comment WordPress fonctionne sous le capot, cette API est le socle sur lequel tout repose. Commencez par un simple GET dans votre navigateur, et le reste suivra.

Questions fréquentes sur l’API REST WordPress

L’API REST WordPress est-elle activée par défaut ?

Oui. L’API REST est intégrée au cœur de WordPress depuis la version 4.7 (décembre 2016). Elle est activée par défaut et accessible sur /wp-json/wp/v2/. Gutenberg, le Customizer et de nombreux plugins modernes en dépendent. La désactiver complètement casserait ces fonctionnalités. Si vous voulez la restreindre, limitez les endpoints sensibles (comme /wp/v2/users) plutôt que de tout bloquer.

Comment authentifier les requêtes API REST WordPress ?

La méthode recommandée en 2026 est les Application Passwords, intégrés nativement depuis WordPress 5.6. Créez un mot de passe d’application dans votre profil utilisateur (wp-admin > Utilisateurs > Profil), puis utilisez l’authentification Basic HTTP (user:motdepasse encodé en base64). Pour les appels côté client (JavaScript), utilisez le nonce WordPress (X-WP-Nonce). Pour les applications mobiles, JWT (via un plugin) est une alternative.

Quelle est la différence entre l’API REST et WPGraphQL ?

L’API REST est native (aucun plugin requis), utilise des endpoints multiples (/posts, /pages, /media) et retourne des structures JSON fixes. WPGraphQL est un plugin qui ajoute un endpoint unique où vous décrivez exactement les données voulues en une seule requête. REST est plus simple et mieux documenté. GraphQL est plus efficace pour les front-ends complexes qui combinent plusieurs types de données. Pour débuter, REST suffit largement.

L’API REST WordPress est-elle sécurisée ?

Par défaut, l’API expose certaines informations publiquement (liste des utilisateurs, contenu publié). Les données sensibles (brouillons, réglages) nécessitent une authentification. Pour renforcer la sécurité : restreignez l’endpoint /wp/v2/users aux utilisateurs authentifiés, ajoutez du rate limiting (au niveau serveur ou via un plugin de sécurité), et limitez les namespaces exposés aux seuls endpoints nécessaires. Ne désactivez pas l’API complètement.

Peut-on créer des endpoints personnalisés avec l’API REST ?

Oui. La fonction register_rest_route() crée des endpoints personnalisés dans un plugin ou un mu-plugin. Vous définissez le namespace (ex: mon-plugin/v1), la route (ex: /populaires), la méthode HTTP (GET, POST, etc.), la fonction callback et les permissions. C’est la même API que celle utilisée par WooCommerce, Yoast SEO et tous les plugins modernes.

Comment utiliser l’API REST pour un site WordPress headless ?

Un site WordPress headless utilise WordPress comme back-end (gestion de contenu) et un framework JavaScript (Next.js, Nuxt, Astro) comme front-end. Le front-end récupère les données via l’API REST (/wp/v2/posts, /wp/v2/pages, etc.) et les affiche avec ses propres templates. Les avantages : performances supérieures, flexibilité du front-end, meilleur contrôle du HTML/CSS. L’inconvénient : complexité de mise en place et perte de l’aperçu direct dans WordPress.

Le paramètre _fields améliore-t-il vraiment les performances ?

Oui, considérablement. Le paramètre _fields limite les champs retournés par l’API. Mesure faite sur wpformation.com en juillet 2026, sur une page de 100 articles : la réponse complète (contenu HTML inclus) prend environ 1,7 seconde et pèse 6,3 Mo. Avec _fields=id,title,slug, la même requête tombe à environ 0,25 seconde et 15 Ko. C’est le premier réflexe d’optimisation à avoir quand vous utilisez l’API REST.

WordPress 7.0 apporte-t-il des nouveautés pour l’API REST ?

WordPress 7.0, sorti le 20 mai 2026, a renforcé l’éditeur de blocs et le Full Site Editing (la collaboration temps réel un temps annoncée a finalement été reportée à un cycle ultérieur). Côté API REST elle-même, rien de spectaculaire : elle reste stable et rétrocompatible, ce qui est précisément sa grande force. La nouveauté qui change quelque chose pour un client API, c’est l’Abilities API, introduite en 6.9 et montée en puissance avec la 7.0 : elle expose ce que le site sait faire dans son propre namespace, wp-abilities/v1, ce qui permet à un client (ou à une IA) de découvrir les capacités disponibles au lieu de les deviner. La 7.0 ajoute aussi l’écran Connecteurs et le client IA natif, que je détaille dans mon article sur WordPress 7.

Article original sur WPFormation