Le goulet d'étranglement n'a jamais été le modèle
Demandez aux entreprises pourquoi leur projet pilote d'IA s'est enlisé : la réponse concerne rarement le modèle.
Le modèle raisonnait suffisamment bien. Ce qu'il ne savait pas faire, c'était lire le contrat dans la gestion documentaire, vérifier le stock dans l'ERP, consulter l'historique client dans le CRM et réécrire le résultat — de façon fiable, avec les autorisations intactes, à chaque fois.
Le raisonnement est devenu une commodité. L'accès est la contrainte. Et c'est sur l'accès que les projets d'agents se transforment discrètement en projets d'intégration.
Le problème N×M
Avant qu'un standard existe, chaque connexion entre un agent et un système était du sur-mesure.
Avec quatre agents et six systèmes internes, vous mainteniez jusqu'à vingt-quatre intégrations propriétaires. Chacune avec sa gestion de l'authentification, sa sémantique d'erreur, sa propre façon de décrire ce qu'elle savait faire. L'API de l'ERP changeait, et vous corrigiez chaque agent qui la touchait.
Le secteur a déjà résolu ce problème plusieurs fois ailleurs — pilotes de périphériques, connectivité aux bases de données, serveurs de langage dans les éditeurs de code. La solution a toujours la même forme : cesser de construire des liaisons point à point et s'accorder sur un protocole au milieu. Les N×M intégrations deviennent alors N+M.
Le Model Context Protocol (MCP) est ce protocole pour les agents IA. Introduit par Anthropic comme standard ouvert et désormais implémenté bien au-delà, MCP définit comment une application d'IA découvre et appelle les capacités exposées par des systèmes externes.
Ce que MCP standardise réellement
MCP est un protocole client-serveur. Votre application d'IA est l'hôte et contient un ou plusieurs clients. Chaque client se connecte à un serveur MCP — un adaptateur léger placé devant un système, qui décrit de façon lisible par la machine ce que ce système sait faire.
Le serveur expose trois types de primitives :
- Outils — les actions que l'agent peut déclencher : créer une facture, rechercher des contrats, vérifier un stock. Chacun porte un schéma décrivant ses paramètres, afin que l'agent sache l'appeler correctement au lieu de deviner.
- Ressources — les données que l'agent peut lire. Un document, un enregistrement, une arborescence de fichiers. Adressables et récupérables sans effet de bord.
- Prompts — des modèles d'instructions réutilisables que le serveur propose pour les tâches courantes sur ce système, de sorte que la connaissance métier réside dans le connecteur au lieu d'être réinventée dans chaque agent.
Conséquence essentielle : décrire les capacités devient le travail du serveur, pas celui de l'agent. Un serveur MCP pour votre ERP s'écrit une fois, par quelqu'un qui comprend l'ERP, et tous les agents de votre organisation peuvent l'utiliser.
Pourquoi cela change l'architecture d'entreprise
Le déplacement architectural se décrit vite et pèse lourd en pratique : l'intégration devient un actif réutilisable au lieu d'un coût par projet.
Plusieurs conséquences en découlent.
Les connecteurs survivent aux agents. Les agents sont peu coûteux à réécrire et le seront souvent, à mesure que les modèles et les besoins évoluent. Un serveur MCP pour votre référentiel documentaire est une infrastructure stable. Les séparer signifie que le renouvellement des modèles ne menace plus votre couche d'intégration.
Une seule surface d'intégration à sécuriser. Au lieu d'auditer des identifiants dispersés dans le code des agents, vous disposez d'une frontière définie par système. Authentification, périmètre de droits, limitation de débit et journalisation vivent dans le serveur.
L'inventaire des capacités devient possible. Lorsque chaque système s'expose via le même protocole, vous pouvez enfin répondre à la question « que savent faire nos agents ? » — une question de gouvernance bien avant d'être technique.
La dépendance aux fournisseurs diminue. Un connecteur écrit contre un protocole plutôt que contre un framework d'agents particulier survit à un changement de framework ou de fournisseur de modèle.
À quoi ressemble un bon serveur
L'erreur classique sur un premier serveur MCP consiste à refléter l'API sous-jacente à l'identique — exposer quarante points d'entrée en quarante outils et considérer le travail terminé.
Cela produit un serveur techniquement correct que les agents utilisent mal. Un meilleur serveur est conçu autour des tâches, non des points d'entrée.
Comparons deux conceptions pour le même ERP :
| Conception calquée sur l'API | Conception orientée tâche |
|---|---|
| Cinq requêtes distinctes : client, commandes, lignes de commande, expéditions, factures | Un outil : récupérer l'historique de commandes d'un client |
| L'agent enchaîne cinq appels et peut se tromper dans l'ordre | Un appel, jointures correctes garanties côté serveur |
| Les modes de défaillance se multiplient à chaque appel | Défaillance traitée en un seul endroit |
Le serveur orienté tâche travaille davantage en interne et laisse à l'agent beaucoup moins d'occasions de se tromper. Quelques règles pratiques :
- Nommez les outils par intention, dans le vocabulaire que votre entreprise utilise déjà.
- Rédigez les descriptions pour un nouvel arrivant compétent. Elles sont lues par le modèle et déterminent principalement si un outil sera employé correctement.
- Renvoyez des erreurs qui suggèrent l'étape suivante, pas des traces d'exécution brutes. « Client introuvable — essayez la recherche par nom » est actionnable ; un 404 nu ne l'est pas.
- Gardez les réponses légères. Chaque champ inutile consomme du contexte dont l'agent a besoin pour raisonner.
- Séparez la lecture de l'écriture. Outils distincts, droits distincts, traitement d'audit distinct.
Le contrôle d'accès est la partie difficile
MCP standardise la description des capacités. Il ne décide pas qui a le droit de les utiliser — et c'est précisément là que les déploiements en entreprise deviennent délicats.
Trois questions à trancher avant qu'un serveur touche des données de production.
Quelles autorisations s'appliquent ? Un agent agissant pour le compte d'une personne devrait hériter des droits de cette personne, et non détenir un compte de service qui voit tout. La commodité du compte de service au démarrage est la façon la plus courante dont les projets d'agents acquièrent un problème d'autorisations qu'ils ne peuvent plus démêler ensuite.
Quelle est la portée des dégâts de chaque outil ? Un outil de lecture sur une réplique de reporting et un outil d'écriture qui déclenche des paiements appartiennent à des catégories de risque différentes, avec des exigences de validation différentes. Les traiter de la même manière revient soit à trop restreindre l'inoffensif, soit à trop peu restreindre le dangereux.
La traçabilité est-elle suffisante ? Chaque appel doit être imputable — quel agent, pour le compte de qui, avec quels arguments, avec quel résultat. Dans les environnements suisses et européens régulés, ce n'est pas facultatif, et l'ajouter après coup est nettement plus difficile.
La localisation des données ne disparaît pas non plus parce qu'un protocole est impliqué. Le serveur MCP est exactement l'endroit où vous imposez qu'un document ne quitte jamais une juridiction donnée — un point de contrôle à concevoir délibérément plutôt qu'à découvrir plus tard.
Là où MCP s'arrête
MCP est un protocole de connexion. Ce n'est pas un framework d'agents, et ce n'est pas de l'orchestration.
Il ne dit rien sur la façon de découper le travail entre plusieurs agents, de conserver l'état au fil d'un processus long, de gérer les reprises et les actions compensatoires, ni d'évaluer si un agent a bien fait son travail. Ces décisions de conception restent les vôtres — notre orchestration d'IA traite la couche située au-dessus de la couche de connexion.
Nommer clairement cette frontière est utile. MCP supprime une catégorie de travail d'intégration sans valeur différenciante. Il ne supprime pas la nécessité de penser la conception des processus, et une équipe qui attend autre chose sera déçue par un protocole par ailleurs solide.
Comment démarrer
Le scénario d'échec ici, c'est un programme de plateforme de six mois qui connecte tout et ne livre rien. Inversez-le.
- Choisissez un flux avec une friction réelle — quelque chose pour lequel des gens recopient aujourd'hui des données entre deux systèmes.
- Construisez le plus petit serveur qui le supporte. Deux ou trois outils orientés tâche, en lecture seule si le flux le permet.
- Exploitez-le en mode fantôme. L'agent produit un résultat qu'un humain compare au processus actuel, sans qu'aucune action soit engagée.
- Accordez l'écriture à un seul outil dès que les résultats fantômes sont constamment corrects, avec une validation en amont.
- Généralisez seulement ensuite. Votre deuxième serveur sera meilleur, parce que le premier vous aura appris ce que vos agents demandent réellement.
Chaque étape livre quelque chose d'utilisable, et cet enchaînement produit des intégrations qui fonctionnent plutôt qu'une stratégie d'intégration.
Les organisations qui tireront une valeur durable des agents ne seront pas celles dotées des plus grands modèles. Ce seront celles dont les systèmes sont proprement accessibles, correctement cloisonnés et entièrement auditables — car la génération de modèles changera encore l'an prochain, la couche d'intégration non.
Connecter des agents à des systèmes qui n'ont jamais été conçus pour eux constitue l'essentiel du travail réel. Découvrez nos déploiements en production ou parlez à notre équipe de ce à quoi ressemblerait une architecture accessible aux agents pour votre stack.