Migration cloud : guide stratégique de transfert de fichiers

Une stratégie de transfert de fichiers pour la migration cloud repose sur trois décisions : le chemin de transport (internet public, Direct Connect, ou appliance physique), le modèle de bascule (big-bang, par phases, ou exécution parallèle), et les vérifications d'intégrité auxquelles vous ferez confiance. Pour un parc de 50 To sur une liaison à 1 Gbps, attendez environ 5 jours de temps de transfert pur à la vitesse maximale — moins si vous compressez, plus si la ligne est partagée. Planifiez la séquence avant de planifier les outils, et budgétez 20 % de marge pour les reprises et la réconciliation.

Dimensionner le jeu de données avant de toucher au câble

Avant de choisir AWS DataSync, Azure AzCopy, ou Google Storage Transfer Service, inventoriez ce que vous avez réellement. Lancez du -sh sur les partages de fichiers, interrogez les catalogues de bases de données pour les comptes de lignes, et exportez les manifestes de stockage objet. Une entreprise de taille intermédiaire que j'ai auditée pensait avoir 8 To sur son NAS ; le nombre réel était 34 To une fois que vous comptiez les snapshots et les fichiers verrous Office ~$ cachés.

Classifiez l'inventaire selon trois axes : taille, taux de modification, et poids réglementaire. Les fichiers de moins de 1 Mo se déplacent lentement en octets en raison de la surcharge par objet — un bucket avec 200 millions de petits fichiers peut prendre plus longtemps qu'un avec 10 To de vidéo. Rangez les données chaudes (qui changent quotidiennement) séparément des données froides (archives PDF, factures de 2017). Les données froides peuvent être envoyées des semaines à l'avance ; les données chaudes nécessitent une logique de synchronisation-jusqu'à-bascule.

Choisir un transport adapté à votre calendrier

Pour moins de 10 To avec une bonne connexion fibre, le transfert en ligne via TLS 1.3 gagne généralement. Entre 10 To et 500 To, réservez de la bande passante ou provisionnez AWS Direct Connect / Azure ExpressRoute pour éviter de saturer le WAN d'entreprise. Au-delà de 500 To, l'ensemencement physique bat l'internet : AWS Snowball Edge contient 80 To, Snowmobile déplace des exaoctets dans un conteneur de transport, et Azure Data Box Heavy stocke 1 Po.

Faites le calcul honnêtement. À 1 Gbps (125 Mo/s soutenu, réalistement 80 Mo/s après la surcharge), 100 To prend environ 14 jours de débit ininterrompu. Si votre fenêtre d'opérations est de 48 heures, le câble n'est pas viable — expédiez des disques. Incluez l'egress : déplacer 100 To hors d'un ancien fournisseur à 0,09 $/Go coûte 9 000 $ avant même de toucher la destination.

Intégrité : faites confiance mais vérifiez les checksums

Toute migration nécessite une vérification d'intégrité de bout en bout, pas seulement TLS au niveau transport. Générez des hashes SHA-256 ou xxHash64 à la source, transmettez-les avec le payload, et ré-hachez à la destination. AWS DataSync le fait par défaut ; rsync avec --checksum le force ; rclone supporte --check-first et les backends crypt.

Pour les charges de travail de conformité, conservez le manifeste — un CSV de chemin, nombre d'octets, et hash — pendant toute la durée de rétention. Les entités couvertes par HIPAA doivent journaliser chaque objet sous les contrôles d'intégrité 45 CFR 164.312(c)(1), et l'article 5(1)(f) du RGPD vous exige de démontrer que les fichiers n'ont pas été altérés en transit. Un seul octet mal aligné dans une étude DICOM peut faire refuser l'ouverture à la visionneuse d'un radiologue.

Minimiser les interruptions avec la synchronisation delta

Les bascules big-bang sont l'ennemi du sommeil. À la place, faites une copie en masse initiale des semaines à l'avance, puis exécutez des deltas incrémentiels nocturnement jusqu'à la fenêtre de bascule. Des outils comme Rclone (--update --use-server-modtime), AzCopy (--overwrite=ifSourceNewer), et gsutil rsync -d de Google détectent les fichiers modifiés par mtime ou hash et ne déplacent que le delta.

