3.6 Modernisation des systèmes hérités

Vue d’ensemble et motivation

Les systèmes hérités sont les systèmes qui font tourner le monde. Les grands livres bancaires centraux, les moteurs fiscaux et de prestations, les systèmes de contrôle aérien et de défense, l’administration de polices d’assurance, et les registres gouvernementaux dont dépendent les sociétés ont fréquemment des décennies. Beaucoup sont écrits en COBOL (Common Business-Oriented Language) ou d’autres technologies plus anciennes, et ils traitent encore la majorité des transactions critiques. « Hérité » n’est pas une insulte. Cela signifie que le système est assez précieux pour avoir survécu, assez critique pour que l’échec soit catastrophique, et assez ancien pour que le changer en sécurité soit difficile. La modernisation des systèmes hérités est la discipline d’améliorer, migrer, ou remplacer ces systèmes sans casser les services essentiels qu’ils fournissent.

C’est un problème disproportionnellement d’entreprise et gouvernemental, et c’est là que se produisent les plus grands échecs informatiques les plus publics. Une vaste part des transactions majeures dans le monde touche encore des systèmes mainframe. Une grande fraction du code de production dans les grandes institutions est dans des langages plus anciens maintenus par un bassin de spécialistes vieillissant et rétrécissant. Les gouvernements portent le fardeau le plus lourd : des obligations légales codées sur des décennies, des cycles d’approvisionnement et de budget qui survivent aux administrations, et des services citoyens qui ne peuvent pas être interrompus. Le risque dominant n’est pas que ces systèmes soient vieux, puisque beaucoup fonctionnent superbement. C’est que le savoir pour les maintenir prend sa retraite, les plateformes sont de plus en plus coûteuses et contraintes, et la tentation de « simplement le réécrire » mène à certains des échecs les plus coûteux de l’histoire du domaine.

Ce chapitre couvre les motifs de modernisation incrémentale qui fonctionnent réellement (figuier étrangleur et branche par abstraction), comment évaluer et prioriser le risque hérité, la gestion des parcs mainframe et COBOL, la discipline de la migration de données et de l’exploitation en parallèle, et par-dessus tout comment résister à la tentation de la grande réécriture. La conviction centrale est qu’une modernisation réussie est presque toujours incrémentale, fondée sur des preuves, et livre continuellement de la valeur. Ce n’est jamais un grand fracas de plusieurs années.

Principes clés

Hérité signifie précieux et fondateur, pas simplement vieux. Respectez ce que fait le système avant d’y toucher ; il codifie des décennies de règles métier durement acquises.
L’incrémental bat le grand fracas, presque toujours. Remplacez morceau par morceau derrière une interface stable ; livrez de la valeur continuellement et gardez le risque petit.
La grande réécriture est le mode d’échec par défaut. Les réécritures complètes dépassent couramment les délais, sous-livrent, et sont annulées ; traitez l’envie avec une profonde suspicion.
Vous ne pouvez pas moderniser ce que vous ne comprenez pas. Rétro-concevez et documentez le comportement (incluant les règles non documentées) avant de le remplacer.
La migration de données est là où les projets meurent. Les données sont plus vieilles, plus sales, et plus emmêlées que quiconque ne s’y attend ; planifiez-les comme un effort de premier ordre.
Faites fonctionner l’ancien et le nouveau en parallèle pour construire la confiance. L’exploitation en parallèle et la comparaison attrapent les divergences avant la bascule.
Priorisez par risque et valeur, pas par âge. Modernisez ce qui est le plus risqué et le plus précieux en premier, pas ce qui est simplement le plus vieux.
Gardez les lumières allumées pendant que vous changez le moteur. Le service doit continuer de fonctionner tout du long ; il n’y a pas de temps d’arrêt acceptable pour les systèmes citoyens ou financiers critiques.

Recommandations

Moderniser incrémentalement avec le motif du figuier étrangleur

Le figuier étrangleur (nommé d’après la liane qui pousse autour d’un arbre et le remplace graduellement) est le cheval de trait de la modernisation sûre. Placez une couche de routage (une passerelle API, une façade, ou un proxy) devant le système hérité. Puis, capacité par capacité, construisez le remplacement dans un système moderne et redirigez cette tranche de trafic vers lui, laissant le reste sur le système hérité. Avec le temps, le nouveau système grandit et l’ancien rétrécit, jusqu’à ce qu’il puisse être retiré. Cela livre de la valeur continuellement, garde chaque changement petit et réversible, évite une bascule risquée, et vous permet d’arrêter ou de reprioriser à tout moment. C’est l’opposé du grand fracas. Le système hérité continue de fonctionner et de gagner sa place pendant que vous le remplacez autour de lui.

