Rehost, Replatform, Refactor… quelle stratégie de modernisation SI choisir ?

Moderniser un système d’information vieillissant ne se résume pas à up grader l’infrastructure ou à déplacer des VM vers un cloud. C’est un chantier structurant qui engage la DSI pour plusieurs années : architecture, sécurité, compétences, organisation… et surtout, capacité à livrer. Aujourd’hui, la question n’est pas tant une question de migration que dans quel ordre et avec quelle stratégie. Il faut aussi intégrer le maintien en condition opérationnelle, pendant cette période sans exploser les coûts ni embarquer la dette technique dans un nouvel environnement.

Les DSI doivent arbitrer entre contraintes budgétaires, technologies en fin de vie, dette IT, dépendances éditeurs (voire prestataires de services) et nécessité d’intégrer de nouvelles technologies : IA, automatisation, plateforme data, moderne, API, event-driven. etc. Il fut un temps où « passer au cloud » aurait réussi à régler cela, on sait aujourd’hui que c’était illusoire. Le cloud n’est pas une stratégie de migration, c’est un moyen. On peut certes gagner en agilité… mais on peut surtout déplacer sa dette à grande vitesse !

Nous vous proposons un mini-série de 2 épisodes pour concevoir une grille de décision opérationnelle, application par application.

Certains parlent de modèles 5R ou 7R, chez Harington, nous privilégions l’approche 6R : Retire, Retain/Encapsulate, Rehost, Replatform, Refactor, Rearchitect/Rebuild. Elle permet de choisir la stratégie la plus adaptée à chaque brique du SI en fonction de la valeur métier, des risques, de l’effort et de l’alignement avec l’architecture cible (SI AI-ready, cloud-native, API-first, modulaire / composable, microservices & DDD). »

Anis Bessa, directeur général, harington

Dans ce premier épisode, nous verrons les choix les plus “pragmatiques” à faire, c’est-à-dire ceux qui permettent de réduire le périmètre, de stabiliser et de gagner du temps sans avoir à lancer une refonte globale :

• R1 Retire : arrêter ce qui ne doit plus exister
• R2 Retain/Encapsulate : conserver mais en reprenant les interfaces (API / événements)
• R3 Rehost : migrer utile rapidement, sans transformation

Moderniser un SI, pourquoi une stratégie de modernisation ?

Le legacy, le fameux iceberg

Souvent, on résume le Legacy à une vieille personne mais la réalité est plus complexe. On utilise souvent l’image de l’iceberg. La partie visible, ce sont les applications, les serveurs, les versions, les incidents, les performances. La partie immergée, celle qui réserve globalement tout le temps des mauvaises surprises et qui est un gouffre financier comprend toutes les dépendances. Et c’est un véritable plat de spaghettis (autre image connue sic) : flux batch implicites, intégrations spécifiques, règles métiers encodées dans des scripts, données dupliquées, droits d’accès historiques, contrats éditeurs, compétences rares et une maintenance souvent construite au rythmes des urgences et autres patchs.

Moderniser un SI legacy, c’est travailler sur un système vivant qui fait tourner le business de l’entreprise et c’est pour cela que c’est critique :

• des dépendances techniques (interfaces, middleware, bases, IAM, réseau),
• des dépendances métier (process, référentiels, usages, obligations),
• des dépendances organisationnelles (qui maintient, qui déploie, qui arbitre),
• et des dépendances contractuelles (éditeurs, infogérance, licences, obsolescence programmée).

Sans stratégie, la modernisation finit en une pile de microdécisions locales. Et un SI modernisé “localement”, c’est un SI incohérent globalement.

Pourquoi “migrer vers le cloud” n’est pas une stratégie

Le cloud est un levier, pas une finalité. On peut y gagner en agilité, en résilience, en time-to-market, en capacité d’automatisation (CI/CD, infra as code, observabilité). Le risque, c’est surtout d’y déplacer sa dette technique avec le même code, les mêmes les problèmes, les mêmes dépendances… Et cela fait à vitesse grand V avec la facture qui va avec !

Une stratégie de modernisation du SI répond, c’est surtout savoir répondre à des questions essentielles :

• Qu’est-ce qu’on arrête ? : Réduction de périmètre
• Qu’est-ce qu’on conserve mais qu’on “découple” ? : Maîtrise des interfaces, API-first, event-driven
• Qu’est-ce qu’on migre vite sans transformer ? : Continuité, contraintes timing
• Qu’est-ce qu’on transforme pour préparer l’avenir ? : Cloud-native, architecture composable, IA-ready

