Manifeste
J'ai arrêté de considérer les LLM comme des outils.
J'ai commencé à les organiser comme une équipe.
Le mois dernier, mes agents IA ont consommé l'équivalent d'environ 6 720 dollars d'usage API Claude.
Concrètement :
- plus de 28 000 appels
- 384 sessions actives
- plusieurs dizaines de milliards de tokens traités
Et pourtant, mon coût réel aujourd'hui reste limité à un abonnement d'environ 100 $/mois grâce à Claude Code.
Je ne dirige pas une équipe de 50 développeurs.
Je suis CTO et cofondateur avec Gaëtan Benezech de Hop Hop Immo, et depuis plusieurs mois, j'expérimente une autre façon de travailler : organiser des agents IA comme une véritable équipe.
Avec des rôles. Des responsabilités. Des garde-fous. Des mécanismes de coordination. Et surtout : une mémoire persistante.
Voici comment j'en suis arrivé là, ce que ça change concrètement dans mon quotidien, et pourquoi je ne pense pas revenir en arrière.
Le déclic
Comme beaucoup, j'ai commencé Claude Code en avril 2025 comme un simple pair programmer.
Une session terminal. Une question. Une réponse.
Très utile pour coder vite. Mais rapidement limité dès qu'on jongle entre plusieurs projets, plusieurs responsabilités et plusieurs contextes.
Entre HopHopImmo, mes missions, les sujets produit, l'infrastructure, le SEO, l'analytics, et même certains projets personnels, je passais mon temps à refaire du contexte.
À réexpliquer. À resituer. À reconnecter les morceaux.
La mémoire vivait surtout dans ma tête.
Et un jour, je me suis posé une question très simple :
Pourquoi je traite Claude comme un outil… alors qu'il se comporte beaucoup plus comme un collaborateur ?
C'est cette bascule mentale qui a tout changé.
La métaphore « équipe humaine »
À partir du moment où on considère un agent IA comme un collaborateur, beaucoup de choses deviennent évidentes.
Un agent a besoin :
- d'un rôle clair
- d'un périmètre précis
- de responsabilités identifiées
- d'un contexte accessible
- de conventions de communication
- et de garde-fous
Et surtout : il ne doit pas dépendre de vous pour chaque micro-décision.
Je me suis alors replongé dans beaucoup de références autour du management et de l'organisation : Drucker, David Marquet, GitLab, Amazon, Apple…
Et j'ai réalisé quelque chose d'assez fascinant :
👉 beaucoup de problèmes qu'on rencontre avec les systèmes multi-agents existent déjà depuis longtemps dans les organisations humaines.
Coordination. Responsabilités. Confiance. Communication. Escalade. Mémoire. Autonomie.
Les patterns existaient déjà. Il fallait simplement les adapter.
Mais la métaphore a aussi ses limites.
Un agent IA :
- ne fatigue pas
- ne se motive pas
- ne ressent pas de reconnaissance
- et peut halluciner
La confiance qu'on lui accorde n'est donc pas une confiance sociale.
C'est une confiance encadrée techniquement.
À quoi ressemble ma flotte aujourd'hui
Aujourd'hui, je pilote une flotte d'environ 95 agents actifs répartis sur plusieurs scopes.
On y retrouve :
- des coordinateurs
- des architectes backend/frontend
- des développeurs spécialisés
- des reviewers
- des agents ops
- des agents SEO / analytics
- des experts métier
- et plusieurs méta-agents chargés d'orchestrer l'ensemble
J'ai aussi des agents plus atypiques :
- gestion documentaire
- fiscalité LMNP
- veille
- organisation personnelle
- préparation golfique pour les championnats de France
Le tout tourne via plusieurs sessions parallèles orchestrées avec agent-deck, un gestionnaire open source basé sur tmux.
Sur les 30 derniers jours :
- ~95 agents actifs
- 384 sessions lancées
- rotation continue jour/nuit
Les patterns qui ont tout changé
1. « I intend to… »
Inspiré de David Marquet.
Mes agents ne demandent plus :
« Est-ce que je peux faire X ? »
Ils disent :
« Je vais faire X sauf opposition. »
Ça change complètement mon rôle.
Je ne valide plus chaque détail. Je supervise les écarts.
2. Outcome + Owner
Chaque tâche contient :
- un résultat attendu concret
- un responsable unique
Si l'objectif n'est pas clair, l'agent doit demander une clarification au lieu d'improviser.
Ça paraît trivial.
Mais ça réduit énormément les dérives.
3. Pull > Push
Je ne crée presque jamais un agent « par anticipation ».
Un agent naît lorsqu'un besoin réel apparaît :
- dette répétée
- nouveau scope
- friction observable
Le système grandit par pression du réel, pas par fantasme d'architecture.
4. Les garde-fous sont obligatoires
Sur les zones sensibles :
- juridique
- fiscalité
- suppression filesystem
- base de données
- mails externes
… aucune action irréversible ne part sans validation explicite.
Jamais.
Les agents peuvent préparer. Analyser. Proposer.
Mais certaines décisions restent humaines.
5. La mémoire n'est pas du contenu
Au début, chaque agent accumulait des notes.
Très mauvaise idée.
Explosion des coûts. Contexte illisible. Temps de chargement énorme.
Aujourd'hui, mes fichiers mémoire sont volontairement minuscules.
Ce sont des index vers des connaissances externes chargées uniquement à la demande.
La différence est énorme.
Ce que ça change vraiment
Le plus gros changement n'est pas la vitesse.
C'est la continuité.
Je peux arrêter une session. Dormir. Revenir. Changer de sujet. Lancer plusieurs scopes en parallèle.
Le système conserve :
- le contexte
- les décisions
- les conventions
- les historiques
Je ne repars plus de zéro en permanence.
Et honnêtement, ça change profondément la façon de travailler.
Et Hoppy dans tout ça ?
Chez Hop Hop Immo, nous travaillons sur Hoppy : un futur agent immobilier IA capable d'accompagner un acquéreur comme le ferait un conseiller humain.
Voix. Mémoire long terme. Agents spécialisés. Contexte persistant. Recherche conversationnelle.
Le projet est aujourd'hui en pause faute de temps et de moyens.
Mais toute cette expérimentation nourrit directement sa future architecture.
Et c'est probablement le point le plus important de tout cet article :
L'IA agentique n'est pas seulement un moyen d'aller plus vite.
C'est une manière d'apprendre, en construisant, les systèmes qui structureront les futurs produits IA.
Le vrai coût
L'IA agentique n'est pas « gratuite ».
Elle demande :
- de la discipline
- de la structuration
- des conventions
- de l'observabilité
- du recul organisationnel
Et surtout : beaucoup d'essais et d'erreurs.
Mais elle change déjà radicalement le scope qu'une petite équipe peut tenir.
Aujourd'hui, une grande partie de mon travail ne consiste plus à écrire du code.
Elle consiste à :
- organiser
- coordonner
- transmettre du contexte
- définir des garde-fous
- concevoir des systèmes capables d'évoluer sans moi
Et finalement, c'est peut-être déjà ça, le vrai métier de CTO.
Article original publié sur LinkedIn — voir version source.
Vous reconnaissez vos propres questions dans ce texte ? Discutons-en.
Prendre contact