Passer au contenu principal

Documentation Index

Fetch the complete documentation index at: https://docs.devin.ai/llms.txt

Use this file to discover all available pages before exploring further.

​
Premiers pas

Prérequis : Devin doit avoir accès à vos dépôts avant que vous puissiez configurer son environnement. Si vous n’avez pas encore configuré votre intégration Git, consultez Avant de commencer pour suivre les étapes de configuration. Les utilisateurs Enterprise doivent également accorder à chaque org l’accès à ses dépôts dans Enterprise Settings > Repository Permissions.
Vous utilisez encore la configuration classique ? Vous pouvez migrer vers la configuration déclarative à tout moment. Devin peut prendre en charge l’essentiel de la migration pour vous. Consultez Migrer vers la configuration déclarative.
Idéal pour la plupart des utilisateurs. Devin analyse votre projet, identifie les outils et dépendances nécessaires, puis génère le blueprint pour vous. Il ne vous reste plus qu’à le vérifier et l’approuver.
1

Démarrer une session Devin

Ouvrez une nouvelle session et demandez à Devin de configurer le dépôt. Par exemple : “Configure ton environnement pour ce repo.”
2

Vérifier et approuver

Devin propose un blueprint. Vous verrez des cartes de suggestion dans votre timeline. Vérifiez-les, puis cliquez sur Approve.
3

Vérifier

Une fois le build terminé, démarrez une nouvelle session. Devin démarre à partir du nouveau snapshot avec tout préconfiguré. Essayez de demander à Devin d’exécuter vos commandes de lint ou de test pour confirmer que tout fonctionne.
La suite de ce guide détaille le parcours manuel. Elle est également utile pour comprendre ce que Devin a généré si vous avez utilisé le parcours recommandé.

​
Comment ça marche

La configuration déclarative repose sur trois concepts :
ConceptCe que c’estAnalogie
BlueprintUne configuration YAML qui décrit ce qu’il faut installer et comment configurer l’environnement de DevinDockerfile
BuildLe processus qui exécute votre blueprint, clone les repos et produit un snapshotdocker build
SnapshotUne image figée et amorçable de l’environnement à partir de laquelle les sessions démarrentDocker image
Les blueprints décrivent ce que vous voulez. Vous les rédigez et les modifiez dans l’interface Settings. Les builds exécutent vos blueprints pour produire des snapshots. Les builds se lancent automatiquement lorsque vous enregistrez un blueprint, puis périodiquement (~toutes les 24 heures) afin de maintenir les dépendances à jour. Les snapshots sont la base à partir de laquelle les sessions démarrent. Chaque organisation dispose d’un snapshot actif. Chaque session démarre à partir d’une copie neuve. Les modifications apportées pendant une session ne sont pas répercutées dans le snapshot.

​
Sections du blueprint

Un blueprint comporte trois sections :
SectionObjectifQuand elle s’exécute
initializeInstaller les outils, les environnements d’exécution, les packages systèmePendant les builds uniquement. Les résultats sont enregistrés dans le snapshot.
maintenanceInstaller/mettre à jour les dépendances du projet, écrire les configurations d’authentificationPendant les builds. Présentée à l’agent au démarrage de la session (non exécutée automatiquement).
knowledgeInformations de référence pour Devin (commandes de lint, test et build)Non exécutée. Chargée dans le contexte de Devin au démarrage de la session.
initialize sert à ce qui ne doit se produire qu’une seule fois : environnements d’exécution, packages système, outils CLI globaux. maintenance sert à l’installation des dépendances qui doivent rester à jour. Elle s’exécute pendant les builds et est présentée à l’agent au démarrage de la session afin qu’il puisse les relancer si les dépendances ont changé (p. ex. après récupération du code le plus récent). Les commandes ne sont pas exécutées automatiquement au démarrage de la session, mais doivent tout de même être rapides et incrémentales (utilisez npm install, pas npm ci). knowledge contient des informations de référence et n’est pas exécutée. C’est ainsi que vous indiquez à Devin les bonnes commandes de lint, de test et de build. Gardez des entrées légères et axées sur des commandes exécutables.
Knowledge ici vs la fonctionnalité produit Knowledge : La section knowledge de votre blueprint sert à de courtes références de commandes liées à l’environnement. Pour la documentation d’architecture, les conventions et les workflows d’équipe, utilisez plutôt la fonctionnalité autonome Knowledge.
YAML multi-document : L’éditeur de blueprint prend en charge le YAML multi-document à l’aide du séparateur ---. Cela vous permet d’organiser des blueprints complexes en sections logiques dans un seul éditeur.
Pour la spécification complète des champs (types d’étapes, variables d’environnement, secrets et fichiers joints), consultez la référence Blueprint.

