Tu as branché ton agent IA à une douzaine d'outils MCP — Slack, GitHub, Jira — testé le tout, mis en prod, et tu es passé à autre chose. MCP (Model Context Protocol), c'est la prise universelle pour les outils IA : imagine l'USB-C, mais pour connecter ton IA à des services externes. Tu as écrit tes prompts, l'agent appelait ses outils, la vie était belle.

Puis un de ces outils a mis à jour son schéma — le contrat qui définit quels paramètres un outil accepte et ce qu'il renvoie — renommé un champ de query en search_query, et ton agent s'est mis à échouer silencieusement une requête sur trois. Pas d'erreur. Pas de notification. L'IA a juste halluciné autour de l'entrée cassée comme si de rien n'était. Comme le développeur Mike l'a documenté dans une étude de cas sur DEV Community le 18 mars : "La serviabilité du modèle est l'amplificateur qui transforme un bug d'intégration mineur en une défaillance invisible."

Ce n'est pas un cas limite hypothétique. C'est l'état par défaut de tout l'écosystème.

L'ampleur du bazar sans versioning

En avril 2026, MCP a atteint 97 millions de téléchargements mensuels du SDK, avec plus de 17 000 serveurs publics et 300+ clients. C'est une croissance de 2 250 % en sept mois. Et dans tout ça — zéro standard de versioning.

Chaque autre dépendance de ta stack a de la gestion de versions. npm a des lockfiles — des fichiers qui figent les versions exactes de tes dépendances pour que rien ne change sans ton accord. Docker a des digests d'images. Les APIs ont des specs OpenAPI avec des avis de dépréciation. Mais les schémas d'outils MCP ? Un auteur de serveur peut renommer des paramètres, changer les types de retour, ou supprimer des endpoints à tout moment sans aucun signal dans l'écosystème. Pas de semver (le système de numérotation "1.2.3" qui te dit si un changement va casser ton code). Pas de lockfile. Pas de changelog.

La seule proposition pour corriger ça — SEP-1575 sur GitHub, qui ajouterait un champ version aux définitions d'outils — est bloquée en brouillon depuis septembre 2025. Versioning au niveau serveur ou au niveau outil ? Toujours en débat. Dix-huit mois après le lancement de MCP.

En attendant, selon les recherches de KushoAI, 41 % des APIs subissent des changements de schéma non documentés dans les 30 jours. Maintenant applique ça à 17 000 serveurs MCP.

Le drift de modèle fait les gros titres. Le drift d'outils ne fait même pas un bruit.

Le 16 avril, Anthropic a remplacé l'alias flottant opus pour qu'il pointe vers Claude Opus 4.7 — ce qui veut dire que chaque outil utilisant cet alias a silencieusement reçu un modèle différent avec un tokenizer qui peut augmenter le coût par token jusqu'à 35 %. Ça a fait la une. Les gens ont remarqué parce que les modèles, c'est visible.

Les schémas d'outils ? Personne ne les surveille. Aucune plateforme ne suit les changements à travers 17 000 serveurs. Ton agent casse, tu accuses ton prompt, tu accuses le modèle, tu passes trois jours à débugger — et la vraie cause était un paramètre renommé dans un outil que tu n'as pas touché depuis des semaines.

AWS tente le premier coup

Le 17 avril, AWS a lancé Agent Registry en preview dans le cadre d'Amazon Bedrock AgentCore. C'est un catalogue centralisé pour les agents IA, les outils et les serveurs MCP avec — enfin — du suivi de versions. Les enregistrements suivent un cycle de vie brouillon → approbation en attente → découvrable. Toute mise à jour remet le statut en brouillon, forçant une re-validation.

C'est le premier grand fournisseur cloud à livrer quelque chose qui ressemble à de la gestion de versions pour les outils MCP. Justin Bundick, VP IA chez Southwest Airlines, a qualifié ça de solution au "problème critique de découvrabilité."

Mais voilà le hic : c'est un catalogue, pas un lockfile. Ça enregistre que des versions existent — ça n'empêche pas les breaking changes d'atteindre ton agent. Tu ne peux toujours pas épingler un outil à un snapshot de schéma précis comme tu épinglerais [email protected] dans package.json. Et l'ADK 1.0 de Google — qui a livré le support stable de MCP le 30 mars — ne mentionne même pas le versioning d'outils dans sa doc.

Ce que tu peux concrètement faire aujourd'hui

Si ton agent a cassé cette semaine et que tu ne trouves pas le bug dans ton prompt ou ton modèle, vérifie si un outil a changé son schéma. Tu n'as aucun moyen automatisé de le savoir — mais au moins maintenant tu sais où chercher.

Les options pratiques sont moches : forker et auto-héberger tes serveurs MCP (ce qui ruine tout l'intérêt), construire une couche proxy qui capture des snapshots de schémas (une complexité que personne ne budgète), ou utiliser des outils communautaires comme mcpdiff pour comparer manuellement les définitions d'outils entre les exécutions. Rien de tout ça ne passe à l'échelle. Tout ça, c'est du scotch.

La stack agent a désormais deux dépendances fantômes sans versioning — les modèles et les outils. Anthropic te permet au moins d'épingler les versions de modèles avec des identifiants complets comme claude-opus-4-7. Les schémas d'outils n'ont aucun équivalent. La première plateforme à livrer une vraie détection de breaking changes — pas un catalogue, mais un vrai lockfile avec intégration CI — capturera la couche gestionnaire de paquets de l'ère des agents.

D'ici là, tu déploies des agents en production sur des dépendances qui peuvent changer sous tes pieds à tout moment, sans notification, sans diff, et sans rollback. npm sans lockfile. En 2026. Pour de l'IA en production.

Dors bien.