Workflows dynamiques Devin

Les workflows dynamiques sont disponibles dans n’importe quelle session Devin : décrivez simplement le travail et demandez à Devin de l’exécuter sous forme de workflow.Comptes Enterprise : la fonctionnalité est désactivée jusqu’à ce qu’un administrateur Enterprise active les Workflows dynamiques dans Enterprise Settings > Devin. Jusque-là, Devin n’exécutera aucun workflow dans les organisations de l’Enterprise.

Que sont les workflows dynamiques ?

Un workflow dynamique est un script Python déterministe qui orchestre une équipe d’agents Devin. Devin écrit et exécute le script, qui détermine quels agents s’exécutent, dans quel ordre et quelles instructions chacun reçoit, en utilisant les résultats structurés des agents précédents pour construire les prompts des suivants. Chaque appel à un agent est enregistré. Une exécution de workflow peut donc être observée pendant son déroulement et reprise en cas d’interruption : les agents ayant terminé effectuent instantanément la relecture de leurs résultats enregistrés, et seul le travail inachevé est de nouveau exécuté. Cela va plus loin que les Devins gérés, où la session de coordination crée et supervise manuellement les sessions enfants. Dans un workflow, l’orchestration est elle-même du code.

Fonctionnement des workflows dynamiques et cas d’usage, avec un exemple de revue d’accessibilité portant sur 12 composants

Quand utiliser un workflow

Demandez un workflow lorsque le travail présente une véritable structure :

Large répartition des tâches avec une étape de consolidation — environ cinq unités indépendantes ou plus (fichiers, modules, endpoints, tickets) nécessitant chacune une évaluation ou une vérification, puis une consolidation des résultats.
Un pipeline par étapes — les étapes ultérieures exploitent la sortie structurée des précédentes, par exemple audit → correctif → vérification.

Privilégiez une session simple (ou quelques Devins gérés) lorsque :

La modification est mécanique — un codemod, une correction automatique du linter ou un générateur l’effectue plus rapidement et plus fiablement que des agents.
Une ou deux sessions indépendantes suffisent, sans échange de données entre elles.
Le travail dépend étroitement d’un état partagé, ou est limité et séquentiel.

Exemples de prompts

Vous décrivez la tâche et demandez un workflow ; Devin écrit le script. Migration — lancez un agent par unité sur sa propre branche, puis regroupez le tout :

Utilise un workflow pour migrer chaque job de jobs/ de l'ancien exécuteur cron
vers notre nouvelle API de planification — un agent par job, chacun travaillant
sur sa propre branche et exécutant les tests du job — puis fais la synthèse des
jobs qui nécessitent une intervention manuelle

Recherche — recueillez des éléments de preuve en parallèle, puis faites-en la synthèse :

Utilise un workflow pour évaluer Postgres, DynamoDB et CockroachDB pour le
nouveau service d'événements : un agent par option, qui la note au regard de
nos exigences de latence, de coût et d'exploitation, puis un agent final qui
compare les éléments recueillis et en recommande une

Revue de code — un relecteur par fichier, puis une étape de fusion :

Utilise un workflow pour relire chaque fichier modifié sur cette branche au
regard de CONTRIBUTING.md — un relecteur par fichier — puis fusionne les
constats en une seule liste dédupliquée, classée par gravité

Audit de l’ensemble de la codebase — un pipeline en plusieurs étapes audit → correctif → vérification :

Utilise un workflow pour auditer chaque requête SQL du module de reporting
afin d'y détecter les paginations manquantes et les patterns N+1, corrige
chaque problème confirmé sur sa propre branche, et vérifie chaque correctif
avec un EXPLAIN avant et après

Boucle — répétez jusqu’à ce qu’une vérification réussisse ou que la progression stagne :

Utilise un workflow pour faire passer au vert la suite de tests d'intégration
instable : exécute-la, corrige ce qui a échoué, et recommence jusqu'à ce
qu'elle passe trois exécutions consécutives ou qu'un tour ne corrige plus rien
de nouveau

Fonctionnement d’une exécution

Devin écrit le script dans un fichier et lance l’exécution. Les exécutions sont approuvées automatiquement par défaut ; pour que Devin demande votre approbation avant chaque exécution, désactivez Settings → Preferences → Approbation automatique des workflows.
Le script s’exécute sur la machine de Devin. Les primitives de workflow sont injectées automatiquement — rien à installer ni à importer.
Chaque appel d’agent génère un agent et attend sa sortie structurée. Par défaut, cet agent est une session Devin indépendante sur sa propre VM.
La progression est transmise à la session. Le panneau des workflows affiche chaque phase, ses agents et leur statut en direct ; vous pouvez y ouvrir la session de n’importe quel agent.
Les résultats sont enregistrés sous un ID d’exécution, ce qui permet de reprendre l’exécution.

