Les 8 pieges de la migration cloud que tout le monde decouvre trop tard
Il existe un moment precis dans toute migration cloud ou vous realisez que quelque chose a mal tourne. En general, c’est trois jours apres la migration, quand un collegue vous dit « je ne retrouve plus mon fichier » ou « le lien de partage ne marche plus ». Si vous suivez le guide de migration cloud, cette page est votre assurance-vie. Chaque piege liste ici a ete decouvert par quelqu’un qui pensait avoir tout prevu. La documentation de Rclone sur les limitations est un bon point de depart pour comprendre ce qui peut mal tourner techniquement.
La plupart de ces pieges ne sont pas des bugs. Ce sont des consequences logiques de differences d’architecture entre clouds que personne ne prend le temps d’etudier avant de migrer. Voici les huit plus frequents, par ordre de frequence d’apparition dans la vraie vie.
Piege 1 a 8 : le catalogue des mauvaises surprises
Piege 1 : les fichiers Google Docs natifs qui deviennent des DOCX casses. C’est LE piege numero un des migrations depuis Google Drive. Les fichiers Google Docs, Sheets et Slides ne sont pas des fichiers – ce sont des pointeurs vers une application web. A l’export, Google les convertit en DOCX/XLSX/PPTX, et la conversion perd des elements : mises en page complexes, macros, commentaires referencant des utilisateurs, suggestions de modification. Si vous avez 500 Google Docs, verifiez les 20 plus critiques manuellement apres la migration.
Piege 2 : les permissions de partage qui disparaissent en silence. Vous partagez un dossier avec huit personnes sur Google Drive. Vous migrez le dossier vers le nouveau cloud. Les fichiers arrivent, mais les permissions ? Parties. Aucun outil de migration ne transpose automatiquement les permissions d’un cloud a un autre (les modeles de permissions sont incompatibles). Si vous ne faites pas l’inventaire des partages AVANT de migrer, vous passez des heures a les reconfigurer APRES – sans etre sur de n’avoir rien oublie.
Piege 3 : les noms de fichiers avec caracteres speciaux. Un fichier nomme Bilan Q3/2025 (final).xlsx est parfaitement legal sur Google Drive. Le slash dans le nom ? Google gere. Mais sur un systeme de fichiers Windows, le slash est un separateur de chemin – le fichier devient introuvable ou provoque une erreur. Les caracteres problematiques : /, \, :, *, ?, ", <, >, |, les emojis dans les noms de fichiers (oui, ca existe), et les espaces en fin de nom.
Piege 4 : les liens publics qui meurent sans prevenir. Chaque lien de partage (les drive.google.com/file/d/..., les dropbox.com/s/...) pointe vers l’ancien cloud. Quand l’ancien cloud ferme ou que votre abonnement expire, ces liens deviennent des 404. Si vous avez partage des liens dans des emails, des wikis internes, des documents clients – ils sont tous morts. Pas de redirection, pas de notification.
Piege 5 : les chemins trop longs. Windows a historiquement une limite de 260 caracteres pour le chemin complet d’un fichier (disque + dossiers + nom). Les clouds n’ont pas cette limite. Un fichier parfaitement accessible sur Google Drive dans Mon Drive/Projets/2024/Client ABC/Phase 3/Livrables finaux/Documentation technique/Annexes/Annexe 12 - Specifications fonctionnelles detaillees v3.docx depasse les 260 caracteres. La synchronisation du nouveau cloud vers un PC Windows echouera silencieusement.
Piege 6 : les metadonnees perdues. Les dates de creation et de modification des fichiers ne survivent pas toujours a la migration. Selon l’outil utilise, la date de creation sur le nouveau cloud sera la date de migration, pas la date originale. Pour des fichiers ou la chronologie compte (documents legaux, archives), c’est un vrai probleme. Rclone a un flag --metadata qui preserve les dates quand le cloud de destination le supporte.
Piege 7 : les fichiers vides ou de zero octet. Certains outils de migration creent des fichiers placeholder quand le transfert echoue pour un fichier individuel, au lieu de signaler l’erreur. Vous vous retrouvez avec le bon nombre de fichiers (tout semble OK) mais certains font 0 octets. La seule parade est une verification d’integrite post-migration qui compare les tailles fichier par fichier.
Piege 8 : le double fonctionnement mal gere. Pendant la migration, les gens continuent de travailler. Si quelqu’un modifie un fichier sur l’ancien cloud apres que vous l’avez migre vers le nouveau, vous avez une divergence. La solution est de definir un « jour J » ou tout le monde bascule, avec une periode de gel (pas de modification sur l’ancien cloud) de 24 a 48 heures. En pratique, il y a toujours quelqu’un qui n’a pas lu le memo.
Les pieges specifiques par source
Chaque source a ses pieges specifiques en plus des pieges generiques. La migration depuis Google Drive cumule les pieges 1, 2 et 4 de maniere particulierement aigüe. Dropbox a moins de pieges mais le piege 6 (perte des dates) est frequent. OneDrive Entreprise ajoute des pieges lies a SharePoint (metadonnees de colonnes, workflows). iCloud a le piege de l’optimisation du stockage (fichiers en local qui ne sont que des miniatures).
Combien de temps prevoir pour eviter ces pieges
La reponse realiste est dans le guide sur la duree d’une migration cloud. Le transfert de fichiers brut, c’est 20% du temps total. La verification, la correction des problemes et la reconfiguration des partages, c’est les 80% restants. Prevoyez le double du temps que vous pensez necessaire. Si ca va plus vite, vous serez agreablement surpris. Si ca prend le temps prevu, vous ne serez pas en retard.
Le meilleur antidote a tous ces pieges : faites un test avec un echantillon representatif de 50-100 fichiers avant de lancer la migration complete. Incluez dans l’echantillon au moins un fichier natif Google, un fichier avec des caracteres speciaux dans le nom, un fichier partage, et un fichier avec un chemin long. Si l’echantillon passe, le reste suivra.