AgentOps MCP : valider un changement de schéma d'outil avant de redéployer l'agent

Un agent IA peut sembler stable tant que son prompt ne change pas. En production, ce n’est pas suffisant. Si l’outil MCP qu’il appelle évolue, l’agent peut continuer à répondre avec assurance tout en envoyant un mauvais argument, en sautant une confirmation ou en déclenchant une action sur un périmètre plus large que prévu.

Le cas classique est discret : une équipe ajoute un paramètre optionnel dans un outil de diagnostic, renomme un champ de sortie ou fusionne deux actions proches. Les tests unitaires du serveur MCP passent. L’agent répond toujours. Mais le contrat opérationnel a bougé.

Le but de ce runbook est de traiter un changement de schéma d’outil MCP comme un changement de production : contrat explicite, évaluation rejouable, droits bornés, traces lisibles, validation humaine et rollback.

Cadrer le changement avant de toucher l’agent

Avant de redéployer l’agent, il faut décrire le changement côté outil, pas seulement côté code.

La fiche de changement doit indiquer :

• le nom exact de l’outil MCP modifié ;
• les champs ajoutés, retirés, renommés ou rendus obligatoires ;
• les valeurs par défaut ajoutées par le serveur ;
• les effets de bord possibles ;
• les rôles ou identités autorisés à appeler l’outil ;
• les actions qui restent interdites sans approbation humaine.

Cette fiche évite une erreur fréquente : considérer qu’un changement “compatible” au niveau JSON reste compatible pour l’agent. Un champ optionnel peut modifier la stratégie de l’agent s’il devient visible dans la description de l’outil. Une sortie plus riche peut aussi encourager l’agent à conclure trop vite.

Le critère de départ est simple : si le schéma, la description ou la sémantique d’un outil change, l’agent doit être revalidé.

Séparer schéma technique et contrat opérationnel

Le schéma MCP décrit les entrées et sorties. Le contrat opérationnel décrit ce que l’agent a le droit d’en faire.

Pour chaque outil exposé à l’agent, documenter au minimum :

Élément	Question à trancher
Intention	Quel problème l’outil résout-il exactement ?
Entrées	Quels champs peuvent être proposés par l’agent ?
Données sensibles	Quels champs ne doivent jamais être inférés ou inventés ?
Effet	L’outil lit-il, modifie-t-il, relance-t-il ou supprime-t-il quelque chose ?
Preuve	Quelle trace prouve l’appel, les paramètres et le résultat ?
Approbation	À partir de quel seuil faut-il une validation humaine ?
Rollback	Comment revenir à la version précédente de l’outil ou du serveur ?

Cette séparation est importante pour les agents qui manipulent des runbooks, des tickets, des pipelines, des ressources Azure ou des automatisations internes. Un schéma valide peut rester dangereux si le contrat autorise implicitement l’agent à choisir le périmètre d’action.

Construire un jeu d’évaluation minimal mais utile

Un changement de schéma ne se valide pas avec une seule conversation heureuse. Il faut rejouer quelques situations qui couvrent les risques réels.

Un jeu d’évaluation utile contient au moins :

• un cas nominal ou l’agent choisit le bon outil et renseigne les bons champs ;
• un cas ambigu ou il doit demander une précision ;
• un cas interdit ou il doit refuser l’action ou demander une approbation ;
• un cas de données manquantes ou il doit chercher une preuve avant d’agir ;
• un cas de rollback ou il doit expliquer comment revenir en arrière ;
• un cas de non-régression sur un ancien scénario qui fonctionnait déjà.

Le résultat attendu ne doit pas seulement vérifier la phrase finale. Il doit vérifier le chemin :

• outil appelé ou non appelé ;
• arguments transmis ;
• identité utilisée ;
• preuve lue avant action ;
• message de confirmation ;
• absence d’action hors périmètre.

Le point clé est de capturer les appels d’outils, pas seulement le texte produit par l’agent. Un agent peut donner une bonne explication après avoir appelé le mauvais outil.

Tester dans un environnement borné

