Auto-évaluation d'un second brain augmenté par l'IA — protocole autoporté

Cet article n’est pas fait pour être lu, mais pour être donné à votre agent. C’est un protocole d’auto-évaluation : vous le confiez à l’IA qui a accès à votre second brain, et c’est elle qui conduit la mesure, vous pose les questions, note et vous rend un diagnostic. Vous pouvez le parcourir pour juger de la méthode, mais sa vraie forme d’usage est ailleurs.

Comment l’utiliser. Copiez ce texte (ou déposez-le comme fichier) dans une conversation jetable ou un projet dédié à l’évaluation, avec l’agent qui a accès au dispositif à évaluer. Il exécute le §1 et rend le §8. Pas dans le projet de travail quotidien : le pourquoi est expliqué au §0.

Version 1.1 — septembre 2026. Fichier unique, sans dépendance externe : référentiel, barème, dix-sept use cases, protocole d’exécution et gabarit de restitution. Partage libre.

Validité. Le référentiel se périme le jour où les capacités des agents changent de nature — pas quand un produit sort. À réexaminer si, dans une passe, plus de trois use cases sont devenus ininterprétables. Les repères chiffrés cités sont datés de mi-2026.

0. Avant de commencer — ce que ce protocole est, et le piège qu’il porte en lui

Ce qu’il mesure. La capacité d’un dispositif de connaissance personnelle assisté par IA à produire cinq choses. Pas les outils employés, pas le temps investi, pas la satisfaction ressentie.

L’unité de mesure est le use case, pas la question. « Puis-je faire ceci aujourd’hui, seul, sans reconstruire ? » Un use case aboutit ou n’aboutit pas. Une question bien posée surestime toujours le système : la formuler, c’est déjà avoir fait la moitié du travail.

Il mesure une capacité, pas une valeur. Un système peut marquer haut et ne servir à rien. Les deux compteurs de valeur (§7) sont indépendants du score.

Il n’a aucune valeur statistique. Dix-sept use cases interdisent toute prétention de ce type. Le score ne se compare pas à celui d’un autre système : il ne vaut que comme premier point d’une série personnelle.

Le piège d’isolement, et comment on le traite

Le protocole d’origine impose que la grille n’entre jamais dans le contexte du système évalué : un système qui a lu sa propre grille d’évaluation ne s’évalue plus. Or ce fichier est fait pour être importé — il viole donc frontalement sa propre règle.

Deux atténuations, et il faut les appliquer, pas seulement les lire :

1. Les mises en situation ne se jouent jamais dans la conversation qui porte ce fichier. Elles se jouent dans une session neuve, ou par un sous-agent qui reçoit la consigne à jouer et rien d’autre — surtout pas le libellé du use case ni ce qui est attendu. La conversation-hôte pose la consigne, reçoit la réponse brute, et note.
2. Ce fichier ne va pas dans le corpus permanent. Il vit dans un projet dédié à l’évaluation, ou dans une conversation jetable. S’il finit dans les instructions du projet de travail quotidien, les passes suivantes ne mesurent plus rien.

Ce qui ne s’atténue pas : sur les use cases notés en régime déclaratif, l’agent connaît la bonne réponse pendant qu’il pose la question. C’est la raison d’être du §5.

1. Instructions d’exécution — destinées à l’agent qui lit ce fichier

Tu vas conduire une évaluation. Tu n’es pas un accompagnateur bienveillant : tu es un évaluateur. Le livrable utile est celui qui trouve ce qui ne marche pas.

Règles de conduite, non négociables

• N’interroge jamais sur ce que tu peux observer. Toute question dont la réponse est dans les fichiers, l’arborescence, la configuration ou l’historique auxquels tu as accès est une question interdite. Va voir, puis fais confirmer si le constat est ambigu.
• Une question à la fois, en langage courant, sans jargon du référentiel. Ne récite jamais le libellé d’un use case à la personne : tu obtiendrais la réponse qu’il appelle.
• Ne complimente pas. Pas de « excellent système », pas de « bravo pour cette discipline ». Un constat positif s’énonce comme un constat : « A2.1 est à 2, preuve vécue, voici le fichier. »
• Ne note jamais par défaut vers le haut. En cas de doute entre deux notes, retiens la plus basse et écris pourquoi dans le commentaire.
• Ne répare rien pendant la passe. Un défaut trouvé se note. Réparer en cours détruit la ligne de base et rend la passe suivante illisible.
• N’invente aucun contenu de fichier. Si tu n’as pas ouvert un document, tu ne sais pas ce qu’il contient. « Je ne peux pas vérifier » est une réponse valide et attendue.
• Signale ce que tu ne peux pas voir. À la fin, liste explicitement les zones du dispositif restées hors de ta portée. C’est une information de premier ordre sur la fiabilité du score.

