Dans un précédent article, j'ai expliqué que les intergiciels sont devenus le plan de contrôle de l'IA pour les entreprises. Alors que les grands modèles linguistiques passent de la génération de recommandations à la prise de mesures, le protocole MCP (Model Context Protocol) marque un tournant important dans la manière dont les systèmes d'IA interagissent avec les outils et les données réels. En permettant aux modèles d'invoquer directement des outils, le protocole MCP raccourcit le chemin entre l'intention et l'exécution et modifie la manière dont le travail est effectué au sein des systèmes d'entreprise.
Cette rapidité est puissante, mais elle révèle également une lacune. Lorsque l'exécution devient facile, la coordination, le contrôle et la responsabilité deviennent plus difficiles. Le MCP traite le problème d'intégration N×M entre les modèles et les outils, mais il ne définit pas comment les actions sont régies, surveillées ou limitées une fois que les agents opèrent au sein des systèmes de production.
Si l'autonomie des agents doit évoluer sans introduire d'instabilité ou de risque, l'orchestration et la gouvernance ne peuvent être facultatives. La question abordée dans cette deuxième partie est simple, mais cruciale : que doit réellement garantir un plan de contrôle IA pour que les agents autonomes fonctionnent de manière sûre et fiable dans l'entreprise ?
Premier mode de défaillance : des outils d'intégration au lieu de capacités
La plupart des adoptions du MCP commencent de la même manière. Les équipes exposent ce qu'elles possèdent déjà :
- Un script devient un outil
- Une requête devient un outil
- Un microservice devient un outil
- un workflow un outil
Au niveau local, cela fonctionne. Cela réduit le temps de configuration et montre des progrès immédiats. Au niveau de l'entreprise, cela crée un problème qui apparaît généralement plus tard, lors du premier incident qui dépasse les limites de l'équipe ou du système.
Un outil n'est pas quelque chose que l'entreprise peut raisonner. Les outils décrivent des mécanismes. Les entreprises raisonnent en termes de résultats. Ce qui intéresse réellement l'entreprise ressemble davantage à ceci :
- À bord d'un client
- Résoudre un litige concernant la facturation
- Fournir un employé
- Effectuer un remboursement
- Clôturer un incident avec des garde-fous
- Créer une opportunité et la valider par rapport à la politique
C'est dans l'écart entre ces deux perspectives que commence l'expansion du MCP. Un agent ne comprend pas la signification organisationnelle à moins que vous ne l'encodiez. Il ne sait pas que cinq appels d'outils valides individuellement, exécutés dans le mauvais ordre, peuvent produire le même impact en aval qu'un changement de production défectueux. Et comme les décisions des agents sont probabilistes, le chemin d'exécution peut varier d'une exécution à l'autre.
Cela conduit au premier principe d'un véritable plan de contrôle IA : exposer moins d'éléments, et exposer des éléments de plus haut niveau.
Au lieu d'exposer chaque action atomique, exposez les capacités qui représentent les résultats que vous êtes prêt à soutenir :
- Pas « mettre à jour le dossier client »
- Pas « créer une facture »
- Ne pas « appliquer la remise »
- Pas « envoyer un e-mail »
Exposez le « problème de facturation à résoudre » et masquez les mécanismes derrière un flux de travail contrôlé qui impose par défaut les commandes, les nouvelles tentatives, les approbations, le masquage et la journalisation.
Ce que le plan de contrôle doit garantir
Une fois que vous passez des outils aux capacités, le rôle du plan de contrôle devient plus clair. Il existe pour fournir un ensemble spécifique de garanties d'exécution. Ces garanties permettent à l'autonomie des agents de fonctionner en toute sécurité au sein des systèmes de production.
1. Abstraction des capacités
Les agents ne doivent pas assembler dynamiquement les composants internes de l'entreprise. Ils doivent invoquer des capacités stables et versionnées qui reflètent l'intention commerciale. En pratique, cela signifie :
- Une fonctionnalité « client embarqué » au lieu d'un ensemble d'outils CRM, de facturation et d'assistance
- Entrées et sorties qui décrivent l'intention plutôt que les détails du schéma interne
- Versionnement explicite, car les règles métier changent même lorsque les agents ne changent pas.
C'est là que les plateformes d'intégration ont toujours joué un rôle discret mais essentiel, en traduisant de nombreuses API système en un processus métier unique et contrôlable.
2. Application des politiques au moment de l'action
Le MCP permet la connexion, pas le contrôle. Un plan de contrôle de la production doit décider si une action doit être effectuée avant qu'elle ne se produise. Cela nécessite de répondre à des questions telles que :
- Cet agent est-il autorisé à effectuer cette action dans cet environnement pour ce segment de clientèle ?
- La portée des données est-elle appropriée, notamment en ce qui concerne le masquage, le traitement des informations personnelles identifiables et les contraintes réglementaires ?
- Sommes-nous dans les limites des taux, des fenêtres de changement ou des règles de séparation des tâches ?
- Cette action nécessite-t-elle une approbation humaine ou une validation secondaire ?
À mesure que les écosystèmes MCP se développent, la fragmentation des identités devient un risque réel. La multiplicité des outils, des identifiants et des contrôles d'accès incohérents ne sont pas des problèmes théoriques. Ce sont eux qui exposent les entreprises à des violations de sécurité.
3. État et idempotence
Les agents réessaient. Les frameworks réessaient. Les réseaux échouent de manière partielle et confuse. Sans un état durable, l'automatisation utile se traduit par des remboursements en double, des tickets en double et des modifications de compte en double. Un véritable plan de contrôle rend cela explicite grâce à :
- Identifiants de corrélation entre les étapes
- Clés de déduplication
- Reprises sécurisées et actions compensatoires
- Des modes de défaillance clairs plutôt que des explications narratives
4. Orchestration déterministe autour de décisions probabilistes
Laissez l'agent décider quoi faire. Ne le laissez pas décider comment l'exécution se déroule. La séparation est intentionnelle :
- La couche probabiliste interprète l'intention et sélectionne une capacité.
- La couche déterministe gère l'orchestration, l'ordonnancement, la gestion des erreurs et la restauration.
Dans la première partie, j 'ai mis en garde contre les chemins d'exécution découverts au moment de l'exécution. Voici comment ce risque peut être maîtrisé sans supprimer l'autonomie.
5. Observabilité favorisant la responsabilisation
Vous n'avez pas besoin de plus de journaux. Vous avez besoin de réponses :
- Qu'a tenté de faire l'agent ?
- Quelle capacité a été invoquée ?
- Quelles données ont été consultées et quelles données ont été masquées ?
- Quels systèmes en aval ont été touchés, et dans quel ordre ?
- Qu'est-ce qui a changé, et à qui revient le mérite ?
Si votre explication post-incident se termine par « le modèle a décidé », le système n'est pas prêt pour la production.
6. Supervision humaine dans le cadre le workflow
L'intervention humaine est souvent considérée comme un recours. Dans les systèmes matures, il s'agit d'une caractéristique de conception. La surveillance fonctionne mieux lorsqu'elle est structurée :
- Approbations supérieures aux seuils définis
- Examens des actions sensibles telles que les modifications d'accès ou les exportations de données
- Acheminement vers le propriétaire correct plutôt que vers une file d'attente générique
7. Simulation et gestion du changement
Les capacités évoluent et doivent être traitées comme des logiciels. Cela signifie :
- Exécution en mode bac à sable
- Rejouer contre des cas historiques
- Détection des dérives lorsque les résultats changent sans mise à jour de version
- Chemins de restauration définis
MCP facilite l'ajout d'outils. Un plan de contrôle permet de faire évoluer les capacités en toute sécurité.
Où s'arrête le MCP et où commence la responsabilité de l'entreprise ?
Considérée dans son ensemble, l'architecture est simple :
- Les agents et les applications interagissent avec les utilisateurs.
- MCP fournit la couche de protocole standard.
- L'entreprise expose un catalogue de capacités régies.
- Une couche d'intégration et d'orchestration garantit l'exécution.
- Les systèmes d'enregistrement restent des systèmes d'enregistrement.
MCP fonctionne comme un connecteur universel. Il ne s'agit pas d'un système d'exploitation. Les entreprises ont toujours besoin d'un contrôle centralisé sur les autorisations, les politiques, les processus et les audits, même lorsque l'exécution se fait à proximité des données pour des raisons de latence, de confidentialité ou de souveraineté.
C'est pourquoi l'intégration et l'orchestration refont discrètement surface en tant que plan de contrôle pour les systèmes agents. Elles fournissent la couche de gouvernance que le MCP omet intentionnellement.
Comment éviter la prolifération des MCP avant qu'elle ne s'enracine
Si les équipes ont déjà adopté le MCP pour tout ce qu'elles possèdent, la solution n'est pas une note de service. Il s'agit plutôt de changer la définition même du succès.
Tout d'abord, arrêtez les outils d'intégration et commencez à intégrer des capacités. Faites de la création de capacités le produit du travail. Les équipes peuvent toujours créer des outils en interne, mais ce qui est publié doit avoir un objectif, des contraintes, une propriété et une auditabilité clairs.
Deuxièmement, centralisez l'application tout en décentralisant la contribution. Laissez les équipes contribuer librement à l'ensemble des capacités, mais standardisez l'identité, la politique, la journalisation, les tests et le déploiement. Cela empêche l'innovation de se transformer en instabilité opérationnelle.
Troisièmement, considérez l'observabilité comme une exigence produit. Si vous ne pouvez pas répondre rapidement à la question « que s'est-il passé ? », l'autonomie finira par être réduite. Cette évolution est prévisible et correspond à celle décrite précédemment.
Ce que cela signifie concrètement
L'adoption du MCP continuera de s'accélérer. L'écosystème va se développer. Le nombre d'outils va se multiplier.
Les organisations qui réussiront ne seront pas celles qui disposent du plus grand nombre d'outils compatibles MCP. Ce seront celles qui laisseront leurs agents agir sans que cela ne se traduise par un chaos dans l'exécution des tâches.
Cela nécessite un plan de contrôle qui ait une opinion tranchée sur les résultats.
- Les agents restent flexibles
- L'exécution reste stable
- L'autonomie reste gouvernable
L'infrastructure qui rend cela possible ne sera pas tape-à-l'œil. Elle ne sera pas à la mode. Mais c'est ce sur quoi les entreprises se mettront d'accord une fois que l'exécution par des agents aura atteint ses limites opérationnelles réelles.
Si vous réfléchissez déjà à la manière de passer de l'expérimentation MCP à une autonomie régulée et adaptée à la production, c'est le moment idéal pour découvrir comment fonctionne concrètement un plan de contrôle basé sur l'intégration.
Réservez une démonstration pour découvrir comment coordonner, gérer et observer l'exécution des agents sans sacrifier la rapidité.
L'intelligence est facultative. La coordination ne l'est pas.
