Python · Google Drive ↔ OneDrive · Guide d’ingénierie open source

Créer un transfert sécurisé entre Google Drive et OneDrive avec Python

Ce guide transforme une copie entre clouds, plus complexe qu’il n’y paraît, en un pipeline explicite : inventorier, effectuer les contrôles préalables, placer en zone intermédiaire, calculer l’empreinte, téléverser, retélécharger, comparer, créer un point de reprise, puis seulement libérer l’espace disque local.

Mis à jour ; 22 min de lecture.

En bref

Pour une migration gérée, FileArk automatise ce processus sans faire de votre ordinateur le canal de transit des données. FileArk a été testé avec des charges de migration de plusieurs téraoctets et vérifie la réception depuis la source, l’acceptation de l’importation par le fournisseur et l’objet dans la destination avant de signaler la réussite. Si vous devez exploiter vous-même le pipeline, le programme Python sous licence MIT ci-dessous effectue une copie prudente en passant par votre ordinateur et ne supprime jamais les fichiers sources.

Choisir le modèle d’exploitation avant de choisir le code

Un service de migration directe entre clouds constitue le choix le plus pratique lorsque la bibliothèque est volumineuse, que la connexion doit fonctionner sans surveillance ou que les données ne doivent pas transiter par un ordinateur portable. FileArk maintient le transfert en ligne, surveille les réponses des fournisseurs, relance les opérations après les erreurs récupérables et offre une vue unique de la progression. Son processus de validation effectue trois contrôles indépendants avant de considérer un fichier comme terminé.

Un script local est utile lorsque vous avez besoin d’un contrôle total sur les applications OAuth, les disques de stockage intermédiaire, les journaux ou les règles applicables au dossier de destination. En contrepartie, vous assumez la responsabilité opérationnelle : votre machine doit rester en ligne, sa connexion réseau devient le goulot d’étranglement, les identifiants OAuth doivent être protégés et un espace disque temporaire suffisant doit rester disponible pour le lot actif et la copie de vérification.

Le programme publié ici est volontairement prudent. Il copie les données depuis la racine d’un espace de stockage personnel vers un nouveau dossier de destination. Il ne propose aucune méthode de suppression, n’écrase pas les éléments en conflit, enregistre un point de reprise durable après la vérification et s’arrête dès que la capacité locale ou celle de la destination passe sous la réserve configurée.

Le pipeline de transfert et les limites de gestion des défaillances

  1. Inventorier l’arborescence source

    L’adaptateur source parcourt les dossiers de manière récursive, suit la pagination du fournisseur, enregistre les identifiants, chemins, types et tailles déclarées, puis associe les fichiers Google natifs pris en charge à des formats d’exportation portables.

  2. Contrôler au préalable la capacité de la destination et du stockage local

    Le moteur compare le nombre d’octets en attente, augmenté d’une réserve configurable, avec le quota de destination. Il vérifie également le système de fichiers de la zone intermédiaire avant chaque lot et chaque téléchargement individuel.

  3. Placer un lot de taille limitée en zone intermédiaire

    Les fichiers sont traités par lots limités à la fois par leur nombre total d’octets et par leur nombre de fichiers. Seul le lot en cours utilise le disque local : une bibliothèque volumineuse ne nécessite donc pas un disque de capacité équivalente.

  4. Calculer l’empreinte et téléverser

    Après le téléchargement, le script calcule le SHA-256 local, vérifie la taille source si elle est connue, crée les dossiers de destination et téléverse les fichiers par fragments reprenables compatibles avec le fournisseur.

  5. Vérifier et créer un point de reprise

    Le mode par défaut télécharge à nouveau le nouvel objet créé dans la destination et compare les empreintes SHA-256. Seul un fichier correspondant est inscrit dans le point de contrôle JSON, puis supprimé de la zone de transit locale.

Télécharger la version Python complète sous licence MIT

Le téléchargement contient un unique point d’entrée Python lisible. Les SDK des fournisseurs ne sont importés que pour un transfert réel : les commandes de démonstration et d’aide fonctionnent donc avant l’installation des dépendances ou des identifiants. Un fichier de dépendances distinct fixe les versions minimales des packages pris en charge, et la licence est fournie avec le code source.

Lisez le code avant de l’utiliser, effectuez un test avec un petit dossier de destination et conservez la vérification par retéléchargement activée par défaut pour les données importantes. Aucun script générique ne peut reproduire l’intégralité des autorisations de partage, raccourcis, étiquettes de rétention, règles de Drive partagé ou stratégies de locataire.

Télécharger le programme Python de transfert
Implémentation directe avec l’API Google Drive et Microsoft Graph, comprenant le traitement par lots, les points de reprise, les nouvelles tentatives, les réserves de quota et la vérification SHA-256 à destination.
fileark-cloud-transfer.py · Python 3.10+ · Licence MIT

