L’architecture tout au long du cycle de vie : en amont, émergente et continue

Le vieux débat : en amont ou émergente ?

Pendant la majeure partie de l’histoire du logiciel, l’architecture était quelque chose que l’on faisait au début. Dans un processus séquentiel (« en cascade »), on recueillait les exigences, puis on produisait et faisait approuver une architecture et une conception détaillée, puis on construisait le système selon cette conception. C’est la conception complète en amont (big design up front) (BDUF). Sa logique est solide dans certains contextes : lorsque les exigences sont stables et bien comprises, lorsque les changements après livraison coûtent extrêmement cher (logiciels de vol, dispositifs médicaux, systèmes liés au matériel), ou lorsque de nombreux prestataires doivent construire des parties qui s’emboîtent, une conception approfondie avant la construction réduit le risque.

Ses faiblesses sont tout aussi connues. Les exigences changent, et une conception élaborée tôt encode des hypothèses qui se révèlent fausses par la suite. Les retours de l’usage réel n’arrivent qu’à la fin, quand le changement coûte le plus cher. Les équipes conçoivent pour des besoins imaginaires (« nous pourrions avoir besoin de gérer cinq devises ») et paient pour une flexibilité que personne n’utilise. Et les documents dont l’approbation a pris des mois tendent à être suivis alors qu’ils ont cessé d’être vrais.

Les méthodes agiles ont réagi contre cela. L’Extreme Programming, en particulier, a plaidé pour la conception émergente : construire la chose la plus simple qui fonctionne pour les fonctionnalités en cours, garder le code propre grâce à une refactorisation continue et à des tests automatisés, et laisser la conception grandir avec le système. Les règles de conception simple de Kent Beck et le principe « you aren’t gonna need it » (YAGNI) expriment la même idée. La conception émergente fonctionne bien à l’intérieur d’un module, et pour les petits systèmes où chaque décision est une porte à double sens. Sa faiblesse apparaît à grande échelle : certaines décisions (le modèle de données d’un système de référence, les frontières entre équipes, le modèle de sécurité, le choix entre intégration synchrone et asynchrone) sont coûteuses à inverser et façonnent tout ce qui est construit par-dessus. Les laisser émerger signifie souvent qu’elles sont prises par accident par la personne qui écrit le premier code.

Ce que le Manifeste agile dit et ne dit pas

L’un des douze principes sous-jacents au Manifeste agile (2001) dit : Les meilleures architectures, spécifications et conceptions émergent d’équipes auto-organisées. On le cite souvent comme s’il signifiait que les équipes agiles n’ont besoin ni d’architecture ni d’architectes. Ce n’est pas ce qu’il dit.

Lu attentivement, le principe affirme quelque chose sur qui produit les meilleures architectures (les personnes qui construisent le système, organisées par elles-mêmes plutôt que dirigées de l’extérieur) et sur comment (elles émergent du travail, au lieu d’être transmises toutes faites). Il ne dit nullement que l’architecture serait sans importance, et le même document contient un autre principe : une attention continue à l’excellence technique et à une bonne conception renforce l’agilité. Une équipe qui ignore les décisions structurelles ne suit pas le manifeste ; elle en ignore la moitié.

Ce que le principe exclut bel et bien, c’est une architecture imposée depuis une tour d’ivoire par des personnes qui n’en vivront pas les conséquences, ainsi qu’une phase durant laquelle l’architecture est terminée et figée avant que quiconque écrive du code. En pratique, la conciliation la plus courante est que l’architecture devient une activité continue, partagée au sein de l’équipe, avec un architecte (ou des ingénieurs sensibles à l’architecture) dans le rôle de guide, de facilitateur et de gardien de la vue d’ensemble plutôt que dans celui de gardien du temple.

Combien d’architecture ? Le modèle piloté par les risques

Si aucun des deux extrêmes n’est le bon, quelle quantité de travail d’architecture suffit ? George Fairbanks a donné l’une des réponses les plus claires dans Just Enough Software Architecture: A Risk-Driven Approach (2010). Son modèle piloté par les risques dit que l’effort consacré à l’architecture doit être proportionné au risque d’échec. Il comporte trois étapes, répétées autant que nécessaire : identifier et hiérarchiser les risques (idéalement sous forme de scénarios de défaillance concrets, comme « la page de réservation dépasse son délai d’expiration quand 5000 patients se connectent à 8 h ») ; choisir et appliquer des techniques qui réduisent ces risques (un modèle, un prototype, un test de charge, une analyse, un patron de conception) ; et évaluer la réduction du risque, en s’arrêtant lorsque le risque restant est acceptable.

