La nuit où mon LLM a codé tout seul
Un soir de fin février 2026, j'ai donné à un LLM un document de vision et l'accès à ma propre base de connaissances vectorisée. Il a codé pendant des heures sans que je touche au clavier. Le système n'a pas tenu — mais le pattern qu'il a révélé tourne, lui, depuis tous les jours.
Il y a eu un soir, fin février 2026, où j'ai allumé un script et où je suis allé me coucher pendant que mon LLM continuait à coder. Ce soir-là, j'ai compris que ce que je voulais construire — l'écosystème dont parle ce site, le gestionnaire de projet qui orchestrerait mes briques, la couche qui me permettrait un jour de finir mon robot — n'était plus une utopie. La méthode existait. Elle avait un nom : la boucle de rétroaction MCP.
Cet article raconte cette soirée — comment j'y suis arrivé, ce qui s'y est passé, et pourquoi tout l'écosystème home-ai a été codé selon ce pattern depuis. C'est probablement l'épisode le plus important pour comprendre comment on construit, aujourd'hui, à mon échelle, quand on est seul.
Le problème qu'aucun prompt ne résolvait
Depuis quelques mois je codais picar avec un LLM en co-pilote. La méthode produisait beaucoup, je l'ai racontée ailleurs — D'un robot à un écosystème. Mais elle butait sur un plafond invisible : à mesure que le projet grossissait, l'assistant perdait pied. Il me proposait des fonctions qui existaient déjà sous un autre nom. Il oubliait un module qu'on avait écrit deux heures plus tôt. Il réinventait des conventions à chaque session.
J'ai d'abord essayé ce que tout le monde essaie : précisions plus longues dans les prompts, contexte plus dense, références citées explicitement. Ça aidait. Mais c'était fragile. Au moindre changement de session, tout repartait à zéro. Ma fenêtre de contexte se remplissait de rappels au lieu de demandes. Le ratio « phrase utile / phrase de rappel » descendait. J'avais l'impression d'enseigner mon propre code à mon assistant pour la dixième fois.
Le problème, je le voyais clairement, n'était pas l'assistant — c'était l'absence d'une mémoire partagée entre lui et moi. Tout ce que je connaissais de mon projet vivait dans ma tête ou dans mes fichiers, et il n'avait accès qu'à ce que je lui balançais explicitement dans le prompt. La conséquence était logique : ce qu'il ne voyait pas, il l'inventait.
Découverte des MCP — le détour
C'est en arrière-plan, sans rapport direct avec picar, que j'ai mis le nez sur le sujet des serveurs MCP. Model Context Protocol — un protocole standard publié par Anthropic, qui permet à un agent LLM d'appeler des outils et de lire des ressources via un mécanisme uniforme. Pas un format propriétaire ; un standard ouvert, implémentable par n'importe qui.
J'ai voulu comprendre. Plutôt que de chercher à utiliser un serveur MCP existant, j'ai décidé d'en construire un, simple. Quelques heures plus tard, j'avais un MCP minimal qui exposait deux ou trois outils stupides — get_current_time, echo, ce genre de truc — et un client qui les appelait. Le but n'était pas de produire de la valeur. Le but était de saisir le flow : comment le LLM voit les tools, comment il décide de les appeler, comment la réponse revient dans la conversation.
C'est en jouant avec ça que j'ai mesuré l'intérêt réel du protocole. Un MCP, c'est un point d'entrée propre pour brancher n'importe quoi à un agent : du code en direct, une API métier, une base de données. Le LLM ne sait pas ce qu'il y a derrière. Il appelle des fonctions, lit des ressources, et toute l'orchestration vit dans le serveur.
Mon premier MCP utile — la révélation des bases vectorielles
Vite, j'ai voulu brancher quelque chose de vraiment intéressant. J'ai choisi : ma propre base de connaissances. Notes éparses, décisions techniques, documents de vision, fragments de doc — tout ce que j'avais empilé dans des fichiers markdown depuis des années.
Pour que le LLM puisse y chercher quelque chose, il fallait que cette base soit interrogeable. J'ai creusé du côté des bases vectorielles, dont j'avais entendu parler mais que je n'avais jamais touchées. La promesse : indexer du texte en vecteurs d'embeddings et chercher par similarité sémantique plutôt que par mots-clés. Quand tu poses la question « comment je gère mes secrets ? », la base te répond en remontant les chunks qui parlent de la même chose, même s'ils ne contiennent aucun de ces mots exacts.
La vulgarisation qui m'a vraiment fait cliquer sur ce qui se passe : imagine un espace multidimensionnel — un espace où chaque mot est un point. Dans cet espace, la distance entre deux points est la distance sémantique — la distance de sens. Un clavier et un écran sont très proches ; un arbre est très loin. Quand j'interroge avec le mot clavier, la base ne cherche pas le mot — elle cherche la zone de l'espace où ce mot vit, et elle me remonte tout ce qui se trouve sémantiquement autour. Même si mes documents ne parlent jamais de clavier explicitement, s'ils parlent de touche, de frappe ou de saisie, ils sont dans le voisinage — et ils remontent.
J'ai installé Postgres avec l'extension pgvector, un embedder local — nomic-embed-text via Ollama — et un petit script d'ingestion qui indexait mes fichiers markdown. Ma première vraie requête de recherche m'est restée. J'avais posé une question vague, formulée avec un vocabulaire absent de mes documents. Trois chunks sont remontés, tous pertinents — l'un d'eux parlait du sujet sous un angle que mon prompt ne suggérait pas, mais que le sens commun reconnaissait immédiatement.
C'est là que j'ai compris ce que veut vraiment dire recherche sémantique. Pas un mécanisme d'index inversé enrichi de synonymes — une représentation continue où la proximité de sens est un calcul direct. Mes documents devenaient cherchables comme un humain les chercherait. Et ce moteur, je pouvais l'exposer via MCP à un agent.
Le 31 janvier 2026 — deux semaines après le premier commit picar — je créais deux dépôts : knowledge pour les documents, knowledge-api pour le service qui les expose, avec son MCP Server embarqué. Le décor était posé.
La boucle de rétroaction
Avec le MCP branché sur ma knowledge, j'avais ce qui m'avait manqué jusqu'ici : un endroit où l'assistant pouvait aller chercher ce qu'il ne savait pas, sans que j'aie à le lui rappeler dans le prompt. Mais ce qui rend ce pattern vraiment puissant, c'est qu'il fonctionne dans les deux sens.
J'ai construit deux prompts symétriques. Le premier, code-vers-knowledge, lisait mon code source et générait des fragments markdown les décrivant : interfaces, décisions implicites, conventions. Ces fragments allaient nourrir la knowledge. Le second, knowledge-vers-code, partait d'une demande fonctionnelle et utilisait la knowledge comme source de vérité pour générer du code conforme. Entre les deux, la base vectorielle servait de mémoire partagée.
Concrètement, ça donnait quelque chose comme : j'écris un nouveau service, je le commit. Un workflow extrait sa documentation et l'indexe. La prochaine fois que je demande au LLM d'écrire un client pour ce service, il interroge la knowledge, trouve la doc fraîche, et produit du code qui respecte la vraie interface — pas une approximation inventée. Et l'inverse marche aussi : je décris un comportement attendu, l'agent génère le code, je le commit, sa propre génération devient à son tour de la knowledge consultable.
C'est la rétroaction. Le code nourrit la knowledge, la knowledge oriente le code, et chaque tour serre un peu plus la cohérence du système.
La nuit
C'est dans ce contexte que j'ai écrit, fin février 2026, ce que j'appellerais aujourd'hui mon premier document de vision opérable. Pas un README. Pas une spec. Un document dense, structuré, qui décrivait point par point le gestionnaire de projet dont je rêvais pour orchestrer toutes les briques que je commençais à empiler — celui qui deviendrait hub-projects. Sa vocation, ses entités, ses workflows. Les contraintes techniques. Les choix par défaut. Tout ce qu'un développeur humain aurait demandé pour s'y mettre.
J'ai injecté ce document dans la knowledge. Je l'ai donné à un LLM — un modèle qui paraîtrait vieux aujourd'hui, mais qui a fait le job ce soir-là — avec un seul ordre : « construis ce système ». Et j'ai laissé tourner.
Ce qui s'est passé pendant les heures qui ont suivi, je m'en souviendrai. L'agent a lu la vision, a interrogé la knowledge pour les conventions à appliquer, a posé sa première arborescence de fichiers, a généré ses migrations Postgres, a écrit ses endpoints FastAPI. À chaque étape, il consultait la knowledge — pour le format de logs, pour la convention de naming, pour les patterns de validation Pydantic. Il s'auto-référençait au fur et à mesure qu'il construisait : ses propres choix devenaient eux aussi de la knowledge, et nourrissaient ses choix suivants.
Au début, c'était stupéfiant. Le code qui sortait n'était pas du code de démo — c'était du code qui ressemblait à ce que j'aurais écrit, dans le style que j'utilisais, avec les bibliothèques que j'aimais. Pas parce que je l'avais demandé, mais parce que la knowledge le disait. J'ai laissé tourner deux heures, trois heures. Le projet prenait forme.
Les garde-fous
Puis ça a commencé à dériver. Subtilement d'abord : un endpoint pas tout à fait conforme à la spec, une décision de design un peu paresseuse, une dépendance ajoutée sans justification. Plus le projet grossissait, plus l'agent se nourrissait de ses propres approximations, et plus ces approximations devenaient la nouvelle base à partir de laquelle il décidait. La rétroaction qui avait servi à serrer la cohérence devenait, sans surveillance, une mécanique d'amplification des erreurs.
J'ai arrêté. Pas avec déception — avec une leçon. La boucle marche parce qu'elle s'appuie sur une knowledge propre. Si tu laisses l'agent y déverser ses propres approximations sans qu'un humain ne trie, tu obtiens au bout d'une nuit un système cohérent — avec lui-même, mais pas avec ce que tu voulais. La qualité de sortie du LLM est, dans ce pattern, exactement la qualité d'entrée que tu lui donnes. La knowledge n'est pas un dépôt — c'est un curateur.
Depuis cette nuit-là, le pattern MCP que j'utilise inclut systématiquement trois disciplines, qui font l'objet d'un article séparé sur le sujet — MCP-first — pourquoi mon agent IA ne devine plus rien. En deux mots : la knowledge est curée à la main avant d'être donnée à un agent ; les générations de l'agent passent par une revue humaine avant d'y entrer ; et les règles invariantes de l'écosystème vivent en haut de la knowledge, jamais dérivables, jamais réinterprétables.
L'œil humain n'est pas un détail d'optimisation. C'est ce qui transforme une mécanique d'amplification en mécanique de capitalisation.
Ce que ça a déclenché
J'ai éteint le script. Le système incohérent que l'agent avait produit cette nuit-là, je l'ai jeté. Mais la conviction était là, et elle a tenu : ce que je voulais construire était possible, à condition de le construire avec ces outils plutôt qu'à côté d'eux.
Trois semaines plus tard, le 21 mars 2026, j'ouvrais le dépôt MCP-Unified et je posais le premier commit de ce qui allait devenir la gateway MCP de tout l'écosystème. Puis, en moins de deux mois, vingt-trois dépôts sont apparus dans l'écosystème dans cette cascade que je raconte ailleurs — vingt-trois briques en cinquante-sept jours. Chacune a été codée selon le même pattern, avec un peu plus de rigueur à chaque tour : knowledge propre, MCP-Unified en façade, garde-fous humains, revues systématiques.
La nuit où mon LLM a codé tout seul ne devait pas se reproduire telle quelle. Elle ne s'est pas reproduite. Mais le pattern qu'elle a révélé, lui, continue à tourner — un peu différent, beaucoup plus discipliné, et chaque jour plus utile.
Voir aussi