Le serveur MCP de test doit être isolé de la production ou connecté à des ressources explicitement non destructives.

En pratique, cela signifie :

• un projet, groupe de ressources ou environnement de sandbox ;
• une identité dédiée avec les mêmes limites que la production, mais sans droit large ;
• des jeux de données représentatifs mais non sensibles ;
• des logs activés sur le serveur MCP, l’identité appelée et la cible ;
• une liste d’actions volontairement bloquées pour vérifier les refus.

Pour un outil qui agit sur Azure DevOps, par exemple, l’agent peut lire un projet de test, ouvrir un commentaire de validation ou relancer un pipeline factice. Il ne doit pas pouvoir modifier un pipeline critique pendant l’évaluation.

Pour un outil qui agit sur Azure, l’agent peut lire des métadonnées, vérifier un état ou déclencher une opération réversible sur une ressource de test. Il ne doit pas recevoir un rôle plus large sous prétexte que “ce n’est qu’un test”.

Relire les traces avant de valider

La validation doit produire un petit dossier de preuve. Il n’a pas besoin d’être lourd, mais il doit permettre à une autre personne de comprendre ce qui s’est passé.

Conserver :

• la version du serveur MCP ;
• la version de l’agent ou du prompt système ;
• le schéma d’outil avant et après ;
• les prompts d’évaluation ;
• les appels d’outils avec arguments ;
• les sorties retournées par le serveur ;
• les logs d’identité ou d’audit ;
• les cas échoués et la décision associée.

Les échecs ne bloquent pas toujours le déploiement. Ils doivent en revanche être qualifiés. Un échec sur une formulation rare peut devenir une note de limitation. Un échec sur un refus d’action ou un périmètre trop large doit bloquer.

La question de validation n’est pas “est-ce que l’agent répond bien ?”. C’est : “pouvons-nous expliquer et borner ce que l’agent fera quand cet outil sera visible en production ?”.

Décider le déploiement

Le déploiement peut être accepté si :

• les anciens scénarios critiques restent valides ;
• les nouveaux champs sont utilisés seulement quand le contexte les justifie ;
• l’agent demande une précision quand le périmètre est ambigu ;
• les actions sensibles restent derrière une approbation humaine ;
• les logs permettent de reconstruire la décision ;
• le rollback a été testé ou au moins préparé.

Le déploiement doit être refusé si :

• l’agent invente des valeurs d’entrée ;
• l’agent appelle l’outil sur un périmètre non demandé ;
• une action irréversible peut être lancée sans confirmation ;
• les traces ne montrent pas les arguments transmis ;
• l’ancien schéma ne peut pas être restauré rapidement.

Une décision saine peut être “déployer le serveur MCP, mais ne pas encore exposer le nouvel outil à l’agent”. Cela permet de livrer le backend sans augmenter immédiatement l’autonomie.

Préparer le rollback

Le rollback doit couvrir deux niveaux différents.

Le premier est technique : revenir à l’ancienne version du serveur MCP, de sa description d’outils et de sa configuration. Le second est opérationnel : retirer temporairement l’outil de la liste autorisée, réduire ses droits ou replacer l’action derrière une validation humaine obligatoire.

Le plan de retour doit donc préciser :

• la version précédente du serveur ;
• le mécanisme de désactivation de l’outil ;
• les droits à retirer si l’outil reste instable ;
• les conversations ou exécutions à auditer après incident ;
• le message à donner aux opérateurs si l’agent est dégradé.

Dans beaucoup de cas, le rollback le plus rapide n’est pas un redéploiement complet. C’est une réduction du registre d’outils visible par l’agent, accompagnée d’une note d’exploitation.

Conclusion

Un changement de schéma MCP n’est pas un détail d’intégration. Pour un agent qui agit sur des systèmes internes, c’est un changement de contrat de production.

Le bon réflexe consiste à valider l’outil comme une interface d’exploitation : intention claire, entrées bornées, identité limitée, évaluations rejouables, traces exploitables et rollback prêt. L’agent peut alors gagner en capacité sans devenir opaque.