La liste qui sert vraiment

Tu ouvres le fichier où tu notes ce qu’il reste à faire. Des lignes de janvier, des lignes d’avant-hier, tout au même niveau, sur des pages que tu fais défiler sans les lire. Tu le refermes avec la sensation exacte que tu avais en l’ouvrant : tu es en retard sur tout, et tu ne sais pas par où commencer.

La leçon 10 demandait « comment tu sais que ça marche ». Celle-ci pose la question d’après, et elle est plus bête en apparence : de tout ce qui reste, qu’est-ce qui compte ?

Ce qui se passe vraiment

Ce fichier n’est pas un arriéré, et il n’a jamais prétendu l’être

Un arriéré, c’est une file de choses dues : chaque ligne a quelqu’un en face qui attend, chacune est en retard, et le tas grandit tant que tu ne rembourses pas. C’est ce que tu crois avoir sous les yeux. Ce n’est pas ce que tu as.

Personne n’a décidé d’écrire une liste de tâches. Ce fichier s’est écrit par accumulation, une ligne à la fois, chacune ajoutée dans un contexte qui n’existe plus. Il porte au moins trois espèces de lignes qui n’ont rien à voir entre elles : ce qui est fait, une trace qui ne demande plus rien à personne ; ce qui est en cours, la seule chose qui répond à « où j’en suis » ; et une décision prise, un débat tranché avec son motif, qui existe justement pour ne pas être rouvert. Les lire toutes comme des tâches transforme un relevé d’état en arriéré, et cet arriéré-là n’existe pas : il est fabriqué par la lecture, pas par le projet.

Une dette, ce n’est pas ce qu’on doit — c’est ce sur quoi des intérêts courent

L’image n’est pas de moi. Martin Fowler l’a posée il y a longtemps, en une phrase qui suffit : le surcoût d’ajouter une fonctionnalité, c’est l’intérêt qu’on paye sur la dette — et il en tire la conséquence qu’on oublie toujours, qu’une zone épouvantable du code sur laquelle on ne repasse jamais ne coûte, en pratique, rien.

Appliqué à ton fichier : une ligne posée il y a huit mois, que personne n’a réclamée et qui ne fait rien grossir, ne te coûte rien. Son seul coût, ce sont les cinq secondes de culpabilité qu’elle te prend chaque fois que tu la relis. Multiplie par quarante pages : le fichier est devenu son propre poste de dépense, et il ne finance rien.

À l’inverse, il existe des lignes sur lesquelles quelque chose court pendant que tu ne regardes pas. Une table qui prend une ligne à chaque passage et que rien ne vide. Un fichier de journal qui grossit sans jamais être vidé ni découpé. Un certificat qui expire à une date écrite quelque part. Un service facturé à l’usage, appelé automatiquement. La leçon 10 rangeait les deux premières parmi les angles morts du test à la main, avec la propriété qui vaut pour les quatre : leur coût grandit tout seul pendant que tout marche.

Et la famille que l’image du crédit rate complètement

Si on s’arrête là, le tri déprécie exactement ce que les trois leçons suivantes apprennent à traquer. Un filet mort ne facture rien. Une faille connue ne gonfle pas. Une sauvegarde jamais restaurée n’accumule aucun intérêt. Coût nul, tous les jours, jusqu’au jour où il est total. C’est une seconde famille, et elle monte pour une autre raison : non parce qu’elle grandit, mais parce qu’entre aujourd’hui et le jour où ça compte, rien ne viendra te prévenir.

À retenir — deux familles montent en tête, pas une. Ce qui coûte pendant que tu dors : les intérêts courent, une facture monte, une donnée gonfle, une réparation enchérit, une échéance approche. Ce qui est armé et silencieux : rien ne bouge, et le jour où ça bouge, tout est joué d’un coup. Et la clause qui fait tenir l’ensemble : « je ne sais pas » compte comme un oui.

