Sous le capot de mon moteur de contexte : comment une IA se souvient d'une mission

J'ai déjà raconté pourquoi la mémoire d'un LLM ne tient pas dans un seul fichier, et pourquoi le contexte est l'actif que le PM doit construire. C'étaient des articles sur le pourquoi.

Celui-ci parle du comment. Je vais ouvrir le capot de mon moteur de contexte — le système qui vit dans un dossier 02-CONTEXT/ de mon vault — et suivre une mission réelle du début à la fin. À chaque étape, j'expliquerai la brique qui entre en jeu : la mission, le focus, les directives, le todo, la file offline, et les trois types de mémoire.

L'objectif : qu'un inconnu qui n'a jamais vu ce système comprenne comment il est organisé, et surtout pourquoi il est organisé comme ça. Parce que chaque dossier, chaque fichier, répond à un problème que j'ai rencontré en travaillant avec une IA sur des sujets qui durent des semaines.

Le principe de départ : le disque est la mémoire

Une chose à poser avant tout le reste. Dans ce système, le système de fichiers est la mémoire principale de l'IA. Pas la conversation.

Une conversation avec un LLM est volatile. On ferme l'onglet, tout est perdu. La fenêtre de contexte est finie, et plus on la remplit, plus l'attention se dégrade — c'est le phénomène du Lost in the Middle dont j'ai parlé ailleurs. Donc au lieu de tout garder dans la conversation, on écrit tout sur disque, dans des fichiers découpés par nature d'information. Et à chaque session, on ne recharge que le strict nécessaire.

Un contexte, c'est donc un dossier. Un dossier = une mission. Il n'y a aucune mémoire transversale implicite entre deux contextes : ce que l'IA sait sur le projet A ne fuit pas vers le projet B. Chaque mission a sa propre tête.

Voici, en simplifié, à quoi ressemble un contexte :

<contexte>/
├── 00_mission/     ← le cadre stable : pourquoi on est là, les règles
├── 01_active/      ← l'état vivant : où on en est, aujourd'hui
├── 02_checkpoints/ ← les photos d'étape
├── 03_sources/     ← la matière brute
├── 04_notes/       ← les idées extraites, reliées entre elles
├── 05_memory/      ← la mémoire consolidée
├── 06_index/       ← l'index machine, pour que l'IA se repère
└── 07_outputs/     ← les livrables

