La peur de l'interruption freine encore de nombreuses entreprises. Pourtant, une migration cloud bien préparée se déroule sans coupure d'activité....
La crainte qui bloque le plus souvent une migration vers le cloud n'est pas le coût : c'est l'interruption. Personne ne veut expliquer à ses équipes qu'elles ne pourront pas travailler pendant deux jours, ni à ses clients qu'ils ne peuvent pas être servis. Cette crainte est légitime, mais elle se traite par la méthode : une migration correctement préparée se déroule sur un week-end, et souvent sans que les utilisateurs s'en aperçoivent le lundi matin.
Les incidents de migration ont presque toujours les mêmes causes, et aucune n'est technique au sens strict. Un inventaire incomplet, d'abord : une application oubliée, un partage réseau que seul un service utilise, une imprimante configurée à la main il y a six ans. Un volume de données sous-estimé, ensuite : transférer plusieurs téraoctets sur une ligne dont l'émission plafonne à 200 Mbit/s prend des jours, pas des heures, et ce calcul se fait avant, pas pendant.
Vient ensuite la question des dépendances : un logiciel métier qui exige un serveur local, une licence liée à une adresse matérielle, un scanner qui dépose ses fichiers dans un dossier précis. Enfin, le facteur le plus fréquent reste humain : des utilisateurs prévenus la veille, qui découvrent lundi que leurs raccourcis ne fonctionnent plus et saturent le support pendant trois jours.
S’ajoute une cause plus banale mais redoutable : la bande passante partagée avec l’activité courante. Lancer une copie massive en pleine journée sature l’émission de la ligne et ralentit tout le monde, ce qui conduit à interrompre le transfert, à le reprendre, et à doubler la durée prévue. La parade consiste à plafonner le débit utilisé par la migration et à concentrer les gros volumes sur les nuits et les week-ends. Enfin, les comptes de service et les tâches planifiées sont régulièrement oubliés de l’inventaire : sauvegardes, exports comptables, scripts de synchronisation. Ils continuent de pointer vers l’ancien serveur après la bascule et échouent en silence, parfois pendant des semaines avant que quelqu’un s’en aperçoive.
La méthode qui évite la coupure
Une migration se conduit en quatre temps. L'inventaire, d'abord, qui recense les applications, les données, les volumes, les dépendances et les utilisateurs concernés. Cette étape prend une à deux journées et détermine tout le reste, y compris le budget et le calendrier réalistes.
La synchronisation préalable, ensuite : les données sont copiées vers le cloud pendant que tout le monde continue de travailler normalement, parfois sur plusieurs semaines. Seule la différence accumulée depuis la dernière copie est transférée au moment de la bascule, ce qui réduit la fenêtre d'indisponibilité de plusieurs jours à quelques heures.
La bascule elle-même se programme un vendredi soir ou un samedi, avec un point de retour arrière défini à l'avance : si un blocage apparaît, on revient à la situation antérieure sans discussion, plutôt que d'improviser sous pression. Enfin, l'accompagnement des premiers jours, avec une présence renforcée du support le lundi et le mardi, absorbe les questions d'usage qui représentent l'essentiel des sollicitations.
Une étape mérite d’être ajoutée entre la synchronisation et la bascule : la répétition. Migrer d’abord un service pilote, avec cinq utilisateurs volontaires, révèle les frictions réelles pour un coût nul. On découvre les raccourcis à refaire, les impressions à reconfigurer, les habitudes à accompagner. Ces détails, corrigés sur cinq personnes, ne se transforment pas en cent tickets le lundi de la bascule générale. La communication compte autant : prévenir dix jours avant, rappeler la veille, indiquer précisément ce qui changera à l’écran et ce qui ne changera pas réduit considérablement l’inquiétude et le volume d’appels.
Les points à traiter avant de signer
Trois sujets méritent d'être réglés en amont plutôt que découverts en cours de route. La localisation des données, d'abord : savoir dans quel pays elles sont hébergées et sous quelle juridiction, ce qui relève désormais autant de la conformité que de la sécurité. La réversibilité, ensuite : comment récupérer l'intégralité de ses données si l'on change de fournisseur, dans quel format et à quel coût. Un contrat qui reste vague sur ce point mérite une question écrite.
La sauvegarde, enfin. Héberger ses données dans le cloud ne les sauvegarde pas : le fournisseur garantit la disponibilité de son infrastructure, pas la récupération d'un fichier supprimé par erreur ou chiffré par un rançongiciel. Une sauvegarde indépendante du fournisseur reste indispensable, et c'est l'oubli le plus fréquent que nous constatons lors de nos audits.
Chez TICLIC, nous conduisons ces migrations pour des structures de cinq à deux cents postes en Île-de-France, avec un engagement simple : la fenêtre d'indisponibilité est annoncée avant le démarrage, et le retour arrière est préparé. Un diagnostic gratuit permet de chiffrer le calendrier et le volume réel à transférer.
Un quatrième sujet mérite d’être traité avant la signature : la maîtrise des coûts dans la durée. Les tarifs affichés couvrent le stockage, rarement les transferts sortants, les restaurations ou les environnements de test. Une facture qui double la deuxième année s’explique presque toujours par ces lignes annexes. Demander une simulation sur trois ans, en intégrant la croissance prévisible du volume, évite la mauvaise surprise. Il est également prudent de vérifier la politique de conservation après résiliation : combien de temps les données restent disponibles, et à quel moment elles sont définitivement supprimées.