Migration cloud : stratégies et méthodologie, du cadrage au run

Une migration cloud se présente rarement sous ce nom. Elle arrive habillée en autre chose : une échéance réglementaire, un contrat d’hébergement qui expire, une facture d’infrastructure que personne n’arrive à expliquer en comité.

C’est le cas de la mission qui sert de fil à cet article. Pour Neuflize OBC, banque privée, nous avons migré le backend de l’application mobile bancaire vers Azure AKS, puis implémenté le Paiement Instantané et la Vérification du Bénéficiaire. Personne n’a jamais demandé « une migration cloud » : la demande était de tenir un règlement à date, sur un canal grand public, sans doubler le coût d’exploitation. Résultat mesuré à l’arrivée : −52 % de coûts cloud sur le périmètre, à service constant.

La nuance change la conduite du projet. Quand la migration est le but, on la déclare réussie le jour de la bascule. Quand elle est le moyen, le succès se mesure des mois plus tard : sur la facture, et sur la capacité des équipes à livrer ce qui justifiait le déplacement.

La phase la plus souvent bâclée est la première. On sait décrire une cible ; beaucoup moins décrire l’existant. Or une stratégie de migration se déduit du parc, pas d’un cadre théorique.

Le point dur n’est pas l’inventaire des serveurs : il existe presque toujours. Ce sont les dépendances qui ne figurent dans aucun schéma — un batch qui dépose un fichier sur un partage réseau, une adresse IP en liste blanche chez un partenaire, un ordonnanceur qui lance des traitements par SSH, un certificat interne. Elles ne se déclarent pas, elles se mesurent : une capture de flux et une lecture des règles de pare-feu en apprennent davantage qu’un atelier de deux jours.

Cinq questions par application

1. Qui la possède ? Pas l’équipe qui l’héberge : celle qui décide de ses évolutions. Sans propriétaire, elle ne bougera pas.
2. Que coûte-t-elle aujourd’hui ? Calcul, stockage, licences, sauvegarde, exploitation humaine. Difficile à obtenir, et pourtant la seule donnée qui dira si la migration a été rentable.
3. Quelles données manipule-t-elle ? Nature, volume, sensibilité, durée de conservation. La réponse conditionne autant l’architecture que la conformité.
4. Est-elle encore construite ? Avec sa chaîne de build et ses tests, elle se replatforme. Livrée en binaire par un éditeur disparu, elle se rehoste ou se remplace.
5. Quelle est son échéance ? Fin de support, expiration de contrat, obligation réglementaire. C’est elle qui ordonnera les vagues, bien plus que la valeur métier.

Triez ensuite en trois piles : ce qui part, ce qui reste, et ce dont vous ne savez pas encore assez pour trancher. La troisième est normale ; la migrer par défaut ne l’est pas.

Les sept stratégies — rehost, replatform, refactor, repurchase, retire, retain, relocate — sont d’ordinaire présentées en liste. C’est trompeur : en pratique on n’en choisit pas une, on élimine les six autres. L’ordre des questions compte plus que les définitions.

Question, dans cet ordre	Si oui	Ce que cela implique
A-t-elle encore des utilisateurs et un propriétaire ?	Non → Retire	Le gain le plus rentable. Décommissionner, c’est archiver selon la durée légale, pas éteindre un serveur.
Une contrainte réglementaire ou matérielle interdit-elle le déplacement ?	Oui → Retain	Décision datée. « On garde » sans échéance de revue devient de la dette silencieuse.
Existe-t-il une offre SaaS crédible ?	Oui → Repurchase	Le vrai coût est la reprise de données, pas l’abonnement.
Faut-il déplacer un socle de virtualisation entier à date fixe ?	Oui → Relocate	Report utile pour sortir d’un datacenter ; l’arbitrage revient ensuite.
La chaîne de build et les tests existent-ils encore ?	Non → Rehost	Le seul cas où le lift-and-shift est un choix et non un renoncement.
Le modèle d’exécution tient-il dans un conteneur avec des services managés ?	Oui → Replatform	Meilleur rapport effort/effet : base managée, secrets externalisés, sans réécriture métier.
Le modèle de données ou l’état interne bloquent-ils l’élasticité ?	Oui → Refactor	Forte valeur ou forte variabilité de charge. Le seul cas qui justifie une réécriture.

Sur le périmètre bancaire mobile, la réponse a été un replatform assumé : conteneurisation des services Java/Spring Boot, passage sur AKS, externalisation des secrets et de la configuration. Le refactor n’a porté que sur les composants du paiement instantané, là où le modèle d’exécution devait changer : un flux qui répond en continu ne se traite pas comme un traitement par lots.

Les répartitions cibles du type « 80 % de replatform, 15 % de refactor » ne veulent rien dire hors contexte : c’est un résultat de l’arbre, pas un objectif.

Une migration se découpe en vagues, non par préférence méthodologique : la première ne migre presque rien, elle construit l’usine.

Vague zéro : les fondations