La logique de rangement est simple mais stricte : ce qui est stable (la mission, les règles) est séparé de ce qui bouge à chaque session (l'état courant), lui-même séparé de la matière brute (les sources), de ce qu'on en extrait (les notes) et de ce qu'on produit (les livrables). Rien n'est mélangé. On verra que cette séparation n'est pas cosmétique : c'est elle qui rend le raisonnement traçable dans le temps.

Pour rendre tout ça concret, je vais suivre une mission que j'ai vraiment menée (un exemple simple, pour faciliter la lecture) : PM016 — écrire des posts LinkedIn à partir de trois articles que j'ai publiés dans un magazine marketing. Une mission de production de contenu, courte, mais qui active la plupart des briques.

Ouvrir un contexte : ce que l'IA charge, et ce qu'elle laisse sur disque

Je démarre une session. La première chose que fait l'IA, ce n'est pas de tout lire. C'est de lire un fichier de configuration : le manifeste de chargement (load_manifest.json). Ce fichier lui dit quoi charger, et ce qu'il faut au contraire laisser sur disque.

Il contient trois listes :

• always_load — le noyau, chargé à chaque fois. La mission, le scope, les directives, les risques, l'état courant, le plan, le focus, le todo, les décisions, les contradictions, la fiche de reprise, la synthèse.
• load_on_demand — tout ce qui reste sur disque et n'est chargé que si la tâche l'exige : les dizaines de sources, les notes atomiques, les journaux de session.
• Des garde-fous : pas plus de 12 fichiers actifs, environ 1200 lignes maximum dans la fenêtre de contexte du LLM.

C'est un plateau de chirurgien. Les instruments essentiels sont déjà sortis ; les autres sont à portée de main, mais on ne couvre pas la table. Un expert humain ne relit pas tout son dossier avant chaque réunion — il a intériorisé l'essentiel et va chercher un document précis quand il en a besoin. 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.

En pratique, l'ouverture d'un contexte se fait par une commande — je tape /context_use pm016 — et l'IA exécute le manifeste : elle lit le noyau, elle lit le dernier checkpoint, et elle est opérationnelle. Elle sait où on en est sans que j'aie eu à lui réexpliquer quoi que ce soit.

La mission et le focus : le but n'est pas la même chose que l'attention

Zoom sur les deux dossiers de tête — le stable et le vivant :

00_mission/          ← le cadre stable
├── mission.md       le but (ne change pas)
├── scope.md         le périmètre
├── directives.md    comment l'IA doit travailler
├── risks.md         les menaces à surveiller
└── glossary.md      le vocabulaire de la mission

01_active/           ← l'état vivant (change à chaque session)
├── focus.md         l'attention du moment
├── current_state.md où on en est
├── current_plan.md  où on va
├── todo.md          les actions futures
├── decisions.md     ce qu'on a tranché
├── contradictions.md ce qui ne colle pas encore
├── resume_work.md   la fiche de reprise
└── offline.md       la boîte aux lettres

Voici la première subtilité, et probablement la plus importante à comprendre.

Il y a deux fichiers qui ressemblent à « ce sur quoi on travaille », mais qui n'ont rien à voir.

Le premier, c'est la mission (00_mission/mission.md). C'est le but. Il est stable. Pour PM016, la mission tient en une phrase : « écrire des posts LinkedIn basés sur les trois articles que j'ai publiés dans le magazine n°16 ». Cette phrase ne change pas pendant toute la vie du contexte. C'est le cap. Le fichier vit dans 00_mission/, le dossier des choses stables.

Le second, c'est le focus (01_active/focus.md). C'est l'attention du moment. Il change à chaque session, parfois plusieurs fois dans une session. Le focus, c'est « aujourd'hui, on travaille sur le découpage des idées de l'article 2 en posts distincts ». Ce n'est pas le but — c'est le sous-problème sur lequel on braque le projecteur maintenant. Le fichier vit dans 01_active/, le dossier des choses vivantes.

Pourquoi séparer les deux ? Parce que confondre le but et l'attention, c'est le meilleur moyen de dériver. Si l'IA prend le focus du jour pour le but de la mission, elle risque de redéfinir toute la mission autour d'un détail. À l'inverse, si elle n'a que le but sous les yeux, elle est trop vague : « écris des posts LinkedIn » ne dit pas sur quoi on se concentre à cet instant. La mission donne la direction, le focus donne la profondeur de champ. On peut refaire le focus dix fois sans jamais toucher à la mission. C'est exactement comme un humain : votre poste (votre mission) ne change pas parce que vous passez l'après-midi sur une tâche précise (votre focus).

Autour de la mission, dans 00_mission/, on trouve trois autres fichiers cadrants.

Le scope délimite ce qui est dans le périmètre et ce qui n'y est pas — la barrière contre la dérive du sujet.

Les risques (risks.md) sont la grille des menaces qui pèsent sur la mission. Sur PM016, c'est modeste ; mais sur une vraie opportunité produit, ce fichier suit les quatre grands risques de Marty Cagan — valeur, utilisabilité, faisabilité, viabilité business. L'idée : garder en permanence sous les yeux les questions qui peuvent faire échouer le projet, et cocher chaque risque à mesure qu'un élément vient l'éclairer ou l'aggraver. Une section vide = un risque encore non documenté, donc un angle mort assumé.

Le glossaire (glossary.md) fige le vocabulaire de la mission, pour que les mêmes mots gardent le même sens du début à la fin. C'est le même réflexe que dans mon contexte copropriété, où j'avais fini par externaliser tous les termes techniques et acronymes dans un fichier dédié : sans ça, chacun — l'humain comme l'IA — finit par employer les mêmes mots avec des sens différents.

Un point important sur tous ces fichiers, et c'est peut-être le plus contre-intuitif du système : ils ne se remplissent pas d'un coup au démarrage. Ils se remplissent progressivement, au fil des échanges. Et « échange » ne veut pas seulement dire « apporter un document ». La plupart du temps, ça veut dire parler. Je discute avec l'IA, je pense à voix haute, je lui donne un contexte que j'ai dans la tête — et c'est elle qui range ce flux au bon endroit : ce point-là est un risque de viabilité, ce terme mérite une entrée de glossaire, cette phrase délimite le scope. Un risque non écrit devient une ligne dans risks.md parce que je l'ai mentionné en parlant, pas parce que j'ai ouvert le fichier pour le remplir. C'est là que le contexte cesse d'être un dossier à classer et devient un secrétaire particulier qui prend en note ce que je pense tout haut.

Les directives : encoder une connaissance que l'IA n'a pas

Autre fichier du noyau stable : les directives (00_mission/directives.md).

Une directive ne parle pas du sujet de la mission. Elle parle de la façon de travailler. C'est la différence entre les ingrédients et la recette.

Un exemple tiré d'un autre de mes contextes, où je fais traiter des centaines de mails de copropriété : « quand deux personnes portent le même nom de famille, utilise le sens de l'email pour indiquer leur prénom et leur entreprise » (deux prestataires avaient le même nom de famille). Ce n'est pas une information sur la copropriété. C'est une règle de traitement. Elle encode une connaissance que moi seul possède, et que l'IA applique ensuite systématiquement — sans oublier, sans se fatiguer.

Pour PM016, une directive typique serait : « chaque post doit défendre une seule idée atomique, jamais un résumé de l'article entier ». C'est une contrainte de production que je pose une fois, et qui vaut pour les vingt-sept posts.

Les directives sont dans le noyau always_load : elles sont donc rechargées à chaque session. Une règle qu'on a établie en semaine 1 s'applique encore en semaine 6, sans que j'aie à la répéter. C'est cumulatif. Plus une mission avance, plus ses directives se raffinent, et plus l'IA travaille comme moi.

Détail d'usage : pour ajouter une directive en cours de conversation, je préfixe simplement mon message par alpha directive : ... et l'IA va la consolider dans le fichier. Il existe une poignée de mots-clés comme celui-là (decision :, contradiction :, todo :, checkpoint, fin de session) — des raccourcis pour ranger une information dans le bon fichier sans avoir à le dire explicitement. Ce ne sont que des commodités ; le cœur du système, ce sont les concepts, pas les mots-clés.

Le todo : les actions futures ne polluent pas le raisonnement présent

Le todo (01_active/todo.md) est un fichier simple mais qui résout un vrai problème.

Quand on travaille sur un sujet, des idées d'actions futures surgissent en permanence. « Il faudra vérifier ce chiffre. » « On devrait décliner ce post en carrousel. » « Penser à relire la version anglaise. » Si on laisse ces actions flotter dans la conversation, deux choses arrivent : soit on les oublie, soit elles polluent le raisonnement en cours en tirant l'attention dans tous les sens.

Le todo, c'est l'endroit où on pose ces actions pour ne plus avoir à les tenir en tête. C'est un backlog. Chaque tâche a un identifiant (T-NNN) et un statut. On l'alimente en écrivant todo : .... Et parce qu'il fait partie du noyau chargé à chaque session, aucune action ne se perd entre deux sessions.

C'est la même logique que pour tout le reste : sortir une information de la mémoire volatile de la conversation pour la poser à un endroit stable et nommé.

La file offline : parler au contexte quand il dort

Voici une brique à laquelle on ne pense pas au début, et qui devient vite indispensable : le fichier offline (01_active/offline.md).

Le problème : les idées ne viennent pas seulement quand on est assis devant l'IA, contexte ouvert. Une idée sur PM016 me traverse l'esprit un dimanche soir, alors que je n'ai aucune envie d'ouvrir une session complète. Où la mettre ?

Dans le fichier offline. C'est une boîte aux lettres. J'y dépose un message — une idée, une correction, un rappel — sans ouvrir de session. Le fichier dort avec le contexte.

Puis, au démarrage de la session suivante, le workflow prévoit une étape précise : si offline.md n'est pas vide, traiter son contenu comme un message entrant, puis vider le fichier. L'IA lit mon message du dimanche soir comme si je venais de le taper, le prend en compte, agit dessus, et remet la boîte à zéro. Rien ne se perd, et je n'ai pas eu à ouvrir une session juste pour noter une idée.

C'est une manière asynchrone de parler à un contexte. Le contexte devient quelque chose à qui je peux laisser un mot, même quand il n'est pas « allumé ».

Les sources et les notes : de la matière brute à la connaissance réutilisable

Jusqu'ici, on a parlé du pilotage. Maintenant, le contenu.

Zoom sur la chaîne qui va du brut à la connaissance :

03_sources/          ← la matière brute
├── SRC-001.md       la fiche (transcription exploitable)
└── raw/             l'original tel quel (le PDF, illisible par l'IA)

