Le besoin

Travailler avec un LLM sur un sujet complexe — une opportunité produit, une veille stratégique, une discovery — dépasse rapidement la simple conversation. On accumule des sources, des décisions, des hypothèses, des contradictions. On revient le lendemain et le LLM a tout oublié. On copie-colle un fichier context.md de plus en plus gros, et à un moment, ça ne tient plus.

Le problème n'est pas que le LLM manque d'intelligence. C'est qu'il manque de mémoire structurée.

Comment j'en suis arrivé là

J'ai commencé comme tout le monde. Sur ChatGPT, en discutant. Le problème est apparu vite : à chaque échange, l'IA régénérait l'intégralité du document. Ou alors seulement une partie, mais sans accès à ce qu'il y avait avant. Je lui disais "montre-moi ce qu'on a fait plus haut", il régénérait tout, on perdait un temps fou, et le contenu finissait par diverger.

L'étape suivante a été de passer sur Claude Code — un outil qui permet de discuter avec un LLM tout en le laissant écrire directement dans un fichier Markdown. De temps en temps, je lui demandais de restructurer, je pouvais relire facilement, voire modifier moi-même dans le texte. C'était mieux. Mais un long fichier, ça ne suffisait toujours pas.

Et surtout, un problème de fond est apparu : le fichier est soit organisé pour l'humain, soit pour l'IA — jamais pour les deux. L'IA a besoin de repères pour reprendre une session là où elle s'est arrêtée, mémoriser des décisions, retrouver des sources. L'humain a besoin d'agréger l'information, la valider, la découper par thème ou par risque. Pas la même structure, pas les mêmes besoins.

Alors j'ai eu deux fichiers. Un pour l'IA, un pour l'humain. Ça a tenu un moment. Mais les deux ont fini par enfler, et il y avait un peu de tout dans chacun — des sources, des décisions, des hypothèses, des directives, mélangées dans le même flux.

J'ai commencé à découper. Un fichier de directives à part, qui ne parle pas d'une feature mais de la façon dont l'IA doit travailler. Puis un fichier de définitions. Puis d'autres. Et à un moment, le déclic : il ne fallait plus penser en fichiers, mais en système d'organisation. Et puisque les LLM sont inspirés du cerveau humain, peut-être que leur mémoire devait l'être aussi.

Voici, en version simplifiée, ce à quoi ressemble un contexte structuré :

<contexte>/
├── 00_mission/
│   ├── mission.md            ← pourquoi on est là
│   ├── directives.md         ← comment l'IA doit travailler
│   └── load_manifest.json    ← quoi charger, dans quel ordre
├── 01_active/
│   ├── active.md             ← état courant + plan
│   └── decisions.md          ← décisions prises et pourquoi
├── 02_checkpoints/           ← photos d'étape du contexte
├── 03_sources/
│   └── source_catalog.md     ← index des sources brutes
├── 04_notes/                 ← notes atomiques, reliées entre elles
├── 05_memory/
│   ├── journal/              ← ce qui s'est passé (épisodique)
│   └── synthesis.md          ← ce qu'on en retient (long terme)
└── 07_outputs/               ← livrables produits

Chaque dossier a un rôle précis. Rien n'est mélangé. Et surtout, on ne charge pas tout à chaque session — on charge le noyau (00_mission + 01_active), et le reste à la demande.

Ce qui compte vraiment, c'est le contexte

Mais avant de détailler pourquoi cette structure fonctionne, il faut poser une vérité plus large.

Ce qui fait qu'on excelle dans un domaine, c'est rarement la technique. C'est la profondeur du contexte qu'on a intériorisé.

Un bon commercial ne vend pas mieux parce qu'il maîtrise un script. Il vend mieux parce qu'il comprend les enjeux de son client — ses contraintes, ses peurs, son vocabulaire, ce qu'il ne dit pas. Un bon product manager ne fait pas un meilleur produit parce qu'il connaît les frameworks. Il le fait parce qu'il a compris le contexte de l'utilisateur — ses habitudes, ses frictions, ce qu'il contourne faute de mieux. Un sociologue ne comprend pas un mouvement social en lisant des statistiques. Il le comprend en saisissant le contexte vécu d'un groupe — ses codes, ses tensions internes, son rapport au monde.

