Qu'est-ce que MCP ? Comment les agents IA se connectent à vos données (Mise à jour de la spécification 2026)

MCP, le Model Context Protocol, est un standard ouvert qui permet à un agent d'IA d'accéder à des outils et des sources de données via une interface commune unique. Au lieu d'une intégration sur mesure par application, un client utilise un seul protocole et n'importe quel serveur compatible peut y répondre. La spécification a été réécrite le 28 juillet 2026, et ce changement est majeur.

Ce guide présente le fonctionnement du protocole et les changements apportés par la version du 2026-07-28. Il aborde également les fonctionnalités désormais obsolètes, les différences avec une simple intégration d'API, et les cas où vous n'en avez pas besoin. Les faits présentés ici sont à jour au 5 août 2026.

Qu'est-ce que MCP ?

Voyez cela comme un format de prise partagé. Avant l'existence d'un standard, connecter un assistant à votre base de données, à votre système de tickets et à vos fichiers nécessitait trois intégrations sur mesure. Chacune avait sa propre authentification, sa propre gestion des erreurs et sa propre charge de maintenance.

MCP définit cette connexion une fois pour toutes. Un client représente le côté agent. Un serveur enveloppe une source de données ou un outil et expose ses capacités. Le client demande au serveur ce qui est disponible, puis l'appelle.

Les serveurs exposent généralement trois types d'éléments. Les outils sont des actions que l'agent peut invoquer. Les ressources sont du contenu lisible. Les prompts sont des modèles réutilisables. Le client découvre ces trois éléments au moment de l'exécution plutôt que de les avoir codés en dur.

Le nom est parfois utilisé de manière approximative, une clarification s'impose donc. Le protocole n'est ni un modèle, ni un agent, ni un produit. C'est le format de transfert (wire format) entre eux.

Deux mots expliquent la majeure partie de la confusion à son sujet. La découverte signifie que le client apprend ce qu'un serveur propose au moment de l'exécution. La réutilisation signifie que le même serveur répond à n'importe quel client compatible.

L'adoption n'est plus théorique. Les mainteneurs du protocole signalent près d'un demi-milliard de téléchargements par mois pour les SDK de niveau 1 (Tier 1). Les SDK TypeScript et Python ont chacun dépassé le milliard au total.

Ce qui a changé dans la spécification du 2026-07-28

Cette version est la révision la plus importante que le protocole ait connue. Le point principal est que le cœur est désormais sans état (stateless).

Changement	Ce que cela signifie
Cœur sans état (stateless)	Les sessions et les handshakes ont disparu. Chaque requête transporte sa propre version du protocole et l'identité du client
Requêtes multi-aller-retour (Multi Round-Trip)	Remplace les requêtes initiées par le serveur qui nécessitaient un flux ouvert. Un outil peut demander une saisie à l'utilisateur en cours d'appel
Routage basé sur les en-têtes	Les noms de méthodes et d'outils transitent dans les en-têtes Mcp-Method and Mcp-Name, de sorte que les passerelles effectuent le routage et l'autorisation sur les en-têtes
Résultats de liste mis en cache	Les listes d'outils, de prompts et de ressources contiennent désormais ttlMs et cacheScope
Renforcement de l'autorisation	Validation de l'émetteur RFC 9207, passage de la Dynamic Client Registration aux Client ID Metadata Documents, et identifiants liés à l'émetteur (issuer-bound credentials)
Framework d'extensions	Les tâches sortent du cœur expérimental pour devenir une extension formelle, aux côtés d'Apps et d'Enterprise Managed Authorization

Voyez cette liste comme une seule et même décision répétée six fois. Chaque changement élimine une hypothèse qui rendait l'exploitation des serveurs distants complexe. Rien de tout cela ne modifie ce qu'un outil peut faire.

L'article officiel sur la spécification du 2026-07-28 contient la liste complète des changements. Les SDK TypeScript, Python, Go et C# la prennent déjà en charge, et Rust est en version bêta.

Pourquoi le sans état (stateless) est important si vous gérez un serveur

