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

# Workflows dynamiques Devin

> Orchestrez de nombreuses sessions Devin à l’aide d’un script Python déterministe : répartissez le travail, transmettez des résultats structurés entre les étapes et reprenez une exécution là où elle s’est arrêtée.

<Info>
  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](https://app.devin.ai/settings/enterprise-devin). Jusque-là, Devin n’exécutera aucun workflow dans les organisations de l’Enterprise.
</Info>

<div id="what-are-dynamic-workflows">
  ## Que sont les workflows dynamiques ?
</div>

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é restituent instantanément 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](/fr/work-with-devin/advanced-capabilities#managed-devins), où la session de coordination lance et supervise manuellement les sessions enfants. Dans un workflow, l’orchestration est elle-même du code.

<div id="when-to-use-a-workflow">
  ## Quand utiliser un workflow
</div>

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](/fr/work-with-devin/advanced-capabilities#managed-devins)) 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.

<div id="example-prompts">
  ### Exemples de prompts
</div>

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 :

```text theme={null}
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 :

```text theme={null}
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 :

```text theme={null}
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* :

```text theme={null}
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 :

```text theme={null}
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
```

<div id="how-a-run-works">
  ## Fonctionnement d’une exécution
</div>

1. **Devin écrit le script** dans un fichier et lance l’exécution. Vous devez d’abord l’approuver, sauf si vous avez activé l’approbation automatique dans **Settings → Preferences → Approbation automatique des workflows**.
2. **Le script s’exécute sur la machine de Devin.** Les primitives de workflow sont injectées automatiquement — rien à installer ni à importer.
3. **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.
4. **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.
5. **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.

<div id="authoring-model">
  ## Modèle de conception
</div>

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.

<div id="example">
  ### Exemple
</div>

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

```python theme={null}
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())
```

<div id="where-agents-run">
  ## Où les agents s’exécutent
</div>

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

<CardGroup cols={2}>
  <Card title="VM distincte (par défaut)" icon="server">
    Une session Devin enfant complète disposant de sa propre machine, de ses clones de dépôt et de son [environnement](/fr/onboard-devin/environment/blueprints). 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.
  </Card>

  <Card title="VM partagée" icon="folder-tree">
    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.
  </Card>
</CardGroup>

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.

<div id="determinism-and-resuming">
  ## Déterminisme et reprise
</div>

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.

<div id="cost">
  ## Coût
</div>

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](/fr/essential-guidelines/when-to-use-devin) 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.

<div id="saving-a-workflow-for-reuse">
  ## Enregistrer un workflow pour le réutiliser
</div>

Une fois qu’un workflow est opérationnel, vous pouvez le valider dans votre repo sous forme de [skill](/fr/product-guides/skills) : 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.

<div id="related">
  ## Ressources connexes
</div>

* [Capacités avancées](/fr/work-with-devin/advanced-capabilities) — orchestrer directement des Devins gérés
* [Skills](/fr/product-guides/skills) — enregistrer des procédures réutilisables, y compris des workflows, dans vos repos
* [Devin MCP](/fr/work-with-devin/devin-mcp) — créer et surveiller des sessions par programmation