Le dernier goulot d'étranglement - Brains, Bodies et Memory

Je construis des Products et je dirige des Engineering Teams depuis 25 ans. Durant tout ce temps, chaque grande vague - Cloud, Mobile, Microservices, DevOps - a changé ce qui était possible. Aucune n’a changé l’unité fondamentale avec laquelle on construit : l’équipe.

Ça a changé cette année. Je shippe désormais régulièrement des Production Features qui auraient nécessité une équipe de cinq il y a dix-huit mois. Pas en travaillant plus dur. En lançant des AI Agents pendant la nuit pendant que je dors, en reviewant leur output le matin avec mon café, et en shippant avant le déjeuner. J’ai décrit ce setup en détail dans The Overnight Agent Factory.

Ce n’est pas une prédiction. C’est mon mardi.

Trois choses ont convergé pour rendre ça possible : les Models sont devenus assez puissants (Brains), l’Agent Orchestration a mûri (Bodies), et des Knowledge Layers persistants sont apparus (Memory). Chacun est intéressant en soi. Ensemble, ils mettent fin à l’ère de la taille d’équipe.

Voici ce qui se passe - et ce que j’observe en pratique.

Brains : Les Models ont franchi une ligne

Soyons concrets sur ce que “meilleurs Models” signifie en 2026, parce que ce n’est pas la progression incrémentale habituelle des Benchmarks.

En mars 2026, Anthropic a confirmé Mythos après qu’un leak les y ait forcés. Les Benchmarks racontent une histoire claire :

93,9% sur SWE-bench Verified - le standard de l’industrie pour les tâches de Coding réelles. Ce n’est pas “écrire une fonction.” C’est “lire une Codebase inconnue, trouver le bug, écrire le fix et passer les tests.”
97,6% sur USAMO 2026 - la compétition de mathématiques la plus difficile des États-Unis.
100% de réussite sur Cybench - aucun autre Model n’y est jamais parvenu. Il a trouvé des milliers de Zero-Day Vulnerabilities dans les systèmes d’exploitation courants, dont un bug OpenBSD qui avait survécu 27 ans de review humaine. Il a enchaîné quatre Exploits séparés, s’est échappé de deux couches de Sandbox et a obtenu un accès système complet. De manière autonome.
En tête sur 17 des 18 Benchmarks mesurés par Anthropic. Des sauts à deux chiffres par rapport à la génération précédente.

Le secrétaire au Trésor américain et le président de la Fed ont convoqué les CEOs des plus grandes banques américaines. Pas pour la régulation. Pour la défense. Anthropic ne publiera pas Mythos - ils ont lancé Project Glasswing, 100 millions de dollars pour un usage purement défensif.

Ce que ça signifie en pratique : Je le ressens chaque jour. En 2024, l’AI était de l’Autocomplete - elle finissait mes phrases. Début 2025, elle pouvait écrire une fonction si je la décrivais soigneusement. Fin 2025, j’avais Claude Code qui construisait des Features entières sur plusieurs fichiers, avec une approche de Planning structurée. Maintenant, je dispatche du travail le soir et je me réveille avec des Pull Requests qui passent la CI. La courbe de “assistant utile” à “builder autonome” s’est déroulée en 18 mois.

Le plafond qu’on supposait - “l’AI peut écrire du Boilerplate mais pas du vrai Engineering” - a disparu. Et Mythos nous dit qu’on est encore loin du sommet.

Bodies : D’un seul Agent à des Agent Teams

Le problème avec un Brain brillant sans structure : du chaos coûteux.

J’ai vécu l’évolution moi-même. Ma progression sur 18 mois ressemblait à ça :

Single Session - un chat Claude Code, je regarde, je tape des Prompts. Utile mais lent.
Agents parallèles - plusieurs instances Claude Code, chacune sur sa propre branche Git, je navigue entre elles. 3-4x de débit. J’ai décrit les Patterns dans Agentic Development Patterns.
Headless Agents - des Agents sur un serveur distant, 24/7, contrôlés depuis mon téléphone. Le Setup complet est dans From Terminal to Factory. C’était le saut de “l’outil” à “l’effectif.”
Agent Teams structurés - des Agents avec des rôles définis (Architect, Implementer, Reviewer, Tester), suivant un Skills Framework qui encode la discipline Engineering. Le gstack Framework de Garry Tan va encore plus loin avec 23 rôles de spécialistes.