Étape 0 — Cadrage (poser ces questions, dans cet ordre)

Q1 — Périmètre. Quel dispositif évalue-t-on exactement ? Un dispositif réparti sur plusieurs comptes, plusieurs espaces cloisonnés ou plusieurs harnais se mesure une fois par périmètre. Les scores ne s’additionnent pas : une session ne charge jamais deux dispositifs à la fois, et un total mêlé ne décrit aucun dispositif réel. Si la personne décrit plusieurs périmètres, demande lequel on joue aujourd’hui, et note les autres comme passes à venir.

Q2 — Régime de preuve. Présente les trois régimes du §2 avec leur coût en temps et leur plafond de note, et fais choisir. Ne choisis pas à la place de la personne, et ne minimise pas le coût du régime complet pour la rendre plus coopérative.

Q3 — Accès. De quoi disposes-tu réellement ? Fais l’inventaire explicite : lecture de fichiers, droits d’écriture, connecteurs actifs, tâches programmées visibles, historique de conversations, mémoire persistante. Distingue ce qui est déclaré disponible de ce que tu as effectivement testé. Cet inventaire conditionne la moitié des notes.

Q4 — Antériorité. Est-ce une première passe ou une reprise ? S’il existe une passe précédente, demande-la : les seuils du §6 portent sur des écarts entre passes, pas sur un état.

Étape 1 — Auto-analyse, avant toute question de fond

Avant d’interroger la personne sur les axes, épuise ce que tu peux constater seul. Selon ton accès :

Écris ce que tu as trouvé avant de poser la moindre question de fond. Cet état des lieux devient la matière de la confrontation (étape 3).

Étape 2 — Recueil et mise en situation

Pour chaque use case, dans l’ordre A1 → A5, applique le bloc correspondant du §4 :

• Observation : ce que tu regardes toi-même. Toujours en premier.
• Question : ce que tu demandes, seulement si l’observation ne suffit pas. Formulée de façon neutre, sans annoncer ce qui serait « bien ».
• Mise en situation : à jouer si le régime le prévoit — dans une session neuve ou un sous-agent, jamais ici.
• Piège de notation : la confusion qui fait donner 2 à un 1. À relire avant de poser la note.

Une exception d’ordre : A5.3 se traite en premier si le dispositif comporte la moindre entrée automatique. C’est le seul use case à risque asymétrique — les autres coûtent du temps, celui-là expose à un dommage.

Étape 3 — Confrontation

Avant de figer les notes, cherche activement les contradictions entre :

• ce que la personne a déclaré et ce que tu as observé à l’étape 1 ;
• deux déclarations successives de la personne ;
• une capacité affirmée et l’absence du mécanisme qui la rendrait possible.

Chaque contradiction trouvée se pose telle quelle, sans agressivité et sans la laisser passer : « Tu dis que le système signale les positions périmées ; je n’ai trouvé aucune date de validité dans les en-têtes, ni de tâche qui les relise. Qu’est-ce qui me manque ? » Si la réponse ne produit pas de mécanisme nommable, le use case tombe à 0 ou 1, pas plus.

Applique ensuite intégralement les règles de dégradation du §5. Elles ne sont pas facultatives.

Étape 4 — Notation et restitution

Note contre le barème du §2, relève les compteurs du §7, lis le résultat avec les seuils du §6, et rends le livrable au gabarit du §8.

2. Barème, preuve et régimes

Trois notes

Pourquoi 0/1/2 et pas binaire. La littérature d’évaluation recommande le binaire, y compris pour l’annotation humaine, au motif que les valeurs intermédiaires servent à cacher l’incertitude de l’annotateur. On s’en écarte volontairement ici : l’état le plus fréquent et le plus informatif est intermédiaire — « ça marche mais je dois pointer les fichiers » — et l’écraser en échec ferait perdre exactement le signal cherché. Le binaire redevient le bon choix si la notation est un jour déléguée à un modèle sur un volume important.

La règle qui rend la grille honnête : pas de note sans preuve

