Pour faire fonctionner des agents de code en parallèle, donnez à chacun son propre git worktree et sa propre branche, alimentez-les à partir d'une file d'attente de plans préalablement validés par un humain, lancez les tests et le linting au sein de chaque worktree avant que quiconque n'examine le diff, et comptabilisez précisément le coût de chaque plan. La plupart des équipes parviennent à cette configuration après avoir expérimenté trois approches antérieures : un agent unique dans une fenêtre de chat, un agent par branche lancé à la main, puis une file d'attente automatisée avec des agents workers. Chaque modèle résout un problème précis tout en révélant le suivant. Ce guide analyse ces quatre approches, leurs points de rupture respectifs et les six fonctions indispensables qu'un orchestrateur doit prendre en charge.

Les quatre modèles d'orchestration

Le cadre proposé par Steve Yegge dans « Les 8 niveaux de développement assisté par IA » (2025) offre une grille de lecture éclairante. La boucle fondamentale — analyser une étape, agir, observer le résultat, répéter — formalisée par Yao et al., ReAct: Synergizing Reasoning and Acting in Language Models, est commune à tous les systèmes. Chaque modèle ci-dessous apporte une réponse différente à la question : qui supervise cette boucle ? À l'heure où nous écrivons ces lignes, la majorité des équipes se situent aux niveaux 2 ou 3 : un développeur envoie un prompt à un agent, lit le résultat et crée un commit. L'orchestration avec agents parallèles, mémoire persistante et barrières de relecture correspond au niveau 8.

Modèle 1 : un agent unique dans une interface de chat

Un développeur ouvre un terminal ou un panneau dans son EDI, formule une consigne et observe l'agent modifier les fichiers dans le répertoire de travail local. Le débit est strictement limité à une tâche par développeur à la fois, puisque l'humain et l'agent partagent la même copie locale du dépôt. Si une seconde tâche est initiée avant la fin de la première, les deux séries de modifications s'entremêlent dans la même arborescence, et le diff perd toute lisibilité.

Modèle 2 : un agent par branche, déclenché manuellement

L'étape suivante consiste à allouer à chaque tâche sa propre branche et sa propre arborescence de travail. Les git worktrees rendent cette approche particulièrement légère : une seule base d'objets partagée pour plusieurs répertoires de travail indépendants.

# Depuis la copie principale du dépôt :
git worktree add ../feature-search-button -b feature/search-button
cd ../feature-search-button
claude "Add a search button to the sidebar. Run the tests when done."

Un développeur peut désormais faire tourner deux ou trois agents en parallèle, chacun dans son propre dossier. Le point de rupture se situe ici dans le suivi opérationnel : personne ne consigne quel worktree correspond à quelle tâche, et les prompts disparaissent dans l'historique défilant du terminal. De plus, si deux agents travaillent sur les mêmes fichiers, des conflits de fusion apparaissent au moment du merge.

Modèle 3 : file d'attente et agents workers dans des worktrees isolés

Dès qu'une équipe fait tourner plus d'une poignée d'agents, le déclenchement manuel devient le principal goulet d'étranglement. La parade naturelle est la file d'attente : les tâches sont empilées, des processus workers les récupèrent, créent un worktree, exécutent l'agent, poussent une branche et ouvrent une pull request. Les frameworks de recherche multi-agents comme AutoGen formalisent exactement cette architecture d'agents ouvriers et de files d'attente.

Cependant, supprimer l'intervention humaine au démarrage de chaque tâche fait naître un nouveau mode de défaillance. Rien ne contrôle la pertinence de la tâche avant que l'agent ne commence à travailler : des tâches mal cadrées consomment alors de coûteux tokens pour produire des pull requests dont personne ne veut. Par ailleurs, rien ne valide la qualité du code avant l'ouverture de la PR, de sorte que les relecteurs humains deviennent le goulot d'étranglement. Enfin, comme la file s'exécute sans surveillance continue, les coûts financiers dérivent de façon incontrôlée.

Modèle 4 : cycle de vie du plan avec points de contrôle humains