À chaque étape, j’étais le coordinateur. Je décidais quoi lancer quand. Je résolvais les conflits entre Agents. J’étais le manager.

Ça a changé début 2026.

Paperclip AI a atteint 42 000 GitHub Stars en quelques semaines après son lancement. Il ne se contente pas d’exécuter des Agents - il les manage. Les Agents reçoivent des Org Charts, des Budgets et de la Governance. Ils envoient des Heartbeat Updates. D’autres Agents s’y abonnent. Un Agent qui épuise son Budget est mis en pause, pas averti. Le système impose la discipline que je faisais manuellement.

Comme Kubernetes a abstrait l’orchestration de Containers. Paperclip abstrait l’orchestration d’Agents. Il se place au-dessus de Claude Code, Codex, Cursor - peu importe ce que tes Agents utilisent - et ajoute le Management Layer.

Mais voici la partie qui compte le plus. Le même schéma émerge avec les humains, pas seulement les machines.

Prenons Langfuse, la plateforme Open-Source de LLM Observability de Berlin. Quinze personnes. Acquise par ClickHouse début 2026. Leur Handbook public le dit clairement : “80% of work is shipped by a single person without needing to collaborate.” Deux Meetings par semaine - un Planning de 15 minutes et une Demo de 60 minutes. C’est tout. Les Engineers gèrent leurs Backlogs, décident eux-mêmes sur quoi travailler, et shippent sans demander la permission. Ils construisent délibérément ce qu’ils appellent des “strong ICs who are autonomous and highly leveraged with AI.”

Langfuse n’est pas un cas isolé. C’est le signal. Un nombre croissant de Startups utilise ce que j’appellerais le Micro-Founder Model : chaque personne qui rejoint obtient un domaine, un budget et construit sa partie du produit de manière autonome. Pas de Sprint Planning. Pas de Standups. Pas de Meetings de coordination. L’entreprise grandit en ajoutant des builders autonomes, pas en agrandissant les équipes.

Je crois depuis vingt ans que le meilleur produit naît quand une seule personne remplit tous les rôles - parle aux clients, conçoit la solution, écrit le code, shippe. Chaque fois qu’on divise une idée entre cinq spécialistes et qu’on recoud leur travail via des Meetings et des Tickets, l’intention originale se dilue. Pendant vingt ans, c’était une belle théorie avec une limite pratique dure : une personne ne pouvait pas tout faire seule.

Cette limite vient de disparaître.

Memory : Ce qui crée le Compound Effect

Brains et Bodies seuls créent un effectif amnésique. Chaque Session repart de zéro. Le travail se fait. Le savoir disparaît.

C’est la pièce que la plupart des gens manquent - et celle sur laquelle j’ai passé le plus de temps à construire à la main.

Le problème est réel. Un Agent construisait quelque chose de brillant, et l’Agent suivant sur la même Codebase n’avait aucun Context sur ce qui avait été construit ou pourquoi. J’étais le Memory. Chaque matin, je réexpliquais l’architecture, les décisions, les contraintes. Si ça ressemble à onboarder un nouveau Freelancer chaque jour - c’est exactement ce que c’était.

La solution a deux couches, et elles correspondent à quelque chose qu’Andrej Karpathy a dit en 2023 et qui s’est révélé prophétique : “The hottest new programming language is English.”

Language-Based Memory (La couche humaine)

La phrase de Karpathy ressemblait à une blague. C’était une prédiction.

Les meilleures Knowledge Structures pour l’ère de l’AI ne sont pas des Schemas de bases de données ou des JSON Configs. C’est du langage simple. Des Markdown Files. Du texte lisible que les humains peuvent ouvrir et comprendre, et que les Agents peuvent lire, analyser et utiliser.

Je construis ça quotidiennement :