Utiliser la branche par abstraction pour les coutures internes

Là où vous devez remplacer un composant dont dépendent de nombreuses parties du système, utilisez la branche par abstraction. Introduisez une couche d’abstraction (une interface) au-dessus de l’implémentation existante, migrez les appelants pour qu’ils dépendent de l’abstraction, construisez la nouvelle implémentation derrière la même abstraction, basculez (souvent derrière un indicateur de fonctionnalité, graduellement), et enfin retirez l’ancienne implémentation. Cela permet à un grand composant d’être remplacé incrémentalement sur la ligne principale de développement sans branche de longue durée, gardant le système livrable tout du long. Cela s’associe naturellement au figuier étrangleur : la façade gère les coutures externes, la branche par abstraction gère les internes.

Évaluer et prioriser délibérément le risque hérité

Avant de moderniser, construisez un inventaire et une évaluation de risque lucides du parc. Pour chaque système, notez-le sur la criticité métier, le risque technique (obsolescence, plateformes non soutenues, exposition de sécurité), la fréquence de changement, et, crucialement, le risque de connaissance (combien de personnes peuvent encore le maintenir, et à quel point elles sont proches de la retraite). Tracez les systèmes sur une grille risque-contre-valeur. Priorisez la modernisation de ce qui est à la fois à haut risque et haute valeur. Envisagez de laisser tranquilles les systèmes stables, à faible changement, et bien compris même s’ils sont vieux, parce qu’un système fonctionnel que personne n’a besoin de changer n’est pas une urgence. Cette évaluation transforme « tout est vieux et effrayant » en une feuille de route défendable et séquencée.

Gérer le parc mainframe et COBOL, pas seulement le remplacer

Tout système mainframe ou COBOL ne devrait pas, ou ne peut pas en sécurité, être remplacé bientôt. La priorité à court terme est souvent la gestion : capturer le savoir avant qu’il ne parte à la retraite. Documentez les règles métier que le code codifie (une grande partie non documentée et irremplaçable), investissez dans des tests automatisés qui fixent le comportement actuel pour que le changement futur soit sûr, recrutez et formez de façon croisée des mainteneurs, et modernisez les pratiques de livraison environnantes (contrôle de source, intégration continue (CI), test automatisé) même pendant que le cœur reste en place. Là où vous modernisez réellement, préférez exposer les capacités héritées à travers des API modernes (encapsulation) comme premier pas. Traitez la traduction automatisée COBOL-vers-langage-moderne avec prudence, parce qu’elle produit du code qui fonctionne mais reproduit souvent fidèlement une logique incompréhensible. La ressource la plus rare est la compréhension, pas le calcul.

Traiter la migration de données et l’exploitation en parallèle comme le cœur du projet

La partie la plus difficile et la plus risquée de la plupart des efforts de modernisation est les données. Elles sont volumineuses, de qualité médiocre et incohérente, et pleines de sens non documenté accumulé sur des décennies. Profilez-les et nettoyez-les, cartographiez explicitement les anciens vers les nouveaux schémas, et construisez une migration répétable et automatisée avec une réconciliation complète (comptes, sommes de contrôle, totaux métier) pour pouvoir prouver que rien n’a été perdu ou altéré. Dé-risquez la bascule avec l’exploitation en parallèle : faites fonctionner l’ancien et le nouveau système côte à côte sur les mêmes entrées et comparez les sorties jusqu’à ce que le nouveau système corresponde à l’ancien à votre seuil de confiance. Seulement alors basculez, et gardez la capacité de revenir en arrière. Pour les systèmes véritablement critiques, migrez et basculez par tranches plutôt que d’un coup.

Gérer la tentation de la grande réécriture

