Les 8 pièges de la migration cloud que tout le monde découvre trop tard
Il existe un moment précis dans toute migration cloud où vous réalisez que quelque chose a mal tourné. En général, c’est trois jours après la migration, quand un collègue 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 piège listé ici a été découvert par quelqu’un qui pensait avoir tout prévu. La documentation de Rclone sur les limitations est un bon point de départ pour comprendre ce qui peut mal tourner techniquement.
La plupart de ces pièges ne sont pas des bugs. Ce sont des conséquences logiques de différences d’architecture entre clouds que personne ne prend le temps d’étudier avant de migrer. Voici les huit plus fréquents, par ordre de fréquence d’apparition dans la vraie vie.
Piège 1 à 8 : le catalogue des mauvaises surprises
Piège 1 : les fichiers Google Docs natifs qui deviennent des DOCX cassés. C’est LE piège numéro 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. À l’export, Google les convertit en DOCX/XLSX/PPTX, et la conversion perd des éléments : mises en page complexes, macros, commentaires référençant des utilisateurs, suggestions de modification. Si vous avez 500 Google Docs, vérifiez les 20 plus critiques manuellement après la migration.
Piège 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 à un autre (les modèles de permissions sont incompatibles). Si vous ne faites pas l’inventaire des partages AVANT de migrer, vous passez des heures à les reconfigurer APRÈS, sans être sûr de n’avoir rien oublié.
Piège 3 : les noms de fichiers avec caractères spéciaux. Un fichier nommé Bilan Q3/2025 (final).xlsx est parfaitement légal sur Google Drive. Le slash dans le nom ? Google gère. Mais sur un système de fichiers Windows, le slash est un séparateur de chemin : le fichier devient introuvable ou provoque une erreur. Les caractères problématiques : /, \, :, *, ?, ", <, >, |, les emojis dans les noms de fichiers (oui, ça existe), et les espaces en fin de nom.
Piège 4 : les liens publics qui meurent sans prévenir. 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 partagé des liens dans des emails, des wikis internes, des documents clients, ils sont tous morts. Pas de redirection, pas de notification.
Piège 5 : les chemins trop longs. Windows a historiquement une limite de 260 caractères 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 dépasse les 260 caractères. La synchronisation du nouveau cloud vers un PC Windows échouera silencieusement.
Piège 6 : les métadonnées perdues. Les dates de création et de modification des fichiers ne survivent pas toujours à la migration. Selon l’outil utilisé, la date de création sur le nouveau cloud sera la date de migration, pas la date originale. Pour des fichiers où la chronologie compte (documents légaux, archives), c’est un vrai problème. Rclone a un flag --metadata qui préserve les dates quand le cloud de destination le supporte.
Piège 7 : les fichiers vides ou de zéro octet. Certains outils de migration créent des fichiers placeholder quand le transfert échoue 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 vérification d’intégrité post-migration qui compare les tailles fichier par fichier.
Piège 8 : le double fonctionnement mal géré. Pendant la migration, les gens continuent de travailler. Si quelqu’un modifie un fichier sur l’ancien cloud après que vous l’avez migré vers le nouveau, vous avez une divergence. La solution est de définir un « jour J » où tout le monde bascule, avec une période de gel (pas de modification sur l’ancien cloud) de 24 à 48 heures. En pratique, il y a toujours quelqu’un qui n’a pas lu le mémo.
Les pièges spécifiques par source
Chaque source a ses pièges spécifiques en plus des pièges génériques. La migration depuis Google Drive cumule les pièges 1, 2 et 4 de manière particulièrement aigüe. Dropbox a moins de pièges mais le piège 6 (perte des dates) est fréquent. OneDrive Entreprise ajoute des pièges liés à SharePoint (métadonnées de colonnes, workflows). iCloud a le piège de l’optimisation du stockage (fichiers en local qui ne sont que des miniatures).
Combien de temps prévoir pour éviter ces pièges
La réponse réaliste est dans le guide sur la durée d’une migration cloud. Le transfert de fichiers brut, c’est 20% du temps total. La vérification, la correction des problèmes et la reconfiguration des partages, c’est les 80% restants. Prévoyez le double du temps que vous pensez nécessaire. Si ça va plus vite, vous serez agréablement surpris. Si ça prend le temps prévu, vous ne serez pas en retard.
Le meilleur antidote à tous ces pièges : faites un test avec un échantillon représentatif de 50-100 fichiers avant de lancer la migration complète. Incluez dans l’échantillon au moins un fichier natif Google, un fichier avec des caractères spéciaux dans le nom, un fichier partagé, et un fichier avec un chemin long. Si l’échantillon passe, le reste suivra.