Décisions architecturales et compromis : réversibilité et moment opportun

Tout est compromis

Tout choix architectural important achète quelque chose en renonçant à autre chose. Découper un système en services déployables indépendamment achète l’autonomie des équipes et une mise à l’échelle indépendante, et se paie en latence réseau, en complexité opérationnelle et en cohérence des données plus difficile. Le cache achète de la vitesse et se paie en données périmées et en logique d’invalidation. Une base de données managée dans le cloud libère des correctifs et des sauvegardes, et se paie en coût et en dépendance envers un seul fournisseur. Mark Richards et Neal Ford placent cette idée en tête de Fundamentals of Software Architecture (2020 ; deuxième édition 2025), comme leur première loi : Tout, en architecture logicielle, est un compromis. Ils en tirent un corollaire : si vous pensez avoir trouvé quelque chose qui n’est pas un compromis, c’est probablement que vous n’avez pas encore identifié le compromis.

Leur deuxième loi dit que le pourquoi est plus important que le comment. N’importe qui peut regarder un système en fonctionnement et voir comment il est construit : trois services, un courtier de messages (message broker), une base de données orientée documents. Ce que le code ne permet pas de retrouver, c’est le pourquoi : quelles alternatives ont été envisagées, quelles préoccupations l’ont emporté, quels risques ont été acceptés. Sans le pourquoi, les ingénieurs suivants soit conservent des choix qui n’ont plus de sens, soit défont des choix dont les raisons restent valables. La deuxième édition ajoute une troisième loi : la plupart des décisions architecturales ne sont pas binaires, mais se situent sur un continuum entre des extrêmes. Vous choisissez rarement entre « monolithe » et « microservices » ; vous choisissez combien d’unités déployables, découpées selon quelles lignes, partageant quoi.

Penser en compromis est l’habitude qui distingue le plus nettement la réflexion architecturale de l’enthousiasme. Quand quelqu’un propose une technologie, les questions utiles ne sont pas « est-ce bien ? » mais « que coûte-t-elle, que rend-elle plus difficile, et ces coûts sont-ils acceptables au regard de nos préoccupations ? ». La section précédente a montré d’où viennent ces préoccupations.

L’anatomie d’une décision

Une décision architecturale est plus que son résultat. Une décision que l’on peut expliquer, examiner et réexaminer comporte six parties, et les nommer est la première étape pour bien décider.

Contexte : les forces en présence. Le problème à résoudre, les exigences d’attributs de qualité qui s’y rapportent, les contraintes (budget, échéances, réglementations, systèmes existants, compétences de l’équipe) et les hypothèses retenues. Options : au moins deux alternatives réelles, y compris souvent « ne rien faire » ou « reporter ». Une décision pour laquelle une seule option a été envisagée est une annonce, pas une décision. Critères : la façon dont les options seront jugées, tirée des préoccupations des parties prenantes et pondérée selon leur importance. Décision et justification : l’option retenue et, surtout, la raison pour laquelle elle l’a emporté sur les autres au regard des critères. Conséquences : ce qui devient plus facile, ce qui devient plus difficile, quels nouveaux risques apparaissent et quelles options futures sont désormais fermées. Statut : proposée, acceptée, obsolète ou remplacée, avec qui a pris la décision et quand.

Les conséquences méritent une attention particulière, car c’est là que l’honnêteté est mise à l’épreuve. Toute option a des inconvénients ; les mettre par écrit protège l’équipe des surprises et donne à la personne qui prendra la décision suivante un compte rendu loyal. Les conséquences d’une décision font aussi partie du contexte de la suivante : une fois que vous avez choisi la messagerie asynchrone, vous devez décider comment traiter les messages en double et les messages qui arrivent dans le désordre.

Portes à sens unique et portes à double sens

La propriété la plus utile d’une décision, à elle seule, est sa réversibilité : le coût et la sûreté avec lesquels on peut la défaire. Dans sa lettre de 2015 aux actionnaires d’Amazon, Jeff Bezos distinguait les décisions de type 1, lourdes de conséquences et irréversibles ou presque (« portes à sens unique »), des décisions de type 2, modifiables et réversibles (« portes à double sens »). Les décisions de type 1 méritent une délibération lente et soigneuse, avec consultation. Les décisions de type 2 doivent être prises rapidement par des individus ou de petits groupes dotés d’un bon jugement, car si elles s’avèrent mauvaises, on peut repasser la porte dans l’autre sens. Il avertissait que les grandes organisations ont tendance à appliquer à tout le processus lourd du type 1, ce qui les rend lentes et frileuses.

L’idée se transpose directement à l’architecture. En logiciel, une porte à sens unique est une décision qui, pour être défaite, exigerait de réécrire de grandes parties du système, de migrer de grandes quantités de données, de renégocier des contrats ou de reformer de nombreuses personnes : le langage de programmation principal d’une vaste base de code, le modèle de données d’un système de référence, l’API publique avec laquelle des centaines de partenaires s’intègrent, un engagement cloud sur plusieurs années. Parmi les portes à double sens figurent le choix d’une bibliothèque de journalisation placée derrière votre propre interface, la structure interne d’un module, le réglage d’un cache, ou le choix entre deux formats de message équivalents à l’intérieur d’un service.

Deux mises en garde. D’abord, la réversibilité est un continuum, pas une alternative binaire : la plupart des décisions se situent quelque part entre « trivial à défaire » et « impossible à défaire », et le coût d’un retour en arrière augmente généralement à mesure que davantage de code, de données et de personnes dépendent du choix. Une décision qui est une porte à double sens le premier mois peut devenir une porte à sens unique au douzième. Ensuite, vous pouvez souvent changer le type de porte face auquel vous vous trouvez, par la conception, comme le montre plus loin la section sur la réversibilité.

