Le code -32002 devient -32602 : le changement qui casse les clients en silence

C'est le plus petit changement de la spec MCP 2026-07-28, et celui qui produit les tickets les plus pénibles.

MCP avait introduit -32002 comme code d'erreur maison pour signaler une ressource absente. JSON-RPC 2.0 avait déjà -32602 pour des paramètres invalides. Les deux se recouvraient. La nouvelle révision supprime le doublon et garde le code standard.

Pourquoi c'est pénible

Parce que ça ne plante pas.

Un client qui compare la valeur littérale -32002 pour détecter une ressource manquante ne lève pas d'exception quand le code change. Il tombe simplement dans sa branche générique. Selon comment il est écrit, ça donne :

• un message d'erreur brut affiché à l'utilisateur au lieu d'un message métier
• une logique de retry qui se déclenche là où elle ne devrait pas, parce que l'erreur n'est plus identifiée comme définitive
• un fallback silencieux qui renvoie un résultat vide au lieu d'une erreur
• une alerte qui ne part jamais, puisque techniquement il n'y a pas eu d'échec

Rien de tout ça n'apparaît dans un tableau de bord d'erreurs. Ça apparaît trois semaines plus tard, dans un ticket support qui dit que l'agent « répond n'importe quoi parfois ».

Ce qu'il faut chercher

Une recherche de chaîne, dans tout le dépôt, sur 32002. Pas seulement dans le serveur.

Regarde aussi :

• tes clients maison et tes scripts d'intégration
• tes SDK internes ou tes wrappers autour du SDK officiel
• tes tests, y compris les fixtures et les mocks qui figent l'ancien code
• ta documentation publique si tu documentes tes codes d'erreur
• tes règles d'alerting, si tu comptes les erreurs par code

Les tests sont le cas le plus insidieux. Un test qui vérifie que ton serveur renvoie -32002 continue de passer si tu ne changes rien, et échoue au moment où tu corriges le serveur. Beaucoup d'équipes corrigent alors le test dans le mauvais sens, en remettant l'ancienne valeur.

Le correctif

Côté serveur, tu remplaces l'émission de -32002 par -32602.

Côté client, deux options. La plus rapide est d'accepter les deux valeurs pendant la période de transition, ce qui te permet de parler à des serveurs migrés et non migrés. La plus propre est de cesser de comparer des codes numériques bruts et de passer par une constante ou un helper du SDK, pour que le prochain changement ne te coûte qu'un seul endroit.

Si tu ne dois faire qu'une chose : ne laisse pas de valeur numérique en dur dans du code de branchement. C'est ce qui a rendu ce changement coûteux.

Le test qui vérifie

Appelle un outil avec une référence de ressource qui n'existe pas, et regarde ce que le client affiche à l'utilisateur final. Pas ce que le serveur renvoie, ce que l'utilisateur voit.

Si le message est générique alors qu'il devrait être métier, ta chaîne de traitement d'erreur ne reconnaît plus l'erreur.

Combien il en reste chez toi

Ce changement fait partie des sept modifications de la révision 2026-07-28. L'audit passe le dépôt au peigne fin, y compris les clients maison et les tests. Sous 24 heures ouvrées, tu as la liste et le chiffrage.

Prêt à faire le point ? Faire auditer mon serveur MCP →

Lectures liées

• Migrer un serveur MCP vers la spec 2026-07-28 : le guide complet
• Audit de migration MCP : la checklist en 12 points