neptay
Toutes les réflexions

Produits

Faire tourner plusieurs agents de codage IA en parallèle

Comment lancer plusieurs agents de codage IA en parallèle : environnement de développement pour agents (ADE), worktrees git, suivi et revue humaine du code.

Dans cet article

Un environnement de développement pour agents (ADE, de l’anglais agent development environment) est un espace de travail conçu pour faire tourner plusieurs agents de codage IA en même temps. Chaque agent reçoit sa propre tâche, une copie isolée du code et un statut visible, tandis qu’un humain découpe le travail, suit l’avancement et relit chaque modification avant qu’elle soit fusionnée.

L’essentiel à retenir

  • Des agents IA en parallèle ne sont rentables que si les tâches sont indépendantes, bien délimitées et vérifiables.
  • L’isolation passe avant tout : donnez à chaque agent son propre worktree git et sa propre branche.
  • L’observabilité est la fonction centrale d’un ADE : voir d’un coup d’œil quel agent travaille, attend, est bloqué ou a terminé.
  • Le goulot d’étranglement n’est plus la génération mais la revue : ne lancez pas plus d’agents que vous ne pouvez en relire.
  • Les humains restent responsables de chaque fusion : lisez le diff et lancez les vérifications vous-même.

Qu’est-ce qu’un agent de codage IA ?

Un agent de codage IA est un outil piloté par un modèle, capable de lire un dépôt, de modifier des fichiers et d’exécuter des commandes et des tests pour mener à bien une tâche décrite, au lieu de se contenter de suggérer du code pendant que vous tapez. On trouve par exemple des agents en ligne de commande comme Claude Code, Codex CLI et Gemini CLI, des modes agent dans les éditeurs de code, et des agents hébergés qui travaillent dans un bac à sable dans le cloud et renvoient une pull request.

Qu’est-ce qu’un environnement de développement pour agents (ADE) ?

Un IDE classique est pensé pour une personne qui modifie une seule copie de travail, et de nombreux éditeurs ajoutent désormais leurs propres fonctions d’agent. Mais dès que plusieurs agents tournent, c’est la coordination, et non plus l’édition, qui occupe le centre de votre journée. Le terme, parfois écrit agentic development environment (environnement de développement agentique), désigne l’endroit où l’on développe du logiciel avec des agents de codage IA, et non des outils servant à construire des agents IA.

Un ADE ne remplace ni votre éditeur ni les agents. C’est la couche d’orchestration qui se place au-dessus d’eux et prend en charge le travail qui se multiplie avec chaque nouvel agent :

  • Isolation des espaces de travail : un répertoire de travail et une branche par agent, sans gestion git manuelle.
  • Suivi des tâches : le brief confié à chaque agent, toujours visible.
  • Statut en direct : quels agents tournent, attendent une intervention, ont terminé ou ont échoué.
  • Espace de revue : le diff, les commandes et les résultats de tests de chaque agent, au même endroit.
  • Intégration : un chemin maîtrisé entre la branche de chaque agent et votre branche principale.

Pourquoi faire tourner plusieurs agents de codage IA en parallèle ?

Sur une tâche non triviale, un agent travaille souvent plusieurs minutes d’affilée : il lit, modifie, teste et corrige. Si vous supervisez les agents un par un, l’essentiel de ce temps se passe à attendre. Les agents en parallèle transforment ce temps d’attente en production utile : pendant que l’un refactorise, un deuxième écrit des tests pour un autre module et un troisième enquête sur un rapport de bug.

En pratique, trois schémas couvrent l’essentiel du travail en parallèle :

  • Répartition (fan-out) : plusieurs tâches indépendantes issues du même backlog, un agent par tâche, chacune fusionnée séparément.
  • Tentatives concurrentes : pour un problème ambigu, la même tâche est confiée à deux agents, ou deux fois avec des consignes différentes, et vous gardez le meilleur résultat.
  • Pipeline : un agent implémente, un deuxième relit le résultat ou écrit des tests pour le vérifier, et un humain tranche.

Quelles configurations pour faire tourner des agents de codage IA en parallèle ?

La plupart des équipes utilisent l’une de ces quatre configurations, et beaucoup les combinent :

  • Des onglets de terminal ou des panneaux tmux, avec un agent et un worktree git chacun : aucun nouvel outil, mais c’est à vous de suivre le statut de chaque agent.
  • Les fonctions multi-agents intégrées à un éditeur : pratiques quand toute l’équipe travaille déjà dans cet éditeur.
  • Des agents cloud ou en arrière-plan qui tournent dans un bac à sable hébergé et renvoient une pull request : rien ne s’exécute en local, et vous relisez une PR.
  • Un environnement de développement pour agents dédié : statut, diffs et revue de chaque agent au même endroit.

Quelles tâches confier à des agents de codage IA en parallèle ?

