MCP en entreprise : brancher les agents sur le SI sans Shadow AI

Le vrai sujet n'est plus « quel agent ». C'est « comment il touche le SI ».

Dès qu'un agent peut lire un mail, créer un événement ou interroger un référentiel, il sort du bac à sable du chat. Il devient un acteur du système d'information. Or la plupart des déploiements improvisés passent encore par des scripts maison, des clés API partagées, des plugins jetables. Résultat : des outils invisibles pour la DSI, des comptes trop puissants, des traces impossibles à relire. C'est exactement le Shadow AI décrit côté plateforme dans AI for leaders comme couche d'IA de confiance.

MCP (Model Context Protocol) propose autre chose. Un contrat commun pour exposer des outils aux agents : schéma, découverte, session. Pas une nouvelle « app IA », une couche d'intégration que la DSI et le CTO peuvent gouverner.

Un contrat outil lisible

Schéma, découverte et session standardisés : l'agent sait ce qu'il peut appeler, et le SI sait ce qui a été exposé.

Pourquoi les scripts et plugins jetables ne tiennent pas

Un script Bash ou un plugin ad hoc résout le PoC. En production, il devient une dette. Chaque équipe invente son format d'arguments, ses timeouts, sa gestion d'erreurs. Personne ne partage le même inventaire d'outils. Quand l'agent échoue, on ne sait pas si le modèle a mal compris, si l'outil a changé, ou si un compte de service a dérivé.

MCP formalise le périmètre. L'outil déclare ce qu'il accepte et ce qu'il renvoie. Le client (l'agent, la plateforme) découvre le catalogue au runtime. La session porte le contexte d'appel. Ce n'est pas magique, mais c'est comparable à ce qu'une API REST bien versionnée apporte face à des scripts dispersés. Pour les workflows agents en général, voir aussi Agents IA en entreprise.

Identité réelle, pas un compte de service omnipotent

Le piège classique : un service account qui peut tout faire « pour que l'agent marche ». Pratique en démo, catastrophique en audit. Dès qu'un outil agit pour un utilisateur, l'appel doit porter son identité (OAuth, délégation, scopes limités), pas un super-compte partagé.

MCP ne remplace pas l'IAM du SI. Il s'y branche. L'objectif : l'agent qui crée une réunion le fait avec les droits de la personne (ou d'un rôle explicite), pas avec une clé oubliée dans un coffre. La CNIL et le RGPD rappellent la même exigence sous un autre angle : savoir qui traite quoi, pour quel but, avec quelle base légale. Un compte de service omnipotent efface cette chaîne.

Délégation plutôt que dieu

OAuth et scopes par outil : chaque appel reste rattaché à un utilisateur ou à un rôle nommé, pas à une clé magique.

Catalogue gouverné contre Shadow AI

Sans catalogue, chaque équipe branche « son » connecteur. Avec un catalogue MCP approuvé, la plateforme publie les outils autorisés (messagerie, calendrier, tickets, lecture documentaire…) et refuse le reste. C'est le même réflexe que pour les applications SaaS : allowlist, revue, retrait.

Le Shadow AI naît souvent d'une bonne intention (gagner du temps) et d'une absence d'alternative contrôlée. Un catalogue MCP utile bascule l'équation : le chemin le plus simple devient aussi le chemin gouverné. Automatisation « workflow » et agents ne se substituent pas l'un à l'autre ; la comparaison n8n vs AI for leaders reste utile pour choisir le bon outil. MCP, lui, standardise comment l'agent touche le SI.

Audit : ce qui a été appelé, par qui, avec quel résultat

Un comité de risques ne demande pas « est-ce que le modèle est intelligent ». Il demande : quels outils ont été invoqués, sur quelles données, avec quel succès, pour quel utilisateur. Les appels MCP doivent être journalisés comme le reste du SI : horodatage, identité, outil, paramètres non secrets, statut, corrélation avec la session agent.

Sans ça, l'observabilité s'arrête au prompt. Avec ça, on peut rejouer un incident, répondre à un audit, et couper un outil sans redéployer toute la plateforme. Les cadres comme le NIST AI RMF insistent sur cette boucle inventaire / mesure / contrôle. MCP fournit un point d'accroche technique pour la tenir côté outils.

Premier terrain : messagerie et calendrier

ERP et GED viendront. Le premier terrain réaliste, c'est souvent Outlook (ou l'équivalent) : lire / résumer un fil, proposer un créneau, créer un événement. Le risque métier est réel, mais le périmètre est borné, l'IAM existe déjà, et la valeur est immédiate pour les directions.

C'est aussi là qu'on valide le pattern MCP en conditions réelles : serveur d'outils derrière l'identité entreprise, scopes mail/calendrier, revue du catalogue, dashboards d'audit. Une fois ce socle solide, élargir vers tickets, CRM ou référentiels documentaires devient un sujet de catalogue, pas une réinvention du contrat outil.

Conclusion

MCP n'est pas un gadget de plus dans la stack agents. C'est le moyen de brancher ces agents sur le SI avec un contrat clair, une identité réelle, un catalogue gouverné et des appels auditables. Sans ça, chaque connecteur improvisé recrée du Shadow AI. Avec ça, la DSI garde la main pendant que les métiers avancent.

Pour le cadre « couche de confiance » côté plateforme, relire AI for leaders comme couche d'IA de confiance. Pour la conception des workflows agents, Agents IA en entreprise.