04_notes/            ← la connaissance extraite
├── atomic/          une idée = une note (NOTE-0001, 0002…)
└── thematic/        les synthèses qui relient plusieurs notes

Quand j'apporte de la matière — pour PM016, le PDF des trois articles — elle ne va pas se déverser dans la conversation. Elle va dans 03_sources/, la matière brute. Chaque source reçoit une fiche et un identifiant (SRC-001, SRC-002…). Le PDF original, illisible directement par l'IA, est conservé tel quel dans un sous-dossier raw/, et une fiche .md en donne une transcription exploitable. On sait toujours d'où vient chaque information.

Ensuite vient le travail d'extraction. À partir des sources, l'IA produit des notes atomiques dans 04_notes/atomic/. Une note atomique capture une seule unité de pensée : un fait, une définition, une hypothèse, un pattern, une contradiction. Pour PM016, l'analyse des trois articles a produit vingt-deux notes. En voici une, réelle :

NOTE-0022 — Arbitrer sans devenir aveugle : le curseur cadre vs autonomie Pattern : donner à une responsabilité assez d'autorité pour arbitrer crée un risque nouveau — la centralisation aveugle. […] La cohérence n'est pas l'homogénéité. Exemple Nike : des univers très différents (running, football, basket…) coexistent sans tout uniformiser.

