Moderniser un legacy conséquent sans y perdre les plumes - Partie III
Moderniser un legacy conséquent sans y perdre les plumes - Partie III
Si vous avez manqué la seconde partie : Moderniser un legacy conséquent sans y perdre ses plumes - Partie II
Dans cette partie, nous aborderons les thématiques suivantes
- Le Core Domain Chart est un outil de distillation stratégique qui rend visibles les écarts de valeur métier et de complexité entre les sous-domaines, afin d’adapter la stratégie de modernisation à leur nature (cœur, support, générique).
- La valeur métier seule ne suffit pas pour prioriser : la dette technique et la complexité du code sont des critères déterminants. Un domaine critique mais fragile impose un rythme et une stratégie spécifiques.
- Les décisions doivent s’appuyer sur des analyses factuelles et partagées (par exemple via des indicateurs de qualité et de complexité du code) pour dépasser les perceptions subjectives.
- Le croisement entre valeur métier, risque technique et contraintes organisationnelles permet de définir une trajectoire de modernisation pragmatique, en engageant les équipes là où les risques et les apprentissages sont les plus critiques.
- La modernisation se pilote de manière incrémentale, par vagues successives, intégrant à la fois transformation organisationnelle et évolution du code, afin de livrer de la valeur, maîtriser les risques et respecter les contraintes de budget et de calendrier.
- Cette démarche relève d’une approche socio-technique globale, où architecture, pratiques d’ingénierie, organisation et dynamiques humaines sont alignées pour construire un système durable et évolutif.
Piloter la modernisation
Après avoir décrit de manière succincte les ingrédients nécessaires à une modélisation du domaine menée dans de bonnes conditions, il est désormais pertinent de s’interroger sur la façon d’opérer un tel changement au sein de l’organisation. La question n’est plus seulement de savoir quoi modéliser, mais comment engager concrètement cette transformation.
Piloter votre modernisation en fonction de vos critères et à votre rythme.
Moderniser le domaine métier peut, de prime abord, paraître complexe et difficile à maîtriser. Pourtant, en s’appuyant sur le principe bien connu du « diviser pour mieux régner », cette démarche devient plus accessible. En découpant le problème en éléments plus petits, plus cohérents et plus autonomes, les enjeux apparaissent progressivement plus clairs et, en définitive, moins complexes à appréhender.
Prioriser les équipes par la valeur
Dans toute organisation, tous les domaines métiers ne se valent pas. Certains portent la singularité de l’entreprise, d’autres ne font que la soutenir, et beaucoup relèvent simplement du générique. Pourtant, les efforts de conception, d’architecture et d’ingénierie sont souvent répartis de manière uniforme, diluant l’attention là où elle devrait être maximale.
Le Core Domain Chart est un outil de distillation stratégique qui permet de rendre cette réalité visible et partageable.
Visualiser la valeur et la difficulté
Le principe du Core Domain Chart est volontairement simple : positionner chaque domaine, capability ou bounded context sur un graphique à deux dimensions :
- La différenciation métier : dans quelle mesure ce sous-domaine contribue-t-il à l’avantage concurrentiel de l’entreprise ?
- La complexité du sous-domaine : à quel point ce sous-domaine est-il difficile à comprendre, à modéliser et à faire évoluer correctement ?
Ce croisement fait immédiatement apparaître des zones de nature très différente.
Identifier le sous-domain coeur de métier
Les domaines situés dans la zone de forte différenciation et de forte complexité constituent le sous-domain cœur de métier.
C’est là que se joue la valeur stratégique du système. C’est là que le modèle doit être précis, riche et profondément ancré dans le langage métier. C’est aussi là que l’on investit les meilleures compétences, le plus de temps, et les pratiques de conception les plus exigeantes.
Dans le sous-domain cœur de métier, il est essentiel de s’appuyer sur le Model-Driven Design pour aboutir à un code clair, expressif et parfaitement aligné avec la fonctionnalité demandée.
Distinguer le sous-domaine-support et le sous-domaine-générique Domains
À l’inverse, certains sous-domaines sont nécessaires mais peu différenciants. Ils forment les sous-domaine-support. Ils méritent un bon niveau de qualité, mais sans sur-investissement conceptuel. L’objectif est ici l’efficacité et la cohérence, pas l’innovation métier.
Enfin, les sous-domaine-générique regroupant les fonctionnalités banales, communes à de nombreux systèmes. Pour ces domaines, la stratégie n’est pas de modéliser finement, mais de standardiser, acheter ou externaliser. Toute sophistication inutile y constitue une dette sans retour sur investissement.
Un outil de conversation, pas un simple diagramme
La véritable force du Core Domain Chart ne réside pas dans sa représentation visuelle, mais dans les conversations qu’il suscite. Cet outil agit avant tout comme un support de dialogue, permettant de confronter les points de vue et de rendre explicites des choix qui restent trop souvent implicites.
Les experts métier y apportent leur vision de la différenciation et de la valeur stratégique, tandis que les ingénieurs mettent en lumière la complexité réelle des systèmes et les enjeux techniques associés. De leur côté, les équipes produit jouent un rôle d’arbitrage en croisant ces éléments avec les contraintes de délais, de coûts et d’alignement stratégique. Le chart devient alors un langage commun, facilitant la prise de décision sur les domaines dans lesquels il est pertinent d’investir fortement, mais aussi sur ceux où il est inutile, voire contre-productif, de rechercher l’excellence.
Enfin, un point essentiel mérite d’être souligné : les équipes ne peuvent pas se proclamer elles-mêmes “Core”. La désignation d’un Core Domain relève exclusivement du métier, et du métier seul. C’est à lui qu’il revient d’identifier quels Bounded Contexts constituent un véritable avantage concurrentiel et lesquels doivent être traités comme des domaines de support ou génériques. Cette clarification est indispensable pour aligner durablement les efforts techniques avec la stratégie business.
Prioriser par la complexité du code
Prioriser les chantiers de modernisation uniquement à l’aune de la valeur métier est une démarche indispensable, mais qui s’avère insuffisante lorsqu’elle est appliquée seule. Si la valeur métier permet d’identifier ce qui est stratégique pour l’organisation, elle ne donne qu’une vision partielle des enjeux réels d’un projet de modernisation.
Dans le cadre d’une modernisation de code, cette valeur doit impérativement être mise en perspective avec la complexité du code existant, c’est-à-dire avec le niveau de dette technique accumulée. Un domaine à forte valeur métier, mais porté par un socle technique fragile, complexe ou mal maîtrisé, n’implique ni la même stratégie, ni le même rythme de transformation qu’un domaine plus simple et moins risqué.
Il est donc essentiel de croiser ces deux critères — valeur métier et dette technique — pour éclairer les décisions de modernisation. Cette double lecture permet d’adapter les approches, de maîtriser les risques et, in fine, de construire une priorisation plus réaliste et plus efficace, alignée à la fois sur les objectifs métier et sur les contraintes techniques existantes.
Rapport analyses SonarQube sur le nombre de lignes par projet
Pour l’ensemble des équipes impliquées dans une démarche de modernisation, il est essentiel de s’appuyer sur des analyses objectives et partagées. Les outils d’analyse de code, par exemple SonarQube, jouent ici un rôle clé en fournissant une vision factuelle de l’état réel du code. Ces analyses permettent de comparer différents périmètres sur des bases homogènes et mesurables, et doivent être menées suffisamment en amont afin de disposer d’indicateurs solides à partager avec les équipes de management en charge du pilotage de la transformation.
Parmi les métriques mobilisées pour qualifier la complexité technique, on retrouve notamment la complexité cyclomatique, la complexité cognitive, le volume de lignes de code, le nombre de fonctions ou de méthodes, ainsi que le taux de duplication du code, exprimé en pourcentage ou en nombre de lignes et de blocs dupliqués. Pris ensemble, ces indicateurs permettent d’appréhender concrètement la difficulté de compréhension, de test et d’évolution du code existant, au-delà des seules perceptions ou ressentis des équipes.
À l’issue de cette analyse, le croisement entre la priorisation par la valeur métier et la mesure de la complexité technique permet de définir une trajectoire de modernisation à la fois pragmatique et maîtrisée (avec une matrice de décision par exemple). Cette approche aide à identifier les domaines et les équipes à engager en premier, en tenant compte du retour sur investissement attendu autant que du niveau de risque technique. Elle contribue ainsi à sécuriser les premières étapes de la transformation et à installer une dynamique durable et crédible de modernisation.
Le budget reste la dernière étape avant débuter la modernisation
L’approche proposée s’appuie sur un découpage organisationnel par équipes, chacune responsable d’un périmètre fonctionnel clairement défini. Pour chaque périmètre, une analyse est conduite selon deux axes complémentaires : la valeur métier générée et le niveau de dette technique associé au code maintenu. Ce regard croisé permet d’objectiver les décisions et d’éviter une priorisation dictée uniquement par l’urgence ou l’intuition. En s’appuyant sur des arbitrages stratégiques explicites, cette priorisation structurée offre un cadre pragmatique pour piloter la modernisation du système d’information.
Toutefois, ces deux critères ne suffisent pas toujours à eux seuls. D’autres contraintes peuvent entrer en ligne de compte, comme le calendrier des fonctionnalités à venir, des engagements produits déjà pris, ou encore des dépendances fortes avec d’autres équipes. Ces éléments doivent être discutés collectivement afin de converger vers une décision éclairée sur les premières équipes à engager dans la démarche de modernisation.
Cette discussion partagée permet d’aligner les enjeux métier, les réalités techniques et les contraintes organisationnelles. La force de l’approche réside alors dans la granularité des Bounded Contexts, qui sont au cœur de la modélisation du domaine et se retrouvent naturellement au centre de la priorisation. Cette cohérence d’ensemble offre une grande flexibilité : elle permet de moduler la trajectoire de modernisation progressivement, à votre rythme, tout en conservant une vision maîtrisée et alignée du système.
Piloter la modernisation par vagues successives
Plutôt que de lancer un chantier global, long et risqué, la transformation est conduite par vagues successives. Cette approche incrémentale permet de livrer régulièrement de la valeur tout en évitant l’effet tunnel souvent associé aux programmes de modernisation de grande ampleur. Selon les contraintes budgétaires et organisationnelles, il est ainsi possible de ne mobiliser qu’une seule équipe à la fois ou, au contraire, d’en engager plusieurs en parallèle lorsque les moyens le permettent.
Sur le plan technique, la manière dont le code est testé et remanié rend inutile la création de branches dédiées à la modernisation. Le travail s’effectue en continu sur le tronc principal : le code n’est jamais figé, il est validé quotidiennement et la modernisation progresse sans interrompre le flux normal de développement. Le cassage des dépendances, loin de fragiliser le système, consiste à enrichir le code existant afin de l’ouvrir aux tests et de le rendre progressivement plus modulable et maîtrisé.
Cet exemple illustre un pilotage de la modernisation mené équipe par équipe, sur une période de huit mois. L’objectif est d’avancer de manière incrémentale, en limitant les risques tout en maximisant l’apprentissage et la montée en compétence collective.
Une vague de huit mois se décompose en deux demi-vagues de quatre mois. La première est consacrée à la modernisation de l’organisation de la première équipe. En parallèle, une partie de l’équipe est accompagnée dans le développement de nouvelles compétences techniques, afin de préparer sereinement les évolutions à venir.
La seconde demi-vague porte sur la modernisation technique à proprement parler. Les pratiques, l’outillage et le code évoluent progressivement, en s’appuyant sur les acquis organisationnels et les compétences renforcées lors de la phase précédente. Les équipes suivantes sont ensuite engagées selon l’ordre de priorité défini par le management, en fonction des contraintes et du budget restant. Cette approche progressive permet d’ajuster la trajectoire au fil des retours d’expérience et de sécuriser l’ensemble de la transformation.
Accompagnement de l'équipe
Pendant la demi-vague de modernisation de l’organisation, il est recommandé d’engager une montée en compétences de l’équipe de développement afin de la préparer à la demi-vague suivante, dédiée à la modernisation du code. Cette anticipation joue un rôle clé pour réduire les risques, aligner les pratiques et créer les conditions nécessaires à une transformation technique efficace et maîtrisée.
La préparation de l’équipe s’est déroulée sur une période de quatre mois, avec pour objectif l’acquisition progressive de nouvelles compétences. Cette phase amont était indispensable pour sécuriser la suite de la démarche et établir un socle commun de pratiques, de langage et de compréhension partagé par l’ensemble des développeurs. Elle a permis de créer un cadre de travail homogène, propice à l’alignement technique et métier avant d’aborder les aspects les plus complexes de la modernisation.
Dès le lancement de cette période, un accompagnement dédié a été mis en place afin de soutenir la montée en compétences. Chaque mois était structuré autour d’un axe précis, permettant à l’équipe de se concentrer pleinement sur une pratique clé et d’en expérimenter concrètement les apports dans son contexte quotidien. Cette progression par paliers a favorisé l’appropriation des concepts, tout en laissant le temps nécessaire à leur assimilation et à leur mise en pratique.
Lors de la demi-vague suivante, les équipes entrent dans la phase opérationnelle de modernisation du code. Il est alors important de mesurer l’écart entre l’apprentissage de pratiques dans un cadre maîtrisé et leur mise à l’épreuve sur un code legacy massif et complexe. C’est pour cette raison que la présence d’un coach technique devient essentielle pour accompagner et piloter la modernisation. Ce coach participe aux ateliers de découverte afin de s’imprégner du contexte métier et d’assurer une continuité entre la compréhension du domaine et les choix techniques effectués.
Dans cette démarche de remaniement du code, même une équipe formée peut être intimidée par l’ampleur du legacy à refactorer. L’accompagnement joue ici un rôle clé : il permet de rassurer les développeurs, de structurer les différentes phases de la modernisation et d’éviter une approche désordonnée ou décourageante. Le coach aide également à prioriser les actions et à maintenir un rythme soutenable pour l’équipe.
Il est donc impératif d’accompagner étroitement les équipes de développement, d’autant plus que la charge mentale est élevée, notamment sur le plan métier. Les informations recueillies lors des phases exploratoires — ateliers, échanges avec le métier, modélisation — constituent une matière précieuse qui doit être distillée progressivement dans la phase de remaniement du code. Cet accompagnement continu garantit que la complexité est absorbée de manière maîtrisée et que la modernisation s’inscrit dans une trajectoire durable et sécurisée.
Conclusion générale
L’approche de modernisation présentée s’inscrit résolument dans une vision socio-technique. Elle met en avant un ensemble de valeurs et de principes qui dépassent largement la seule transformation du code ou des outils. Il s’agit d’une évolution globale, qui engage tout autant les modes de collaboration, les pratiques managériales et les mécanismes de pilotage. La modernisation devient ainsi un levier pour repenser l’articulation entre organisation, pratiques techniques et objectifs stratégiques.
Dans ce cadre, le management adopte une posture renouvelée, davantage orientée vers le leadership que vers le contrôle opérationnel. Son rôle principal consiste à porter la stratégie de l’entreprise et à la rendre lisible à travers des objectifs clairs et partagés, notamment par la définition des OKR. Ces objectifs jouent un rôle de boussole : ils donnent un cap commun aux équipes tout en leur laissant l’autonomie nécessaire quant aux moyens mis en œuvre pour l’atteindre. De nombreuses entreprises ont démontré l’efficacité de cette approche. Google, par exemple, s’appuie fortement sur les OKR pour décliner et adapter finement sa stratégie à chaque niveau de l’organisation.
L’organisation est alors structurée en fonction des problèmes métier à résoudre et de la charge cognitive soutenable par chaque équipe. Ce découpage favorise la clarté des responsabilités, la maîtrise de la complexité et une capacité de décision accrue au plus près du terrain. Il permet également un alignement plus naturel entre les équipes et les domaines métiers qu’elles servent, réduisant ainsi les frictions et les zones de flou organisationnel.
Cette cohérence socio-technique se prolonge naturellement dans les choix d’architecture technique. Les architectures ne sont plus pensées de manière abstraite ou uniquement guidées par des considérations technologiques : elles découlent directement de la structure des équipes, de leurs objectifs et de leur compréhension du domaine. Cet alignement renforce à la fois la robustesse des systèmes et leur capacité à évoluer durablement face au changement.
Une organisation pérenne repose sur un équilibre fondamental entre dimensions humaine et technique, tel que le rappelle le Manifeste Socio-Tech. Ces deux dimensions sont indissociables et doivent être pensées conjointement. Optimiser les systèmes sans tenir compte des personnes, ou inversement, conduit inévitablement à des organisations fragiles. Dans cette perspective, le management n’est pas un organe de contrôle, mais un levier au service des équipes, chargé de créer les conditions de leur réussite.
Conformément aux principes du Manifeste Socio-Tech, les relations au sein et entre les équipes rejettent toute forme de soumission. La performance ne naît pas de l’obéissance, mais de l’engagement. Le management favorise ainsi l’émancipation en permettant aux équipes de comprendre les enjeux, de participer aux décisions et d’exercer pleinement leur jugement professionnel.
L’autonomie, la responsabilité et la confiance deviennent alors des prérequis essentiels à la performance collective. Donner de l’autonomie implique d’accepter la prise d’initiative et le droit à l’erreur, tout en renforçant la responsabilité sur les résultats. La confiance, comme le souligne le Manifeste Socio-Tech, n’est jamais acquise : elle se construit dans la durée, par la transparence, la coopération et la clarté des responsabilités.
Dans cette logique, les systèmes, les outils et les processus doivent être conçus pour s’adapter au travail réel tel qu’il est pratiqué sur le terrain, et non l’inverse. Cette orientation, au cœur du Manifeste Socio-Tech, reconnaît que la qualité d’un système dépend autant de son architecture technique que de la manière dont les humains interagissent avec lui. C’est dans cet alignement entre organisation et technologie que l’entreprise trouve sa capacité à durer et à évoluer.
Apprivoiser un legacy conséquent ne se résume pas à réécrire du code ou à moderniser une architecture. Penser le contraire relève d’une illusion largement répandue. L’expérience montre que, quelques années après des initiatives pourtant ambitieuses, de nombreuses organisations retombent dans les mêmes travers.
Une transformation ne devient réellement pérenne que lorsqu’elle s’attaque à ce qui se joue en profondeur : la culture de l’entreprise. Cela suppose d’ancrer durablement des valeurs et des principes socio-techniques forts au sein des équipes, et d’investir dans le développement continu des compétences. Sans discipline exigeante d’hygiène du code, sans pratiques collectives assumées et sans responsabilité technique partagée, toute modernisation est vouée à l’érosion.
C’est à l’intersection de la culture, des pratiques et de l’exigence technique que la transformation cesse d’être cosmétique pour devenir durable.
À travers ces différentes dimensions, cette approche de modernisation propose une lecture globale du système : de sa valeur métier, de son organisation et de sa capacité à évoluer dans le temps. En l’appliquant, les organisations gagnent une maîtrise conjointe de leur code et de leur structure, grâce à la structuration par domaines, à l’objectivation de la complexité et à l’alignement des équipes.
Synthèse de la troisième et dernière partie
Le Core Domain Chart constitue un outil central de distillation stratégique. Il permet de rendre visibles et partageables les différences de valeur et de complexité entre les sous-domaines du système. En classant les domaines selon leur contribution à l’avantage concurrentiel et leur niveau de complexité, il devient possible d’adapter la stratégie de modernisation en fonction de la nature de chaque sous-domaine, qu’il s’agisse du cœur de métier, de domaines support ou de domaines génériques.
Cette lecture met rapidement en évidence une limite fréquente : la valeur métier seule ne suffit pas à prioriser. Dans une démarche de modernisation, il est indispensable d’intégrer la dette technique et la complexité réelle du code existant. Un domaine à forte valeur, mais techniquement fragile ou difficile à faire évoluer, nécessite une stratégie et un rythme spécifiques, différents de ceux d’un périmètre plus simple et maîtrisé. Le niveau de risque technique devient ainsi un critère structurant des décisions.
Pour objectiver ces choix, il est essentiel de s’appuyer sur des analyses factuelles et partagées. Des outils comme SonarQube permettent de mesurer la complexité du code de manière tangible et comparable. En s’appuyant sur des indicateurs communs, les équipes peuvent confronter différents périmètres sur des bases solides, dépassant les impressions subjectives pour fonder la décision sur des données mesurables.
Le croisement entre valeur métier, dette technique et contraintes organisationnelles permet alors de définir une trajectoire de modernisation pragmatique. Cette approche aide à identifier les équipes à engager en priorité et à sécuriser les premières étapes de la transformation, là où les risques sont les plus élevés et les apprentissages les plus critiques.
Cette trajectoire doit également intégrer les contraintes réelles de l’organisation, notamment le budget disponible et le calendrier fonctionnel. La granularité apportée par les sous-domaines et les équipes offre une flexibilité précieuse, permettant de moduler l’effort de modernisation dans le temps et d’ajuster les choix au fil de l’avancement.
Plutôt que de viser une transformation globale, la modernisation est pilotée par vagues successives. Cette approche incrémentale permet de livrer régulièrement de la valeur, de limiter les risques et d’adapter le nombre d’équipes engagées en fonction des moyens disponibles. Chaque vague combine généralement une phase de transformation organisationnelle et une phase de modernisation du code, afin d’aligner pratiques, compétences et socle technique.
Enfin, l’ensemble de cette démarche s’inscrit dans une approche résolument socio-technique. La modernisation n’est pas uniquement une affaire d’architecture ou de code, mais un levier de transformation globale de l’organisation. Elle articule stratégie, management, pratiques d’ingénierie et dynamiques humaines pour construire un système durable, capable d’évoluer dans le temps sans retomber dans les travers du passé.