L’instinct de jeter le vieux système désordonné et d’en construire un nouveau propre à partir de zéro est puissant, et il est presque toujours faux pour les grands systèmes critiques. Les réécritures complètes sous-estiment la valeur cachée dans le code « laid » (cas limites, règles réglementaires, comportements compatibles-avec-les-bugs dont dépendent de vrais utilisateurs), prennent bien plus longtemps que prévu, ne livrent aucune valeur avant la fin, et sont fréquemment annulées après une dépense énorme. Par défaut, optez pour la modernisation incrémentale. Réservez les réécritures aux cas où la plateforme est vraiment insoutenable et où les chemins incrémentaux sont épuisés. Même alors, décomposez la réécriture en morceaux livrables indépendamment via le motif étrangleur plutôt qu’une seule livraison à grand fracas. Quand la direction pousse pour une réécriture totale, insistez sur la question : quelle valeur est livrée dans les trois premiers mois, et que se passe-t-il si le programme est arrêté à mi-chemin ?

Compromis : avantages et inconvénients

Approche	Avantages	Inconvénients
Figuier étrangleur (incrémental)	Valeur continue, faible risque, réversible, garde le service en fonctionnement	Calendrier global plus long, doit faire tourner deux systèmes en parallèle, surcharge d’intégration
Réécriture à grand fracas	Table rase, pas de contraintes héritées dans le nouveau code	Taux d’échec très élevé, aucune valeur avant la fin, coût énorme, règles métier perdues
Encapsuler (envelopper avec des API)	Rapide, faible risque, modernise l’accès sans toucher au cœur	Le cœur reste hérité ; diffère, ne résout pas, le risque sous-jacent
Laisser tel quel (gérer)	Aucun risque de projet ; le moins cher à court terme	Le risque de connaissance et de plateforme continue de s’accumuler ; action forcée éventuelle

Le compromis fondamental est la vitesse de transformation contre le risque d’échec, et la modernisation des systèmes hérités est le domaine où cet échange est le plus déséquilibré. La réécriture « rapide, propre » à grand fracas est un mirage qui produit systématiquement le résultat le plus lent et le plus coûteux de tous : un programme annulé et un système toujours non modernisé. Les approches incrémentales semblent plus lentes et exigent de faire fonctionner deux systèmes en parallèle, mais elles livrent de la valeur tout du long, gardent le risque petit et réversible, et sont le chemin empiriquement fiable. Le vrai jugement à porter est entre gérer un système hérité stable un peu plus longtemps et commencer le remplacement incrémental maintenant. Laissez la trajectoire de risque piloter cet appel, spécialement le risque de connaissance, plutôt que l’inconfort avec une vieille technologie.

Questions à discuter avec votre équipe

