OpenClaw + Codex/ClaudeCode Agent Swarm : L'équipe de développement d'une seule personne [Configuration complète]

Je n'utilise plus directement Codex ou Claude Code.

J'utilise OpenClaw comme couche d'orchestration. Mon orchestrateur, Zoé, lance les agents, rédige leurs prompts, choisit le bon modèle pour chaque tâche, surveille la progression et me notifie sur Telegram quand les PR sont prêtes à être fusionnées.

Faits marquants des 4 dernières semaines :

• 94 commits en une journée. Ma journée la plus productive – j'avais 3 appels clients et je n'ai pas ouvert mon éditeur une seule fois. La moyenne tourne autour de 50 commits par jour.

• 7 PR en 30 minutes. De l'idée à la production, c'est ultra-rapide car le codage et les validations sont largement automatisés.

• Commits → MRR : J'utilise ce système pour un vrai SaaS B2B que je construis – combiné à une vente pilotée par le fondateur pour livrer la plupart des demandes de fonctionnalités le jour même. La rapidité transforme les prospects en clients payants.

Mon historique Git ressemble à celui d'une équipe de développeurs que je viens d'embaucher. En réalité, c'est juste moi qui suis passé de la gestion de Claude Code à la gestion d'un agent OpenClaw qui lui-même gère une flotte d'autres agents Claude Code et Codex.

Taux de succès : le système réussit du premier coup presque toutes les tâches petites et moyennes, sans aucune intervention.

Coût : ~100 $/mois pour Claude et 90 $/mois pour Codex, mais vous pouvez commencer avec 20 $.

Voici pourquoi c'est plus efficace que d'utiliser directement Codex ou Claude Code :

>Codex et Claude Code ont très peu de contexte sur votre entreprise.

Ils voient le code. Ils ne voient pas la vision globale de votre activité.

OpenClaw change la donne. Il agit comme la couche d'orchestration entre vous et tous les agents – il contient tout le contexte de mon entreprise (données clients, notes de réunions, décisions passées, ce qui a fonctionné, ce qui a échoué) dans mon coffre Obsidian, et traduit le contexte historique en prompts précis pour chaque agent de codage. Les agents restent concentrés sur le code. L'orchestrateur reste au niveau stratégique élevé.

Voici comment fonctionne le système à un haut niveau :

La semaine dernière, Stripe a parlé de son système d'agents en arrière-plan appelé « Minions » – des agents de codage parallèles soutenus par une couche d'orchestration centralisée. J'ai accidentellement construit la même chose, mais cela tourne en local sur mon Mac mini.

Avant de vous expliquer comment configurer cela, vous devez savoir POURQUOI vous avez besoin d'un orchestrateur d'agents.

Pourquoi une seule IA ne peut pas faire les deux

Les fenêtres de contexte sont à somme nulle. Vous devez choisir ce qui entre dedans.

Remplissez-la de code → plus de place pour le contexte commercial. Remplissez-la d'historique client → plus de place pour la base de code. C'est pourquoi le système à deux niveaux fonctionne : chaque IA est chargée exactement avec ce dont elle a besoin.

OpenClaw et Codex ont des contextes radicalement différents :

La spécialisation passe par le contexte, pas par des modèles différents.

Le workflow complet en 8 étapes

Laissez-moi vous guider à travers un exemple réel de la semaine dernière.

Étape 1 : Demande client → Cadrage avec Zoé

J'ai eu un appel avec un client agence. Il voulait réutiliser les configurations déjà mises en place dans son équipe.

Après l'appel, j'ai discuté de la demande avec Zoé. Comme toutes mes notes de réunion sont automatiquement synchronisées dans mon coffre Obsidian, aucune explication n'a été nécessaire de ma part. Nous avons cadré la fonctionnalité ensemble – et nous avons abouti à un système de templates qui leur permet de sauvegarder et d'éditer leurs configurations existantes.

Ensuite, Zoé fait trois choses :

