Migration On-Prem vers le Cloud : ce que personne ne te dit avant de commencer

Série Cloud Journey · Billet B11

La promesse du cloud… et la réalité

Le PDG entre dans la salle de réunion avec une énergie débordante. "On migre tout vers le cloud en 6 mois. On va réduire nos coûts, accélérer nos déploiements, et devenir enfin agiles." Applaudissements dans la salle. Enthousiasme général.

Neuf mois plus tard, la facture d'infrastructure a triplé. Les trois meilleurs développeurs ont donné leur démission — épuisés par une migration chaotique effectuée en parallèle de leurs responsabilités habituelles. Et l'application principale, migrée à la va-vite en "Lift & Shift", consomme 40 instances EC2 surdimensionnées dont 60% des ressources ne servent à rien.

Cette histoire, on l'a vécue. Pas une fois. Plusieurs fois. Et à chaque fois, l'origine est la même : une migration cloud sans préparation adéquate.

Ce guide est le condensé de ce qu'on apprend sur le terrain. Pas la théorie des vendors. La réalité des PME canadiennes.

Le cadre de référence : les 6 R's de la migration cloud

Avant de plonger dans les erreurs et les stratégies, établissons le vocabulaire de base. Amazon Web Services a popularisé le cadre des 6 R's de migration — aujourd'hui adopté par l'ensemble de l'industrie et parfois étendu à 7, 8 ou 9 R's selon les auteurs.

Note : Certains référentiels ajoutent un 7e R — Relocate (déplacer vers une infra cloud gérée, ex: VMware Cloud on AWS) — utile si tu migres une infra VMware existante sans refonte applicative.

Ce cadre donne un langage commun à toute l'organisation. Avant de classifier chaque workload, c'est la première conversation à avoir avec ton équipe.

Ce guide se concentre en détail sur les 3 stratégies les plus fréquentes en contexte PME/mid-market : Rehost, Replatform et Refactor. Pour une vision complète des 6 piliers du Well-Architected Framework d'AWS ou du Cloud Adoption Framework (CAF), consultez les ressources officielles AWS, Azure ou GCP.

Les 3 erreurs fatales d'une migration cloud

1. Le Lift & Shift aveugle

L'erreur la plus courante : prendre chaque serveur on-prem et le recréer tel quel dans le cloud. Résultat ? Vous payez pour le cloud, mais vous avez tous les inconvénients du on-prem — sans aucun des bénéfices natifs.

Un client avait 40 serveurs on-prem. L'équipe les a migrés un à un vers EC2, en gardant les mêmes specs. Six mois après : 40 instances EC2 actives 24/7, dont la plupart à moins de 20% d'utilisation CPU. 60% des ressources gaspillées. Facture mensuelle : le double du budget prévu.

Le problème n'était pas le cloud. C'était l'absence d'analyse préalable : quelles apps sont cloud-ready ? Lesquelles peuvent être containerisées ? Lesquelles méritent d'être refactorées ?

2. Sous-estimer les coûts réels

Le benchmark industrie est brutal : prévoyez 1.4x votre estimation initiale. Pourquoi ? Parce que les coûts visibles (compute, storage) ne représentent que la moitié de la facture réelle.

Les coûts cachés s'accumulent silencieusement :

• Egress réseau : 0.08–0.09 USD/GB pour transférer vos données hors du cloud
• Support Enterprise : 10%+ de votre facture mensuelle si vous optez pour du support business-critical
• Licences BYOL : Windows Server, SQL Server — les licences on-prem ne se transfèrent pas automatiquement
• Formation équipe : 15,000–25,000 CAD pour former une équipe de 3-4 personnes aux bonnes pratiques cloud
• Ressources idle : une instance laissée allumée par erreur = 130 USD/mois minimum

3. Ignorer la dette technique

Migrer une application qui a 10 ans de dette technique, c'est la transplanter avec ses problèmes. Pire : le cloud amplifie certaines inefficacités (coût des requêtes, latence réseau inter-services, etc.).

Avant de migrer, faites un inventaire honnête : quelles apps sont un risque ? Quelle est leur criticité ? Peut-on les moderniser en même temps, ou faut-il les planifier séparément ?

