<aside> 📜

Comment un projet piloté par un non-développeur tient debout : pas par la confiance, par des règles écrites, datées, vérifiées par des scripts. Ce chapitre raconte comment elles sont nées ; presque toutes viennent d'un incident réel. Premier jet posé le 14 août 2026 ; relu le 15 août 2026.

</aside>

Au début, il n'y avait qu'un fichier de consignes que chaque session d'IA lisait en démarrant. Puis les incidents sont arrivés, et chaque incident a laissé une règle. Six semaines plus tard, le projet a une constitution : des registres de clauses numérotées, un protocole de clôture, un rituel de reprise, et des scripts qui vérifient que personne, humain ou IA, ne réécrit l'histoire.

Chaque règle est née d'une blessure

Aucune de ces règles n'a été écrite par anticipation. Elles portent toutes la date et le nom de l'incident qui les a rendues nécessaires.

<aside> ⚖️

Le garde-fou n°1 (29 juillet, session SOSPOLISH) : une session cite une décision passée comme précédent favorable, sans sa clause restrictive « ne pas toucher ces deux écrans » ; le diff portait précisément sur ces deux écrans. Stoppée avant tout commit. La règle, depuis : un précédent lu partiellement vaut absence de précédent.

</aside>

Une mémoire qui refuse d'être réécrite

Le cœur du système : les décisions sont append-only. On n'édite jamais une règle en place ; on écrit un amendement daté qui cite l'original. Un chiffre périmé se date ; une consigne périmée se remplace. Et ce n'est pas une préférence de style : des scripts vérifient l'empreinte cryptographique de chaque clause, et refusent le commit si une seule a changé en silence.

La mémoire déborde, et c'est un chantier en soi

Le fichier de règles a un plafond de taille : au-delà, les sessions ne le lisent plus vraiment. Il a fallu le scinder quatre fois en deux semaines, à chaque fois en déplaçant les clauses caractère pour caractère, jamais en les résumant.

Ce que le système ne couvre pas

L'honnêteté oblige : ce filet a des trous, et ils sont documentés au même endroit que le reste. Un grep par nom de fichier ne trouve rien pour un fichier qui n'existe pas encore ; un plancher de contrôle en retard ne voit pas une perte ; un script de preuve peut rendre le vert le plus rassurant sans avoir rien vérifié. Les registres portent donc, en tête, des déclencheurs de lecture par type de travail plutôt que par nom de fichier ; et le chapitre 4 raconte les fois où les contrôles eux-mêmes se sont trompés.

<aside> 📚

Sources : le fichier de règles du projet (CLAUDE.md) et ses registres (sécurité, zéro honte, couleur), journal des sessions, entrées de consolidation. Citations verbatim des archives ; 40 fragments collectés pour ce chapitre le 14 août 2026.

</aside>