---
title: "Étude de cas : des agents de données en libre-service sans divulguer les identifiants — onemcp"
description: "Une équipe de données illustrative voulait que ses analystes utilisent des agents IA sur les systèmes de production sans distribuer les identifiants de bases de données et d'entrepôt. L'authentification côté hôte d'onemcp a gardé les secrets hors de chaque poste."
ogTitle: "Étude de cas : des agents de données en libre-service, les secrets à leur place"
ogDescription: "Comment une équipe de données a donné à ses analystes des agents IA sur les outils de production tout en gardant chaque identifiant côté hôte dans un portail onemcp."
url: "https://onemcp.dev/fr/case-studies/data-team-secure-agents"
eyebrow: "Étude de cas · Données et gouvernance"
headline: "Donner aux analystes des agents sur les données de production — sans distribuer les clés."
summary: "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."
industry: "Données et analytique"
teamSize: "~25 analystes + une équipe plateforme de données de 4 personnes"
stack: "Snowflake · dbt · Postgres · API de métriques interne · GitHub"
illustrative: "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."
results:
  - "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"
quote: "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."
quoteAttribution: "Responsable plateforme de données (illustratif)"
---

## 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`, `describe` et `execute` plutô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.

## Études de cas associées

- [Une équipe plateforme regroupe 20 serveurs MCP derrière un point d'accès](/fr/case-studies/platform-team-mcp-gateway)
- [Un agent de support IA au régime de jetons](/fr/case-studies/support-agent-token-diet)