Réseau et interconnexion avec l’existant, identité, découpage des abonnements, politiques de sécurité, gestion des clés, infrastructure en code, chaîne CI/CD et observabilité. Elle coûte cher et ne produit aucune valeur métier visible — principale source d’incompréhension avec les directions financières. Ce que vous financez là, c’est le coût unitaire de toutes les vagues suivantes.

Vague un : l’application témoin

Le choix classique est une application sans enjeu. C’est une erreur : sans exigence de disponibilité ni données sensibles, elle ne révèle rien. Prenez une application représentative — même pile technique, mêmes contraintes de données — dont l’interruption reste supportable. C’est elle qui montrera ce que vos fondations ne savent pas encore faire.

Vagues suivantes : par grappe de dépendances

On migre par grappe, pas application par application : les composants qui se parlent en synchrone partent ensemble. Séparer une application de sa base par un lien inter-sites, c’est ajouter une latence à chaque requête et découvrir en production que le code faisait cent appels là où on en imaginait trois.

Entre deux vagues, imposez un critère d’arrêt explicite : niveau de service tenu sur une période définie, coût conforme à l’estimation, exploitation reprise par l’équipe concernée. Sans ce contrôle, les défauts s’accumulent et le projet se termine sur une date plutôt que sur un état.

Le calcul se déplace facilement. Les données, non. C’est là que se concentrent les risques irréversibles : une erreur ne s’y corrige pas par un redéploiement.

Trois schémas couvrent la plupart des cas. La bascule à froid — arrêt, transfert, redémarrage — reste la plus simple et la plus sûre quand la fenêtre d’indisponibilité est acceptable ; on l’écarte trop souvent par principe alors qu’elle évite des semaines de complexité. La réplication continue avec bascule courte convient aux bases relationnelles et laisse choisir le moment. Le double run avec réconciliation est le seul dispositif qui donne une vraie confiance sur un flux financier, et le plus coûteux : écrire le comparateur, traiter les écarts, fixer d’avance sa date de fin — sinon il devient permanent.

Deux règles ne se négocient pas : la restauration se teste avant la migration, sur la cible, chronomètre en main ; et le plan de retour arrière s’exécute au moins une fois pour de vrai. Un rollback jamais joué n’est pas un plan, c’est une intention.

La réversibilité comme livrable

La réversibilité a longtemps été une clause contractuelle sans conséquence technique. Ce n’est plus tenable, en particulier dans le secteur financier où le régulateur attend une stratégie de sortie documentée et testable : où sont les données et sous quel format les récupérer, quelles dépendances devraient être réécrites, combien de temps prendrait la sortie. Le Data Act européen prévoit par ailleurs la suppression progressive des frais de changement de fournisseur.

Elle ne s’obtient pas en refusant les services managés, mais en isolant les points d’adhérence et en sachant lesquels vous acceptez. Un cluster Kubernetes, du stockage objet et une base PostgreSQL managée se retrouvent partout ; une fonction propriétaire couplée à un bus propriétaire, beaucoup moins.

Sur un périmètre bancaire, la contrainte réglementaire n’est pas un chapitre du dossier : c’est le cadre qui détermine l’architecture, sur quatre axes.

• Localisation et souveraineté. Le choix de région n’est pas un paramètre de latence : il engage la juridiction applicable aux données, et doit être tenu aussi pour les sauvegardes, les journaux et la reprise d’activité — c’est presque toujours là que la règle se perd. En France, la qualification SecNumCloud de l’ANSSI structure le débat sur les données les plus sensibles.
• Externalisation et résilience opérationnelle. Le règlement européen DORA impose aux entités financières un cadre formalisé sur le risque lié aux prestataires informatiques : registre des contrats, exigences contractuelles minimales, droit d’audit, tests de résilience, notification des incidents majeurs, stratégie de sortie. Rien n’y interdit le cloud public : le régulateur exige que vous sachiez continuer à opérer si le fournisseur tombe, et en sortir.
• Maîtrise des clés et des accès. Chiffrement au repos et en transit, clés gérées par le client, séparation des rôles, traçabilité des accès administrateurs. « Qui peut lire cette donnée en clair, et où est-ce journalisé ? » doit avoir une réponse écrite avant la première bascule.
• Exigences fonctionnelles imposées. Le règlement européen sur les virements instantanés a rendu obligatoires la réception puis l’émission de virements en euros en quelques secondes, et la vérification du bénéficiaire avant validation. Des obligations de résultat qui deviennent des contraintes d’architecture : disponibilité continue, pas de fenêtre de maintenance confortable, budget de latence réparti entre les appels.

C’est cette dernière catégorie qui explique la formulation du début : le passage sur AKS n’était pas la finalité, c’était ce qui rendait possible un service continu et élastique sans provisionner en permanence l’infrastructure du pic.

C’est la recommandation la plus rentable de cet article, et la plus systématiquement repoussée : sans mesure de l’existant, la non-régression ne se démontre pas, et toute discussion sur les performances se règle à l’impression.

