Brancher une IA sur les outils métier : le périmètre avant la démo

La démo a tenu en vingt minutes. L’assistant a listé des outils, ouvert une fiche CRM, résumé un historique, et proposé un brouillon de courriel. Dans la salle, personne n’a vu de bug. Le scénario illustratif qui suit est fréquent : on branche un connecteur MCP « pour montrer », on réutilise le même serveur pour la suite, et le premier accès réel arrive sans contrat d’accès écrit. Le connecteur n’est plus une vitrine — c’est un compte technique qui lit et écrit au nom de l’entreprise.

Le problème n’est pas le protocole MCP. C’est le modèle d’authentification et de permissions qu’on a collé dessus sans le nommer : quels outils sont exposés, avec quels droits applicatifs, où vivent les secrets, et quelles actions irréversibles exigent encore une validation humaine. Tant que ces quatre questions restent implicites, la démo réussit et la production hérite d’un accès trop large — le même type d’incident qu’une clé API permissive, vu sous l’angle agentique.

Une décision raisonnable… jusqu’au premier accès réel

La décision d’architecture qui revient le plus souvent est simple : tout exposer sur un seul serveur de connecteurs pour aller vite. CRM, messagerie, back-office, parfois un outil d’administration « le temps de la recette ». Pourquoi c’est raisonnable le jour J : la valeur se voit immédiatement, le métier comprend le geste, et l’équipe évite de négocier trois périmètres avant d’avoir une preuve. Aucune de ces intentions n’est absurde. Elles deviennent coûteuses dès que le même socle sert d’accès permanent.

Un connecteur MCP n’est pas une démo. C’est un canal d’appels vers des outils métier. Le protocole transporte l’appel ; il ne réduit pas les droits du compte technique derrière. Si ce compte peut tout lire, envoyer et exporter, l’agent le pourra aussi — y compris après une instruction malveillante glissée dans un contenu lu (mail, ticket, champ libre). Ce risque de détournement du dialogue est agentique : il n’est pas propre à MCP. Il apparaît dès qu’un agent enchaîne des outils avec des credentials trop larges. Côté back-end, chaque outil exposé est une surface d’accès métier, pas une slide de capacités.

Quatre couches qui ne se corrigent pas de la même façon

La couche protocole décrit comment l’agent découvre et appelle des outils. Elle ne décide pas du métier. Confondre « le connecteur répond » et « l’accès est borné » produit des correctifs cosmétiques : on change de modèle, et l’on laisse le même compte admin derrière.

La couche permissions applicatives porte vraiment le risque. Le compte technique hérite des droits CRM, mail, admin. Least-privilege ici signifie lire une fiche, chercher, créer un brouillon — pas « tout le CRM » parce que c’était plus simple à brancher. Si le compte peut tout faire, l’agent aussi. Aucun garde-fou conversationnel ne remplace une ACL déjà juste.

La couche secrets décide où vivent jetons et clés : hors du prompt, hors des captures de démo, hors des logs de dialogue — dans le coffre d’environnement, distincts entre recette et production. Un secret collé « pour simplifier les appels » dans le contexte de l’agent n’est plus un détail de config ; c’est un credential exposé au canal conversationnel.

La couche gouvernance porte les actions irréversibles. Envoi externe, suppression, export massif, changement de tarif : l’agent propose, un humain confirme. La lecture peut être plus large que l’écriture ; l’écriture silencieuse ne l’est jamais. Sans cette ligne écrite, la démo devient une chaîne d’actions que personne n’aurait validées à la main — non parce que le protocole serait « dangereux », mais parce que le contrat d’accès n’a pas séparé proposition et exécution.

Ces quatre couches coexistent. Les confondre produit des demi-correctifs : on retire un outil et l’on laisse le secret dans le dialogue ; ou l’on ajoute une confirmation humaine tout en gardant un compte admin. Le bon réflexe : nommer laquelle a cassé, puis tester.

Tests discriminants : hypothèse, geste, résultat attendu

Avant d’élargir le modèle ou d’ajouter des outils, on vérifie ce qui est réellement exposé. Les tests suivants séparent protocole, permissions, secrets et gouvernance sur un scénario illustratif contrôlé.

