# Un agent IA a modifié la mauvaise page à cause d’un identifiant ambigu

> Deux pages au titre presque identique, un outil MCP trop permissif sur l'identifiant reçu : incident réel et correctif par un schéma plus strict.

- Auteur : Clément Hadrot
- Publié le : 2026-04-12
- Mis à jour le : 2026-04-12
- Catégorie : IA & MCP
- URL : https://wpmoderne.dev.wordpress-developpement.fr/ia-mcp/agent-ia-mauvaise-page-identifiant-ambigu/

## L’essentiel

- La recherche par titre approximatif a créé l'ambiguïté
- L'agent a choisi la page la plus récente, pas la bonne
- Un identifiant numérique obligatoire a réglé le problème

« Mentions légales » et « Mentions légales — filiale Suisse » : deux pages du même site institutionnel, créées à six mois d'écart, avec un titre qui ne diffère que par ce complément entre tirets. Un agent chargé de mettre à jour le texte de la page « Mentions légales » à la demande d'un juriste a modifié la mauvaise des deux, sans qu'aucune alerte ne se déclenche avant la publication du changement.

Cet incident, bien réel, illustre un problème que nous retrouvons régulièrement dans les intégrations agentiques : la tentation de laisser un outil accepter un titre approximatif plutôt qu'un identifiant strict, pour simplifier l'usage côté agent. Ce texte ne traite pas les schémas rejetés par un MCP Adapter au sens technique, déjà couverts ailleurs : il porte sur l'ambiguïté sémantique, un problème différent, plus insidieux.

## Comment l'outil était conçu au départ

L'outil MCP `update_page_content` acceptait un paramètre `titre_page` en texte libre, puis effectuait une recherche approximative dans la base pour retrouver la page correspondante, avant d'appliquer la modification demandée. Ce choix de conception semblait raisonnable au moment de l'écriture : il évitait à l'agent de devoir connaître l'identifiant numérique interne de chaque page avant de pouvoir la modifier.

> L'essentiel à retenir : La recherche par titre approximatif a créé l'ambiguïté ; L'agent a choisi la page la plus récente, pas la bonne ; Un identifiant numérique obligatoire a réglé le problème

```
function agence_update_page_content( $titre_page, $nouveau_contenu ) {
    $pages = get_posts( array(
        'post_type'   => 'page',
        's'           => $titre_page,
        'post_status' => 'publish',
    ) );

    if ( empty( $pages ) ) {
        return new WP_Error( 'introuvable', 'Aucune page correspondante.' );
    }

    // Problème : on prend simplement le premier résultat
    $page = $pages[0];
    wp_update_post( array(
        'ID'           => $page->ID,
        'post_content' => $nouveau_contenu,
    ) );

    return array( 'id' => $page->ID, 'titre' => $page->post_title );
}
```

## Le déroulé de l'incident

La demande transmise à l'agent mentionnait simplement « la page mentions légales ». La recherche approximative a renvoyé les deux pages, triées par défaut selon la pertinence calculée par WordPress. La page filiale, publiée plus récemment, est arrivée en première position, et l'outil a silencieusement appliqué la modification à cette page, plutôt qu'à la page principale visée par le juriste.

Rien dans la réponse de l'outil n'indiquait qu'un choix avait été fait entre plusieurs candidats possibles : l'agent a reçu une confirmation de succès, identique à ce qu'il aurait reçu si une seule page avait correspondu.

## Le correctif : un schéma qui refuse l'ambiguïté

La correction a consisté à supprimer purement la recherche approximative de l'outil de modification, et à exiger un identifiant numérique explicite. Un outil de recherche séparé, en lecture seule, reste disponible pour que l'agent retrouve d'abord les candidats possibles, avec leur identifiant, avant de choisir lequel modifier.

```
{
  "name": "update_page_content",
  "inputSchema": {
    "type": "object",
    "properties": {
      "page_id": { "type": "integer", "description": "Identifiant numérique exact de la page, obtenu via l'outil find_page" },
      "nouveau_contenu": { "type": "string" }
    },
    "required": ["page_id", "nouveau_contenu"]
  }
}

{
  "name": "find_page",
  "description": "Recherche des pages par titre approximatif. Renvoie une LISTE, jamais une page unique choisie automatiquement.",
  "inputSchema": {
    "type": "object",
    "properties": { "recherche": { "type": "string" } },
    "required": ["recherche"]
  }
}
```

Avec ce découpage, si la recherche renvoie plusieurs candidats, l'agent doit explicitement présenter le choix ou le demander avant d'appeler l'outil de modification. Un seul résultat ne suffit plus à déclencher une action silencieuse.

## Pourquoi ce piège est facile à reproduire

La tentation de simplifier l'interface d'un outil pour l'agent (moins de paramètres, moins d'appels préalables) va souvent à l'encontre de la sécurité de l'action elle-même. Un identifiant numérique est moins agréable à manipuler pour un humain qui relit le code, mais il élimine complètement la classe d'erreur rencontrée ici.

> Un outil d'écriture ne devrait jamais deviner à la place de l'agent quand plusieurs interprétations sont possibles. Deviner juste neuf fois sur dix, c'est encore une fois de trop sur une page de mentions légales.

## En résumé

Séparer strictement la recherche (qui peut renvoyer plusieurs résultats ambigus) de l'action d'écriture (qui exige un identifiant unique et non ambigu) élimine une classe entière d'incidents silencieux. Ce principe, simple à énoncer, demande une vigilance réelle au moment de concevoir chaque nouvel outil, tant la tentation de simplifier l'usage immédiat reste forte.