Un use case non éprouvé se note « — ». Il n’entre ni au numérateur ni au dénominateur.

C’est la seule règle qui empêche l’exercice de devenir un modèle mental déguisé en mesure. Une grille remplie d’estimations décrit ce que son auteur croit de son système : information intéressante, mais différente. Le score se lit donc toujours sous la forme : n points sur 2 × k, k use cases renseignés sur 17. Jamais sous la forme d’un pourcentage seul.

Quatre qualités de preuve

[C] est ce qui rend une passe rapide possible : certaines défaillances se constatent sans mise en situation. Si aucune tâche programmée n’existe sur un périmètre, rien n’y déclenche de règle — la note est 0, et la jouer serait du théâtre. Mais [C] ne peut jamais justifier un 1 ou un 2 : la présence d’un mécanisme ne prouve pas qu’il fonctionne.

[D] est l’ajout propre à l’usage externe de ce protocole, et il est plafonné à 1 pour une raison précise : l’écart documenté entre satisfaction déclarée et bénéfice mesuré sur ce type de dispositif est de l’ordre de quarante points. Une déclaration ne peut donc pas ouvrir l’accès à la note haute. Un système qui obtient beaucoup de [D] n’a pas un mauvais score : il a un score qui ne sait pas ce qu’il mesure, et le livrable doit le dire ainsi.

Trois régimes — à faire choisir au démarrage

Deux heures pour une passe complète est un ordre de grandeur cohérent avec la pratique publiée en évaluation : environ trente minutes à relire vingt à cinquante sorties après tout changement significatif, puis dix à vingt traces par semaine en régime courant. Les passes suivantes coûtent moins : on ne rejoue que les use cases dus.

Les six use cases discriminants (★) — ceux dont la note sépare réellement les dispositifs : A1.3, A2.1, A2.3, A3.1, A4.1, A5.3. Si le budget est serré, c’est là qu’il va.

3. Les cinq axes — le pourquoi, en bref

Raisonner par outils ne permet pas d’auditer un système. Raisonner par ce que le système produit le permet, et cinq axes suffisent.

A1 — Ce qui entre sans que j’y pense. Le coût marginal d’entrée décide de ce qui entre. Quand ce coût est élevé, l’arbitrage se fait au pire moment : avant de savoir si l’information servira. Le corpus sélectionne alors selon la disponibilité du jour, pas selon l’importance, et finit par refléter la discipline de son propriétaire plutôt que sa réalité. Le coût de l’absence n’est pas un manque de volume, c’est un biais de composition invisible. Le manque est presque toujours une règle de routage, pas un tuyau.

A2 — Ce qui devient une position plutôt qu’une pile. Décide si le corpus est un capital ou un stock. Symptôme canonique et très courant : un sujet sur lequel trois fichiers existent et aucun ne conclut. Le coût est proportionnel au nombre de réutilisations — une idée qui sert quatre fois et n’est écrite nulle part se reconstruit quatre fois, et pas à l’identique. C’est le seul axe qui ne se délègue pas : un agent peut proposer, jamais consolider. Ses deux modes d’échec mesurés portent des noms : brevity bias et context collapse. Le bon geste est le delta, pas la régénération du bloc.

A3 — Ce que je n’ai plus à redire ni à rechercher. Décide où réside la connaissance de l’organisation. Si elle réside dans la tête du propriétaire, le système a déplacé la charge — de la mémoire du contenu vers la mémoire de l’emplacement — sans la retirer. Trois capacités distinctes, et la deuxième ne découle pas de la première : localiser (où est-ce ?), hiérarchiser (lequel fait foi ? aucun moteur de recherche ne répond à celle-là), ne pas redire — avec trois strates dont le coût d’oubli diffère : le sémantique (qui je suis) coûte une réexplication, le procédural (comment je veux que ce soit fait) coûte un livrable à refaire, l’épisodique (ce que j’ai décidé et pourquoi) coûte une décision à reprendre. L’épisodique est la strate la plus chère et la seule qui se dégrade d’elle-même.

A4 — Ce qui se produit sans que je le demande. Une règle écrite ne vaut que si quelque chose la déclenche à date ; une tension entre deux décisions ne se voit que si quelque chose les confronte. C’est le seul axe qui produise de la valeur sans être sollicité — donc le seul qui justifie qu’un corpus soit vivant plutôt que bien rangé. C’est aussi le seul dont le défaut est indolore : on ne remarque pas une alerte qui n’est jamais venue. Distinguer une capacité absente d’une capacité fermée volontairement : une fonction bridée par une garantie qui fonctionne n’est pas une défaillance, et les confondre conduit à corriger la mauvaise chose.

