Angle
Chaque étage du contexte qui absorbe cinq cents mails de copropriété a été ajouté par une panne datée du niveau précédent : le journal chronologique parce que l'agrégation avait effacé les dates du chantier, le fichier de directives parce que les règles de traitement étouffaient sous la matière, le découpage en quinze fichiers thématiques parce que le context.md avait passé les mille lignes, le glossaire parce que le même vocabulaire technique se répétait partout. L'architecture finale — directives, glossaire, index, fichiers thématiques — se lit donc comme la liste des pannes rencontrées, dans leur ordre d'apparition ; et comme cette liste est ce qui manque à quiconque la reprend d'ailleurs, un système copié sur sa forme ne rend que la structure de celui qui l'a subie, en laissant intactes les pannes qu'on n'a pas encore rencontrées.
Synthèse
Les quatre pannes de la série n'ont rien en commun quant à leur cause. L'une est un effacement volontaire qui ne produit aucune erreur — une fiche exacte, simplement amnésique. Une autre est un désaccord d'organisation, où la machine a bien travaillé et où ce qu'elle rend n'est la structure de personne qui aura à s'en servir. Une troisième est un effet de volume qui se retourne contre le modèle lui-même. La dernière est une redondance de vocabulaire. Ce qui les réunit tient à une seule chose : aucune n'était visible depuis le palier précédent, et chacune n'a été nommable qu'après avoir été subie.
De là suit l'ordre, qui n'est pas interchangeable : on ne découpe proprement par thématique qu'après avoir sorti les règles du fichier, faute de quoi on ignore ce qu'il faut recopier dans chaque morceau. Et de là suit le statut singulier du premier palier — il ne produit pas un système, il produit l'inventaire des pannes à venir, ce qui rend son remplacement normal plutôt que coûteux, et ce qui explique qu'on ne puisse pas emprunter cet inventaire à quelqu'un d'autre : une architecture achevée ne montre que ses réponses.
Reste la condition qui autorise toute la démarche, et qu'aucun de ces paliers n'énonce. Réparer après la panne suppose que la panne se paie en détour et non en perte — l'historique manquant se retrouve dans les mails bruts conservés à côté, un prestataire mal rattaché se corrige en rouvrant un message. Sur une matière où l'erreur ne se rattrape pas, la construction par pannes successives cesse d'être une méthode et devient une prise de risque.
Tensions / contradictions
Deux consignes de la même série ne tirent pas dans le même sens. L'une dit de ne franchir un palier que lorsque le précédent ne suffit plus ; l'autre dit que la première version est faite pour être jetée. Réparer par petits pas et repartir de zéro sont deux gestes différents, et rien ne dit à quel moment l'un cesse d'être le bon.
Autre tension, entre le principe et la pratique de celui qui l'énonce : il recommande de partir d'un fichier et d'avancer par pannes, tout en tenant un système de contextes complet — dossiers, manifestes de chargement, notes reliées — dont il est déjà à la troisième version. Le conseil s'adresse à qui commence ; il ne décrit pas la position de celui qui le donne.
Questions
- Un système hérité — repris d'un collègue, d'un modèle public — peut-il produire ses propres pannes assez vite pour qu'on les comprenne, ou faut-il l'avoir construit soi-même pour les voir ?
- Combien de paliers une équipe peut-elle franchir ensemble, quand la panne n'est ressentie que par la personne qui traite la matière ?
- Que devient un étage dont la panne d'origine a disparu — le seuil qui l'a motivé ayant changé — et que personne ne pense à démonter ?