Stratégies de migration cloud : les 7 R, la découverte, les vagues et la bascule

La plupart des programmes de migration ne sont pas ralentis par la technologie. Copier une machine virtuelle, répliquer une base de données, repointer un DNS : ces mécaniques sont bien connues et abondamment outillées. Ce qui coince, c'est que personne ne sait dire avec certitude lesquelles des quatre cents applications de l'inventaire comptent encore, à qui elles appartiennent, avec quoi elles communiquent, ni ce qui se passe si l'une d'elles s'arrête pendant six heures. Une migration, c'est un exercice de gestion de portefeuille déguisé en projet d'ingénierie.

Ce guide suit l'enchaînement d'un vrai programme : découvrir ce que vous avez, décider d'une stratégie par application, construire la destination, déplacer les données, basculer, puis recommencer par vagues. Il suppose que vous maîtrisez les fondamentaux du cloud et, si la destination est Azure, la hiérarchie décrite dans les fondamentaux d'Azure.

La découverte : savoir ce que vous exploitez réellement

La découverte répond à trois questions pour chaque application : de quoi s'agit-il, de quoi dépend-elle, et combien coûte-t-elle à faire tourner en l'état ?

Les outils automatisés fournissent une première passe. Les scanners sans agent lisent les inventaires des hyperviseurs et les flux réseau ; les collecteurs à agent ajoutent le détail au niveau des processus et l'historique de performance. AWS comme Azure proposent des services d'évaluation de migration qui recommandent une cible correctement dimensionnée à partir de plusieurs semaines d'observation du CPU, de la mémoire, du disque et du réseau. Prenez cet historique de performance au sérieux : c'est le livrable le plus précieux de la découverte, car c'est la seule défense contre le re-provisionnement dans le cloud d'un parc dimensionné pour le pic.

L'automatisation ne vous dira pas ce qui décide réellement du plan : qui valide l'interruption de service, quel contrat fournisseur interdit l'exécution hors d'un datacenter nommé, quelle base de données est discrètement le système de référence d'un reporting réglementaire. Cela s'obtient par des entretiens, et le résultat est une fiche de portefeuille par application :

La cartographie des dépendances est l'endroit où se cache le vrai risque. Les données de flux révèlent les connexions que personne n'a documentées : un dépôt de fichier nocturne sur un partage SMB, une adresse IP codée en dur dans un batch, un outil de reporting qui garde une connexion ouverte vers un réplica de production. Construisez la cartographie à partir du trafic observé sur au moins un mois complet, pour faire apparaître les traitements trimestriels et de fin de mois, puis regroupez les applications en groupes de migration (move groups) : des ensembles qui doivent migrer ensemble, parce que les séparer ferait passer une conversation bavarde et sensible à la latence par un lien réseau.

Les sept R

Une fois que vous savez ce qu'est une application, vous lui attribuez une stratégie. La liste comptait cinq entrées à l'origine ; elle en compte aujourd'hui sept par convention.

Retire (retirer). L'éteindre. Dans la plupart des parcs, dix à vingt pour cent des applications n'ont aucun utilisateur ou font doublon avec autre chose. Chaque retrait supprime un coût de migration, un coût de licence et une surface d'attaque. C'est l'option la plus rentable et la plus difficile à faire valider, car quelqu'un doit accepter le risque de se tromper.

Retain (conserver). La laisser où elle est, pour l'instant. Se justifie par une dépendance au mainframe, un remplacement imminent, un régulateur qui n'a pas encore approuvé la région cible ou un matériel pas encore amorti. Une décision de conservation doit porter une date de revue, sinon elle devient un datacenter permanent avec trois serveurs dedans et un contrat de support complet.

Rehost (réhéberger). Déplacer la charge telle quelle : le fameux « lift and shift ». Des outils de réplication au niveau bloc copient des serveurs en fonctionnement vers des machines virtuelles cloud, avec quelques minutes d'interruption à la bascule. C'est rapide, peu risqué et n'exige aucune modification applicative ; mais toutes les inefficacités suivent, si bien qu'un parc réhébergé coûte généralement plus cher par unité de travail que le matériel qu'il a quitté, tant qu'il n'a pas été optimisé.

Replatform (replatformer). Déplacer l'application avec des changements ciblés qui rapportent un bénéfice disproportionné : le « lift and reshape ». Les cas typiques : pointer l'application vers une base de données managée au lieu d'une base auto-administrée, la placer derrière un load balancer managé avec certificats managés, la conteneuriser sans la repenser, ou remplacer un partage de fichiers par du stockage objet. La logique applicative n'est pas touchée ; la charge d'exploitation baisse nettement. Pour la plupart des parcs, c'est le meilleur choix par défaut lorsqu'aucune échéance n'impose le rehost.

Repurchase (racheter). La remplacer par un produit du marché, généralement en SaaS. Courant pour le CRM, les RH, le ticketing, les outils collaboratifs et la messagerie. Le travail de migration devient de la migration de données, de l'intégration et de la conduite du changement plutôt que de l'infrastructure, et le coût total est généralement dominé par les deux derniers postes.