Télécharger les dépendances Python
Liste réduite de dépendances pour Google OAuth et Drive, l’authentification Microsoft, les requêtes Graph et la gestion des nouvelles tentatives.
requirements-fileark-cloud-transfer.txt · dépendances pip · texte brut

Télécharger la licence MIT
Avis d’autorisation couvrant les deux scripts de transfert manuel de FileArk.
LICENSE-fileark-cloud-transfer.txt · MIT · texte brut

Examiner le processus de sécurité avant d’accorder l’accès au cloud

Terminal exécutant le script Python de transfert cloud FileArk en mode démonstration sans réseau
La démonstration intégrée permet de tester le parcours destiné à l’opérateur sans identifiants ni appels réseau. Une exécution réelle affiche les mêmes informations sur la capacité, les lots, la vérification, le point de contrôle et l’état de la suppression à la source.

Exécutez d’abord la démonstration. Elle n’effectue aucun appel réseau et n’écrit aucune donnée dans le cloud. La dernière ligne est volontairement sans ambiguïté : aucun fichier source n’a été supprimé. Le moteur réel produit la même séquence dans des journaux structurés et renvoie un code de sortie différent de zéro dès le premier fichier non vérifié.

Test de bon fonctionnement sans réseau
chmod +x fileark-cloud-transfer.py
python3 fileark-cloud-transfer.py --demo
python3 fileark-cloud-transfer.py --help

Créer des clients OAuth sans intégrer de secrets

Pour Google Drive, créez un client OAuth pour application de bureau dans un projet Google Cloud, activez l’API Drive, configurez l’écran de consentement et téléchargez le fichier JSON du client. Transmettez son chemin avec --google-client-secret ou définissez GOOGLE_OAUTH_CLIENT_SECRET_FILE. Le script demande l’accès à Drive, car il doit répertorier et télécharger les fichiers, créer des dossiers, téléverser les fichiers et les vérifier.

Pour OneDrive, inscrivez une application cliente publique dans Microsoft Entra ID, activez le flux de code d’appareil, ajoutez l’autorisation déléguée Files.ReadWrite et transmettez l’ID client de l’application. Choisissez common pour les comptes personnels et professionnels, organizations pour les comptes professionnels, ou un ID de locataire spécifique lorsque la politique l’exige.

Les jetons sont mis en cache dans des fichiers locaux afin qu’une migration interrompue puisse reprendre sans nouvelle connexion. Traitez le fichier JSON du client et les caches de jetons comme des secrets : excluez-les du contrôle de version, limitez les autorisations du système de fichiers, ne les joignez jamais à des demandes d’assistance et supprimez-les une fois la migration validée.

Installer les dépendances dans un environnement isolé
python3 -m venv .venv
. .venv/bin/activate
python -m pip install --upgrade pip
python -m pip install -r requirements-fileark-cloud-transfer.txt

Effectuer le transfert de Google Drive vers OneDrive, ou dans le sens inverse

Toutes les valeurs propres à l’identité relèvent de l’opérateur. Le programme est fourni sans ID client, secret, locataire, jeton, compte distant ni identifiants de destination. La première commande ouvre la connexion à Google dans un navigateur et à Microsoft à l’aide d’un code d’appareil, puis effectue la copie dans un nouveau dossier OneDrive.

Inversez la source et la destination pour effectuer un transfert de OneDrive vers Google Drive. Utilisez un fichier d’état et une racine de destination distincts pour chaque migration indépendante. Le point de reprise associe le fournisseur source, le fournisseur de destination et la racine, et refuse toute reprise avec une configuration différente.

De Google Drive vers OneDrive par lots de 8 Gio
export MICROSOFT_CLIENT_ID="your-public-client-id"
python fileark-cloud-transfer.py \
  --source google \
  --destination onedrive \
  --google-client-secret ./client_secret.json \
  --microsoft-tenant common \
  --destination-root "FileArk Manual Transfer 2026-07-25" \
  --batch-gib 8 \
  --batch-files 200 \
  --local-reserve-gib 15 \
  --destination-reserve-gib 10 \
  --verification redownload
Sens inverse : de OneDrive vers Google Drive
python fileark-cloud-transfer.py \
  --source onedrive \
  --destination google \
  --microsoft-client-id "$MICROSOFT_CLIENT_ID" \
  --google-client-secret ./client_secret.json \
  --destination-root "OneDrive archive 2026-07-25" \
  --state-file ./onedrive-to-google-state.json \
  --verification redownload

Pourquoi la capacité est-elle vérifiée plusieurs fois ?

