« Nonce verification failed » — ce message, familier de tout développeur WordPress qui a déjà déboggé un formulaire, prend une tournure différente lorsqu’il provient d’un agent IA connecté via un client MCP plutôt que d’un navigateur classique. Le nonce est généré correctement, transmis correctement, et pourtant l’appel échoue systématiquement une fois qu’un certain délai s’est écoulé entre la génération et l’utilisation.
Ce symptôme révèle une incompatibilité de conception : le mécanisme de nonce de WordPress a été pensé pour une interaction humaine, généralement close en quelques minutes entre le chargement d’un formulaire et sa soumission. Un client MCP asynchrone, qui peut mettre une action en file d’attente avant de l’exécuter, dépasse régulièrement cette hypothèse implicite.
Comment fonctionne la fenêtre de validité d’un nonce
Un nonce généré par wp_create_nonce() reste valide, selon la configuration par défaut, pendant deux « ticks » de douze heures chacun : la vérification via wp_verify_nonce() retourne 1 si le nonce a été généré dans le tick courant, 2 s’il provient du tick précédent, et false au-delà. Concrètement, un nonce peut rester valide entre douze et vingt-quatre heures selon le moment précis de sa génération à l’intérieur du cycle.
$resultat = wp_verify_nonce($nonce, 'action_agent_ia');
if ($resultat === 1) {
// Généré dans le tick courant
} elseif ($resultat === 2) {
// Généré dans le tick précédent, encore valide
} else {
// false : le nonce a expiré ou n'a jamais été valide
wp_die(esc_html__('Nonce verification failed', 'mon-plugin'));
}
Pourquoi un client MCP dépasse plus souvent cette fenêtre
Un agent connecté à un site via un serveur MCP peut recevoir une instruction de l’utilisateur, la mettre en file d’attente pour exécution différée (attente d’une validation humaine, exécution planifiée à un horaire précis, traitement par lots), puis tenter d’exécuter l’action des heures voire des jours plus tard. Si le nonce a été généré au moment de la réception de l’instruction plutôt qu’au moment de l’exécution réelle, la fenêtre de validité de vingt-quatre à quarante-huit heures se révèle souvent insuffisante pour ce type de flux.
Ne pas simplement allonger la durée de vie du nonce
Le filtre nonce_life permet techniquement d’allonger la durée de validité d’un nonce au-delà de la valeur par défaut. Cette solution, tentante en apparence, affaiblit la protection contre le rejeu que le nonce est censé apporter : un nonce valide plus longtemps reste exploitable plus longtemps en cas de fuite, ce qui déplace le problème plutôt que de le résoudre.
Régénérer le nonce au moment de l’exécution
La correction la plus robuste consiste à séparer la réception de l’instruction et son exécution : le nonce ne devrait être généré qu’immédiatement avant l’appel réel à l’ability ou à la route REST, jamais au moment où l’instruction est reçue par l’agent. Pour un client MCP qui gère une file d’attente, cela signifie que la génération du nonce doit faire partie de l’étape d’exécution elle-même, pas de l’étape de planification.
- Séparer clairement la planification d’une action de son exécution effective dans l’architecture de l’agent
- Générer le nonce (ou le jeton d’autorisation équivalent) juste avant l’appel réel, jamais en avance
- Pour les actions différées de plus de quelques heures, envisager un jeton d’application dédié plutôt qu’un nonce, mécanisme mieux adapté à ce cas d’usage
Le cas des actions différées de plusieurs jours
Pour une action planifiée plusieurs jours à l’avance, le nonce n’est simplement pas l’outil adapté : un mot de passe d’application, associé à une vérification de capacité au moment de l’exécution plutôt qu’à un jeton à courte durée de vie, correspond mieux à ce contexte. Le nonce protège contre le rejeu d’une action humaine rapprochée dans le temps ; il n’a jamais été conçu comme un mécanisme d’autorisation de longue durée.
Un « nonce verification failed » qui survient systématiquement après un délai précis n’est pas un bug à corriger dans le nonce lui-même : c’est un signal que le mécanisme choisi ne correspond pas au rythme réel de l’appel.
En résumé
Le mécanisme de nonce de WordPress reste parfaitement adapté à une interaction humaine rapprochée dans le temps, mais un client MCP qui met une action en attente avant de l’exécuter dépasse régulièrement sa fenêtre de validité de vingt-quatre à quarante-huit heures. Plutôt que d’allonger cette fenêtre au détriment de la protection contre le rejeu, la bonne réponse consiste à générer le nonce au moment réel de l’exécution, ou à choisir un mécanisme d’autorisation mieux adapté aux délais longs pour les actions différées.
