Checklist migration cloud : 12 étapes pour réussir sans mauvaises surprises
Azure, AWS, Google Cloud ou OVH — la migration vers le cloud est un projet structurant. 80 % des migrations qui échouent n’échouent pas à cause de la technologie, mais à cause d’une mauvaise préparation. Cette checklist vous guide étape par étape.
Pourquoi migrer vers le cloud — et pourquoi maintenant ?
Le cloud n’est plus une option réservée aux grandes entreprises. Les entreprises qui migrent gagnent en agilité, en sécurité et en maîtrise des coûts — à condition de ne pas improviser la migration.
Réduction des coûts fixes
Fin des serveurs à amortir et des licences perpétuelles. Paiement à l’usage selon les ressources réellement consommées.
Sécurité renforcée
Les grands fournisseurs investissent massivement en sécurité. Mises à jour automatiques, chiffrement natif, conformité certifiée.
Continuité d’activité
Haute disponibilité, sauvegardes géo-redondantes et reprise d’activité en quelques minutes plutôt que plusieurs heures.
Scalabilité instantanée
Augmenter les ressources en quelques clics selon l’activité — sans investissement matériel préalable.
Télétravail & mobilité
Accès sécurisé aux applications depuis n’importe quel appareil, partout dans le monde.
Conformité réglementaire
Certifications ISO 27001, HDS, PCI DSS, RGPD incluses chez les grands fournisseurs — sans effort supplémentaire.
Avant de commencer — les 8 conditions à réunir
Une migration cloud réussie se prépare bien en amont du démarrage technique. Ces 8 conditions doivent être réunies avant de lancer la première instance cloud.
Sponsorship direction — La migration doit être portée par la direction. Un projet sans sponsor exécutif échoue ou s’enlise.
Budget validé — Coûts migration + abonnement cloud + formation + éventuel hébergement hybride transitoire. Prévoir 20% de marge.
Inventaire du SI existant — Liste complète de toutes les applications, serveurs, bases de données et dépendances. Rien ne doit être oublié.
Objectifs mesurables définis — Réduction des coûts de X%, disponibilité cible de X%, délai de reprise d’activité réduit à Xh.
Équipe projet constituée — Chef de projet, responsable technique interne, prestataire cloud, responsable métier pour les tests.
Stratégie de données définie — Quelles données migrent ? Lesquelles restent sur site (données sensibles, souveraineté) ? Dans quels pays sont-elles hébergées ?
Plan de rollback documenté — Que faire si la migration échoue ? Quelle est la procédure de retour en arrière pour chaque application critique ?
Communication préparée — Informer les équipes, définir les fenêtres de maintenance, anticiper les questions des collaborateurs.
Les 12 étapes d’une migration réussie
Ces 12 étapes couvrent les trois phases d’une migration cloud : préparation, exécution et stabilisation. Aucune ne doit être sautée.
La première étape est de définir précisément pourquoi vous migrez et ce que vous migrez. Pas « aller vers le cloud » — mais « réduire les coûts d’infrastructure de 30% en 18 mois » ou « atteindre 99,9% de disponibilité pour l’application CRM ».
- Objectifs de migration documentés et validés par la direction
- Applications et données dans le périmètre identifiées
- Applications hors périmètre (et raisons) documentées
- Indicateurs de réussite définis (KPIs, délais, budget)
- Planning général avec jalons validé
Un inventaire incomplet est la cause numéro un de dépassements de budget et de délais. Des applications oubliées, des dépendances non documentées, des licences manquantes découvertes en cours de migration — autant de risques évitables.
- Liste exhaustive de toutes les applications (y compris shadow IT)
- Serveurs physiques et virtuels avec configurations documentées
- Bases de données : moteur, taille, croissance annuelle
- Cartographie des dépendances inter-applications
- Inventaire des licences logicielles et de leur portabilité cloud
- Volumétrie de données totale et croissance estimée
Chaque application doit être évaluée selon deux axes : sa criticité métier (que se passe-t-il si elle est indisponible 1h ?) et sa complexité technique de migration. Cette matrice détermine l’ordre et la stratégie de migration.
- RTO défini pour chaque application critique (délai max d’indisponibilité)
- RPO défini (perte de données maximale acceptable)
- Stratégie de migration choisie par application (les 5R)
- Ordre de migration validé : en commençant par les applications peu critiques
Ne commencez jamais par l’application la plus critique. Commencez par un « quick win » — une application simple à migrer qui vous permettra de valider votre méthode avant d’aborder les systèmes sensibles.
Avant toute migration, toutes les données doivent être sauvegardées dans un emplacement distinct — physiquement séparé de la source et du cloud cible. Cette étape n’est pas négociable.
- Sauvegarde complète de toutes les données dans un site tiers
- Restauration testée et validée avant le démarrage
- Rétention minimum de 30 jours confirmée
- Sauvegarde immuable en place (protection anti-ransomware)
Il n’y a pas de « meilleur » fournisseur cloud universel — il y a celui qui correspond le mieux à votre environnement existant, vos contraintes réglementaires et vos objectifs. De nombreuses entreprises choisissent Azure si elles utilisent Microsoft 365.
- Fournisseur sélectionné selon les critères : environnement existant, conformité, support
- Région d’hébergement choisie (UE obligatoire si données RGPD)
- Modèle de tarification compris et budgété (pay-as-you-go vs reserved instances)
- Certifications du fournisseur vérifiées (ISO 27001, HDS, PCI DSS selon besoin)
Migrer votre architecture actuelle telle quelle vers le cloud (lift & shift) n’est pas toujours la bonne stratégie. C’est l’occasion de revoir l’architecture pour exploiter les services natifs du cloud et optimiser les coûts.
- Architecture cible documentée avec schéma
- Services cloud cibles identifiés (VM, containers, PaaS, SaaS)
- Architecture réseau (VNet, VPC, sous-réseaux, firewall) définie
- Haute disponibilité et redondance planifiées
- Estimation de coût mensuelle calculée avant démarrage
Le cloud suit un modèle de responsabilité partagée : le fournisseur sécurise l’infrastructure physique, vous sécurisez vos données et vos configurations. Les incidents cloud sont très souvent dus à des mauvaises configurations, pas à des failles du fournisseur.
- MFA activé sur tous les comptes cloud (admin et utilisateurs)
- Principe du moindre privilège appliqué aux rôles IAM
- Chiffrement des données en transit et au repos configuré
- Groupes de sécurité et pare-feu réseau configurés et testés
- Journaux d’audit (CloudTrail, Azure Monitor) activés
- Scanner de conformité configuré (Security Center, GuardDuty)
Le réseau est souvent le point de blocage oublié. Transférer des téraoctets de données vers le cloud prend du temps. Accéder aux applications cloud depuis vos bureaux nécessite une bande passante adaptée et une connexion sécurisée.
- Bande passante actuelle mesurée et comparée aux besoins estimés
- Solution de connexion sécurisée choisie (VPN site-to-site, ExpressRoute, Direct Connect)
- Délai de transfert de données estimé selon le volume
- Solution de transfert initial choisie (réseau ou appliance physique si > 100 To)
Chaque migration doit être testée dans un environnement isolé avant d’être appliquée en production. Cette étape révèle les problèmes de compatibilité, de performance et de configuration — sans impact sur les utilisateurs.
- Environnement de développement/test créé dans le cloud cible
- Application migrée et testée fonctionnellement en environnement de test
- Tests de performance réalisés et résultats conformes aux attentes
- Tests de sécurité basiques effectués (ports ouverts, accès non autorisés)
- Tests de restauration depuis les sauvegardes cloud validés
La migration de production se fait idéalement pendant une fenêtre de maintenance planifiée, avec toutes les parties prenantes alertées. Le plan de rollback doit être prêt à être exécuté en quelques minutes si nécessaire.
- Fenêtre de maintenance définie et communiquée aux équipes
- Plan de rollback documenté et testé
- Toute l’équipe technique présente ou joignable pendant la fenêtre
- Point de décision go/no-go défini (si problème à T+2h → rollback automatique)
- Communication envoyée aux utilisateurs avant, pendant et après
Ne supprimez jamais les systèmes on-premise avant d’avoir validé le bon fonctionnement complet du cloud pendant au moins 2 à 4 semaines. Le retour en arrière doit toujours rester possible.
Les 4 premières semaines post-migration sont critiques. Performance, coûts, comportements inattendus, tickets utilisateurs — tout doit être surveillé activement avant de déclarer la migration terminée.
- Monitoring des performances activé et dashboards configurés
- Alertes sur les métriques clés (disponibilité, temps de réponse, coûts)
- Point quotidien avec l’équipe technique pendant les 2 premières semaines
- Retours utilisateurs collectés et analysés
- Première facture cloud analysée par rapport aux estimations
L’optimisation des coûts cloud n’est pas un projet ponctuel — c’est une pratique continue. Sans surveillance active, les dépenses cloud dérapent : instances inutilisées, stockage non nettoyé, services activés et oubliés.
- Rapport d’optimisation des coûts réalisé à J+30 et J+90
- Instances surdimensionnées identifiées et ajustées (rightsizing)
- Ressources inutilisées supprimées (snapshots, disques orphelins, IPs)
- Reserved instances évaluées pour les charges stables
- Système on-premise désactivé après validation complète
- Bilan de migration documenté et partagé avec la direction
Azure · AWS · Google Cloud · OVH — lequel choisir ?
| Critère | Azure (Microsoft) | AWS (Amazon) | Google Cloud | OVH Cloud |
|---|---|---|---|---|
| Recommandé si | Utilisateurs Microsoft 365 | Besoin maximal de services | Data & IA au cœur du projet | Contraintes RGPD / souveraineté |
| Intégration Microsoft 365 | Native et complète | Partielle | Partielle | Partielle |
| Richesse des services | Très élevée | La plus élevée | Élevée | Modérée |
| Hébergement France | Oui (Paris) | Oui (Paris) | Oui (Paris) | Oui (Roubaix, Strasbourg) |
| Conformité RGPD | Certifié | Certifié | Certifié | Très fort (données FR) |
| Support entreprise | Bon | Bon | Moins adapté à certains environnements | Très bon (écosystème FR) |
| Courbe d’apprentissage | Modérée | Élevée | Modérée à élevée | Faible à modérée |
| Coût estimatif | Modéré | Modéré à élevé | Modéré | Le plus compétitif |
Si vous utilisez Microsoft 365 : Azure. L’intégration est native, la gestion des identités est unifiée (Azure AD / Entra ID) et le support s’intègre bien aux environnements Microsoft. Si la souveraineté est la priorité absolue : OVH Cloud avec hébergement en France.
Comment migrer chaque application — les 5R
Il n’y a pas une seule façon de migrer vers le cloud. En fonction de l’application, plusieurs approches sont possibles. Le framework « 5R » aide à prendre la bonne décision pour chaque système.
| Stratégie | Description | Quand l’utiliser | Complexité |
|---|---|---|---|
| Rehost (Lift & Shift) | Migrer l’application telle quelle vers le cloud | Migration rapide, première étape | Faible |
| Replatform | Petits ajustements pour exploiter les services cloud | Application stable, gains ciblés | Modérée |
| Refactor / Re-architect | Réécrire pour architecture cloud-native | Application stratégique à moderniser | Élevée |
| Replace (SaaS) | Remplacer par une solution SaaS équivalente | Solution SaaS mature disponible | Faible à modérée |
| Retire | Désactiver l’application — elle n’est plus utile | Application obsolète identifiée | Nulle |
La méthode UNTHUB — 8 phases pour migrer sans stress
Audit & inventaire
Cartographie complète du SI existant, identification des dépendances et des risques.
Architecture cible
Conception de l’architecture cloud cible avec estimation de coût et plan de migration.
Sécurité & compliance
Définition de la politique de sécurité cloud, IAM, chiffrement et conformité RGPD/NIS2.
POC & tests
Migration pilote d’une application non critique. Validation de la méthode et des outils.
Migration progressive
Migration par vagues selon la criticité. Plan de rollback activable à chaque étape.
Validation & tests
Tests fonctionnels, performance et sécurité avant chaque passage en production.
Go-live & stabilisation
Bascule production avec monitoring renforcé pendant 30 jours post-migration.
Optimisation
Rightsizing, suppression des ressources inutiles, analyse des coûts et recommandations.
Rôles et responsabilités
Les indicateurs d’une migration réussie
Checklist finale — les 50 points à valider
Cette checklist synthétise l’essentiel des 12 étapes. À imprimer ou à partager avec votre équipe projet.
Les 8 erreurs qui font échouer les migrations
Migrer sans inventaire complet. Des applications oubliées sont découvertes en cours de migration — délais et coûts explosent.
Sous-estimer les coûts cloud. Le cloud coûte plus cher sans optimisation. La première facture surprend souvent.
Ne pas tester le rollback. Découvrir que le plan de retour ne fonctionne pas le jour de la migration est catastrophique.
Commencer par les applications critiques. Commencez toujours par une application peu critique pour valider la méthode.
Désactiver le SI on-premise trop vite. Attendez au minimum 4 semaines de bon fonctionnement cloud avant de l’éteindre.
Ignorer la sécurité du cloud. Les mauvaises configurations IAM sont la principale cause d’incidents dans le cloud.
Ne pas former les équipes. Une équipe non formée à la gestion cloud crée des incidents en production.
Migrer pour migrer. Si votre SI actuel fonctionne bien, définissez d’abord précisément ce que le cloud vous apportera.
Tout ce que vous voulez savoir sur la migration cloud
Combien coûte une migration cloud ?▼
Le coût dépend du volume de données, du nombre d’applications, de la complexité de l’architecture et des choix techniques. Une migration simple (quelques serveurs) peut coûter de 5 000 à 20 000 € en prestation, plus le coût cloud mensuel récurrent. Une migration complexe multi-applications peut dépasser 100 000 €. UNTHUB réalise un chiffrage précis après un audit initial.
Combien de temps dure une migration cloud ?▼
De quelques semaines pour une migration simple (2 à 3 serveurs) à 12 à 18 mois pour un SI complexe multi-sites. De nombreuses entreprises réalisent leur migration en 3 à 6 mois. La phase de préparation représente généralement 40% de la durée totale.
Azure ou AWS pour une entreprise ?▼
Si vous utilisez déjà Microsoft 365, Azure est presque toujours le meilleur choix : intégration native des identités, support adapté aux PME, familiarité de l’écosystème. AWS offre davantage de services mais une courbe d’apprentissage plus élevée.
Le cloud est-il compatible avec le RGPD ?▼
Oui, à condition de choisir un hébergement dans l’Union européenne et de vérifier les certifications du fournisseur. Azure, AWS et Google Cloud proposent tous un hébergement en France avec des certifications RGPD. OVH est particulièrement plébiscité pour la souveraineté des données.
Le cloud coûte-t-il moins cher que l’on-premise ?▼
Pas systématiquement. Le cloud élimine les coûts d’investissement (serveurs, licences) mais crée des coûts d’abonnement récurrents. Il est généralement plus économique pour les entreprises qui disposent des infrastructures vieillissantes à renouveler, ou qui ont des besoins variables. Un cloud non optimisé peut coûter plus cher que l’on-premise.
Peut-on migrer partiellement — garder certains systèmes sur site ?▼
Oui — c’est ce qu’on appelle l’architecture hybride. Elle est parfaitement viable et souvent recommandée pour les systèmes sensibles ou les applications legacy difficiles à migrer. Le SI hybride peut être une étape transitoire ou une cible durable selon vos contraintes.
Mes données sont-elles en sécurité dans le cloud ?▼
Le cloud suit un modèle de responsabilité partagée. Le fournisseur sécurise l’infrastructure physique. Vous sécurisez vos configurations, accès et données. La grande majorité des incidents cloud provient de mauvaises configurations (IAM trop permissifs, buckets S3 publics, MFA désactivé) — pas de failles chez le fournisseur.
Qu’est-ce que le « lift and shift » ?▼
Le lift and shift (ou rehost) consiste à migrer une application telle quelle vers le cloud, sans la modifier. C’est la stratégie la plus rapide et la moins risquée. Elle ne tire pas pleinement parti des services cloud natifs, mais permet une migration rapide avant une optimisation ultérieure.
Comment savoir si une application est prête pour le cloud ?▼
Les critères clés : l’application est-elle supportée par son éditeur en environnement cloud ? Ses licences sont-elles transférables ? A-t-elle des dépendances matérielles spécifiques ? Un audit applicatif répond à ces questions avant de commencer.
Faut-il migrer toutes ses applications vers le cloud ?▼
Non. Certaines applications legacy très spécifiques, des systèmes industriels ou des applications avec des contraintes réglementaires particulières peuvent légitimement rester on-premise. L’objectif est de migrer ce qui apporte de la valeur, pas de migrer pour migrer.
Ressources associées
Votre migration cloud mérite un expert dédié.
UNTHUB accompagne les entreprises dans leurs migrations cloud — audit, architecture, sécurité et optimisation. Réponse sous 48h.