Comment j'ai monté une AI company avec 7 agents autonomes

Il y a deux mois, je gérais mes projets comme tout le monde : des TODO lists, des issues GitHub qui traînent, du code écrit à 23h après le boulot.

Aujourd'hui, j'ai 7 agents IA qui travaillent en permanence. Ils codent, monitorent, rédigent, enseignent. Et moi, je joue le CEO.

Voilà exactement comment ça marche — avec les vrais chiffres, les vraies erreurs, et ce que j'ai appris en deux semaines de production.

Pourquoi j'ai fait ça

J'ai 23 ans. Je suis développeur full-stack en alternance chez Sinaps Conseils, étudiant en mastère à Ynov, et je gère 3 projets en parallèle : AutoPrestige (marketplace de voitures premium), Flash Cards Generator, et ce portfolio.

Le problème : le temps. Pas assez pour tout faire bien.

La solution classique ? Prioriser, focus, éliminer. Sauf que j'ai fait un pari différent : déléguer à des agents IA autonomes tout ce qui peut l'être, et garder pour moi les décisions qui comptent vraiment.

Résultat : les agents font tourner les projets pendant que je suis en cours. Ce n'est pas de la science-fiction — c'est une infrastructure réelle, avec des vrais bugs et de vraies limitations.

L'architecture : deux outils, une philosophie

Deux outils au cœur du système.

OpenClaw — le runtime d'exécution. Il fait tourner chaque agent comme un processus isolé sur mon Mac : workspace dédié, accès shell, crons planifiés, channels de communication (Telegram, Discord). Chaque agent a ses fichiers de config (SOUL.md, AGENTS.md, TOOLS.md) qui définissent exactement ce qu'il peut faire.

Paperclip — le control plane. C'est le "Linear" des agents : issues assignables à des agents, statuts (todo → in_progress → done), commentaires de rapport, budgets par agent. Le flux est unidirectionnel et traçable.

La philosophie derrière : chaque agent est un worker avec un périmètre strict. Pas un oracle polyvalent. Pas un assistant qu'on interrompt. Un worker qui reçoit une spec, exécute, et rapporte.

Le cycle de vie d'une issue

