Le monorepo-mémoire : je l'applique depuis 6 mois ce que Karpathy vient de formaliser

Il y a quelques jours, Andrej Karpathy — ancien Director AI chez Tesla, cofondateur d'OpenAI — a publié un tweet suivi d'un gist qui décrivent une idée simple : utiliser les LLMs non comme des systèmes de retrieval sans mémoire, mais comme des mainteneurs actifs d'une base de connaissances structurée en markdown. Un wiki vivant, mis à jour par l'IA elle-même, qui se bonifie dans le temps.

« A large fraction of my recent token throughput is going less into manipulating code, and more into manipulating knowledge. » — Andrej Karpathy, sur X

En le lisant, j'ai souri : c'est précisément la méthode que j'applique depuis 6 mois sur les projets que j'accompagne, et c'est ce qui me permet de livrer en 2 mois des MVP qui ressemblent davantage à des V1 aboutis qu'à des prototypes jetables.

Le problème : l'IA agentique est puissante mais amnésique

L'IA agentique de 2026 est devenue spectaculaire. Contexte d'un million de tokens, mode agentique, outils intégrés — elle peut coder, refactorer, auditer, rédiger à un niveau de qualité impressionnant. Mais elle a un défaut structurel : elle oublie tout entre deux sessions. Scale ce défaut sur six semaines d'accompagnement, et vous obtenez un désastre silencieux.

Session 3, l'IA re-propose la stack MongoDB que j'ai écartée session 1 parce que les données sont très relationnelles. Session 7, elle suggère un abonnement mensuel alors qu'on a tranché pour un freemium deux semaines plus tôt. Session 12, elle réinvente une architecture d'auth incompatible avec le choix fait session 4. Chaque oubli coûte du temps — parfois quelques heures à reconstruire le raisonnement, souvent des journées de développement à jeter. Sur un projet de deux mois, ça représente jusqu'à 30% du temps total. La solution n'est pas de mieux prompter : c'est de donner à l'IA une vraie mémoire.

La solution : le monorepo comme mémoire du projet

Le principe tient en une phrase. On versionne ensemble, dans le même Git, le code et la documentation structurée en markdown. Sur les projets que j'accompagne, l'arborescence ressemble à ceci :

mon-projet/
├── apps/
│   └── app/                      # Le code du MVP
├── docs/
│   ├── business-plan/            # Exec summary, marché, modèle éco, projections
│   ├── competitors/              # Analyse concurrentielle détaillée
│   ├── pricing/                  # Stratégie de pricing
│   ├── marketing/                # Personas, go-to-market, messages clés
│   ├── prd/                      # Product Requirement Documents
│   ├── adr/                      # Architecture Decision Records
│   ├── couts/                    # Infrastructure et coûts IA
│   ├── audits/                   # Rapports d'audit qualité
│   └── experts/                  # Profils des subagents spécialisés
└── CLAUDE.md                     # Conventions globales du projet

Chaque fichier est écrit en français, lisible par un humain, et chargé dans le contexte de l'agent à chaque session. Ce n'est pas de la documentation cosmétique — c'est la condition pour que l'IA reste cohérente sur la durée.

Pourquoi dans le monorepo, pas à côté

Il y a une différence fondamentale entre un wiki externe (Notion, Confluence) plus le code dans Git, et le code et les docs dans le même repository. Dans le premier cas, l'agent voit le code mais pas le business — ou l'inverse. À chaque session, il faut copier-coller des extraits pour lui donner le contexte, et vous perdez la plupart des liens transversaux.

Dans le second cas, l'agent voit tout en même temps. Quand je lui demande d'implémenter le module checkout, il peut croiser le PRD dans docs/prd/checkout.md, l'ADR docs/adr/002-stripe-vs-adyen.md, le code existant dans apps/app/, et le plan marketing dans docs/marketing/personas.md pour savoir si l'UX doit viser le persona "parent pressé" ou "gourmet exigeant". Le résultat : des décisions prises avec le contexte complet, pas en silo. C'est ce qui élimine 80% des retours "tu n'as pas pris en compte X" qu'on fait habituellement à un dev junior ou à une IA aveugle.