Avez-vous un endroit où placer une couche de routage devant votre système hérité, et sinon, que faudrait-il pour en créer un ? Le figuier étrangleur dépend d’une couture : une passerelle API, une façade, ou un proxy à travers lequel vous pouvez rediriger une capacité à la fois vers une nouvelle implémentation. De nombreux vieux systèmes n’ont pas une telle couture, donc le premier incrément de modernisation est souvent simplement de construire le point d’interception, et ce travail est facile à sous-estimer. Apportez la carte d’intégration actuelle et demandez où le trafic pourrait être intercepté par capacité sans une bascule à grand fracas. S’il n’y a nulle part, la branche par abstraction sur une couture interne peut être le mouvement de départ à la place. Sans couche de routage, vous n’avez pas de chemin incrémental, ce qui est exactement comment les organisations sont repoussées vers la réécriture qui échoue généralement.
Avez-vous réellement tracé votre parc sur une grille risque-contre-valeur, ou votre feuille de route est-elle pilotée par quel système semble le plus vieux ? Le chapitre insiste sur le fait de moderniser d’abord ce qui est à haut risque et haute valeur, et de laisser délibérément tranquilles les systèmes stables, à faible changement, et bien compris même quand ils sont anciens. Sans grille explicite, l’attention va vers la plainte la plus forte ou la technologie la moins à la mode, et de vraies bombes à retardement (un système critique avec deux mainteneurs proches de la retraite) attendent. Notez chaque système sur la criticité métier, le risque technique, la fréquence de changement, et le risque de connaissance, puis séquencez depuis le coin supérieur droit. Apportez cette grille à la réunion comme la carte partagée. Le risque de connaissance mérite le poids le plus lourd, parce que c’est la seule entrée qui ne fait qu’empirer et ne peut pas être rachetée une fois que les gens partent.
Quand vous basculez, comment prouverez-vous qu’aucun enregistrement unique n’a été perdu ou altéré, et qui valide cette preuve ? La migration de données est là où ces projets meurent, et la confiance vient de la réconciliation : des comptes de lignes, des sommes de contrôle, et des totaux de contrôle métier qui correspondent entre l’ancien et le nouveau, plus une exploitation en parallèle qui compare les sorties sur les mêmes entrées jusqu’à ce qu’elles s’accordent à un seuil élevé. Pour un système de prestations ou de grand livre, une divergence est un citoyen sous-payé ou un centime perdu, donc la preuve doit satisfaire un auditeur, pas seulement un ingénieur. Décidez maintenant quels totaux vous réconcilierez, quel seuil de confiance déclenche la bascule, et combien de temps vous ferez fonctionner l’ancien et le nouveau en parallèle. Gardez le retour en arrière disponible tout du long, et basculez par tranches plutôt que d’un coup. Les divergences que vous trouvez pendant l’exploitation en parallèle sont généralement des règles héritées non documentées que vous devez préserver, donc traitez chacune comme une découverte, pas juste un défaut.
Lesquels de vos systèmes hérités gérez-vous contre remplacez-vous activement, et qui a décidé lequel est lequel ? Le chapitre trace une ligne délibérée entre les systèmes qui valent la peine d’être stabilisés en place (documenter les règles, ajouter des tests de caractérisation, former de façon croisée les mainteneurs) et les systèmes qui valent la peine d’être remplacés incrémentalement, et les deux exigent un financement et une dotation en personnel très différents. Pour une grande organisation, le danger est la dérive : un système étiqueté « géré pour l’instant » devient discrètement « géré pour toujours » jusqu’à ce que le dernier mainteneur parte à la retraite et que le choix soit fait pour vous sous crise. Les considérations concurrentes sont le coût de gestion et l’obsolescence de plateforme d’un côté contre le risque et la perturbation du remplacement de l’autre, et le risque de connaissance devrait faire pencher la balance parce qu’il ne fait qu’empirer. Apportez la grille risque-contre-valeur, l’effectif de mainteneurs et l’horizon de retraite pour chaque système, et un propriétaire explicite pour la décision gérer-ou-remplacer. Dans les parcs d’entreprise et gouvernementaux, nommez une cadence de révision et un fonctionnaire responsable pour chaque système, parce qu’une classification que personne ne révise est une décision que personne ne prend.
Quand la direction demande une réécriture complète, quelle est votre réponse standard, et pouvez-vous montrer ce qu’un chemin incrémental livre dans les trois premiers mois ? La réécriture à grand fracas est le mode d’échec par défaut, pourtant elle continue d’être financée parce qu’une table rase est facile à vendre et qu’un figuier étrangleur ne l’est pas. Une grande équipe a besoin d’une réponse répétée pour que l’argument soit gagné sur preuve plutôt que sur qui est le plus senior dans la pièce. La vraie tension est que certaines plateformes sont réellement insoutenables et qu’une réécriture est justifiée, donc la réponse ne peut pas être un refus général : elle doit peser si des coutures incrémentales existent encore contre le vrai coût de garder l’ancienne plateforme vivante. Apportez la valeur qu’un premier incrément incrémental livrerait, le taux d’échec historique de réécritures comparables, et une décomposition de toute réécriture proposée en morceaux livrables indépendamment. En administration publique, où un programme de plusieurs années annulé brûle de l’argent public en pleine vue, insistez sur le fait que toute réécriture livre de la valeur tôt et survit à un arrêt à mi-chemin sans perte totale.
Comment capturerez-vous les règles métier verrouillées dans votre code le plus ancien avant que les gens qui les comprennent ne soient partis ? Une grande partie de la valeur dans un système hérité est un comportement non documenté que des décennies de cas limites, de réglementations, et de correctifs compatibles-avec-les-bugs ont accumulé, et il vit dans un bassin rétrécissant de spécialistes qui prennent leur retraite plutôt que dans un quelconque enregistrement écrit. Pour une grande organisation, c’est le seul risque qui ne peut pas être racheté une fois que les gens partent, donc il mérite un financement en avance du travail de plateforme plus visible. La tension concurrente est que la capture de connaissance (documentation, tests de caractérisation, rétro-ingénierie, formation croisée) semble être une surcharge qui ne livre rien, ce qui est exactement pourquoi elle est différée. Apportez un inventaire de qui détient le savoir critique, à quel point ils sont proches de partir, et quelle couverture de test fixe le comportement actuel aujourd’hui. Dans les contextes régulés et publics, traitez les règles légales codées dans le vieux code comme un actif de conformité : les perdre silencieusement n’est pas de la dette technique, c’est une exposition légale.