Le sujet n’est jamais “cloud vs pas cloud” dans la réalité des projets. C’est la trajectoire, à savoir de nombreux arbitrages à faire sur le portefeuille applicatif et son alignement avec l’architecture SI cible.

Le prérequis ? Diagnostiquer avant d’arbitrer

Le diagnostic, ce n’est pas un vaste inventaire de l’existant. C’est une cartographie qui va permettre de prendre les décisions qui s’imposent. Elle montre toutes les dépendances et les zones de couplage. Elle permet de trier puis de prioriser.

Sur un portefeuille applicatif, l’objectif est de qualifier ce qui est le plus important en termes de valeur métier pour chaque application en fonction de la criticité opérationnelle, la contribution au chiffre d’affaires, l’exposition client, etc. Le diagnostic permet aussi objectiver le niveau de risque qu’il s’agisse de cybersécurité, de conformité, de continuité d’activité, d’obsolescence technologique ou de contraintes sectorielles.

Il mesure aussi la complexité à venir en termes de transformation : degré de dépendance aux autres briques du SI, densité des flux, sensibilité des données, gestion des droits et des accès, contraintes contractuelles liées aux éditeurs. Enfin, il spécifie les capacités de passage à l’échelle, c’est-à-dire la visibilité sur le fonctionnement à venir comme la possibilité de revenir en arrière de retour arrière, le niveau d’automatisation, la maturité CI/CD et la qualité des pratiques de mise en production et de supervision.

Ce diagnostic, c’est aussi un moment de vérité. Non, toutes les applications ne sont pas “à moderniser” inexorablement. Certaines doivent être décommissionnées, d’autres optimisées et certaines gardées en étant en les encapsulant correctement.

Dans la plupart des cas SI que nous avons eu chez Harington, la création de valeur commence déjà par la réduction du périmètre, bien avant d’ouvrir le vaste chantier d’une refonte.

Aligner les 6R sur les objectifs business

La stratégie de modernisation du SI n’a de valeur que si elle met bien en perspective les choix technologiques dans la stratégie globale. Dans la réalité, les DSI arbitrent entre :

• Capacité du delivery : réduire le time-to-market, industrialiser les déploiements, éviter un “gel ” du SI
• Maîtrise du risque : sécurité, conformité, auditabilité, continuité
• Maîtrise des coûts : FinOps, rationalisation, réduction de la dette, limitation des licences
• Innovations : SI AI-ready, API-first, architecture modulaire/composable, event-driven, capacités d’automatisation.

Le modèle 6R est un framework intéressant parce qu’il traduit ces objectifs en décisions, application par application. Il permet d’éviter deux écueils fréquents : le “tout refondre” (coûteux, long, risqué) et le “tout migrer” (rapide, pas de bénéfice structurel).

Qu’est-ce le modèle des 6R en modernisation SI ?

Spoiler : il n’existe pas de méthode universelle

Quand on s’engage sur le sujet de la modernisation du SI, on a tendance ce à cherche LA bonne méthode. Spoiler ! Elle n’existe pas. Il n’y a pas de stratégie universelle applicable à toutes les applications. Les applications n’ont en effet pas le même rôle métier, pas le même niveau de couplage, pas la même exposition au risque, ni la même capacité à évoluer.

Définir chaque “R”, de trier à transformer

Chez Harington, le modèle 6R est utilisé comme grille de décision, orientée arbitrage et trajectoire globale. Les 6 R couvrent l’ensemble du spectre, de la réduction de périmètre jusqu’à la transformation globale SI. Ce n’est pas une méthode miracle, en revanche cela met de l’ordre !

Retire consiste à éliminer ce qui est obsolète et inutile.

Retain et Encapsulate visent à conserver ce qui fonctionne tout en reprenant la main sur les interfaces, via APIs ou even-driven pour découpler le SI et contourner les contraintes du “monolithe”.

Rehost correspond à une migration rapide sans transformation du code, utilisée pour répondre à des contraintes de time-to-market, de fin de support ou de sortie d’un datacenter. A noter que Rehost ne répond absolument aux objectifs cloud-native ou IA-ready…

Replatform permet des adaptations ciblées, en basculant vers des services managés ou en modernisant le runtime pour gagner en stabilité et en efficacité.

Refactor lance la modernisation du code et des dépendances afin de préparer une architecture API-first et event-driven.

Et pour finir, Rearchitect ou Rebuild abordent les cas où la refonte est indispensable pour atteindre une architecture SI cible modulaire, composable, microservices et DDD avec des capacités d’automatisation et de passage à l’échelle.