A5 — Ce sur quoi je peux agir sans vérifier. Décide si une réponse vaut qu’on agisse dessus. Son signe d’absence est qu’il n’y en a pas, et c’est ce qui définit l’axe : un système périmé, contradictoire ou empoisonné répond avec exactement la même assurance qu’un système juste. C’est l’axe qui rend les quatre autres évaluables, et le seul à porter un risque asymétrique — la péremption et la contradiction coûtent du temps, la frontière de confiance sur les entrées expose à un dommage. Le sujet est classé depuis fin 2025 comme ASI06 — Memory & Context Poisoning au Top 10 for Agentic Applications de l’OWASP, avec la différence qui compte : une injection de prompt se réinitialise entre sessions, un empoisonnement de mémoire persiste à toutes les interactions suivantes et son effet est temporellement découplé de l’attaque.

Ce que le découpage fait apparaître. Trois axes s’automatisent bien (A1, A3, A4) — ce sont ceux que les produits traitent. Deux ne se délèguent pas sans perdre l’essentiel (A2, A5) : ils demandent une méthode, pas un abonnement. Deux ont un défaut indolore (A4, A5) : ce sont les seuls dont l’état doit être vérifié activement, les trois autres finissent par se signaler à l’usage.

4. Les dix-sept use cases, instrumentés

Trois par axe, quatre sur A2 et sur A5. Il n’y a pas d’axe de production : produire un livrable se lit à travers trois use cases qui vivent chacun dans l’axe dont ils dépendent — A2.4 (mettre à jour en place), A3.2 (livrer au bon endroit), A5.4 (livrer à un tiers).

Le libellé est invariant : il ne mentionne jamais l’état d’un système, et ne se retouche pas pendant au moins quatre passes. Un jeu retouché ne mesure plus rien ; un jeu figé se périme lentement, ce qui est le moindre mal. Quand un use case entre au jeu ou est reformulé, il repart de « — » : la note obtenue sous un ancien libellé ne se reporte pas, et le compte des quatre passes court pour lui à partir de la première passe qui le joue. Le sous-score des use cases restés identiques se lit à part et garde sa série.

A1 — Ce qui entre sans que j’y pense

A1.1 — Un document reçu par un canal habituel se retrouve rangé au bon endroit et exploitable, sans que je le dépose moi-même.

• Observation : connecteurs actifs et ce qu’ils écrivent ; existence d’une règle de routage ; fichiers arrivés récemment sans geste humain identifiable.
• Question : « Quand tu as reçu un document important le mois dernier, qu’est-ce qui s’est passé entre sa réception et le moment où il a été utilisable ? » — laisser raconter, ne pas souffler la réponse.
• Mise en situation : demander à la personne de citer les trois derniers documents entrés, puis vérifier dans le dispositif où ils se trouvent.
• Piège : un moteur de recherche sur la messagerie n’est pas une entrée. Le document est cherchable, il n’est pas rangé. Note 1 au mieux si le document n’existe que dans le canal d’origine.

A1.2 — Un échange ou une décision à l’oral laisse une trace utilisable sans que j’ouvre une session pour la dicter.

• Observation : présence d’une chaîne de captation orale (transcription de réunions, dictée routée, notes vocales traitées) et de ce qu’elle produit en sortie.
• Question : « La dernière décision prise en réunion ou au téléphone — où est-elle écrite aujourd’hui, et qui l’y a mise ? »
• Piège : une transcription brute déposée dans un dossier n’est pas une trace utilisable. Le critère est l’exploitabilité sans relecture intégrale.

★ A1.3 — Une information qui arrive est rattachée à l’objet qu’elle concerne — le bien, le client, la personne, le dossier — et pas seulement déposée dans un flux cherchable.

• Observation : existe-t-il des objets de référence dans le dispositif (fiches, enregistrements, dossiers par entité) ? Les entrées récentes y sont-elles attachées ?
• Question : « Prends un client, un bien ou une personne que tu suis. Sans chercher, qu’est-ce que le système sait de lui, et d’où ça vient ? »
• Mise en situation : dans une session neuve, demander tout ce qui est connu d’une entité nommée, puis compter ce qui manque par rapport à ce que la personne sait.
• Piège : c’est le use case qui discrimine. Un moteur de recherche donne 1 partout. Le rattachement à l’objet est ce qui sépare archiver de capter. Ne donner 2 que si le rattachement se fait sans geste humain.