Cette clause n’est pas une précaution de rédaction. Ne pas savoir si un dispositif fonctionne encore est l’état par défaut de tout dispositif — c’est la démonstration entière de la leçon 13, où des filets posés sur un projet en production sont restés morts sept semaines sans que rien ne le signale. Une ligne dont la réponse est « je ne sais pas » monte, et sa condition de sortie est simple : aller regarder.

Ce sur quoi des intérêts courent	Ce qui est armé et silencieux	Ce qui attendra un an sans empirer
une donnée qui gonfle à chaque passage	un filet dont tu ne sais plus s’il fonctionne	un nom de variable qui te déplaît
une échéance datée — certificat, clé, quota	une faille connue et non corrigée	une page à refaire plus joliment
un service facturé à l’usage, appelé tout seul	une sauvegarde jamais restaurée pour de vrai	une option que personne n’a demandée
une réparation qui enchérit chaque semaine	un chemin de production où personne n’est repassé	une réécriture que tu voudrais faire

Les deux premières colonnes montent. La troisième n’est pas honteuse : ce ne sont pas des retards, ce sont des idées, et une idée qui attend n’a pas de créancier. Et aucune ligne ne se signale d’elle-même : elles ont toutes la même police, elles sont peut-être en page douze, et rien ne distingue une sauvegarde jamais essayée d’une envie notée un soir de fatigue.

Ce que montre un vrai fichier de notes, celui de cette formation

Ces seize leçons sont produites avec un fichier de suivi tenu pendant la production. Ce qui suit, c’est sa structure ; les lignes elles-mêmes restent dans les sessions en visio.

• Il sépare le périmètre de l’état. Son en-tête l’annonce en une ligne : le plan décide quoi écrire, ce fichier dit où on en est. La confusion des deux fabrique les quarante pages, un périmètre étant fait pour être large et un état pour être court.
• Il trace le pourquoi, pas seulement le quoi. Sa plus longue section est une suite de décisions datées, chacune avec son motif — plus coûteux qu’une case cochée, et c’est ce qui a rendu visible ce qu’aucune case n’aurait montré : la même classe de défaut y est numérotée d’occurrence en occurrence, jusqu’à la cinquième. On ne compte que ce qu’on a écrit avec sa raison.
• Il a une section pour ce qu’on a choisi d’ignorer, « Objections encaissées sans correction », dont la phrase de cadrage donne l’usage : utile quand quelqu’un refera la même objection. Une objection écartée sans trace revient tous les trois mois et se retranche tous les trois mois, au même prix.

Et ce qu’il ne fait pas, que je préfère écrire que maquiller : rien, dans ce fichier, ne dit ce qui coûte de l’argent maintenant ni ce qui peut casser la production. Je n’ai donc pas de vraie section à te montrer — ni ici, ni ailleurs : sur les projets en production, les lignes de cette espèce sont des adresses de failles et des chemins de sauvegarde, qui ne se publient pas. Ce que tu liras plus bas est inventé pour la forme, et le manque est réel. La leçon 16 démonte le reste de cette chaîne de production.

Ce qu’on fait

Cinq gestes. Aucun ne demande d’installer quoi que ce soit, et les trois premiers se font aujourd’hui.

1. Séparer le périmètre de l’état, puis donner une adresse à chaque espèce

Un fichier pour ce que le projet pourrait devenir. Un autre, court, pour où il en est. Tu ne gagnes pas de place — tu gagnes le droit de lire le second sans lire le premier, et c’est le seul moyen qu’un fichier d’état reste court. Ensuite, chaque espèce de ligne va à un endroit, et un seul : sans cette carte, les sections apparaissent au fil de l’écriture et le fichier redevient ce qu’il était.