Le contexte, c'est ce qui transforme de l'information en compréhension. Le reste — la décision, l'action, la production — en découle presque mécaniquement.

Et c'est exactement ce qui manque quand on travaille avec un LLM sur un sujet qui dure.

On ne peut pas tout mettre dans un seul fichier

Un cerveau humain ne fonctionne pas en chargeant tout ce qu'il sait à chaque instant. Il décompose. Il range. Il sépare ce qui est stable de ce qui est en cours. Il distingue une source brute d'une conviction personnelle. Il oublie les détails pour garder les patterns.

Un LLM, c'est pareil — mais en pire. Sa fenêtre de contexte est finie. Et plus on la remplit, plus son attention se dégrade sur ce qui est enfoui au milieu. Ce n'est pas une intuition : des chercheurs de Stanford l'ont démontré dans Lost in the Middle (Liu et al., 2024). Leur conclusion : un LLM retrouve bien mieux une information placée au début ou à la fin de son contexte qu'une information enfouie au milieu. Charger un fichier de 3000 lignes en espérant qu'il "comprenne tout", c'est comme lire un livre entier à voix haute à quelqu'un en lui demandant de retenir chaque phrase.

Ce qu'il faut, c'est charger seulement ce qui compte pour la tâche en cours. Et pour ça, il faut avoir découpé le savoir en morceaux navigables.

Charger le minimum, avec le maximum d'impact

Si le problème est clair — on ne peut pas tout charger — la question devient : que charger, et comment ?

La solution, c'est d'avoir un noyau compact qu'on charge systématiquement : la mission (pourquoi on est là), l'état courant (où on en est), le plan (où on va), les décisions prises, les contradictions ouvertes, et une fiche de reprise. Ce noyau tient en quelques fichiers courts. Il donne au LLM tout ce qu'il faut pour être opérationnel immédiatement, sans bruit.

Ensuite, selon le besoin de la session, on charge à la demande : une source précise qu'on veut analyser, une note qu'on veut enrichir, un checkpoint ancien qu'on veut comparer. Le reste — les dizaines de sources, les notes atomiques, les journaux de session — reste sur disque, accessible mais pas dans la fenêtre de contexte.

Pour que ça fonctionne, il faut un mécanisme qui dise à l'IA quoi charger, dans quel ordre, et avec quelle priorité. C'est le rôle d'un manifeste de chargement — une sorte de playlist de contexte. En premier : la mission et l'état courant (le noyau, toujours). Ensuite : les fichiers recommandés selon la phase en cours. Enfin : les fichiers disponibles mais chargés uniquement si la session le nécessite. C'est un plateau de chirurgien : les instruments essentiels sont déjà là, les autres sont à portée de main, mais on ne met pas tout sur la table.

C'est exactement ce que fait un expert humain. Il ne relit pas tout son dossier à chaque réunion. Il a intériorisé l'essentiel, et il va chercher un document précis quand il en a besoin. La différence, c'est qu'un LLM ne peut pas intérioriser — il n'a que ce qu'on lui donne. D'où l'importance de lui donner le bon sous-ensemble, pas tout.

Séparer les sources de ce qu'on produit

Une erreur fréquente : tout mélanger. La transcription d'une interview, l'hypothèse qu'on en tire, la décision qu'on prend, le livrable qu'on génère — tout dans le même fichier, dans le même flux.

Le problème, c'est la traçabilité. Quand tout est mélangé, on ne sait plus ce qui vient d'où. On ne sait plus si une affirmation est un fait sourcé ou une interprétation. On ne sait plus si une décision est encore valide ou si elle a été remplacée.

Séparer les sources (la matière brute) de la mémoire (ce qu'on en retient) et des productions (ce qu'on livre) n'est pas de la bureaucratie. C'est ce qui permet de garder un raisonnement fiable sur la durée.

Un contexte bien structuré produit plus que ce qu'on lui demande

Un problème classique en product management : on écrit beaucoup de documents, mais on ne retrouve jamais ce qu'on veut. Les notes de discovery dorment dans un Google Doc. Le brief produit est dans un Notion. Le compte-rendu de la réunion stratégique est quelque part dans Slack. L'information existe, mais elle est dispersée, non reliée, inutilisable.