Le modèle est puissant parce qu’il fournit une règle d’arrêt. Un simple outil interne construit sur une technologie familière avec peu d’utilisateurs fait face à peu de risques architecturaux, et un croquis sur un tableau blanc peut suffire. Une plateforme de paiement qui traite des millions de transactions, soumise à une réglementation, en affronte beaucoup, et mérite une modélisation, un prototypage et une revue soigneux. Une même équipe peut appliquer des quantités d’architecture très différentes à différentes parties d’un même système. Fairbanks souligne aussi que le temps passé à concevoir est du temps qui n’est pas consacré à construire ou à tester, si bien que la surconception est un coût réel, et non un choix par défaut sans danger.

L’architecture intentionnelle et la piste architecturale

Les grandes organisations font face à un problème de coordination qu’une équipe unique ne connaît pas : des dizaines d’équipes doivent construire des parties qui s’emboîtent. Le Scaled Agile Framework (SAFe), un cadre largement adopté, et aussi largement débattu, pour mettre à l’échelle les pratiques agiles, décrit l’architecture comme un équilibre entre la conception émergente au sein des équipes et l’architecture intentionnelle : la planification délibérée, entre équipes, des structures et des lignes directrices qu’elles partagent. Il appelle le résultat la piste architecturale (architectural runway) : le code, les composants et l’infrastructure technique existants nécessaires pour implémenter les fonctionnalités à court terme sans refonte ni retard excessifs. Le travail d’extension de la piste (par exemple, introduire une plateforme de messagerie avant les fonctionnalités qui en ont besoin) est planifié explicitement à côté du travail sur les fonctionnalités, et les fonctionnalités consomment la piste à mesure qu’elles l’utilisent.

Décrite de façon neutre, la métaphore de la piste saisit une vérité valable pour toute organisation : si l’infrastructure dont une fonctionnalité a besoin n’existe pas encore, cette fonctionnalité sera lente, et construire l’infrastructure prend du temps. Les détracteurs de SAFe soutiennent qu’il peut réintroduire une planification lourde et descendante sous un vocabulaire agile ; ses partisans répondent qu’une certaine coordination centrale est inévitable à grande échelle. Vous n’avez pas besoin d’adopter SAFe pour utiliser l’idée : « de quelles fondations les fonctionnalités du prochain trimestre auront-elles besoin, et les construisons-nous à temps ? » est une bonne question pour tout architecte.

L’architecture continue

Murat Erder et Pierre Pureur, dans Continuous Architecture: Sustainable Architecture in an Agile and Cloud-Centric World (2015) et Continuous Architecture in Practice (2021, avec Eoin Woods), décrivent l’architecture comme un flux continu de décisions plutôt que comme une phase ou un document. Leurs six principes sont : concevoir l’architecture de produits, et pas seulement de solutions pour des projets ; se concentrer sur les attributs de qualité, et non sur les exigences fonctionnelles ; retarder les décisions de conception jusqu’à ce qu’elles soient absolument nécessaires ; concevoir pour le changement en tirant parti de la puissance de petites parties faiblement couplées ; concevoir pour construire, tester, déployer et exploiter ; et modeler l’organisation de vos équipes sur la conception du système sur lequel vous travaillez.

Deux de ces principes font écho aux sections précédentes de ce chapitre : retarder les décisions, c’est le dernier moment responsable, et modeler les équipes sur le système est un usage délibéré de la loi de Conway. L’accent pratique est mis sur la décision comme unité du travail d’architecture, consignée au moment où elle est prise, et sur les boucles de rétroaction (tests automatisés, fonctions d’aptitude, supervision en production) qui indiquent à l’équipe si l’architecture atteint toujours ses objectifs de qualité.

Squelettes ambulants et spikes

