Claude Code et Codex peuvent-ils travailler sur le même projet en même temps ?

Oui. Chacun tourne dans sa propre session de terminal. La configuration la plus sûre consiste à répartir le travail par dossier ou à donner à chaque agent son propre worktree git pour qu’ils ne modifient jamais les mêmes fichiers.

Les agents parallèles ont-ils besoin de comptes distincts ?

Non. Chaque CLI utilise sa propre connexion. Vous pouvez ouvrir plusieurs agents sur un même compte ; les limites d’usage se remplissent par compte.

Combien d’agents lancer en même temps ?

Autant que vous pouvez en suivre. Deux à quatre agents restent gérables pour la plupart des projets ; au-delà, les flows et les notifications aident.

Les agents peuvent-ils utiliser la sortie les uns des autres ?

Avec les flows d’AgentVera, la dernière réponse d’un agent est envoyée à un autre via un modèle, sans copier-coller à la main.

Agents de code en parallèle : Claude Code et Codex

Les agents de code en parallèle, c’est faire tourner plus d’un agent de code IA sur le même projet en même temps. Un agent écrit une fonctionnalité, un autre écrit les tests, un troisième met à jour la doc. Bien configuré, vous répartissez un travail que vous faisiez étape par étape. Mal configuré, les agents écrasent les mêmes fichiers, le contexte gonfle et vous perdez la trace de qui a fait quoi.

Cet article présente une manière pratique de faire tourner Claude Code et Codex côte à côte : comment répartir le travail, comment éviter les conflits de fichiers et comment faire passer la sortie d’un agent au suivant.

Pourquoi des agents de code en parallèle ?

Avec un seul agent, le goulot d’étranglement, c’est l’attente. Pendant qu’il réfléchit, lit des fichiers et lance des tests, vous attendez ou passez à autre chose. Les agents parallèles mettent ce temps d’attente à profit.

Ils rapportent le plus quand vous avez :

Du travail indépendant : un endpoint backend et un formulaire frontend qui ne se touchent pas.
De l’écriture et de la vérification : un agent écrit le code, un autre écrit les tests du même changement.
De la recherche et de l’implémentation : un agent compare des bibliothèques pendant qu’un autre modifie le code existant.
Des forces différentes : Claude Code et Codex arrivent avec des modèles et des jeux d’outils différents ; essayer les deux approches sur le même problème peut y mener plus vite. Pour leurs différences, voir Claude Code vs Codex.

Trois règles pour répartir le travail

Le succès du travail parallèle dépend de la façon de le répartir.

1. Tracez les frontières de fichiers d’avance

Deux agents qui modifient le même fichier, c’est l’échec le plus courant. Indiquez dans le rôle de chaque agent quels dossiers il peut toucher. Par exemple, un agent ne travaille que sous src/api/, l’autre que sous tests/.

2. Donnez un seul objectif à chaque agent

Plutôt que « améliore le module d’auth », donnez un objectif mesurable comme « passe la gestion de session aux refresh tokens ». Un objectif clair permet à l’agent de s’arrêter tôt et rend sa sortie facile à vérifier.

3. Décidez où va la sortie

Si le résultat d’un agent alimente un autre, concevez cela d’avance. Écrira-t-il un fichier de plan, commitera-t-il, ou enverra-t-il sa réponse directement à l’agent suivant ?

Éviter les conflits de fichiers avec les worktrees git

Quand les frontières de dossiers ne suffisent pas, l’option la plus robuste est un arbre de travail séparé par agent. Les worktrees git ouvrent des dossiers distincts sur différentes branches du même dépôt :

git worktree add ../acme-web-auth -b auth-refactor
git worktree add ../acme-web-tests -b auth-tests

Chaque agent travaille dans son propre dossier et ne touche jamais les fichiers de l’autre. Une fois terminés, vous fusionnez les branches par une pull request normale. J’en parle en détail dans les worktrees git pour agents parallèles.

Dans AgentVera, les worktrees se trouvent dans le panneau de droite : créez-en un à partir d’une branche nouvelle ou existante, voyez son nombre de changements et son avance ou son retard par rapport à la branche principale, et démarrez un agent directement dedans.

Exemple de configuration : Claude Code écrit, Codex teste

Une disposition de départ simple et efficace :

Agent	Outil	Rôle	Travaille dans
Architect	Claude Code	Planifie et implémente la fonctionnalité	Worktree `auth-refactor`
Tester	Codex	Écrit les tests d’intégration du changement	Même worktree, `tests/` uniquement
Serveur de dev	Terminal	Lance `pnpm dev`	Dossier principal

Étapes de mise en place :

Ajoutez le dossier du projet à AgentVera.
Dans la boîte de dialogue « New agent », choisissez Claude Code, nommez-le « Architect » et écrivez les frontières de fichiers dans son rôle.
Faites de même pour Codex sous le nom « Tester ».
Démarrez le serveur de dev dans un agent Terminal.
Donnez sa tâche à Architect ; quand il termine son tour, transmettez sa sortie à Tester.

