Moderniser un legacy conséquent sans y perdre ses plumes - Partie I

le 25/01/2026 par Bruno Boucard

Tags: Software Engineering, Product & Design, Bonne Pratique, Architecture, Craft

Moderniser un legacy conséquent sans y perdre ses plumes - Partie I

Dans cette partie, nous aborderons les thématiques suivantes

Dans la majorité des organisations, le système d’information finit par être qualifié de legacy
Les évolutions deviennent lentes et coûteuses ; chaque nouvelle fonctionnalité se transforme en combat, générant frustration côté métier comme côté IT
Et si le véritable problème n’était pas le code legacy, mais ce qu’il révèle ?
La prise de conscience survient généralement au niveau du management, lorsqu’il devient évident que la situation n’est plus tenable
La réécriture complète du système apparaît souvent comme une fausse bonne idée, en raison du maintien de deux systèmes en parallèle, de la faible connaissance fonctionnelle nécessaire pour écrire correctement le nouveau
Comprendre que le code n’est que « l’arbre qui cache la forêt » est la clé d’une modernisation plus profonde, dépassant largement le simple remaniement du code
Le management joue un rôle clé dans cette transformation organisationnelle
Il doit accompagner les équipes afin de faciliter l’atteinte de leurs objectifs, plutôt que de se limiter à des décisions structurelles ou techniques
Atelier Event Storming Big Picture permet de prendre de la hauteur et réorganiser les équipes au-delà des silos existants
Le management doit également encourager les initiatives favorisant la collaboration avec le métier avec quelques ateliers collaboratifs favorisant la compréhension métier
Ces pratiques aident les équipes à mieux comprendre les enjeux métier et la valeur réelle de leur produit

Le legacy n’arrive pas par hasard

Un système d’information devient inévitablement legacy avec le temps. Les spécifications initiales se perdent, le turnover érode la mémoire collective, et l’hygiène du code se dégrade progressivement. L’architecture évolue au fil des contraintes et des urgences, sans véritable prise de recul ni vision d’ensemble.

Peu à peu, tout finit par être couplé à tout. Les frontières s’estompent, les dépendances se multiplient, et les équipes héritent de périmètres trop vastes pour rester réellement maîtres de leur système. Ce manque de clarté rend chaque évolution plus coûteuse et plus risquée que la précédente.

Néanmoins, il convient de ne jamais perdre de vue la nature même du logiciel. Par essence, le logiciel est malléable et peut être transformé par des mains expertes. En revanche, les approches et techniques permettant de remanier le code restent malheureusement peu connues ou mal maîtrisées, ce qui conduit trop souvent à des situations complexes, voire dramatiques.

Les conséquences sont alors bien connues. Les bugs se multiplient, les équipes s’épuisent sous une charge mentale croissante, et les managers se retrouvent à gérer une situation sous tension permanente. Le code prend l’apparence d’un plat de spaghetti : fragile, difficile à comprendre, et dangereux à faire évoluer.

Progressivement, un climat de peur s’installe chez les développeurs. Modifier le code devient une source d’anxiété, car chaque changement peut provoquer des effets de bord imprévisibles. À ce stade, le système n’est plus seulement un frein technique : le code legacy devient un obstacle pour les développeurs, qui en subissent les effets en tant que victimes collatérales des choix organisationnels.

Le mirage de la réécriture totale

La modernisation des systèmes legacy est souvent perçue comme une illusion. Beaucoup la jugent irréaliste, en s’appuyant sur un raisonnement qui paraît logique à première vue : si une telle transformation était réellement possible, de nombreuses entreprises l’auraient déjà menée à bien.

Ce scepticisme revient systématiquement lors des échanges avec des organisations confrontées au découpage de monolithes legacy. La démarche est fréquemment considérée comme impossible, ou du moins comme quelque chose que personne n’a jamais véritablement observé en pratique. Cette perception n’est pas infondée : la modernisation d’un monolithe est rare, car elle est complexe, risquée et profondément engageante pour les équipes comme pour l’organisation.

Cependant, il est essentiel de ne pas confondre rareté et inexistence. Ce qui est peu fréquent n’est pas pour autant irréalisable. Avec une approche progressive, structurée et sécurisée, il est tout à fait possible de moderniser un monolithe legacy. Certaines entreprises y sont parvenues, non pas par une rupture brutale, mais par une succession d’étapes maîtrisées, guidées par une vision claire et une discipline d’exécution.