Regard sectoriel

Jeune pousse. Votre héritage est votre propre MPV pressé, pas un mainframe : un prototype qui porte maintenant du revenu et que tout le monde a peur de toucher. Ne le réécrivez pas. Enveloppez le module le plus effrayant derrière une interface propre, ajoutez des tests de caractérisation pour fixer son comportement, et extrayez la fonctionnalité incrémentalement pour que chaque petite livraison apporte de la valeur et réduise le risque. Vous n’avez pas de marge pour une reconstruction à partir de zéro, donc l’optionalité compte plus que l’élégance.

Petite entreprise. Vous n’avez pas d’équipe de modernisation et un budget serré, donc le mouvement pratique est généralement de garder un système fonctionnel fonctionnel : capturez ce que sait la seule personne qui le comprend, mettez-le dans le contrôle de source avec quelques tests automatisés, et appuyez-vous sur un fournisseur ou un produit packagé plutôt qu’une reconstruction sur mesure. Cadrez la décision comme acheter contre construire, et préférez acheter quand la capacité est une commodité. Dépensez votre effort limité sur le seul système dont l’échec arrêterait l’affaire, pas sur celui qui semble simplement le plus vieux.

Grande entreprise. Le problème est l’échelle de portefeuille : des dizaines de systèmes, de nombreuses équipes, et un risque de connaissance à l’échelle du parc. Exécutez une évaluation risque-contre-valeur partagée, standardisez sur des motifs incrémentaux (figuier étrangleur et branche par abstraction), et traitez la migration de données et l’exploitation en parallèle comme des disciplines de premier ordre avec une réconciliation en laquelle tout le monde a confiance. Gouvernez la modernisation comme un portefeuille continu contre la trajectoire de risque plutôt qu’une dispersion de projets héroïques, et budgétez explicitement la gestion et la capture de connaissance pour qu’aucun système critique ne dépende d’un seul mainteneur en retraite.

Gouvernement. Les obligations légales codées sur des décennies, les règles d’approvisionnement, et les services citoyens qui ne peuvent pas être interrompus rendent le remplacement à grand fracas particulièrement dangereux. Favorisez la migration incrémentale par figuier étrangleur avec une bascule tranche par tranche, prouvez par réconciliation et longue exploitation en parallèle qu’aucun enregistrement citoyen n’a été perdu ou mal calculé, et gardez le retour en arrière disponible tout du long. L’approvisionnement devrait exiger la portabilité des données et la divulgation des règles métier plutôt qu’une traduction opaque, et tout programme de plusieurs années doit livrer une valeur auditable tôt et survivre à l’examen public s’il est arrêté à mi-chemin.

Exemples

Jeune pousse. Le MVP original d’une start-up de trois ans est devenu son propre genre d’héritage : un prototype précipité qui gère maintenant du vrai revenu et que tout le monde a peur de toucher. Plutôt qu’une réécriture, l’équipe enveloppe le pire module derrière une interface propre, ajoute des tests de caractérisation pour fixer son comportement actuel, et déplace la fonctionnalité hors de lui morceau par morceau sur quelques mois. Chaque petite livraison apporte de la valeur et réduit la partie effrayante, donc la start-up obtient un système maintenable sans parier l’entreprise sur une reconstruction à partir de zéro qu’elle ne peut pas se permettre.

Grande entreprise. Un grand assureur exploite l’administration de polices sur un système mainframe COBOL qui est fiable mais coûteux à changer et maintenu par une poignée d’ingénieurs approchant de la retraite. Plutôt qu’une réécriture, l’assureur enveloppe le mainframe avec des API modernes et applique le figuier étrangleur : de nouvelles capacités de devis-et-achat et de libre-service sont construites sur une plateforme moderne et acheminées à travers une façade, tandis que les dossiers de police centraux restent sur le mainframe. En parallèle, l’équipe documente les règles métier et ajoute des tests de caractérisation autour du COBOL. Sur plusieurs années, capacité après capacité quitte le mainframe, chaque livraison apportant de la valeur, jusqu’à ce que le cœur restant puisse être retiré selon les conditions de l’assureur plutôt que sous crise.

