Migration vers le cloud : guide pratique pour les PME
Pourquoi migrer vers le cloud
Une migration cloud reussie suit quatre etapes : audit de l’existant et classification des charges de travail, choix du fournisseur (AWS, Google Cloud, Azure ou alternatives europeennes), planification avec estimation des coûts, puis execution via Infrastructure as Code. Le processus dure entre 2 et 6 mois pour une PME selon le volume de donnees et la complexite applicative. Trois raisons justifient concrètement le mouvement :
La scalabilite. Un serveur physique ou un VPS a des limites fixées. Quand le trafic double en une semaine (campagne marketing, saisonalite), les ressources ne suivent pas. Le cloud permet d’ajouter de la capacite en quelques minutes et de la reduire quand le pic est passe.
La resilience. Un serveur heberge dans une seule salle machine constitue un point de defaillance unique. Le cloud distribue les donnees et les services sur plusieurs datacenters. La panne d’un site geographique n’interrompt pas le service.
La reduction de la charge d’exploitation. Les services manages (base de donnees, file d’attente, stockage objet) transferent la maintenance operationnelle au fournisseur cloud. L’equipe interne se concentre sur le code applicatif plutot que sur les mises a jour systeme.
Audit de l’existant
Inventaire technique
Avant de migrer quoi que ce soit, cartographier l’infrastructure actuelle :
- Serveurs — Nombre, systeme d’exploitation, role (web, base de donnees, mail, fichiers)
- Applications — Technologies utilisees, dependances, versions
- Donnees — Volume, type (fichiers, bases relationnelles, objets), frequence d’acces
- Reseau — Flux entre les composants, bande passante consommee, VPN
Cet inventaire revele les interdependances. Migrer le serveur web sans le serveur de base de donnees casse l’application si les deux communiquent en reseau local. Le guide sur le choix d’un hebergement web aide a evaluer les options avant de s’engager dans une migration.
Classification des charges de travail
Chaque charge de travail se classe dans une des categories suivantes :
| Strategie | Description | Exemple |
|---|---|---|
| Rehost (lift & shift) | Deplacer tel quel vers le cloud | Serveur web sur VM cloud |
| Replatform | Adapter a un service manage | MySQL local vers RDS |
| Refactor | Reecrire pour exploiter le cloud | Monolithe vers microservices |
| Retain | Garder sur site | Logiciel metier non compatible |
| Retire | Decommissionner | Application obsolete |
Le lift & shift est la methode la plus rapide. Elle ne tire pas parti des avantages du cloud (elasticite, services manages) mais elle minimise les risques de la migration. Le replatforming offre un bon compromis : migrer vers des services manages (base de donnees, cache, stockage) sans reecrire le code applicatif.
Choix du fournisseur
Les trois hyperscalers
| Fournisseur | Points forts | Points faibles | Region FR |
|---|---|---|---|
| AWS | Catalogue de services le plus large, maturite | Complexite, coûts difficiles a prevoir | Paris (eu-west-3) |
| Google Cloud | Performances reseau, BigQuery, Kubernetes natif | Moins de services que AWS, support | Paris (europe-west9) |
| Azure | Integration Microsoft 365, hybrid cloud | Interface moins intuitive | Paris (France Central) |
Alternatives europeennes
OVH Public Cloud, Scaleway et Infomaniak proposent des offres cloud avec des datacenters en France et une conformite RGPD simplifiee. Le catalogue de services est plus restreint que celui des hyperscalers, mais suffisant pour les cas d’usage les plus courants (VM, stockage, base de donnees, Kubernetes). Le deploiement du MFA sur les comptes cloud fait partie des prerequis de securite quel que soit le fournisseur choisi.
Le choix depend du stack technique et des contraintes reglementaires. Une PME qui utilise Microsoft 365 trouve un avantage operationnel avec Azure. Une equipe qui developpe en Python et utilise des pipelines de donnees beneficie de l’ecosysteme Google Cloud.
Planification de la migration
Ordre de migration
Commencer par les charges de travail les moins critiques pour accumuler de l’experience avant de migrer les systemes de production.
Ordre recommande :
- Environnements de developpement et de test
- Sites web et applications front-end
- Applications internes non critiques
- Bases de donnees et applications metier
- Services de messagerie et outils collaboratifs
Estimation des coûts
Le cloud facture a l’usage : compute (CPU/RAM), stockage, transfert de donnees, services manages. Les surprises viennent souvent du transfert de donnees sortant (egress), facture par Go chez tous les hyperscalers.
Outils d’estimation :
- AWS Pricing Calculator — Estimation detaillee par service
- Google Cloud Pricing Calculator — Equivalent Google
- Infracost — Estimation des coûts depuis du code Terraform
Comparer le coût cloud projete au coût actuel sur 12 et 36 mois. Le cloud coûte souvent plus cher qu’un VPS pour une charge stable et previsible. L’avantage financier apparaît quand la charge varie ou quand les services manages reduisent le temps d’exploitation.
Migration des donnees
Le transfert de donnees volumineuses via Internet prend du temps. Pour 1 To de donnees sur une connexion 100 Mbps, compter environ 24 heures de transfert ininterrompu.
Strategies selon le volume :
| Volume | Methode | Duree indicative |
|---|---|---|
| < 100 Go | Transfert en ligne (rsync, S3 CLI) | Quelques heures |
| 100 Go - 10 To | Transfert en ligne avec parallelisation | 1-7 jours |
| > 10 To | Envoi physique (AWS Snowball, disque dur) | 1-2 semaines |
Pour les bases de donnees, le schema de migration depend du moteur. PostgreSQL et MySQL disposent d’outils de replication qui permettent une migration avec un temps d’arret minimal (quelques minutes).
Execution
Infrastructure as Code
Definir l’infrastructure cloud en code (Terraform, Pulumi, CloudFormation) plutot qu’en cliquant dans la console. Les avantages :
- Reproductibilite : deployer le meme environnement en dev, staging et production
- Versioning : suivre les changements d’infrastructure dans Git
- Revue : les modifications passent par une pull request avant d’etre appliquees
- Rollback : revenir a un etat precedent en cas de probleme
Terraform est le standard multi-cloud. CloudFormation convient aux environnements exclusivement AWS. Pulumi attire les equipes qui preferent ecrire en TypeScript ou Python plutot qu’en HCL. La maîtrise des commandes Linux reste indispensable pour diagnostiquer les problemes sur les instances cloud.
Bascule et validation
Le jour de la migration, le processus suit un schema standardise :
- Deployer l’infrastructure cloud et les applications
- Synchroniser les donnees une derniere fois
- Valider les tests de fumee sur l’environnement cloud
- Basculer le DNS vers la nouvelle infrastructure
- Surveiller les metriques pendant 24-48 heures
- Decommissionner l’ancienne infrastructure apres validation (garder les sauvegardes 30 jours)
La bascule DNS peut se faire progressivement avec un poids (weighted routing) : 10% du trafic vers le cloud, puis 50%, puis 100%. Cette approche detecte les problemes avant qu’ils n’impactent tous les utilisateurs. Les applications web modernes construites sur des frameworks JavaScript beneficient souvent de cette transition grace aux plateformes de deploiement integrees (Vercel, Cloudflare Pages).
Apres la migration
Optimisation des coûts
Trois actions reduisent la facture cloud de 20 a 40% dans les 3 mois suivant la migration :
- Right-sizing — Reduire les instances surdimensionnees. La plupart des VM migrees utilisent moins de 30% de leurs ressources.
- Instances reservees — Engager sur 1 ou 3 ans pour les charges stables reduit le prix de 30 a 60%.
- Nettoyage — Supprimer les ressources orphelines (disques detaches, snapshots obsoletes, IPs non utilisees).
Monitoring
Les outils de monitoring cloud (CloudWatch, Stackdriver, Azure Monitor) remplacent les outils on-premise. Configurer des alertes sur :
- Utilisation CPU et memoire
- Latence des requetes
- Taux d’erreur applicatif
- Coût journalier (alerte si depassement du budget prevu)
La migration vers le cloud n’est pas un projet a date fixe. C’est une transition progressive qui transforme la maniere dont l’equipe gere l’infrastructure. Les premiers mois demandent un investissement en apprentissage. La securisation des acces doit accompagner chaque etape de la migration. Le retour se mesure en agilite operationnelle et en capacite a faire evoluer l’infrastructure au rythme du metier.