Les bases de données ont besoin de leur propre plan. Pour une instance PostgreSQL de 2 To, utilisez pg_basebackup plus le transport WAL ; pour MySQL, mettez en place un réplica sur la destination et promouvez-le lors de la bascule. Les deltas de système de fichiers via rsync peuvent réduire la synchronisation finale de heures à minutes, ce qui rentre généralement dans une fenêtre de maintenance du samedi soir.

Mise en forme de bande passante et transferts nocturnes

Les migrations qui consomment chaque bit du WAN se terminent mal — les tickets au service d'assistance s'accumulent avant le petit déjeuner. Limitez agressivement. AzCopy accepte --cap-mbps, rclone supporte --bwlimit 50M:100M pour les taux jour/nuit, et DataSync planifie des tâches avec des plafonds de bande passante par heure. Une politique sensée : 30 % de la liaison pendant les heures de bureau, 90 % la nuit, 100 % le week-end.

Segmentez également le trafic au pare-feu. Étiquetez les flux de migration avec une valeur DSCP afin que les politiques QoS ne privent pas les appels Zoom. Si vous utilisez MPLS vers des succursales, envisagez un breakout SD-WAN pour que le trafic de migration sorte localement plutôt que de transiter par le siège.

Gérer les données sensibles en transit

Toute migration incluant des DCP, des PSI ou des données de titulaires de cartes nécessite un chiffrement conforme à la norme applicable. TLS 1.3 est le minimum ; pour les fichiers au repos pendant la mise en scène, enveloppez avec AES-256-GCM avant l'envoi. La règle PCI DSS 4.0 4.2.1 impose une cryptographie robuste pour les données de titulaires de cartes sur les réseaux publics, et la norme de chiffrement adressable HIPAA l'exige effectivement pour les PSI électroniques.

Le RGPD impose également des mesures de sécurité appropriées pour tout transfert de données personnelles — documentez votre base légale de transfert et les mesures techniques dans votre AIPD. Pour les transferts ponctuels de petits lots pendant une migration (par exemple un consultant exportant une table Salesforce ou un administrateur de base de données déplaçant un coffre-fort de credentials), les outils de chiffrement de bout en bout gardent les clés hors de portée du fournisseur de transport. HexaTransfer gère cela proprement pour les fichiers ponctuels pendant une migration — le chiffrement se produit dans le navigateur avant que quoi que ce soit ne touche un serveur.

Tester la bascule avant la bascule

Faites une répétition générale de la migration sur un sous-ensemble. Choisissez un département — disons 300 Go du disque partagé du Marketing — et exécutez le pipeline complet : inventaire source, transfert, vérification de checksum, mappage des permissions, et basculement de l'application. Chronométrez chaque étape et documentez ce qui a échoué.

Surprises courantes : les ACL NTFS qui ne se mappent pas proprement aux politiques de bucket S3, les liens symboliques que rclone traite comme des fichiers, les chemins de partage SMB intégrés dans les configs d'application, et les différences de sensibilité à la casse entre les destinations Windows et Linux. Réglez ces problèmes en mise en scène, pas à 2h du matin la nuit du lancement. Une répétition qui prend une semaine économise un retour arrière qui en prend un mois.

Réconciliation post-migration

Déclarez le succès uniquement après la réconciliation. Comparez les comptes d'objets source et destination, les octets totaux, et un échantillon de hash aléatoire à 1 %. Interrogez les métriques de l'application — si un système de gestion documentaire signalait 4,2 millions de fichiers et la destination en affiche 4,19 millions, trouvez les 10 000 manquants avant d'éteindre la source.

Gardez la source en lecture seule pendant au moins 30 jours après la bascule. Les utilisateurs finiront inévitablement par avoir besoin d'un fichier qui n'a pas migré parce qu'il était dans ~/Bureau/vieux_trucs/ plutôt que dans le partage inventorié. Prévoyez-le, ne soyez pas surpris, et rédigez le runbook de retour arrière avant d'en avoir besoin.

Essayez-le sur https://hexatransfer.com — gratuit, sans compte, 10 Go maximum.