# Des jetons API plus précis en WordPress 7.0 pour restreindre un accès headless > WordPress 7.0 affine le système de jetons d'application : voici les nouveautés classées par impact pour restreindre un accès headless en lecture seule. - Auteur : Clément Hadrot - Publié le : 2026-04-27 - Mis à jour le : 2026-04-27 - Catégorie : Headless & API - URL : https://wpmoderne.dev.wordpress-developpement.fr/headless/jetons-api-precis-wordpress-7-0-headless/ ## L’essentiel - Les jetons peuvent désormais restreindre l'accès à des routes précises - Une expiration configurable réduit le risque d'un jeton oublié - La rétrocompatibilité avec les anciens jetons est conservée « Ce jeton d'application a-t-il vraiment besoin d'écrire dans WordPress, ou seulement de lire le catalogue ? » Cette question, posée depuis l'introduction des mots de passe d'application avec WordPress 5.6, restait jusqu'ici sans réponse satisfaisante : un jeton généré donnait accès à tout ce que le compte associé pouvait faire, sans granularité possible. WordPress 7.0 change cette donne avec un système de jetons d'application capable de restreindre l'accès à des routes précises de l'API REST. Pour un projet headless en lecture seule, cette évolution répond à un besoin ancien : donner à un front, ou à un service tiers, uniquement le droit de lire certains contenus, sans jamais exposer la possibilité de créer, modifier ou supprimer quoi que ce soit, même si le compte associé au jeton dispose par ailleurs de droits plus larges dans l'interface d'administration. ## Ce qui change, classé par impact Trois nouveautés se démarquent particulièrement pour un accès headless : ### Restriction par route : l'impact le plus direct Un jeton peut désormais être limité à un ensemble de routes précises de l'API REST, définies au moment de sa création. Un front qui n'a besoin que de lire le contenu des articles et des pages peut recevoir un jeton restreint à `wp/v2/posts` et `wp/v2/pages` en lecture seule, sans aucun accès aux routes utilisateurs ou aux réglages du site, même en cas de compromission du jeton lui-même. ### Expiration configurable : réduire le risque d'un jeton oublié > L'essentiel à retenir : Les jetons peuvent désormais restreindre l'accès à des routes précises ; Une expiration configurable réduit le risque d'un jeton oublié ; La rétrocompatibilité avec les anciens jetons est conservée Les mots de passe d'application, jusqu'ici, restaient valides indéfiniment sauf révocation manuelle. WordPress 7.0 permet de fixer une durée de validité au moment de la création du jeton, ce qui limite naturellement le risque d'un accès oublié depuis des années sur un projet dont plus personne ne se souvient de l'existence. ### Un journal d'utilisation par jeton Chaque jeton conserve désormais un horodatage de dernière utilisation et un compteur d'appels, visible depuis le profil de l'utilisateur associé. Un jeton jamais utilisé depuis des mois devient repérable en un coup d'œil, plutôt que de rester invisible parmi une liste de jetons actifs sans historique. ## Créer un jeton restreint en pratique ``` wp user application-password create 12 "Front headless catalogue" \ --restrict-to=wp/v2/posts,wp/v2/pages \ --read-only \ --expires=90 ``` Cette commande, exécutée via WP-CLI, crée un jeton limité en lecture seule aux deux routes indiquées, avec une expiration fixée à quatre-vingt-dix jours, obligeant à renouveler l'accès plutôt que de le laisser filer indéfiniment. ## La rétrocompatibilité avec les jetons existants Les jetons créés avant WordPress 7.0 continuent de fonctionner sans restriction supplémentaire, exactement comme avant la mise à jour. Aucune migration forcée n'est imposée : la restriction par route ne s'applique qu'aux nouveaux jetons créés après l'installation de cette version, ce qui laisse le temps de revoir progressivement les accès existants plutôt que de risquer une coupure brutale d'un service en production. - Un jeton ancien garde son comportement d'origine, sans restriction de route. - Un nouveau jeton peut être créé en parallèle avec des permissions plus fines, puis substitué progressivement à l'ancien. - La révocation d'un jeton reste immédiate, comme auparavant. ## Ce que cette évolution ne couvre pas Ce mécanisme ne remplace pas un système d'authentification complet de type OAuth, pensé pour des scénarios où plusieurs applications tierces doivent s'authentifier au nom d'utilisateurs différents avec des flux de consentement explicites : il s'agit ici d'un jeton unique, associé à un compte unique, avec des permissions désormais plus fines qu'auparavant. > Un accès en lecture seule qui ne peut techniquement pas écrire vaut toujours mieux qu'un accès en lecture seule qui repose uniquement sur la discipline de celui qui l'utilise. ## Un point de vigilance à surveiller après la mise à jour La restriction par route ne protège que ce qui est explicitement listé au moment de la création du jeton : ajouter un nouvel endpoint personnalisé après coup, sans revoir la liste des routes autorisées pour les jetons déjà émis, ne les fait pas automatiquement en bénéficier ni en pâtir. Il reste nécessaire de revoir périodiquement la portée de chaque jeton actif à mesure que l'API du projet évolue, plutôt que de considérer la restriction comme un réglage figé une fois pour toutes. ## Notre verdict La restriction par route est la nouveauté la plus utile pour un projet headless : elle permet enfin de délivrer un accès strictement proportionné au besoin réel du front, sans attendre un système d'authentification plus lourd à mettre en place.