Qu’est-ce que la migration cloud ?
La migration cloud déplace des charges de travail depuis une infrastructure on-premise, ou d’un fournisseur cloud à un autre, vers une plateforme mieux adaptée à la façon dont l’entreprise fonctionne aujourd’hui. L’objectif est rarement le déménagement en lui-même. Il s’agit de réduire les coûts d’exploitation, de livrer plus vite, de gagner en résilience ou de réduire la surface d’attaque, et le plan se construit à rebours depuis cet objectif.
Une migration n’est pas un événement unique. C’est une suite de vagues, chacune avec ses dépendances, sa bascule et son retour arrière. C’est cette structure qui permet à l’activité de continuer pendant que l’infrastructure change en dessous.
Le périmètre varie. Certains projets déplacent un seul datacenter vers un fournisseur. D’autres consolident deux clouds après une acquisition, ou conservent une partie du parc on-premise dans une configuration hybride. La méthode reste la même : savoir ce que vous exploitez, décider ce que devient chaque application, et la déplacer dans l’ordre que permettent les dépendances. Notre expertise en conseil cloud couvre le travail d’architecture et de coûts qui précède et suit la migration.
Les signes qu’une migration cloud s’impose
La plupart des migrations démarrent avec une échéance plutôt qu’avec une stratégie. Les signes ci-dessous sont ceux que nous rencontrons le plus souvent, et chacun modifie la manière de construire le plan.
Un renouvellement de datacenter ou de matériel approche
Une fin de contrat ou du matériel en fin de vie est le déclencheur habituel, et le meilleur moment pour se demander ce qui doit réellement migrer.
Monter en charge prend des semaines, pas des minutes
La capacité s’achète en avance sur la demande, si bien que les pics sont soit mal servis, soit payés toute l’année.
Une revue de sécurité ou de conformité approche
IAM, segmentation réseau et chiffrement coûtent moins cher à concevoir avant l’audit qu’à rattraper après.
L’infrastructure prend le pas sur le produit
Quand l’équipe passe ses semaines à patcher des serveurs et à renouveler des licences, les services managés rendent ce temps à la feuille de route.
Personne ne sait ce que coûte une application
Le matériel partagé et les contrats groupés masquent le coût de chaque système, et chaque discussion budgétaire part d’estimations au doigt mouillé.
Un signe isolé justifie rarement une migration complète. Deux ou trois réunis signifient en général que la plateforme actuelle coûte plus en temps et en risques qu’une migration planifiée.
Ce que couvre notre audit de migration
L’audit est la partie du projet qui détermine si la suite se passe bien. Il transforme un parc qui n’existe que dans la tête des équipes en un inventaire écrit, et il donne à chaque décision ultérieure une base documentée. Notre guide sur l’assessment de l’infrastructure cloud avant migration détaille la méthode étape par étape.
Inventaire des charges de travail et cartographie des dépendances
Chaque application, base de données et intégration documentée, avec les liens qui déterminent l’ordre des vagues.
Une stratégie par application
Rehost, replatform, refactor, repurchase, retire ou retain, avec une justification écrite pour chacune.
Architecture cible et landing zone
Comptes, réseau, identités et garde-fous conçus avant que la première charge de travail ne migre.
Plans de bascule et de rollback
Des étapes de bascule répétées, des conditions de déclenchement et un chemin de retour testé vers l’ancien système.
Modèle de coûts et feuille de route
Les coûts d’exploitation estimés sur la plateforme cible et une séquence de vagues priorisée.
Le livrable est un document que votre équipe peut utiliser sans nous : un inventaire, une décision par application, une architecture cible et une séquence de vagues chiffrée. Si vous choisissez de mener la migration en interne, l’audit reste exploitable tel quel.
Vous ne savez pas par où commencer ?
Un audit de préparation dure de 2 à 4 semaines et se termine par une feuille de route priorisée et des coûts estimés.
Notre méthode de migration en quatre phases
Chaque phase se termine par un livrable et un point de décision, ce qui permet de mettre le projet en pause ou de changer de cap sans perdre le travail déjà réalisé.
PHASE 01
Auditer
Inventaire, dépendances, risques et feuille de route priorisée.
PHASE 02
Concevoir
Architecture cible, landing zone et plans de bascule.
PHASE 03
Migrer
Des vagues avec répétitions à blanc, bascule et validation.
PHASE 04
Exploiter
Supervision post-migration, nettoyage et optimisation.
Les vagues sont dimensionnées pour que chacune puisse être annulée dans une seule fenêtre de maintenance. Les premières vagues déplacent des applications peu risquées pour éprouver la landing zone et le runbook. Les systèmes critiques arrivent plus tard, une fois que l’équipe a répété la bascule sur de vraies charges de travail. Des consultants seniors pilotent chaque vague aux côtés de votre équipe, et les runbooks vous restent après la passation.
Rehost, replatform, refactor : le choix 6R
Toutes les applications ne méritent pas le même traitement. Nous classons chacune selon le modèle 6R et consignons la justification, afin de pouvoir revoir le choix quand les contraintes évoluent.
| Stratégie | Ce que cela signifie | Quand elle convient | Effort |
|---|---|---|---|
| Rehost | Déplacer l’application telle quelle, sur des machines virtuelles dans le cloud | Une sortie rapide de datacenter, avec peu de changements possibles | Faible |
| Replatform | Déplacer avec des ajustements légers, comme une base de données managée | Des gains rapides sans réécrire le code | Moyen |
| Refactor | Réarchitecturer l’application pour la rendre cloud native | L’application est stratégique et freine l’activité | Élevé |
| Repurchase | Remplacer l’application par un SaaS ou un service managé | Une fonction standard avec une bonne alternative sur le marché | Moyen |
| Retire | Décommissionner l’application | Personne ne l’utilise, ou un autre système la couvre déjà | Faible |
| Retain | La conserver où elle est, pour l’instant | La conformité, la latence ou un contrat empêche la migration | Aucun |
Le choix 6R est rarement définitif au premier passage. Des dépendances découvertes pendant l’audit peuvent faire passer une application de rehost à replatform, ou la repousser à une vague ultérieure. Conserver la justification à côté de chaque décision permet de revoir ces changements rapidement. Avant de choisir, consultez les blocages et dépendances dans les migrations 6R qui modifient le plus souvent la réponse.
Risques et rollback
La plupart des incidents de migration proviennent d’un petit nombre de causes connues à l’avance. Nous traitons chacune comme un élément planifié avec un responsable, pas comme de la malchance.
Dépendances cachées
Les liens non documentés entre applications sont la première cause d’échec des bascules. Nous les cartographions avant de fixer l’ordre des vagues.
Synchronisation des données à la bascule
Les données et l’état applicatif restent synchronisés jusqu’au basculement, dans une fenêtre de gel définie.
Conditions de rollback
Les conditions de déclenchement sont écrites à l’avance, pour que la décision de revenir en arrière ne se prenne pas sous pression.
Validation post-migration
La continuité réseau, les performances et l’intégrité des données sont vérifiées par rapport à la référence avant le retrait de l’ancien système.
La bascule elle-même suit un runbook écrit avec des points de contrôle go / no-go. Nos guides sur le plan de bascule sans interruption de service et sur les procédures de rollback et leurs conditions d’activation montrent ce que contiennent ces documents.
Tarifs de la migration cloud
Chaque mission commence par un diagnostic et se conclut par un devis forfaitaire. Les durées sont indicatives, pas garanties.
| Format | Durée | Prix |
|---|---|---|
| Audit de préparation | 2 à 4 semaines | Devis forfaitaire après diagnostic |
| Projet de migration | 6 semaines à 6 mois | Devis forfaitaire après l’audit |
| Optimisation managée après la passation | Mensuel | Forfait mensuel chiffré à la passation |
Ce qui fait varier le prix : le nombre de charges de travail, les dépendances entre applications, le périmètre de conformité et la part d’exécution que conserve votre équipe.
Le devis couvre uniquement des consultants seniors, un périmètre défini et les livrables de chaque phase. Les coûts du fournisseur cloud sont distincts de nos honoraires et sont estimés dans le modèle de coûts pendant l’audit.
FAQ migration cloud
Combien de temps dure une migration cloud ?
Un audit de préparation dure de 2 à 4 semaines. Un projet de migration prend de 6 semaines à 6 mois, selon le nombre de charges de travail et les dépendances entre elles.
L’activité va-t-elle s’arrêter pendant la migration ?
Non. Les migrations se déroulent par vagues, avec des répétitions à blanc et une bascule répétée, si bien que la production continue de tourner. Chaque vague dispose d’un plan de rollback.
Vers quel cloud devons-nous migrer ?
Nous sommes indépendants des fournisseurs et certifiés sur AWS, Azure et Google Cloud. Nous recommandons la plateforme adaptée à vos charges de travail, et nous documentons pourquoi.
Pouvez-vous migrer d’un cloud à un autre ?
Oui. La consolidation entre clouds suit la même méthode : inventaire, stratégie par application, bascule répétée et plan de rollback.
Comment choisissez-vous entre rehost et refactor ?
Nous partons de l’objectif métier et de l’état de chaque application. Le rehost est plus rapide et moins coûteux au départ. Le refactor coûte plus cher mais lève les limites d’un système stratégique. Chaque choix est consigné avec sa justification pendant l’audit, pour pouvoir être revu plus tard.
Travaillez-vous avec notre équipe interne ?
Oui. Des consultants seniors travaillent aux côtés de vos ingénieurs sur chaque vague, et les runbooks, schémas et décisions sont transmis pour que votre équipe puisse exploiter la plateforme après le projet.
Que se passe-t-il après la dernière vague ?
Les anciens systèmes sont retirés une fois la validation réussie, puis la nouvelle plateforme est supervisée et ajustée. Vous pouvez nous confier l’optimisation managée au mois, ou la reprendre entièrement.