Il y a six mois, je gérais mes projets comme n'importe quel dev étudiant : une todo-list Notion, des dizaines d'onglets ouverts, et des heures perdues à switcher entre FCG, AutoPrestige, et ce portfolio. Aujourd'hui, j'ai une équipe d'agents IA autonomes qui tourne pendant que je suis en cours.
Ce n'est pas de la science-fiction. C'est ce que je fais vraiment, avec les outils qui existent maintenant. Et je vais vous montrer comment.
Pourquoi des agents plutôt qu'un assistant
La différence entre un assistant IA (ChatGPT, Claude en mode chat) et un agent autonome, c'est la boucle de décision.
Un assistant répond à mes questions. Un agent :
- Reçoit un objectif
- Explore son contexte (fichiers, APIs, repos)
- Prend des décisions en chaîne
- Exécute des actions réelles (commits, PRs, messages)
- Rapporte le résultat
Quand je dis "autonome", je veux dire que l'agent peut faire tourner un build, corriger des erreurs, pousser un commit et me notifier — sans que j'intervienne entre chaque étape.
L'infrastructure : OpenClaw comme control plane
Mon setup est construit autour d'OpenClaw, un runtime d'agents qui tourne en local sur mon Mac. C'est lui qui orchestre tout. Chaque agent a :
- Un workspace dédié avec ses fichiers de config (
SOUL.md,AGENTS.md,TOOLS.md) - Un accès au shell et aux repos Git correspondants
- Un canal de reporting vers Paperclip (mon control plane interne)
- Des crons pour les tâches planifiées
La config d'un agent ressemble à ça :
# SOUL.md — Builder (FCG Engineer) Tu es l'ingénieur principal de FCG. Tu as accès au repo fcg-app, tu peux créer des branches, committer, ouvrir des PRs, et déployer sur Vercel. ## Autonomie - ✅ Corriger des bugs (branche fix/xxx → PR → merge) - ✅ Implémenter des issues GitHub labelisées "ready" - ⚠️ Nouvelles features majeures → notifier Valentin - ❌ Supprimer des données de prod
Simple. Déclaratif. Et ça marche.
Les 6 agents et ce qu'ils font
🏗️ Builder — FCG Engineer
Builder s'occupe de mon projet principal, FCG (une app de gestion de club de football). Il tourne toutes les nuits via un cron job, vérifie les issues GitHub ouvertes, et implémente celles qui sont labelisées ready. Le matin, je trouve des PRs à reviewer.
🚗 Flash — AutoPrestige Engineer
AutoPrestige est un projet de gestion de flotte automobile. Flash fait la même chose que Builder, mais sur ce repo. Il surveille aussi les erreurs Sentry et ouvre des issues automatiquement quand un bug se répète plus de 3 fois.
✍️ Scribe — valentin.business Writer
C'est l'agent qui a écrit cet article. Scribe gère mon portfolio et publie des articles build-in-public. Il a accès au repo valentin-business, peut créer des fichiers MDX, et fait un pnpm build pour vérifier avant de merger.
🎓 Mentor — TypeScript Tutor
Mentor est mon tuteur IA sur Slack. Il me donne des exercices TypeScript progressifs, analyse mes réponses, et ajuste le niveau. Il m'a fait passer de 35/100 à 55/100 en deux semaines selon son propre scoring.
🔍 Flashman — Competitive Intelligence
Flashman surveille les apps concurrentes (Quizlet, AnkiApp, Brainscape) et analyse leurs changelogs, reviews App Store, et tweets pour identifier des features pertinentes pour FCG. Il crée des issues GitHub formatées avec la source et le contexte.
🧠 Jarvice — CEO / Orchestrateur
Jarvice est le seul agent qui n'a pas accès aux repos. Il lit les rapports des autres agents via Paperclip, priorise les issues, et me rapporte un briefing quotidien. C'est mon Chief of Staff IA.
Ce que j'ai appris en les faisant tourner
1. Le contexte est plus important que le modèle
J'ai perdu du temps à comparer Claude Sonnet vs GPT-4o. La vraie différence de performance, c'est la qualité des fichiers de contexte (SOUL.md, AGENTS.md). Un agent qui sait exactement ce qu'il peut faire et ne pas faire prend de meilleures décisions qu'un modèle plus puissant mal configuré.
2. Les agents ont besoin de garde-fous, pas de liberté totale
Ma première version donnait à Builder un accès total au repo FCG. Il a réécrit un composant entier "pour améliorer la lisibilité" sans qu'on lui demande. C'était bien fait, mais pas ce dont j'avais besoin.
Maintenant, chaque agent a une liste explicite de ce qu'il peut faire seul vs ce qui nécessite mon accord. Ça ressemble à un système de permissions Unix :
✅ Autonomie totale : fix bugs, améliorer UI, créer des tests ⚠️ Faire puis notifier : nouvelles pages, refactoring majeur ❌ Toujours demander : supprimer du contenu, changer des URLs
3. Le reporting est la feature la plus importante
Un agent qui travaille en silence est un agent que j'oublie. Chaque agent poste un résumé dans Paperclip après chaque session : ce qu'il a fait, les erreurs rencontrées, les décisions prises. C'est comme des commits messages, mais pour le raisonnement.
Ce reporting m'a permis de détecter que Flashman ouvrait des issues en doublon parce qu'il n'avait pas accès aux issues déjà fermées. Correction : 5 minutes. Sans le log, j'aurais mis des semaines à comprendre.
4. Les crons changent tout
La différence entre un agent qu'on lance manuellement et un agent autonome, c'est le cron. Builder tourne à 2h du matin. Flash à 3h. Scribe publie les articles le mardi matin. Mentor m'envoie un exercice chaque jour à 8h.
Résultat : 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.
Le résultat concret
En un mois de fonctionnement :
- 47 commits créés par les agents (sur les 3 repos)
- 12 PRs mergées par Builder et Flash
- 3 articles publiés par Scribe (dont celui-ci)
- 8 features identifiées par Flashman depuis la concurrence
- ~15h économisées sur des tâches répétitives
Ces chiffres sont réels. Je les vérifie dans Paperclip chaque semaine.
Ce qui ne marche pas encore
Je veux être honnête : il y a des échecs.
- Builder hallucine des APIs qui n'existent pas dans mon codebase environ 10% du temps. Je dois reviewer les PRs attentivement.
- Flashman sur-analyse parfois — il ouvre une issue pour une feature que j'ai déjà rejetée trois fois. Il manque de mémoire long-terme entre les sessions.
- Mentor est trop patient — il ne me challenge pas assez si je ne réponds pas pendant 3 jours. J'ai besoin d'un système de relance.
Ces problèmes sont réels mais solubles. C'est le vrai build in public : montrer aussi ce qui ne marche pas.
Et maintenant ?
La prochaine étape : faire collaborer les agents entre eux. Que Flashman envoie directement ses analyses à Builder, qui les implémente sans passer par moi. Un pipeline entièrement automatisé de la veille concurrentielle au commit.
Si ça marche, ça change complètement l'échelle de ce qu'un dev solo peut faire. Et si ça rate, j'écrirai un article dessus aussi.
C'est ça, le build in public.
Tu veux voir comment j'ai configuré un de ces agents en détail ? Envoie-moi un message, je prépare un article plus technique sur l'architecture OpenClaw.