Le moment : le dernier moment responsable

Quand faut-il prendre une décision ? Mary et Tom Poppendieck, dans Lean Software Development: An Agile Toolkit (2003), ont popularisé l’idée de décider au dernier moment responsable : le moment où ne pas décider éliminerait une alternative importante. Avant ce moment, vous décidez avec moins d’informations que vous ne pourriez en avoir ; après, la décision est prise à votre place, par défaut, et généralement mal.

Le principe vaut dans les deux sens. Il plaide contre une décision trop précoce : figer la technologie de base de données la première semaine, avant de comprendre la forme des données et les schémas d’accès, revient à deviner. Il plaide tout autant contre une décision trop tardive. Si l’équipe a commencé à écrire du code de persistance en s’appuyant sur une hypothèse jamais formulée, la décision a déjà été prise, simplement pas consciemment. Si le service achats a besoin de six semaines pour approuver un fournisseur cloud, le dernier moment responsable pour ce choix se situe au moins six semaines avant que vous ayez besoin de l’environnement.

Les praticiens ne s’accordent pas sur la limite à ne pas franchir. Les critiques font valoir que le « dernier moment responsable » sert facilement de prétexte à la procrastination, que certaines décisions (structure des équipes, langage de programmation) façonnent tout ce qui suit et doivent donc être prises tôt, et que l’indécision a son propre coût : les équipes ne peuvent pas travailler en parallèle sans interfaces convenues. Les partisans répondent que le principe n’a jamais voulu dire « le plus tard possible » mais « aussi tard que c’est responsable », et qu’identifier ce moment est en soi un acte de planification. Les deux positions s’accordent sur le noyau pratique : sachez quelles décisions sont en attente, sachez quand chacune doit être prise, et utilisez le temps qui reste pour apprendre.

Concevoir pour la réversibilité

La façon la moins coûteuse de prendre une décision difficile est souvent de la transformer en une décision plus facile. Plusieurs techniques réduisent le coût d’un changement d’avis ultérieur, au prix d’un certain effort aujourd’hui.

L’abstraction à la frontière. Placez une interface étroite qui vous appartient entre votre logique centrale et une technologie que vous pourriez remplacer, comme un prestataire de paiement, un courtier de messages ou l’API d’un grand modèle de langage. Remplacer la technologie plus tard ne touchera alors qu’un adaptateur, et non toute la base de code. L’idée remonte au masquage de l’information (information hiding) de David Parnas (1972) et réapparaît dans l’architecture hexagonale (chapitre 5). Les feature flags (indicateurs de fonctionnalité). Livrez le nouveau comportement désactivé, activez-le pour une petite part des utilisateurs, et désactivez-le de nouveau en quelques secondes s’il se comporte mal ; les mises en production deviennent ainsi des portes à double sens. La migration incrémentale. Faites tourner l’ancien et le nouveau côte à côte et basculez le trafic progressivement plutôt qu’en une seule étape. Les spikes et les preuves de concept. Passez quelques jours à construire la partie la plus risquée avec une technologie candidate avant de vous y engager. Les sorties contractuelles. Préférez des engagements plus courts, des formats de données standard et la possibilité d’exporter vos données.

C’est le raisonnement en options, emprunté à la finance : vous payez une petite prime aujourd’hui (un adaptateur, un flag, un spike) pour acheter le droit, mais pas l’obligation, de changer de cap plus tard. Comme toute option, elle ne vaut la peine d’être achetée que si la prime est faible par rapport à la valeur de la flexibilité. Envelopper chaque bibliothèque dans une abstraction « au cas où nous la changerions » est une façon classique d’ajouter du coût et de l’indirection pour une flexibilité dont personne ne se sert. Achetez des options sur les décisions à la fois incertaines et coûteuses à inverser ; pour tout le reste, décidez et passez à la suite.

Les pièges cognitifs

Les architectes sont humains, et les décisions architecturales se prennent dans l’incertitude, sous la pression du temps et sous la pression sociale : des conditions idéales pour les biais cognitifs. Connaître les plus courants par leur nom permet de mieux les repérer chez soi et de les contester avec bienveillance chez les autres.

Consigner les décisions : un aperçu des ADR

La deuxième loi dit que le pourquoi compte plus que le comment ; le pourquoi doit donc être mis par écrit. Le format léger le plus utilisé est l’enregistrement de décision d’architecture (ADR), proposé par Michael Nygard dans un billet de blog de 2011. Un ADR est un court fichier texte, conservé avec le code dans la gestion de versions, qui consigne une décision selon l’anatomie décrite plus haut : titre, statut, contexte, décision et conséquences. Les ADR ne sont jamais modifiés pour réécrire l’histoire ; une décision ultérieure remplace une décision antérieure et y renvoie, de sorte que le journal raconte comment l’architecture a évolué.

Le chapitre 4 présente les modèles, les outils et les habitudes qui gardent les ADR utiles, dans Enregistrements de décision d’architecture (ADR). L’exemple ci-dessous consigne la décision de l’exemple commenté.

ADR 7: Use managed PostgreSQL for the order service

Status: Accepted (2026-10-12)

Context
Orders and payments need multi-row transactions and must never be lost.
The team knows PostgreSQL well and has no database administrator.
Expected growth is about 3x in two years.

Decision
We will use the cloud provider's managed PostgreSQL service.

Consequences
+ Backups, patching and failover are handled by the provider.
+ Standard SQL keeps self-hosting or another provider open as a fallback.
- Monthly cost is about 30% higher than self-hosting at current load.
- Maintenance windows are set by the provider.
Revisit if write volume exceeds what one primary instance can handle.