L'ancienne architecture supposait une connexion persistante et bidirectionnelle. Cette seule hypothèse était à l'origine de la majeure partie des difficultés opérationnelles.

Auparavant, un serveur distant avait besoin de sessions persistantes (sticky sessions) pour qu'un client continue de se connecter à la même instance. Il nécessitait un stockage de session partagé pour que l'état survive à un redémarrage. Les passerelles devaient souvent inspecter les charges utiles (payloads) pour comprendre ce qu'une requête faisait.

Rien de tout cela n'est requis aujourd'hui. Un serveur peut se trouver derrière un simple répartiteur de charge (load balancer) de type round-robin. Le routage se fait sur un en-tête. Les clients mettent en cache la liste des outils aussi longtemps que la fenêtre définie par le serveur le permet. Le protocole est passé d'un élément que l'on déploie avec précaution à quelque chose que l'on déploie normalement.

Cela implique un coût de migration. Les serveurs conçus pour l'ancien cœur nécessitent des ajustements, et les bibliothèques clientes doivent évoluer en conséquence.

Ce changement réduit également le coût d'un essai. Mettre en place un serveur était auparavant une décision d'infrastructure. Aujourd'hui, cela s'apparente au déploiement de n'importe quel petit service web.

Pour quiconque évalue le serveur MCP d'un fournisseur, voici la question pratique à poser : quelle version de la spécification cible-t-il, et quand migrera-t-il ?

Ce qui est obsolète, et de combien de temps vous disposez

Trois fonctionnalités sont en cours d'abandon : Roots, Sampling et Logging. Le transport hérité HTTP+SSE est également obsolète.

Les mainteneurs se sont engagés sur un délai minimum de douze mois avant la suppression. C'est généreux, mais c'est aussi une date limite. Si vous avez développé sur l'un de ces quatre éléments, inscrivez la migration dans une feuille de route (roadmap) plutôt que dans un backlog.

Vérifiez également votre client, pas seulement votre serveur. Un client figé sur l'ancien transport continuera de fonctionner pendant cette période, puis s'arrêtera.

La Dynamic Client Registration est officiellement obsolète au profit des Client ID Metadata Documents. Les identifiants liés à l'émetteur (issuer-bound credentials) empêchent désormais qu'un jeton émis pour un serveur soit rejoué sur un autre.

Comparaison entre MCP et une simple intégration d'API

	Intégration d'API personnalisée	Serveur MCP
Travail par source	Nouvelle authentification, schéma et gestion des erreurs à chaque fois	Un seul protocole, réutilisé
Découverte	Vous codez en dur ce qui existe	Le client demande au moment de l'exécution
Qui peut l'utiliser	L'application dans laquelle vous l'avez intégré	N'importe quel client compatible
Maintenance	S'interrompt lorsque l'API du fournisseur change	Le serveur absorbe le changement
Idéal pour	Un seul canal profond à fort volume	De nombreuses sources sollicitées par un agent

Un autre aspect à prendre en compte est de savoir qui maintient le connecteur. Un serveur publié par un fournisseur évolue avec le produit de ce dernier, ce qui vous libère de cette charge de travail.

Pour être tout à fait honnête, MCP n'est ni plus rapide ni moins cher pour une intégration unique. Il devient avantageux lorsque le nombre de sources augmente, ou lorsque vous souhaitez que plusieurs agents accèdent à la même source sans avoir à tout reconstruire.

Ce que vous pouvez produire une fois qu'une source de données est connectée

La connexion n'est que de la plomberie. Ce qui intéresse vraiment les utilisateurs, c'est le livrable final.

Une fois la source de données connectée, un agent peut récupérer les chiffres actuels et lancer l'analyse. Le résultat obtenu est finalisé : un graphique, un résumé écrit, un jeu de diapositives. La valeur réside dans la suppression de l'étape d'exportation, et non dans le protocole lui-même. Ce livrable est également ce qui justifie la mise en place du système en interne. Une connexion que personne ne transforme en rapport finit par être désactivée en toute discrétion.