Le dernier modèle introduit deux points de contrôle humains et une étape de vérification automatisée. Chaque tâche prend la forme d'un plan écrit. Un humain examine ce plan avant qu'une seule ligne de code ne soit écrite. Les agents exécutent les modifications dans des worktrees strictement étanches. Les tests, le linting et la synthèse du diff s'exécutent au sein du worktree — selon le principe éprouvé de l'intégration continue, mais appliqué par agent plutôt que par développeur. Un humain analyse le diff. Ce n'est qu'après ces validations qu'une pull request est ouverte.

Ivy qualifie ce schéma d'organisation de « software factory » (usine logicielle) : un flux de travail rigoureux et répétable dans lequel chaque modification franchit les mêmes étapes ordonnées et les deux mêmes arbitrages humains. Pour une analyse approfondie, consultez Qu'est-ce qu'une software factory.

Les points de rupture de chaque étape

Modèle	Problème résolu	Problème suivant
Agent unique en chat	Aucun (situation de référence)	Une seule tâche à la fois par dev ; dossier de travail partagé
Un agent par branche, manuel	Tâches simultanées sans collisions de fichiers	Perte de contexte, prompts volatils, conflits tardifs au merge
File d'attente avec workers	Fin du lancement manuel des tâches	Spécifications et sorties non filtrées, opacité des coûts
Cycle de vie avec checkpoints	Évite les exécutions inutiles et le code non vérifié	Nécessite des outils dédiés : file, isolation, vérification, coûts, mémoire

Les six piliers indispensables d'un orchestrateur

L'orchestrateur est le composant logiciel chargé d'exécuter de manière fiable le modèle 4. Il doit obligatoirement assumer six responsabilités fondamentales ; si l'une d'elles fait défaut, elle devra être traitée manuellement et redeviendra immédiatement le facteur limitant de l'équipe :

File d'attente (Queue) : Les plans attendent dans un ordre précis avec un état explicite : ébauche (draft), approuvé (approved), en cours d'exécution (executing), en cours de vérification (verifying), en relecture (in review), fusionné (merged). L'avancement doit être consultable sans ouvrir de terminal.
Isolation : Chaque plan en cours reçoit son propre worktree et sa propre branche. La branche principale (main) ne subit jamais de modifications directes de la part d'un agent. Git worktrees pour agents IA parallèles démontre pourquoi les worktrees surpassent les dépôts partagés et les conteneurs.
Vérification automatique : Tests, linters, analyse statique de types et inspection de diff sont exécutés au sein du worktree dès la fin du travail de l'agent et avant toute sollicitation humaine. En cas d'échec, la tâche est renvoyée à l'agent avec la trace d'erreur complète.
Relecture humaine (Review) : Strictement deux points de contrôle — sur le plan et sur le diff —, chacun doté d'une action formelle d'approbation ou de rejet. Un rejet au niveau du plan ne consomme aucun token de génération de code. Un rejet au niveau du diff ne coûte qu'une seule itération.
Comptabilisation des coûts : Les tokens et les montants financiers sont enregistrés par plan et par tâche, permettant à l'équipe de connaître le coût réel de chaque pull request fusionnée et des plans abandonnés.
Mémoire contextuelle : Les enseignements tirés par l'agent lors d'un plan doivent être accessibles pour les suivants, sous peine de voir chaque agent repartir de zéro et répéter indéfiniment les mêmes erreurs.

L'implémentation par Ivy Tendril

Ivy Tendril est une application de bureau local-first pour macOS, Windows et Linux conçue pour exécuter le modèle 4 avec n'importe quel agent de code en ligne de commande. Elle s'utilise également en mode headless avec tendril --web.

