# Ce qu’est réellement un contexte d’agent (agent context) pour WordPress

> Historique, permissions, état courant du site : ce qu'un agent reçoit réellement avant d'agir, et pourquoi le confondre avec un simple prompt cause des erreurs.

- Auteur : Clément Hadrot
- Publié le : 2026-07-07
- Mis à jour le : 2026-07-07
- Catégorie : IA & MCP
- URL : https://wpmoderne.dev.wordpress-developpement.fr/ia-mcp/contexte-agent-agent-context-wordpress/

## L’essentiel

- Le contexte inclut l'état du site, pas seulement l'instruction reçue
- Un prompt sans contexte à jour produit des décisions obsolètes
- Le contexte se reconstruit à chaque appel, il ne se mémorise pas indéfiniment

Une confusion revient régulièrement dans les projets où un agent doit agir sur un site WordPress : on parle de « prompt » quand on devrait parler de « contexte », et cette confusion mène directement à des décisions prises sur des informations obsolètes ou incomplètes. Ce n'est pas un glossaire général que nous voulons refaire ici, déjà publié ailleurs sur ce blog, mais une définition précise et opérationnelle de ce qu'un contexte d'agent doit réellement contenir pour agir correctement sur un site.

Comprendre cette distinction change concrètement la façon dont on conçoit un serveur MCP ou un outil exposé à un agent : un outil qui ne reconstruit pas correctement le contexte à chaque appel finit tôt ou tard par agir sur une image du site qui n'existe plus.

## Le prompt n'est qu'une des composantes du contexte

Le prompt est l'instruction ou la question posée à l'agent à un instant donné : « republie cet article », « résume les commentaires en attente ». Le contexte, lui, regroupe tout ce que l'agent sait ou peut consulter au moment de traiter cette instruction : l'historique de la conversation, les permissions dont il dispose, et l'état courant du site au moment précis de l'action, pas au moment où la conversation a commencé.

> L'essentiel à retenir : Le contexte inclut l'état du site, pas seulement l'instruction reçue ; Un prompt sans contexte à jour produit des décisions obsolètes ; Le contexte se reconstruit à chaque appel, il ne se mémorise pas indéfiniment

## Les quatre composantes d'un contexte d'agent

- **L'historique de la conversation** : les échanges précédents dans la même session, qui donnent son sens à une instruction courte comme « fais-le aussi pour les trois autres ».
- **Les permissions effectives** : ce que le compte associé à l'agent a réellement le droit de faire au moment de l'appel, pas ce qu'il pouvait faire lors d'une session antérieure.
- **L'état courant du site** : la version actuelle du contenu concerné, son statut, ses métadonnées, récupérés à l'instant de l'action, jamais mis en cache indéfiniment.
- **Les contraintes déclarées de l'outil** : le schéma d'entrée et de sortie qui borne ce que l'agent peut demander et ce qu'il recevra en retour.

## Pourquoi confondre prompt et contexte cause des erreurs

Un agent qui reçoit uniquement un prompt, sans reconstruire l'état courant du site avant d'agir, peut prendre une décision fondée sur une information périmée. Prenons un exemple concret : un agent chargé de republier un article dépublié « il y a une heure » selon la conversation, mais republié entre-temps par un membre de l'équipe éditoriale. Sans relecture de l'état courant juste avant l'action, l'agent republierait une seconde fois sur une base d'information fausse, avec un risque réel d'écraser une modification faite entre-temps.

```
// Contexte mal reconstruit : on suppose l'état sans le vérifier
function agence_republier_article( $article_id ) {
    wp_update_post( array( 'ID' => $article_id, 'post_status' => 'publish' ) );
    return 'republié';
}

// Contexte correctement reconstruit avant l'action
function agence_republier_article_securise( $article_id ) {
    $article = get_post( $article_id );

    if ( 'publish' === $article->post_status ) {
        return array(
            'action'  => 'aucune',
            'raison'  => 'Article déjà publié, aucune action nécessaire.',
        );
    }

    wp_update_post( array( 'ID' => $article_id, 'post_status' => 'publish' ) );
    return array( 'action' => 'republié' );
}
```

## Le contexte ne se mémorise pas indéfiniment

Un piège fréquent consiste à considérer le contexte comme quelque chose qu'on établit une fois en début de session, puis qu'on réutilise tel quel pour chaque action suivante. En réalité, les permissions peuvent changer en cours de session (un rôle modifié par un administrateur), et l'état du contenu évolue en continu si d'autres personnes ou d'autres agents interviennent sur le même site. Un contexte fiable se reconstruit, au moins partiellement, à chaque nouvelle action, pas seulement à la connexion initiale.

| Élément de contexte | Fréquence de reconstruction recommandée |
| --- | --- |
| Permissions du compte agent | À chaque appel d'outil sensible |
| État du contenu ciblé | Juste avant toute action d'écriture |
| Historique de conversation | Conservé pour la durée de la session |

> Un contexte figé au début d'une session est déjà un contexte obsolète dès que quelqu'un d'autre touche au site pendant que l'agent travaille.

## En résumé

Le contexte d'un agent ne se résume jamais à l'instruction qu'on lui donne : il inclut l'historique de la conversation, les permissions effectives, l'état courant du site et les contraintes de l'outil appelé. Confondre ce contexte avec un simple prompt mène à des décisions fondées sur une image du site qui n'est déjà plus exacte au moment de l'action. La bonne pratique reste de reconstruire les éléments les plus volatils du contexte, permissions et état du contenu en tête, juste avant chaque action réelle, plutôt que de se fier à une photographie prise en début de session.