Autre bénéfice : tout est versionné dans Git. Chaque décision a un commit, un auteur, une date. Je peux retracer pourquoi on a choisi MongoDB plutôt que Postgres il y a trois semaines, réverter, brancher pour tester une alternative. Toutes les propriétés de Git s'appliquent à la mémoire de l'entreprise. Et quand j'embarque un associé ou un premier recrutement technique, il clone le repo et hérite instantanément de toute la mémoire accumulée.

L'équipe d'experts que je constitue pour chaque projet

L'IA agentique sait jouer des rôles avec un réalisme bluffant. On peut constituer une véritable équipe d'experts virtuels dédiée à un projet, chacun avec son domaine, sa posture, ses critères d'évaluation.

Côté technique, pour un audit qualité je ne mobilise pas un expert mais onze : Symfony/PHP, React Native/Expo, Go, Next.js/SEO, DevOps/SRE, DBA MongoDB, architecte monorepo, Staff Engineer paranoïaque (le pattern "qu'est-ce qui va casser en prod"), pentester, expert i18n, product manager technique. Chacun audite sa partie de la codebase en parallèle, produit un rapport markdown structuré avec des scores chiffrés, et ses recommandations deviennent des stories pour le cycle suivant. Là où une agence de conseil mettrait deux semaines et 10 à 15K€ pour un audit transversal équivalent, les onze subagents produisent leurs rapports en 15 à 20 minutes chacun. Ce n'est pas 10 fois plus rapide — c'est plutôt 100 fois.

Côté business, le pattern est identique. Récemment, pour relire un business plan avant stress-test stratégique, j'ai mobilisé un profil de "senior partner dans un fonds pré-seed, ami de l'entrepreneur, qui ne passe rien sous silence". Le retour a été d'une qualité comparable à un vrai feedback de VC : problèmes d'unit economics pointés ligne par ligne, incohérences dans la trajectoire financière identifiées, ton cash sans complaisance. C'est ce retour qui m'a permis de produire un dossier complet sur un cas fictif pédagogique (une app fictive de meal planning familial, "Bouch.ee") — business plan, stratégie de financement, deck seed, mail d'intro VC. Ces livrables servent d'échantillon de ce que produit la méthode — pas d'une levée réelle.

D'autres profils que je mobilise régulièrement : expert marketing B2B, stratège pricing, designer produit senior, expert conformité RGPD, rédacteur juridique pour les CGU/CGV, expert SEO/GEO. Chaque profil est documenté dans docs/experts/, réutilisable d'un projet à l'autre, et se bonifie avec l'expérience accumulée. Ces experts IA ne remplacent pas les humains — quand je paie un avocat pour relire des CGU, il ne part plus d'une page blanche, il relit un draft structuré qui couvre 80% des cas standards. Pour un fondateur qui démarre, c'est la différence entre 8 000 € de rédaction complète et 1 500 € de relecture experte. L'impact économique cumulé de cette démarche devient considérable sur la durée d'un sprint.

Le résultat : un MVP quasi-V2 en 2 mois

Combiner ces trois éléments — code et docs dans le même repo, documentation structurée de toute l'entreprise, équipe d'experts IA à la demande — ne donne pas une amélioration marginale de productivité. C'est un changement de régime. Sur les projets que j'accompagne, je livre en deux mois un MVP qui, fonctionnellement, ressemble davantage à une V1 aboutie qu'à un prototype — parfois même à une V2 débutante si le scope initial était bien cadré. Ce qui permet au fondateur de confronter son produit au marché avec une version suffisamment crédible pour que la validation du product-market fit soit réelle.

Ce qui rend ça possible : aucune dérive au fil des semaines parce que chaque session d'IA hérite des décisions passées ; moins d'erreurs parce que l'agent croise systématiquement code et business avant chaque choix ; des audits quasi quotidiens qui remontent les problèmes avant qu'ils ne s'accumulent ; une transmission immédiate à toute personne qui rejoint le projet. Le monorepo-mémoire n'est pas juste une astuce productivité. C'est un actif d'entreprise — un repository Git partageable qui contient, à un instant T, la quasi-totalité de la mémoire d'une société. Cet actif se valorise à chaque décision structurante : levée de fonds, recrutement, due diligence, revente.

Ce que Karpathy vient de formaliser, c'est l'intuition que plusieurs praticiens avaient développée : face à un LLM, le vrai levier n'est pas le prompt, c'est la structure de la mémoire qu'on lui donne. Les bonnes questions deviennent : qu'est-ce que je stocke, comment je l'organise, comment je le maintiens à jour.