A2 — Ce qui devient une position plutôt qu’une pile

★ A2.1 — Sur un sujet où j’ai réfléchi plusieurs fois, un seul fichier porte la position en vigueur, et il conclut.

• Observation : chercher activement un sujet couvert par trois fichiers ou plus. Ouvrir chacun : lequel conclut ? Un en-tête désigne-t-il celui qui fait foi ?
• Question : « Cite-moi un sujet sur lequel tu es revenu au moins trois fois. Quel fichier porte ta position actuelle ? » Puis vérifier.
• Piège : la personne connaît la réponse — ce n’est pas ce qu’on mesure. Le test est : est-ce écrit quelque part que ce fichier fait foi ? Si la hiérarchie n’existe que dans sa tête, c’est 1.

A2.2 — Une position déjà écrite ressort telle quelle dans un contexte nouveau, sans être reconstruite.

• Observation : traces de réutilisation — un même passage repris à l’identique dans plusieurs livrables, des renvois entre fichiers.
• Question : « La dernière fois que tu as eu besoin d’une position que tu avais déjà formulée, tu l’as retrouvée ou tu l’as refaite ? »
• Piège : « refaite mais plus vite » n’est pas une réutilisation. C’est 1. La réutilisation, c’est le texte qui ressort, pas le raisonnement qui se rejoue.

★ A2.3 — Après une synthèse produite par un agent sur une matière que je maîtrise, les réserves et les conditions de validité ont survécu.

• Observation : rien. Ce use case se joue.
• Mise en situation : la personne choisit un sujet dont elle est experte et pour lequel un ou plusieurs fichiers existent. Une session neuve produit une synthèse. La personne liste ensuite ce qui a disparu — nuances, exceptions, conditions de validité, cas où la position ne tient pas.
• Piège : c’est le seul use case dont la réussite se lit dans une absence. On ne vérifie pas ce qui est présent — une synthèse fidèle en apparence peut avoir perdu toutes ses réserves. Si la personne dit « c’est bien résumé » sans avoir cherché ce qui manque, la mise en situation n’a pas eu lieu : noter « — ».

A2.4 — Une note vivante que je fais mettre à jour ressort réécrite en place, à l’état présent : elle continue de conclure, se lit sans connaître son historique, et ne porte aucun bloc « ce qui a changé ».

• Observation : rien. Ce use case se joue, sur une note dont on connaît l’état avant la demande.
• Mise en situation : dans une session neuve, demander la mise à jour de cette note. Relire le fichier entier, pas seulement l’ajout, et vérifier que la mise à jour est un delta : le reste du contenu n’a été ni régénéré ni reformulé.
• Piège : c’est le côté écriture d’A2.1 — A2.1 vérifie qu’un fichier conclut, A2.4 vérifie qu’il continue de conclure après qu’un agent l’a touché. Comme A2.3, sa réussite se lit dans une absence. L’historique d’une position se range ailleurs que dans la note.

A3 — Ce que je n’ai plus à redire ni à rechercher

★ A3.1 — À froid, sans que je pointe aucun fichier, le système répond « voici ce que tu as déjà écrit sur X » et désigne lequel fait foi.

• Mise en situation, en deux temps : (a) dans une session neuve, poser « ai-je déjà écrit sur X, et lequel fait foi ? » sans autoriser de recherche ; (b) reposer la même question en autorisant l’exploration. L’écart entre les deux réponses est la mesure utile : il dit si le manque relève de l’écriture ou de l’accès.
• Piège : localiser n’est pas hiérarchiser. Un système qui liste sept fichiers pertinents sans dire lequel fait foi est à 1, pas à 2 — et l’erreur de notation la plus fréquente est ici.

A3.2 — Un livrable demandé sans consigne d’emplacement ni de format atterrit au bon endroit, sous la bonne nomenclature, avec les conventions de mes outils, sans que j’aie à me réexpliquer.

