MCP : réussir la migration sans fragiliser ses agents

La migration d’un serveur MCP se valide sur des appels réels, des refus attendus et un retour arrière testé. La compatibilité du SDK ne suffit pas : votre agent doit conserver les mêmes droits, retrouver les mêmes outils et reprendre correctement une opération interrompue. La spécification du 28 juillet 2026 change plusieurs de ces frontières. Voici comment préparer la migration côté entreprise, avec un protocole de recette utilisable par une équipe technique.

Dans son annonce de juillet 2026, le projet MCP présente un cœur de protocole sans état de session, un routage par en-têtes et un durcissement de l’autorisation. Ces évolutions concernent surtout les intégrations déjà connectées à des documents, des applications et des actions métier. Pour les principes du protocole, commencez par ce que MCP rend réellement branchable. Ici, la question est celle du passage d’une version à l’autre.

Il faut inventorier les couples client et serveur effectivement utilisés, leurs versions et les opérations qu’ils autorisent. Un serveur conforme ne garantit pas que tous les clients de votre organisation sachent dialoguer avec lui. Une application de bureau, un agent hébergé et un traitement planifié peuvent dépendre de bibliothèques différentes, mises à jour à des rythmes différents.

Préparez une fiche par intégration : propriétaire métier, client, serveur, transport, version de protocole, mécanisme d’authentification, liste d’outils et opérations irréversibles. Ajoutez les applications intermédiaires : passerelle, proxy, cache et service d’identité. Ce sont souvent ces composants qui transforment une évolution mineure en panne difficile à reproduire. Une passerelle peut, par exemple, supprimer un en-tête que le nouveau transport attend.

Je recommande de joindre une trace anonymisée d’un appel réussi et d’un refus légitime. Cela fournit deux comportements de référence avant toute modification. Conservez également le catalogue d’outils avec leurs paramètres : un outil qui garde son nom mais change la signification d’un argument peut provoquer une régression silencieuse. La recette doit vérifier le résultat métier, pas seulement l’absence d’erreur réseau.

Le fonctionnement sans session impose de rendre explicites les informations dont chaque requête dépend. Le journal des changements de la spécification décrit notamment la disparition de l’échange d’initialisation traditionnel et de l’identifiant de session au niveau du protocole. Cela ne supprime pas l’état de votre application : un dossier, un panier ou une opération en cours peuvent toujours exister.

Prenons un agent qui prépare un devis. Dans une intégration ancienne, le serveur pouvait associer implicitement plusieurs appels à un état conservé en mémoire. Une migration mal conduite peut perdre ce contexte lors du passage à une autre instance. Le test utile consiste donc à préparer le devis sur une instance, puis à poursuivre le parcours sur une autre, avec des identifiants métier explicites et des droits contrôlés à nouveau.

Testez aussi la répétition d’une requête après une coupure réseau. Une opération de lecture peut être rejouée sans conséquence majeure ; une création de commande exige une protection contre les doublons. Cette protection relève de votre application. Le protocole ne remplace ni une clé d’idempotence adaptée ni la vérification du statut de l’opération avant de recommencer. Documentez le comportement attendu pour chaque outil qui écrit des données.

L’identité du serveur d’autorisation doit être contrôlée avant que le client échange le code reçu contre un jeton. La spécification MCP sur l’autorisation précise le traitement du paramètre `iss`. S’il est présent, il doit correspondre à l’émetteur attendu. S’il est annoncé comme pris en charge mais absent, la réponse doit être rejetée. Si ni l’annonce ni le paramètre ne sont présents, la spécification prévoit un autre comportement : il faut donc tester les cas séparément.

La RFC 9207 décrit ce mécanisme d’identification de l’émetteur pour limiter les attaques de confusion entre serveurs d’autorisation. Dans la recette, utilisez deux fournisseurs d’identité de test. Le parcours commencé avec le premier ne doit pas être terminé en envoyant son code au second. Un message d’erreur propre ne suffit pas si le code a déjà quitté la bonne frontière.

Ajoutez un test sur la ressource visée par le jeton et un autre sur les permissions de l’utilisateur. L’authentification prouve une identité ; elle n’autorise pas toutes les actions. Un compte qui consulte les contrats ne doit pas pouvoir les modifier parce que l’agent a trouvé un nouvel outil d’édition. Pour les données documentaires, cette vérification complète le filtrage des droits d’accès dans un RAG.

Les tests les plus utiles associent un parcours légitime à sa variante interdite. Pour une lecture de document, vérifiez le document autorisé, puis le document d’un autre service. Pour une modification, vérifiez l’action permise, puis la même action avec un rôle de consultation. Pour une connexion, vérifiez l’émetteur attendu, puis un émetteur différent, une réponse incomplète et une session expirée.

Séparez les contrôles de transport des contrôles métier. Le premier niveau porte sur les en-têtes, le format des requêtes et la compatibilité. Le deuxième porte sur les droits et les effets produits. Le troisième vérifie le comportement de l’agent : sait-il expliquer qu’une action a été refusée, demander une information manquante et poursuivre sans contourner la restriction ? Un refus technique mal interprété peut déclencher plusieurs tentatives coûteuses ou une réponse trompeuse.

Ces scénarios constituent une proposition de recette, pas un ensemble de garanties fournies par MCP. Ils doivent être adaptés aux risques du système et complétés par les tests d’injection de prompt indirecte lorsque les outils lisent des contenus non fiables.

Une bascule réversible garde une version précédente exploitable et limite d’abord le trafic de la nouvelle intégration. Installez la nouvelle version dans un environnement distinct, avec un compte de test et un jeu de données contrôlé. Exécutez la même recette sur les deux versions. Notez les écarts de résultat, de latence, d’appels et de permissions, sans masquer les refus dans une moyenne globale.

Pour les lectures, un parcours comparatif peut aider à observer les différences. Pour les écritures, évitez de faire exécuter deux fois la même opération en production : comparez sur un environnement de recette ou remplacez l’effet externe par une simulation. Le mécanisme de retour arrière doit inclure les données si leur format a changé ; remettre l’ancien exécutable ne répare pas automatiquement une migration de stockage.

Fixez les critères d’arrêt avant l’ouverture : action non autorisée, duplication, perte de contexte métier, fuite d’information ou incapacité à reprendre proprement. Affectez un responsable à la décision de poursuivre et un autre à la surveillance métier. Le livrable de migration doit permettre à une personne absente des développements de comprendre ce qui a été testé, ce qui reste incompatible et comment revenir à la situation précédente. Un audit technique IA peut structurer cette recette autour des usages réellement exposés.