La croyance selon laquelle « cela ne se fait jamais » repose donc sur une confusion courante : ce qui est difficile et exigeant est souvent assimilé à de l’impossible. Or, seuls les acteurs prêts à s’engager avec méthode, persévérance et lucidité parviennent à en tirer des bénéfices durables.

Face à cette complexité, une tentation s’impose alors naturellement : repartir de zéro. La réécriture complète promet un langage moderne, un code enfin propre, des équipes regonflées à bloc et un management plein d’espoir. Cette promesse est séduisante, mais elle conduit bien souvent à une désillusion rapide.

Car, dans des conditions organisationnelles et culturelles inchangées, les mêmes causes produisent inévitablement les mêmes effets. Sans transformation profonde des pratiques, des modes de collaboration et de la manière de concevoir le système, réécrire revient souvent à reconstruire un nouveau legacy — simplement plus récent.

Il est temps de ne plus croire au père Noël

La cohabitation entre l’ancien et le nouveau système épuise les équipes, dilue les connaissances métier et conduit l’organisation à maintenir simultanément deux systèmes coûteux. Dans de nombreux cas, l’un des deux finit par être abandonné et ce n’est pas toujours le plus ancien. La réécriture totale devient alors le moyen le plus sûr de fabriquer… une nouvelle version legacy.

J’ai personnellement été témoin de ce type de réécriture au sein de grandes organisations, notamment dans des environnements où les sous-systèmes sont à la fois complexes et denses, comme l’informatique des salles de marché. Dans ces contextes, les tentatives de réécriture au niveau d’un sous-domaine métier échouent fréquemment, à la fois pour les raisons évoquées plus haut et sous la pression de fortes contraintes réglementaires.

Les exemples de réécritures avortées y sont nombreux. L’un d’eux concernait un service de pricing développé en C++, sujet à des « arrêts cardiaques » réguliers au grand dam des traders. La décision fut prise de le réécrire en C#, avec l’espoir d’une plus grande stabilité. Cette initiative se solda par un échec : la version C# ne parvient jamais à retrouver la richesse des connaissances fonctionnelles accumulées dans le code d’origine. Pendant ce temps, sous la pression de cette réécriture concurrente, les défauts du système C++ furent finalement corrigés… et c’est lui qui continua à porter la valeur métier.

Prendre de la hauteur - le problème n’est pas que le code

En prenant du recul, une évidence s’impose : le problème ne se limite pas au code. L’organisation des équipes influence directement l’architecture des systèmes que l’on produit. Une équipe seule, confrontée simultanément à plusieurs domaines métiers complexes, finit inévitablement en situation de surchauffe, générant un code difficile à comprendre, à faire évoluer et à maîtriser.

Quand le sage désigne la lune, l’idiot regarde le doigt - Confussius

Cette observation n’est pas nouvelle. Dès la fin des années 1960, Melvin Conway formule ce qui résonne aujourd’hui comme une loi sociologique toujours d’actualité. La loi de Conway nous rappelle que la structure organisationnelle d’une entreprise façonne mécaniquement la structure de ses systèmes : une organisation mal alignée favorise des architectures étroitement couplées, qui entravent le flux de travail et empêchent les équipes de travailler de manière réellement indépendante.

Dans les grandes structures, il est fréquent de constater que le management est largement accaparé par les enjeux budgétaires. Cette focalisation, bien que légitime, tend parfois à éloigner les décideurs des réalités opérationnelles et des difficultés concrètes rencontrées par les équipes au quotidien.

La modernisation organisationnelle ne devrait pas se limiter à un exercice structurel ou financier. Elle constitue avant tout une opportunité pour le management de se reconnecter aux problématiques du terrain et de mieux comprendre les freins qui entravent l’efficacité collective.

Dans cette perspective, accompagner les équipes dans l’atteinte de leurs objectifs devient un enjeu central. Cela implique un soutien actif, une écoute attentive et la mise en place de conditions favorables à la réussite, plutôt qu’une simple recherche d’optimisation budgétaire.

Le pouvoir au service des équipes