Les 3 modèles de migration : choisir le bon

Rehost (Lift & Shift)

Principe : Migration directe, sans modification. On déplace les VMs telles quelles vers le cloud.

Avantages : Rapide à exécuter, risque technique faible, utile pour les migrations d'urgence ou les fins de bail datacenter.

Inconvénients : Aucun bénéfice cloud natif, sur-dimensionnement quasi-systématique, coûts élevés à long terme.

Quand l'utiliser : Apps legacy avec contraintes réglementaires fortes, deadline imminente, ou comme première étape avant une refactorisation planifiée.

Économies estimées : 10–15% par rapport au on-prem (principalement sur l'élimination du capex).

Replatform (Lift, Tinker & Shift)

Principe : Migration avec optimisations légères. On utilise les services managés du cloud sans réécrire le code applicatif.

Exemples concrets : Remplacer un MySQL self-hosted par Amazon RDS ou Azure Database for MySQL. Remplacer Redis on-prem par ElastiCache ou Azure Cache for Redis. Migrer les fichiers statiques vers S3 ou Azure Blob Storage.

Pourquoi c'est le meilleur ratio pour les PME : Effort modéré (2-3 mois), résultats rapides, 25–35% d'économies sur les coûts d'infrastructure, et une équipe qui monte en compétence progressivement.

C'est le modèle qu'on recommande dans 80% des cas pour les PME canadiennes.

Refactor (Re-architect)

Principe : Réécriture de l'application pour exploiter pleinement les capacités cloud-native : microservices, containers, serverless, event-driven architecture.

Avantages : 50–70% d'économies sur 3 ans, scalabilité automatique, résilience maximale, innovation accélérée.

Réalité : Effort important (6–18 mois), risque technique élevé, nécessite des compétences cloud avancées. À réserver aux apps stratégiques à fort volume de trafic.

À planifier uniquement pour les 20% d'applications qui justifient l'investissement.

Azure vs AWS vs GCP : quel cloud pour votre PME canadienne ?

La réponse courte : ça dépend de votre stack actuel. La réponse longue :

Microsoft Azure

Recommandé si : votre organisation est Microsoft-heavy (Office 365, Active Directory, SQL Server, .NET).

• Régions canadiennes : Canada Central (Toronto) et Canada East (Québec City)
• Intégration native avec Active Directory et Microsoft 365
• Excellente conformité : PIPEDA, SOC 2, ISO 27001
• Azure Hybrid Benefit : économies sur les licences Windows/SQL Server existantes

Amazon Web Services (AWS)

Recommandé si : vous voulez le catalogue le plus large et la maturité maximale.

• Région canadienne : ca-central-1 (Montréal) + ca-west-1 (Calgary) annoncé
• Le plus grand catalogue de services managés (200+ services)
• Écosystème partenaires le plus vaste
• Reserved Instances : économies de 40–60% vs on-demand

Google Cloud Platform (GCP)

Recommandé si : data analytics, machine learning, ou Kubernetes natif.

• Régions canadiennes : northamerica-northeast1 (Montréal) + northamerica-northeast2 (Toronto)
• BigQuery pour l'analytique à grande échelle
• GKE : le meilleur Kubernetes managé du marché
• Sustained Use Discounts automatiques (pas besoin de réserver à l'avance)

Le plan en 5 étapes

Étape 1 — Assessment (2–4 semaines)

Inventaire complet de votre portfolio applicatif. Pour chaque app : criticité, dépendances, architecture, dette technique, coûts actuels. Construisez le business case de la migration avec un TCO comparatif sur 3 ans.

Livrable : matrice d'applications avec stratégie de migration recommandée (Rehost / Replatform / Refactor / Retire / Retain).

Étape 2 — Pilot (4–6 semaines)

Migrez 1 à 3 applications non-critiques. L'objectif n'est pas la performance, c'est l'apprentissage : valider l'architecture cible, identifier les friction points, former les équipes en conditions réelles.

Livrable : runbook de migration validé, architecture de référence, coûts réels vs estimés.

Étape 3 — Wave 1 (6–10 semaines)

Migration des applications prioritaires : celles avec le meilleur ratio effort/bénéfice. Procédez par lots de 5-10 apps. Chaque lot = tests de non-régression + validation métier avant basculement de trafic.

Livrable : 40-60% du portfolio migré, KPIs de performance cloud vs on-prem.

Étape 4 — Optimize (continu)

La migration n'est pas la fin, c'est le début. Right-sizing des instances (utilisation CPU/RAM réelle), activation des Reserved Instances ou Savings Plans, mise en place du FinOps : budgets, alertes, dashboards coûts.

Livrable : réduction de 20-30% supplémentaire sur la facture cloud initiale.

Étape 5 — Scale

Migration des applications restantes avec les leçons apprises. Exploration des services cloud-native pour les nouveaux projets. Transition vers une culture cloud-first dans les équipes de développement.

Les coûts cachés : ce qu'on ne vous dit pas

Voici les postes budgétaires que les devis cloud omettent systématiquement :

• Egress réseau : Azure, AWS et GCP facturent 0.08–0.09 USD/GB pour transférer vos données vers l'extérieur. Pour un système avec 10 TB/mois de transfert sortant = 800–900 USD/mois supplémentaires.
• Support Enterprise : Le support Business ou Enterprise représente 10%+ de votre facture mensuelle. Sur 50,000 USD/mois de cloud, ça fait 5,000–8,000 USD/mois juste pour du support.
• Licences BYOL : Windows Server et SQL Server en BYOL (Bring Your Own License) nécessitent une vérification rigoureuse de vos droits d'utilisation. Certaines licences on-prem ne se transfèrent pas.
• Formation : Certifications AWS Solutions Architect, Azure Administrator, ou Google Cloud Professional — comptez 15,000–25,000 CAD pour former une équipe de 3-4 personnes correctement.
• Ressources idle : Une seule instance EC2 m5.xlarge laissée allumée = 130 USD/mois. Multipliez par 20 ressources oubliées = 2,600 USD/mois gaspillés. Ça arrive. Souvent.

Cas concret BOTUM : −40% de coûts en 90 jours

Un client de taille intermédiaire — secteur services, 120 VMs on-prem, infrastructure vieillissante, bail datacenter expirant dans 8 mois — nous mandate pour une migration cloud complète.

Assessment (3 semaines) : Inventaire des 120 VMs. Résultat : 45% des apps sont Replatform-ready, 35% nécessitent Rehost en première phase puis Replatform, 20% sont des candidats Refactor pour la phase 2. 15 VMs sont à désactiver (apps abandonnées mais toujours actives).

Stratégie retenue : 80% Replatform (bases de données vers services managés, apps web vers containers managés), 20% Refactor pour les 3 apps à fort trafic.

Exécution : Migration en 4 waves sur 10 semaines. À chaque wave, right-sizing immédiat et activation des Reserved Instances 1 an pour les workloads stables identifiés.

Résultat à 90 jours :

• Coûts d'infrastructure : −40% vs on-prem (incluant l'amortissement du bail datacenter)
• Disponibilité : 99.97% vs 99.2% on-prem (incidents liés au hardware éliminés)
• Temps de déploiement : de 4h à 12 minutes (CI/CD natif cloud)
• 15 VMs désactivées = économie immédiate de 3,200 USD/mois

La migration la plus efficace n'est pas nécessairement la plus rapide. C'est celle qui est préparée.

Conclusion

Migrer vers le cloud, c'est une décision stratégique, pas une décision technique. Ça commence par un assessment honnête de votre portfolio applicatif, un business case rigoureux, et une stratégie claire par application.

Le modèle Replatform offre le meilleur ratio risque/bénéfice pour la majorité des PME. Le Refactor, quand il est justifié, transforme réellement les organisations. Le Lift & Shift pur est rarement la bonne réponse — sauf comme étape transitoire planifiée.

Et surtout : prévoyez 1.4x votre estimation. Formez vos équipes. Activez le FinOps dès le début. Les économies cloud ne sont pas automatiques — elles se construisent.