> ## Documentation Index > Fetch the complete documentation index at: https://docs.devinenterprise.com/llms.txt > Use this file to discover all available pages before exploring further. # Connecter Devin à MongoDB > Connectez Devin à MongoDB Atlas avec un utilisateur de base de données aux droits restreints, un compte de service Atlas, mongosh et l'Atlas CLI dans un blueprint, ou le serveur MCP MongoDB. Devin peut travailler avec vos données MongoDB comme le ferait un ingénieur disposant d'une chaîne de connexion en lecture seule : examiner ce que contiennent réellement les collections, déterminer pourquoi une requête est lente, tester une migration dans une base de données sandbox et ouvrir une pull request (PR). Ce guide explique comment configurer tout cela avec des identités créées spécifiquement pour Devin, afin qu'il ne s'exécute jamais sous l'identité de l'un de vos ingénieurs. Tout reste dans votre compte Atlas : un utilisateur de base de données, un compte de service, les outils MongoDB installés via un [blueprint d'environnement](/fr/onboard-devin/environment/blueprints) et, si vous le souhaitez, un serveur MCP. Commencez avec des droits limités (production en lecture seule), puis élargissez les rôles ultérieurement : ce sont les rôles qui définissent le périmètre, et vous les modifiez dans Atlas sans toucher à Devin.

Deux plans, deux identités

| Plan | Ce à quoi il donne accès | Identité de Devin | Identifiants | | - | - | - | - | | **Plan de données** | Bases de données, documents, index, `explain()` | Un **utilisateur de base de données** | Nom d'utilisateur et mot de passe dans une chaîne de connexion | | **Plan de contrôle** | Clusters, index Search, Performance Advisor, logs des requêtes lentes, utilisateurs de base de données, listes d'accès | Un **compte de service Atlas** | Client ID et client secret OAuth 2.0 | Un utilisateur de base de données ne peut pas appeler l'API d'administration Atlas, et un compte de service ne peut pas lire de documents via l'API. La plupart des équipes commencent uniquement par le plan de données, puis ajoutent le compte de service lorsque Devin a besoin de Performance Advisor ou des logs des requêtes lentes (clusters dédiés, M10 et au-delà). Deux mises en garde : * Un compte de service capable de créer des utilisateurs de base de données (`GROUP_OWNER`, `GROUP_DATABASE_ACCESS_ADMIN`) peut se créer lui-même une identité sur le plan de données. C'est précisément ce que fait le serveur MCP MongoDB lorsqu'on lui demande de se connecter à un cluster (option B). * Les données des requêtes lentes contiennent les valeurs littérales des requêtes.

Choisir le mode de connexion de Devin

