# Simuler un outil MCP pour tester un agent sans toucher au site réel

> Ajouter un mode simulation qui renvoie une réponse plausible sans exécuter l'action, pour valider le comportement d'un agent avant de l'autoriser en production.

- Auteur : Clément Hadrot
- Publié le : 2026-03-18
- Mis à jour le : 2026-03-18
- Catégorie : IA & MCP
- URL : https://wpmoderne.dev.wordpress-developpement.fr/ia-mcp/simuler-outil-mcp-tester-agent-sans-production/

## L’essentiel

- Un mode simulation renvoie une réponse plausible sans jamais appeler la logique réelle
- Le même schéma d'entrée et de sortie garantit que le comportement observé reste représentatif
- Un indicateur explicite distingue toujours une réponse simulée d'une réponse réelle

Avant d'autoriser un agent à créer réellement des commandes fournisseurs via un outil MCP, encore faut-il pouvoir observer son comportement sur des dizaines de scénarios sans jamais déclencher une seule commande réelle. Un mode simulation, ajouté directement à l'outil plutôt que reconstruit à côté, permet cette validation sans toucher au site en production ni dupliquer la logique de l'outil.

Ce tutoriel détaille la mise en place d'un tel mode sur un outil MCP existant, étape par étape. Il ne traite pas des tests unitaires PHP classiques, qui restent nécessaires par ailleurs pour valider la logique métier elle-même, indépendamment du comportement de l'agent.

## Étape 1 : identifier ce qu'un mode simulation doit préserver

Un mode simulation utile doit conserver exactement le même schéma d'entrée et de sortie que le mode réel : c'est cette identité stricte qui garantit que le comportement de l'agent observé en simulation reste représentatif de son comportement une fois l'outil activé réellement. Un mode simulation qui renverrait une réponse simplifiée ou différente fausserait l'observation plutôt que de la faciliter.

## Étape 2 : ajouter un indicateur d'environnement à l'outil

Le basculement entre les deux modes repose sur une seule variable d'environnement, lue au moment de l'exécution de l'outil, jamais codée en dur dans un fichier de configuration versionné.

> L'essentiel à retenir : Un mode simulation renvoie une réponse plausible sans jamais appeler la logique réelle ; Le même schéma d'entrée et de sortie garantit que le comportement observé reste représentatif ; Un indicateur explicite distingue toujours une réponse simulée d'une réponse réelle

```
server.tool(
  'creer_commande_fournisseur',
  {
    fournisseur_id: z.number(),
    reference_produit: z.string(),
    quantite: z.number().min(1),
  },
  async ( { fournisseur_id, reference_produit, quantite } ) => {
    if ( process.env.MODE_AGENT === 'simulation' ) {
      return {
        content: [ { type: 'text', text: JSON.stringify( {
          simule: true,
          commande_id: 'SIMULATION-' + Date.now(),
          fournisseur_id, reference_produit, quantite,
          statut: 'aurait ete creee',
        } ) } ],
      };
    }
    const commande = await erp.creerCommande( { fournisseur_id, reference_produit, quantite } );
    return { content: [ { type: 'text', text: JSON.stringify( commande ) } ] };
  }
);
```

## Étape 3 : rendre la réponse simulée plausible, pas seulement valide

Une réponse simulée techniquement conforme au schéma mais manifestement artificielle, comme un identifiant de commande toujours identique, réduit la valeur du test : l'agent qui enchaîne plusieurs appels doit recevoir des réponses cohérentes entre elles, comme il le ferait en conditions réelles. L'identifiant simulé porte ici un horodatage variable, suffisant pour rester crédible sur une session de test sans reproduire toute la complexité du système réel.

## Étape 4 : marquer explicitement chaque réponse comme simulée

Le champ `simule: true` reste présent dans chaque réponse, y compris dans les journaux de session conservés après le test. Cette marque explicite évite toute confusion ultérieure lors d'une relecture des journaux, en particulier si une session de test et une session réelle sont examinées côte à côte plusieurs semaines après coup.

## Étape 5 : construire un jeu de scénarios représentatifs

Le mode simulation lui-même ne vaut que par les scénarios soumis à l'agent une fois activé. Un jeu d'une quinzaine de formulations différentes, couvrant les demandes claires, les demandes ambiguës et les demandes hors périmètre de l'outil, permet d'observer si l'agent appelle l'outil au bon moment, avec les bons paramètres, avant toute activation réelle.

1. Activer `MODE_AGENT=simulation` sur l'environnement de test de l'agent.
2. Soumettre le jeu de scénarios représentatifs, un par un, en conservant chaque réponse simulée.
3. Relire l'ensemble des appels obtenus, en cherchant les paramètres incorrects ou les appels non déclenchés à tort.
4. Corriger la description de l'outil ou la consigne de l'agent selon les écarts constatés, puis rejouer le même jeu de scénarios.
5. Désactiver la variable d'environnement seulement une fois ce jeu de scénarios rejoué sans écart plusieurs fois de suite.

- Le mode simulation partage le même schéma que le mode réel, sans aucune exception.
- Chaque réponse simulée porte un indicateur explicite, conservé dans les journaux.
- Le basculement se fait par une seule variable d'environnement, jamais par une copie du code de l'outil.

> Un mode simulation qui ressemble un peu trop à un raccourci de développement ne teste rien : il doit rester assez fidèle pour qu'un agent s'y comporte exactement comme il le ferait face à l'outil réel.

## En résumé

Ajouter un mode simulation directement dans un outil MCP existant, plutôt que de construire un outil séparé pour les tests, garantit que le comportement observé reste fidèle à celui attendu en production. Un indicateur explicite d'environnement, un schéma strictement identique et un jeu de scénarios représentatifs suffisent à valider le comportement d'un agent avant toute autorisation réelle.