Ce que tu lis dans ton fichier	Où ça va	Ce qui l’en fait sortir
ce qui court, ou ce qui est armé et silencieux	la section en tête, datée	sa condition de sortie, écrite avec elle
ce qui est en cours	la section d’état, quelques lignes	ça se termine, ou ça s’abandonne pour de bon
une décision prise, avec son motif	la section des décisions, datée	rien : elle reste, c’est sa fonction
une objection qu’on choisit de ne pas traiter	la section des objections écartées	rien : on la relit, on ne la recalcule pas
ce qui est fait	le bas de page	rien, et elle n’en remonte jamais
tout le reste	les idées	rien ne l’en sort tout seul — voir le geste 5

La dernière ligne est la plus importante et la moins agréable : ce qui n’entre nulle part va dans les idées. Pas dans « à voir », pas dans « bientôt » — dans les idées, où tu n’as plus le droit de te sentir en retard.

2. Mettre en tête une section « Ce qui coûte maintenant ou peut casser »

Elle est en haut, datée, et bornée : quelques lignes, pas une page. Si elle déborde, ce n’est pas qu’il y a beaucoup de choses urgentes, c’est que le test du geste 3 n’a pas été appliqué. Chaque ligne porte quatre choses, et les trois exemples qui suivent sont inventés :

1. la date d’entrée — celle où tu l’as inscrite, pas celle où tu comptes t’en occuper ;
2. ce que ça coûte, ou ce que ça casse — de l’argent, de la place, un risque, en une phrase ;
3. l’échéance, s’il y en a une — une famille entière de lignes admises ici en a une, et c’est alors la date qui commande, pas le coût ;
4. ce qui la fait sortir — la condition précise à laquelle tu as le droit de l’effacer.

## Ce qui coûte maintenant ou peut casser — passé au test le 18/08

- [18/08] La table des évènements grossit à chaque visite et rien ne la vide.
  Coût : de la place, tous les jours, sans plafond connu. Échéance : aucune.
  Sort d'ici quand une purge s'exécute et que je l'ai vue s'exécuter.
- [18/08] Je ne sais plus si le contrôle avant publication s'exécute encore.
  Coût : nul aujourd'hui, total le jour où il aurait dû arrêter quelque chose.
  Sort d'ici quand je l'ai vu refuser un cas fabriqué exprès pour lui.
- [18/08] Le certificat du domaine expire le 12/11.
  Coût : le site devient inatteignable d'un coup. Échéance : 12/11, elle commande.
  Sort d'ici quand le renouvellement automatique a marché une fois sous mes yeux.

Sans condition de sortie, une ligne ne sort jamais — ou elle sort le jour où elle t’ennuie, ce qui est le même hasard dans l’autre sens. Et une section vide n’affirme qu’une chose : ce qui a été passé au test. Le jour où rien ne remplit les deux familles, tu n’écris pas « tout va bien » mais « rien ne remplit le test appliqué le 18/08 », et tu refermes. Les leçons 12 et 13 tiennent qu’un rapport vide n’est une bonne nouvelle que si l’on sait ce qui a été regardé : ton fichier n’y échappe pas.

Enfin, la phrase que la leçon 10 t’a demandé d’écrire quelque part, non essayé n’est pas validé, a sa place ici, mais pas telle quelle : « je n’ai pas pu essayer le paiement par virement » ne coûte rien tant que personne ne paye par virement. Écris-la avec sa date et sa condition de montée — le jour où ce chemin sert vraiment, elle passe en tête.

3. Le test avant d’y faire entrer une ligne

Deux familles, chacune ses questions. Une seule réponse « oui » suffit à faire monter la ligne.

Famille 1 — est-ce que quelque chose court pendant que tu dors ?

• Est-ce que quelque chose s’accumule ou se facture sans moi ? Une facturation à l’usage, une donnée qui s’entasse, une tâche planifiée, un compteur.
• Est-ce que la réparation devient plus chère chaque semaine ? Plus de données à reprendre, plus d’endroits à changer, plus de gens à prévenir.
• Est-ce que ça casse tout seul, à une date ? Un certificat, une clé, un quota, une version qui cesse d’être servie.

Famille 2 — est-ce que c’est armé et silencieux ?