Plutôt que de faire la dernière étape à la main, construisez un flow. Les flows envoient la dernière réponse d’un agent à un autre via un modèle {{output}}, et attendent que l’agent cible termine son tour s’il est occupé.

Garder un œil sur les agents parallèles

À mesure que le nombre d’agents augmente, le vrai travail devient de les suivre. Surveillez :

L’état : quel agent travaille, lequel vous attend, lequel a rencontré une erreur ?
La taille du contexte : les longues conversations coûtent plus de tokens à chaque tour.
Les demandes d’approbation : un agent qui attend une permission s’arrête pendant que les autres continuent.

L’espace de travail d’AgentVera montre les agents côte à côte dans une grille. Chaque panneau affiche son état, la taille de contexte en direct et une zone de message. Les agents en attente d’approbation sont listés dans la barre d’état, et ⇧⌘A saute à celui qui attend depuis le plus longtemps.

Contexte et coût

Travailler en parallèle multiplie aussi la consommation de tokens. La première requête de chaque agent embarque les définitions d’outils, le prompt système et les plugins. Dans les longues conversations, cette base est relue à chaque tour.

Pour maîtriser le coût :

Démarrez les agents pour des tâches simples avec un jeu d’outils plus restreint.
Compactez les longues conversations avec /compact.
Quand vous passez une sortie d’un agent à l’autre, n’envoyez que la partie nécessaire.

Pour des chiffres mesurés, voir réduire la consommation de tokens de Claude Code.

Erreurs fréquentes

Deux agents sur un même fichier. Le correctif le plus rapide est un worktree ou une frontière de dossier stricte.

Des tâches vagues. Des tâches ouvertes comme « corrige le code » poussent l’agent à lire des fichiers sans fin et gonflent le contexte.

Fusionner sans vérifier. Lancez les tests et relisez les diffs avant de fusionner ce que les agents parallèles ont produit. La revue de code automatique fait gagner du temps ici.

Tout démarrer d’un coup. Commencez avec deux agents et ajoutez un troisième une fois la répartition rodée.

Un exemple de bout en bout : passer aux refresh tokens

Répartir le travail paraît facile sur le papier ; voici comment cela se passe sur une vraie tâche. L’objectif : faire passer la gestion de session d’une application web à des access tokens de courte durée avec des refresh tokens à rotation.

Découper la tâche

D’abord, découpez le travail en morceaux indépendants. Cette tâche en compte trois :

Côté serveur : émission, validation et rotation des tokens (src/auth/).
Tests : tests d’intégration du nouveau flux (tests/api/).
Docs : refléter les changements d’API dans le README.

Le côté serveur et les tests regardent le même comportement mais vivent dans des dossiers différents. La doc n’a de sens qu’une fois le côté serveur stabilisé. Lancez donc les deux premiers en parallèle et le troisième ensuite.

Instructions de rôle

Gardez le rôle de chaque agent court et strict. Pour Architect :

Work only under src/auth/. Don't change tests.
Run pnpm test auth after every change.
When you're done, summarize your changes as a bullet list.

Pour Tester :

Work only under tests/. Don't touch application code.
Write integration tests for the behaviors in the summary you receive.

La dernière ligne du rôle d’Architect compte : son résumé devient l’entrée de Tester via le flow. Plus le résumé est net, moins Tester a de fichiers à lire.

Transmission et suite

Quand Architect termine son tour, le flow envoie sa dernière réponse à Tester via un modèle. Si Tester est occupé, le flow attend la fin de son tour, et la limite de tours de la connexion empêche les deux agents de boucler indéfiniment. Pendant ce temps, vous pouvez surveiller les logs du serveur de dev dans l’agent terminal ou faire préparer la doc par un troisième agent.

Quand ne pas passer en parallèle

Tout ne se parallélise pas. Restez sur un seul agent qui avance étape par étape quand :

Le changement est concentré dans un fichier ou quelques fichiers étroitement liés.
La tâche n’est pas encore claire ; recherche et plan viennent d’abord.
La sortie d’un agent est un prérequis pour l’autre, et la seconde tâche est courte.

Dans ces cas, un pipeline par étapes fonctionne mieux que le parallélisme. J’en parle dans le workflow d’agents IA.

Checklist

Avant une session parallèle :

L’objectif de chaque agent tient-il en une phrase ?
Les frontières de fichiers figurent-elles dans le rôle ?
Si des conflits sont probables, chaque agent a-t-il son propre worktree ?
Si la sortie d’un agent alimente un autre, le flow ou le fichier de plan est-il prêt ?
Y a-t-il un agent ou un terminal pour lancer les tests ?

Pour conclure

Les agents de code en parallèle font gagner un vrai temps sur un travail qui se divise proprement. La clé est de séparer les agents et de définir la transmission entre eux. Les worktrees séparent les fichiers, les flows transportent les sorties, et des rôles bien écrits séparent les responsabilités.

AgentVera est conçu pour mettre cela en place dans une seule fenêtre : Claude Code, Codex et d’autres CLI tournent côte à côte avec leurs propres connexions. Vous pouvez commencer avec l’offre gratuite et consulter les offres quand il vous en faut plus.