Un contrôle préalable unique peut devenir obsolète pendant un transfert de longue durée. Une autre personne peut importer des fichiers dans la destination, un document Google exporté peut être plus volumineux que ne le laissent penser ses métadonnées source, et des applications sans rapport avec le transfert peuvent consommer de l’espace disque local. Le moteur vérifie donc la capacité totale de la destination avant de démarrer, sa capacité à chaque lot, puis de nouveau après chaque téléchargement local, ainsi que l’espace disque local avant chaque copie de transfert ou de vérification.

Les valeurs de réserve constituent une marge de sécurité opérationnelle, et non une estimation du volume à transférer. Prévoyez une marge suffisante pour les mises à jour du système d’exploitation, les délais de comptabilisation du fournisseur et les autres utilisateurs du même quota cloud. Lorsqu’un fournisseur n’indique pas de quota restant fini, le script émet un avertissement et s’en remet aux limites appliquées par le fournisseur. Cette protection est moins fiable qu’un contrôle préalable fondé sur une valeur connue et nécessite une surveillance active.

L’invariant de quota avec échec bloquant
def ensure_destination_capacity(quota, required, reserve):
    if quota.remaining is None:
        LOG.warning("Destination did not report a finite quota")
        return
    needed = required + reserve
    if quota.remaining < needed:
        raise RuntimeError(
            f"Destination is too small: {human_bytes(quota.remaining)} free, "
            f"{human_bytes(needed)} required including reserve."
        )

Limiter l’espace de transit en fonction du volume et du nombre de fichiers

Une limite en octets réduit l’espace disque mobilisé ; une limite du nombre de fichiers réduit la surcharge de l’API et du système de fichiers lorsque la source contient des centaines de milliers de petits objets. Un fichier dépassant la limite de taille d’un lot est autorisé à constituer un lot à lui seul. La réserve doit donc être dimensionnée en fonction du plus grand objet individuel.

La taille de segment par défaut est de 10 MiB. Il s’agit d’un multiple commun de la granularité de 256 KiB des importations avec reprise de Google Drive et de l’exigence de Microsoft Graph concernant des fragments séquentiels de 320 KiB. Le validateur en ligne de commande rejette les tailles de segment incompatibles avant l’authentification.

Planificateur de lots à double limite
def batches(files, max_bytes, max_files):
    batch, batch_size = [], 0
    for item in files:
        planned_size = max(item.size, 1)
        if batch and (
            len(batch) >= max_files
            or batch_size + planned_size > max_bytes
        ):
            yield batch
            batch, batch_size = [], 0
        batch.append(item)
        batch_size += planned_size
    if batch:
        yield batch

Traiter les documents natifs Google comme des conversions

Les documents Google Docs, Sheets, Slides et Drawings ainsi que les projets Apps Script ne sont pas des flux d’octets ordinaires pouvant être téléchargés. L’adaptateur Google les exporte respectivement aux formats DOCX, XLSX, PPTX, PNG et JSON, en ajoutant une extension de fichier portable. Les dossiers sont parcourus, mais ne sont pas téléversés comme objets vides s’ils ne contiennent aucun fichier.

La conversion peut modifier les polices, les formules, les commentaires, les objets incorporés, la mise en page et l’historique collaboratif. Les points de terminaison d’exportation de Google imposent également des contraintes de format et de taille. Le script ignore les types natifs non pris en charge en affichant un avertissement, plutôt que d’inventer une représentation. Examinez manuellement un échantillon représentatif de fichiers convertis.

Les raccourcis, les Drives partagés, les fichiers partagés avec vous mais absents de Mon Drive, les packages OneNote, les métadonnées de rétention de l’organisation, l’historique des versions et les listes de contrôle d’accès (ACL) de partage ne sont pas pris en charge dans cette version. En raison de ces limites, une copie de fichiers ne doit pas être présentée comme une migration complète de locataire.

Utiliser la vérification complète par retéléchargement depuis la destination pour contrôler chaque octet

La réussite de l’importation chez le fournisseur est nécessaire, mais pas suffisante. Après l’importation, le script compare d’abord la taille indiquée dans les métadonnées de la destination à celle du fichier placé dans la zone de transit. Dans le mode de retéléchargement par défaut, il télécharge ensuite l’objet de destination dans un fichier temporaire situé au même niveau, calcule son empreinte SHA-256 et la compare à celle de la source placée dans la zone de transit.

Seule la correspondance de la taille et de l’empreinte entraîne l’ajout d’une entrée au point de reprise. Celui-ci enregistre l’identifiant source, la taille déclarée par la source, l’identifiant de destination, le chemin de destination, le nombre réel d’octets, les deux empreintes et l’heure d’achèvement en UTC. Si un chemin source déjà enregistré dans le point de reprise renvoie ensuite vers un identifiant ou une taille différents, le script s’arrête au lieu d’ignorer silencieusement les données modifiées.