L’exécution se déroule en arrière-plan, de sorte que la session reste réactive — vous pouvez continuer à parler à Devin pendant son exécution, demander un récapitulatif de l’avancement ou lui demander d’arrêter l’exécution. L’arrêt annule le script et met en veille les sessions enfants restantes ; tout ce qui a déjà été enregistré peut être repris.

Modèle de conception

Le script est du Python standard. Devin l’écrit, mais il est utile d’en connaître la structure lorsque vous en examinez un :

Primitive	Rôle
`register_workflow(meta)`	Déclare le nom, la description et les phases du workflow. Doit être attendu avant le lancement de tout agent.
`agent(prompt, phase=..., schema=...)`	Exécute un agent et renvoie sa sortie structurée sous forme de dictionnaire.
`pipeline(items, stage1, stage2, ...)`	Exécute chaque élément indépendamment à travers les étapes — il n’y a pas de barrière entre les étapes : l’élément A peut donc être à l’étape 3 alors que l’élément B est encore à l’étape 1.
`parallel([...])`	Exécute des appelables asynchrones simultanément et attend qu’ils soient tous terminés. À utiliser uniquement lorsqu’une étape requiert réellement tous les résultats précédents, par exemple lors d’une fusion ou d’une déduplication.
`log("message")`	Écrit une ligne de progression visible tant que l’exécution est en cours.

Chaque appel à agent() reçoit un schéma JSON et renvoie un dictionnaire qui respecte ce schéma. Les constats d’une étape peuvent ainsi alimenter le prompt de l’étape suivante. Gardez les schémas petits et plats.

Exemple

Un pipeline d’audit suivi de correctifs sur trois modules :

import asyncio
import json

REPO = "github.com/acme/api"
MODULES = ["auth", "billing", "search"]

META = {
    "name": "error-handling-audit",
    "description": "Audit and fix error-handling bugs across api modules",
    "phases": [
        {"title": "analyze", "detail": "audit each module for error-handling bugs"},
        {"title": "fix", "detail": "fix confirmed issues and push a branch"},
    ],
}

FINDINGS_SCHEMA = {
    "type": "object",
    "properties": {
        "module": {"type": "string"},
        "issues": {"type": "array", "items": {"type": "string"}},
    },
    "required": ["module", "issues"],
}

FIX_SCHEMA = {
    "type": "object",
    "properties": {"branch": {"type": "string"}, "summary": {"type": "string"}},
    "required": ["branch", "summary"],
}

async def analyze(module):
    return await agent(
        f"In {REPO}, audit the '{module}' module for error-handling bugs. "
        "Report each issue as a one-line string.",
        phase="analyze",
        schema=FINDINGS_SCHEMA,
        label=f"analyze-{module}",
    )

async def fix(findings):
    if not findings["issues"]:
        return None
    return await agent(
        f"In {REPO}, fix these issues in the '{findings['module']}' module:\n"
        + json.dumps(findings["issues"], sort_keys=True)
        + "\nPush your work to a new git branch (do not open a PR) and "
        "report the branch name and a one-line summary.",
        phase="fix",
        schema=FIX_SCHEMA,
        label=f"fix-{findings['module']}",
    )

async def main():
    await register_workflow(META)
    results = await pipeline(MODULES, analyze, fix)
    for module, result in zip(MODULES, results):
        log(f"{module}: {result['branch'] if result else 'no fix needed/failed'}")

asyncio.run(main())

Où les agents s’exécutent

Par défaut, chaque agent s’exécute sur sa propre VM, mais peut être épinglé à la machine de la session d’orchestration.

VM distincte (par défaut)

Une session Devin enfant complète disposant de sa propre machine, de ses clones de dépôt et de son environnement. Elle ne peut pas accéder aux fichiers de la session d’orchestration. Les transferts de code passent donc par des branches Git : chaque agent pousse une branche et en indique le nom, que les étapes ultérieures lisent dans la sortie structurée.

VM partagée

L’agent s’exécute sur la machine de la session d’orchestration et partage son arbre de travail, y compris les modifications non validées — aucun transfert Git n’est nécessaire. Utilisez cette option lorsque les agents doivent lire ou modifier l’arbre de travail actuel, ou lorsque le dépôt n’existe que sur cette machine.