• Est-ce qu’un filet est censé être en place sans que je l’aie vu agir récemment ? Un contrôle, une alerte, une limite.
• Est-ce qu’une faiblesse est connue et non corrigée, sans que rien ne la signale d’ici là ?
• Est-ce qu’une réparation d’urgence n’a jamais été essayée pour de vrai ? Une sauvegarde jamais restaurée est une sauvegarde dont on ignore l’état.

Et « je ne sais pas » compte comme un oui. C’est la réponse la plus fréquente à la famille 2, et c’est justement le signal : la ligne monte, sa condition de sortie est d’aller regarder, sa date d’entrée est le jour où tu as constaté que tu ne savais pas. Que des « non » aux deux familles : la ligne descend dans les idées, et elle n’a plus le droit de te mettre en retard.

Et si tu ne lis pas le code ? L’objection vient tout de suite, et elle est juste : ces questions parlent de choses enfouies dans des fichiers que ce parcours ne te demande pas d’ouvrir. Elles se tranchent ailleurs.

• Dans des nombres, et ils ont une adresse. La facture du mois courant contre celle du mois dernier se lit sur la page de facturation de ton hébergeur. La taille d’une table et son nombre de lignes s’affichent dans la console d’administration de ta base de données, qui les tient à jour pour toi. La date d’expiration d’un certificat se lit dans le détail du certificat, que ton navigateur ouvre depuis sa barre d’adresse — l’icône qui y mène a changé de forme et de nom selon les navigateurs et les versions, le détail, lui, est toujours là. Aucun de ces gestes ne demande de savoir lire du code, et une donnée qui gonfle ne se voit qu’ainsi : c’est pour ça que la leçon 10 la range parmi les angles morts du test à la main.
• Dans un dispositif, pour ce qui reste dans le code — et il ne t’a pas encore été donné. Faire relire par un regard neuf est le sujet de la leçon 12 ; vérifier qu’un filet est encore vivant, celui de la leçon 13. D’ici là, cette voie t’est fermée, et je préfère le dire que de te renvoyer à un outil que tu n’as pas. Quand ces dispositifs arriveront, ce qu’ils te rendront n’entrera pas directement en tête de fichier : ça repassera par le test, comme n’importe quelle ligne.

4. Écrire les décisions avec leur motif, et fermer les débats

Une décision prise sans son motif se rouvre. Écris la date, ce qui a été tranché, et pourquoi — trois lignes. Et tiens une section pour ce que tu as choisi de ne pas corriger, avec la raison : c’est ce qui te permet, six mois plus tard, de répondre à quelqu’un qui refait l’objection sans reprendre le raisonnement depuis zéro.

La trace du pourquoi vaut plus que la trace du quoi. Une case cochée dit qu’on a fait ; un motif daté empêche de refaire, de rouvrir, et permet de compter ce qui se répète. Cette section protège aussi la précédente : un point rejeté une fois et non tracé revient s’asseoir en tête au premier doute.

5. Relire par le haut — et ce que ça te coûte

Relire, c’est relire la première section, pas le fichier. Une ligne de la section du haut se lit avec une seule question : sa condition de sortie est-elle remplie ? Oui, on l’efface. Non, on la laisse et on passe. Le reste du fichier ne se relit pas ligne à ligne, jamais, et c’est délibéré : c’est exactement cette relecture intégrale qui produit la culpabilité du début de leçon.

Reste ce qu’on aimerait promettre ici et qui serait faux : que ce qui compte finira par remonter tout seul. Rien ne remonte tout seul. Une idée descendue peut y mourir, et une ligne de la famille 2 que tu n’as pas reconnue le jour où tu l’as écrite ne se fera pas remarquer plus tard. Deux choses seulement, dont aucune n’est un remède. La porte de retour, quand tu peux la poser : une ligne descendue porte une date d’aller-voir, et c’est cette date qui la fait remonter, pas ton intuition. Et l’aveu, quand tu ne peux pas — le fond de ce fichier n’est plus surveillé, tu l’as décidé, et il n’y a pas de version où ça ne se paye pas.

