De Zéro à 1 appliqué à l'architecture

L’optimisme défini contre l’optimisme indéfini

Il y a une distinction que Thiel fait entre deux formes d’optimisme. L’optimisme indéfini croit que l’avenir sera meilleur, mais sans plan précis pour l’atteindre. L’optimisme défini croit que l’avenir sera meilleur parce qu’on a un plan concret et qu’on va l’exécuter.

La différence entre les deux tient à deux notions que Thiel considère indissociables : la vision et la planification. La vision, c’est savoir précisément ce que ton système doit être dans trois ans, pas de façon vague (“scalable et maintenable”) mais de façon opérationnelle : quels usages il doit supporter, quelles contraintes il doit absorber, quelle propriété il doit avoir que les solutions concurrentes n’ont pas. Sans cette vision, chaque décision technique est prise par défaut, pas par choix. La planification, c’est la traduction de cette vision en séquence de décisions concrètes, chacune justifiée par ce qu’elle permet d’atteindre, et mesurée par des indicateurs définis avant d’agir.

L’architecture par défaut est souvent un optimisme indéfini. On adopte des patterns populaires en espérant que ça se passera bien. On ajoute des couches d’abstraction en anticipant des besoins futurs hypothétiques. On diversifie les technologies dans l’espoir de couvrir un maximum de bases. À ne pas confondre avec le principe de Martin : reporter une décision technique, c’est refuser de choisir tant qu’on n’a pas assez d’information. Abstraire prématurément, c’est au contraire décider trop tôt, en faveur d’une généricité que rien ne justifie encore. L’un préserve les options. L’autre les fige sous couvert de flexibilité.

L’optimisme défini en architecture, c’est savoir pourquoi tu fais ce choix maintenant, quelle contrainte précise il résout, comment tu mesureras que ça fonctionne, et ce que tu feras si ce n’est pas le cas. C’est avoir une conviction technique fondée sur une analyse de ton contexte, pas sur l’agrégation de ce que les autres font.

Cette conviction se nourrit de la connaissance intime de ton système. Des données de performance réelles, pas des benchmarks synthétiques. Du comportement de tes utilisateurs en production, pas de personas théoriques. Des contraintes d’équipe effectives, pas des org charts idéaux.