Les agents sur VM partagée sont en concurrence avec la session pour le processeur, la mémoire et l’espace disque, et sont soumis à une limite de concurrence plus faible. Comme ils partagent un même arbre de travail sans isolation, les agents qui écrivent en parallèle doivent se voir attribuer des fichiers ou répertoires strictement distincts. Les agents peuvent également être épinglés à un mode Devin spécifique — par exemple, le mode Devin Lite, moins coûteux, pour la classification de chaque élément dans le cadre d’une répartition des tâches très large.

Déterminisme et reprise

Lorsqu’une exécution reprend, le script de workflow est réexécuté depuis le début, et chaque appel d’agent est associé à un hash de son prompt, de son schéma et de ses paramètres d’exécution. Tout ce qui s’est déjà terminé est rejoué à partir de son résultat enregistré ; le reste est exécuté à nouveau dans de nouvelles sessions. Cela ne fonctionne que si le script effectue les mêmes appels à chaque fois. La logique du workflow et les prompts ne doivent pas dépendre de l’heure ou de la date actuelles, du hasard, des ID générés, des variables d’environnement, de l’état du système de fichiers ou des réponses du réseau. Tout ce qui nécessite d’inspecter le monde extérieur doit être placé dans un appel agent(), dont le reste du script consomme la sortie enregistrée. Deux conséquences à connaître :

Modifier un prompt réexécute cet agent et tout ce qui en dépend en aval, tandis que les agents précédents non modifiés sont toujours rejoués.
Une exécution ayant expiré ou été interrompue reprend là où elle s’était arrêtée lorsqu’elle est reprise avec son ID d’exécution. Le budget par défaut et maximal d’une exécution est de sept jours.

Si un agent échoue — parce que sa session s’est arrêtée ou qu’il n’a produit aucune sortie structurée valide — le script décide de la suite : ignorer l’élément, utiliser une valeur par défaut, réessayer ou faire échouer l’exécution. Une exécution reprise réessaie les agents ayant échoué dans de nouvelles sessions.

Coût

Chaque agent d’un workflow correspond à une session Devin. Une exécution peut donc consommer bien plus d’ACU que la même tâche effectuée dans une seule session. Avant d’appliquer un workflow à un repo entier, exécutez-le sur un sous-ensemble — un répertoire, trois modules, une question plus ciblée — et vérifiez l’utilisation des ACU des agents dans le panneau des workflows. Demander un mode moins coûteux pour les étapes à fort volume, telles que la classification élément par élément, permet également de maîtriser les coûts d’une large répartition des tâches.

Enregistrer un workflow pour le réutiliser

Une fois qu’un workflow est opérationnel, vous pouvez le valider dans votre repo sous forme de skill : un fichier workflow.py accompagné d’un fichier SKILL.md décrivant quand l’utiliser. Devin le détectera et l’exécutera à nouveau pour de futures tâches, au lieu de créer un nouveau script. Demandez à Devin d’enregistrer un workflow ; il créera les fichiers nécessaires.

Capacités avancées — orchestrer directement des Devins gérés
Skills — enregistrer des procédures réutilisables, y compris des workflows, dans vos repos
Devin MCP — créer et surveiller des sessions par programmation

Prise en main

Concepts essentiels

Mise en place de Devin

Travailler avec Devin

Guides produit

Intégrations

Administration

Notes de version

Workflows dynamiques Devin

Que sont les workflows dynamiques ?

Quand utiliser un workflow

Exemples de prompts

Fonctionnement d’une exécution

Modèle de conception

Exemple

Où les agents s’exécutent

VM distincte (par défaut)

VM partagée

Déterminisme et reprise

Coût

Enregistrer un workflow pour le réutiliser

​Que sont les workflows dynamiques ?

​Quand utiliser un workflow

​Exemples de prompts

​Fonctionnement d’une exécution

​Modèle de conception

​Exemple

​Où les agents s’exécutent

VM distincte (par défaut)

VM partagée

​Déterminisme et reprise

​Coût

​Enregistrer un workflow pour le réutiliser

​Ressources connexes

Que sont les workflows dynamiques ?

Quand utiliser un workflow

Exemples de prompts

Fonctionnement d’une exécution

Modèle de conception

Exemple

Où les agents s’exécutent

Déterminisme et reprise

Coût

Enregistrer un workflow pour le réutiliser

Ressources connexes