Gestion de file d'attente : L'interface Plans centralise tous les plans avec leur statut. Les sections Drafts, Icebox et Recommendations organisent les travaux en attente de validation. Les plans peuvent être générés depuis des tickets GitHub ou des signalements jam.dev via webhooks, ou encore par le serveur MCP, l'API REST et la CLI.
Isolation étanche : Au lancement de l'exécution, Tendril génère un git worktree et une branche dédiés pour ce plan. De nombreux plans peuvent s'exécuter simultanément en parallèle. Une fois le code fusionné, Tendril supprime automatiquement le worktree. Voir Git worktrees pour agents IA parallèles.
Vérification intégrée : L'application Review présente les tests, le linting et le diff sous forme d'onglets pour chaque plan. Les offres Pro permettent d'importer directement les résultats de vérification depuis votre CI.
Relecture humaine : Au point de contrôle du plan, le relecteur peut utiliser les actions Expand, Split ou Update sur l'ébauche, ou insérer des commentaires pour régénérer le plan. Le point de contrôle du diff intervient après la vérification automatique. Aucune pull request n'est créée sans ces deux validations préalables.
Suivi budgétaire : La consommation de tokens et les dépenses sont mesurées pour chaque plan et chaque tâche, avec un tableau de bord affichant les indicateurs clés et l'évolution des coûts.
Mémoire d'ingénierie : Chaque phase du cycle de vie est pilotée par une unité de promptware comprenant un fichier Program.md d'instructions évolutives, un répertoire Memory/ de connaissances capitalisées sur la base de code, des Tools/ aux privilèges restreints et des journaux Logs/. Tendril intègre nativement CreatePlan, ExpandPlan, ExecutePlan, UpdatePlan, SplitPlan, CreatePr et CreateIssue. Voir promptware.

Tendril est agnostique vis-à-vis des agents. Il prend en charge Claude Code, OpenAI Codex CLI, GitHub Copilot CLI, Google Gemini CLI, OpenCode ainsi que tout autre agent en ligne de commande, le choix de l'agent ou du modèle pouvant être modifié plan par plan. Le code reste en permanence sur votre poste ; les seuls appels réseau sortants sont destinés à l'API LLM configurée et à GitHub.

Ivy indique que sa propre équipe de développement est passée d'environ 10 à plus de 100 pull requests par jour après avoir adopté ce flux de travail.

Comment démarrer

Installez Tendril : lancez curl -sSf https://cdn.ivy.app/install-tendril.sh | sh sous macOS ou Linux, ou irm https://cdn.ivy.app/install-tendril.ps1 | iex sous Windows. Instructions complètes sur la page d'installation.
Ouvrez un dépôt de code dans l'application et renseignez votre clé d'API pour le fournisseur de modèle de votre choix.
Créez un plan à partir d'un ticket existant, validez l'ébauche, lancez l'exécution et analysez le diff dans l'application Review.
Dès que ce premier plan est fusionné, créez trois plans simultanément et observez leur déroulement en parallèle.

Tendril est gratuit et son code est accessible sous licence Functional Source License ; les fonctionnalités d'équipe, l'authentification SSO, l'hébergement on-premise et l'import de vérifications CI sont proposés dans les forfaits Pro (59 $ par utilisateur et par mois) et Enterprise.

Foire aux questions

Des conteneurs sont-ils indispensables pour exécuter des agents en parallèle ?

Non. Les git worktrees offrent à chaque agent son propre répertoire de travail et sa propre branche tout en mutualisant la base d'objets. Les conteneurs apportent une isolation au niveau du runtime, utile uniquement si les agents doivent installer des paquets système ou ouvrir des ports réseau ; la grande majorité des tâches de développement n'en ont pas besoin.

Combien d'agents peuvent s'exécuter simultanément ?

La limite pratique provient généralement des quotas de requêtes (rate limits) des fournisseurs de modèles et de la puissance machine disponible pour compiler et tester, non de l'orchestrateur. Commencez avec trois à cinq plans en parallèle, puis augmentez progressivement la charge tant que les vérifications s'exécutent de manière fluide.

Que se passe-t-il lorsque deux plans touchent au même fichier ?

Le second plan qui tentera d'être fusionné provoquera un conflit sur sa branche. La bonne approche consiste à intervenir dès la phase de planification : scindez ou ordonnancez les plans qui touchent aux mêmes modules avant de lancer l'exécution, ce qui correspond exactement au rôle de l'action Split dans Tendril.

Premiers pas avec Ivy Tendril

Prêt pour une orchestration d'agents parallèle au niveau développeur ?

Explorer le code: Découvrez Ivy Tendril sur GitHub (Open Source).
Consulter la documentation: Trouvez des guides d'intégration sur tendril.ivy.app.
Planifier une session d'architecture: Contactez renco@ivy.app pour une consultation technique de 30 minutes.

Modèles d'orchestration d'agents : comment exécuter des agents de code en parallèle