Une équipe technique qui souhaite exposer une partie de son contenu multilingue à une application mobile, sans pour autant réécrire l’intégralité du site en headless, se heurte historiquement à un problème récurrent avec WPML : faire correspondre proprement la langue demandée par le client à la bonne version traduite du contenu via l’API REST de WordPress. Les évolutions récentes de l’extension simplifient sensiblement ce cas d’usage intermédiaire, sans nécessiter un découplage complet du front-end.
Ce cas de figure, souvent qualifié de « headless partiel », concerne les équipes qui gardent WordPress comme moteur d’affichage principal du site public, tout en exposant certains contenus via l’API REST pour une application mobile, un widget externe ou un service tiers consommant les données multilingues sans passer par le rendu HTML classique.
Le problème historique : la langue de la requête REST
Par défaut, l’API REST de WordPress ne connaît rien de la notion de langue introduite par WPML. Une requête vers /wp-json/wp/v2/posts/42 renvoie systématiquement le contenu de l’article portant cet identifiant précis, sans tenir compte d’une éventuelle préférence linguistique du client consommant l’API. Obtenir la version allemande d’un contenu supposait, jusqu’ici, de connaître à l’avance l’identifiant spécifique de la traduction allemande, ce qui suppose déjà de résoudre la correspondance entre langues côté client.
Les développeurs contournaient généralement ce problème en appelant la fonction wpml_object_id via un filtre personnalisé enregistré sur l’API REST, une solution fonctionnelle mais qui demandait un développement sur mesure non négligeable pour chaque projet.
Ce que permet désormais un simple en-tête HTTP
Avec les versions récentes de WPML, il devient possible de transmettre la langue souhaitée directement via un en-tête HTTP de la requête REST, sans développement additionnel côté serveur. WPML intercepte cette information et adapte la résolution du contenu retourné à la langue demandée, de façon comparable à ce que fait déjà le sélecteur de langue côté navigateur pour l’affichage classique du site.
curl https://exemple.fr/wp-json/wp/v2/posts/42 \
-H "Accept-Language: de"
Ce type d’appel, une fois la prise en charge activée dans la configuration de l’extension, renvoie directement le contenu de la traduction allemande de l’article 42 si elle existe, sans que le client ait besoin de connaître au préalable l’identifiant spécifique de cette traduction dans la base de données.
Ce que cela ne remplace pas
Cette évolution simplifie la résolution de langue au niveau de la requête individuelle ; elle ne transforme pas WPML en solution de headless complet. Les métadonnées de structure du site — menus, taxonomies liées, réglages globaux — restent gérées côté administration WordPress classique, et un client headless souhaitant les exploiter doit toujours composer plusieurs appels API distincts, comme c’était déjà le cas avant cette évolution.
- La langue peut désormais être transmise sans développement sur mesure côté serveur.
- Le contenu individuel se résout correctement, mais la structure globale reste à composer manuellement.
- Un headless partiel reste préférable à un développement headless complet pour une majorité de projets multilingues.
Un cas d’usage concret : l’application mobile compagnon
Sur un projet éditorial ayant adopté cette approche, une application mobile compagnon consomme désormais directement l’API REST du site WordPress multilingue pour afficher les derniers articles, en transmettant la langue de l’appareil du lecteur via l’en-tête HTTP. Avant cette évolution, il aurait fallu développer un point de terminaison personnalisé faisant explicitement appel à wpml_object_id pour chaque requête, un développement que l’équipe avait reporté faute de ressources.
Un headless partiel bien pensé résout 80 % des besoins d’une application compagnon sans jamais toucher à l’architecture d’affichage principale du site.
Ce qu’il reste à surveiller
La cohérence des identifiants de traduction demeure le point de vigilance principal de cette approche. Si une traduction est supprimée ou dépubliée sans que son lien avec l’original soit correctement nettoyé dans les tables internes de WPML, la résolution de langue via l’API REST peut renvoyer une erreur 404 inattendue côté client, sans message d’erreur explicite sur la cause réelle du problème.
| Besoin | Solution adaptée |
|---|---|
| Exposer un article dans la bonne langue | En-tête HTTP de langue via l’API REST |
| Exposer toute la structure du site (menus, réglages) | Développement headless complet toujours nécessaire |
Notre verdict
Cette évolution de WPML ne remplace pas une architecture headless complète pour les équipes qui en ont réellement besoin, mais elle évite un développement sur mesure coûteux à la majorité des projets qui n’ont besoin d’exposer qu’une partie de leur contenu multilingue via l’API REST. C’est précisément le public le plus large concerné par cette question, et c’est une bonne nouvelle pour lui.