Les trois approches reposent sur le même accès réseau (Étape 1) et les mêmes identités (Étape 2) ; elles diffèrent par ce que Devin est autorisé à détenir. | Approche | Idéal pour | Configuration | | - | - | - | | [**Option A : CLI dans un blueprint**](#option-a-cli-in-a-blueprint) | Tâches que Devin exécute et répète dans un repo : migrations, backfills, données de seed, tests sur des données au format réaliste | Quatre Devin Secrets et un blueprint succinct. Commencez par là. | | [**Option B : serveur MCP MongoDB**](#option-b-mongodb-mcp-server) | Découverte de schéma et analyse de requêtes et d'index sous forme d'outils, avec les garde-fous `--readOnly` et `--indexCheck` | Un serveur MCP STDIO personnalisé utilisant les mêmes credentials. Vient compléter l'Option A. | | [**Option C : plugin MongoDB Atlas**](#option-c-mongodb-atlas-plugin) | Questions sur Atlas et lectures à l'échelle du projet, sans stocker d'identifiant MongoDB dans la session | Plugin du Marketplace, connexion OAuth avec un utilisateur Atlas dédié ; mode d'accès à l'organisation défini sur **Read**. |

Pourquoi connecter Devin à MongoDB ?

* **Le schéma est dans les documents.** MongoDB ne dispose pas d'`information_schema`, et les modèles Mongoose ou Prisma finissent par diverger de ce qui est réellement stocké. Devin échantillonne les collections en production et travaille à partir de leur structure réelle. * **Le cycle d'optimisation des requêtes lentes se boucle en une seule session.** Devin consulte Performance Advisor et le log des requêtes lentes, exécute `explain()` sur la collection réelle, identifie le code qui émet la requête et ouvre une pull request (PR) contenant le correctif et l'index proposé. * **Les rôles de l'utilisateur de la base de données définissent le périmètre d'action de Devin.** Commencez en lecture seule sur la production, avec une sandbox `devin_dev` pour les écritures : chaque action est consignée dans les logs Atlas sous l'identité propre de Devin.

Prérequis

**Atlas** * Un projet disposant d'un cluster. * Le rôle `Organization Owner` pour créer un compte de service ; le rôle `Project Owner` pour l'utilisateur de la base de données et les listes d'accès. **Devin** * L'autorisation de modifier le [blueprint d'environnement](/fr/onboard-devin/environment/blueprints) et d'ajouter des [Secrets](/fr/product-guides/secrets). * Pour les options MCP, l'autorisation **Manage MCP Servers**. **Réseau** * Les adresses IP de Devin ajoutées à la liste d'accès IP du projet (Étape 1). * Si vous utilisez une [politique réseau](/fr/product-guides/security-profiles) Devin, autorisez `*.mongodb.net` et `cloud.mongodb.com`, ainsi que les hôtes depuis lesquels le blueprint installe ses composants : `pgp.mongodb.com` et `repo.mongodb.org` (Option A), `registry.npmjs.org` et `nodejs.org` (Option B). Le pilote se connecte sur le port 27017, et non sur le port 443 ; comme les entrées de la politique sont des hostnames ou des CIDR, aucun port n'est à définir. Les builds du snapshot s'exécutent avec la même politique.

Étape 1 : ouvrir l’accès réseau

Atlas refuse les connexions provenant d’adresses IP absentes de la liste d’accès IP du projet. Ajoutez les adresses IP indiquées dans la section [Mise en liste d’autorisation des adresses IP](/fr/admin/common-issues#ip-allowlisting), sans vous fier à votre mémoire. Les tenants dédiés disposent de leurs propres adresses de sortie ; vérifiez-les auprès de votre équipe de compte. ```bash theme={null} atlas accessLists create --type ipAddress --comment "Devin" --projectId atlas accessLists create --type cidrBlock --comment "Devin" --projectId ``` La liste contient à la fois des adresses individuelles et une plage CIDR ; utilisez `--type ipAddress` pour les adresses individuelles et `--type cidrBlock` pour la plage. Si votre organisation impose une liste d'accès API pour les comptes de service, ajoutez les mêmes adresses IP sur la page du compte de service dans Atlas. Les appels provenant d'une adresse IP absente de la liste échouent avec une erreur `403`.

Étape 2 : Créer les identités de Devin

Utilisateur de base de données

Lecture seule sur les bases de données de production, lecture/écriture dans une sandbox, avec un périmètre limité à des clusters spécifiques : ```bash theme={null} atlas dbusers create \ --username devin-sessions \ --password "" \ --role read@analytics,read@billing,readWrite@devin_dev \ --scope \ --projectId ``` Sans `--scope`, l'utilisateur peut accéder à tous les clusters du projet. Utilisez un [rôle de base de données personnalisé](https://www.mongodb.com/docs/atlas/security-add-mongodb-roles/) lorsque les rôles intégrés ne permettent pas de définir le périmètre souhaité. Générez le mot de passe avec un gestionnaire de mots de passe et veillez à ce qu'il ne reste pas dans l'historique du shell. Copiez la chaîne de connexion de cet utilisateur ; ne confiez pas à Devin l'utilisateur administrateur du cluster.

Compte de service (uniquement si Devin a besoin du plan de contrôle)

Dans Atlas, ouvrez **Identity & Access > Applications** au niveau de l'organisation. Commencez en lecture seule et choisissez la durée de vie du Client Secret la plus courte que permet votre politique de rotation. | | Rôles | Pourquoi | | - | - | - | | **Accorder** | `ORG_MEMBER` sur l'organisation ; `GROUP_READ_ONLY` et `GROUP_DATA_ACCESS_READ_ONLY` sur chaque projet | Socle en lecture seule | | **Ajouter uniquement si nécessaire** | `GROUP_SEARCH_INDEX_EDITOR` | Devin gère les index Search | | **Jamais** | `GROUP_OWNER`, `GROUP_DATABASE_ACCESS_ADMIN` | L'un comme l'autre permet à Devin d'étendre ses propres accès | La ligne **Jamais** est particulièrement importante avec l'option B. Si le compte de service peut créer des utilisateurs de base de données, l'outil `atlas-connect-cluster` du serveur MCP crée un utilisateur temporaire sur l'ensemble du cluster (`readAnyDatabase`, ou `readWriteAnyDatabase` sans `--readOnly`), contournant ainsi les rôles par base de données définis sur `devin-sessions`. Cet utilisateur reste actif pendant 4 heures, sauf si l'outil de déconnexion MCP le supprime avant.

Étape 3 : Connecter Devin

Option A : CLI dans un blueprint

1. Ajouter des Devin Secrets

Dans l’onglet **Secrets** du blueprint : | Secret | Valeur | | - | - | | `MONGODB_URI` | La chaîne de connexion de `devin-sessions`, par ex. `mongodb+srv://devin-sessions:@cluster0.abcde.mongodb.net/`. Encodez le mot de passe en pourcentage (percent-encoding). | | `MONGODB_ATLAS_CLIENT_ID` | Client ID du compte de service (`mdb_sa_id_...`), si vous utilisez le plan de contrôle | | `MONGODB_ATLAS_CLIENT_SECRET` | Client Secret du compte de service | | `MONGODB_ATLAS_PROJECT_ID` | ID de projet par défaut | Les secrets sont injectés à chaque session : la rotation d’une valeur ne nécessite donc aucun rebuild. L’Atlas CLI lit le Client ID et le Client Secret dans ces variables d’environnement, ce qui rend `atlas auth login` inutile. À la première utilisation, elle met en cache un token d’accès dans `~/.config/atlascli/config.toml`. Ce n’est pas un problème au sein d’une session, mais ne créez jamais ce fichier dans `initialize`.

2. Ajouter le blueprint

```yaml theme={null} initialize: - name: Install the Atlas CLI and mongosh run: | curl -fsSL https://pgp.mongodb.com/server-8.0.asc \ | sudo gpg --batch --yes -o /usr/share/keyrings/mongodb-server-8.0.gpg --dearmor echo "deb [ arch=amd64,arm64 signed-by=/usr/share/keyrings/mongodb-server-8.0.gpg ] https://repo.mongodb.org/apt/ubuntu jammy/mongodb-org/8.0 multiverse" \ | sudo tee /etc/apt/sources.list.d/mongodb-org-8.0.list sudo apt-get update sudo apt-get install -y mongodb-atlas-cli mongodb-mongosh atlas --version && mongosh --version knowledge: - name: mongodb-access contents: | Connect to MongoDB with `mongosh "$MONGODB_URI"`; the URI is a Devin Secret. The Atlas CLI authenticates as a service account from MONGODB_ATLAS_CLIENT_ID and MONGODB_ATLAS_CLIENT_SECRET, with MONGODB_ATLAS_PROJECT_ID as the default project. Do not run `atlas auth login`, do not ask for a username, password, or API key, and never write the connection string into a file, script, log, or PR. Production databases are read-only; write only to the devin_dev database. Ship schema, index, and migration changes through a pull request. ``` Remplacez `jammy` si votre image n'est pas basée sur Ubuntu 22.04. Le bloc `knowledge` est plus important que l'installation : sans lui, les sessions lancent `atlas auth login` (un flux d'authentification dans le navigateur que personne ne peut mener à terme) ou demandent une chaîne de connexion déjà présente dans l'environnement. N'écrivez pas de credentials sur le disque dans `initialize`. Un fichier `~/.mongoshrc.js` ou `~/.config/atlascli/config.toml`, ou encore une URI exportée dans `~/.bashrc`, se retrouve dans le snapshot et est partagé par toutes les sessions futures.

3. Générer le snapshot

Enregistrez le blueprint, attendez le statut **Success**, puis démarrez une nouvelle session. Les sessions déjà ouvertes conservent l'ancien snapshot.

Option B : serveur MCP MongoDB

Le serveur officiel [`mongodb-mcp-server`](https://github.com/mongodb-js/mongodb-mcp-server) s'exécute en tant que processus local dans la session et utilise les identités de l'étape 2. Pour bénéficier de ses garde-fous, ajoutez-le comme serveur MCP personnalisé (**Customize > MCPs > Add MCP > Add custom MCP**, transport **STDIO**) plutôt que via le plugin `mongodb` de la marketplace, dont le manifeste n'expose ni `--readOnly` ni `--indexCheck`. | Champ | Valeur | | - | - | | Command | `npx` | | Arguments | `-y mongodb-mcp-server@ --readOnly --indexCheck` | | Environment | `MDB_MCP_CONNECTION_STRING` (même valeur que `MONGODB_URI`) ; éventuellement `MDB_MCP_API_CLIENT_ID` et `MDB_MCP_API_CLIENT_SECRET` pour les outils Atlas | Épinglez `` sur une version que vous avez testée : `npx` récupère le package à chaque démarrage de session. Avec le compte de service en lecture seule de l'étape 2, `atlas-connect-cluster` renvoie `401` ; Devin accède aux données via la connexion `preconfigured` définie par `MDB_MCP_CONNECTION_STRING`, ce qui est le comportement attendu. * `--readOnly` désactive l'enregistrement des outils de création, de mise à jour et de suppression, et rejette les agrégations contenant `$out` ou `$merge`. Sans cette option, ces agrégations s'exécutent après une demande de confirmation, voire sans confirmation si le client MCP ne prend pas en charge les prompts. Activez-la pour tout ce qui cible la production. * `--indexCheck` rejette les requêtes dont le plan d'exécution est un parcours complet de collection. Il s'agit d'un garde-fou de performance : si `explain` échoue, la requête s'exécute malgré tout. Le serveur nécessite Node `^20.19.0 || ^22.13.0 || >=24.0.0`. Vérifiez `node --version` dans une session ; si la version est antérieure, ou si `npx` ne figure pas dans le PATH visible par le processus MCP, ajoutez Node au blueprint : ```yaml theme={null} initialize: - name: Install Node.js for the MongoDB MCP server uses: github.com/actions/setup-node@v4 with: node-version: "22" ``` Conservez l'utilisateur de base de données en lecture seule, même avec `--readOnly`. Devin peut aussi exécuter `mongosh "$MONGODB_URI"` avec ce même utilisateur : ce sont donc les rôles de cet utilisateur qui constituent la véritable barrière de sécurité.

Option C : plugin MongoDB Atlas

Le [plugin](/fr/product-guides/plugins) **MongoDB Atlas** connecte Devin au serveur MCP hébergé de MongoDB (`mcp.mongodb.com`) et installe les skills d'agent de MongoDB. Devin agit avec les rôles Atlas de l'utilisateur qui se connecte, dans la limite du mode d'accès des clients IA défini pour l'organisation. 1. Un Organization Owner active l'[accès des clients IA](https://www.mongodb.com/docs/mcp-server/remote-mcp/manage-ai-client-access/) (**Organization Settings > App Connections**) et définit le mode d'accès sur **Read**, afin que les outils d'écriture ne soient pas enregistrés. Ce paramètre s'applique à tous les clients IA de l'organisation, et pas uniquement à Devin. 2. Créez un utilisateur Atlas dédié à Devin avec les rôles `GROUP_READ_ONLY` et `GROUP_DATA_ACCESS_READ_ONLY`, uniquement dans les projets qu'il est autorisé à lire. `GROUP_DATA_ACCESS_READ_ONLY` donne accès en lecture aux documents de toutes les bases de données du projet : cet accès est donc plus large que celui de l'utilisateur `devin-sessions`. 3. Installez le plugin et effectuez une seule fois la connexion OAuth dans **Customize > MCPs**, en vous connectant avec cet utilisateur, et non avec votre propre compte. 4. Une fois le plugin opérationnel, [épinglez-le sur un commit](/fr/product-guides/plugins#pinning-a-plugin). Le trafic provient de l'infrastructure hébergée de MongoDB et de Devin, et non de la session : les listes d'adresses IP de l'étape 1 et votre politique réseau ne s'appliquent donc pas. L'accès expire après 7 jours d'inactivité ou 30 jours après la connexion, selon la première échéance ; il faut alors se reconnecter. La révocation de l'accès ne supprime ni les utilisateurs de base de données ni les autres artefacts créés par le client : pensez donc à les auditer.

Rebuilds et épinglage des versions

Le blueprint installe la version que `apt` résout au moment du build, et le `npx` de l'option B récupère `mongodb-mcp-server` à chaque démarrage de session. Une fois que tout fonctionne, épinglez les deux (`mongodb-atlas-cli=`, `mongodb-mongosh=`, `mongodb-mcp-server@`), puis ne les mettez à jour qu'en connaissance de cause. La rotation d'un secret ne nécessite pas de rebuild, contrairement à la modification d'un outil installé.

Étape 4 : Définir les autorisations

L'authentification établit qui est Devin ; les rôles de base de données et Atlas déterminent ce à quoi il peut accéder. Les flags MCP et les instructions de Knowledge sont des aides qui viennent s'ajouter par-dessus, et non la véritable limite de sécurité. | Profil | Travail typique | Rôles de l'utilisateur de base de données | Rôles du compte de service | | - | - | - | - | | **Explore** (commencez ici) | Documenter le schéma, expliquer une requête lente, proposer un index dans une PR | `read` sur les bases de données de production | `GROUP_READ_ONLY` + `GROUP_DATA_ACCESS_READ_ONLY` | | **Build** | Écrire et tester des migrations, des pipelines et des données de seed sur des données de structure réaliste | Explore, plus `readWrite@devin_dev` | Identique à Explore | | **Operate** | Créer des index ou des index Atlas Search sur des collections spécifiques | Explore, plus un rôle personnalisé accordant `createIndex` sur ces collections | Explore, plus `GROUP_SEARCH_INDEX_EDITOR` | Pour Explore, les index suggérés ne nécessitent que `GROUP_READ_ONLY` (les valeurs des requêtes sont alors masquées). La liste des requêtes lentes, les exemples de valeurs de requêtes et le téléchargement des logs nécessitent en plus `GROUP_DATA_ACCESS_READ_ONLY` ; le rôle `GROUP_DATA_ACCESS_READ_WRITE` demandé par l'aide de l'Atlas CLI n'est pas nécessaire. Avec `GROUP_READ_ONLY` seul, l'outil MCP `atlas-get-performance-advisor` renvoie « No slow query logs found » au lieu d'une erreur `401` : un résultat vide peut donc venir d'un problème de rôle. Le code passe toujours par des pull requests. Devin lit la production pour comprendre le problème et valide le correctif dans `devin_dev` ; la migration ou l'index est ensuite intégré via votre processus de revue habituel.

Étape 5 : Vérifier

Démarrez une nouvelle session et demandez à Devin d'exécuter : **Connectivité.** Quel utilisateur, quels rôles et (le cas échéant) si l'Atlas CLI parvient à s'authentifier : ```bash theme={null} mongosh "$MONGODB_URI" --quiet --eval 'JSON.stringify(db.runCommand({connectionStatus: 1}), null, 2)' atlas clusters list --projectId "$MONGODB_ATLAS_PROJECT_ID" ``` **Vérification des limites.** La première insertion doit échouer (`not authorized on to execute command` sur les clusters dédiés, `user is not allowed to do action [insert] on [.devin_probe]` sur M0/Flex) ; la seconde doit réussir : ```bash theme={null} mongosh "$MONGODB_URI" --quiet --eval 'db.getSiblingDB("").devin_probe.insertOne({probe: 1})' mongosh "$MONGODB_URI" --quiet --eval 'db.getSiblingDB("devin_dev").devin_probe.insertOne({probe: 1}); db.getSiblingDB("devin_dev").devin_probe.drop()' ``` Vérifiez que les rôles indiqués dans `connectionStatus` correspondent au profil que vous avez attribué ; le simple fait qu'une connexion soit ouverte ne prouve pas grand-chose. Pour le serveur MCP, demandez à Devin de lister les bases de données à l'aide des outils MCP (il utilise la connexion `preconfigured`), puis d'insérer un document : avec `--readOnly`, l'outil `insert-many` n'existe pas, et toute agrégation avec `$out` est refusée.

Dépannage

| Symptôme | S'applique à | Cause et correctif | | - | - | - | | La connexion expire, ou l'erreur mentionne la liste d’accès IP | A, B | Les IP de Devin sont absentes de la liste d’accès IP du projet (cause d'échec la plus fréquente), ou votre politique réseau bloque `*.mongodb.net` sur le port TCP 27017. | | `querySrv ENOTFOUND _mongodb._tcp.` | A, B | DNS bloqué ou hostname incorrect. Autorisez `*.mongodb.net` dans la politique réseau. | | `Authentication failed` ou `bad auth : authentication failed` | A, B | Mot de passe ou `authSource` incorrect. | | `MongoParseError: Protocol and host list are required` | A, B | Le mot de passe de l'URI contient `@`, `/` ou `+` sans être encodé en pourcentage. Encodez-le ; il ne s'agit pas d'une erreur d'authentification. | | `not authorized on to execute command` ou `user is not allowed to do action` | A, B | Connecté, mais sans autorisation. Comportement normal lorsque Devin tente d'écrire en production ; sinon, élargissez les rôles de l'utilisateur. | | L'Atlas CLI renvoie `unauthorized` ou suggère `atlas auth login` | A, B | Les secrets du compte de service sont manquants, incorrects ou expirés, ou le rôle du compte de service n'autorise pas cette action (le serveur MCP signale aussi ce cas comme des credentials invalides). Vérifiez le rôle avant de renouveler les secrets. N'exécutez pas `atlas auth login`. | | L'Atlas CLI renvoie `403` après l'authentification | A, B | Les IP de Devin sont absentes de l'access list d'API du compte de service (étape 1). | | Devin exécute `atlas auth login` ou demande une chaîne de connexion | A | Le bloc `knowledge` est absent, ou les secrets ne figurent pas dans le blueprint utilisé par la session. | | Le build du blueprint échoue sur `apt-get`, ou le serveur MCP ne démarre pas | A, B | La politique réseau n'inclut pas `pgp.mongodb.com`, `repo.mongodb.org`, `registry.npmjs.org` ou `nodejs.org` ; ou la version de Node est antérieure à 20.19 (exécutez `node --version`). | | Le MCP rejette une requête parce qu'elle n'utilise pas d'index | B | `--indexCheck` joue son rôle. Ajoutez l'index dans une pull request (PR), ou exécutez la requête avec `mongosh` sur `devin_dev`. Les requêtes nécessitant un index de collation sont systématiquement rejetées : l'outil MCP `find` n'accepte aucun argument de collation. | | Outils Atlas manquants ou outils d'écriture visibles | C | L'accès des clients IA est désactivé, le mode d'accès est **Read and write**, ou l'utilisateur Atlas connecté dispose de rôles plus étendus que prévu. Vérifiez le mode dans **App Connections** et identifiez la personne qui a effectué la connexion OAuth. | | Les credentials fonctionnent dans une session, mais pas dans la suivante | A | Un fichier de configuration obsolète issu d'un `initialize` antérieur se trouve dans le snapshot. Supprimez-le du blueprint et relancez le build. |

Limitations

**Des credentials stockés sont requis.** Le [token OIDC](/fr/product-guides/oidc) de courte durée de Devin n’est pas encore utilisable avec MongoDB : l’API d’administration n’accepte que les secrets de compte de service ou les clés d’API. La [Workload Identity Federation](https://www.mongodb.com/docs/atlas/workload-oidc/) d’Atlas couvre le plan de données sur les clusters dédiés, mais elle nécessite une fonction de rappel (callback) de token au niveau du pilote et n’a pas été testée avec l’émetteur de Devin. Si vous souhaitez l’essayer, contactez votre équipe de compte. **MongoDB auto-hébergé.** Les étapes relatives au plan de données (utilisateur de base de données, `MONGODB_URI`, `mongosh`, serveur MCP) s’appliquent telles quelles. Il n’y a ni compte de service Atlas ni liste d’accès IP ; l’accès réseau passe par votre [VPN](/fr/onboard-devin/vpn) ou par votre propre liste d’autorisation.

Assistance

Côté Atlas, consultez la [documentation sur la sécurité d'Atlas](https://www.mongodb.com/docs/atlas/setup-cluster-security/) et la [documentation du serveur MCP de MongoDB](https://www.mongodb.com/docs/mcp-server/). Côté Devin, contactez [support@cognition.ai](mailto:support@cognition.ai) ou l'équipe chargée de votre compte. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.