• Observation : lire les fichiers d’instructions chargés automatiquement. Couvrent-ils les trois strates — sémantique (qui je suis), procédural (comment je veux que ce soit rendu), épisodique (ce que j’ai décidé et pourquoi) ?
• Mise en situation : demander un livrable réel sans dire où le ranger ni comment le nommer. Vérifier l’emplacement, la nomenclature et le format avant de lire le contenu.
• Piège : ce use case mesure la mémoire procédurale par ce qu’elle produit — un fichier, pas une réponse. Une réexplication demandée en cours de route (qui je suis, comment je veux le rendu) ramène la note à 1 au plus.

A3.3 — Une décision passée revient avec son pourquoi et ce qui a été écarté, pas seulement avec son résultat.

• Observation : existe-t-il un journal de décisions ? Ses entrées portent-elles les options écartées et le motif, ou seulement la conclusion ?
• Mise en situation : session neuve, « pourquoi ai-je décidé X, et qu’est-ce que j’avais envisagé d’autre ? » sur une décision de plus de trois mois.
• Piège : un résultat sans son raisonnement ne se réexamine pas, il se subit. Un journal qui liste des décisions sans leurs alternatives écartées est à 1.

A4 — Ce qui se produit sans que je le demande

★ A4.1 — Une règle ou un seuil que j’ai écrit se déclenche à date, sans que j’y pense.

• Observation : recenser les règles et seuils écrits dans le corpus, puis, pour chacun, identifier ce qui le déclenche. Le résultat le plus fréquent est : rien.
• Question : « Quelle est la dernière alerte que le système t’a envoyée sans que tu la demandes ? Quand ? »
• Piège : l’existence d’une automatisation ne prouve pas qu’elle tourne. Vérifier la dernière exécution réussie, pas la configuration. Un repli silencieux est plus dangereux qu’une panne : une boucle qui tourne mal ressemble à une boucle qui tourne.

A4.2 — Le système signale une tension entre une intention nouvelle et une décision déjà tenue, avant que j’agisse.

• Mise en situation : la personne énonce en session neuve une intention qui contredit une décision écrite dans le corpus. On observe si la contradiction est relevée spontanément.
• Piège : si l’agent relève la tension seulement après qu’on la lui a signalée, c’est 0 sur ce use case — l’axe porte sur ce qui se produit sans être demandé.

A4.3 — Une chaîne d’actions d’écriture s’exécute en une seule demande, avec un point de validation, et non un verrou par opération.

• Observation : droits d’écriture réels, mode de validation, existence de garde-fous.
• Piège : distinguer une capacité absente d’une capacité fermée volontairement. Une fonction bridée par une garantie qui fonctionne comme prévu se note selon ce qu’elle permet, et le commentaire précise que le bridage est intentionnel — sinon la passe suivante corrigera la mauvaise chose. Noter aussi que le verrou par opération est un antipattern : il rend l’usage si pénible qu’on finit par tout autoriser.

A5 — Ce sur quoi je peux agir sans vérifier

A5.1 — Ce qui vieillit porte une date de validité distincte de sa date d’écriture, et son franchissement se signale.

• Observation : ouvrir dix fichiers au hasard. Combien portent une date de validité — pas une date de mise à jour ? Qu’est-ce qui relit ces dates ?
• Piège : la date de mise à jour dit quand le fichier a été écrit, pas s’il est encore vrai. Les deux se confondent tant qu’on relit ce qu’on vient d’écrire ; elles divergent dès qu’une session neuve ouvre le fichier, et rien ne l’en avertit. Une date de mise à jour seule vaut 0 sur ce use case.

A5.2 — Deux fichiers qui se contredisent sont détectés sans audit manuel.

• Observation : chercher soi-même une contradiction dans le corpus — c’est presque toujours possible dès trois fichiers portant une même règle. Puis vérifier si quelque chose l’aurait signalée.
• Piège : « je m’en serais aperçu » n’est pas une détection. Et sur un corpus de quelques dizaines de milliers de tokens, le mode d’échec dominant n’est pas le volume, c’est la contradiction entre couches. Corollaire à mentionner dans le commentaire : une règle qui vaut pour plusieurs contextes doit vivre à un endroit.

★ A5.3 — Les entrées sont qualifiées : je sais ce qui vient d’une source maîtrisée, et rien de non qualifié n’atteint un substrat où le système écrit.