Soumettez chaque tâche candidate à quatre questions. Est-elle indépendante des autres tâches en cours ? Peut-elle être décrite dans un brief court ? Des tests, une vérification de types, un build ou un critère d’acceptation permettent-ils de la vérifier ? Touche-t-elle une partie différente de la base de code ?

Les bonnes candidates

  • Ajouter des tests aux modules qui manquent de couverture.
  • Des corrections de bugs circonscrites, avec une reproduction claire.
  • Des fonctionnalités isolées derrière une interface bien définie, comme un nouvel endpoint d’API ou un nouveau composant d’interface.
  • Des migrations mécaniques qui se découpent proprement par répertoire ou par package.
  • La documentation, l’amélioration du typage et les corrections de lint dans des zones que personne d’autre ne modifie.

Les mauvaises candidates

  • Les changements d’architecture qui se répercutent sur des types partagés ou sur le modèle de données.
  • Les tâches dont la définition de « terminé » est une affaire de goût.
  • Deux tâches qui doivent toutes deux modifier le même fichier central, comme un routeur, un schéma ou un manifeste de dépendances.
  • Un travail qui dépend du résultat d’une autre tâche encore inachevée.

Comment lancer plusieurs agents de codage IA : étape par étape

  1. Découper le travail en tâches indépendantes.
  2. Isoler chaque agent dans son propre worktree git, sur sa propre branche.
  3. Rédiger un brief que chaque agent peut exécuter.
  4. Observer, débloquer et intervenir.
  5. Relire et fusionner une branche à la fois.

Étape 1 : découper le travail en tâches indépendantes

Partez du résultat visé, pas des agents. Décomposez l’objectif en tâches qui peuvent chacune être terminées, vérifiées et fusionnées de façon autonome. Si deux tâches doivent modifier les mêmes fichiers, regroupez-les ou exécutez-les l’une après l’autre. Une courte note de dépendance, du type « nécessite le nouveau schéma de la tâche 2 », évite la plupart des mauvaises surprises à l’intégration.

Étape 2 : isoler chaque agent avec des worktrees git

Deux agents dans le même répertoire de travail peuvent écraser les modifications l’un de l’autre et fausser mutuellement leurs exécutions de tests. L’isolation fiable la plus simple est le worktree git : un répertoire de travail supplémentaire rattaché au même dépôt, sur sa propre branche.

Exemple de code
# One worktree and one branch per agent
git worktree add -b agent/auth-refactor ../app-agent-auth
git worktree add -b agent/billing-tests ../app-agent-tests

# See what is checked out where
git worktree list

# Clean up once the branch has been merged locally (use -D after a squash merge)
git worktree remove ../app-agent-auth
git branch -d agent/auth-refactor

Par défaut, git refuse d’extraire la même branche dans deux worktrees à la fois, et c’est exactement le garde-fou recherché. Au moment du nettoyage, git worktree remove refuse de supprimer un worktree qui contient des fichiers modifiés ou non suivis : commitez-les ou abandonnez-les d’abord, ou ajoutez --force une fois que vous en êtes sûr. Les worktrees isolent les fichiers, pas tout le reste. Anticipez ce qu’ils partagent :

  • Dépendances et sorties de build : chaque worktree a généralement besoin de ses propres paquets installés (node_modules, environnements virtuels) et de sa propre sortie de build.
  • Ports : deux serveurs de développement ne peuvent pas écouter sur le même port, alors attribuez-en un par agent.
  • Bases de données : utilisez des bases ou des schémas locaux distincts, jamais un environnement de staging partagé.
  • Fichiers d’environnement : ne copiez que la configuration non secrète dont chaque agent a besoin.

Étape 3 : rédiger un brief que chaque agent peut exécuter

Les agents comblent chaque lacune d’un brief par des suppositions. Un bon brief est court mais complet :

  • Objectif : une phrase qui décrit le résultat attendu, pas l’implémentation.
  • Contexte : les fichiers, modules ou documents qui comptent, et les conventions à respecter.
  • Limites : ce que l’agent ne doit pas modifier, comme les interfaces publiques, les migrations ou les dépendances.
  • Définition de « terminé » : les tests, vérifications de types ou comportements qui doivent passer.
  • Compte rendu : ce que l’agent doit vous remettre, par exemple un résumé des changements et les questions en suspens.

Des instructions de projet persistantes, placées dans un fichier que l’agent lit au démarrage (AGENTS.md ou CLAUDE.md selon l’agent), vous évitent de répéter les conventions dans chaque brief.

Étape 4 : observer, débloquer et intervenir