Cette note est autonome : on la comprend sans rouvrir l'article. Elle est sourcée (elle pointe vers SRC-001, page 67). Et elle est reliée : en bas, une section ## Backlinks la connecte à la note thématique the-brand-man. C'est du Zettelkasten — des unités de pensée reliées entre elles, où l'intelligence émerge des liens, pas de l'accumulation.

Il y a une règle que je m'impose ici, et qui est plus subtile qu'elle n'en a l'air : une note atomique n'est jamais de la matière pré-formatée pour le livrable. Même si le but de la mission est de produire des posts LinkedIn, une note ne doit pas être une « accroche » ou une « punchline ». La note capture une connaissance neutre et vraie. La mise en forme au service de l'objectif, elle, se fait uniquement dans les livrables. La chaîne est stricte : sources (brut) → notes (connaissance neutre) → outputs (livrable orienté). Tant qu'on est dans les notes, le but de la mission n'a pas encore son mot à dire. Sinon, on empoisonne sa propre matière première.

Cette règle a l'air rigide. En réalité, c'est elle qui rend les notes puissantes — parce qu'une connaissance neutre est agnostique du livrable, donc réutilisable pour n'importe lequel.

Prenons une mission produit plutôt que PM016. À partir d'un même ensemble de notes atomiques — un enjeu client, une contrainte d'adoption, un pattern de marché — je peux générer des supports très différents : un pitch pour un comité de direction, une documentation de support, un article de blog, une sales narrative, un onboarding. Chaque livrable pioche et combine les briques dont il a besoin dans ce corpus commun. Si j'avais formaté ces notes pour le pitch, elles ne serviraient qu'au pitch. En les gardant neutres, elles servent les cinq. La mise en forme, l'angle, le ton : tout ça arrive au dernier moment, dans 07_outputs/, une fois qu'on sait quel livrable on produit.

Et la réutilisabilité ne s'arrête pas à la mission. Les contextes ne sont pas des silos étanches. Une note produite pour un contexte peut en éclairer un autre — parce qu'on peut relier des contextes connexes entre eux. Je peux même ouvrir un contexte pour aller en auditer un autre : parcourir ses notes et repérer les bonnes idées à reprendre. Une brique de connaissance écrite une fois peut ainsi nourrir un livrable aujourd'hui, un autre livrable demain, et une décision dans un troisième contexte dans six mois. C'est exactement la promesse de départ : le livrable est jetable, la note est un actif.