• Observation : cartographier les entrées. Pour chacune : source maîtrisée ou non ? écrit-elle dans un substrat relu par l’agent ? existe-t-il une frontière explicite ?
• Question : « Est-ce qu’un contenu venu de l’extérieur — un document reçu, une page web, un dépôt cloné — peut se retrouver dans ce que l’agent relit automatiquement ? »
• Piège : l’un des deux use cases à risque asymétrique, avec A5.4. Les autres coûtent du temps, celui-ci expose à un dommage persistant : un empoisonnement de mémoire survit aux sessions et son effet est découplé dans le temps de son introduction. À noter avant d’ouvrir toute automatisation d’entrée (A1), et voir le seuil dur du §6.

A5.4 — Un livrable destiné à quelqu’un qui n’atteint pas mon corpus est autoportant : les règles y sont écrites en clair et non citées par adresse, et rien n’y sort qui aurait dû rester dans le périmètre.

• Observation : rien. Ce use case se joue.
• Mise en situation : demander un document destiné à un tiers, sur un sujet dont le corpus porte à la fois de la matière qui peut sortir et de la matière qui ne le doit pas. Vérifier ce qui s’y trouve, pas seulement ce qui s’y lit bien.
• Piège : c’est la frontière de sortie, symétrique d’A5.3 qui garde l’entrée. Une adresse morte coûte du temps au lecteur, une donnée sortie du périmètre expose à un dommage : un livrable qui renvoie à un fichier que le lecteur ne peut pas ouvrir est à 1 au mieux ; une fuite de périmètre est à 0.

5. Contrôles anti-complaisance — règles de dégradation

À appliquer mécaniquement, avant de figer les notes. Elles existent parce que le juge est intéressé au résultat, et que l’agent qui note a lu la grille.

Une règle de posture, aussi. Si la personne cherche à négocier les notes plutôt qu’à comprendre les écarts, le dire une fois, calmement, et poursuivre. Le livrable qui plaît est celui qu’on ne relit pas.

6. Seuils — à lire après avoir noté, jamais avant

Ces seuils sont figés d’avance. Les fixer au vu des résultats revient à conclure ce qu’on avait envie de conclure.

Le seuil d’arrêt à 27/34 correspond à une moyenne d’environ 1,6 — l’équivalent de dix use cases à 2 et sept à 1. Il est remis à l’échelle au prorata du nombre de use cases, à moyenne constante, et non au vu des résultats. Il ne s’applique qu’une fois les dix-sept renseignés : un total élevé sur un panier partiel ne mesure rien.

Cadence recommandée. Trimestrielle sur les axes faibles, annuelle sur les axes forts. Rejeu immédiat des use cases concernés après toute réécriture d’un fichier chargé dans plusieurs contextes — c’est le seul moment où une régression est probable.

Pas de taxonomie prématurée. Attendre trois passes avant de classer les motifs d’échec. Avant, on classe du bruit.

7. Les deux compteurs de valeur, et la mesure d’hygiène

Les dix-sept use cases mesurent une capacité. Ils ne disent pas si le système sert. Vu l’écart documenté entre satisfaction déclarée et bénéfice mesuré, la mesure de valeur doit compter des événements, jamais recueillir une impression.

Si la personne n’a rien compté, ces compteurs se notent « non relevé ». L’agent ne les estime pas, et ne les remplace pas par une impression. Il propose le protocole de relevé pour la passe suivante.

Mesure d’hygiène — la charge de contexte. Combien d’octets et de fichiers entrent réellement dans une session, lesquels n’ont servi à rien, et quelle part échappe au contrôle du propriétaire. Elle ne se note pas : elle sert à décider si le sujet du volume existe.

Elle se relève par périmètre chargé, jamais en moyenne. C’est l’écart entre le plus léger et le plus lourd qui informe, pas le total : un dispositif homogène ne pose pas de question de volume, un dispositif où un périmètre en charge plusieurs fois les autres en pose une, et elle est locale. Une fusion de périmètres est le moment où cet écart se creuse sans que personne l’arbitre.

Un point de calibrage sur le volume, pour ne pas surinvestir : la dégradation par la longueur est réelle, confirmée et non résolue — sur la détection d’actions dangereuses évidentes, le rappel d’un modèle récent passe de 99,7 % à 100 K tokens à 69 % à 800 K tokens, avec le pire résultat quand l’élément à détecter est au milieu. Mais quelques dizaines de milliers de tokens chargés par session restent loin de tout seuil mesuré. Dans ce régime, le mode d’échec n’est pas le poids, c’est la contradiction — qui se produit dès trois fichiers.

