Architecture logicielle : les choix de Decathlon Digital

Avec quoi gérer ses comptes rendus de décisions d’architecture ? Chez Decathlon Digital, plusieurs BU ont opté pour Structurizr.

Cet outil open source propose un langage spécifique pour créer des « diagrammes en tant que code ». La société l’utilise aussi pour ses modélisations C4. Elle y a consacré un post, inscrit dans une présentation plus large de ses processus de décision en matière d’architecture logicielle.

Subsidiarité dans une « anarchie organisée »

En la matière, la vision s’inspire du « modèle de la poubelle », également dit « anarchie organisée ». Celui-ci postule, dans les grandes lignes, que les parties prenantes participent de façon intermittente aux prises de décisions. Lesquelles résultent d’une combinaison aléatoire de problèmes, de solutions et de temporalités. D’où la métaphore de la corbeille, dans laquelle on jette de façon chaotique ces problèmes et ces solutions.

Le modèle n’englobe pas toute la réalité des prises de décisions (évaluation des solutions alternatives et des conséquences de chaque solution, entre autres). Pour combler ce manque, Decathlon Digital a mis en place des comités d’architecture, au niveau des BU.

Ces comités ne prennent pas les décisions pour les ingés. Ils les aident à définir les problèmes et leur contexte, à comparer des solutions en assurant la conformité avec les lignes directrices du groupe… puis à documenter les décisions.

Les chefs des comités d’architecture participent à des SIG (Special Interest Groups). Il s y font remonter les cas d’usage susceptibles d’aboutir à la création ou à la mise à jour de trois éléments internes : standards, radars technologiques et matrices de maturité.
Les propositions qui ont le plus d’impact passent par une autre instance. En l’occurrence, un comité de supervision technique, composé de CTO et d’autres managers techniques seniors.

Sur cette chaîne, le principe de subsidiarité s’applique. Ainsi, toute décision n’affectant qu’une équipe doit, au possible, être prise à ce niveau. Le comité d’architecture intervient alors en tant que conseiller. Ses KPI sont essentiellement le niveau de satisfaction des ingés (NPS), l’impact sur le SLO et les métriques DORA. Un tel mécanisme allonge les délais de décision, mais favorise l’inclusion des bonnes parties prenantes.

Du modèle C4 au system thinking

Pour associer la bonne méthodo à chaque problème, Decathlon Digital utilise le modèle C4 (contexte – conteneur – composant – code).

Pour un changement donné, les niveaux C4 impactés dictent la stratégie. La méthodo retenue dépend des archétypes de problème (principale question : en connaît-on ou non les frontières ?).
Le remplacement d’une dépendance par une autre dans un conteneur est un exemple de problème aux frontières définies. Il suppose effectivement des listes finies d’occurrences à modifier dans le code et de composants impactés. On peut le résoudre avec une approche réductionniste (linéaire).
Au contraire, la refactorisation de plusieurs composants en interaction dans un conteneur n’a pas de frontière claire. Diviser le travail en une liste de tâches ne garantit pas la compatibilité de chaque décision avec l’output attendu. On adoptera une approche holistique examinant le lien entre toutes les portions du problème.

En combinant les deux approches, on tombe dans le system thinking. Un nouveau lien peut mettre en lumière une nouvelle perspective… et donner une nouvelle valeur à des solutions. Decathlon Digital donne l’exemple d’une amélioration de parcours client couvrant plusieurs systèmes. Le constat : le taux de conversion chutait du fait d’une UX incohérente entre deux applications. La première de type serveur, écrite en Svelte et bundlée avec Vite. La deuxième de type client, écrite en Svelte et bundlée avec Webpack.

Comment Decathlon Digital documente ses décisions

Parallèlement à la réflexion sur les solutions à adopter, il fut demandé à l’équipe produit sa vision long terme. Sa réponse : pour un bon moment, les pages allaient rester autonomes et les services, isolés. Après un certain temps, les composants pourraient interagir en mode cross-app.
Le critère « pages autonomes » permit de fusionner trois problèmes en un (« applications Svelte et React autonomes et liées »). Combiné avec l’approche micro-front-end, on en est arrivé à « micro front-end vertical ». Et on y a associé des solutions : CSI (Client Side Include), SSI (Server Side Include) et ESI (Edge Side Include). À « page autonome », on a associé « composant ouvert», « composant web », « fédération native », « SingleSPA » et « iframes ». Puis on a identifié les principales synergies. Par exemple, la fédération native permet de construire une architecture support le rendu côté serveur et côté client, d’être compatible SSI et de passer à un micro-front-end horizontal.

Pour documenter les décisions prises, Decathlon Digital emploie donc notamment Structurizr. Il y associe un générateur spécifique de sites statiques pour afficher les diagrammes. L’hébergement est centralisé. Une solution qui favorise autant le contrôle qualité que les références aux dépendances externes des systèmes (liens C1-C1 dans le modèle C4).
La structure de gouvernance est récursive (BU, sous-BU, équipe, conteneur). À chaque couche, deux fichiers (model.dsl, views.dsl) et deux dossiers (adrs, docs). Séparer modèles et visualisations permet de mieux séparer les responsabilités et facilite l’import/export de compositions.

Illustration générée par IA