La migration vers le cloud est souvent présentée comme une simple bascule technique : on déplace des machines virtuelles d’un datacenter vers Azure et l’affaire est réglée. Dans les faits, les migrations qui déçoivent — factures qui dérapent, performances en retrait, incidents de sécurité — échouent rarement sur la technologie. Elles échouent sur le cadrage, la gouvernance des coûts et la sécurité, trois sujets qui se décident avant la première ressource déployée.
Cadrer par les usages, pas par les serveurs
Le Cloud Adoption Framework de Microsoft structure une migration en étapes claires : définir la stratégie et les motivations, établir un plan à partir d’un inventaire réel, préparer une zone d’atterrissage (landing zone) conforme, puis migrer par vagues. L’erreur classique consiste à commencer par l’inventaire technique sans avoir relié chaque application à un usage métier et à un résultat attendu. Une application peu utilisée ne se migre pas « telle quelle » : elle se retire, se remplace ou se modernise.
- Rehost (« lift-and-shift ») : rapide, mais ne capte aucun bénéfice d’architecture — à réserver aux charges contraintes par le temps.
- Refactor / Replatform : quelques adaptations (base managée, conteneurs) pour gagner en coût et en résilience.
- Rearchitect / Rebuild : pour les applications stratégiques qui justifient un vrai investissement cloud-native.
- Replace : bascule vers un SaaS (souvent Microsoft 365 ou Dynamics 365) quand l’application sur mesure n’apporte plus de différenciation.
La facture cloud se pilote (FinOps), elle ne se subit pas
Le cloud transforme un coût d’investissement (acheter des serveurs) en coût d’exploitation variable. Sans discipline, cette variabilité devient une dérive. La démarche FinOps — portée par la FinOps Foundation — installe une responsabilité partagée entre finance, technique et métier autour de trois temps : donner de la visibilité (qui consomme quoi, et pourquoi), optimiser (dimensionnement au juste besoin, réservations, arrêt des ressources inutilisées) et opérer dans la durée (budgets, alertes, revue régulière).
Concrètement, les leviers les plus rentables sont rarement spectaculaires : redimensionner les ressources sur-provisionnées, éteindre les environnements hors production la nuit et le week-end, tirer parti des réservations et des plans d’économies pour les charges stables, et rattacher chaque ressource à un centre de coût par un étiquetage rigoureux. Un tableau de bord de coûts sans propriétaire désigné ne change rien : le FinOps est d’abord une pratique d’équipe, pas un outil.
La sécurité se conçoit dès la zone d’atterrissage
Rattraper la sécurité après coup est le plus coûteux des choix. L’approche recommandée consiste à préparer une landing zone qui porte, dès le départ, l’identité (Microsoft Entra ID), la segmentation réseau, le chiffrement, la journalisation et les garde-fous de conformité. Le principe directeur est celui du Zero Trust : ne jamais présumer la confiance, vérifier explicitement chaque accès, et limiter les privilèges au strict nécessaire.
- Identité comme périmètre : authentification forte, accès conditionnel, privilèges just-in-time.
- Gouvernance par la conception : politiques et garde-fous appliqués automatiquement, pas laissés à la bonne volonté de chaque équipe.
- Visibilité continue : supervision et détection (Microsoft Defender for Cloud, Sentinel) plutôt qu’audit ponctuel.
- Sauvegarde et reprise : testées régulièrement, car une sauvegarde jamais restaurée n’est pas une sauvegarde.
Notre lecture : migrer par vagues, mesurer à chaque étape
Une migration Azure réussie ressemble moins à un grand saut qu’à une série de vagues courtes, chacune cadrée, sécurisée et mesurée. On commence par un lot à faible risque qui sert de référence, on outille la gouvernance des coûts et de la sécurité dès ce premier lot, puis on industrialise. C’est cette discipline — et non le choix d’un service plutôt qu’un autre — qui sépare une migration qui tient ses promesses d’une facture qui gonfle sans bénéfice.