Pourquoi migrer vers le cloud
Le cloud n'est pas une fin en soi. Migrer sans objectif clair conduit à des coûts qui explosent et à des performances dégradées.
Les motivations valables
Élasticité — absorber les pics de charge sans surprovisionnement
Agilité — provisionner une nouvelle ressource en minutes plutôt qu'en semaines
Innovation — accéder à des services managés (IA, analytics, IoT) difficiles à opérer en local
Résilience — disposer d'une redondance géographique
Coûts — dans certains cas, réduire le coût total de possession
Les motivations douteuses
« Tout le monde y va » — pas une raison stratégique
« On n'aura plus besoin d'IT » — faux, l'IT change de nature mais reste indispensable
« C'est moins cher » — pas systématiquement, surtout sans optimisation
Une migration cloud se justifie par des objectifs business mesurables.
Les 5 stratégies de migration (règle des 5 R)
Toutes les applications ne migrent pas de la même façon. Cinq stratégies existent.
1. Rehost (lift and shift)
Déplacer l'application telle quelle vers le cloud. Rapide, peu risqué, mais n'exploite pas les avantages du cloud. Convient aux applications critiques à migrer vite.
2. Replatform
Adapter légèrement l'application pour profiter de services managés (base de données managée, cache managé). Compromis entre rapidité et optimisation.
3. Refactor / Rearchitect
Reconstruire l'application pour être cloud-native. Long, coûteux, mais optimal à long terme. À réserver aux applications stratégiques.
4. Repurchase
Remplacer l'application par une solution SaaS équivalente. Simple quand une solution existe, mais implique un changement d'outil et de contrat.
5. Retire / Retain
Supprimer l'application (obsolète) ou la conserver en local (trop spécifique, données sensibles).
Le bon mix
Une migration réussie combine ces stratégies selon les applications. Tout migrer en rehost est rapide mais coûteux à long terme. Tout refactor est trop long.
Les 4 phases d'une migration
1. Évaluation (2-3 mois)
Inventaire des applications, dépendances, volumétrie, contraintes. Classification selon les 5 R. Estimation des coûts cible.
2. Fondations (1-2 mois)
Mise en place de l'infrastructure cloud cible : comptes, réseaux, sécurité, monitoring. Pas encore de migration d'applications.
3. Migration progressive (6-18 mois)
Migration par vagues. Chaque vague contient un petit nombre d'applications. Tests, validation, ajustement.
4. Optimisation continue
Après migration : right-sizing, réservations, monitoring, amélioration de la résilience.
Le calendrier réel dépend de la taille du patrimoine. Pour 50 à 100 applications, compter 12 à 24 mois.
Sécurité et conformité
La sécurité dans le cloud suit des principes spécifiques.
Responsabilité partagée
Le fournisseur cloud est responsable de la sécurité de l'infrastructure. Le client est responsable de la sécurité dans l'infrastructure. Ne jamais confondre.
Identité et accès
Authentification à double facteur obligatoire
Principe du moindre privilège
Comptes de service séparés des comptes humains
Rotation régulière des secrets
Chiffrement
Chiffrement au repos (disques, bases de données, buckets)
Chiffrement en transit (TLS obligatoire partout)
Gestion des clés (KMS ou équivalent)
Conformité
Vérifier que le fournisseur cloud respecte les réglementations applicables : RGPD, ISO 27001, SOC 2. Pour les données sensibles, préférer une région locale.
Maîtriser les coûts
Le coût est l'un des principaux échecs des migrations cloud.
Le piège du surprovisionnement
Par crainte de la panne, on surdimensionne. Résultat : 30 à 50 % des ressources sont sous-utilisées.
Les leviers d'optimisation
Right-sizing — ajuster la taille des ressources à l'usage réel
Réservations — s'engager 1 ou 3 ans pour les charges stables (-30 à -60 %)
Spot instances — pour les charges flexibles (-60 à -80 %)
Storage lifecycle — basculer automatiquement les données froides vers du stockage moins cher
Serverless — pour les charges intermittentes
La gouvernance des coûts
Tag obligatoire sur chaque ressource (projet, équipe, environnement)
Tableau de bord de coûts accessible aux équipes
Revue mensuelle des dérives
Objectifs d'optimisation par équipe
Infrastructure as Code (IaC)
L'IaC est la pratique qui consiste à décrire l'infrastructure dans des fichiers versionnés, plutôt qu'à la configurer manuellement.
Pourquoi c'est essentiel
Reproductibilité — recréer un environnement identique en quelques minutes
Traçabilité — chaque changement est historisé dans Git
Réversibilité — revenir à une version antérieure si besoin
Collaboration — plusieurs personnes peuvent travailler sans conflits
Les outils
Terraform — standard multi-cloud
Pulumi — alternative en langage de programmation
CloudFormation — spécifique AWS
Ansible — configuration des serveurs
Recommandation
Adopter IaC dès le début de la migration. Rétrofitter l'IaC sur une infrastructure existante est bien plus difficile.
Checklist migration cloud
☐ Objectifs business clairs et mesurables
☐ Inventaire des applications réalisé
☐ Stratégie de migration (5R) définie pour chaque application
☐ Architecture cible documentée
☐ Sécurité (IAM, chiffrement, réseau) en place
☐ IaC pour toute l'infrastructure
☐ Monitoring et alerting
☐ Plan de réversibilité (fallback on-prem)
☐ Formation des équipes
☐ Politique FinOps
☐ Migration progressive par vagues