Mettre en place une veille de conformité MCP sans équipe protocole
Le protocole MCP a maintenant une politique de dépréciation et une suite de conformité. Le dispositif minimum pour suivre ça sans y consacrer un poste.
Jusqu'en 2026, suivre MCP était un sport. Les révisions arrivaient, les fonctionnalités changeaient, et la seule façon de ne pas se faire surprendre était de lire les SEP au fil de l'eau.
La révision 2026-07-28 change ça. Elle apporte trois éléments de gouvernance qui rendent la veille possible sans y consacrer un poste : une politique formelle de cycle de vie, un système d'extensions, et une exigence de suite de conformité.
Encore faut-il brancher quelque chose. Voici le dispositif minimum.
Ce qu'il y a à suivre, en réalité
Quatre sources, pas plus.
Le changelog de la spécification. C'est la liste faisant autorité des changements entre deux révisions. Tout le reste en découle.
Les dépréciations. Elles sont suivies publiquement, avec des échéances. Une fonctionnalité dépréciée reste fonctionnelle au moins douze mois avant retrait. C'est cette liste qui te donne ton calendrier.
Les notes de version de ton SDK. C'est là que le protocole devient du code chez toi. Les capacités dépréciées y sont marquées obsolètes, avec un pointeur vers le remplacement.
Les clients que tu supportes. Un changement de protocole ne te concerne vraiment que quand un client que tes utilisateurs utilisent l'adopte. C'est ce qui détermine ton urgence réelle, pas la date de la spec.
Ce dernier point est le plus mal suivi et le plus décisif. La bascule est opt-in des deux côtés : rien ne change tant que le client n'a pas bougé.
Le dispositif minimum
Un check de conformité dans la CI. Le protocole exige désormais une suite de conformité. Fais-la tourner sur ton serveur à chaque merge. Ce n'est pas une preuve complète, mais ça attrape les régressions de forme sans que personne y pense.
Un test de bascule dans la CI. Scénario multi-étapes réel, deux instances en round-robin, une instance tuée au milieu. C'est le seul test qui prouve que ton serveur est vraiment stateless.
Une alerte calendrier par dépréciation. Pas « un jour ». Une date, posée le jour où tu apprends la dépréciation, avec deux mois de marge avant l'échéance annoncée.
Une revue trimestrielle d'une heure. Tu ouvres le changelog, la liste des dépréciations, les notes de ton SDK, et tu écris trois lignes : ce qui te concerne, ce qui ne te concerne pas, ce qu'il faut planifier. Une heure par trimestre suffit si le reste est automatisé.
Ce que ça coûte de ne pas le faire
Le coût n'est jamais une panne le jour J. Il est toujours différé, et il prend trois formes.
Le rattrapage. Tu découvres trois révisions de retard d'un coup, et ce qui aurait été trois petits chantiers devient un gros, avec des dépendances entre eux.
Le code mort qui lève. Une fonctionnalité dépréciée compile jusqu'au jour où elle est retirée du SDK. Le bug arrive alors sans contexte, six mois après que quelqu'un aurait pu le supprimer en deux minutes.
La soumission refusée. Les annuaires de connecteurs regardent la conformité. Un serveur en retard de deux révisions passe mal, et le délai de correction retarde la distribution.
Qui doit s'en occuper
Si tu as une équipe protocole, ce n'est pas ton problème. Presque personne n'en a.
Le cas normal est un SaaS dont le serveur MCP a été écrit par un dev en deux semaines il y a un an, qui est passé à autre chose depuis. Le serveur tourne, personne ne le regarde, et il dérive lentement.
Les deux options honnêtes sont : quelqu'un chez toi prend une heure par trimestre et la CI fait le reste, ou tu externalises la veille. Le pire choix est de décider que ça se fera « quand on aura le temps », parce que ce moment n'arrive pas.
FAQ
À quelle fréquence sortent les révisions ?
Le rythme n'est pas garanti, mais la 2026-07-28 est annoncée comme la dernière à casser la compatibilité de cette ampleur. Les gouvernances ajoutées visent précisément à permettre l'évolution sans rupture.
Est-ce que la suite de conformité suffit à valider mon serveur ?
Non. Elle valide la forme du protocole. Elle ne dit rien de ta sécurité, de tes performances, ni de la qualité de tes outils du point de vue de l'agent.
Que faire des extensions ?
Elles évoluent sur leur propre calendrier, c'est le but du système. Suis seulement celles que tu utilises.
La veille, sans y passer tes vendredis
290 € par mois. Je surveille les évolutions du protocole, je te dis ce qui concerne ton serveur précisément, et je te préviens avant que ça devienne urgent. Pas de rapport de vingt pages, juste ce qui te concerne.
Intéressé ? Discuter de la veille de conformité →
Lectures liées
Un serveur MCP à faire auditer ?
Cinq minutes pour le décrire. Je réponds sous 24 heures ouvrées avec un premier diagnostic écrit et gratuit.
Faire auditer mon serveur MCP