Il y a un mois, j’ai ouvert Claude pour la première fois avec une idée simple : faire un jeu vidéo. Le projet s’appelait Rekall Studio. J’avais une vision, pas de compétences en développement, et un abonnement à un LLM.
En quinze jours et soixante-huit sessions, je n’avais toujours pas de jeu vidéo. Mais j’avais autre chose.
En clair : un projet de jeu qui se transforme en laboratoire d’observation. Pas par stratégie — par paresse honnête. Quand l’outil est plus intéressant à comprendre que le produit qu’on essaie d’en tirer, le sujet bascule.
Ce que Rekall m’a appris
Rekall Studio n’était pas un échec. C’était un accident productif. En essayant de faire construire un jeu par un LLM, je me suis retrouvé à observer comment le LLM travaillait. Comment il dérivait. Comment il oubliait. Comment il produisait un résultat parfait à la troisième tentative puis un résultat catastrophique à la quatrième, avec le même prompt. Je passais plus de temps à comprendre l’outil qu’à construire le jeu.
À un moment, j’ai arrêté de me mentir. Ce qui m’intéressait, ce n’était pas le jeu. C’était le système.
La bifurcation
J’ai transformé Rekall en laboratoire. Pas un vrai labo — pas de budget, pas d’équipe, pas de publications. Un ingénieur télécom seul avec un abonnement Claude et une obsession pour comprendre comment faire travailler un LLM de manière fiable.
Le début était flou. Le lab était trop centré sur Rekall. Les expériences étaient trop spécifiques à un cas d’usage. Il a fallu du temps — une vingtaine de sessions sur les premières du lab — pour que le sujet se détache du projet et devienne autonome. Pour que je comprenne que ce qui m’intéressait n’était pas “comment faire un jeu avec un LLM” mais “comment orchestrer un système dont un des composants est probabiliste”.
Le mot que je ne comprenais pas
Architecture. J’ai mis du temps à saisir ce que ce mot recouvrait. Je l’utilisais sans vraiment comprendre qu’il désignait exactement ce que je faisais : agencer des composants qui ont des propriétés différentes pour qu’ils produisent un résultat fiable ensemble. Le LLM est un composant. Le terminal qui l’exécute est un composant. Les fichiers de contexte sont un composant. Et moi — l’humain qui décide, valide, et redirige — je suis un composant aussi.
C’est peut-être la chose la plus importante que j’ai comprise : je fais partie de l’architecture. Pas comme un utilisateur qui appuie sur un bouton. Comme un routeur. Un routeur à bande passante limitée qui décide ce qui passe, ce qui est rejeté, et ce qui est reformulé. Le système ne fonctionne pas sans ce routeur. Et le routeur ne fonctionne pas s’il essaie de tout traiter lui-même.
En clair : l’humain n’est pas extérieur au système — il en est un composant. Les autres composants (LLM, terminal, fichiers de contexte) ont été conçus pour s’articuler avec ses limites. Si on supprime le routeur, le réseau ne tombe pas en panne : il dérive sans qu’on s’en aperçoive.
La paresse comme moteur de conception
Les meilleures solutions sont venues de ma paresse.
Le transfert de session entre deux conversations ? C’était parce que je refusais de répéter le contexte à chaque ouverture. Ça m’a semblé évident dès les premières sessions : si je ferme une conversation et j’en ouvre une autre, il faut un document qui porte l’état. C’est un concept vieux comme l’informatique — la sérialisation d’état. Appliqué à un LLM, ça donne un fichier Markdown qui dit “voici où on en est, voici ce qui reste à faire”.
Le triptique — moi qui décide, Claude.ai qui formalise, Claude Code qui exécute — c’est né de la même paresse. Je ne voulais pas taper des prompts XML de 200 lignes avec une forte probabilité de me tromper et d’oublier des contraintes. Alors j’ai délégué la formalisation à Claude.ai et l’exécution à Claude Code. En quelques mots de ma part, le système produit un prompt structuré de 250 lignes, vérifié, avec des gates et des critères de validation. Ma bande passante limitée de routeur est devenue un avantage : moins je tape, plus le système compense.
Repousser les limites pour voir ce qui casse
Une fois le système en place, j’ai voulu voir jusqu’où il tenait. Quarante agents lancés en parallèle sur une seule tâche décomposée, juste pour savoir si ça cassait. Ça n’a pas cassé. Alors j’en ai lancé cinquante-deux. Le record est de quatre-vingt-deux agents sur une session. Ce n’est pas utile. C’est de l’exploration. Comme un gamin qui empile des cubes pour trouver le point de rupture.
Mais l’exploration produit des données. Et les données produisent de la connaissance. J’ai appris que le parallélisme massif fonctionne — quarante agents en parallèle sans dégradation visible — mais que la consolidation séquentielle qui suit est le vrai goulot, parfois quinze à vingt minutes pour digérer ce que les agents ont produit en deux. Que le contexte se dégrade après vingt échanges environ. Que les skills d’orchestration formatent mais n’améliorent pas la qualité intrinsèque. Que le LLM s’auto-évalue positivement et qu’il faut une vérification externe pour chaque résultat.
Ces résultats négatifs — les choses qui ne marchent pas, les limites structurelles qu’on ne peut pas contourner — sont les plus précieux. Personne ne les publie. Les papiers académiques montrent ce qui fonctionne. Moi je documente ce qui casse.
La formalisation tardive
Pendant longtemps, je n’ai pas eu de thèse. J’avais des observations, des décisions, des conventions, mais pas de vision unificatrice. C’est venu autour de la session soixante-neuf du lab — à la fin de la deuxième semaine. En prenant du recul, j’ai vu que tout ce que je construisais ressemblait à un système d’exploitation. Pas un OS classique. Un OS dont le processeur est probabiliste.
La gestion mémoire, l’ordonnancement des tâches, l’isolation des contextes, le dispatch par type cognitif — ce sont des problèmes d’OS traduits en langage humain. Parce que c’est ce que je sais faire. Je ne suis pas matheux. Je ne suis pas développeur. Mais je sais structurer ma pensée. Et il se trouve que structurer la pensée, c’est exactement le problème que pose un LLM en production.
Trente jours
Cent soixante-six sessions en trente jours. Soixante-huit pour essayer de faire un jeu vidéo. Quatre-vingt-dix-huit pour comprendre l’outil avec lequel j’essayais de le faire.
Plus de cinq cents observations formalisées avec des niveaux de preuve. Un système anti-dérive qui détecte quand les conventions se dégradent. Un pipeline éditorial qui transforme la recherche en vulgarisation publique. Et toujours pas de jeu vidéo.
Le lab n’est pas un produit. Il n’a pas vocation à en devenir un. C’est un espace d’exploration pour une personne qui pense en arborescence et qui a besoin d’un système de convergence pour que cette pensée produise quelque chose de tangible. Le harness du lab, c’est mon harness à moi.
Et si quelqu’un me demande ce que je fais, je réponds : à la base je voulais juste faire un jeu vidéo.