Hypothèse A — outils trop larges. Test : lister les outils réellement publiés par le serveur (pas la slide) et les comparer à une liste nominative écrite. Résultat attendu si l’hypothèse tient : au moins un outil hors besoin, ou un « tout le CRM ». Conclusion : restreindre la surface avant de parler d’expérience utilisateur.

Hypothèse B — compte technique non least-privilege. Test : inspecter les droits du compte derrière le connecteur côté application ; vérifier s’il peut faire plus que la liste d’outils. Résultat attendu si l’hypothèse tient : droits admin ou export massif alors que l’usage annoncé est un résumé. Conclusion : corriger l’ACL applicative ; le protocole ne la réduira pas tout seul.

Hypothèse C — secrets près du dialogue. Test : chercher jetons et clés dans prompts, variables de contexte, logs de conversation, captures de démo ; vérifier que recette et production ne partagent pas les secrets live. Résultat attendu si l’hypothèse tient : credential visible hors coffre, ou secret live réutilisé en staging. Conclusion : sortir les secrets du canal conversationnel — même isolement d’environnements que pour un callback mal branché, vu sous un autre angle dans l’URL de webhook qui dérive.

Hypothèse D — action irréversible sans confirm humaine. Test : tenter un envoi, une suppression ou un export via l’agent et vérifier s’il existe un cran de validation humaine obligatoire. Résultat attendu si l’hypothèse tient : exécution directe. Conclusion : séparer proposition et exécution avant d’élargir l’écriture.

Hypothèse E — journal non corrélé. Test : déclencher un appel outil et exiger une trace (qui, quel outil, quel identifiant métier, succès ou refus) joignable au dialogue. Résultat attendu si l’hypothèse tient : silence ou logs dispersés. Conclusion : sans corrélation, on ne départage pas une erreur métier d’un agent qui a trop bien « aidé ».

Ces cinq tests tiennent en une demi-journée. Ils collent à des artefacts — liste d’outils, ACL, coffre, cran humain, journal — plutôt qu’à un débat d’intention (« c’était juste une démo »).

Correction maintenant, prévention ensuite

La correction traite ce qui est déjà exposé. On restreint la liste d’outils au besoin écrit. On réduit les droits du compte technique au strict nécessaire. On retire les secrets du contexte de conversation et on sépare les coffres recette / production. On ajoute la validation humaine sur les actions irréversibles et un journal corrélé. On ne « demande pas à l’équipe d’éviter certains prompts » : on retire la capacité d’exécuter ce qui ne doit pas l’être sans confirm.

La prévention se pose avant le premier accès réel aux données qui ressemblent à la production. Périmètre nominatif au lancement. Compte least-privilege créé pour le connecteur, pas un admin « le temps de la recette » laissé après. Secrets uniquement hors dialogue. Environnements distincts. Règle écrite : lecture vs écriture vs irréversible. Revue quand on ajoute un outil — comme un changement d’ACL, pas comme une improvisation du vendredi soir.

Séparer les deux évite un piège classique : croire qu’un meilleur prompt suffit. Un prompt cadre le comportement ; il n’annule pas une permission trop large ni un secret exposé. Inversement, une ACL juste ne sauve pas une écriture irréversible sans cran humain.

Limites et ce que ce texte n’est pas

Ce texte décrit une classe fréquente de décisions d’accès agentique — connecteur ouvert trop large, secrets trop près du dialogue, validation absente — pas un incident nominatif. Aucun client, aucune stack interne. Les vecteurs listés ne sont pas exhaustifs : outil oublié, serveur partagé entre démo publique et production, contenu utilisateur traité comme instruction de confiance. Le bon réflexe reste hypothèse, test sur artefact, conclusion.

MCP n’est ici ni le sujet ni le coupable. C’est un protocole d’appel d’outils. Le risque vient du modèle d’auth, des credentials et de l’architecture d’accès qu’on met derrière. Quand le projet ne peut plus vivre sans un compte technique trop large « parce que la démo était impressionnante », ce n’est plus une intégration IA : c’est une dette d’accès.

Si vous branchez déjà un agent sur le CRM ou le mail et que le contrat d’accès n’est écrit nulle part, le cadre opérationnel — périmètre, secrets, validation humaine — est décrit sur la page IA / MCP.