Ce que ça ne fait pas

Une note n’est pas un contrôle

Piège — une ligne qui affirme qu’un problème est réglé est un filet de plus, avec le même mode de panne que les autres : elle ne vérifie rien, elle enregistre que quelqu’un y a cru à une date. La leçon 13 raconte le cas d’un fichier de suivi qui annonçait un préjudice neutralisé depuis la pose d’un garde-fou qui, mesure faite, n’avait jamais rien intercepté. Une note qui dit « corrigé » se traite comme une trouvaille de relecteur : elle vaut ce que vaut la preuve qu’on peut produire aujourd’hui.

C’est la limite la plus dangereuse, parce qu’elle produit l’inverse exact de l’effet recherché — d’où la forme retenue au geste 2 : une condition de sortie est une phrase qu’on peut aller vérifier ; « corrigé le 3 juin » n’en est pas une.

Une note n’est pas une garantie

Les leçons 3 et 6 ont posé la règle générale, et elle vaut ici sans changement : ce qui est écrit dans un fichier (le CLAUDE.md, le fichier de règles du projet, relu à chaque session) est une demande, pas une configuration appliquée. À plus forte raison une note que personne ne charge. Ce qui doit arriver à chaque fois, sans dépendre de ta mémoire ni de la sienne, ne s’écrit pas en ligne de liste : c’est la ligne du hook — un déclenchement automatique attaché à un événement, leçon 5. C’est le sujet de la leçon 13.

Et ce tri ne répond que pour toi. Les deux familles sont écrites au singulier, et c’est une limite, pas un style : à plusieurs, une ligne qui ne te coûte rien peut bloquer quelqu’un d’autre — ce que tu ranges dans les idées parce que tu n’y repasses jamais est peut-être le chemin quotidien d’un collègue. Le test se passe alors à deux, ou il ne vaut que pour ta part du projet.

Ce fichier n’est pas lu tout seul, et le faire lire n’est pas neutre

Trois choses que le lecteur confond régulièrement, et qui ne se remplacent pas :

Ce que c’est	Qui l’écrit	Ce que ça fait
Ton fichier de notes	toi	rien, tant que personne ne l’ouvre
Le fichier de règles du projet	toi	chargé au début de chaque session
La mémoire automatique	Claude	ses propres notes, rangées par dépôt ; seul son index est relu au démarrage, et seulement jusqu’à un plafond

La mémoire automatique n’est pas ton arriéré non plus. La leçon 6 en a donné le mécanisme ; deux points comptent ici. Claude y range ce qu’il juge utile pour plus tard (commandes de build, trouvailles de débogage, préférences), et il ne note pas quelque chose à chaque session. Et ce qui est rechargé au démarrage, c’est l’index seul, et partiellement : ses 200 premières lignes ou ses 25 premiers Ko, au premier atteint ; les fichiers de sujet, eux, ne sont jamais chargés au démarrage. Même pour le fichier que la machine tient elle-même, ce qui est en haut est ce qui est lu : ta section en tête n’y est pas pour des raisons de goût.

Et si tu fais lire ton fichier de notes à chaque session, sache ce que tu achètes. La leçon 3 l’a établi sur deux plans : le poste de dépense principal du contexte, ce sont les fichiers lus, et ce qu’on pose sur le plan de travail dilue l’attention portée au reste sans attendre que la fenêtre soit pleine. La documentation ajoute la partie qu’on n’attend pas — un fichier d’instructions long ou périmé n’occupe pas seulement de la place, il oriente les réponses. Une note morte qu’on charge ne dort pas.

La liste de tâches intégrée n’est pas ton arriéré

Celle qui s’affiche dans la session est la liste de Claude : les étapes qu’il s’est données pour le travail du moment. Le détail est sur la page liée plus bas ; deux points comptent ici.

