L'architecture de la conviction : pourquoi les décisions techniques sont vraiment des choix de valeurs

Chaque système que vous construisez encode vos croyances sur ce qui compte. Ce n'est pas une métaphore. C'est une description littérale de ce qui se passe quand vous choisissez Postgres plutôt que DynamoDB, le monolithe plutôt que les microservices, la cohérence plutôt que la disponibilité.

Après trois ans de conception de systèmes distribués à grande échelle, j'en suis venu à voir que les choix architecturaux les plus difficiles ne sont jamais purement techniques. Ce sont des reflets de ce que vous valorisez : la cohérence plutôt que la disponibilité, la simplicité plutôt que la flexibilité, la vitesse plutôt que la sécurité.

L'illusion de l'objectivité

Nous aimons croire que les décisions techniques sont rationnelles. Nous dessinons des diagrammes. Nous lançons des benchmarks. Nous écrivons des RFC avec des sections intitulées "Alternatives envisagées". Mais si vous y prêtez attention, vous remarquerez que la conclusion était souvent décidée avant que le document ne soit rédigé. La RFC n'est pas un processus de découverte ; c'est un processus de justification.

Ce n'est pas de la malhonnêteté. C'est la nature humaine. Nous avons des intuitions façonnées par l'expérience, et ces intuitions sont en réalité des valeurs déguisées.

Quand un ingénieur senior dit "on devrait garder ça simple", il ne fait pas une affirmation technique. Il fait une affirmation de valeurs : la simplicité compte plus que la couverture fonctionnelle. Quand un autre ingénieur dit "on doit gérer tous les cas limites", il fait aussi une affirmation de valeurs : la correction compte plus que la vitesse de livraison.

Aucun des deux n'a tort. Mais ils n'ont pas un désaccord technique. Ils ont un désaccord de valeurs habillé en langage technique.

Ce que j'ai appris d'une migration de base de données

L'année dernière, mon équipe a migré d'un store de documents NoSQL vers Postgres. Les raisons techniques étaient solides : nous avions besoin de jointures, de transactions, d'un schéma qui attraperait les bugs avant la production.

Mais la vraie raison était un changement de valeurs. Nous avions passé deux ans dans une culture du "avance vite, on verra plus tard". Le store de documents était parfait pour ça : jette n'importe quelle forme de données dedans, ne te soucie jamais de la structure. Mais à mesure que le système grandissait, "on verra plus tard" est devenu "on verra à 3h du matin quand l'alerte d'astreinte te réveille".

La migration vers Postgres n'était pas juste un changement de base de données. C'était une déclaration : nous valorisons désormais la prévisibilité plutôt que la vélocité. Nous croyons désormais que ralentir pour définir notre modèle de données nous fera gagner plus de temps que ça n'en coûte.

La technologie, c'était la partie facile. La partie difficile, c'était d'admettre que nos valeurs avaient changé.

Trois questions que je pose maintenant

Avant chaque décision architecturale, je pose trois questions :

1. Qu'est-ce que ce choix optimise, et qu'est-ce qu'il sacrifie ?
2. Ferais-je le même choix si l'équipe était deux fois plus grande ? Deux fois plus petite ?
3. Est-ce que je choisis ceci parce que c'est juste pour le système, ou parce que ça m'est familier ?

La troisième question est la plus difficile. La familiarité est le biais le plus puissant en ingénierie. Nous tendons la main vers les outils que nous connaissons, puis nous construisons des arguments pour expliquer pourquoi ces outils se trouvent être le meilleur choix pour ce problème particulier.

L'honnêteté des contraintes

Il y a une forme d'honnêteté dans les contraintes. Quand vous choisissez un monolithe, vous dites : nous ne connaissons pas encore assez bien les frontières de notre domaine pour découper ce système. C'est une affirmation honnête. Quand vous choisissez les microservices dès le premier jour, vous dites : nous comprenons déjà parfaitement notre domaine. C'est presque toujours un mensonge.

Les meilleures architectures que j'ai vues sont celles où les contraintes correspondent aux connaissances réelles de l'équipe. Elles ne prétendent pas savoir plus qu'elles ne savent. Elles laissent de la place pour apprendre.

Ce que cela signifie pour le travail

Je ne plaide pas contre l'analyse technique. Les benchmarks comptent. La documentation des compromis compte. Mais je plaide pour que nous soyons honnêtes sur la couche sous l'analyse : les valeurs qui façonnent quels compromis nous trouvons acceptables.

Quand vous êtes en désaccord avec un collègue sur l'architecture, essayez ceci : au lieu de débattre des mérites techniques, essayez d'énoncer vos valeurs explicitement. "Je valorise la simplicité plutôt que l'exhaustivité." "Je valorise la sûreté de typage plutôt que la vitesse de développement." "Je valorise la stabilité opérationnelle plutôt que la vélocité fonctionnelle."

Vous découvrirez peut-être que le désaccord technique se dissout une fois les valeurs sur la table. Ou vous découvrirez peut-être que le désaccord est réel et fondamental, et ça vaut la peine de le savoir aussi.

L'architecture reflétera vos valeurs que vous les énonciez ou non. Autant être explicite.