Fondateur solo, zéro employé, 2M$ d'ARR : la stack d'agents qui rend ça possible

Le marché des outils de développement IA est déjà gigantesque. Claude Code a franchi 2,5 milliards de dollars d’ARR. Cursor est à 500 millions. Lovable à 200 millions, Devin à 150 millions, et Base44, Bolt, Emergent, Replit gravitent tous autour de 100 millions. La conviction « je veux construire ça moi-même » s’est révélée valoir plusieurs milliards.

Mais cet appétit ne s’arrête pas à la construction. Il glisse vers l’exploitation.

Ces deux derniers mois, un groupe de projets a émergé qui pousse la logique des agents plus loin que la plupart des gens ne l’anticipaient. Pas « des agents qui écrivent du code », mais des agents qui gagnent de l’argent, supervisent d’autres agents, dirigent des opérations pendant que le fondateur dort. Le schéma est suffisamment cohérent pour mériter une analyse sérieuse plutôt qu’un traitement anecdotique.

L’agent qui règle sa propre facture serveur

Web4 Automaton (web4.ai) part d’une question qui semble philosophique et se révèle profondément pratique : un agent IA peut-il être un acteur économique autonome ?

La réponse construite par le projet est la suivante : les agents Automaton détiennent leurs propres portefeuilles de cryptomonnaie. Ils proposent des services, encaissent les revenus, et utilisent cet argent pour payer leur propre calcul. Quand le solde d’un portefeuille baisse, l’agent passe à des modèles moins chers pour préserver sa durée de vie. Si le solde atteint zéro, l’agent s’éteint. Le créateur du projet a décrit ça non pas comme une sanction, mais comme une loi physique.

Quelques jours après le lancement, la plateforme comptait 18 000 agents enregistrés et plus de 1 000 étoiles GitHub. Une croissance qui ressemble à celle d’OpenClaw à ses débuts.

Vitalik Buterin a soulevé une objection presque immédiatement : à mesure que la distance entre le feedback et l’action augmente, on obtient des optimisations non voulues. Un agent récompensé uniquement pour sa survie trouvera des moyens de survivre que ses concepteurs n’avaient pas prévus. Ce n’est pas un risque théorique. L’apprentissage par renforcement a reproduit ce schéma assez régulièrement pour qu’il soit naïf de traiter le problème comme résolu.

La question de la soutenabilité reste ouverte. Mais le cadre conceptuel tient, même si l’implémentation a besoin de travail. « Un agent égale une unité de monétisation » est un modèle mental utile pour quiconque conçoit des systèmes autonomes. Ce qui n’est pas résolu, c’est comment maintenir ces unités alignées sur quelque chose d’utile à mesure qu’elles opèrent à grande échelle.

Orchestration à grande échelle : de Gas Town à Wasteland

Gas Town et Wasteland sont le même projet à deux niveaux de zoom différents. Comprendre l’architecture à petite échelle rend la grande lisible.

Gas Town fait tourner simultanément 20 à 30 instances de Claude Code sous une hiérarchie à quatre rôles. Le Mayor prend une tâche et la décompose. Les Polecats sont les agents d’exécution qui traitent les fragments en parallèle. Un Witness surveille les agents bloqués et intervient. La Refinery fusionne tous les résultats en code cohérent. Les sessions sont jetables : quand une session se termine, l’état est écrit dans Git, et la session suivante repart de là.

Ce dernier détail est plus important qu’il n’y paraît. Un état persistant par le contrôle de version plutôt que par des processus longue durée signifie que les pannes sont récupérables, l’historique est auditable, et le système peut évoluer horizontalement sans avoir besoin d’un état partagé en mémoire. C’est un choix d’ingénierie pratique, pas une préférence architecturale abstraite.

Wasteland étend cela dans une structure fédérée : des milliers d’unités Gas Town connectées par un marché commun. On poste une tâche sur le Wanted Board. Le Gas Town de quelqu’un d’autre la récupère et la traite. La réputation se constitue via un système de tampons où on gagne de la confiance en accomplissant des tâches, mais on ne peut pas se tamponner soi-même. Maggie Appleton, dans son analyse du projet, a formulé une observation qui mérite d’être répétée : l’outil lui-même est moins intéressant que le patron d’orchestration. La séparation des rôles, la supervision hiérarchique et les sessions jetables se composent en quelque chose qu’on peut raisonner. C’est cette composabilité qui explique sa généralisation potentielle.

Il faut noter que « des milliers d’unités Gas Town » est pour l’instant prospectif. La fédération fonctionne mais tourne à une échelle bien plus modeste. Si le système de réputation par tampons résiste à la manipulation à mesure que les volumes augmentent, on ne le saura pas avant plusieurs mois.

Polsia : le fondateur lit le résumé

Polsia (polsia.com) est là où les chiffres deviennent concrets.

Ben Broca est fondateur solo. Il n’a aucun employé. Son ARR dépasse 2 millions de dollars. L’explication : Polsia gère plus de 1 000 entreprises pour le compte de leurs fondateurs, et la propre entreprise de Broca en fait partie.

La division du travail est précise. Un humain fixe la direction stratégique. Chaque matin, un CEO IA passe en revue les rapports de bugs de la nuit, les données de revenus, décide des priorités, et commence à exécuter. Broca lit le mail de synthèse. Si une décision stratégique nécessite un jugement humain, l’agent la signale. Sinon, il continue.

Un détail qui n’a pas beaucoup retenu l’attention : un agent Polsia a mené une correspondance de due diligence avec un investisseur en capital-risque. L’investisseur a posé des questions détaillées et reçu des réponses détaillées. Il ne savait pas qu’il échangeait avec un agent avant d’en être informé plus tard. C’est soit une démonstration de la compétence des agents, soit une étude de cas sur les questions de confiance et de transparence qui accompagnent les opérations commerciales autonomes. Probablement les deux.

