WordPress headless : un seul back-office pour votre site et vos apps iOS et Android

Votre équipe connaît WordPress. Vos contenus, vos produits et vos clients y sont déjà. Le jour où vous lancez une application mobile, la pire option serait de créer un second back-office à tenir à jour en parallèle. Avec WordPress headless, WordPress devient la source unique : il gère les contenus et les comptes, et une API les sert au site comme aux applications. C’est ma spécialité : « un seul back-office, deux plateformes ». Je suis Landry Caleyron, fondateur d’AppliWin, prestataire WordPress et développeur Flutter : je conçois donc les deux côtés de l’API, ce qui évite les malentendus entre deux prestataires.

WordPress headless : la définition simple

Un WordPress headless, ou découplé, sépare le back-office de l’affichage. WordPress sert uniquement à saisir et stocker les contenus ; une application mobile, un site Next.js ou Astro les récupère via une API REST ou GraphQL et les affiche à sa façon. Une même base de contenus peut ainsi alimenter plusieurs interfaces : c’est le modèle que j’ai mis en place chez AppliWin pour LSF-CFB.

Dans un WordPress classique, le thème génère les pages HTML. Dans un WordPress headless, le thème disparaît ou presque : WordPress répond à des requêtes en JSON. Entre les deux, il existe une voie hybride, souvent la plus raisonnable : le site reste un WordPress classique, rapide et bien référencé, et l’API alimente en plus vos applications iOS et Android. C’est l’architecture que je recommande le plus souvent.

Headless ou classique : le comparatif

Le WordPress classique est plus simple, moins cher et parfait pour un site seul. Le headless se justifie quand plusieurs interfaces partagent les mêmes contenus, ou quand le front exige une technologie précise. L’hybride combine les deux : site WordPress classique et API pour les applications, sans dupliquer le back-office.

Critère	Classique	Hybride (site + API)	Headless pur
Site web	Thème WordPress	Thème WordPress	Front séparé (Next.js, Astro)
Applications mobiles	Non	Oui, via l’API	Oui, via l’API
Bases de code à maintenir	Une	Deux (site, app)	Deux ou trois
Aperçu et édition visuelle	Natifs	Natifs pour le site	À reconstruire
SEO	Direct	Direct pour le site	Dépend du rendu côté serveur
Cas typique	Site vitrine, blog	Site et application e-learning ou e-commerce	Plateforme multi-supports, front très spécifique

Un back-office pour votre site et vos applications

Avec un back-office unique, un contenu publié dans WordPress apparaît en même temps sur le site, dans l’application iOS et dans l’application Android. Les comptes utilisateurs, les achats et les droits d’accès sont partagés : un client qui s’abonne sur le site retrouve son abonnement dans l’app, sans double saisie ni synchronisation fragile.

Pour vous, cela change tout au quotidien : une seule interface à apprendre, un seul endroit où corriger une coquille, une seule base de clients. WordPress apporte ce qu’il fait de mieux, à savoir la gestion des contenus, des médias, des rôles et, avec une boutique WooCommerce, des commandes et des paiements. L’application apporte ce que le web fait moins bien : notifications push, mode hors ligne, accès en un geste. Le détail côté mobile est sur la page consacrée à l’application mobile connectée à votre WordPress.

API REST sur mesure : endpoints, JWT et sécurité

L’API REST native de WordPress expose les contenus standards, mais une application a besoin de réponses taillées pour ses écrans. Je crée des routes dédiées, versionnées, qui renvoient exactement les données utiles, protégées par une authentification par jeton, une vérification des droits sur chaque route et une validation stricte des paramètres.

Des endpoints pensés pour les écrans

Plutôt que d’obliger l’application à enchaîner dix requêtes génériques, je regroupe les données d’un écran en une réponse légère : un catalogue de cours avec la progression de l’utilisateur, une fiche produit avec ses variations et son stock. Les routes vivent dans un espace de noms versionné, comme /v1/, ce qui permet de faire évoluer l’API sans casser les applications déjà installées sur les téléphones. Elles sont regroupées dans une extension indépendante du thème : un cas typique de création de plugin WordPress sur mesure, qui survit à un changement de design.

Authentification : JWT ou mots de passe d’application

Pour les utilisateurs d’une application mobile, j’utilise des jetons signés (JWT ou équivalent) envoyés dans l’en-tête Authorization, avec une durée de vie limitée et un renouvellement contrôlé. Les mots de passe d’application, intégrés à WordPress, conviennent aux échanges entre serveurs, par exemple pour un outil interne, mais pas aux comptes clients.

• HTTPS partout, sans exception.
• Une fonction de permission sur chaque route, qui vérifie les droits réels de l’utilisateur.
• Des paramètres validés et assainis à l’entrée, des données échappées à la sortie.
• Une limitation des tentatives de connexion et des requêtes abusives.
• Aucune donnée sensible exposée par défaut, et la liste des utilisateurs fermée au public.
• Des origines autorisées (CORS) limitées aux domaines de vos interfaces.

