Plan de migration cloud en six étapes : de l'inventaire à la bascule
Un plan de migration cloud en six étapes pour une PME : inventaire, stratégie, pilote, bascule, validation et clôture, avec budget et critères de décision.
Une migration cloud réussie suit six étapes : inventorier ce qui existe, choisir une stratégie par application, réaliser un pilote, planifier et exécuter la bascule, valider, puis clôturer en supprimant l'ancien environnement. Le plus grand risque n'est pas technique mais organisationnel : une bascule précipitée sans sauvegarde testée, sans plan de retour arrière et sans critères de succès définis à l'avance. Prévoyez de passer plus de temps à préparer qu'à migrer ; c'est la préparation qui détermine la durée d'interruption et le coût final.
Étape 1 : inventorier et cartographier
Listez toutes les applications, serveurs, bases de données, tâches planifiées, domaines, certificats, flux entre systèmes et dépendances externes. Pour chaque élément, notez : propriétaire, criticité, volume de données, dépendances, niveau de service attendu, contraintes réglementaires (données personnelles, de santé), version des logiciels et date de fin de support. Un tableur suffit pour une petite structure. Cet inventaire révèle souvent des éléments oubliés : un script qui tourne sur un serveur ancien, un certificat qui expire, une règle de pare-feu dont personne ne se souvient.
Étape 2 : choisir la stratégie par application
On distingue classiquement plusieurs approches, pour chaque application.
| Stratégie | Principe | Avantage | Inconvénient |
|---|---|---|---|
| Rehosting (« lift and shift ») | Déplacer la machine à l'identique | Rapide, peu de changements | Ne profite pas des services du cloud |
| Replatforming | Changer certains composants (base de données managée) | Réduit l'administration | Nécessite des tests supplémentaires |
| Refactoring | Réécrire pour une architecture cloud | Meilleure élasticité et résilience | Coûteux et long |
| Remplacement | Adopter un logiciel en ligne à la place | Supprime l'exploitation | Migration de données et conduite du changement |
| Conservation | Laisser en l'état, pour l'instant | Aucun risque immédiat | Dette technique qui subsiste |
| Retrait | Arrêter ce qui ne sert plus | Économie directe | Vérifier l'absence d'usage caché |
Pour la plupart des PME, le rehosting avec quelques ajustements (sauvegardes, supervision) est la stratégie la plus rentable. Le refactoring se justifie lorsque l'application a de réels besoins d'élasticité ou qu'elle est de toute façon en cours de refonte.
Étape 3 : concevoir la cible et lancer un pilote
Définissez l'architecture cible : réseau, sécurité, stockage, sauvegardes, supervision. Choisissez une application peu critique pour un pilote : cela valide la chaîne de migration, révèle les surprises et rassure les équipes. Mesurez pendant le pilote : temps de réponse, consommation de ressources, coût réel, difficulté d'exploitation. Comparez au budget prévu avant de poursuivre. C'est le moment d'ajuster la taille des machines.
Étape 4 : préparer la bascule
Rédigez un plan de bascule minuté : qui fait quoi, à quelle heure, dans quel ordre. Prévoyez :
- une sauvegarde complète vérifiée de l'ancien environnement ;
- la réduction du TTL DNS plusieurs jours à l'avance ;
- une fenêtre de maintenance communiquée aux utilisateurs ;
- un plan de retour arrière avec une condition de déclenchement claire (par exemple : si le test de paiement échoue après 30 minutes) ;
- une liste de vérification à dérouler après bascule. Vous pouvez utiliser notre liste de contrôle de migration.
Étape 5 : exécuter et valider
Après la bascule, surveillez de près les journaux d'erreurs, les performances, les paiements, les envois d'e-mails et les tâches planifiées. Gardez l'ancien environnement intact, mais coupé des écritures, pendant une période de retour arrière définie à l'avance (une à quatre semaines selon la criticité). Recueillez les retours des utilisateurs : les problèmes subtils apparaissent à l'usage.
Étape 6 : clôturer proprement
Une fois la période de validation terminée, résiliez l'ancien hébergement, demandez la suppression ou la restitution des données et conservez une trace de cette demande, notamment si des données personnelles étaient concernées. Mettez à jour la documentation, l'inventaire, les procédures de restauration et les contacts. Dressez un bilan : coûts réels, écarts avec le prévisionnel, leçons apprises.
Budget : poste par poste (exemple illustratif)
Voici un chiffrage fictif pour la migration d'un petit système d'information de trois applications.
| Poste | Hypothèse | Montant |
|---|---|---|
| Inventaire et conception | 4 jours × 500 € | 2 000 € |
| Mise en place de la cible | 3 jours × 500 € | 1 500 € |
| Migration et tests | 5 jours × 500 € | 2 500 € |
| Double facturation (un mois) | 400 € | 400 € |
| Formation | 1 jour × 500 € | 500 € |
| Aléas (10 %) | 690 € | |
| Total | 7 590 € |
Avec une économie annuelle estimée à 3 000 €, le retour sur investissement est de 7 590 / 3 000 ≈ 2,5 ans, hors bénéfices non financiers. Le taux journalier de 500 € est une hypothèse : adaptez-le à votre contexte. Simulez-le avec le calculateur de retour sur investissement.
Erreurs fréquentes
- Migrer sans inventaire exhaustif et découvrir une dépendance le jour de la bascule.
- Négliger de tester la restauration de la sauvegarde.
- Sous-estimer le temps de transfert de grands volumes de données : 1 To à 100 Mbit/s demande plus de 22 heures en conditions idéales (1 To = 8 000 000 Mbit ; divisé par 100 Mbit/s, soit 80 000 secondes). Prévoyez une synchronisation incrémentale.
- Oublier la communication auprès des utilisateurs et des clients.
- Basculer un vendredi soir sans équipe disponible le week-end.
Quand faire appel à un professionnel
Si votre système traite des paiements, des données de santé ou des volumes importants, ou si vous n'avez aucune compétence d'exploitation en interne, un prestataire peut piloter la migration. Demandez un périmètre clair, un calendrier et la remise d'une documentation complète en fin de mission.
FAQ
Combien de temps dure une migration cloud pour une PME ?
De quelques semaines pour un site ou une application simple à plusieurs mois pour un système d'information complet. La préparation représente la plus grande partie du calendrier.
Faut-il tout migrer en même temps ?
Non. Procéder par vagues, en commençant par les applications peu critiques, réduit le risque et permet d'apprendre.
Que faire si la bascule échoue ?
Appliquez le plan de retour arrière prévu : remettre le DNS vers l'ancien environnement, rétablir les écritures et analyser la cause avant de reprogrammer.
Sources
- ANSSI – Cyber.gouv.fr — guides sur la sécurité du cloud et de l'infogérance
- CNIL — gestion des sous-traitants et sécurité des données
- Numérique.gouv.fr — doctrine et ressources sur le cloud
