Escaliers vers nulle part : pourquoi les plans sont plus importants que jamais avec l'IA

Escaliers vers nulle part : pourquoi les plans sont plus importants que jamais avec l'IA

Trop de logiciels aujourd'hui sont construits comme la Winchester Mystery House : des pièces ajoutées une à une, des escaliers menant nulle part. Cette maison mystérieuse n'est pas hantée par des fantômes, mais par la question de savoir pourquoi quelqu'un construirait ainsi.

La maison n'a pas été conçue pour que vous y viviez. Elle a été construite pour une personne, et cela fonctionnait pour elle. Mais en la parcourant aujourd'hui, on ressent la différence entre un espace conçu pour son propriétaire et un espace conçu pour d'autres.

Une des escaliers de la Winchester Mystery House — construit sans plan, menant nulle part. © Getty Images (515427836)

On a l'impression d'être dans une maison de carnaval. En réalité, c'est un manoir à San José, au cœur de la Silicon Valley. La Winchester Mystery House a été construite continuellement pendant trente-huit ans par son propriétaire, Sarah Winchester, sans plan directeur. Pièce après pièce ajoutée sans se soucier de la façon dont les gens se déplaceraient à travers elles. Aujourd'hui, c'est une attraction touristique. Les gens paient pour vivre cette désorientation.

Elle a appris l'architecture à partir de journaux : une amateur avec des ressources extraordinaires, responsable uniquement d'elle-même. Quand un couloir était mal conçu, elle le détruisait. Quand elle voulait une pièce, elle l'ajoutait, qu'elle soit connectée à quelque chose ou non. Des escaliers montent vers les plafonds. Des portes s'ouvrent sur des murs. La dysfonction n'avait pas d'importance car elle était la seule utilisatrice.

Les équipes de développement logiciel construisent des maisons comme celle-ci chaque jour.

Cela se produit lorsque les équipes travaillent en silos — chacune optimisant son propre plan, sa propre définition de ce qui est terminé, son propre lancement. Chaque pièce fonctionne. Le parcours entre elles se brise.

Il y a plus de trente ans, Mitch Kapor a nommé ce problème. Kapor avait fondé Lotus et créé Lotus 1–2–3, le tableur qui a transformé le PC en outil professionnel. Il n'était pas un outsider critiquant l'industrie ; il était quelqu'un qui avait construit des logiciels massivement réussis en disant que nous faisions cela de manière incorrecte.

Son « Manifeste de conception logicielle » soutenait que le logiciel avait besoin d'un rôle similaire à celui de l'architecte, quelqu'un qui se demande comment les gens se déplaceront à travers ce que vous construisez avant le début de la construction.

J'ai découvert le manifeste dans le livre de Terry Winograd, Bringing Design to Software, un titre qui faisait l'argument avant même d'ouvrir la couverture. Cela a donné une voix à un parcours que j'étais déjà en train de suivre. J'avais été formé comme architecte et j'avais évolué vers le logiciel avant que le web ne devienne courant. Le besoin était le même, l'échelle était mondiale. Kapor nommait le rôle de l'intérieur de l'industrie.

Son raisonnement était simple : lorsque vous concevez une maison, vous parlez à un architecte avant de parler à un ingénieur. Pas parce que les ingénieurs ne sont pas essentiels, ils le sont, mais parce que les premières questions ne sont pas structurelles. Elles concernent la façon dont les gens vivront. Où la cuisine devrait-elle être par rapport à la salle à manger ? Cela émerge de la compréhension des objectifs humains, et non des contraintes techniques. Le logiciel, soutenait Kapor, avait complètement sauté cette étape.

« L'une des principales raisons pour lesquelles la plupart des logiciels informatiques sont si abominables est qu'ils ne sont pas du tout conçus, mais simplement ingénierés. » — Mitch Kapor

Il y a deux mille ans, l'architecte romain Vitruve soutenait que les bonnes constructions présentent trois qualités : firmitas, utilitas, venustas. Elles sont construites pour durer, elles répondent aux besoins et elles récompensent l'expérience d'y être. Kapor voyait le même test pour le logiciel.

Trois décennies plus tard, l'argument de Kapor semble moins un manifeste qu'un principe intemporel, un principe qui devient encore plus critique dans un monde agentique.

C'est pourquoi « comment les gens se déplacent à travers ce que nous construisons » n'est pas une préférence de conception. C'est la fondation.

Un plan n'est pas une spécification. C'est une vue partagée de la manière dont les gens se déplaceront à travers ce que vous construisez : comment cette fonctionnalité se connecte à la suivante, ce qui se passe après qu'une personne a terminé une tâche, où elle va quand quelque chose ne va pas. Cela garde l'équipe orientée vers la personne à l'autre bout, et non seulement vers le produit en cours de développement.

Et comme tout plan, il doit aller plus loin que les pièces : l'architecture des permissions, les limites de données, les modes de défaillance, l'infrastructure de confiance qui soutient tout.

Les personnes à l'intérieur du bâtiment dépendent de cette infrastructure qu'elles sachent ou non qu'elle est là. Elles ne voient pas les fondations. Elles font simplement confiance au fait que le sol ne s'effondrera pas.

Nous avons trop souvent vu ce qui se passe lorsque cette couche est supposée plutôt que conçue. Les violations de données ne sont pas des échecs de surface. Ce sont des échecs architecturaux — quelque chose qui aurait dû être dans le plan ne l'était pas.

Dans un monde agentique, où les systèmes agissent au nom des gens et ont accès à leurs comptes, fichiers et finances,