La cathédrale, le bazar et la Winchester Mystery House — le troisième modèle du développement logiciel à l’ère de l’IA

The Cathedral, the Bazaar, and the Winchester Mystery House

Publié en 1998 par Eric Raymond, La cathédrale et le bazar est un texte fondateur du mouvement open source. En opposant le modèle de la « cathédrale », fermé et contrôlé, à celui du « bazar », ouvert et distribué, ce texte annonçait une évolution où le modèle du bazar allait dominer toute une génération, à mesure qu’Internet faisait baisser le coût de la collaboration sur le code. Mais avec l’arrivée des agents de codage IA, c’est désormais le coût même de production du code qui chute brutalement. L’auteur Drew Breunig estime donc qu’un troisième modèle est apparu : la « Winchester Mystery House ». Cette demeure bien réelle de San José, construction étrange et gigantesque agrandie toute sa vie par Sarah Winchester grâce à des moyens illimités et à une passion personnelle, sert ici de métaphore pour décrire la manière dont les développeurs d’aujourd’hui, accompagnés par l’IA, continuent à bâtir indéfiniment leurs propres outils sur mesure.

Points clés

• Trois modèles de développement logiciel : la cathédrale (planification fermée), le bazar (collaboration ouverte), et le nouveau venu, la Winchester Mystery House (extensions personnalisées et cumulatives à l’échelle individuelle).
• Le prix du code s’est effondré : selon les données citées dans l’article, Claude Code produit environ 1 000 lignes nettes de code supplémentaires par commit. L’auteur explique que cela représente un ordre de grandeur à deux chiffres au-dessus de ce qu’un développeur humain écrit en une journée (environ 10 à 30 lignes, d’après Le Mythe du mois-homme de Brooks).
• Le coût du feedback ne baisse pas : si le coût de l’implémentation s’effondre, le rythme des tâches humaines comme la revue, la discussion ou les tests ne change pas, ce qui déplace le goulot d’étranglement.
• Le style de développement « Mystery House » : l’auteur cite Steve Yegge avec Gas Town, Jeffrey Emanuel avec Agent Flywheel et FrankenSuite, ainsi que Gary Tan avec gstack, pour montrer la montée de grands outils privés construits avant tout pour leur propre auteur.

Caractéristiques

• Idiosyncratique : comme les développeurs bouclent directement avec des agents de codage selon leurs goûts et leurs besoins, on se retrouve souvent avec des structures difficiles à déchiffrer pour les autres et peu ou pas de documentation.
• Tentaculaire : le coût d’ajout de code étant pratiquement tombé à zéro, la tendance n’est plus à couper, mais à empiler encore et encore. Les correctifs sont appliqués sur place et les éléments inutilisés restent en l’état.
• Amusant : puisque les agents transforment chaque tâche en quête secondaire, peaufiner son propre workflow devient un hobby en soi.

En quoi cela diffère du bazar

• Structure de la boucle de feedback : le bazar s’appuie sur le regard de nombreuses personnes (throughput élevé, latency importante), tandis que la Mystery House compresse la boucle autour d’un seul développeur : la latence devient proche de zéro, mais le champ de vision se réduit à une seule personne.
• Conflit avec l’infrastructure partagée : l’article mentionne des cas où le grand volume de PR généré par des agents paralyse la capacité de revue de projets comme curl. curl a mis fin à son bug bounty, et GitHub a ajouté une option pour bloquer les contributions par PR.

Les leçons proposées par l’auteur

• Une coexistence possible : à l’image d’OpenClaw, il estime que le bazar et la Mystery House peuvent coexister si la communauté gère un noyau commun pendant que les utilisateurs prennent en charge les extensions individuelles.
• Ne pas vendre la “partie amusante” : les opportunités pour les outils et services ne se trouvent pas dans ce que les développeurs veulent construire eux-mêmes, mais dans des domaines comme la sécurité, l’infrastructure ou la plomberie — des zones qu’ils ne veulent pas assumer et où le coût de l’échec est élevé.
• La ressource désormais rare, c’est l’« attention » : maintenant que le code puis les coûts de coordination sont devenus bon marché, le prochain enjeu consiste, selon lui, à créer des outils et des pratiques capables de faire émerger les bonnes idées au milieu du flot de contributions.

Au fond, l’argument de l’auteur se ramène à une seule question. Si Internet a réduit le coût de la collaboration et ouvert l’ère du bazar, et si les agents de codage ont réduit le coût de l’implémentation et ouvert l’ère de la Mystery House, alors ce dont nous avons besoin désormais, ce sont des outils qui réduisent le coût de l’« attention ». À défaut, prévient l’article en conclusion, l’écosystème open source deviendra de plus en plus bruyant sans devenir plus intelligent, et les bonnes idées enfouies dans les Mystery Houses de chacun risqueront de disparaître dès que leur maintenance s’arrêtera.

[superdorai]

Je me reconnais tellement là-dedans, haha. Je laisse aussi ma mystery house. C’est un harness ultra-sécurisé pour les non-développeurs.

https://github.com/lbk0523/samantha

[youknowone]

Moi aussi, je suis en train d’empiler une Winchester Mystery House. Mon objectif est de sortir d’ici la fin de l’année un PyPy écrit en Rust.

https://github.com/youknowone/pyre/

[youknowone]

Pas la cathédrale et le bazar, mais https://ko.wikipedia.org/wiki/Seongdanggwa_sijang