Quand plusieurs notes convergent, on écrit une note thématique dans 04_notes/thematic/ — une synthèse d'un angle ou d'une tension. Pour PM016, une par article.

Les trois mémoires : épisodique, sémantique, et les photos d'étape

Zoom sur les trois lieux de mémoire — trois échelles de temps :

05_memory/
├── journal/         ce qui s'est passé, jour par jour (l'histoire)
└── synthesis.md     ce qu'on en retient (la leçon)

02_checkpoints/      l'état complet à un instant T (la photo de reprise)

C'est ici que se joue la deuxième grande subtilité du système. Un cerveau humain n'a pas une mémoire, il en a plusieurs, qui fonctionnent à des échelles de temps différentes : celle qui retient ce qui se passe maintenant, celle qui stocke les événements vécus, et celle qui consolide les savoirs durables. Le système reproduit cette architecture avec trois objets distincts, qu'il ne faut surtout pas confondre.

Le journal (mémoire épisodique). Dans 05_memory/journal/, un fichier par jour de travail. Il raconte ce qui s'est passé : ce qu'on a fait ce jour-là, dans quel ordre, quelles décisions ont été prises, ce qui a coincé. C'est le récit chronologique. On y va quand on se demande « mais qu'est-ce qu'on avait décidé mardi, et pourquoi ? ». C'est daté, séquentiel, jamais réécrit.

La synthèse (mémoire sémantique). Dans 05_memory/synthesis.md, un seul fichier. Il ne raconte pas ce qui s'est passé — il condense ce qu'on en retient. Les conclusions stables, les convictions validées, les patterns extraits de dizaines de sessions. C'est la mémoire à long terme, débarrassée de la chronologie. Un product manager senior ne redécouvre pas à chaque projet que les utilisateurs mentent en interview : c'est devenu un savoir sémantique. La synthèse, c'est ça. Elle fait partie du noyau chargé à chaque session, parce que c'est le condensé le plus utile pour reprendre le fil.