Deux techniques simples rapprochent l’architecture et la livraison dès la première semaine. Un squelette ambulant (walking skeleton), terme associé à Alistair Cockburn, est une implémentation minuscule du système qui réalise une petite fonction de bout en bout à travers tous les principaux composants architecturaux. Pour un système de réservation hospitalier, il pourrait permettre à un utilisateur de test de se connecter, de voir les créneaux libres d’une clinique codée en dur, récupérés depuis le système d’administration des patients, d’en réserver un et de recevoir un SMS, le tout déployé dans un environnement proche de la production via le vrai pipeline de livraison. Il ne fait presque rien d’utile, mais il prouve que les pièces se connectent, que le pipeline fonctionne et que l’architecture peut être construite. Chaque fonctionnalité ultérieure ajoute de la chair à un squelette qui marche déjà.

Un spike (autre terme issu de l’Extreme Programming) est une expérience courte, limitée dans le temps, destinée à répondre à une question ou à réduire un risque : l’interface du PAS (système d’administration des patients) peut-elle traiter 50 requêtes par seconde ? Combien de temps le fournisseur d’identité met-il à émettre un jeton ? La bibliothèque que nous avons choisie peut-elle générer des PDF accessibles ? Les spikes sont généralement jetés ; leur résultat est la connaissance, consignée dans une décision. C’est le moyen le moins coûteux de faire passer une décision de la conjecture aux éléments probants avant son dernier moment responsable.

Les activités d’architecture dans un cycle itératif

Dans un processus itératif, le travail d’architecture n’a pas lieu une seule fois ; il revient à chaque cycle, avec une profondeur adaptée aux risques auxquels l’équipe fait face. Le programme de l’iSAQB décrit les tâches essentielles de l’architecte d’une manière qui se transpose naturellement à un tel cycle, et Le rôle de l’architecte les a présentées. Les voici sous forme de boucle :

Clarifier les exigences : identifier les parties prenantes et les préoccupations, préciser les objectifs de qualité et les contraintes, et identifier les risques (voir Parties prenantes et préoccupations). Concevoir les structures : prendre ou réviser les décisions significatives, en choisissant des styles et des patrons et en définissant les frontières et les interfaces. Communiquer et convenir : expliquer les décisions aux personnes qui construisent, exploitent et financent le système, dans des vues adaptées à chaque public, et les consigner. Accompagner l’implémentation : travailler avec les équipes pendant qu’elles construisent, répondre aux questions, relire le code et ajuster la conception quand la réalité résiste. Évaluer : vérifier que le système atteint ses objectifs de qualité, par des revues, des tests, des mesures en production et des fonctions d’aptitude automatisées. Faire évoluer : agir sur ce que l’évaluation a révélé, rembourser la dette et s’adapter aux exigences qui ont changé, ce qui vous ramène à la clarification des exigences.

L’architecture dans le DevOps et la livraison continue

La livraison continue, dans laquelle chaque changement est construit, testé et maintenu prêt à être mis en production, et le DevOps, qui réunit les responsabilités du développement et de l’exploitation, modifient à la fois les objectifs de l’architecture et ses boucles de rétroaction.

Ils modifient les objectifs parce que la déployabilité, la testabilité et l’exploitabilité deviennent des attributs de qualité de premier rang. Un système ne peut pas être mis en production plusieurs fois par jour si les composants doivent être déployés ensemble dans un ordre fixe, si les tests nécessitent une copie complète de la production, ou si personne ne peut dire, d’après la supervision, si une mise en production a aggravé les choses. Les recherches résumées dans Accelerate (Nicole Forsgren, Jez Humble et Gene Kim, 2018) ont montré qu’une architecture faiblement couplée, qui permet aux équipes de tester et de déployer leurs parties indépendamment, figurait parmi les plus puissants prédicteurs de la performance en livraison continue. L’architecture n’est donc pas seulement aidée par de bonnes pratiques de livraison ; elle en est l’une des conditions préalables.

Ils modifient les boucles de rétroaction parce que le système en fonctionnement devient la revue d’architecture la plus honnête. Les métriques de production, les traces et les revues d’incidents montrent où l’architecture est faible de façon bien plus fiable que les diagrammes. Les règles d’architecture peuvent être appliquées sous forme de fonctions d’aptitude automatisées dans le pipeline (chapitre 11), l’infrastructure est définie en tant que code et relue comme du code (chapitre 10), et des techniques comme les feature flags et les canary releases (déploiements canari) rendent de nombreuses décisions réversibles à moindre coût. Le rôle de l’architecte évolue en conséquence : moins d’approbation de documents, davantage de façonnage de la plateforme, du pipeline et des garde-fous qui permettent aux équipes de prendre rapidement de bonnes décisions.