• Une liste vide n’est pas une liste finie. Depuis la version 2.1.233, en session interactive, les outils qui la remplissent ne sont plus fournis sur les modèles les plus récents sauf demande explicite — la documentation donne le motif et quatre façons de les récupérer. Une bascule d’affichage qui ne montre rien n’est donc pas une panne. Avec une exception qui compte : en session d’arrière-plan et sur le web, les mêmes outils sont fournis sur tous les modèles, listés ou non.
• Ce qu’elle partage avec ton fichier est mince. Elle survit aux compactions, et un réglage documenté permet même de partager une liste entre sessions, via un répertoire nommé sous ~/.claude/tasks/. Ça n’en fait pas un fichier d’état : elle décrit un travail en cours, pas ce sur quoi des intérêts courent.

Rien ne supprime les lignes à ta place

Il n’existe aucun dispositif qui vienne dire « cette note ne sert plus ». Le plus près du ménage où va la machine, c’est son propre index de mémoire : quand il frôle son plafond, Claude Code rappelle à Claude de le raccourcir ; quand il le dépasse, l’écriture passe, mais une erreur lui demande de réécrire l’index. Personne n’efface — on rappelle à quelqu’un d’écrire moins. Cette mémoire est même exclue du ménage périodique qui supprime les vieilles sessions.

Le seul geste documenté qui réponde à « quand retirer » parle de ta configuration, pas de tes notes : /doctor fait un examen d’installation, signale les skills, serveurs MCP et plugins que tu n’utilises pas au regard de ce qu’ils coûtent en contexte, et propose d’élaguer d’un CLAUDE.md versionné ce que Claude peut déduire du code lui-même — cette vérification-là à partir de la version 2.1.206. Il rapporte d’abord et ne change rien sans que tu confirmes. Ça montre surtout ce qui manque : l’équivalent pour ton fichier de notes, c’est le geste 5, et il n’a pas de commande.

Ce n’est pas un gain de temps

Écrire une condition de sortie prend plus de temps que cocher une case, et écrire le motif d’une décision plus de temps que la prendre. Ce que ça te rend, ce n’est pas de la vitesse : c’est de pouvoir ouvrir ce fichier un lundi matin, lire dix lignes, et savoir ce qui a été passé au test — et, tout aussi précisément, ce qui ne l’a pas été.

Et les versions bougent sous tes pieds. Chaque comportement daté ci-dessus porte son numéro de version à l’endroit où il est décrit. L’ensemble a été contrôlé le 20 août 2026 contre l’instantané de la documentation officielle du même jour. C’est la date du dernier contrôle, pas une promesse de fraîcheur : claude --version et /help répondent pour ta machine, aujourd’hui.

Où c’est écrit

Cette leçon est un process, pas une fonctionnalité : l’essentiel n’est dans aucune page. Les faits techniques qu’elle avance, eux, sont vérifiables.

• La liste de tâches — ce qu’elle contient, sa bascule et son plafond, ce qui survit aux compactions, le réglage qui la partage entre sessions ; puis la disponibilité des outils de tâches : les modèles, la version, le motif, les quatre façons d’activer, et l’exception de l’arrière-plan et du web ;
• Comment Claude se souvient de ton projet — ce que la mémoire automatique note d’elle-même, ce qui est chargé au démarrage et jusqu’où, le rappel envoyé quand l’index déborde, et son emplacement, exclu du ménage périodique ;
• La liste des commandes, entrée /doctor — l’énumération exacte de ce qu’il examine et propose, la phrase qui dit qu’il rapporte avant d’agir, et la version que demande la vérification du CLAUDE.md versionné ; puis déboguer sa configuration pour la place de cette commande parmi les autres. Le tableau de cette seconde page résume la même chose en moins précis : lis l’entrée de la première ; et quand les réponses semblent moins bonnes que d’habitude : un fichier d’instructions long ou daté consomme du contexte et oriente les réponses.