La modernisation ne peut réussir sans un management profondément tourné vers le leadership (Servant Leader). Dans cette posture, le rôle du management n’est plus de diriger par le contrôle, mais de créer les conditions dans lesquelles les équipes peuvent réussir. À l’inverse, un manque d’accompagnement managérial laisse les équipes dans un sentiment d’abandon et d’incompréhension, ce qui affecte directement le moral et l’engagement. L’absence de dialogue installe une distance progressive entre le management et les équipes, fragilisant la confiance, pourtant essentielle à toute transformation durable.

Le servant leadership constitue un levier central des transformations agiles et Lean, en rupture avec le modèle managérial traditionnel fondé sur l’autorité, le contrôle et la prescription. Il repose sur une inversion du rôle du management : plutôt que de diriger les équipes par la hiérarchie, le manager se met au service de leur capacité à créer de la valeur.

Formalisé par Robert K. Greenleaf dans The Servant as Leader (1970), ce concept affirme que le leader est avant tout un facilitateur. Sa responsabilité première est de créer un environnement favorable à l’autonomie, à l’apprentissage et à l’amélioration continue, en comprenant et en prenant en compte les besoins réels des équipes.

Dans le cadre d’une transformation agile, le Servant Leader s’intéresse prioritairement au travail réel plutôt qu’au travail prescrit : contraintes opérationnelles, dépendances organisationnelles, charge cognitive, dette technique et variabilité de la demande. Par une présence active sur le terrain, il identifie les obstacles systémiques qui ralentissent le flux et agit pour les éliminer.

En supprimant les frictions organisationnelles, en rendant les priorités explicites et en protégeant les équipes des sollicitations contradictoires, le management devient un acteur clé de l’optimisation du flux de valeur de bout en bout. Il favorise ainsi la stabilité, la focalisation et la capacité des équipes à livrer de la valeur de manière continue et soutenable.

Cette posture induit un changement organisationnel profond et transforme l’agenda managérial : moins de pilotage par les indicateurs de conformité, davantage de temps consacré au terrain, à l’observation du travail réel, à l’écoute, au coaching et à l’amélioration du système. Le leadership s’exerce alors par l’influence et le soutien plutôt que par le contrôle.

Enfin, le servant leadership s’inscrit dans un investissement de long terme. Il exige de la discipline managériale, de l’écoute active et une volonté sincère de servir avant de diriger. En retour, il permet d’obtenir des résultats durables : amélioration de la performance globale, renforcement de la collaboration, accélération du flux de valeur et engagement accru des équipes.

La confiance n’est pas optionnelle

Avec l’appui d’un management adoptant une posture de servant leadership, les équipes peuvent construire des relations solides et durables avec le métier, fondées sur la confiance. Cette relation de confiance constitue un pilier essentiel de cette posture managériale, car elle conditionne la qualité de la collaboration et la capacité collective à créer de la valeur.

Favoriser une collaboration étroite et continue entre les experts métier et les équipes techniques est en effet indispensable pour développer une compréhension partagée des enjeux, des règles et des objectifs. Cette proximité permet de réduire les malentendus, d’aligner les décisions et d’ancrer le développement logiciel dans la réalité du domaine.

Comme le rappelle Alberto Brandolini, créateur des ateliers EventStorming : « Ce n’est pas le cerveau du métier qui part en production, mais celui des développeurs. » Cette affirmation souligne la responsabilité des Product Managers et Product Owners : ils doivent fournir des récits métier clairs, concrets et illustrés, afin de permettre aux équipes techniques de traduire fidèlement les intentions métier dans le code.

Pour faciliter la compréhension du métier entre les équipes de développement et les acteurs métier, de nombreux outils sont à votre disposition. Disposer d’une meilleure compréhension, orientée produit, est essentiel pour ancrer à la fois le pourquoi et le comment de ce que nous allons construire.

C’est dans cette perspective que Jeff Patton publie en 2013 l’ouvrage User Story Mapping, qui révolutionne la manière de concevoir un produit en structurant sa construction par incréments de valeur.

Cette modernisation organisationnelle débute par une prise de conscience du management. Confrontée à des difficultés récurrentes de livraison et à un mécontentement croissant des utilisateurs, la direction cherche alors un levier pour sortir d’une crise devenue structurelle.