Le retéléchargement double le trafic de lecture côté destination et nécessite temporairement de l’espace pour le fichier intermédiaire et la copie de vérification. Ne sélectionnez le mode métadonnées que si vous comprenez ce coût et disposez d’un processus indépendant de vérification du contenu.

Vérification des octets à la destination
destination.redownload(uploaded, verification_copy)
verification_hash = sha256_file(verification_copy)
if verification_hash != local_hash:
    raise RuntimeError(
        f"SHA-256 mismatch after destination re-download: {relative!r}."
    )

state["completed"][relative] = {
    "source_id": item.id,
    "destination_id": uploaded.id,
    "bytes": actual_size,
    "sha256": local_hash,
    "destination_sha256": verification_hash,
}

Reprendre sans considérer l’incertitude comme une réussite

Le programme écrit l’état de manière atomique au moyen d’un fichier temporaire, puis le renomme. Un élément vérifié n’est supprimé de la zone de stockage intermédiaire locale qu’après cette écriture durable. La réexécution de la même commande ignore les éléments enregistrés dans le point de reprise et continue avec les chemins en attente.

Un plantage peut survenir après l’acceptation d’une importation par le fournisseur, mais avant l’écriture du point de contrôle. Comme le comportement en cas de conflit est défini sur « fail », l’exécution suivante s’arrête lorsqu’elle rencontre ce chemin existant dans la destination, au lieu d’écraser l’objet ou d’annoncer à tort une réussite. Examinez l’objet, comparez-le, puis ajoutez avec précaution une entrée de récupération vérifiée ou recommencez dans une nouvelle racine de destination.

Les opérations sont relancées dans des limites définies en cas d’expiration d’OAuth, de limitation du débit, d’erreurs serveur temporaires ou d’interruption de segments. Les échecs d’authentification ou les erreurs d’autorisation persistantes arrêtent le programme. Conservez les journaux, le point de contrôle et le contenu de la zone de transit jusqu’à ce que vous ayez compris la cause de l’échec.

Effectuer un véritable test de validation

  • Commencez par un petit dossier contenant des fichiers vides, des fichiers volumineux, des arborescences profondes, des noms Unicode et des documents natifs Google.
  • Exécutez d’abord --dry-run et comparez le nombre total d’octets de l’inventaire avec celui indiqué dans l’interface du fournisseur.
  • Surveillez séparément l’espace local disponible et le quota de destination pendant le premier lot en production.
  • Laissez la vérification par retéléchargement activée et archivez le point de contrôle avec les données de suivi de votre migration.
  • Ouvrez dans la destination un échantillon représentatif de PDF, de fichiers Office, d’images, de vidéos, d’archives et de documents natifs convertis.
  • Comparez le nombre attendu de dossiers et de fichiers, examinez chaque élément ignoré ou en échec et testez l’accès depuis le compte d’un deuxième utilisateur.
  • Conservez la source inchangée pendant une période de chevauchement définie. Ce script ne la supprime jamais.

Questions fréquentes

Le script Python supprime-t-il parfois des fichiers sources ?

Non. La suppression à la source n’est pas implémentée. Le moteur télécharge les fichiers depuis la source et les écrit dans une racine de destination distincte. Une vérification réussie supprime uniquement la copie temporaire de la zone de transit locale.

Peut-il effectuer le transfert dans les deux sens ?

Oui. Définissez Google Drive ou OneDrive comme source et l’autre fournisseur comme destination. Utilisez un point de reprise et une racine de destination uniques pour chaque migration.

Conserve-t-il les autorisations de partage et l’historique des fichiers ?

Non. Cette version copie le contenu actuel des fichiers et les chemins des dossiers. Les listes de contrôle d’accès (ACL) de partage, les liens publics, les versions, les commentaires, les étiquettes, les stratégies de rétention et les métadonnées propres à l’organisation nécessitent une migration et une validation distinctes.

Pourquoi retélécharger des fichiers qui viennent d’être téléversés ?

L’acceptation du téléversement et la taille indiquée dans les métadonnées ne prouvent pas que les octets exacts peuvent être relus depuis la destination. Le mode de retéléchargement calcule le SHA-256 du contenu de destination et ne crée un point de reprise qu’en cas de correspondance exacte.

S’agit-il d’un outil officiel de Google ou de Microsoft ?

Non. Il s’agit d’une implémentation de référence FileArk indépendante, publiée sous licence MIT. Examinez-la, testez-la avec des données non critiques et respectez les règles de votre fournisseur et de votre organisation.

Ressources officielles utilisées pour ce guide

Lire le guide