Quand on structure un contexte autour d'un sujet — en séparant les sources, les notes, les décisions, la mémoire — quelque chose de puissant se produit. Ce contexte devient un socle réutilisable. À partir du même noyau de connaissances, on peut générer des livrables très différents : un brief release, des user stories, un communication pack (résumé, newsletter, post LinkedIn), une présentation pour le comité de direction.

On ne réécrit pas tout à chaque fois. On combine les bonnes briques du contexte pour répondre à un besoin précis. Le LLM n'invente rien — il assemble ce qui est déjà là, avec la bonne granularité et le bon angle. C'est la différence entre dicter un document à partir de zéro et demander à un assistant qui connaît déjà tout le dossier de le décliner sous un nouveau format.

C'est là que la structuration passe de "bonne pratique" à avantage réel : un contexte bien organisé n'est pas juste lisible, il est productif.

La fin du séquentiel

Le product management classique fonctionne en phases : on fait la discovery, puis on rédige les specs, puis on livre, puis on communique. Chaque étape attend la précédente. C'est propre sur un diagramme, mais c'est lent — et ça ne reflète pas la réalité du terrain.

Avec un système de contextes et un LLM, ce séquencement saute. La discovery ne s'arrête jamais vraiment. On dialogue en continu avec l'IA pour affiner, challenger, reformuler. Le contexte mûrit en permanence, et les livrables s'améliorent au fil de cette maturation — pas à la fin d'une phase, mais pendant. On peut sortir un premier brief dès la deuxième session, le faire évoluer à mesure que le contexte s'enrichit, et le livrable final n'est que la dernière itération d'un document qui a grandi avec la réflexion.

Mais l'effet le plus intéressant est ailleurs. Quand on travaille ainsi, on ouvre beaucoup de contextes. Des opportunités produit, des explorations, des veilles. Certains ne deviendront jamais une fonctionnalité. Ils ne "servent à rien" au sens classique du terme. Sauf que ces contextes ne sont pas isolés. Ils sont connexes. Une exploration sur les habitudes de maintenance industrielle nourrit une réflexion sur la gestion d'actifs. Une veille sur les modèles de pricing SaaS éclaire une opportunité sur la monétisation d'un module. Trois contextes qui semblaient indépendants convergent un jour vers un quatrième, qui n'aurait jamais été aussi riche sans eux.

C'est un changement de posture. On ne travaille plus en mode "une idée → un livrable". On cultive un réseau de contextes qui se fertilisent mutuellement. Et le jour où une décision produit doit être prise, le terreau est déjà là.

Des idées précises, reliées entre elles

Ce réseau de contextes fonctionne à grande échelle. Mais à l'intérieur de chaque contexte, le même principe s'applique à l'échelle des idées.

Ce qui fait l'intelligence — humaine ou artificielle — ce n'est pas d'accumuler du savoir. C'est de relier des idées précises entre elles. Et surtout des idées éloignées.

Un exemple. Dans le domaine de l'optimisation des emplois du temps — affecter des salles, des ressources, des créneaux sous contraintes multiples — une des approches les plus efficaces s'appelle le recuit simulé. En 1983, Kirkpatrick, Gelatt et Vecchi publient dans Science un article fondateur : ils montrent qu'un procédé de métallurgie — chauffer un métal puis le refroidir lentement pour que ses atomes trouvent une configuration stable — peut être transposé en algorithme d'optimisation combinatoire. Aucun rapport évident entre une fonderie et un planning de salles — et pourtant, ce transfert a changé tout un champ de recherche. Le lien existe, à condition de l'avoir capté.

C'est exactement la promesse du Zettelkasten — ce système de notes atomiques inventé par le sociologue allemand Niklas Luhmann, qui décrivait sa boîte à fiches comme un « partenaire de communication » (Luhmann, 1981). Chaque idée est isolée, précise, et reliée explicitement à d'autres. On ne stocke pas des blocs de texte. On stocke des unités de pensée, chacune avec ses liens. Et c'est dans ces liens que l'intelligence émerge : quand une note sur un phénomène physique croise une note sur un problème d'ordonnancement, quand une observation terrain rejoint une hypothèse théorique lue six mois plus tôt.

