Étude de cas · Données et gouvernance
Donner aux analystes des agents sur les données de production — sans distribuer les clés.
Une équipe de données souhaitait des agents IA en libre-service sur l'entrepôt et les API internes, sans pour autant que chaque poste d'analyste détienne des identifiants de production. Un portail onemcp a maintenu l'authentification côté hôte et centralisé les accès.
- Secteur
- Données et analytique
- Équipe
- ~25 analystes + une équipe plateforme de données de 4 personnes
- Stack technique
- Snowflake · dbt · Postgres · API de métriques interne · GitHub
# Synthèse
- Aucun identifiant de production sur les machines des analystes
- 1 portail comme point central de contrôle des accès
- Nouveaux outils ajoutés de façon centralisée, non poste par poste
Scénario illustratif inspiré de déploiements onemcp courants. L'équipe décrite est une composition et non un client nommé ; les chiffres sont représentatifs et non mesurés.
Contexte
Une équipe de données d'environ vingt-cinq analystes voulait utiliser des agents IA pour le quotidien : écrire des requêtes, retrouver des définitions de métriques, vérifier la santé des pipelines. Les outils dont elle avait besoin — Snowflake, dbt, une API de métriques interne, quelques réplicas Postgres — disposaient tous de serveurs MCP.
Le point bloquant n'a jamais été l'agent. C'était la question que la sécurité posait chaque fois : *où vivent les identifiants ?*
Le défi
La voie évidente consistait à confier les serveurs MCP à chaque analyste et à le laisser s'authentifier. La sécurité n'aurait pas donné son accord, et elle avait raison de s'y refuser.
- Les identifiants se dissémineraient. Vingt-cinq analystes détenant chacun sur leur poste des identifiants d'entrepôt et d'API, ce sont vingt-cinq endroits où un secret peut fuiter, sans moyen propre de le faire tourner.
- L'accès était tout ou rien. Confier un serveur revenait à confier tout ce que son jeton permettait, avec une visibilité quasi nulle sur qui possédait quoi.
- La gouvernance ne passait pas à l'échelle. Examiner et révoquer les accès poste par poste n'était un processus que personne ne voulait porter.
L'approche
L'équipe plateforme de données a exploité un unique portail onemcp comme frontière entre les analystes et les systèmes de production.
- Les identifiants restent côté hôte. Chaque amont est authentifié une fois, dans le portail. L'OAuth amont natif et les jetons y vivent — jamais sur la machine d'un analyste, jamais dans un dépôt. Les agents des analystes se connectent au portail, non aux bases de données.
- L'accès est centralisé. Quels serveurs sont disponibles, et pour qui, se décide en un seul endroit. Intégrer un nouvel outil est une modification du portail ; révoquer un accès n'exige de toucher à la configuration de personne.
- Le catalogue reste léger dans le contexte. Via le Code Mode, le portail expose
search,describeetexecuteplutôt que le schéma de chaque outil — les agents ne récupèrent donc que les outils nécessaires à la tâche, et le contexte de l'analyste reste tourné vers l'analyse.
Les résultats
- Aucun identifiant de production sur les postes. Les secrets vivent dans le portail. Le départ d'un analyste ou la perte d'une machine n'est plus une urgence de rotation d'identifiants.
- Un seul lieu de gouvernance. La sécurité examine et gère les accès depuis le portail, et non à travers vingt-cinq configurations individuelles.
- Le libre-service sans la dispersion. Les analystes ont obtenu leurs agents ; l'équipe plateforme a conservé un point de contrôle unique et auditable — et ajouter l'outil suivant n'est qu'une seule modification centralisée.
Le déclic n'était pas l'agent lui-même — c'était de pouvoir lui dire oui. Les accès vivent dans le portail : la sécurité n'avait qu'une seule chose à examiner, au lieu de trente postes.