Une fois les agents lancés, vous passez du rôle d’auteur à celui de superviseur. Faites le point à intervalles réguliers plutôt que de regarder défiler la sortie d’un seul agent, et répondez vite aux demandes d’autorisation, car un agent bloqué, c’est du temps perdu. Arrêtez tôt un agent qui dérive : le relancer avec un brief plus précis est généralement plus rapide que de rattraper une longue exécution partie dans la mauvaise direction.

Étape 5 : relire et fusionner une branche à la fois

Fusionnez dans l’ordre des dépendances, une branche à la fois. Après chaque fusion, rebasez les branches restantes sur la branche principale à jour et relancez leurs vérifications. À ce stade, les conflits sont une information utile : ils révèlent des tâches moins indépendantes qu’elles n’en avaient l’air.

Comment éviter les conflits entre agents IA

La plupart des conflits entre agents en parallèle viennent de quelques points chauds partagés :

  • Fichiers de verrouillage (lockfiles) et manifestes de dépendances : n’autorisez qu’un seul agent par cycle à ajouter ou mettre à jour des dépendances.
  • Migrations de base de données : exécutez-les l’une après l’autre, car des migrations générées en parallèle peuvent entrer en conflit sur leur ordre ou sur l’état du schéma.
  • Registres partagés comme les routeurs et la configuration : attribuez chaque fichier à un seul propriétaire, ou faites la modification vous-même en premier.
  • Code généré : régénérez-le après la fusion au lieu de fusionner des fichiers générés provenant de plusieurs branches.
  • Reformatage superflu : demandez aux agents de ne pas reformater les fichiers qu’ils n’ont pas modifiés par ailleurs.

Les branches à courte durée de vie sont l’autre moitié de la réponse : de petites tâches fusionnées en quelques heures provoquent bien moins de conflits que des branches qui s’éloignent de la branche principale pendant des jours.

Comment suivre ce que fait chaque agent de codage IA ?

Avec un agent, vous surveillez le terminal. Avec cinq, c’est impossible. Pour chaque agent, vous devez pouvoir répondre d’un coup d’œil à ces questions :

  • Sur quoi travaille-t-il, et quel brief lui a été confié ?
  • Dans quel état est-il : en cours, en attente d’une réponse ou d’une autorisation, bloqué sur une erreur, ou terminé ?
  • Qu’a-t-il modifié jusqu’ici, sous forme de diff par rapport à sa branche de base ?
  • Quelles commandes a-t-il exécutées, et les tests et vérifications ont-ils réussi ?
  • Depuis combien de temps tourne-t-il, et quelle est sa consommation jusqu’ici ?

Les notifications comptent autant que les tableaux de bord. Un agent qui attend dix minutes une validation d’un seul mot est un coût caché fréquent du travail en parallèle. Un bon environnement de développement pour agents fait remonter ces moments immédiatement.

Combien coûte l’utilisation de plusieurs agents de codage IA ?

Le coût a deux composantes : l’utilisation des modèles et le temps humain. L’utilisation des modèles augmente avec le nombre d’agents, la durée de leurs exécutions et le contexte qu’ils lisent. Que vous payiez au token ou que vous travailliez dans les limites d’un abonnement, des agents en parallèle consomment ce budget plus vite, et les tentatives concurrentes le dépensent délibérément pour du travail que vous jetterez.

Le temps humain est le coût le plus souvent sous-estimé, car la production de chaque agent doit être lue, testée et intégrée. Une règle empirique utile : ne lancez pas plus d’agents que vous ne pouvez en relire avec le soin que vous accordez à la pull request d’un collègue. Pour garder ces deux coûts sous contrôle :

  • Gardez des tâches petites, pour des exécutions courtes et des diffs faciles à relire.
  • Orientez les agents vers les fichiers pertinents plutôt que vers tout le dépôt.
  • Arrêtez les exécutions qui dérivent au lieu de les laisser aller jusqu’au bout.
  • Suivez l’utilisation par tâche pour savoir quels types de travail valent la peine d’être délégués.

Pourquoi la revue humaine du code généré par l’IA reste indispensable

Les agents de codage IA sont compétents, mais ils ne sont pas responsables. Ils peuvent mal interpréter une exigence, écrire des tests qui valident le mauvais comportement, faire taire une erreur au lieu de la corriger, ou annoncer qu’une vérification a réussi alors qu’elle n’a jamais été lancée. Le code écrit par des humains est relu pour les mêmes raisons ; les agents en parallèle produisent simplement davantage de modifications, plus vite.

Une boucle de revue pragmatique comporte trois niveaux : l’agent vérifie son propre travail au regard de la définition de « terminé » ; éventuellement, un deuxième agent relit le diff avec un contexte neuf ; enfin, un humain lit le diff et décide de fusionner ou non. Les niveaux automatisés réduisent le bruit ; ils ne remplacent pas cette décision.