Les checkpoints (les photos d'étape). Dans 02_checkpoints/, un fichier par jour maximum. Un checkpoint est un instantané complet de l'état du contexte à un moment donné. L'angle de rédaction est très précis, et c'est ce qui en fait sa valeur : « si un LLM arrivait maintenant sans rien avoir lu, que doit-il savoir pour reprendre sans erreur et sans recommencer ? » Le checkpoint est le filet de sécurité de la reprise.

La distinction journal / synthèse est celle qui échappe le plus souvent. Le journal, c'est l'histoire ; la synthèse, c'est la leçon. On a besoin des deux, exactement pour la raison qui m'avait poussé, dans mes tout premiers essais, à séparer l'agrégation d'un log chronologique : je voulais à la fois savoir où on en est (la synthèse) et pouvoir remonter le fil (le journal). Écraser l'un avec l'autre, c'est perdre soit la mémoire, soit la traçabilité.

Et c'est précisément ce qui rend le système auditable. Un cerveau oublie — c'est sa force. Un système de fichiers, lui, n'oublie rien. De la synthèse, on remonte au checkpoint. Du checkpoint, aux journaux. Des journaux, aux notes. Des notes, aux sources brutes. Quand quelqu'un demande « pourquoi cette décision ? », la réponse n'est jamais « parce que l'IA l'a dit ». C'est une chaîne de preuves : source → note → décision.

Le cycle d'une session, de bout en bout

Maintenant qu'on a les briques, voici le film complet d'une session sur PM016.

Au démarrage. L'IA lit le manifeste, charge le noyau, lit le dernier checkpoint. Elle vérifie le fichier offline : s'il contient un mot que j'ai laissé entre deux sessions, elle le traite puis le vide. En quelques secondes, elle sait où on en est. La fiche de reprise (resume_work.md) lui donne même la première action à faire.

Pendant la session. On discute — souvent à voix haute, devant l'écran. Et au fil de la conversation, l'IA range en continu. Une nouvelle source arrive → 03_sources/. Une idée durable émerge → une note atomique dans 04_notes/. Une décision est prise → decisions.md. Une contradiction apparaît → contradictions.md (on ne la lisse pas artificiellement, on la garde visible). Une action future → le todo. Chaque fois qu'un fichier est créé, le README.md de son dossier et l'index machine sont mis à jour. Le contexte se tient constamment à jour, sans effort de ma part.

En fin de session. Je tape /context_close. L'IA déclenche le rituel de clôture : elle écrit le journal du jour, met à jour l'état courant et la fiche de reprise, promeut vers la synthèse ce qui mérite de devenir durable, et crée un checkpoint si un seuil est atteint. Puis elle commit le tout. La prochaine session pourra reprendre exactement là où celle-ci s'est arrêtée.

Il existe aussi une compaction en cours de route (/context_push) : quand l'état courant enfle, que le todo devient illisible, ou qu'on tourne en rond, on condense, on déduplique, on priorise, on archive ce qui ne sert plus — sans jamais perdre la traçabilité.

Mais le /context_push a un rôle plus vital encore, et c'est un piège dans lequel on tombe forcément quand on découvre le système. Quand une session dure longtemps, la conversation finit par dépasser la fenêtre du LLM. À ce moment-là, le LLM fait sa propre compaction : il résume silencieusement les échanges anciens pour faire de la place. Et tout ce qui n'avait pas encore été écrit sur disque à cet instant — une décision évoquée à l'oral, une idée lancée en passant, une nuance importante — est raboté, déformé, ou purement perdu. Le LLM ne vous prévient pas ; il croit avoir gardé l'essentiel, mais c'est lui qui a choisi ce qui était essentiel.

Le /context_push est la parade : il force la persistance sur disque avant que le LLM ne compacte sa mémoire de travail. En poussant régulièrement, on garantit que tout ce qui compte est déjà écrit dans les fichiers — au bon endroit, sourcé, tracé — donc que la compaction du LLM ne fait plus perdre quoi que ce soit d'important. C'est le principe fondateur de l'article, appliqué au fil de la session : ce qui vit uniquement dans la conversation est en sursis ; seul ce qui est sur disque est vraiment mémorisé.

L'oubli sans la perte

Un dernier point, parce qu'il dit beaucoup de la philosophie du système. Il n'y a pas de suppression brutale.

Quand une information n'est plus utile, on ne l'efface pas. On la sort du chargement par défaut, on la compacte, ou on l'archive. Quand une idée en remplace une autre, on ne l'écrase pas : on la marque superseded, on garde l'ancien identifiant, et on fait pointer l'ancien vers le nouveau. On ne supprime réellement qu'en cas d'erreur manifeste ou de doublon non ambigu.

Pourquoi tant de précautions ? Parce que l'auditabilité est toute la valeur du système. Le jour où une conviction produit doit être défendue, je dois pouvoir remonter jusqu'à sa source, même si elle date de deux mois et qu'elle a été « superseded » depuis. Un raisonnement dont on a effacé l'historique n'est plus un raisonnement — c'est une opinion sans preuve.

Ce que le contexte est vraiment

Au fond, ce moteur de contexte n'est pas un système de rangement. C'est une architecture de mémoire pour une intelligence qui n'en a pas nativement.

Chaque brique répond à une limite du LLM : le manifeste répond à la fenêtre finie ; les trois mémoires répondent à l'oubli entre sessions ; les notes atomiques répondent au Lost in the Middle ; la séparation sources/notes/livrables répond au besoin de traçabilité ; le fichier offline répond au fait que la pensée ne s'arrête pas quand la session se ferme.

Et le résultat, c'est ce que je décrivais dans mes articles précédents : 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 — cette mémoire structurée, traçable, réutilisable, qu'on enrichit session après session et qui finit par produire bien plus que ce qu'on lui demande.

Pour PM016, le but était vingt-sept posts LinkedIn. Mais ce qui reste, une fois les posts publiés, c'est un contexte : vingt-deux idées atomiques reliées, trois synthèses thématiques, des sources tracées. Une matière que je pourrai rouvrir dans six mois pour un tout autre livrable. Le post était l'objectif. Le contexte est l'actif.

Pour en savoir plus

Du fichier unique au système de contextes : pourquoi la mémoire d'un LLM ne tient pas dans un seul document Le PM comme architecte du Contexte Un fichier, des directives, et Claude fait le reste — comment j'ai structuré 500 mails sans effort Qu'est-ce qu'une note atomique ? Qu'est-ce qu'une note thématique ?