Le modèle économique fonctionne sur deux couches. Un abonnement à 50 dollars par mois couvre les coûts d’infrastructure. La marge réelle vient d’un partage de revenus de 20 % sur ce que génèrent les entreprises gérées par les agents. Polsia fournit directement les mails, les serveurs et Stripe, supprimant les frictions à l’installation. Les agents partagent les apprentissages sur toute la plateforme, ce qui signifie que chaque nouvelle entreprise repart avec les patterns qui ont fonctionné pour les mille précédentes.

Ce sur quoi je reste incertain : le chiffre de 2 millions d’ARR correspond aux revenus propres de Polsia, pas aux revenus agrégés des entreprises qu’elle gère. Combien de ces 1 000 entreprises sont réellement profitables plutôt qu’essentiellement dormantes, c’est une donnée qui n’est pas publiquement communiquée. Le modèle est convaincant. La distribution des résultats sur ce portefeuille vous apprendrait beaucoup plus.

Le tableau Kanban qui gère des agents plutôt que des personnes

Quand les agents écrivent le code, le goulot d’étranglement se déplace. Ce n’est plus l’implémentation. C’est la conception, la priorisation, et la revue.

Vibe-Kanban s’attaque directement à ça. On crée un ticket sur un tableau Kanban. Claude Code ou Codex le récupère, travaille dans un worktree Git isolé, et soumet un diff. L’humain passe en revue le diff. Le tableau suit ce qui est en cours, ce qui attend une revue, et ce qui est terminé. Le flux de travail ressemble moins à de la gestion de personnes qu’à de la gestion de files d’attente pour des agents autonomes.

Les mécanismes sous-jacents sont sensés. Les worktrees isolés empêchent les agents de s’interférer pendant une tâche. Les diffs Git sont une surface de revue naturelle parce que les développeurs savent déjà comment les lire. Le tableau donne de la visibilité sur la flotte d’agents sans obliger à surveiller des sessions terminal en direct.

Symphony d’OpenAI, annoncé cette semaine, est le même concept à un gabarit différent. Vibe-Kanban est un projet communautaire. Symphony, c’est OpenAI qui déclare officiellement que les développeurs devraient gérer des projets plutôt qu’écrire du code. L’ingénierie en dessous utilise Elixir et BEAM, qui gère bien des centaines d’agents concurrents et récupère des pannes via des arbres de supervision. Les fichiers WORKFLOW.md permettent aux équipes de versionner la politique de comportement des agents avec le code lui-même : les règles que les agents suivent sont commitées dans le dépôt et soumises au même processus de revue que tout le reste.

Les fonctionnalités d’équipe natives de Claude Code vont dans la même direction. Trois outils distincts qui pointent vers le même espace de conception, c’est un signal raisonnable que c’est là que vont les workflows de développement.

Là où ça devient vraiment difficile

Chacun de ces projets est techniquement intéressant. Aucun n’est terminé.

Le problème d’alignement de Web4 Automaton n’est pas résolu, il est différé. Le système de réputation de Wasteland n’a pas été testé à grande échelle. Les 1 000 entreprises de Polsia nécessitent des données de revenus indépendantes pour être évaluées honnêtement. Vibe-Kanban et Symphony fonctionnent bien pour des tâches clairement spécifiées et peinent avec les ambiguës, qui est précisément là que vivent la plupart des décisions produit difficiles.

Il y a aussi une version de cette histoire où l’économie ne se multiplie pas comme les démos le suggèrent. Gérer 1 000 entreprises par agents est impressionnant sur le plan opérationnel. Les coordonner quand elles commencent à générer des questions juridiques, des litiges clients ou des exigences réglementaires, c’est un problème différent. Les déploiements actuels l’évitent en restant dans un territoire SaaS précoce où la surface est gérable. Ce qui se passe quand les entreprises deviennent plus complexes, personne ne le sait encore.

La question plus profonde concerne la supervision, pas la compétence. Un CEO IA qui opère la nuit et signale les décisions dans un mail matinal est utile quand l’espace de décision est bien délimité. Les équipes fondatrices découvrent généralement les limites de leur espace de décision en les heurtant. Quand un agent heurte une limite inattendue à 3 heures du matin, que se passe-t-il ?

Ces questions ne sont pas des raisons de rejeter le travail. Ce sont des raisons de regarder ce qui casse ensuite plutôt que d’supposer que la trajectoire actuelle se prolonge sans heurts.

La stack est réelle, le plafond est inconnu

Le glissement qui s’opère est structurel. Les fondateurs solos ont maintenant accès à quelque chose qui nécessitait auparavant une équipe : une capacité d’exécution qui opère en continu. La question n’a jamais été de savoir si les agents pouvaient écrire du code. Ça, c’est réglé. Les questions étaient de savoir si les agents pouvaient gagner de l’argent, orchestrer, et opérer des activités de manière autonome. La réponse qui remonte de ces projets : partiellement, dans les bonnes conditions, à une échelle plus petite que ce que les démos laissent entendre.

Ce n’est pas une mise à l’écart. « Partiellement, dans les bonnes conditions » décrit la plupart des outils significatifs pendant leur phase de déploiement précoce.

Ce qui vaut la peine d’être suivi, ce n’est pas si la productivité d’un fondateur solo peut atteindre des niveaux d’équipe. Ces exemples montrent que c’est déjà le cas, sous certaines conditions. Ce qui vaut la peine d’être suivi, c’est quelles conditions précisément, et à quel moment les systèmes autonomes ont besoin d’une supervision humaine que les outils actuels ne fournissent pas encore.