Cache et webhooks

Les réponses publiques sont mises en cache côté serveur et côté réseau, avec une invalidation automatique quand vous modifiez un contenu. Les événements importants peuvent déclencher des webhooks. Quelques exemples courants : une nouvelle leçon publiée envoie une notification push aux abonnés, une commande WooCommerce prévient votre outil de gestion, une mise à jour régénère les pages d’un front statique.

REST ou WPGraphQL ?

L’API REST est native, simple à mettre en cache et idéale pour une application mobile avec des routes sur mesure. WPGraphQL, une extension, permet au front de demander exactement les champs voulus en une requête, ce qui séduit les projets Next.js complexes. Pour une application Flutter, je privilégie presque toujours REST.

Le choix n’est pas idéologique. GraphQL brille quand plusieurs équipes front interrogent des contenus très reliés entre eux. REST l’emporte quand on maîtrise les deux côtés de l’API, ce qui est mon cas, et quand le cache HTTP compte, ce qui est le cas de toute application grand public. Les deux peuvent d’ailleurs cohabiter sur le même WordPress.

Le front : Flutter, Next.js ou Astro

Pour les applications iOS et Android, j’utilise Flutter : un seul code, deux stores, des performances natives. Pour un site découplé, Next.js convient aux interfaces très dynamiques, et Astro aux sites de contenu qui doivent être ultra légers. Dans beaucoup de cas, un thème WordPress sur mesure reste le meilleur front web.

Flutter est au cœur de mon activité : je l’utilise pour toutes les applications que je développe. Je détaille ce choix sur la page développeur Flutter freelance. Pour le web, j’évite de découpler par principe : un thème WordPress sur mesure bien écrit est rapide, bien référencé et garde l’aperçu natif de l’éditeur.

Quand le headless n’est pas pertinent

Le headless pur n’a pas d’intérêt pour un site vitrine seul, un blog ou un petit budget : il double les bases de code, complique l’aperçu des contenus et oblige à reconstruire ce que WordPress fait seul, comme les formulaires, le SEO ou les redirections. Je le déconseille dans ces cas, même s’il est à la mode.

• Vous n’avez qu’un site web, sans application ni autre interface prévue.
• Votre équipe a besoin de l’aperçu visuel et de l’édition directe des pages.
• Le budget ne permet pas de maintenir deux bases de code dans la durée.
• Le site dépend d’extensions qui agissent sur l’affichage, comme un constructeur de formulaires.

Étude de cas : LSF-CFB

LSF-CFB est une application d’apprentissage de la langue des signes française, en Flutter pour iOS, Android et le web, réalisée de janvier à avril 2026. Son back-office est un WordPress enrichi d’une API REST sur mesure : authentification, cours, abonnements, locations, favoris, gamification, forum, espace entreprise et paiements passent par des routes dédiées et versionnées.

L’application s’authentifie par jeton porteur (Bearer), lit le catalogue et vérifie les droits d’accès liés aux abonnements ou aux locations de 7, 30 ou 90 jours. Sur iPhone, chaque achat intégré est vérifié par WordPress auprès d’Apple avant d’ouvrir l’accès ; sur Android et sur le web, le paiement passe par Stripe. Côté serveur, une extension sur mesure fait ré-encoder chaque vidéo envoyée par le service Coconut, dans un format lisible par la grande majorité des téléphones Android. Le back-office d’apprentissage est décrit sur la page plateforme e-learning WordPress, et le projet complet dans l’étude de cas LSF-CFB.

SEO et headless : rendu serveur et sitemap

Un site headless peut être bien référencé, à condition que les pages soient rendues côté serveur ou générées à l’avance, et non construites dans le navigateur. Il faut aussi recréer côté front ce que WordPress faisait seul : balises title et meta, canonical, sitemap XML, données structurées, redirections et pages d’erreur.

C’est la principale source de mauvaises surprises : un front découplé livré sans sitemap, sans balises sociales ou avec des URL différentes de l’ancien site perd du trafic dès la mise en ligne. Avec une architecture hybride, la question ne se pose pas pour le site, qui reste un WordPress classique ; l’API ne sert que les applications, qui ne sont pas indexées de la même façon.

Coûts d’un projet WordPress headless

Le coût dépend du nombre de routes, de la complexité des droits d’accès et des interfaces à alimenter. À titre indicatif, le back-office WordPress sur mesure d’une application et son API représentent 1 500 à 4 000 € HT en option d’un projet d’application ; un front web découplé se chiffre en plus, sur devis.

Une API simple qui expose des contenus publics coûte peu. Une API qui gère des comptes, des paiements, des abonnements et des droits fins demande plus de conception et de tests. Mes autres fourchettes sont sur la page des tarifs WordPress. Pour aller plus loin côté technique, lisez le guide pour connecter une application Flutter à WordPress, ou décrivez votre projet de WordPress headless dans la demande de devis.

Questions fréquentes sur WordPress headless