Comment s’articulent MCP, les connecteurs et les protocoles d’agent à agent en 2026?

Trois noms reviennent chaque fois qu’on parle d’agents qui font du vrai travail : MCP, connecteurs et A2A. On les confond facilement parce que tous trois servent à « connecter l’IA à des choses ». La différence tient à ce qui est connecté. MCP relie une application d’IA à des outils et à des données. Un connecteur est simplement une connexion MCP emballée, que vous activez dans un produit. A2A relie un agent à un autre agent.

Voici le portrait en octobre 2026 : comment les morceaux s’emboîtent, ce qui a changé cette année et comment décider ce qui mérite une connexion.

Trois couches, une seule image

Le projet A2A décrit la séparation en termes de direction : MCP est vertical, il approfondit ce qu’un seul agent peut faire, tandis qu’A2A est horizontal, il permet à des agents bâtis avec des cadres différents et exploités par des organisations différentes de se découvrir et de se partager le travail. Un agent A2A publie une fiche d’agent (agent card), une courte description lisible par machine de ce qu’il sait faire et de la façon de le joindre, pour qu’un autre agent puisse la lire et décider s’il lui délègue une tâche.

En août 2026, A2A s’est joint à l’Agentic AI Foundation, que dirige la Linux Foundation et qui accueille déjà MCP et la convention AGENTS.md. Pour un acheteur, c’est plus important qu’il n’y paraît : aucun des deux protocoles n’appartient maintenant à un seul fournisseur, de sorte qu’un outil que vous bâtissez ou achetez en s’appuyant sur eux risque moins de se retrouver orphelin.

Ce qui a changé dans MCP cette année

La spécification MCP actuelle est datée du 28 juillet 2026, et c’est la plus grosse révision à ce jour. Vous n’avez pas besoin des détails pour utiliser des connecteurs, mais trois changements expliquent pourquoi les produits ne se comportent plus tout à fait comme il y a un an.

• Des requêtes sans état. Les versions précédentes ouvraient une session par une poignée de main. Maintenant, chaque requête transporte sa propre version et ses propres capacités, ce qui rend les serveurs MCP plus faciles à exploiter à grande échelle dans le nuage.
• Des extensions. Des modules optionnels se trouvent hors du noyau : Tasks pour les longues tâches que l’on vérifie plus tard, Skills over MCP pour des instructions emballées, et MCP Apps pour de petits éléments interactifs, comme un graphique ou un formulaire, affichés dans la conversation.
• Du ménage. Certaines fonctions plus anciennes, dont Sampling et Roots, sont dépréciées, et une nouvelle politique garantit un préavis d’au moins douze mois avant tout retrait.

Ce qui n’a pas changé, c’est la position en matière de sécurité. La spécification dit toujours que les utilisateurs doivent comprendre et accepter les données partagées et les actions exécutées, que l’application hôte doit demander la permission avant d’appeler un outil, et que la description d’un outil doit être considérée comme non fiable, sauf si le serveur est digne de confiance. Elle admet aussi que le protocole ne peut faire respecter rien de tout cela à lui seul. C’est l’application que vous utilisez et les choix que vous faites qui s’en chargent.

Un exemple concret : un petit bureau, trois couches

Imaginez un cabinet de tenue de livres de cinq personnes.

1. Des connecteurs dans son assistant d’IA : le lecteur partagé (en lecture seule, dossiers clients seulement) et le calendrier de l’équipe.
2. Un serveur MCP sur mesure, écrit par un contractuel, qui expose exactement deux outils du logiciel comptable : find_invoice et list_unpaid_invoices. Aucun outil qui crée ou supprime quoi que ce soit.
3. A2A, plus tard et au besoin : si un fournisseur offre un agent de commande avec une fiche d’agent, l’agent du cabinet pourrait lui demander les dates de livraison au lieu qu’une personne téléphone.

Avant d’activer le serveur sur mesure, quelqu’un de l’équipe pose cette question à l’assistant :

Énumère chaque outil que cette connexion te donne, avec une ligne pour chacun sur ce qu’il peut lire, ce qu’il peut modifier et s’il peut envoyer quoi que ce soit à l’extérieur de notre entreprise. Si un outil peut créer, modifier, supprimer ou envoyer, dis-le en premier.

La réponse devient le registre de ce que le cabinet a approuvé, et on refait l’exercice à chaque mise à jour du serveur.

Que faut-il connecter, et que faut-il garder à l’écart?

Connectez ce dont une tâche a besoin, à la plus petite portée qui fonctionne. Un connecteur qui lit un seul dossier partagé est plus sûr qu’un connecteur qui lit tout votre lecteur, et un outil en lecture seule est plus sûr qu’un outil qui peut écrire. De bons premiers candidats sont les sources que vous fouillez déjà à la main : documentation, base de connaissances, calendrier, file de demandes de soutien. Chaque connexion rapporte quand elle vous épargne un copier-coller que vous faites tous les jours.

Gardez à l’écart, ou derrière l’approbation d’une personne, tout ce qui déplace de l’argent, envoie des messages en votre nom, supprime des dossiers, modifie des autorisations ou contient des données que la loi vous oblige à protéger, comme des dossiers de santé ou des pièces d’identité de clients. Méfiez-vous surtout des connexions qui réunissent trois choses : l’accès à des données privées, l’exposition à du contenu venant d’inconnus (courriels, pages Web, documents partagés) et un moyen d’envoyer de l’information vers l’extérieur. Un agent qui a les trois peut être piégé par du texte planté et laisser fuir ce qu’il voit.

Pour les liens d’agent à agent, ajoutez une règle : traitez l’autre agent comme une partie externe, pas comme un collègue. Lisez sa fiche d’agent, ne partagez que ce que vous mettriez dans un courriel à cette entreprise, et ne laissez jamais la demande d’un agent distant déclencher une action dans vos systèmes sans la même approbation qu’exigerait une demande humaine. Les protocoles facilitent la connexion; décider de ce qui y circule reste votre travail.