C’est dans ce contexte que l’Event Storming Big Picture s’impose comme une évidence.

L’Event Storming Big Picture a pour objectif de mettre à plat le fonctionnement global du domaine métier afin d’en faire émerger des sous-domaines cohérents et compréhensibles par tous. C’est précisément ce travail de découpage et de clarification que nous allons aborder maintenant.

Passer d’une organisation de contrôle à une organisation de confiance

Moderniser durablement un legacy impose donc d’agir à plusieurs niveaux simultanément : l’organisation, les interactions humaines et le code lui-même. C’est précisément dans cette articulation que les approches issues du Domain-Driven Design et de Team Topologies prennent tout leur sens, en proposant des leviers concrets pour aligner structure organisationnelle, compréhension métier et architecture logicielle.

La première étape d’une démarche de modernisation consiste à faire évoluer l’organisation avant de s’attaquer au code. L’objectif est de traiter les causes structurelles des difficultés rencontrées, plutôt que de se limiter à corriger leurs manifestations techniques. Sans cette transformation préalable, la modernisation du code risque de reproduire les mêmes problèmes, simplement sous une forme plus récente.

EventStorming Big Picture pour réorganiser avec discernement les équipes

Exemple d’atelier Event Storming Big Picture est mené dans une phase organique, en tout début d’atelier

Il peut être nécessaire, en amont, d’établir un inventaire fonctionnel du domaine métier. Ce travail préparatoire permet d’identifier les principales capacités, responsabilités et interactions du domaine, et de réunir ensuite une audience à la fois diversifiée et suffisamment informée. Cette préparation est essentielle pour garantir la qualité des échanges et la pertinence des décisions prises lors de l’atelier.

Chaque sous-domaine peut ensuite être approfondi en constituant une ou plusieurs équipes, selon la complexité métier et la charge cognitive à maîtriser. La démarche s’achève par une validation de l’alignement effectif entre la structure des équipes et ce découpage du domaine.

Cette démarche s’inscrit directement dans les principes de Team Topologies, qui rappellent que la performance durable repose sur des équipes clairement responsabilisées, capables de maîtriser un périmètre métier limité et compréhensible. En réduisant la charge cognitive par équipe, on crée les conditions nécessaires à l’autonomie, à la qualité du code et à la capacité d’évolution.

**D’un point de vue opérationnel, l’atelier EventStorming Big Picture joue un rôle clé. Il réunit des profils complémentaires afin d’établir une compréhension partagée et actionnable du métier. L’atelier permet d’identifier clairement les flux, de faire émerger des narrations métier exploitables et de structurer le domaine en sous-domaines concrets. **

Sur la surface de modélisation, les participants commencent par délimiter les frontières des sous-domaines métiers afin de rendre explicite le découpage du domaine. Les événements qui apparaissent à la jonction de ces sous-domaines sont appelés événements pivots. Ils jouent un rôle clé : ils rendent visibles les points de passage entre domaines, facilitent la compréhension des interactions inter-domaines et servent de repères pour raisonner sur les dépendances et les responsabilités entre équipes.

Ces éléments constituent un socle pour orienter les décisions d’organisation et aligner efficacement les équipes avec les réalités du domaine métier. Au sein de chaque sous-domaine métier, des équipes sont ensuite constituées autour de thématiques clairement identifiées, de manière à maintenir une charge cognitive soutenable et à garantir une capacité de livraison régulière et prévisible.

Sur la surface de modélisation, chaque sous-domaine accueille les Bounded Contexts du Domain-Driven Design, ce qui permet de rendre explicite et visible leur périmètre de responsabilité.

Bounded Context : QuesaQo ?

Le Bounded Context n’est pas une simple abstraction de modélisation : c’est avant tout un choix stratégique. Il définit une sphère de connaissance clairement délimitée, au sein de laquelle l’équipe réunit les conditions nécessaires pour faire émerger à la fois l’innovation métier et l’excellence technique. Cette convergence est essentielle pour produire un logiciel de haute qualité, durable et pertinent.

En érigeant des frontières explicites, le Bounded Context redonne à l’équipe la maîtrise de son périmètre. Il protège le modèle des interférences extérieures et impose une compréhension du domaine à la fois partagée, cohérente et exigeante. Cette clarté n’est pas un confort superflu : elle constitue une condition fondamentale de la qualité.