Powerdrill Bloom propose un serveur basé sur ce modèle. Selon sa propre documentation, il s'authentifie avec votre User ID et votre Project API Key. Un client peut ensuite parcourir les ensembles de données de votre compte, obtenir des détails sur l'un d'eux et exécuter des tâches en posant des questions en langage naturel. Il fonctionne avec Claude Desktop et d'autres clients compatibles. L'annonce du serveur MCP détaille la configuration, et la page des connecteurs de données répertorie les autres types de sources.

Quand vous n'avez pas du tout besoin de MCP

Cette partie est souvent omise dans la plupart des explications, il convient donc de la formuler clairement.

Si vos données arrivent sous forme de fichier, vous n'avez pas besoin de protocole. Vous avez besoin d'un import (upload). Un export trimestriel, un CSV envoyé par e-mail, un relevé PDF — rien de tout cela ne justifie la mise en place d'un serveur. Glissez-déposez le fichier et posez votre question.

Posez-vous une question avant de vous lancer. Ce même export sera-t-il à nouveau nécessaire le mois prochain, par quelqu'un d'autre que vous ?

MCP prouve son utilité lorsque la source est active et récurrente. Une base de données mise à jour toutes les heures, une file d'attente de tickets, une table d'entrepôt de données qui alimente un rapport hebdomadaire. Le test consiste à savoir si, autrement, vous devriez exporter à nouveau la même chose la semaine suivante.

Il y a également une dimension de sécurité. Une source connectée est une autorisation permanente, et non un partage unique. Les modifications d'autorisation du 2026-07-28 existent précisément parce que cette distinction est importante.

En résumé

MCP est une prise standard entre les agents et les sources de données. La version du 2026-07-28 a rendu le cœur sans état (stateless), a déplacé le routage dans les en-têtes, a rendu les résultats de liste mis en cache et a renforcé l'autorisation. Roots, Sampling, Logging et l'ancien transport HTTP+SSE sont obsolètes avec un délai de douze mois.

Pour un fichier ponctuel, ignorez tout cela. Essayez Powerdrill Bloom gratuitement — importez le fichier, posez votre question en langage naturel et exportez le graphique ou la présentation. Si vous comparez les options de serveur, consultez les meilleures plateformes MCP.

Questions fréquentes

Que signifie MCP ?

Model Context Protocol. Il s'agit d'un standard ouvert permettant de connecter des clients d'IA à des outils et des sources de données via une interface unique. Chaque nouvelle source évite ainsi une intégration sur mesure.

Qu'est-ce qui a changé dans la spécification MCP du 2026-07-28 ?

Le cœur est devenu sans état (stateless), abandonnant les sessions et les handshakes. Les requêtes multi-aller-retour (Multi Round-Trip Requests) ont remplacé les requêtes initiées par le serveur sur des flux ouverts, et le routage a été déplacé dans les en-têtes Mcp-Method et Mcp-Name. Les résultats de liste sont devenus mis en cache, et l'autorisation a été renforcée par la validation de l'émetteur et des identifiants liés à l'émetteur (issuer-bound credentials).

MCP est-il identique à une API ?

Non. Une API est l'interface d'un seul fournisseur pour un seul système. Le protocole est une enveloppe commune que de nombreux systèmes peuvent implémenter, de sorte que tout client compatible peut les découvrir et les appeler sans code personnalisé par source.

Qu'est-ce qui est obsolète dans la nouvelle spécification MCP ?

Roots, Sampling et Logging sont obsolètes, tout comme le transport hérité HTTP+SSE. La Dynamic Client Registration cède la place aux Client ID Metadata Documents. Les mainteneurs ont annoncé un délai minimum de douze mois avant la suppression.

Ai-je besoin de MCP pour analyser une feuille de calcul avec l'IA ?

Non. Pour un fichier que vous possédez déjà, l'importer est plus simple et plus rapide. Le protocole vaut la peine d'être configuré lorsque la source est active et que, sans cela, vous devriez ré-exporter régulièrement les mêmes données.