Guide : réussir sa migration 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.

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.

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.

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.

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

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.

• ☐ 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