Cet espace volontairement limité, stable et assumé devient alors un véritable terrain d’expression où un vocabulaire métier est cultivé, qu’on appelle aussi langage ubiquitaire du Domain-Driven Design, afin de prendre des décisions techniques fortes, pleinement au service du métier. C’est sur cette base que peuvent être conçus des systèmes réellement robustes, évolutifs et profondément alignés avec la réalité business et non façonnés par des compromis organisationnels subis.

Projeter l’organisation au regard des échanges entre les équipes

À l’issue de ces ateliers, les frontières deviennent visibles : des Bounded Contexts, portés par des équipes alignées sur des responsabilités claires, et des relations explicites entre ces contextes grâce au Context Mapping. Ce dernier atelier permet de projeter l’organisation sur un autre axe, en rendant visibles les modes d’interaction entre équipes, qu’il s’agisse de collaboration, de dépendances amont/aval ou de services consommés.

Context Mapping offre un regard différent en appuyant sur les relations en les Bounded Contexts

Cette projection met parfois en évidence des erreurs de découpage ou des zones de responsabilité floues. Conformément aux enseignements de Team Topologies, ces situations sont alors traitées par des ajustements organisationnels et des échanges ciblés entre équipes, afin de clarifier les responsabilités et d’améliorer les flux de collaboration. Une fois ces ajustements réalisés, l’organisation obtenue réduit significativement la charge cognitive par équipe et redonne aux équipes une véritable capacité d’action, condition indispensable à une modernisation durable du legacy.

Dans cette instance de Context Mapping, on constate que le Bounded Context “Programmation artistique” est fortement couplé au Bounded Context “Programmation des représentations”. Les échanges fréquents entre ces deux contextes, par exemple lors de la définition d’une saison artistique, de l’ajustement des dates de représentation ou de la gestion des contraintes de disponibilité des artistes, constituent un signal clair d’un découpage excessif. Dans ce cas, maintenir deux contextes distincts introduit davantage de coordination que de valeur, et ces deux Bounded Contexts devraient probablement être regroupés en un seul afin de simplifier le modèle et le fonctionnement des équipes**.**

Le pouvoir au service des équipes

La confiance n’est pas optionnelle

User Story Mapping

Il existe des outils et des pratiques qui permettent de rapprocher durablement les équipes de développement et les représentants métier. Leur objectif est de construire une vision globale et partagée du produit, élaborée collectivement par l’équipe avec le soutien actif du métier.

Le User Story Mapping fait partie de ces approches. En favorisant une compréhension commune des parcours utilisateurs, des priorités et de la valeur métier, il constitue un levier puissant de collaboration et d’alignement entre les acteurs techniques et fonctionnels.

Le User Story Mapping est une pratique agile qui permet de représenter visuellement le parcours d’un utilisateur lorsqu’il interagit avec un produit. Son objectif principal est d’aider les équipes à comprendre ce que vit réellement l’utilisateur, du début à la fin de son expérience, afin de construire un produit cohérent, utile et orienté valeur. Contrairement à un backlog linéaire, cette approche offre une vue d’ensemble qui met en évidence le sens global du produit et la manière dont les fonctionnalités s’enchaînent.

A Guide to User Story Mapping: Templates and Examples (How to Map User Stories) | Planio

Cette technique répond à un problème fréquent des équipes agiles : la perte de vision produit. Lorsqu’un backlog devient une simple liste priorisée de user stories, il est facile d’oublier pourquoi certaines fonctionnalités existent et comment elles contribuent à l’expérience utilisateur. Le User Story Mapping permet de replacer les besoins utilisateurs au centre des discussions, en alignant l’équipe sur les objectifs du produit, les attentes des clients et la valeur métier recherchée.

La construction d’une User Story Map commence par l’identification des grandes activités que l’utilisateur réalise pour atteindre son objectif. Ces activités forment la colonne vertébrale de la carte et décrivent les étapes clés du parcours utilisateur. Sous chacune de ces activités sont ensuite détaillées des histoires utilisateurs plus fines, qui correspondent aux actions concrètes que l’utilisateur doit pouvoir effectuer. Cette organisation rend visible la relation entre les fonctionnalités et le parcours global.