Les fichiers CLAUDE.md donnent à chaque Agent le même Context projet - décisions d’architecture, Coding Standards, conventions du domaine. J’ai écrit un guide détaillé : The Perfect CLAUDE.md. Un bon CLAUDE.md est à la fois documentation pour les humains, Context pour les Agents et mémoire institutionnelle qui persiste entre les Sessions.
Les Obsidian Vaults servent de second cerveau. De simples fichiers .md dans des dossiers. Pas de Lock-in. Pas de format propriétaire. Chaque note de conversation client, chaque décision d’architecture, chaque Research Finding - tout en Markdown que n’importe quel Agent peut parser et n’importe quel humain peut lire.
Les Skill Files structurés encodent les processus Engineering sous forme d’instructions lisibles. Le Skills Framework transforme le Tribal Knowledge en quelque chose que les Agents peuvent suivre de manière consistante.

Un format, trois audiences : lecteur humain, AI Agent, Search Index. C’est le “Programming Language” que Karpathy avait prédit.

Technical Memory (La couche machine)

Le Language Layer couvre ce que les humains doivent comprendre. Le Technical Layer passe à l’échelle.

Les Vector Databases comme Pinecone stockent l’information par sens, pas seulement par mots-clés. Quand un Agent a besoin de “la discussion sur la Retry-Logik de la semaine dernière,” il cherche par similarité sémantique - pas par noms de fichiers exacts. Ça rend les grandes Knowledge Bases réellement utilisables.

GBrain, construit par le CEO de Y Combinator Garry Tan, va plus loin. C’est un Memory Layer complet que l’Agent lui-même installe et opère. E-mails, Meetings, notes, entrées de calendrier - tout intégré dans une base Postgres locale, interrogeable par sens et correspondance exacte. Trente-sept opérations, de l’import à l’Embedding en passant par le Query et le Sync. L’Agent ne termine pas une tâche et n’oublie pas. Il écrit ce qu’il a appris.

La différence pratique : sans Memory, les Agents sont des Freelancers qui repartent de zéro chaque jour. Avec Memory, ce sont des collègues qui construisent du savoir institutionnel. La qualité de leur travail s’améliore plus ils travaillent sur ton projet.

Je maintiens ça à la main depuis plus d’un an - ça marche, mais ça demande un effort constant. Des outils comme GBrain transforment ce travail manuel en infrastructure. Comme Docker a transformé “ça marche sur ma machine” en quelque chose de reproductible.

Mon Stack actuel

Voici à quoi ça ressemble en pratique. Ce n’est pas théorique - c’est avec ça que je shippe du logiciel :

Layer	Ce que j’utilise	Ce que ça fait
Brains	Claude Opus 4.6, Claude Sonnet 4	Les Models qui font le vrai travail d’Engineering
Orchestration	Claude Code + Headless Agents	Workstreams parallèles, Overnight Factories, Remote Dispatch
Planning	Ultraplan, Spec-Driven Workflow	Planning Multi-Agent dans le cloud avant l’Execution
Discipline	Skills Framework, gstack Roles	Processus Engineering en tant que code, rôles spécialisés
Memory	CLAUDE.md, Obsidian, Project Context	Savoir persistant entre les Sessions
Architecture	Three-Tier AI Pattern	Rules vs. ML vs. Agents - le bon outil pour chaque tâche
Local Fallback	Gemma 4 sur Apple Silicon	Local Model de classe Frontier, intégré dans Claude Code

Chaque élément renvoie à un Deep-Dive que j’ai écrit. Ce n’est pas un outil - c’est un système. Et ce système produit plus de logiciel fonctionnel que n’importe quelle équipe que j’ai dirigée en 25 ans.

Ce que le Leadership devient

Si une personne peut construire ce qui nécessitait une équipe - que signifie encore le Leadership ?

J’ai passé 25 ans à recruter des Engineers, dessiner des Org Charts, animer des Standups, débattre de Sprint Velocity. J’étais bon. Et je pense maintenant que l’essentiel de ça était la gestion d’un goulot d’étranglement qui est en train de disparaître.