Refactor (refactorer). Réécrire des parties importantes pour exploiter les services cloud natifs et, souvent, changer d'architecture : découper un monolithe, passer au traitement événementiel, adopter le serverless. C'est ce qui apporte le plus grand bénéfice à long terme, mais aussi ce qui consomme le plus gros budget et les profils les plus seniors. Réservez-le aux applications dont le business case est précis : un système incapable de suivre un plan de croissance connu, ou dont le délai de mise en production freine le chiffre d'affaires. Refactorer sous la contrainte d'une sortie de datacenter, c'est la recette pour rater l'échéance.

Relocate (relocaliser). Déplacer tout un parc virtualisé vers une version hébergée dans le cloud de la même pile d'hyperviseur, sans convertir les machines une par une. Intéressant quand un gros parc VMware doit quitter un bâtiment rapidement et que l'effort de conversion est hors de portée ; cela préserve l'outillage et les compétences, mais repousse la question de la modernisation au lieu de la régler.

Choisir une stratégie par application

Une heuristique qui fonctionne, appliquée application par application puis vérifiée à l'échelle du portefeuille :

Is anyone using it?                          no  -> Retire
Is there a credible SaaS equivalent?         yes -> Repurchase
Is it blocked (licence, latency, regulator)? yes -> Retain (with review date)
Is change lead time or scale a real problem
   AND is there budget and appetite?         yes -> Refactor
Would swapping 1-2 components remove most
   of the operational burden?                yes -> Replatform
Is the deadline immovable?                   yes -> Rehost, optimise later
Is the estate large and time short?          yes -> Relocate

Deux vérifications au niveau du portefeuille comptent davantage que la réponse application par application. D'abord, le mix : un plan à quatre-vingt-dix pour cent de rehost tiendra sa date et décevra tout le monde sur les coûts, tandis qu'un plan à trente pour cent de refactor ne tiendra pas sa date du tout. Environ soixante pour cent de rehost et de replatform, dix à quinze pour cent de retrait et une poignée de refactors choisis pour leur impact métier : c'est une forme qui résiste généralement à l'épreuve du réel. Ensuite, le séquencement : placez les refactors sur une piste séparée avec leur propre financement, pour qu'une réécriture qui dérape ne bloque pas une sortie de datacenter.

La landing zone d'abord

Rien ne doit bouger tant que la destination n'est pas prête à accueillir les charges en toute sécurité. Une landing zone est le socle préconstruit et automatisé sur lequel atterrit chaque charge migrée. Les deux principaux fournisseurs publient des implémentations de référence, et partir de l'une d'elles coûte bien moins cher que de tout inventer.

Au minimum, elle fournit :

• Une structure de comptes ou d'abonnements avec des frontières distinctes pour la production, la hors-production, les services de plateforme partagés, l'outillage de sécurité et l'archivage des logs.
• L'intégration de l'identité : fédération avec l'annuaire de l'entreprise, groupes associés à des rôles, aucun identifiant à longue durée de vie, comptes « bris de glace » (break-glass) documentés et placés sous alerte.
• Une topologie réseau : hub-and-spoke ou équivalent, plages d'adresses allouées pour ne pas entrer en collision avec l'on-premise, connectivité vers le datacenter par circuit privé ou VPN, résolution DNS fonctionnelle dans les deux sens.
• Des garde-fous : des politiques qui empêchent de créer des ressources dans des régions non approuvées, imposent le chiffrement et le tagging, et bloquent par défaut le stockage public. Des contrôles préventifs, pas un rapport publié chaque mois.
• La journalisation et la supervision : des logs d'audit centralisés écrits dans un compte que personne d'autre ne peut modifier, plus une stack de supervision à laquelle les charges se branchent au lieu d'en réinventer une chacune.
• Un pipeline et des modèles, pour qu'accueillir une charge revienne à exécuter de l'automatisation, pas à cliquer. C'est la partie du programme où la discipline de l'infrastructure as code rapporte le plus.

Le DNS hybride et le chevauchement des plages IP méritent une mention spéciale : ce sont des sujets ennuyeux, découverts tard, et ils ont retardé plus de migrations que n'importe quel problème applicatif.

Déplacer les données

Les données sont la partie qu'on ne peut pas refaire rapidement ; ce sont donc elles qui dictent la conception de la bascule.

Transfert en masse. Pour de gros volumes statiques, faites honnêtement le calcul : un téraoctet sur un lien d'un gigabit saturé prend environ trois heures au débit théorique, et nettement plus en pratique ; un parc qui se mesure en centaines de téraoctets dépasse la fenêtre. Les appliances de transfert physique — des boîtiers durcis qu'on vous expédie, que vous remplissez et renvoyez — existent précisément pour cela, et sont généralement plus rapides et moins chères que la mise à niveau d'un circuit pour une opération ponctuelle.