La dimension verticale de la carte permet de gérer la priorisation. Les histoires les plus importantes pour l’utilisateur sont placées en haut, tandis que les fonctionnalités secondaires ou optionnelles se trouvent plus bas. Cette hiérarchisation aide l’équipe à définir des versions successives du produit, en traçant des lignes de découpe horizontales qui correspondent aux incréments livrables, qu’il s’agisse de versions, de releases ou de sprints.

Le User Story Mapping est avant tout une activité collaborative. Il implique généralement les développeurs, le Product Owner, les designers et toute personne ayant une connaissance utile du produit ou des utilisateurs. Ensemble, ils discutent des hypothèses, des besoins réels et des priorités, ce qui favorise une compréhension partagée et réduit les malentendus. Cette collaboration permet également de détecter plus tôt les zones d’incertitude, les dépendances ou les risques fonctionnels.

Un des principaux bénéfices de cette pratique est sa capacité à encourager une approche itérative et incrémentale. En se concentrant d’abord sur un parcours utilisateur minimal mais complet, l’équipe peut livrer rapidement une première version fonctionnelle du produit, puis l’enrichir progressivement en fonction des retours utilisateurs. Cela limite le gaspillage et maximise l’apprentissage à chaque itération.

Cependant, malgré la clarté apportée par le User Story Mapping, il est parfois nécessaire d’approfondir la compréhension du cœur d’une user story. Autrement dit, il s’agit d’illustrer les critères d’acceptation à l’aide d’exemples concrets, construits en collaboration avec l’équipe de développement.

Cet atelier existe : il s’appelle l’Example Mapping.

Atelier Example Mapping

Dans de nombreuses organisations, les besoins métier, traduits sous forme de user stories, sont décrits par le Product Owner dans des outils comme Jira de manière parfois anémique. Ces descriptions se limitent fréquemment à quelques phrases génériques, insuffisantes pour porter une compréhension partagée du besoin réel.

Or, par nature, une user story n’est pas une spécification figée : c’est avant tout un espace de conversation entre le métier et l’équipe de développement. Elle sert de point de départ à des échanges visant à clarifier les intentions, les règles métier et les comportements attendus du système.

Dans ce contexte, l’Example Mapping apparaît comme une pratique particulièrement pertinente. Il s’agit d’un atelier à la fois simple et puissant, conçu pour enrichir les user stories par des conversations structurées. En une trentaine de minutes, l’atelier permet de transformer les critères d’acceptation d’une user story en exemples concrets, compréhensibles et partagés par l’ensemble des acteurs.

Example Mapping est un atelier à fois simple et puissant pour transférer la connaissance métier

Avant de commencer le développement d’une user story, il est en effet essentiel de disposer d’un temps dédié pour clarifier et valider les critères d’acceptation. L’Example Mapping vise précisément à rendre cette conversation courte mais extrêmement productive, en se concentrant sur des exemples concrets du comportement attendu du système plutôt que sur des formulations abstraites.

L’idée centrale est que les exemples constituent un levier puissant pour explorer et comprendre le domaine du problème. En discutant collectivement de ces exemples, l’équipe identifie les règles qui gouvernent le comportement attendu, tout en faisant émerger des zones d’ombre : questions non résolues, hypothèses implicites ou cas limites jusqu’alors ignorés.

Concrètement, l’Example Mapping se matérialise par une représentation visuelle à l’aide de notes de couleur disposées sur un tableau ou une table. La user story est inscrite sur une index-card jaune placée en haut. Les règles ou critères d’acceptation sont représentés par des index-cards bleues positionnées en dessous. Sous chaque règle, des index-cards vertes décrivent les exemples concrets qui l’illustrent, tandis que les questions ouvertes sont consignées sur des index-cards rouges. Cette visualisation facilite la structuration de la discussion et la mémorisation des points encore à éclaircir.

L’équipe poursuit la discussion et enrichit cette carte jusqu’à ce que le périmètre de la user story soit jugé suffisamment clair, ou que le temps alloué à l’atelier soit écoulé. L’objectif n’est pas uniquement de collecter des exemples, mais de construire une compréhension partagée et alignée de ce qui doit être développé, avant même que la user story ne soit planifiée et implémentée.