Appliqué à un système de contextes pour LLM, ça veut dire : ne pas écrire de longues synthèses monolithiques, mais des notes courtes, bien titrées, bien reliées. Chaque note est un point. Le réseau de liens entre ces points, c'est la carte. Et c'est cette carte qui permet — à un humain comme à un LLM — de faire des connexions qu'un fichier plat ne permettrait jamais.

C'est d'ailleurs l'intuition derrière A-MEM (Xu et al., 2025) — un système de mémoire pour agents LLM directement inspiré du Zettelkasten. Des notes structurées, indexées dynamiquement, reliées entre elles. Une architecture qui donne à l'IA les moyens de naviguer dans sa propre mémoire plutôt que de tout charger d'un bloc.

Mémoire courte, mémoire longue, et le droit de remonter le fil

Un cerveau humain n'a pas une seule mémoire. Il en a plusieurs, qui fonctionnent à des échelles de temps différentes. C'est ce qu'Atkinson et Shiffrin ont formalisé dès 1968 avec leur modèle multi-stores : un registre sensoriel, une mémoire à court terme, une mémoire à long terme. Endel Tulving a ensuite affiné la distinction en 1972 en séparant mémoire épisodique et mémoire sémantique. Concrètement : la mémoire de travail retient ce qui se passe maintenant — une conversation, un calcul en cours. La mémoire épisodique stocke les événements vécus — ce qu'on a fait mardi, ce que le client a dit en réunion. Et la mémoire à long terme consolide les vérités durables — les réflexes, les convictions, les patterns qu'on a intériorisés à force d'expérience. Un conducteur expérimenté ne réfléchit plus à comment passer une vitesse. Un product manager senior ne redécouvre pas à chaque projet que les utilisateurs mentent en interview. Ces savoirs sont devenus des automatismes.

Un système de contextes pour LLM reproduit cette architecture. Le journal de session, c'est la mémoire épisodique : ce qui s'est passé, quand, dans quel ordre. La synthèse consolidée, c'est la mémoire à long terme : les conclusions stables, les décisions validées, les patterns extraits de dizaines de sessions. Et les checkpoints sont les photos d'étape — l'état complet du contexte à un instant donné.

Mais il y a une différence fondamentale avec le cerveau humain. Un cerveau oublie — c'est même sa force, ça lui évite de saturer. Un système de fichiers, lui, n'oublie rien. Et c'est là que l'auditabilité entre en jeu. Dans un système bien structuré, chaque information raffinée — une conviction produit, une décision stratégique, une hypothèse validée — peut être retracée. De la synthèse, on remonte au checkpoint qui l'a produite. Du checkpoint, on remonte aux sessions. Des sessions, on remonte aux sources brutes — l'interview, l'article, la donnée.

C'est le même principe qu'en science : une conclusion n'a de valeur que si on peut remonter à la méthode et aux données qui l'ont produite. Quand un stakeholder demande "pourquoi cette décision ?", la réponse n'est pas "parce que l'IA l'a dit". C'est "voici le chemin : source → analyse → synthèse → décision". Tout est traçable, tout est vérifiable. La mémoire n'est pas une boîte noire — c'est une chaîne de preuves.

Ce que ça change concrètement

Avant, mon métier de product manager consistait pour une bonne part à produire des documents. Beaucoup de documentation. Certaines pièces faisaient appel à de l'expertise — cadrage stratégique, arbitrages d'architecture, priorisation. Mais beaucoup d'autres étaient de la production de contenu à partir d'information déjà existante : documentation support, articles de blog, newsletters, notes de release, communication interne. Du travail nécessaire, mais largement automatisable dès lors qu'on dispose d'un contexte solide.

Aujourd'hui, c'est en cours d'automatisation. Pas parce que l'IA est "magique", mais parce qu'un contexte fort, cohérent et complet permet de générer ces livrables de manière quasi autonome. La documentation support se déduit des décisions et des specs. La newsletter se construit à partir des notes de release et du contexte produit. Certains livrables sont automatisés à près de 100 %. D'autres — les user stories, par exemple — demandent encore une relecture humaine, mais le premier jet est déjà solide.

Le changement le plus profond n'est pas dans la production. C'est dans la matière première. Avant, on écrivait des documents pour faire des produits. On rédigeait des livrables pour pouvoir livrer du logiciel. C'était le livrable qui comptait — le document final, figé, validé.