​
Périmètre des blueprints

Vous pouvez définir des blueprints à deux niveaux :
NiveauOù configurerQue mettre ici
OrganisationSettings > Environment > Blueprints > Configuration à l’échelle de l’organisationOutils partagés par tous les dépôts : environnements d’exécution, gestionnaires de paquets, authentification Docker
DépôtSettings > Environment > Blueprints > [nom du dépôt]Configuration spécifique au projet : npm install, commandes de lint/test/build
Les blueprints sont additifs : les blueprints de dépôt s’appuient sur le blueprint de l’organisation. L’étape maintenance d’un dépôt peut utiliser des outils installés par l’étape initialize de l’organisation. Si un seul dépôt a besoin d’un outil, placez-le dans le blueprint de ce dépôt. Si tous les dépôts en ont besoin, placez-le dans le blueprint de l’organisation.
Utilisateurs Enterprise : Il existe un troisième niveau, le blueprint Enterprise, qui s’applique à toutes les organisations. Consultez la vue d’ensemble de l’environnement Enterprise pour plus de détails.

​
Builds et sessions

​
Le snapshot

Votre organisation dispose d’un snapshot actif : une image de machine virtuelle avec vos outils, dépôts et dépendances préinstallés. Tous les dépôts configurés sont clonés et configurés dans cette image unique. Chaque session démarre à partir d’une nouvelle copie.

​
Comment fonctionnent les builds

