Connecter Devin à 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 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	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	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	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 et d’ajouter des 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 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, 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.

atlas accessLists create <ip> --type ipAddress --comment "Devin" --projectId <project-id>
atlas accessLists create <cidr> --type cidrBlock --comment "Devin" --projectId <project-id>

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 :

atlas dbusers create \
  --username devin-sessions \
  --password "<generated-password>" \
  --role read@analytics,read@billing,readWrite@devin_dev \
  --scope <cluster-name> \
  --projectId <project-id>

Sans --scope, l’utilisateur peut accéder à tous les clusters du projet. Utilisez un rôle de base de données personnalisé 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

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:<password>@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.

Ajouter le blueprint

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.

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 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@<version> --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 <version> 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 :

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 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.

Un Organization Owner active l’accès des clients IA (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.
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.
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.
Une fois le plugin opérationnel, épinglez-le sur un commit.

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=<version>, mongodb-mongosh=<version>, mongodb-mcp-server@<version>), 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 :

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 <prod-db> to execute command sur les clusters dédiés, user is not allowed to do action [insert] on [<prod-db>.devin_probe] sur M0/Flex) ; la seconde doit réussir :

mongosh "$MONGODB_URI" --quiet --eval 'db.getSiblingDB("<prod-db>").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.<host>`	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 <db> 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 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 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 ou par votre propre liste d’autorisation.

Assistance

Côté Atlas, consultez la documentation sur la sécurité d’Atlas et la documentation du serveur MCP de MongoDB. Côté Devin, contactez support@cognition.ai ou l’équipe chargée de votre compte.

Prise en main

Concepts essentiels

Mise en place de Devin

Travailler avec Devin

Guides produit

Intégrations

Administration

Notes de version

Connecter Devin à MongoDB

Deux plans, deux identités

Choisir le mode de connexion de Devin

Pourquoi connecter Devin à MongoDB ?

Prérequis

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

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

Utilisateur de base de données

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

Étape 3 : Connecter Devin

Option A : CLI dans un blueprint

Ajouter des Devin Secrets

Ajouter le blueprint

Générer le snapshot

Option B : serveur MCP MongoDB

Option C : plugin MongoDB Atlas

Rebuilds et épinglage des versions

Étape 4 : Définir les autorisations

Étape 5 : Vérifier

Dépannage

Limitations

Assistance

​Deux plans, deux identités

​Choisir le mode de connexion de Devin

​Pourquoi connecter Devin à MongoDB ?

​Prérequis

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

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

​Utilisateur de base de données

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

​Étape 3 : Connecter Devin

​Option A : CLI dans un blueprint

​ Ajouter des Devin Secrets

​ Ajouter le blueprint

​ Générer le snapshot

​Option B : serveur MCP MongoDB

​Option C : plugin MongoDB Atlas

​Rebuilds et épinglage des versions

​Étape 4 : Définir les autorisations

​Étape 5 : Vérifier

​Dépannage

​Limitations

​Assistance

Deux plans, deux identités

Choisir le mode de connexion de Devin

Pourquoi connecter Devin à MongoDB ?

Prérequis

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

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

Utilisateur de base de données

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

Étape 3 : Connecter Devin

Option A : CLI dans un blueprint

Ajouter des Devin Secrets

Ajouter le blueprint

Générer le snapshot

Option B : serveur MCP MongoDB

Option C : plugin MongoDB Atlas

Rebuilds et épinglage des versions

Étape 4 : Définir les autorisations

Étape 5 : Vérifier

Dépannage

Limitations

Assistance