1. Recharge les crédits pour débloquer le client immédiatement – elle a un accès API administrateur
2. Récupère la configuration client depuis la base de prod – elle a un accès en lecture seule à la base de prod (mes agents Codex n'auront jamais cela) pour récupérer leur configuration existante, qui est incluse dans le prompt
3. Lance un agent Codex – avec un prompt détaillé contenant tout le contexte

Étape 2 : Lancement de l'agent

Chaque agent reçoit son propre worktree (branche isolée) et sa session tmux :

1# Créer le worktree + lancer l'agent
2git worktree add ../feat-custom-templates -b feat/custom-templates origin/main
3cd ../feat-custom-templates && pnpm install
4
5tmux new-session -d -s "codex-templates" \
6  -c "/Users/elvis/Documents/GitHub/medialyst-worktrees/feat-custom-templates" \
7  "$HOME/.codex-agent/run-agent.sh templates gpt-5.3-codex high"

L'agent tourne dans une session tmux avec une journalisation complète du terminal via un script.

Voici comment nous lançons les agents :

1# Codex
2codex --model gpt-5.3-codex \
3  -c "model_reasoning_effort=high" \
4  --dangerously-bypass-approvals-and-sandbox \
5  "Votre prompt ici"
6
7# Claude Code
8claude --model claude-opus-4.5 \
9  --dangerously-skip-permissions \
10  -p "Votre prompt ici"

Avant, j'utilisais codex exec ou claude -p, mais j'ai récemment basculé vers tmux :

tmux est bien meilleur car la redirection en cours de tâche est puissante. L'agent va dans la mauvaise direction ? Ne le tuez pas :

1# Mauvaise approche :
2tmux send-keys -t codex-templates "Stop. Concentre-toi d'abord sur la couche API, pas sur l'interface." Enter
3
4# Besoin de plus de contexte :
5tmux send-keys -t codex-templates "Le schéma est dans src/types/template.ts. Utilise-le." Enter

La tâche est suivie dans .clawdbot/active-tasks.json :

1{
2  "id": "feat-custom-templates",
3  "tmuxSession": "codex-templates",
4  "agent": "codex",
5  "description": "Templates d'email personnalisés pour client agence",
6  "repo": "medialyst",
7  "worktree": "feat-custom-templates",
8  "branch": "feat/custom-templates",
9  "startedAt": 1740268800000,
10  "status": "running",
11  "notifyOnComplete": true
12}

Une fois terminée, elle se met à jour avec le numéro de PR et les vérifications. (Plus de détails à l'étape 5)

1{
2  "status": "done",
3  "pr": 341,
4  "completedAt": 1740275400000,
5  "checks": {
6    "prCreated": true,
7    "ciPassed": true,
8    "claudeReviewPassed": true,
9    "geminiReviewPassed": true
10  },
11  "note": "Toutes les vérifications ont réussi. Prêt à fusionner."
12}

Étape 3 : Surveillance en boucle

Une tâche cron s'exécute toutes les 10 minutes pour superviser tous les agents. Cela fonctionne essentiellement comme une Ralph Loop améliorée, plus de détails plus tard.

Mais elle n'interroge pas les agents directement – ce serait coûteux. Au lieu de cela, elle exécute un script qui lit le registre JSON et vérifie :

1.clawdbot/check-agents.sh

Le script est 100 % déterministe et extrêmement économe en tokens :

• Vérifie si les sessions tmux sont actives
• Vérifie s'il y a des PR ouvertes sur les branches suivies
• Vérifie le statut CI via gh cli
• Relance automatiquement les agents ayant échoué (max 3 tentatives) si la CI échoue ou si des retours critiques de revue
• Alerte uniquement si quelque chose nécessite une attention humaine

Je ne regarde pas les terminaux. Le système me dit quand intervenir.

Étape 4 : L'agent crée la PR

L'agent commit, push et ouvre une PR avec \gh pr create --fill\. À ce stade, je ne suis PAS notifié – une PR seule n'est pas terminée.

Définition de « fait » (très important que votre agent le sache) :

• PR créée
• Branche synchronisée avec main (pas de conflit de fusion)
• CI réussie (lint, types, tests unitaires, E2E)
• Revue Codex réussie
• Revue Claude Code réussie
• Revue Gemini réussie
• Captures d'écran incluses (si modifications de l'interface)

Étape 5 : Revue de code automatisée

Chaque PR est revue par trois modèles d'IA. Ils détectent des choses différentes :

• Reviewer Codex – Exceptionnel sur les cas limites. Effectue la revue la plus approfondie. Détecte les erreurs logiques, les gestions d'erreur manquantes, les conditions de course. Le taux de faux positifs est très bas.
• Reviewer Gemini Code Assist – Gratuit et incroyablement utile. Détecte les problèmes de sécurité et d'évolutivité que les autres agents manquent. Et suggère des correctifs spécifiques. Une évidence à installer.
• Reviewer Claude Code – Plutôt inutile – a tendance à être trop prudent. Beaucoup de suggestions « envisage d'ajouter… » qui sont souvent de la sur-ingénierie. Je passe tout sauf si c'est marqué critique. Il trouve rarement des problèmes critiques par lui-même mais valide ce que les autres reviewers signalent.

Tous les trois postent des commentaires directement sur la PR.

Étape 6 : Tests automatisés

Notre pipeline CI exécute une série lourde de tests automatisés :

• Lint et vérifications TypeScript
• Tests unitaires
• Tests E2E
• Tests Playwright sur un environnement de prévisualisation (identique à la prod)

J'ai ajouté une nouvelle règle la semaine dernière : si la PR modifie une interface, elle doit inclure une capture d'écran dans la description. Sinon, la CI échoue. Cela réduit considérablement le temps de revue – je peux voir exactement ce qui a changé sans naviguer dans la prévisualisation.

Étape 7 : Revue humaine

Maintenant, je reçois la notification Telegram : « PR #341 prête pour la revue. »

À ce stade :

• CI réussie
• Trois reviewers IA ont approuvé le code
• Les captures d'écran montrent les modifications d'interface
• Tous les cas limites sont documentés dans les commentaires de revue

Ma revue prend 5 à 10 minutes. Je fusionne de nombreuses PR sans lire le code – la capture d'écran me montre tout ce dont j'ai besoin.

Étape 8 : Fusion

La PR est fusionnée. Une tâche cron quotidienne nettoie les worktrees orphelins et le fichier JSON du registre des tâches.

La Ralph Loop V2

C'est essentiellement la Ralph Loop, mais en mieux.

La Ralph Loop extrait le contexte de la mémoire, génère une sortie, évalue les résultats, sauvegarde les apprentissages. Mais la plupart des implémentations exécutent le même prompt à chaque cycle. Les apprentissages distillés améliorent les récupérations futures, mais le prompt lui-même reste statique.

Notre système est différent. Quand un agent échoue, Zoé ne se contente pas de le relancer avec le même prompt. Elle examine l'échec avec tout le contexte commercial et trouve comment le débloquer :

• L'agent a manqué de contexte ? « Concentre-toi uniquement sur ces trois fichiers. »
• L'agent est allé dans la mauvaise direction ? « Stop. Le client voulait X, pas Y. Voici ce qu'il a dit lors de la réunion. »
• L'agent a besoin de clarifications ? « Voici l'email du client et ce que fait son entreprise. »

Zoé surveille les agents jusqu'à leur achèvement. Elle a un contexte que les agents n'ont pas – l'historique client, les notes de réunion, ce que nous avons essayé avant, pourquoi cela a échoué. Elle utilise ce contexte pour rédiger de meilleurs prompts à chaque nouvel essai.

Mais elle n'attend pas non plus que je lui assigne des tâches. Elle trouve du travail de manière proactive :

• Matin : Scanne Sentry → trouve 4 nouvelles erreurs → lance 4 agents pour enquêter et corriger
• Après les réunions : Scanne les notes de réunion → identifie 3 demandes de fonctionnalités mentionnées par les clients → lance 3 agents Codex
• Soir : Scanne le git log → lance Claude Code pour mettre à jour le changelog et la documentation client

Je vais me promener après un appel client. Je reviens et je trouve sur Telegram : « 7 PR prêtes pour la revue. 3 fonctionnalités, 4 corrections de bugs. »

Quand les agents réussissent, le modèle est enregistré. « Cette structure de prompt fonctionne pour les fonctionnalités de facturation. » « Codex a besoin des définitions de types en amont. » « Inclure toujours les chemins des fichiers de test. »

Les signaux de récompense sont : CI réussie, les trois revues de code réussies, fusion humaine. Tout échec déclenche la boucle. Avec le temps, Zoé écrit de meilleurs prompts car elle se souvient de ce qui a été livré.

Choisir le bon agent

Tous les agents de codage ne se valent pas. Référence rapide :

Codex est mon cheval de bataille. Logique backend, bugs complexes, refontes multi-fichiers, tout ce qui nécessite un raisonnement à travers la base de code. Il est plus lent mais minutieux. Je l'utilise pour 90 % des tâches.

Claude Code est plus rapide et meilleur pour le travail frontend. Il a aussi moins de problèmes de permissions, donc il est excellent pour les opérations git. (Avant, je l'utilisais davantage pour le quotidien, mais Codex 5.3 est simplement meilleur et plus rapide maintenant)

Gemini a un superpouvoir différent – le sens du design. Pour de belles interfaces, je fais d'abord générer une spécification HTML/CSS par Gemini, puis je la confie à Claude Code pour l'implémenter dans notre système de composants. Gemini conçoit, Claude construit.

Zoé choisit le bon agent pour chaque tâche et achemine les sorties entre eux. Un bug dans le système de facturation va à Codex. Une correction de style de bouton va à Claude Code. Un nouveau design de tableau de bord commence avec Gemini.

Comment configurer cela

Copiez l'intégralité de cet article dans OpenClaw et dites-lui : « Implémente cette configuration d'essaim d'agents pour ma base de code. »

Il lira l'architecture, créera les scripts, mettra en place la structure de répertoires et configurera la surveillance cron. Fait en 10 minutes.

Pas de cours à vous vendre.

Le goulot d'étranglement que personne n'attend

Voici le plafond que je rencontre actuellement : la RAM.

Chaque agent a besoin de son propre worktree. Chaque worktree a besoin de son propre
ode_modules\. Chaque agent exécute des builds, des vérifications de types, des tests. Cinq agents en simultané signifient cinq compilateurs TypeScript parallèles, cinq exécuteurs de tests, cinq ensembles de dépendances chargés en mémoire.

Mon Mac Mini avec 16 Go atteint son maximum à 4-5 agents avant de commencer à swapper – et encore, il faut de la chance pour qu'ils n'essaient pas tous de builder en même temps.

J'ai donc acheté un Mac Studio M4 max avec 128 Go de RAM (3 500 $) pour alimenter ce système. Il arrive fin mars et je partagerai s'il en vaut la peine.

À venir : l'entreprise à un million de dollars tenue par une seule personne

Nous allons voir énormément d'entreprises à un million de dollars tenues par une seule personne à partir de 2026. L'effet de levier est massif pour ceux qui comprennent comment construire des agents qui s'améliorent eux-mêmes de manière récursive.

Voici à quoi cela ressemble : un orchestrateur IA comme une extension de vous-même (comme ce que Zoé est pour moi), déléguant le travail à des agents spécialisés qui gèrent différentes fonctions de l'entreprise. Ingénierie. Support client. Opérations. Marketing. Chaque agent concentré sur ce qu'il fait de mieux. Vous gardez une concentration laser et un contrôle total.

La prochaine génération d'entrepreneurs ne va pas embaucher une équipe de 10 pour faire ce qu'une personne avec le bon système peut faire. Ils construiront comme cela – rester petits, aller vite, livrer tous les jours.

Il y a tellement de contenu généré par IA de mauvaise qualité en ce moment. Tellement de battage autour des agents et des « centres de contrôle » sans rien construire d'utile. Des démos tape-à-l'œil sans bénéfices réels.

J'essaie de faire l'inverse : moins de battage, plus de documentation sur la construction d'une véritable entreprise. De vrais clients, de vrais revenus, de vrais commits qui arrivent en production, et de vraies pertes aussi.

Qu'est-ce que je construis ? Agentic PR – une entreprise d'une seule personne qui défie les géants traditionnels des relations publiques. Des agents qui aident les startups à obtenir une couverture médiatique sans un abonnement à 10 000 $ par mois.

Si vous voulez voir jusqu'où je vais pousser cela, suivez-moi.