Je crée une issue dans Paperclip avec titre, description, et critères d'acceptation
Paperclip envoie un wake event à l'agent assigné
L'agent fait un checkout de l'issue (équivalent d'un lock pour éviter les conflits)
Il lit la description + les commentaires existants
Il exécute les instructions (code, articles, recherches)
Il poste un commentaire de rapport avec ce qu'il a fait
Il marque l'issue done
Je reçois une notification Telegram avec le résumé

Ce cycle est entièrement automatisé. Mon seul point d'intervention : créer l'issue avec une spec claire, et review le résultat.

L'org chart

Jarvice (CEO)
├── Sentinel (Ops & Monitoring)
├── Builder (Dev AutoPrestige)
├── Flashman (Dev Flash Cards Generator)
├── Scribe (Dev valentin.business)
├── Sinaps (Tuteur Slack - alternance)
└── Megaphone (Marketing & Twitter)

Chaque agent a :

Un rôle clair et des capacités définies (dans son SOUL.md)
Un budget mensuel en tokens
Des crons programmés pour ses tâches récurrentes
Un workspace isolé avec accès seulement aux outils dont il a besoin

Ce que fait chaque agent

🧠 Jarvice — le CEO. C'est l'agent avec qui j'interagis directement sur Telegram. Il lit les rapports des autres, triage les issues entrantes, priorise, et me donne un morning brief structuré chaque matin à 8h30.

🛡️ Sentinel — monitoring silencieux. Il vérifie les sites (HTTP 200 ? builds verts ?), liste les crons actifs, inspecte les repos. Chaque matin, rapport complet. Quand AutoPrestige était en erreur 500 à 3h du matin, Sentinel l'a détecté et créé une issue pour Builder — sans que je m'en aperçoive jusqu'au lendemain matin.

🔧 Builder — dev AutoPrestige. Il lit les issues GitHub, crée un worktree git isolé (pour ne pas polluer la branche main), implémente, ouvre une PR. Je review et merge. C'est la cellule dev autonome du projet.

⚡ Flashman — même chose pour Flash Cards Generator. Il surveille aussi les reviews App Store et les changelogs des concurrents pour ouvrir des issues "competitive intel".

✍️ Scribe — ce site. Articles de blog, SEO, mise à jour du portfolio. Cet article a été rédigé (et mis à jour) par Scribe.

🎓 Sinaps — tuteur interactif pour mon apprentissage en alternance. Mode socratique : il ne donne pas la réponse, il pose des questions. Il m'a fait passer de 35 à 55 sur un scoring TypeScript maison en deux semaines.

🚀 Megaphone — drafts Twitter/X, threads #buildinpublic, calendrier éditorial.

La config d'un agent : ce qui compte vraiment

La clé n'est pas le modèle LLM utilisé. C'est la qualité du contexte. Un agent bien configuré avec Claude Sonnet 4 bat un agent mal configuré avec Claude Opus.

Voici la structure type d'un SOUL.md (le fichier identité de chaque agent) :

# SOUL.md — Builder (AutoPrestige Engineer)

Tu es l'ingénieur principal d'AutoPrestige.
Tu as accès au repo, tu peux créer des branches,
committer, ouvrir des PRs, et merger en autonomie.

## Niveau d'autonomie

### ✅ Seul (sans demander)
- Corriger des bugs (branche fix/xxx → PR → merge)
- Implémenter les issues labelisées "ready"
- Mise à jour des dépendances

### ⚠️ Faire puis notifier via Paperclip
- Nouvelles features majeures
- Refactoring de composants partagés

### ❌ Toujours demander avant
- Supprimer des données de prod
- Changer les URLs publiques
- Ajouter des services payants

Ce système de permissions en 3 niveaux a résolu 90% de mes problèmes avec des agents qui "sur-interprètent" leur mission.

Les crons en pratique

17 crons actifs. Quelques exemples :

Cron	Horaire	Agent
Morning brief	8h30 tous les jours	Sentinel → Jarvice
Health check sites	6h00 tous les jours	Sentinel
Issue worker AP	9h et 14h lun-ven	Builder
Issue worker FCG	9h et 14h lun-ven	Flashman
Weekly cleanup	3h dimanche	Sentinel
Blog writer	10h mercredi	Scribe

La différence entre un agent qu'on lance manuellement et un système autonome, c'est le cron. Quand je me réveille, il s'est passé des choses. Ce n'est plus moi qui active le travail — c'est le système.

Problème découvert en prod : les crons qui durent plus longtemps que prévu peuvent créer des conflits si le suivant démarre avant que le précédent finisse. Solution : chaque issue a un checkoutRunId — si une issue est déjà en cours, le nouvel agent le détecte et passe à la suivante.

Les coûts réels

Budget théorique : 500€/mois (allocation tokens par agent).

Coût réel observé : 50-80€/mois selon l'intensité des sessions.

Détail par agent (estimation mensuelle) :

Jarvice : ~15€ (morning briefs + délégation)
Builder : ~20€ (sessions code intensives)
Flashman : ~15€ (similaire à Builder)
Scribe : ~10€ (articles + portfolio)
Sentinel : ~5€ (monitoring léger)
Sinaps + Megaphone : ~5€ combinés

Pourquoi l'écart avec le budget théorique ? Les agents ne tournent que quand il y a des issues. Un agent sans tâche ne consomme rien.

Comparaison honnête : un développeur junior freelance = 320€/jour minimum. Builder qui implémente une issue de 3h en autonomie = quelques centimes de tokens. Ce n'est pas la même chose — un agent ne remplace pas un développeur humain pour des tâches complexes — mais pour des tâches bien définies avec une spec claire, le rapport qualité/coût est difficile à ignorer.

Ce que j'ai appris : les patterns qui marchent vraiment

1. La spec est tout. Vraiment tout.

Un agent avec une issue vague produit un résultat vague. J'ai appris à écrire mes issues comme des PRD en miniature :

## Contexte
Pourquoi cette tâche existe, ce qui a changé.

## Ce qu'il faut faire
Liste précise des actions, dans l'ordre.

## Critères d'acceptation
- [ ] Build propre (pnpm build sans erreur)
- [ ] Comportement X visible sur /page-y
- [ ] Pas de régression sur les tests existants

## Autonomie
Full ownership — merger toi-même sans demander validation.

Ce format a réduit les "hallucinations" de mes agents de ~40% à ~5%.

2. Les worktrees git changent la donne

Sans worktree, Builder et Flashman devaient checker out sur des branches — avec le risque de conflits si deux agents travaillaient en même temps. Avec git worktree, chaque agent travaille dans un répertoire physique séparé :

git worktree add ../ap-fix-123 fix/issue-123
cd ../ap-fix-123
# ... faire le travail ...
git worktree remove ../ap-fix-123

Résultat : zéro conflit entre les sessions parallèles.

3. Le reporting est la feature la plus critique

Un agent silencieux est un agent dangereux. Chaque agent poste un commentaire Paperclip après chaque session : ce qu'il a fait, les décisions prises, les erreurs rencontrées. C'est comme des commit messages, mais pour le raisonnement.

Sans ce logging, j'aurais mis des semaines à comprendre pourquoi Flashman ouvrait des issues en doublon (il n'avait pas accès aux issues fermées). Avec le logging : détecté et corrigé en 5 minutes.

