Retire et Retain : les deux stratégies souvent négligées de la migration
Quand on parle migration cloud, on imagine généralement que tout doit partir vers AWS. C'est une erreur coûteuse. Deux des six modèles de transformation, Retire et Retain, sont paradoxalement les plus rentables et les plus rapides à mettre en oeuvre, mais aussi les plus mal évalués en phase d'assessment.
Retire signifie arrêter l'application. Retain signifie la garder on-premise, ou en tout cas ne pas la migrer actuellement. Ni l'un ni l'autre ne produit de ligne d'investissement tape-à-l'oeil. Pourtant, arrêter une application obsolète réduit la dette technique, libère des ressources et simplifie le portefeuille informatique. Conserver on-premise une application critique mais trop liée à l'infrastructure historique évite une migration coûteuse et hasardeuse, tout en libérant le budget pour les vrais gains cloud.
C'est précisément sur ces deux décisions que les équipes traînent. Elles craignent de rater de la valeur, de mécontenter un métier, ou simplement elles ne savent pas par où commencer pour évaluer si une application mérite vraiment un ticket de migration. Le framework des 6R vous aide à trancher.
Retire : quand arrêter une application coûte moins que de la maintenir
Une application est candidate à Retire dès qu'elle satisfait au moins l'un de ces critères : elle n'a plus d'utilisateurs actifs réguliers, elle génère peu ou pas de valeur métier, elle remplit une fonction dupliquée par un autre système, ou le coût de maintenance et licence dépasse le bénéfice quantifiable.
La confusion vient souvent du fait qu'une application "historiquement importante" reste en portefeuille par habitude. On continue à la maintenir, à patcher, à former les rares utilisateurs, sans se demander si elle crée encore du chiffre d'affaires. Pire, une migration cloud force l'équipe IT à la relancer, la transformer, et y investir massivement, alors qu'elle aurait pu être abandonnée pour quasi rien.
Pour identifier les candidates Retire, commencez par l'usage : qui l'utilise réellement et combien de fois par mois ? Si le chiffre est inférieur à, disons, quelques dizaines de transactions mensuelles, ou si la fonction est couverte par un autre outil moderne (ERP, plateforme SaaS, etc.), la migration n'a aucun sens. Passez à l'analyse coût-bénéfice simple : divisez le coût total annuel de maintenance, licence, infrastructure, support par le bénéfice quantifié (chiffre d'affaires supporté, économies, productivité). Si le ratio est inférieur à 0,1 ou 0,2, l'application n'existe que par inertie.
Retire comporte aussi un bénéfice caché : réduire la surface de sécurité, simplifier la conformité (moins de systèmes à auditer), et diminuer la complexité du portefeuille IT. Une équipe qui gère 20 applications critiques est plus productive qu'une qui en gère 50 dont la moitié dort. Avant de signer un devis de migration, purgez donc ce backlog.
Retain : les applications qui doivent rester on-premise aujourd'hui
Retain est le choix inverse. L'application a de la valeur et des utilisateurs actifs, mais migrer coûterait trop cher, prendrait trop longtemps, ou cimenterait des dépendances avec l'infrastructure on-premise qu'on n'a pas le temps de démêler avant la migration.
Les candidats Retain classiques incluent les monolithes legacy fortement imbriqués dans l'infrastructure locale, les systèmes de base de données spécialisées (base de données propriétaire, appliance avec matériel physique), les applications qui dépendent d'intégrations réseau très basse latence, et les systèmes qui requièrent des certificats ou des configurations hardware spécifiques difficiles à reproduire en cloud.
Une autre catégorie d'applications relevante pour Retain : celles dont la migration est techniquement possible mais dont le ROI est trop faible. Par exemple, une application critériée mais stable, consommant peu de ressources, peu d'utilisateurs, peu de maintenance. Migrer une telle application coûte facilement trois à six fois plus cher qu'elle ne le justifie. La rationalité économique commande alors de la laisser en place. L'infrastructure on-premise finit par être un musée de ces applications, ce qui est normal : l'objectif du cloud n'est pas de déplacer tout ce qui existe, mais de réaligner le portefeuille IT sur la vraie valeur métier.
Retain peut aussi être un choix temporaire. Une application complexe peut rester on-premise aujourd'hui, en attendant une version future plus légère qu'on pourra migrer, ou en attendant que la dette technique soit remboursée en interne avant d'envisager une transformation cloud. Cette approche réduit le risque : plutôt que de forcer une migration à tout prix dans un calendrier de 18 mois, on laisse l'équipe infrastruture se concentrer sur les gains immédiats et on revisite Retain dans un an.
Critères concrets pour trancher entre Retire et Retain
Pour ne pas que la décision soit subjective, appliquez une grille minimale. Voici les questions à poser pour chaque application candidate :
- Qui l'utilise et combien de fois par mois ? Si moins de 50 transactions mensuelles ou quelques dizaines d'utilisateurs, elle penche vers Retire ou Retain très conservateur.
- Quel est le coût annuel total, infrastructure plus maintenance plus licences, divisé par le chiffre d'affaires supporté ou l'économie générée ? Si le ratio est supérieur à 1 (coût > bénéfice), c'est un signal Retire. Si le ratio est entre 0,5 et 1, c'est Retain en attente d'optimisation ou Retire si la dette technique est trop élevée.
- Quelles sont ses dépendances avec d'autres applications ? Si elle dépend d'une dizaine d'autres systèmes pour fonctionner, ou si une dizaine d'autres dépendent d'elle, la migrer devient un chantier complexe. Retain devient plus intelligent, sauf si ces dépendances elles-mêmes partent au cloud (auquel cas démêlez les intégrations d'abord).
- Quel est l'effort estimé pour la migrer en jours-homme ? En règle de pouce, si elle demande plus de 50 à 100 jours pour Rehost (la migration la plus simple), elle est candidate Retain, au moins temporairement, sauf si le bénéfice métier est stratégique.
- Existe-t-il une alternative SaaS ou une version cloud-native du même outil ? Si oui, Repurchase ou Refactor devient intéressant et Retire de l'ancienne version suit naturellement. Si non, Retain est le choix logique.
- Quel est le risque métier de l'arrêter ou de la laisser en place ? Un système critique qui ne supporte aucune discontinuité doit être Retain, au moins pendant quelques mois. Une application "nice to have" peut être Retire sans exposer l'entreprise.
Cette évaluation ne demande pas un assessment cloud de trois mois. Elle requiert une réunion de trois heures avec le propriétaire métier, l'IT ops, et un architecte. Le résultat : une liste purgée d'une trentaine à cinquante pour cent des applications.
Retire et Retain dans le cadre de la matrice 6R
Le framework des 6R classe chaque application selon le type de transformation la mieux adaptée. Retire et Retain en font intégralement partie, au même titre que Rehost, Replatform, Refactor, ou Repurchase. Cette classification n'est pas un plan d'action minute par minute ; c'est une décision stratégique qui doit être prise dans les deux à trois premières semaines d'un assessment cloud.
La matrice 6R (ou la Matrice de sélection 6R telle que Stralya la propose) rassemble les critères d'évaluation : complexité technique de l'application, valeur métier, dépendances, coût de migration estimé, durée d'implémentation, et risque métier. Retire et Retain sont généralement situés aux deux extrêmes : Retire apparaît quand la valeur est très faible et que l'arrêt ne pose aucun risque ; Retain apparaît quand la valeur est élevée mais que la complexité ou les dépendances rendent la migration trop coûteuse pour le moment.
Ce classement ne signifie pas Retire ou Retain définitivement. C'est une photographie du moment T. Une application Retain aujourd'hui peut basculer en Rehost dans deux ans, quand les dépendances auront été déliées ou qu'une version cloud-native de la même fonction sera disponible. Une application Retire peut être réclamée par le métier si le besoin change. L'intérêt de la matrice 6R est de rendre ces décisions explicites et révisables, et surtout de distinguer les migrations qui ont du sens de celles qui n'en ont pas.
Intégrer Retire et Retain dans le plan de migration
Une fois que vous avez classé vos applications en Retire, Retain, et les autres, la phase d'exécution devient claire. Les candidates Retire disparaissent du roadmap : elles sont simplement arrêtées selon un calendrier de décommissionnement (généralement quelques semaines à quelques mois pour collecter les données d'audit, notifier les utilisateurs, etc.). Cet arrêt réduit le coût global du projet de migration, libère des ressources humaines et des cycles d'équipe.
Les applications Retain restent en place. Elles ne consomment pas de budget migration, mais elles demandent une décision à long terme : continuez-vous à les maintenir on-premise dans une infrastructure historique, ou créez-vous une stratégie "îlots Retain" légers, regroupant vos applications Retain sur une infrastructure minimale et sécurisée ? Certaines organisations choisissent de laisser les applications Retain telles quelles ; d'autres les consolident sur un sous-ensemble de serveurs ou migrent vers une infrastructure on-premise virtualisée et allégée, libérant ainsi la majorité de l'infrastructure historique pour la fermeture.
La discipline à respecter : les applications Retain ne doivent jamais devenir un fourre-tout de l'inaction. Une revue annuelle ou bisannuelle doit évaluer si les hypothèses initiales tiennent toujours. Si une application Retain a vu sa charge user exploser, peut-être qu'une migration d'une partie des flux en cloud vaut le coup. Si le métier demande une augmentation de capacité pour une application Retain, demandez-vous si vous ne gagneriez pas en agilité et en coût en la migrant plutôt qu'en renforçant l'infrastructure on-premise.
Pour les applications Retire, le suivi est simple : elles disparaissent à la date X. Après la date, l'équipe IT ne parle plus d'elles. C'est un gain net en complexité et en coût de maintenance.
Pièges à éviter avec Retire et Retain
Le premier piège est la paralysie décisionnelle. Les organisations accumulent les applications au fil des années, et l'idée d'en arrêter une suscite des objections émotionnelles ("mais c'est un projet qu'on avait financé il y a dix ans") ou organisationnelles ("telle équipe en a encore besoin en cas de panne de l'autre système"). Fixez-vous une règle simple : si l'usage est inférieur à X et que le métier n'en dépend pas directement, arrêt avant la fin du projet migration. Les objections post-facto sont très rares quand l'application n'existe vraiment plus.
Le deuxième piège est de garder en Retain une application à cause de craintes techniques exagérées. L'équipe IT dit : "la migrer serait trop compliquée, elle est trop intégrée", sans avoir étudié concretement l'effort. Quelques jours d'assessment minutieux peuvent montrer que Rehost est en fait à la portée, et qu'une fois migrée, l'application consomme moins de ressources et coûte moins cher. Investissez 10 jours d'étude avant de décider Retain, pas zéro.
Le troisième piège : laisser les applications Retain se multiplier, devenir une majorité silencieuse, et finir par peser autant que l'infrastructure historique entière. Définissez un plafond acceptable (ex : maximum 20% du portefeuille en Retain), et révisez-le chaque année. Les applications qui restent doivent avoir une justification précise et temporelle.
Le quatrième piège est de oublier que Retire crée un besoin d'archivage et de conformité. Avant d'arrêter une application, assurer que toutes les données historiques qui pourraient être utiles à titre légal, fiscal, ou auditif sont exportées et stockées quelque part. Un arrêt mal préparé peut créer des problèmes réglementaires mois ou années plus tard.