Gouvernement. Une agence de sécurité sociale doit moderniser un système de calcul de prestations vieux de plusieurs décennies qui paie des millions de citoyens et ne peut être interrompu ni mal payer. Elle rejette un remplacement à grand fracas après avoir étudié des programmes échoués comparables. Au lieu de cela, elle profile et nettoie les données, construit une migration automatisée avec réconciliation complète contre des totaux de contrôle, et fait fonctionner le nouveau moteur de prestations en parallèle avec l’ancien pendant de nombreux mois, alimentant les deux avec les mêmes demandes et comparant chaque calcul, investiguant chaque divergence (découvrant souvent des règles héritées non documentées qui doivent être préservées). Seulement une fois que le nouveau système correspond à l’ancien avec une très haute confiance bascule-t-elle type de prestation par type de prestation, gardant le retour en arrière tout du long. La façade étrangleur permet aux citoyens de voir un service continu unique à travers la transition.

Argumentaire économique : motivations, retour sur investissement et coût total de possession

La modernisation des systèmes hérités a un argumentaire économique inhabituel, parce que le plus grand coût est souvent le coût de l’inaction et le plus grand risque est le projet de modernisation lui-même. Les coûts croissants de ne pas moderniser sont concrets : maintenance et licences croissantes sur des plateformes obsolescentes, une main-d’œuvre spécialisée de plus en plus rare et chère, incapacité de satisfaire rapidement de nouvelles demandes réglementaires ou de service, et exposition croissante à un échec catastrophique sans personne qui comprend encore le système. Contre cela, le coût de la modernisation est élevé, et fait comme un grand fracas il porte une probabilité d’échec vraiment élevée. C’est précisément pourquoi l’approche incrémentale compte pour le retour sur investissement : elle convertit un seul grand pari en une série de petits qui rapportent chacun de la valeur et peuvent être arrêtés.

Faites valoir cela auprès de la direction en recadrant le choix. La question n’est pas « moderniser ou pas ». C’est « moderniser incrémentalement maintenant, ou payer des coûts de gestion croissants et affronter une modernisation forcée et à plus haut risque plus tard sous crise ». Quantifiez le CTP du statu quo (coûts de plateforme et de licence, la prime pour des compétences rares, le coût pondéré par le risque d’une panne irrécupérable) et comparez-le à un programme échelonné qui réduit le risque et le coût à chaque incrément tout en gardant le service en fonctionnement. De façon critique, insistez pour que toute réécriture proposée soit structurée pour livrer de la valeur tôt et souvent. Un programme qui ne livre rien pendant trois ans et peut être annulé avec une perte totale n’est pas un investissement ; c’est un pari. L’argument de retour sur investissement le plus fort pour l’approche étrangleur est l’optionalité : la valeur est livrée continuellement et l’organisation peut ajuster le cap à tout moment.

Anti-patterns et pièges

La réécriture à grand fracas. Un remplacement tout-ou-rien de plusieurs années qui ne livre aucune valeur avant la fin et est fréquemment annulé à grands frais.
Réécrire sans comprendre. Remplacer du code dont les règles métier n’ont jamais été documentées, laissant tomber silencieusement des cas limites dont dépendent de vrais utilisateurs et des lois.
Sous-estimer les données. Traiter la migration de données comme une réflexion après coup alors que c’est la partie la plus difficile et la plus risquée du projet.
Sauter l’exploitation en parallèle. Basculer vers le nouveau système sans comparaison en parallèle, découvrant les divergences seulement après qu’elles affectent de vraies personnes.
La traduction automatisée comme solution. Traduire automatiquement du COBOL vers un langage moderne et croire que le travail est fait, produisant du code incompréhensible qui reproduit l’ancienne logique mot pour mot.
Moderniser par âge, pas par risque. Dépenser de l’effort sur des systèmes vieux-mais-stables pendant que des systèmes à haut risque et fort changement attendent.
Perdre le savoir. Laisser les derniers mainteneurs partir à la retraite sans capturer les règles métier et ajouter des tests de caractérisation.
Pas de retour en arrière. Basculer sans moyen de revenir en arrière quand le nouveau système se comporte mal sous charge réelle et données réelles.

Modèle de maturité

