Vous avez une tâche Codex en cours, un correctif de bug que vous voulez déléguer, une suite de tests à couvrir et une refactorisation que vous ne cessez de repousser. Les quatre sont indépendantes. Rien n'empêche de les lancer en même temps, sauf un obstacle très concret : pointez deux sessions Codex sur le même checkout et elles se mettent à écraser mutuellement leurs modifications. Le parallélisme que vous vouliez se transforme en fusion que vous n'avez pas demandée.
Faire tourner plusieurs tâches Codex en parallèle relève moins d'une fonctionnalité que l'on active que d'une configuration que l'on met en place. Trois voies existent : les tâches cloud de Codex, plusieurs sessions CLI locales et les sous-agents au sein d'une même session. Chacune apporte une vraie concurrence, et chacune a un mode de défaillance qui se manifeste dès que les écritures se chevauchent. Ce guide passe en revue les trois, avec les commandes et la défaillance nommées à chaque étape, puis montre où un tableau de tâches prend le relais.
Ce tableau de tâches, c'est Sharkly. Vous avez déjà Codex. Sharkly se place au-dessus : il exécute Codex comme un Runtime et transforme chaque exécution parallèle en une Tâche dotée de son propre checkout isolé, de son propre journal et de son propre relecteur. L'article commence par la configuration manuelle, car mieux vaut comprendre ce que l'on automatise avant de l'automatiser.
TL;DR
Les agents Codex parallèles, c'est le fait d'exécuter plusieurs tâches Codex simultanément plutôt qu'une à la fois. Trois façons de procéder : les tâches cloud Codex (chacune dans un environnement isolé, comme l'indique la documentation d'OpenAI), plusieurs sessions locales du CLI codex, ou des sous-agents au sein d'une même session. La règle qui les régit toutes : une copie de travail par unité de travail. Donnez à chaque tâche son propre worktree git pour que les modifications concurrentes ne touchent jamais les mêmes fichiers. Cela tient sans problème jusqu'à une poignée de tâches. Au-delà, savoir quel agent a fait quoi et relire chaque résultat séparément devient le goulot d'étranglement : c'est la couche que Sharkly ajoute.
Les trois façons d'exécuter Codex en parallèle
Choisissez votre voie en fonction de l'endroit où le travail s'exécute et de ce que vous avez besoin de voir, pas de celle qui sonne le plus puissant.
| Voie | Mode d'exécution | Isolation | Idéal pour |
|---|---|---|---|
| Tâches cloud Codex | Chaque tâche dans son propre environnement cloud | Forte, par tâche | Tâches déléguées et autonomes, relues plus tard |
| Sessions CLI multiples | Plusieurs processus codex sur votre machine |
Aucune par défaut ; checkout partagé | Travail local que vous voulez suivre en direct |
| Sous-agents dans une session | Une session répartit les threads qu'elle a lancés | Répertoire de session partagé | Travail à forte composante de lecture : exploration, triage, tests |
Utilisez les tâches cloud Codex quand le travail est bien cadré et que vous acceptez de le vérifier après coup. Utilisez les sessions CLI locales quand vous voulez piloter chaque exécution en temps réel. Utilisez les sous-agents quand la tâche consiste surtout à lire, car les agents lancés partagent un même répertoire de travail et, d'après le comportement des sous-agents Codex, la session attend qu'ils aient tous terminé et renvoie une seule réponse consolidée. Cette dernière forme ne convient pas à l'écriture en parallèle : des agents qui modifient le code en même temps créent des conflits, et un résumé unique ne peut pas être relu morceau par morceau.
Étape par étape : exécuter plusieurs tâches Codex en local sans collisions
La voie locale est celle que la plupart des gens adoptent en premier, et celle qui casse en premier. Voici la configuration qui tient bon.
Étape 1. Donnez à chaque tâche son propre checkout. Un git worktree est un second répertoire de travail adossé au même dépôt, sur sa propre branche. Créez-en un par tâche :
git worktree add ../app-authfix -b fix/token-refresh
git worktree add ../app-tests -b test/checkout-coverage
git worktree add ../app-refactor -b refactor/api-client
Ce qui casse si vous sautez cette étape : deux sessions codex dans le même dossier modifient les mêmes fichiers, l'écriture la plus tardive l'emporte en silence, et les deux annoncent un succès. Vous découvrez la perte en relecture, ou en production.
Étape 2. Lancez une session Codex par worktree. Ouvrez un terminal dans chaque répertoire et lancez-y Codex :
cd ../app-authfix && codex
Ce qui casse si vous sautez cette étape : une session avec quatre objectifs dans son contexte part dans tous les sens et perd la trace de la modification qui appartient à quelle tâche.
Étape 3. Scriptez celles qui n'ont pas besoin d'un humain au clavier. Pour une tâche autonome, le mode non interactif va jusqu'au bout sans invite :
cd ../app-tests && codex exec "add tests for the checkout flow until coverage passes"
Ce qui casse si vous sautez cette étape : vous restez à surveiller des sessions qui n'ont jamais eu besoin de vous, ce qui annule tout l'intérêt de les exécuter en parallèle.
Étape 4. Fusionnez délibérément, une branche à la fois. Chaque worktree est une branche : relisez-les et fusionnez-les séparément. Ne laissez jamais les agents fusionner le travail les uns des autres. Ce qui casse si vous sautez cette étape : trois branches atterrissent d'un coup, un conflit apparaît dans le commit de fusion, et vous ne savez plus quelle modification d'agent en est la cause.
Pour les détails du nettoyage des worktrees après coup, voir gérer les worktrees des agents de codage sans le casse-tête du nettoyage. Ce même schéma de worktree fait fonctionner l'exécution de plusieurs agents Claude Code ; il est neutre vis-à-vis du runtime par conception.
Là où la configuration maison cesse de passer à l'échelle
Les worktrees règlent les collisions. Ils ne règlent pas tout, et le mur est plus proche qu'il n'y paraît.
À trois ou quatre tâches, la configuration tient. À huit, la grille de terminaux cesse d'être un espace de travail pour devenir un test de mémoire. Les défaillances ne sont pas spectaculaires ; elles s'accumulent :
- Vous perdez la carte. Quelle fenêtre correspond au correctif d'authentification ? Laquelle a terminé ? Laquelle a échoué il y a vingt minutes et tourne à vide depuis ? L'état n'existe que dans votre tête et défile hors de l'écran.
- La relecture n'a aucune couture. La sortie de chaque session est un mur de scrollback. Aucun enregistrement par tâche ne dit ce qu'elle a touché, ce qu'elle a exécuté et où elle s'est arrêtée ; impossible donc d'accepter un résultat et de rejeter un autre proprement.
- Rien n'est partagé. Dès qu'un collègue veut voir l'avancement, vous copiez des diffs dans un fil Slack. Le travail est bien réel, mais invisible.
Ce sont les trois mêmes problèmes sur lesquels converge tout flux de travail d'agents parallèles, et c'est pourquoi les équipes se tournent vers des outils dédiés à la gestion des agents de codage parallèles dès que le nombre grimpe. L'isolation est un problème résolu. La visibilité et la relecture ne le sont pas, du moins pas avec une grille de terminaux.
Ce qu'apporte un tableau de tâches
C'est ici que la couche au-dessus de l'agent justifie sa place. Dans Sharkly, une Tâche est l'enregistrement partagé d'une unité de travail, et exécuter des tâches Codex en parallèle revient à exécuter des Tâches en parallèle.
Chaque Tâche s'approprie automatiquement un worktree git isolé : les agents parallèles dans des worktrees isolés cessent d'être quelque chose que vous scriptez pour devenir la norme. Dix Tâches sur un seul dépôt, zéro état partagé, aucun git worktree add tapé à la main. Le Runtime qui effectue les modifications reste Codex ; l'isolation est fournie autour de lui.
La répartition des rôles est tout l'intérêt. Les agents explorent, exécutent, testent et rendent compte. Les humains donnent la direction, accordent l'autorité et acceptent le résultat. L'automatisation s'arrête là où le jugement de l'équipe est requis. Ainsi, chaque exécution conserve son propre journal, avec le déclencheur, les appels d'outils et le point d'arrêt, et son résultat final revient à la Tâche au lieu de défiler dans un terminal. Contexte, avancement, blocages, résultats et relecture humaine restent visibles de la demande à la livraison, et vous relisez chaque élément individuellement plutôt que de lire un résumé de résumés. Pour le volet reporting, voir comment suivre le travail réalisé par les agents de codage IA.
Sharkly ne remplace pas Codex. Il ajoute la couche partagée de tâches, de checkouts, de contexte et de relecture autour de l'agent que vous utilisez déjà. Si vous ne faites jamais tourner qu'une seule session Codex à la fois, vous n'en avez pas besoin. Si vous en faites tourner plusieurs sur une même base de code et que vous perdez le fil, c'est précisément le problème pour lequel il a été conçu. Vous pouvez monter la configuration de worktrees ci-dessus à la main, ou faire passer vos tâches Codex existantes par Sharkly et laisser le flux de travail conserver l'état pour vous.
Une checklist à appliquer dès aujourd'hui
- Un worktree git par tâche, chacun sur sa propre branche. Aucune tâche ne partage son checkout avec une autre.
- Une session Codex par worktree, ou
codex execpour les tâches qui n'ont pas besoin de vous. - N'utilisez les sous-agents que pour le travail à forte composante de lecture ; réservez les écritures concurrentes à des checkouts séparés.
- Fusionnez une branche à la fois et relisez chacune avant qu'elle n'atterrisse.
- Tenez un registre indiquant quelle tâche correspond à quoi, ce que chacune a touché et son résultat, dans un endroit visible par vos collègues.
- Quand la grille de terminaux ne tient plus dans votre tête, transférez le suivi et la relecture vers un tableau de Tâches pour que chaque exécution renvoie son résultat au même endroit partagé.
FAQ
Codex peut-il exécuter plusieurs tâches en même temps ? Oui. Codex cloud exécute les tâches dans des environnements isolés, comme l'indique la documentation d'OpenAI, et en local vous pouvez lancer plusieurs sessions codex à la fois. La contrainte, c'est le checkout, pas Codex : donnez à chaque tâche locale son propre worktree git pour que leurs modifications ne se percutent pas.
Combien d'agents Codex parallèles puis-je exécuter ? Autant que votre machine et votre quota de modèle le permettent. Le plafond réel est plus bas : c'est le nombre de résultats simultanés qu'une personne peut réellement relire. Au-delà d'une poignée, c'est le suivi et la relecture, et non la puissance de calcul, qui deviennent la limite.
Ai-je besoin de worktrees, ou puis-je simplement ouvrir plus de terminaux ? Plus de terminaux dans le même répertoire signifie des écritures simultanées dans les mêmes fichiers et des écrasements silencieux. Les worktrees donnent à chaque session son propre répertoire et sa propre branche, et c'est ce qui rend le parallélisme local sûr. Voir les worktrees git pour les agents de codage IA.
Quelle différence entre les sous-agents Codex et les tâches parallèles ? Les sous-agents s'exécutent dans une seule session, partagent son répertoire de travail et renvoient une réponse consolidée unique, ce qui convient à la lecture et au triage. Les tâches parallèles sont des exécutions distinctes avec des checkouts distincts, ce qu'il vous faut pour l'écriture concurrente et une relecture indépendante.