Aujourd'hui, on écrit des contextes. On discute avec l'IA — souvent à voix haute, devant son écran — pour créer, enrichir, affiner du contexte. Le livrable n'est plus le point de départ du travail, c'est un sous-produit. Ce qui a de la valeur, c'est le contexte lui-même — et comme on l'a vu, le réseau de contextes connexes qui se fertilisent entre eux.

Vers quoi ça mène

Ce qui se dessine, c'est un changement de posture du product manager. On passe de quelqu'un qui fait beaucoup de choses seul — discovery, specs, communication, coordination — à quelqu'un qui manage une équipe d'IA. On discute, on explique du contexte, on challenge les résultats, on arbitre. Le quotidien ressemble moins à de la rédaction et plus à du management.

Et c'est un exercice exigeant. Expliquer un contexte à une IA qui n'y connaît rien, c'est se forcer à vérifier qu'on le comprend soi-même. Réexpliquer, reformuler, préciser — c'est un miroir impitoyable. Si le contexte est flou dans votre tête, le résultat sera flou. L'IA ne compense pas l'approximation, elle l'amplifie.

Naval Ravikant parle de specific knowledge — ce savoir qui ne peut pas s'enseigner, qui ne se réduit pas à un process. On peut enseigner la comptabilité. On peut même l'automatiser, la confier à une IA. Mais il existe des compétences qu'on ne sait pas formaliser. Pourquoi telle personne est excellente dans un domaine qu'on n'arrive pas à reproduire ? C'est du savoir spécifique — construit par l'expérience, l'intuition, le contexte vécu.

Je crois que c'est là que l'humain se recentre. L'IA prend en charge ce qui est formalisable : la production de contenu, l'agrégation, la mise en forme. L'humain garde ce qui ne l'est pas : l'opinion. Parce que faire du produit, c'est croiser des données quantitatives et qualitatives, c'est recouper des signaux faibles — mais à la fin, c'est avoir une conviction. Et une conviction, ça ne se délègue pas.

Avoir une opinion, c'est même parfois prendre des risques démesurés. Dans une startup, certains choisissent d'avoir 1 ou 2 % de chances de devenir une licorne — et 99 % de chances de mourir. Quelle IA prendrait cette décision ? Prendre des risques, tenir des positions tranchées, parier sur une vision que les données ne valident pas encore — une IA ne sait pas faire ça. Pas aujourd'hui, en tout cas. Et c'est précisément ce qui donne à un éditeur de logiciel sa culture, sa couleur, son ADN. Ce qui fait qu'un produit n'est pas interchangeable avec un autre, même quand les features se ressemblent. Ce n'est pas l'IA qui crée cette différence — c'est l'humain derrière.

Ce système de contextes n'est pas une fin en soi. C'est un outil pour que l'humain puisse se concentrer sur ce qu'il fait de mieux — penser, décider, avoir un point de vue — en déléguant le reste à une IA qui a enfin les moyens de se souvenir.

Ce système gère l'amont — la réflexion, la structuration, la décision. Mais côté aval, une autre transformation est en cours.

Nous l'avons tous vécu : une documentation est produite au moment de la spécification, puis le développement avance, des arbitrages sont rendus, des ajustements se font en cours de route — et personne n'a le temps de revenir mettre à jour chaque spec, chaque changelog, chaque document de support. Le résultat est toujours le même : la documentation et le code finissent par diverger. Plus le produit vieillit, plus l'écart se creuse.

Aujourd'hui, l'IA permet d'inverser ce flux. Quand le code est suffisamment propre et documenté, on peut en faire la source à partir de laquelle tout le reste se reconstruit : remettre à jour une documentation de support après une livraison, générer un changelog plus fiable, ou reconstituer une spécification fonctionnelle à partir de l'état réel du produit plutôt qu'à partir d'un document ancien.

C'est ce qu'on peut appeler une approche code centric. Le code n'est plus seulement le livrable final — il devient l'élément central, la source de vérité autour de laquelle gravitent et se régénèrent les autres artefacts du produit. La même logique vaut pour le design : si on est capable de reconstruire un design system à partir du code réel et de le maintenir à jour, la maquette change de statut — elle ne reste plus une représentation figée, elle devient une base exploitable.

J'explore cette idée plus en détail dans cet article.