Une migration cloud réussie se juge après la remise en service, pas au moment où les serveurs démarrent. Ce guide donne à une PME marocaine un plan de bascule vérifiable : inventaire, budget, essai, retour arrière et suivi après migration. Il complète notre audit DevOps avant migration.
Décider d'abord ce qui doit réellement migrer
Listez les applications, bases de données, domaines, tâches planifiées, utilisateurs et fournisseurs. Pour chaque élément, notez son responsable, ses dépendances et l'impact d'une interruption. Une application peu utilisée peut être retirée ou remplacée ; une autre peut rester sur site si sa latence, sa licence ou sa connexion locale l'exige. Le « tout cloud » n'est pas un objectif en soi.
Faites confirmer l'inventaire par les équipes métier. Le serveur oublié est souvent celui qui produit un export quotidien ou sert d'interface avec un logiciel de gestion. Conservez une copie du schéma des flux avant toute modification.
Comparer deux budgets sur le même périmètre
Séparez le coût ponctuel (audit, migration, tests, formation) du coût récurrent (calcul, stockage, sauvegardes, trafic sortant, support, supervision et licences). Pour comparer cloud et infrastructure actuelle, utilisez une période identique, par exemple 36 mois, et incluez renouvellement matériel, électricité, maintenance et temps d'administration. Les tarifs du fournisseur varient selon région, devise et usage ; demandez un chiffrage sur vos volumes réels plutôt qu'un prix générique en dirhams.
Une petite machine de test laissée active, des sauvegardes non purgées ou un trafic sortant imprévu peuvent modifier la facture. Mettez des alertes budgétaires et attribuez un propriétaire à chaque ressource avant la bascule.
Préparer une répétition de migration
Créez un environnement de test représentatif. Restaurez-y une sauvegarde, déployez l'application, vérifiez les connexions et exécutez les parcours métier critiques. Testez les droits d'accès avec de vrais rôles : administrateur, opérateur et utilisateur ordinaire. Mesurez le temps de synchronisation et de validation, plutôt que de supposer que la fenêtre prévue suffira.
Le plan de bascule doit tenir sur une page opérationnelle : heure de gel des écritures, responsable de chaque étape, validation fonctionnelle, seuil de retour arrière et canal de communication. Gardez l'ancien environnement disponible jusqu'à la fin de la période de contrôle prévue.
Exemple de critères « go / no-go »
| Contrôle | Décision attendue |
|---|---|
| Sauvegarde restaurée et données comparées | Aucune bascule sans restauration vérifiée |
| Connexions aux systèmes tiers testées | Chaque échange critique a un propriétaire |
| Parcours client et facturation validés | Les équipes métier signent la recette |
| Retour arrière répété | Durée et perte de données acceptables documentées |
| Alertes et budget configurés | Un responsable reçoit et traite les anomalies |
Les seuils chiffrés dépendent de votre activité. Une boutique qui accepte une interruption nocturne n'a pas les mêmes exigences qu'un service utilisé en continu. Fixez le délai maximal de reprise et la perte de données tolérable avec les responsables métier avant de choisir l'architecture.
Les 30 jours après la bascule
Suivez chaque jour les erreurs applicatives, le temps de réponse, les sauvegardes et la facture. Comparez les indicateurs avec l'ancienne plateforme et corrigez les ressources surdimensionnées. Programmez un exercice de restauration, vérifiez les accès temporaires ouverts pour la migration et fermez l'ancien environnement seulement après validation des données et des obligations de conservation.
Un prestataire doit vous remettre l'architecture, les accès, les procédures d'incident, les coûts récurrents estimés et les décisions restant à prendre. Pour cadrer ce travail, consultez notre service DevOps et cloud au Maroc ou contactez Sky Vaults.