Ce modèle est intéressant parce qu’il rend les choix explicites. Choix que l’on est amené à faire au fur et à mesure quoi qu’il y en soit. Sans méthode, ces choix finisseent par aboutir à un SI hybride subi qui ne répond pas convenablement à la trajectoire et aux objectifs fixés.

Dans la vraie vie, on mixe trajectoires et stratégies

Dans la réalité des projets, choisir le bon « R » pour telle ou telle application n’est pas si simple. On mixe souvent plusieurs stratégies dans le temps ou par sous-ensemble d’applications. Par exemple, une application peut être conservée mais encapsulée pour découpler le SI, puis replatformée pour sécuriser le runtime, avant un refactor progressif sur les composants qui portent le plus de valeur. De la même façon, un rehost peut servir de transition tactique à condition d’être assumé comme tel, avec une trajectoire vers une cible plus durable. Le modèle 6R n’est donc pas un menu, c’est une boussole sur un terrain complexe et accidenté.

Dans cet épisode, nous nous concentrons sur les trois choix les plus “pragmatiques”, ceux qui permettent de réduire le périmètre, de stabiliser et d’avancer sans lancer immédiatement une transformation lourde. Nous allons détailler Retire, Retain/Encapsulate et Rehost, en explicitant les cas d’usage, les garde-fous et les signaux qui indiquent qu’il faut passer au “R” suivant. Les options plus transformantes, Replatform, Refactor et Rearchitect/Rebuild seront traitées dans l’Épisode 2 avec la matrice de décision Harington, les erreurs à éviter et une checklist opérationnelle pour trier un portefeuille applicatif.

Retire : arrêter ce qui doit l’être

Redondance, obsolescence, zéro valeur, ces signes qui ne trompent pas

Retire est souvent le “R” le plus rentable et étonnement le moins mis en œuvre au sein des DSI…. Dans le portefeuille applicatif, on a tendance à garder des briques par prudence. Pourtant, elles ne génèrent plus de valeur et consomment des coûts.

Les signaux sont comparables d’un SI à l’autre. La redondance fonctionnelle est la plus fréquente. On a deux outils font la même chose mais personne ne tranche.

L’obsolescence lourde arrive juste derrière, notamment lorsque la technologie n’est plus supportée que les compétences sont rares ou coûteuse ; ou encore que chaque patch est une aventure à haut risque.

On le voit typiquement sur certains environnements historiques comme le mainframe (COBOL) ou AS/400, mais aussi sur des stacks BI et intégration déployées depuis longtemps, par exemple Cognos, BusinessObjects, SAS ou des plateformes ETL très customisées. Même scénario quand des applications restent figées sur des runtimes en retard (Java ancien, .NET Framework, PHP 5, Python 2).

Enfin, il y a le cas le plus fréquent mais le moins assumé … L’application ne porte plus de valeur métier mesurable et survit parce qu’elle “a toujours été là”.

Retirer ne veut pas dire casser. Cela veut dire décider que l’application n’a plus sa place dans l’architecture cible et que le meilleur investissement consiste à réduire drastiquement le périmètre. Ce « R » est beaucoup fantasmé et fait peur. Dans la réalité, c’est un soulagement.

Sécuriser : dépendances, archivage, auditabilité, conformité

Le vrai sujet du Retire n’est pas technique. Avant de décommissionner, il faut définir ce qui dépend réellement de l’application. Les dépendances cachées sont l’écueil courant comme les les flux batch, les extractions “maison”, les interfaces historiques ou les usages non documentés côté métier. Un retrait sécurisé demande de prévoir l’archivage et la conservation des données (et la durée) car il est indispensable de préserver ce qui doit l’être selon les obligations internes et externes.

La modernisation SI se joue aussi sur l’auditabilité. Retirer une application ne doit pas dégrader la capacité à justifier un traitement, retracer un accès, prouver une conservation, ou répondre à une demande de contrôle. Qu’il s’agisse de RGPD de compliance spécifique à votre secteur d’activité ou de contraintes de continuité, le Retire demande de mettre en place une gouvernance des risques autant que le chantier technologique à mener.

Décider : gouvernance, sponsors, “sunset plan”

Un Retire sans sponsor est une décision qui peut vous hanter à chaque incident ! La solution, c’est le “sunset plan” avec un propriétaire métier identifié, un calendrier et des critères de sortie définis. On ne décide pas de débrancher comme ça, tel ou tel jour. Cela se fait par étapes avec le gel des évolutions, la réduction des usages, la bascule vers un outil cible puis l’arrêt définitif.