Un build crée un nouveau snapshot en exécutant vos blueprints dans l’ordre : 
1. Blueprint Enterprise, si configuré (s'exécute dans ~) :
   a. initialize
   b. maintenance
2. Blueprint org (s'exécute dans ~) :
   a. initialize
   b. maintenance
3. Cloner tous les dépôts (jusqu'à 10 en simultané)
4. Pour chaque repo configuré, dans l'ordre affiché dans Settings
   (s'exécute dans ~/repos/<repo-name>) :
   a. initialize
   b. maintenance
5. Vérification de l'état, puis le snapshot est enregistré
Les couches sont cumulatives : les commandes propres au dépôt peuvent utiliser des outils installés par l’organisation ou le blueprint Enterprise. Les niveaux inférieurs ne peuvent pas écraser ce qu’un niveau supérieur a configuré. Les builds prennent généralement 5 à 15 minutes. Chaque étape expire au bout d’1 heure.

​
Fonctionnement des sessions

Chaque session démarre avec une nouvelle copie du snapshot. Lorsque la session se termine, toutes les modifications sont abandonnées. Au démarrage de la session :
  1. La version la plus récente du code est récupérée pour le ou les repos concernés.
  2. Les commandes maintenance (Enterprise, organisation et repo) sont présentées à l’agent comme contexte — elles ne sont pas exécutées automatiquement. L’agent peut les relancer s’il détecte que les dépendances ont changé depuis le dernier build.
  3. Les entrées Knowledge de ce repo sont chargées dans le contexte de Devin.
Knowledge est spécifique à chaque repo. Si vous avez 5 repos configurés, Devin ne voit que les entrées Knowledge de celui sur lequel il travaille.

​
Ce qui déclenche un build

DéclencheurDescription
Enregistrement d’un blueprintCréation, mise à jour ou suppression d’un blueprint
Ajout ou suppression d’un dépôtToute modification de la liste des dépôts
Ajout d’un secret de dépôtLes nouveaux secrets nécessitent un rebuild pour être disponibles
Déclenchement manuelClic sur Build snapshot dans l’interface
Actualisation périodiqueAutomatique, environ toutes les 24 heures
Suggestion de DevinDevin propose une modification du blueprint pendant une session
Un seul build peut s’exécuter à la fois. Tout nouveau déclencheur annule tout build en file d’attente et relance le processus à zéro.

​
États des builds

StatusMeaning
SuccessToutes les étapes sont terminées. Le snapshot est prêt.
PartialCertaines étapes au niveau du repo ont échoué, mais le snapshot reste utilisable. Les repos qui ont réussi fonctionnent normalement ; les repos en échec nécessitent de corriger leurs blueprints.
FailedÉchec critique (la configuration de l’organisation ou de l’environnement Enterprise a échoué). Le snapshot n’est pas utilisable.
CancelledRemplacé par un build plus récent ou annulé manuellement.
Un build partial produit quand même un snapshot exploitable. Si l’un des cinq repos a un blueprint défectueux, les quatre autres sont entièrement fonctionnels.
Le build échoue ? Consultez Résolution des problèmes de build pour obtenir un guide de débogage pas à pas.

​
Gérer votre environnement

​
États des dépôts

Les dépôts apparaissent sous trois états dans les paramètres d’Environment :
ÉtatSignification
ConfiguredDispose d’un blueprint avec initialize/maintenance/knowledge. Entièrement configuré dans le snapshot.
IncludedCloné dans le snapshot, mais sans blueprint personnalisé. Devin peut accéder au code.
AvailableConnecté à l’organisation, mais non ajouté à l’environnement. Non cloné.
Included vs. configured : Un dépôt « included » est cloné pour que Devin puisse accéder au code, mais il n’a pas de commandes de configuration personnalisées. Un dépôt « configured » comporte des instructions explicites pour initialize/maintenance/knowledge.

​
Secrets

Faites référence aux secrets avec la syntaxe $VARIABLE_NAME. Ajoutez-les dans l’onglet Secrets de l’éditeur de blueprint. 
maintenance:
  - name: Configure private registry
    run: npm config set //registry.npmjs.org/:_authToken $NPM_TOKEN
Les secrets sont disponibles sous forme de variables d’environnement lors des builds et des sessions. Ils sont supprimés avant que le snapshot ne soit enregistré, mais si une commande écrit la valeur d’un secret dans un fichier de configuration pendant initialize, cette valeur persiste dans le snapshot. Placez les étapes qui écrivent des identifiants dans maintenance afin qu’elles soient actualisées lors des builds périodiques. Pour en savoir plus sur les périmètres des secrets et leur comportement, consultez la référence Blueprint.

​
Plusieurs dépôts

Chaque dépôt dispose de son propre blueprint. Lors d’un build, tous les dépôts sont configurés dans le même snapshot, puis clonés dans des répertoires distincts, avec des dépendances installées indépendamment. Si deux dépôts installent des versions différentes d’un outil global ou modifient des fichiers partagés (comme ~/.bashrc), c’est le dernier à s’exécuter qui l’emporte. Installez les outils partagés dans le blueprint à l’échelle de l’organisation afin d’éviter les conflits.

​
GitHub Actions

Au lieu d’écrire des scripts shell pour installer des outils et des environnements d’exécution, vous pouvez faire directement référence à des GitHub Actions dans votre blueprint. Devin télécharge et exécute l’action pendant le build, de la même manière que les runners CI de GitHub exécutent les étapes de l’action. 
initialize:
  - name: Install Python 3.12
    uses: github.com/actions/setup-python@v5
    with:
      python-version: "3.12"
C’est particulièrement utile pour les actions de configuration de langage comme setup-python, setup-node et setup-go, qui gèrent automatiquement les versions et la configuration du PATH. Pour plus de détails sur la syntaxe, des exemples et les limites, consultez GitHub Actions dans les blueprints.

​
Monorepos

Dans les monorepos, utilisez des subshells pour exécuter des commandes dans des sous-répertoires : 
maintenance:
  - name: Frontend deps
    run: (cd packages/frontend && pnpm install)
  - name: Backend deps
    run: (cd packages/backend && uv sync)
Les parenthèses (cd ... && ...) s’exécutent dans un sous-shell, ce qui réinitialise le répertoire de travail pour l’étape suivante.

​
Épinglage et mises à jour automatiques

Par défaut, Devin utilise le snapshot du dernier build réussi. L’épinglage permet de verrouiller le snapshot d’un build spécifique. C’est utile lorsqu’un nouveau build introduit une régression, ou lorsque vous souhaitez figer l’environnement pour un lot de sessions. Pour épingler : accédez à Settings > Environment > Snapshots, recherchez le build dans l’historique (il doit être success ou partial et dater de moins de 7 jours), puis cliquez sur Épingler. Une fois épinglé, les actualisations périodiques sont suspendues et l’interface affiche Mises à jour automatiques en pause. Pour retirer l’épinglage : cliquez sur Reprendre les mises à jour automatiques. Devin bascule vers le dernier build réussi.

​
Blueprints basés sur Git

Les blueprints basés sur Git ne sont pas encore pris en charge. Cette fonctionnalité sera bientôt disponible. Vous pourrez stocker des blueprints dans votre dépôt et déclencher automatiquement des builds lorsqu’ils sont modifiés. Pour l’instant, configurez les blueprints depuis l’interface utilisateur.

​
Résolution des problèmes de build

​
Échec de l’étape d’initialisation

Causes fréquentes : faute de frappe dans une commande shell, package indisponible, délai d’attente réseau dépassé, référence GitHub Action incorrecte. Correctif : consultez les logs de build pour connaître l’erreur exacte. Mettez à jour initialize dans votre blueprint et enregistrez. Un nouveau build est automatiquement activé.

​
Échec du clonage du repo

Causes fréquentes : Devin n’a pas accès au repo, le repo a été renommé/déplacé/supprimé, ou il s’agit d’un problème réseau temporaire. Correctif : Vérifiez l’accès au repo dans les paramètres de votre service Git. Supprimez le repo, puis ajoutez-le à nouveau s’il a été renommé.

​
L’étape de maintenance a échoué

Causes courantes : conflit de dépendances, bibliothèque système manquante, espace disque insuffisant, fichier de verrouillage non synchronisé. Correctif : vérifiez les logs du package ou de la commande qui échoue. Mettez à jour maintenance ou initialize pour installer les dépendances manquantes, ou corrigez le fichier de verrouillage dans votre dépôt.

​
Expiration du build

Chaque étape a un délai d’expiration d’une heure. Causes fréquentes : compilation de dépendances natives volumineuses à partir du code source (utilisez des binaires précompilés), téléchargement d’artefacts volumineux, commandes qui se bloquent en attendant une saisie (toutes les commandes doivent être non interactives).

​
Itérer sur les correctifs

  1. Consultez les logs de build pour identifier la cause de l’échec
  2. Mettez à jour le blueprint concerné
  3. Enregistrez (un nouveau build s’active automatiquement)
  4. Surveillez les logs du nouveau build
  5. Répétez jusqu’à ce que le build se termine avec succès
Vous n’avez pas besoin d’attendre la fin d’un build en échec. L’enregistrement d’une nouvelle configuration annule tout build en file d’attente et relance un build à partir de zéro.

​
Prochaines étapes

GitHub Actions dans les blueprints

Utilisez GitHub Actions pour installer des langages, des outils et des SDK sans écrire de scripts shell.

référence Blueprint

Référence complète des champs : types d’étapes, variables d’environnement, secrets, fichiers joints.

Bibliothèque de modèle

Blueprints prêts à copier-coller pour Python, Node.js, Go, Java, Ruby, Rust et cas d’usage avancés.

Migration depuis la configuration classique

Guide étape par étape pour passer de l’assistant interactif aux blueprints déclaratifs.

Gestion des environnements Enterprise

Gestion des environnements à l’échelle de l’entreprise : hiérarchie à 3 niveaux, secrets et configuration entre organisations.