5.5API REST & WordPress headless (notions)
L'essentiel en 30 secondes
- L'API REST expose le contenu WordPress en JSON : /wp-json/wp/v2/posts renvoie déjà les articles.
- Le headless utilise WordPress comme back-end de contenu, avec un front séparé (React, Next.js, application mobile).
- Avantages : liberté du front et diffusion multi-canal ; contreparties : complexité, perte de l'aperçu et de nombreuses extensions front.
Mini-cas filé — faut-il passer l'atelier en headless ?
Un développeur propose à Hassan un site headless « plus moderne ». Samir examine le besoin réel : une vitrine et une petite boutique, sans application mobile ni multi-canal. Il conclut que le WordPress classique reste plus simple et moins coûteux. Il montre quand même l'API REST à Hassan pour illustrer l'ouverture possible vers une application de visite guidée, sans engager la refonte.
Suite du cas 5.4 — connaître les possibles sans sur-vendre.
1. L'API REST en pratique
WordPress intègre une API REST : une interface qui expose les contenus et certaines actions en JSON, un format lisible par d'autres applications. En ouvrant /wp-json/wp/v2/posts sur un site, on obtient déjà la liste des articles. C'est la même technologie qui alimente l'éditeur de blocs et de nombreuses intégrations.
Cette API permet à une application externe — site front, application mobile, tableau de bord — de lire ou de publier du contenu. Samir peut l'utiliser pour connecter un outil, sans refondre le site. Il vérifie quels endpoints sont publics et lesquels exigent une authentification.
2. Headless : promesse et contreparties
Le WordPress headless sépare le back-end de contenu du front qui l'affiche. On garde WordPress pour gérer les articles et les médias, et on affiche via React, Next.js ou une application mobile. Avantages : liberté totale du front, performance possible, diffusion du même contenu sur plusieurs canaux.
Les contreparties sont réelles : il faut deux compétences (WordPress + front), gérer l'aperçu, les formulaires, le SEO, le cache et les extensions qui dépendent du front. Pour la majorité des sites, le WordPress classique reste plus simple et moins cher. Le headless se justifie pour des projets qui ont un vrai besoin multi-canal ou une équipe technique.
🔎 Exemple concret — Une application de visite guidée (cas Samir)
Besoin réel : une app mobile pour visiter l'atelier.
WordPress reste le back-end de contenu.
API REST : /wp-json/wp/v2/realisations.
Application : lit les fiches en JSON.
Vitrine classique conservée pour le web.
→ Pas de refonte headless du site entier.Résultat : un usage ciblé de l'API, sans refonte coûteuse.
Leçon : on choisit l'architecture selon le besoin.
Vocabulaire de la section
- API REST
- Interface qui expose les contenus et actions de WordPress en JSON.
Exemple simple : /wp-json/wp/v2/posts.
Ce que ce n'est pas : croire qu'elle est réservée aux développeurs.
Réflexe : API = porte d'entrée des données.
- JSON
- Format de données léger, lisible par les applications.
Exemple simple : la réponse de l'API liste les articles.
Ce que ce n'est pas : confondre JSON et HTML.
Réflexe : JSON = données structurées.
- Headless
- Architecture où WordPress fournit le contenu et un front séparé l'affiche.
Exemple simple : un front React sur l'API WordPress.
Ce que ce n'est pas : croire que headless est toujours plus performant.
Réflexe : headless = back et front séparés.
- Endpoint
- Adresse précise de l'API qui renvoie une ressource.
Exemple simple : l'endpoint des réalisations.
Ce que ce n'est pas : exposer des données sensibles sans contrôle.
Réflexe : vérifier droits et visibilité.
- Authentification API
- Mécanisme qui protège les endpoints non publics.
Exemple simple : une clé d'application pour publier.
Ce que ce n'est pas : laisser l'écriture ouverte à tous.
Réflexe : les actions sensibles exigent une auth.
En pratique — Explorer l'API sans refondre
- Ouvrez /wp-json/wp/v2/posts sur un site de test et observez la réponse JSON.
- Repérez un endpoint utile et vérifiez s'il est public ou protégé.
- Notez ce qu'un front séparé devrait gérer : aperçu, formulaires, SEO, cache.
- Comparez avec un site classique et décidez ce qui est réellement justifié.
Script prêt à dire — recadrer le headless (25 s)
« Le headless est puissant pour une application mobile ou plusieurs canaux, mais il double la complexité et le coût. Pour votre vitrine et votre boutique, le WordPress classique reste plus simple. On peut utiliser l'API pour un usage précis sans tout reconstruire. »
Parler besoin avant technologie : c'est le rôle du conseil.
Modèle copier-coller — décision headless
BESOIN MULTI-CANAL RÉEL : oui / non
APPLICATION MOBILE PRÉVUE : oui / non
ÉQUIPE FRONT DISPONIBLE : oui / non
APERÇU / FORMULAIRES / SEO À REPENSER : _______________
ENDPOINTS PUBLICS VÉRIFIÉS : oui / non
DÉCISION : WordPress classique / headless / API cibléeSite vitrine
WordPress classique ; API seulement pour une intégration.
Application mobile
API REST + front mobile, back-end WordPress.
Multi-canal
Un contenu, plusieurs fronts : web, app, bornes.
Équipe technique
Headless avec front React/Next.js et CI/CD.
✓ Bonnes pratiques
- Partir du besoin avant de choisir l'architecture.
- Vérifier quels endpoints sont publics.
- Protéger l'écriture par une authentification.
✗ Pièges fréquents
- Choisir headless par mode.
- Laisser l'API ouverte sans contrôle.
- Oublier aperçu, formulaires et SEO dans le front séparé.
Points clés à retenir
- L'API REST expose le contenu WordPress en JSON.
- Le headless sépare le back-end de contenu du front.
- Avantages de liberté, contreparties de complexité.
- La sécurité des endpoints est indispensable.
Défi 48h — appliquez demain
Ouvrez l'API d'un site de test, repérez un endpoint public et un endpoint protégé, puis listez ce qu'un front headless devrait gérer. 25 minutes.
- Je comprends ce qu'expose l'API REST.
- Je sais expliquer headless et ses contreparties.
- Je vérifie la sécurité des endpoints.
Questions fréquentes
Le headless est-il l'avenir de WordPress ?
C'est une voie adaptée à certains projets — fort trafic, front sur mesure, multi-canal, équipe technique — pas une nécessité générale. Pour la majorité des sites, le WordPress classique reste plus simple, moins cher et performant avec le cache.
Faut-il savoir programmer pour faire du headless ?
Oui, nettement plus que pour un WordPress classique : le front séparé demande des compétences de développeur web. Cette section est une initiation aux notions, pour savoir quand cela vaut le coup, pas un tutoriel de mise en œuvre.
L'API REST est-elle accessible à tous ?
Certains endpoints de lecture sont publics, d'autres exigent une authentification. Les actions d'écriture doivent être protégées. Il faut vérifier la configuration et ne jamais exposer de données sensibles.
Qu'est-ce que le WordPress « headless » ?