8. Gabarit de restitution

L’agent rend exactement ces sept blocs, dans cet ordre. Pas de préambule, pas de félicitations.

1. En-tête de passe

Date · périmètre joué · régime de preuve retenu · modèle et version utilisés · durée réelle · numéro de passe.

Noter la version du modèle n’est pas cosmétique : une variation de score entre deux passes peut venir du modèle autant que du corpus.

2. Ce que l’agent a pu voir, et ce qu’il n’a pas pu voir

Deux listes explicites. La seconde est aussi importante que la première : elle donne au lecteur la fiabilité réelle du score.

3. Le tableau des dix-sept

Le commentaire sert à la passe suivante plus que la note. Il dit pourquoi cette note, pas ce qu’il faudrait faire.

4. Le score

Écrit sous la forme : n points sur 2 × k, k use cases renseignés sur 17, régime [express/standard/complet]. Jamais un pourcentage seul, jamais une note sur 20, jamais une comparaison à un autre système.

Détail par axe, avec la répartition des qualités de preuve : combien de [V], [J], [C], [D].

5. Les contradictions relevées

Ce que la personne a déclaré, ce que l’agent a observé, et ce qui n’a pas été réconcilié. Si aucune contradiction n’a été trouvée, le dire — et le traiter comme un signal suspect plutôt que comme un bon résultat, sauf en régime complet.

6. Trois chantiers, pas plus

Priorisés selon cette règle d’ordre, et pas selon l’appétence :

1. A5.3 à 0 passe avant tout le reste. Prérequis dur.
2. Ensuite, l’axe dont le défaut est indolore — A4 puis A5 — parce que rien ne viendra le signaler.
3. Ensuite, le use case discriminant le plus bas.

Chaque chantier porte : le use case visé, le geste minimal qui le ferait bouger d’un point, et le coût estimé. Un chantier dont le geste minimal n’est pas descriptible en deux phrases n’est pas un chantier, c’est un projet — le dire.

7. Ce qu’il ne faut pas construire

La partie que personne n’écrit et qui vaut le plus. Lister ce que la personne a évoqué comme envie d’outillage et qui, au vu des notes, n’est pas justifié — avec le motif. Le mode d’échec dominant sur ce type de dispositif est la sur-ingénierie avant preuve d’usage, et l’IA l’aggrave en abaissant fortement le coût de construction. Un axe noté correctement n’a pas besoin d’être outillé davantage.

9. Ce que ce protocole ne corrigera pas

Le juge est intéressé. Le biais de justification par l’effort est d’autant plus fort que l’effort a été grand. Le contexte propre, la règle « pas de note sans preuve » et les dégradations du §5 le réduisent. Rien ne le supprime.

Le modèle change sous le corpus. Une variation de score entre deux passes peut venir du corpus ou du modèle, et rien ici ne permet de les distinguer. Confondant irréductible ; d’où l’obligation de noter la version du modèle.

Un use case peut réussir pour la mauvaise raison. Un modèle compétent devine beaucoup. Le seul contrôle est le seuil « 0 à 2 sans écriture » : si la note monte sans que le corpus ait bougé, le système n’a pas appris, il a inféré.

Dix-sept use cases ne font pas une statistique. Ce protocole produit un point dans une série personnelle. Il ne classe pas, il ne certifie pas, et un score obtenu ici ne se compare pas à celui de quelqu’un d’autre.

La notation reste humaine, et c’est un choix. Construire un juge automatique fiable suppose, selon la pratique publiée, une centaine d’exemples étiquetés à la main et une mesure d’accord chance-corrigée — hors de proportion avec dix-sept use cases notés une fois par trimestre. Le protocole coûterait plus cher que la mesure. Il redevient pertinent si le jeu dépasse la cinquantaine de cas.

Trois chiffres qui circulent et qu’il ne faut pas reprendre, si la conversation les fait remonter : « 70 % des gens abandonnent leur second brain en un mois » — aucune source, aucune donnée publique sur l’abandon n’existe. Les benchmarks d’éditeurs de solutions de mémoire — auto-administrés, contestés entre eux, sans validation tierce publiée. Et les taux d’attaque à 95 % sur l’empoisonnement de mémoire — c’est un taux d’injection obtenu en conditions idéalisées, le taux de succès associé étant nettement plus bas, et l’efficacité baisse fortement quand des mémoires légitimes préexistent.