Parallèle ne veut pas dire donner la même tâche à cinq agents
Les workflows Codex parallèles marchent quand chaque agent possède une partie séparée du problème. Ils échouent quand tout le monde modifie les mêmes fichiers et produit un énorme conflit de merge.
Le but : découper une fonctionnalité en workstreams sûrs, lancer Codex sur des agents VPS séparés, puis recombiner seulement après tests et revue. Office Claws rend cela praticable : chaque agent a son hôte, sa branche, son terminal et son bureau visible dans l’app. Vous gardez les décisions produit; les agents prennent l’attente, les tests et les changements mécaniques.
La règle : découper par frontières, pas par envies
Un mauvais découpage :
- Agent A : implémenter la fonctionnalité
- Agent B : ajouter les tests
- Agent C : mettre à jour la documentation
Cela semble parallèle, mais B ne connaît pas encore l’interface et C documentera peut-être un comportement qui change.
Un meilleur découpage suit les frontières techniques :
- Agent A : migration et couche repository
- Agent B : route API et validation
- Agent C : états UI vide, chargement et erreur
- Agent D : documentation et note de version une fois l’interface stabilisée
Si deux agents doivent modifier le même fichier, le découpage est probablement mauvais.
Un workflow pratique en quatre branches
1. Écrire un contrat d’abord
Avant de lancer les agents, écrivez un petit contrat dans la branche principale : types, forme de l’endpoint, fichiers et commande de test.
Endpoint: POST /api/runs/:id/retry
Request: { mode: "failed-only" | "all" }
Response: { runId: string, queuedTasks: number }
Tests: npm run test -- retry
Ne pas renommer les valeurs RunStatus existantes.C’est ennuyeux, mais c’est ce qui sépare le parallélisme du chaos.
2. Une branche par agent
Nommez les branches par responsabilité :
feat/retry-runs-apifeat/retry-runs-uifeat/retry-runs-testsdocs/retry-runs-release-note
Dans Office Claws, chaque agent Codex travaille sur son propre VPS et sa propre branche. Les expériences ratées restent isolées.
3. Des prompts étroits
Tu possèdes uniquement la route API et la validation pour retry runs.
Ne modifie pas les fichiers UI. Ne renomme pas les enums partagés.
Avant de terminer, exécute : npm run test -- retry
Retourne un résumé, les fichiers modifiés et tout changement de contrat nécessaire.Les interdictions évitent les conflits de merge.
L’ordre de merge compte
Fusionnez d’abord la base : modèle de données, API, UI, puis docs. Après chaque merge, rebasez les branches restantes pour que chaque agent voie le contrat actuel.
- Merge repository/base de données après tests verts
- Rebase API, correction de la dérive, merge
- Rebase UI et connexion au vrai endpoint
- Tests et docs en dernier
N’attendez pas la fin pour tout fusionner. Cela crée une revue géante et cache l’endroit où le design a changé.
Quand cela vaut le coup
Le parallélisme aide quand les limites sont naturelles :
- Backend + frontend + docs
- Migration + adaptateur + tests
- Refactoriser un package pendant qu’un autre agent met à jour les appels
- Explorer trois corrections possibles et garder la meilleure
- Porter le même motif vers plusieurs intégrations indépendantes
Pour un bug de 20 lignes, une seule session Codex est plus rapide.
Le rôle d’Office Claws
On peut le faire avec des onglets SSH et tmux. Le problème est de se souvenir quelle machine, branche et terminal possède quelle partie. Office Claws sert de plan de contrôle : plusieurs agents Codex sur VPS, visibles depuis une seule application desktop.
Si vous venez d’OpenClaw, commencez par la comparaison OpenClaw vs Codex. Si vous savez déjà que vous voulez des agents Codex hébergés, la page des tarifs montre les options self-hosted et managed.
Checklist
- Existe-t-il un contrat écrit ?
- Chaque agent possède-t-il des fichiers différents ?
- Chaque prompt dit-il clairement ce qui est interdit ?
- Y a-t-il une commande de validation par branche ?
- L’ordre de merge est-il connu avant le départ ?
- Un humain accepte-t-il les changements de contrat ?
Les workflows Codex parallèles sont puissants parce qu’ils gardent les agents étroits. Ils ne deviennent pas des managers autonomes; ils arrêtent simplement de s’attendre pendant que vous gardez l’architecture.