Cela permet d’éviter des drames comme découvrir au dernier moment qu’une équipe, un processus critique ou un partenaire dépendait encore de l’application. Le R se pilote.

Retain & Encapsulate : conserver… mais pas à n’importe quel prix

Quand conserver du legacy est rationnel (et même intelligent)

Retain, ce n’est pas un renoncement mais également un arbitrage à faire. Certaines legacy sont critiques, stables, maîtrisées et coûteux s’il fallait les répondre pour des gains limités. Les conserver est la bonne solution si la valeur métier est forte, le risque sous contrôle et si l’organisation dispose encore des compétences nécessaires à le faire fonctionner.

Dans une stratégie de modernisation SI, Retain est même intelligent lorsqu’il s’inscrit dans une architecture cible cohérente. Autrement dit, on conserve, mais on prépare la suite, notamment en travaillant l’interface et le découplage.

Encapsuler pour découpler : API-first, couche d’API, anti-corruption layer

Encapsuler, c’est conserver un cœur applicatif legacy tout en reprenant la main sur les échanges avec le reste du SI. Concrètement, on met en place une couche d’API (façade) qui normalise les accès, renforce la sécurité et évite la multiplication d’intégrations spécifiques point à point. Dans les SI très couplés, l’anti-corruption layer a un rôle essentiel : il isole le modèle legacy, traduit les données et les règles de gestion et empêche que les contraintes historiques ne se propagent dans les nouveaux composants.

C’est aussi un prérequis pour un SI AI-ready. Tant que les interactions avec le legacy restent pilotées par l’IHM ou par une logique de traitement embarquée côté front et complétées par des intégrations point à point fragiles, l’automatisation et l’orchestration par des agents IA est illusoire. En encapsulant le cœur legacy derrière une couche d’API et des contrats d’échange stables, on crée des points d’entrée standardisés, sécurisés et traçables, indispensables pour industrialiser les usages et faire évoluer le SI sans rupture.

Encapsuler par l’événementiel : bus, CDC, architecture orientée événement

Lorsque l’on cherche à gagner en réactivité, en traçabilité et à réduire le couplage entre applications, une architecture orientée événements devient un levier très efficace. Le principe consiste à diffuser des événements métier sur un bus ou une plateforme de streaming plutôt que de multiplier les appels synchrones point à point, ce qui permet de découpler les producteurs et les consommateurs et de faire évoluer le SI de façon progressive. Dans cette logique, le CDC (Change Data Capture) est souvent une étape logique pour moderniser sans rupture en exposant les changements de données de manière contrôlée et industrialisée, le temps de refondre les composants qui le nécessitent.

Le point de vigilance est dans l’architecture et la gouvernance. L’événementiel ne doit pas devenir un “tuyau ” : sans conventions de nommage, contrats de messages, gouvernance des schémas et observabilité des flux ; on remplace un couplage historique par un couplage différent, qui sera encore plus difficile à diagnostiquer.

Faire cohabiter legacy & cloud sans créer un SI “à deux vitesses”

La cohabitation legacy & cloud est un passage quasi obligé. Le risque, c’est de créer un SI à deux vitesses où les produits modernes livrent en continu, tandis que le legacy impose des cycles longs, des exceptions et des contournements. L’encapsulation limite cet effet en imposant un contrat d’échange stable, en sécurisant les accès et en rendant les dépendances explicites.

Côté pilotage, la règle d’or a appliqué est que chaque exception doit être temporaire et documentée. Sinon, la cohabitation s’ancre dans la durée et n’est plus une transition.

Retour d’expérience de modernisation SI

Dans une entreprise régulée accompagnée par Harington, une application cœur de gestion des contrats était robuste, mais fortement couplée au reste du SI et adossée à une IHM vieillissante. Plutôt que de s’engager dans un refactoring, l’équipe a choisi d’encapsuler le legacy derrière une couche d’API afin de standardiser les échanges et sécuriser les accès. Les interfaces ont ensuite été modernisées progressivement en découplant la logique de traitement et en basculant les usages vers de nouveaux services au fur et à mesure. Quelques événements métier clés ont également été exposés sur le bus pour alimenter des services périphériques et des cas d’usage data. Résultat : une modernisation visible pour les utilisateurs, une baisse du couplage applicatif, et une trajectoire maîtrisée vers une architecture plus composable, sans interruption significative de service.