Sur le périmètre Neuflize OBC, la chaîne associe Prometheus pour les métriques, Loki et Promtail pour les journaux, Tempo pour le traçage distribué et Grafana pour la restitution et l’alerte. L’intérêt n’est pas la liste des outils : c’est qu’un même identifiant de corrélation permet de passer d’une alerte à la trace, puis aux journaux de la requête concernée, sans changer d’onglet.

Trois choses à faire avant la première bascule

1. Établir la ligne de base. Latence par percentile — la moyenne ne dit rien —, taux d’erreur, débit, saturation, volumétrie des journaux, sur une période incluant les pics.
2. Instrumenter le code avant de le déplacer. Traçage distribué et journaux structurés s’ajoutent bien plus facilement quand l’application est stable dans son environnement connu. Les ajouter après la bascule, c’est modifier deux variables à la fois.
3. Écrire les alertes sur des symptômes, pas des causes. Une alerte sur le taux d’erreur vu par le client vaut mieux que dix alertes sur l’utilisation processeur : ces dernières se déclenchent en permanence après une migration, les seuils de l’ancien monde ne valant plus rien dans le nouveau.

Cette instrumentation fournit aussi les données sans lesquelles les ressources ne s’ajustent pas.

Une migration ne produit pas d’économie : elle en crée la possibilité. Les −52 % viennent du travail fait après la bascule, dans un ordre qui compte.

1. Mesurer et attribuer. Étiquetage des ressources, découpage par espace de noms et par environnement, tableau de bord de coûts que l’équipe technique consulte elle-même. Tant que la facture est un document mensuel envoyé à la direction financière, personne ne l’optimise.
2. Dimensionner sur la mesure. Les demandes et limites fixées au jugé lors de la conteneurisation sont presque toujours généreuses. Les corriger après quelques semaines d’observation est le geste le plus rentable, et il ne touche pas au produit.
3. Rendre l’élasticité réelle. Autoscaling des services et du cluster, et surtout extinction du hors-production hors heures ouvrées : beaucoup de plateformes de recette tournent la nuit, le week-end et en août.
4. Traiter le stockage et la rétention. Les journaux sont fréquemment le deuxième poste après le calcul. Une rétention différenciée — courte sur le détaillé, longue sur l’agrégé — se décide avant que le volume ne devienne un sujet.
5. Engager en dernier. Réservations et plans d’économies se souscrivent une fois le profil de consommation stabilisé, jamais pendant la migration : s’engager trois ans sur un dimensionnement provisoire verrouille le gaspillage.

Rien là-dedans n’est une astuce de facturation : ce sont des décisions d’architecture d’exploitation, détaillées dans notre guide FinOps et dans notre expertise Cloud & FinOps.

Le lift-and-shift qui double la facture. On transpose des machines virtuelles dimensionnées pour un pic ancien, allumées en permanence, sur une infrastructure facturée à l’heure — alors que le matériel d’origine était amorti. Le résultat est mécanique. Étape courte défendable, avec date de fin et budget de modernisation voté ; état final, jamais.

Les dépendances qu’on découvre en production. Le batch qui écrit sur un partage réseau, l’adresse IP en liste blanche chez un partenaire, la tâche planifiée sur un serveur non inventorié. Elles ne se trouvent pas en atelier mais en observant le trafic réel avant de couper.

Les équipes qu’on n’a pas formées. Le symptôme est reconnaissable : le cluster devient la propriété d’une seule personne, et plus rien ne se déploie quand elle est absente. La formation n’est pas une ligne de fin de projet, c’est une condition de sortie. Une mission n’est terminée que lorsque l’équipe interne opère seule — ce qui protège aussi d’une dépendance au prestataire, exigence que le régulateur formule explicitement dans la finance.

Le projet piloté par la date plutôt que par l’état. Ce qui saute en premier est alors invariablement l’observabilité, les tests de restauration et la documentation d’exploitation — précisément ce qui permet de tenir le run. La facture arrive six mois plus tard, sous forme d’incidents. Corollaire : si personne n’est nommément responsable du coût du périmètre migré, il dérivera.

Si vous avez une échéance — fin de contrat d’hébergement, fin de support, obligation réglementaire —, elle définit votre première vague, quelle que soit la valeur métier des applications concernées. Sinon, commencez par les deux choses qui ne se rattrapent pas : l’évaluation honnête du parc, coût actuel réel compris, et l’instrumentation de l’existant.

Puis posez la question du début : qu’est-ce que cette migration doit rendre possible, que vous ne pouvez pas faire aujourd’hui ? Si la réponse tient en un objectif technique, le projet manque de commanditaire. Si elle tient en une contrainte métier ou réglementaire datée, vous avez une trajectoire.

Nous intervenons sur ce type de trajectoire en cadrage comme en réalisation, avec un associé-architecte sur le projet. Décrivez-nous la décision devant vous : nous vous disons ce que nous ferions et ce que cela coûte.