Ces liens pointent vers les pages anglaises, avec la réserve de vocabulaire expliquée en leçon 4 ; la version française existe, /fr/ à la place de /en/. Et deux textes qui ne parlent pas du tout de Claude Code, à qui cette leçon doit son ossature — il faut les nommer, parce qu’on lit souvent que ce tri n’existe nulle part, et c’est faux :

• TechnicalDebt, Martin Fowler — la dette comme intérêts payés en surcoût de développement, et le corollaire qui sert ici : ce qu’on ne touche jamais ne coûte pas, si épouvantable soit-il ;
• Getting Things Done, David Allen — la liste Someday/Maybe, dont la fonction est exactement celle de nos « idées » : sortir du quotidien ce qui n’a pas à consommer de ressource mentale, sans le jeter.

Ce que cette leçon ajoute : la seconde famille, qu’aucune des deux ne traite — chez Fowler, ce qu’on ne touche pas ne coûte rien, ce qui est vrai du code mort et faux d’un filet mort ; et le raccordement à un outillage agentique, qui n’existait pas quand ces textes ont été écrits. Où entre ce qu’un relecteur te rend, ce que la mémoire automatique note toute seule sans te demander ton avis, ce que /doctor signale et ce qu’il ne fera jamais.

Le point de bascule

Il y a un moment où ouvrir ce fichier cesse de te mettre en retard. Concrètement : tu lis dix lignes en haut, tu refermes, et la question qui te reste n’est plus « par où je commence ? » mais « qu’est-ce qui court, ou qu’est-ce qui est armé, que je n’ai pas mis en haut ? ». Celle-là se traite : deux familles, une date, et l’aveu de ce que tu n’as pas regardé.

Vérifier que c’est passé

Deux lignes dans ton fichier. L'une date de huit mois : « refaire la page de contact, elle est moche » — elle te met mal à l'aise à chaque ouverture. L'autre date d'avant-hier : « le fichier de journal du serveur n'est jamais vidé ». Laquelle passe en tête ?

La seconde, et l’ancienneté de la première est justement l’argument contre elle. Un journal que rien ne vide grossit à chaque passage : quelque chose court dessus, sans toi, pendant que tout marche. La page moche, elle, a démontré pendant huit mois qu’elle n’empirait pas — c’est une idée, pas une dette. Le malaise qu’elle provoque n’est pas un signal d’urgence, c’est le coût de lire un fichier de notes comme un arriéré.

En tête de ton fichier, une ligne datée : « 3 juin — corrigé, le problème ne se reproduit plus ». Qu'est-ce que cette ligne prouve ?

Que quelqu’un y a cru le 3 juin. Rien d’autre. Une note n’est pas un contrôle : elle enregistre une conviction, elle ne la vérifie pas, et elle a le mode de panne des dispositifs de la leçon 13 — avec un défaut en plus, celui de faire renoncer à regarder. C’est pour ça qu’une ligne de la section du haut porte une condition de sortie et non un verdict : « sort d’ici quand j’ai vu la purge s’exécuter » se vérifie, « corrigé » ne se vérifie pas.

Tu passes ton fichier au test. Une ligne dit : « scan de secrets avant enregistrement — installé en mars ». Rien ne se facture, rien ne gonfle, aucune échéance, et tu ne saurais pas dire s'il s'exécute encore. Elle monte ou elle descend ?

Elle monte, et c’est le cas qui distingue ce tri d’un tri par intérêts. Aucune question de la première famille ne répond oui : rien ne s’accumule. Mais ce filet est armé et silencieux — il ne coûte rien tous les jours, et il coûte tout le jour où il aurait dû arrêter quelque chose. S’y ajoute la clause qui décide : tu ne sais pas, donc c’est un oui. Sa date d’entrée est aujourd’hui, son coût s’écrit « nul maintenant, total au premier accident », et sa condition de sortie n’est pas « vérifier le fichier » mais l’avoir vu refuser un cas fabriqué pour lui — leçon 13.