Rehost : le lift & shift, utile… mais pas miraculeux

Ce que le rehost permet vraiment : rapidité, réduction de risque infra

Rehost, c’est l’autoroute ! On déplace une application “as is” vers une nouvelle infrastructure, souvent pour sortir d’un datacenter, respecter une contrainte de fin de support ou tenir un rétroplanning infaisable. Le bénéfice est immédiat sur la couche infrastructure avec un risque fonctionnel généralement limité puisque le code ne change pas. Dans certains contextes, c’est un choix raisonnable notamment lorsqu’on a besoin d’acheter du temps sans arrêter le business.

Ce qu’il ne règle jamais : dette technique, rigidité, coûts d’exploitation

Le rehost ne modernise absolument pas l’application. Il modernise son adresse ! La dette technique reste identique, le couplage reste identique et les limites d’évolutivité restent identiques. Pire, si l’on ne prépare pas la suite, le lift and shift peut produire un “legacy dans le cloud” avec une facture d’infrastructure et d’exploitation très élevée, sans aucun bénéfice bien en tendu sur l’architecture cible.

C’est particulièrement vrai si l’objectif est cloud-native ou SI AI-ready. Rehost ne rend pas une application API-first, ne crée pas de traçabilité et ne transforme pas une dépendance à un monolithe en architecture composable.

Les cas où le rehost est pertinent

Le rehost est pertinent lorsqu’il est assumé comme une étape tactique avec une trajectoire de transformtion SIclaire. C’est le bon choix quand l’organisation doit réduire un risque immédiat, gagner du temps ou traiter une contrainte externe forte, tout en sachant qu’un replatform, un refactor ou une refonte seront nécessaires sur les applications à forte valeur. Le rehost est aussi utile lorsqu’il permet de standardiser un socle de base, de préparer l’observabilité ou de mettre en place des pratiques de déploiement plus industrialisées, avant d’engager des transformations plus profondes.

Garde-fous : FinOps, observabilité, “exit plan” vers les R suivants

Un rehost sans garde-fous est inenvisageable. Les deux fondamentaux sont le FinOps et l’observabilité. Le FinOps permet d’éviter le piège de la dérive de coûts et d’objectiver le rapport valeur/prix des choix d’infrastructure. L’observabilité permet de stabiliser et de comprendre ce qui conditionne toute transformation à venir.

Enfin, il faut un exit plan explicite. Le rehost doit pointer vers le “R suivant”, même si la date n’est pas inscrite dans le marbre. Sans cela, on appelle “stratégie” ce qui n’est qu’un déplacement du problème.

Moderniser le SI commence par stabiliser et simplifier pour planifier la suite

Les 3 erreurs à éviter dès le départ

La première erreur consiste à traiter la modernisation du SI comme un simple projet de migration technique sans vision globale ni pilotage du portefeuille applicatif. La deuxième est de privilégier la rapidité au détriment de la création de valeur en enchaînant des opérations de rehost sans trajectoire cible clairement définie, ce qui revient souvent à déplacer la dette technologique plutôt qu’à la réduire. La troisième erreur est de sous-estimer l’importance du découplage en conservant des applications legacy sans véritable stratégie d’encapsulation, ce qui verrouille l’architecture cible et limite durablement les capacités d’automatisation et d’intégration de nouveaux usages, notamment autour de l’IA.

Transition : quand passer de Pragmatique à Transformateur ?

Dans cet épisode n°1, nous avons voulu poser les choix les plus pragmatiques à engager en amont d’un programme de modernisation du SI : réduire le périmètre applicatif, stabiliser l’existant et redonner de la marge de manœuvre à la DSI. Mais dès qu’une application porte une forte valeur métier, qu’elle est critique dans la chaîne de traitement ou qu’elle doit absorber une montée en charge significative, des choix de transformation deviennent inévitables.

Sans trop en dévoiler, l’Épisode 2 traitera des stratégies Replatform, Refactor et Rearchitect/Rebuild, ainsi que de la matrice de décision Harington, pour arbitrer avec méthode, éviter les impasses et aligner durablement le SI sur une cible cloud-native et AI-ready.

A lire en complément sur ce sujet :

• Migrer ses applications dans le cloud : quelle méthode choisir ?
• Modernisation du SI, les objectifs des DSI
• Modernisation ? Votre SI mérite mieux qu’un patch de plus.
• Pourquoi est-il urgent de moderniser votre système d’information ?
• Modernisation du SI et poids du Legacy ?
• Cartographie du SI : quelles étapes pour un diagnostic réussi ?