Réplication continue. Pour les bases de données, le schéma standard est un service de réplication qui effectue un chargement complet, puis applique en continu les changements lus dans le journal de transactions jusqu'à ce que source et cible soient synchronisées. AWS Database Migration Service et Azure Database Migration Service le font tous deux, y compris pour les migrations hétérogènes où le moteur change, avec une étape préalable de conversion de schéma. Faites tourner la réplication plusieurs jours avant la bascule, pour que le retard de réplication soit mesuré et non supposé.

Validation. Le comptage des lignes est un point de départ, pas une fin. Comparez des checksums par table, rapprochez un total métier (le montant des commandes de la veille, la balance comptable) et exécutez les chemins de lecture de l'application elle-même contre la cible avant que quiconque ne s'engage.

L'approche de migration prend alors l'une de trois formes :

L'exécution en parallèle — les deux systèmes en service, l'un faisant autorité — est la plus sûre et la plus coûteuse, car quelqu'un doit rapprocher les deux et trancher lorsqu'ils divergent.

Vagues, bascule et retour arrière

Les migrations avancent par vagues : des lots de groupes de migration planifiés ensemble. La première vague est un pilote, et son objectif est d'apprendre, pas de faire du volume. Choisissez deux ou trois applications réelles, qui ont un responsable, et suffisamment peu importantes pour qu'un mauvais week-end reste supportable, puis instrumentez le processus lui-même : combien de temps a pris chaque étape, ce que le runbook indiquait de travers, quelles permissions manquaient.

Chaque vague suivante doit avoir des critères d'entrée écrits (landing zone prête, validation du responsable, dépendances déjà migrées ou incluses dans la même vague), un runbook avec des responsables nommés et des durées, et des critères de sortie explicites : taux d'erreur et latence dans une fourchette convenue, batchs terminés avec succès, rapprochement sans écart, supervision qui alerte correctement.

Le plan de retour arrière est ce qui rend l'ensemble envisageable sans danger, et il doit être plus précis que « on revient en arrière ». Écrivez noir sur blanc le point de non-retour — généralement le moment où la cible accepte des écritures qui ne sont pas répliquées vers la source — et à quoi ressemble la décision de part et d'autre de ce point. Avant, le retour arrière consiste à repointer le DNS ou un load balancer vers la source. Après, il implique une réplication inverse ou le rejeu des transactions, ce qui doit avoir été testé si vous prétendez en disposer.

Juste après chaque vague, faites deux choses que les programmes oublient régulièrement : décommissionnez la source, car payer les deux parcs est le dépassement de coûts classique ; et redimensionnez la cible à partir de deux semaines de métriques cloud réelles plutôt que de l'estimation on-premise. C'est là que se trouvent vraiment les économies qui ont financé le programme — voir la gestion des coûts du cloud.

Les risques à nommer dans le plan

Les régressions de performance dues aux architectures coupées en deux. Pendant une migration, une application dans le cloud dialogue souvent avec une base de données restée on-premise. Un échange qui prenait des microsecondes coûte désormais des millisecondes par aller-retour, et un code ORM bavard se dégrade de façon non linéaire. Migrez les composants couplés dans la même vague.

Les licences qui suivent le matériel. Certains éditeurs facturent par cœur physique ou interdisent l'hébergement virtualisé. Vérifiez avant de concevoir la cible, pas après.

Les intégrations non documentées qui se déclenchent chaque trimestre. Un mois de données de flux ne voit pas le traitement de fin d'année. Demandez aux équipes finance et exploitation ce qui se passe lors des clôtures.

La traîne sans responsable. Les applications sans responsable identifiable ne peuvent être ni retirées ni migrées. Faites-les remonter tôt, avec une option par défaut annoncée — généralement « nous l'éteindrons à telle date sauf si quelqu'un la réclame » —, car l'alternative, c'est de découvrir son responsable à la semaine cinquante.

Les compétences et la fatigue. Les bascules ont lieu le week-end. Un planning qui suppose que les six mêmes ingénieurs enchaîneront douze week-ends de suite est un plan pour les perdre en cours de programme.

Points clés à retenir

• C'est la découverte, et non la technologie, qui détermine le succès d'une migration : fiches de portefeuille, utilisation observée et cartographie des dépendances construite sur au moins un mois de trafic.
• Les sept R — retire, retain, rehost, replatform, repurchase, refactor, relocate — s'attribuent application par application, et c'est le mix du portefeuille qui décide si le programme tient sa date.
• Retirer les applications mortes est le gain le moins cher qui soit, et le rehost est légitime à condition que le travail d'optimisation soit planifié et non simplement supposé.
• La landing zone — comptes, identité, réseau, garde-fous, journalisation, pipelines — doit exister avant que la première charge ne soit migrée.
• L'approche de migration des données découle de l'interruption acceptable ; validez par un rapprochement au niveau métier, pas par un simple comptage de lignes.
• Les vagues exigent des critères d'entrée et de sortie, un point de non-retour clairement nommé, un retour arrière répété à blanc, et le décommissionnement rapide de la source pour cesser de payer deux fois.