Idée principale
Le contexte qui absorbe les mails d'une copropriété commence par un fichier context.md et une phrase : agrège et découpe en thématiques. Ce niveau tient jusqu'à ce qu'on constate que l'état courant a effacé l'historique du chantier — et l'on ajoute un log chronologique. Il tient de nouveau jusqu'à ce que les homonymes et les doubles noms produisent des fiches en double — et l'on écrit des directives métier. Puis le fichier passe les mille lignes et la fenêtre du modèle s'y perd — on sort les directives, puis on découpe par thématique. Puis le vocabulaire technique se répète dans chaque fichier — on le centralise dans un glossary.md.
Chaque palier a donc une cause nommable, et cette cause est toujours une panne du niveau précédent, jamais une amélioration souhaitée dans l'abstrait. C'est ce qui distingue une montée en complexité d'un surengineering : la première répond à un besoin qui s'est manifesté, la seconde à une architecture qu'on trouvait belle. Le test est disponible avant chaque étage — quel problème concret, déjà rencontré, cet étage supprime-t-il ?
L'ordre qui en résulte n'est pas interchangeable non plus : on ne peut découper proprement par thématique qu'après avoir sorti les règles de traitement, sinon on ne sait pas ce qu'il faut recopier dans chaque morceau. Et à chaque palier, on dispose d'un système qui fonctionne — pas d'un chantier à moitié fini qui ne servira qu'une fois terminé.
Pourquoi c'est important
Cela renverse la manière d'aborder un système décrit par quelqu'un d'autre. Devant un modèle complet — dossiers, manifestes de chargement, notes atomiques reliées —, la lecture naturelle est celle d'un plan à installer ; la lecture utile est celle d'une trajectoire, dont on ne reprend que les étages dont on a déjà rencontré la panne.
Cela donne aussi un critère de décision pour les versions suivantes : on change de version parce que les besoins ont crû, et le constat d'un besoin qui n'a pas crû est une raison suffisante de rester où l'on est.
Nuances et limites
Certaines pannes sont prévisibles pour qui a déjà construit un système comparable, et attendre qu'elles surviennent coûte une migration qu'on aurait pu éviter. La règle protège du surengineering, pas de la naïveté.
Et toutes les pannes ne se manifestent pas comme un manque. La perte de précision d'un modèle sur un long fichier ne produit aucune alerte : elle dégrade lentement des réponses qui restent plausibles, et le palier suivant n'est franchi que si quelqu'un a nommé le mécanisme par avance.
Questions ouvertes
- Qu'est-ce qui, dans un système en place, indique qu'il ne suffit plus, quand la panne ne prend pas la forme d'une réponse manifestement fausse ?