Le Setup traditionnel - les Product Managers écrivent les Requirements, les Engineering Managers distribuent le travail, les Scrum Masters animent les Ceremonies, les Tech Leads reviewent le code - existe parce que le travail devait être réparti entre beaucoup de gens qui devaient rester alignés. Tout ce Management Layer, ce sont des coûts de coordination. Nécessaires quand dix personnes construisent une chose. Mais des coûts.

Dans un monde de Micro-Founders avec des Agent Teams, le Leadership garde ce qui compte vraiment et abandonne tout ce qui n’était que de la colle :

La Vision devient le job principal. Pas le type vague qui vit dans un Deck que personne ne lit. Une direction claire, mesurable, que chaque builder autonome peut suivre de manière indépendante. Si un Micro-Founder ne peut pas lire ta Vision et prendre la bonne décision Product sans te demander, ta Vision n’est pas assez bonne.

Le Trust remplace le Control. Tu arrêtes de reviewer chaque Pull Request. Tu définis à quoi ressemble le succès - en chiffres, pour les clients - et tu fais confiance à chaque builder et son Agent Team pour trouver le meilleur chemin. Le leader qui ne peut pas lâcher prise devient le goulot d’étranglement dans une entreprise conçue pour n’en avoir aucun.

Le Judgment devient le Skill le plus rare. Quand l’Execution est bon marché et rapide, choisir la bonne chose à construire sépare les gagnants des entreprises qui shippent juste beaucoup de code. Quel problème client résoudre. Quel marché attaquer. Quel pari prendre. Quel Feature tuer. Aucun Agent Framework ne prendra ces décisions pour toi.

C’est un retour à ce que le Leadership aurait toujours dû être. Avant qu’on l’enterre sous Jira, les Velocity Charts et les Status Meetings.

Ce qui change pour chaque entreprise Tech

Il ne s’agit pas de Headcount ou d’efficacité. Ça, c’est la lecture ennuyeuse.

La lecture passionnante : que devient possible quand on arrête de dépenser 80% de son énergie en coordination et qu’on commence à la consacrer au vrai problème client ?

Pense à ce que la plupart des Product Teams font toute la journée. Refinement Meetings. Écrire des Tickets. Estimer des Story Points. Attendre le Code Review. Standups. Négocier les priorités entre équipes. Quand ils arrivent enfin au vrai problème client, la solution a été diluée six fois par la chaîne de transmission qui l’a produite.

Imagine maintenant une personne avec une compréhension profonde du client, un Product Taste solide et une Agent Team - qui passe de l’insight au produit livré en jours, pas en trimestres. Pas de comité. Pas de dilution. Pas de “on mettra ça dans le prochain Sprint.”

C’est ce que cette convergence débloque. Pas du logiciel moins cher. Du meilleur logiciel. Des produits plus proches de ce dont les clients ont vraiment besoin, parce que le builder est la même personne qui a parlé au client. Des produits qui itèrent en heures plutôt qu’en Sprints. Des produits qui résolvent des problèmes plus difficiles, parce que le builder peut concentrer toute son énergie sur le problème plutôt que sur le processus autour.

Langfuse a construit une plateforme définissant son industrie avec quinze personnes - parce que leur structure a permis à chaque personne de se concentrer sur de vrais problèmes pour de vrais développeurs, sans que l’overhead ne dévore leur meilleure réflexion.

Les entreprises qui bougent en premier ne seront pas juste plus légères. Elles construiront des choses que leurs concurrents ne peuvent pas. L’écart entre ce qui est possible et ce que la plupart des organisations croient possible n’a jamais été aussi grand.

J’ai écrit des guides détaillés sur chaque partie de ce Stack. Si tu es un builder qui veut travailler comme ça, commence par Agentic Development Patterns et The Overnight Agent Factory. Si tu es un leader qui cherche à comprendre le shift, lis The Perfect CLAUDE.md - ça montre comment le Knowledge Transfer vers les Agents fonctionne en pratique.

Le goulot d’étranglement a toujours été les humains. Pas parce que les humains ne sont pas assez bons. Parce qu’une personne ne pouvait pas passer à l’échelle. Maintenant, elle le peut.