La Duck Conf 2025 - L'architecture continue par la pratique

Duck Conf 2025, du haut de plus de 30 années d'expérience cumulées, Pierrette Bertrand et Pierre-Jean Dousset partagent leur vécu et leurs recettes pour aborder l'architecture continue. Cette tendance découle inéluctablement du passage du mode projet au mode produit.

Pour commencer, une définition de l'architecture continue qui amène son lot de challenges :

L’architecture continue consiste à faire évoluer rapidement et sans rupture les systèmes d’information au fur et à mesure des besoins.

Créer de l'alignement

Pierre-Jean prend comme exemple le système de gestion des urgences sur lequel il travaille où il rencontre des tracas, commes des API non sécurisées ou un référentiel critique sollicités en mode synchrone. Son problème ? Un manque d'alignement au sein des équipes.

Pierrette propose pour y remédier de formuler une vision technique, pendant technique de la vision produit, et qui soutient cette dernière. Pour y arriver, elle commence par identifier des drivers de l'architecture, tels que sécurité, coût, scalabilité, disponibilité… Les drivers sont les caractéristiques-clés de l'architecture, celles qu'on vérifie systématiquement avant de mettre en production par exemple.

Ensuite, il s'agit de positionner les curseurs pour comparer ces drivers, en fonction de leurs impacts sur le SI, ou de combien on investit pour les vérifier.

À l'instar de la vision produit, cette vision technique doit être confrontée à la réalité, en production. Les métriques métier et technique doivent être en phase, permettant ainsi de vérifier que les bons drivers ont été identifiés.

Pierre-Jean, doté de sa vision technique, est également confronté à des difficultés de communication liées au mode de fonctionnement remote de ses équipes. Même si le management visuel en présentiel n'est plus aussi répandu, Pierrette recommande d'utiliser des outils collaboratifs type Miro ou Excalidraw pour faciliter la developer experience en rassemblant l'ensemble des productions des équipes : schémas d'architecture, vision technique, explications, réflexions…

Perte de maîtrise

Pierrette, elle, a du mal à produire de la documentation d'architecture aussi vite que les équipes réalisent. Donc l'architecture cible et celle effectivement implémentée sont en décalage, malgré l'utilisation d'outils type live doc.

Pierre-Jean propose pour cela de s'appuyer sur des conventions, notion primordiale que l'on retrouve en software craftsmanship, ou artisanat logiciel. Elles permettent d'abaisser les temps d'onboarding inter-applicatifs, de faciliter la compréhension du système d'information, et de développer des réflexes.

Et parmi ces conventions, Pierre-Jean propose de se focaliser sur les conventions des variables d'environnement, car elles configurent les flux et les connexions aux bases de données, aux systèmes de messaging. Par exemple : DATABASE_URL, ou RABBITMQ_URL. La difficulté est surtout la localisation de cette configuration, puisqu'elle sert de base à l'exécution des scripts de déploiement.

Pierre-Jean compare ensuite le schéma d'architecture cible et celui implémenté, qui a été généré sur la base des variables d'environnement, des scripts Python et quelques grep. C'est via des rituels fréquents avec les tech leads, qu'on veille collectivement à la synchronisation de l'architecture cible et celle implémentée.

Hormis les variables d'environnement, d'autres se sont montrées intéressantes à structurer via des conventions : variable d'habilitations, cron jobs, responsabilité métier des composants, consommations d'events. Cela a permis de s'aligner, notamment sur des schémas d'architecture locaux.

L'alignement autour des conventions s'opère en cultivant une proximité entre les tech leads, qui communiquent régulièrement lors de rituels et via les outils collaboratifs. Et en cas de manque de sujets à aborder, les conventions sont une valeur sûre à mettre sur la table, source intarissable de confrontations d'idées constructives.

Sans rupture certes, mais pas sans complication

Même si tout ça semble séduisant, Pierrette remarque un goulet d'étranglement dans le système présenté, qui est effectivement un problème pour Pierre-Jean. Il s'agit d'un référentiel qui a exposé des API au fur et à mesure, et qui s'est retrouvé en position centrale : interfaces spécifiques, criticité importante, coordination des évolutions compliquées entre applications, soucis de performance…

La solution a été d'inverser le paradigme, en poussant l'information auprès des applicatifs consommateurs plutôt que ces derniers requêtent le référentiel. Ainsi le système d'information évolue d'une architecture style API vers une architecture de type événementiel. Et ce changement s'opère de manière opportuniste : les nouvelles applications utilisent le paradigme événementiel, tandis que les applications existantes restent sur le mode d'appel API. Le choix a été fait d'avoir un système d'information hétérogène pour privilégier la continuité de service métier. Cela a par ailleurs permis de cibler les efforts et d'apprendre au fur et à mesure de la transition.

Pierrette souligne qu'il est souvent crucial de définir ce que l'on nomme "événement". Dans ce cas, Pierre-Jean s'appuie sur la définition suivante de Gregor Hohpe.

Event: "A significant change in state that is relevant to other components in the system".

Ce qui donne qu'un événement est un changement d'état significatif qui est pertinent pour les autres composants du système. Ainsi, Pierre-Jean a choisi de transmettre un changement d'état d'un objet du domaine métier, via un message contenant l'intégralité de celui-ci, plutôt qu'une différence par rapport à une version précédente.

En s'appuyant sur sa compréhension du contexte, Pierrette déduit que Pierre-Jean a choisi avec ses équipes de partir sur un outil de type MOM, et souligne le besoin de garder en tête certains patterns relatifs aux architectures événementielles : Transactional Outbox pattern, Retry system, mécanismes de rejeux, séparer asynchrone et interactions utilisateurs, idempotence, ou encore détection des désynchronisations…

Créer de l'ownership

Pierrette appuie sur le fait qu'en tant qu'architecte, on doit être en constante proximité avec les équipes pour prendre ensemble les décisions et diffuser les savoir-faire autour de l'architecture.

Ainsi, trois objectifs vont contribuer à cela :

• Faire faire : toujours assumer en décidant le moins possible, ne pas décider de tout
• Faire avancer : savoir se contenter d'une solution satisfaisante, good enough
• Transmettre : se mettre à disposition des équipes, ne pas être sur le chemin critique

Pour encourager la responsabilisation des équipes, Pierre-Jean recommande l'implication des équipes "les deux pieds dans la prod", en demandant à chaque équipe de communiquer quotidiennement une météo sur ce qui se passe en production.

Afin de cultiver cette proximité, Pierrette et Pierre-Jean articulent la collaboration entre architecte et tech lead, entre contexte global et contexte local, entre entropie du SI et qualité du produit.

La recette gagnante de l'architecture continue

L'essentiel de l'architecture continue peut se résumer en quatre points

• Aligner les équipes avec une vision technique qui sert la vision produit
• Garder la maîtrise en outillant la tech grâce aux conventions
• Accompagner l'émergence de l'architecture avec des designs sans rupture et des efforts ciblés
• Créer de l'ownership en travaillant la posture, "you build it, you run it"

Et leur dernier message :