Checklist de revue pour les modifications écrites par un agent

  • Lisez le diff lui-même, pas seulement le résumé qu’en donne l’agent.
  • Lancez vous-même les tests et les vérifications, ou confirmez qu’ils ont bien tourné en CI.
  • Repérez les dérives de périmètre : des fichiers modifiés dont le brief ne parlait pas.
  • Contrôlez les nouvelles dépendances, les appels réseau et tout ce qui touche à l’authentification, aux paiements ou aux données personnelles.
  • Assurez-vous qu’aucun secret, token ou chemin propre à une machine n’a été commité.
  • Vérifiez que les nouveaux tests mettent réellement à l’épreuve le nouveau comportement, et ne se contentent pas de passer.

Les erreurs fréquentes quand on fait tourner plusieurs agents IA

  • Faire tourner deux agents dans le même répertoire de travail et perdre du travail à cause de fichiers écrasés.
  • Laisser des branches d’agents ouvertes pendant des jours, jusqu’à ce qu’elles ne fusionnent plus proprement.
  • Donner aux agents des identifiants de production ou des permissions dont ils n’ont pas besoin.
  • Compter les agents en cours d’exécution plutôt que les modifications fusionnées et fonctionnelles.

Questions fréquentes

Quelle différence entre un IDE et un environnement de développement pour agents ?

Un IDE classique est centré sur une personne qui modifie du code dans une seule copie de travail, même si de nombreux éditeurs intègrent désormais des fonctions d’agent. Un environnement de développement pour agents est centré sur la supervision de plusieurs agents de codage IA, avec l’isolation des espaces de travail, le suivi des tâches, le statut en direct et un circuit maîtrisé de revue et de fusion. Beaucoup de développeurs utilisent les deux : l’ADE pour coordonner les agents, l’IDE pour examiner ou terminer leur travail.

Combien d’agents de codage IA faire tourner en même temps ?

Autant que vous pouvez en relire correctement. En règle générale, commencez avec deux ou trois agents sur des tâches clairement indépendantes. N’augmentez leur nombre que si votre processus de revue et de fusion suit le rythme. Si des diffs attendent des jours avant d’être relus, ou si vous vous surprenez à fusionner sans lire, c’est que vous en faites tourner trop.

Faut-il des worktrees git pour faire tourner des agents en parallèle ?

Il vous faut une forme d’isolation, et les worktrees git sont l’option la plus légère : chaque agent dispose de son propre répertoire et de sa propre branche au sein d’un même dépôt partagé. Des clones séparés ou des conteneurs isolent plus fortement, mais demandent plus d’espace disque et de configuration. Les bacs à sable hébergés qui renvoient une pull request sortent l’isolation de votre machine, mais pas la revue. Ne laissez jamais deux agents modifier le même répertoire de travail en même temps.

Des agents de codage IA peuvent-ils relire le code les uns des autres ?

Oui, et c’est un niveau de contrôle supplémentaire utile. Un deuxième agent, doté d’un brief de relecteur et d’un contexte neuf, repère souvent des tests manquants, des cas limites non gérés et des dérives de périmètre. Il ne doit toutefois pas être le dernier filtre : les agents peuvent partager les mêmes angles morts, donc un humain doit toujours lire le diff et décider de la fusion pour tout ce qui part en production.

Est-il sûr de laisser des agents de codage IA exécuter des commandes sur ma machine ?

Cela peut l’être, avec des garde-fous. Accordez aux agents le minimum de privilèges nécessaires, tenez les identifiants de production à l’écart de leur environnement et exigez une validation pour les commandes destructrices ou qui accèdent au réseau. Considérez comme non fiable tout ce qu’un agent lit en dehors de votre base de code, comme des tickets, des pages web ou des fichiers tiers, car ces contenus peuvent renfermer des instructions conçues pour tromper l’agent : c’est le risque appelé injection de prompt (prompt injection). Les conteneurs ajoutent une protection supplémentaire.

L’approche de Neptay en matière de développement avec des agents

Nous concevons des agents IA et des automatisations dans le cadre de nos prestations pour nos clients, et nous développons nos propres produits technologiques sous la marque Anlato. Anlato Space, le produit phare de la famille Anlato, est notre environnement de développement pour agents : de nombreux agents de codage IA côte à côte dans une seule fenêtre native, chacun avec sa tâche et son statut, et chaque modification en attente de votre revue. Il arrive bientôt. Si vous concevez un workflow d’agents pour votre équipe, ou si vous souhaitez suivre Anlato Space, écrivez-nous à hello@neptay.com.

Chez NeptayAnlato Space

Neptay Media & Technology Services

Parlons-en

Vous préparez un projet similaire ?

Les méthodes décrites dans ces articles sont celles que nous appliquons aux projets de nos clients — logiciels, automatisation IA, contenu, réseaux sociaux et production de lives. Dites-nous ce que vous avez en tête ; nous répondons sous 24 heures.