Niveau 1 (Initier) : Les systèmes hérités sont craints et gelés ; le changement est évité. Aucun inventaire ou évaluation de risque n’existe. La modernisation, quand elle est tentée du tout, est une réécriture ad hoc tout-ou-rien pilotée par la frustration. Le savoir vit dans quelques têtes en retraite avec rien d’écrit.
Niveau 2 (Développer) : Certaines équipes ont un inventaire et un sens approximatif du risque, et quelques systèmes hérités sont enveloppés avec des API pour l’accès. Les motifs incrémentaux sont connus mais appliqués de façon inégale, et la pensée dérive encore vers les réécritures à grand fracas. La migration de données est tentée mais sous-estimée, et la pratique varie largement d’une équipe à l’autre.
Niveau 3 (Standardiser) : Les systèmes sont priorisés par risque et valeur contre une méthode documentée et à l’échelle de l’organisation. Les motifs incrémentaux (figuier étrangleur, branche par abstraction) sont la valeur par défaut imposée, et chaque modernisation suit un playbook standard. La migration de données est un effort planifié et réconcilié avec exploitation en parallèle avant bascule, et la capture de connaissance et les tests de caractérisation sont une pratique requise plutôt qu’optionnelle.
Niveau 4 (Gérer) : La modernisation est mesurée et contrôlée avec des données. Le parc porte des références : effectif de mainteneurs et horizon de retraite par système, couverture de test de caractérisation, taux de réussite de réconciliation de migration, comptes de divergence d’exploitation en parallèle, et valeur livrée par incrément, tous suivis contre des cibles. Les décisions gérer-ou-remplacer et les décisions de feu vert de bascule sont prises sur cette preuve, et un système dérivant au-delà de son seuil de risque de connaissance déclenche une action plutôt que d’attendre une crise.
Niveau 5 (Orchestrer) : La modernisation est continue, intégrée à la planification d’affaires et de risque, et adaptative. Le portefeuille est rééquilibré contre la trajectoire de risque (spécialement le risque de connaissance) à mesure qu’elle change, le remplacement incrémental est routinier et sans drame, chaque incrément livre de la valeur et est réversible, et l’organisation pilote le rythme délibérément. Les leçons de chaque migration alimentent en retour le playbook partagé pour que tout le parc s’améliore dans le temps.

Pistes de réflexion

Pour votre système hérité le plus critique, combien de personnes peuvent encore le maintenir, et à quel point sont-elles proches de partir ?
Où êtes-vous tenté par une réécriture à grand fracas, et quelle valeur une approche incrémentale pourrait-elle livrer dans les trois premiers mois à la place ?
Dans quelle mesure les règles métier dans vos systèmes les plus vieux sont-elles documentées, et que leur arrive-t-il si le code est remplacé ?
Avez-vous profilé les données que vous devriez migrer, et savez-vous à quel point elles sont réellement sales et emmêlées ?
Sur quels systèmes vieux-mais-stables dépensez-vous de l’énergie de modernisation que vous pourriez laisser tranquilles en sécurité ?
Pourriez-vous faire fonctionner votre nouveau système en parallèle avec l’ancien et prouver qu’ils s’accordent avant de basculer ?

Points clés à retenir

Hérité signifie précieux et fondateur ; respectez et comprenez un système avant de le changer.
Modernisez incrémentalement avec le figuier étrangleur et la branche par abstraction, livrant de la valeur continuellement et gardant chaque changement petit et réversible.
Traitez la réécriture à grand fracas comme le mode d’échec par défaut ; réservez-la aux plateformes vraiment insoutenables et même alors décomposez-la.
Priorisez par risque et valeur (spécialement le risque de connaissance), pas par âge ; certains vieux systèmes sont mieux gérés, pas remplacés.
La migration de données et l’exploitation en parallèle sont le cœur de l’effort ; profilez, réconciliez, faites fonctionner en parallèle, et gardez le retour en arrière.
L’argumentaire économique le plus fort est l’optionalité : la modernisation incrémentale convertit un gros pari risqué en de nombreux petits qui rapportent de la valeur.

Références et lectures complémentaires

Michael Feathers, Working Effectively with Legacy Code
Martin Fowler, « StranglerFigApplication » et « BranchByAbstraction »
Sam Newman, Monolith to Microservices
Nicholas Carr / études industrielles sur la dépendance mainframe et COBOL (contexte sur l’échelle des parcs hérités)
Robert Annett, Working with Legacy Systems
Eric Evans, Domain-Driven Design (couche anti-corruption)
Gregor Hohpe, Enterprise Integration Patterns et The Software Architect Elevator
Standish Group CHAOS Report (preuves sur les taux d’échec des grands projets et réécritures)