Dans le cadre d’une équipe mettant en œuvre à la fois le User Story Mapping et l’atelier Example Mapping, une question se pose naturellement : existe-t-il un moyen de connecter ces deux pratiques ? La réponse est oui.

Il est tout à fait pertinent de matérialiser cette connexion en apposant une pastille de couleur sur certaines user stories**, dans la zone de détail du** User Story Map**. Cette pastille rend visible le fait que la** user story devra être explorée plus en profondeur au travers d’un atelier d’Example Mapping.

Cette dynamique, résolument orientée vers la découverte du métier, permet à l’équipe d’acquérir une compréhension de plus en plus fine des besoins, tout en renforçant la confiance collective au moment d’entrer en phase de développement.

Les règles métier immuable sont appelées invariants dans la sphère du Domain-Driven Design. Les invariants sont généralement hébergés dans un regroupement de classes donc la cohérence fonctionnelle est sans équivoque. Ce regroupement est aussi appelé Agrégat dans la sphère Domain-Driven Design.

La valeur métier avant les plans

Un des piliers de l’approche Team Topologies consiste à dépasser la simple recherche d’un flux rapide pour adopter une vision plus large : celle de l’écosystème dynamique. Si l’organisation du travail autour du flux de valeur reste fondamentale, elle n’est plus envisagée comme une optimisation locale ou linéaire, mais comme le résultat d’interactions continues entre des capacités distribuées au sein de l’organisation.

Dans cette perspective, une organisation n’est plus perçue comme un empilement de fonctions ou de silos, mais comme un ensemble de capacités interconnectées, en constante évolution. Le focus mis sur le flux de valeur permet alors de réduire les dépendances nuisibles entre équipes, de limiter les frictions organisationnelles et de créer des conditions favorables à l’autonomie et à l’innovation. Les interactions entre équipes ne sont plus laissées au hasard : elles sont intentionnellement conçues et optimisées à l’aide de modèles éprouvés.

L’approche Team Topologies invite ainsi à abandonner une vision mécaniste de l’organisation, centrée sur l’optimisation des coûts ou la centralisation des décisions. À la place, ils proposent de construire une infrastructure interne d’agilité, où chaque équipe, clairement positionnée dans l’écosystème, contribue de manière cohérente et alignée à la création de valeur globale. Cette approche reconnaît la complexité des systèmes humains et mise sur leur capacité à s’adapter plutôt que sur un contrôle rigide.

Par exemple, dans de nombreuses organisations, le recours à des validations manuelles constitue un frein majeur à la fluidité des livraisons. Or, plus un produit est livré rapidement, plus l’équipe est en mesure de recueillir et d’analyser les retours des utilisateurs. Le délai occasionné par la temps de la validation manuelle est propice à un changement de contexte pour l’équipe.

Conditions propices aux switching contexts

Cette capacité à obtenir un feedback rapide permet alors, en collaboration avec l’équipe produit, d’ajuster finement la solution en fonction des usages réels et des besoins exprimés, et ainsi de maximiser la valeur délivrée.

Synthèse de la première partie

Un système d’information ne devient pas legacy par accident. Avec le temps, la perte de connaissances, la dette technique et l’absence de vision globale conduisent à des architectures fortement couplées, fragiles et coûteuses à faire évoluer. Face à cette situation, la réécriture totale apparaît souvent comme une solution évidente, mais elle échoue fréquemment à défaut de transformer les pratiques, l’organisation et les modes de collaboration. Le problème est donc moins technique que organisationnel et humain, comme l’illustre la loi de Conway.

Une modernisation durable suppose un management adoptant une posture de servant leadership, favorisant la confiance, la collaboration étroite entre métier et technique, et l’optimisation du flux de valeur. Elle nécessite d’agir conjointement sur l’organisation, la compréhension du domaine et le code. Les approches issues du Domain-Driven Design et de Team Topologies offrent des leviers concrets pour aligner équipes, responsabilités et architecture, notamment à travers l’EventStorming, le Context Mapping et des pratiques de découverte continue comme le User Story Mapping et l’Example Mapping.

Moderniser un legacy n’est donc pas une question de technologie ou de réécriture, mais un travail d’alignement durable entre organisation, métier et architecture, guidé par la valeur et porté par des équipes autonomes et responsabilisées.