Pourquoi « boring »

Chaque pièce de ce site est une instance d'une seule affirmation :

Le levier se compose quand les règles sont explicites et que leur application est structurelle. Il se dégrade quand les règles sont implicites et que leur application repose sur l'attention d'une seule personne.

Quinze ans entre business, product et engineering — plateformes en production, petites équipes, contraintes dures — produisent toujours la même observation. Les systèmes qui ont survécu n'étaient jamais les plus malins. C'étaient ceux dont les règles étaient écrites, dont les frontières tenaient par la structure — un hook de pre-commit, un registre typé, une frontière architecturale — et où la vigilance d'une seule personne ne portait jamais la charge.

« Boring », c'est cette propriété. Un système boring est un système dont le comportement se prédit parce que ses règles sont visibles. L'excitation en production, c'est la facture des règles restées dans la tête de quelqu'un.

L'IA monte les enjeux des deux côtés. Les agents amplifient la discipline en place, quelle qu'elle soit : règles explicites et application structurelle, et les agents composent votre levier ; règles implicites et vigilance personnelle, et les agents composent votre chaos — plus vite qu'aucune équipe humaine. C'est pourquoi la barre ici est la même pour les ingénieurs et pour l'IA, pas deux barres.

Les quatre lanes du site, c'est la même affirmation sous quatre angles :

• Work : l'affirmation appliquée à des systèmes en production — frontières auth démêlées, sortie de vendor lock-in, adoption de l'IA sur une plateforme live. La preuve, contraintes incluses.
• Writing : les guides de décision qu'elle produit — quelles règles expliciter, où placer les frontières, quoi faire respecter par la structure.
• Building : la forme exécutable — le harness d'agents, les hooks, les skills. L'affirmation qui tourne en live, versionnée dans git.
• Archive : la couche doctrine — les playbooks qui changent le plus lentement parce qu'ils dépendent des gens, pas des stacks.

Le site tourne sur sa propre thèse. Les règles sont versionnées, l'application vit dans les hooks de pre-commit, et chaque article passe les mêmes gates structurels que le code. Là où l'affirmation est fausse, c'est dans les études de cas que ça se verra en premier.