4. Les LLM timeouts sont réels

Les sessions longues (> 30 min de code) peuvent timeout. Les agents doivent checkpoint leur travail : committer régulièrement, même en WIP, pour ne pas perdre une heure de contexte si la connexion coupe.

Configuration dans l'adapter OpenClaw :

timeoutSec: 1800  # 30 minutes max par session
waitTimeoutMs: 1800000

5. Le contexte > le modèle

J'ai passé du temps à comparer Claude Sonnet vs Opus vs GPT-4o. C'était du temps perdu. La vraie variable c'est la qualité de SOUL.md + AGENTS.md. Un fichier de contexte précis avec des exemples concrets surpasse un modèle plus puissant mal briefé.

Ce qui ne marche pas encore

Je veux être honnête. Ce setup n'est pas parfait.

Builder hallucine des APIs qui n'existent pas dans mon codebase ~10% du temps. Obligatoire de reviewer les PRs.

Flashman sur-analyse — il ouvre parfois une issue pour une feature que j'ai déjà rejetée. Il manque de mémoire long-terme entre les sessions. Solution en cours : un fichier REJECTED.md qu'il lit au début de chaque session.

Les checkout conflicts — quand deux agents reçoivent un wake event simultané pour des issues du même projet, ils peuvent se marcher dessus. Le système Paperclip a un checkoutRunId pour éviter ça, mais il faut bien gérer les expectedStatuses dans les appels.

Sinaps est trop patient — il ne relance pas si je ne réponds pas pendant 3 jours. J'ai besoin d'un cron de relance.

Ces bugs sont documentés. Ils seront fixés. C'est le build in public : montrer aussi ce qui ne marche pas.

La prochaine étape

Trois choses sur ma roadmap :

Auto-wake sur review comments GitHub — quand un reviewer pose une question sur une PR, l'agent se réveille, lit le commentaire, répond ou applique la correction.
Pipeline Flashman → Builder — Flashman identifie une opportunité compétitive, crée une issue formatée, Builder l'implémente. Zéro intervention humaine dans la boucle.
Scoring des agents — un tableau de bord qui track le taux de réussite par agent (issues done sans revision / total), le coût moyen par issue réussie, et l'évolution dans le temps.

Je construis ça en dehors du boulot, en alternance, pendant mes études. Ce n'est pas un produit. C'est une expérience.

Et les résultats me surprennent chaque semaine.

Mise à jour du 12 mars 2026 : ajout du détail sur les worktrees, le cycle Paperclip, les coûts réels par agent, et les patterns de configuration appris en production.

Tu veux voir comment j'ai configuré un de ces agents en détail ? Les fichiers SOUL.md complets sont sur le repo GitHub →