Récupérer 1,2 To depuis Google Photos : REX d'une vraie migration

Le contexte : pourquoi ce REX

Dans le premier article de cette série, nous décrivions les pièges théoriques de la sortie de Google Photos : fragmentation des archives, doublons, et surtout métadonnées EXIF externalisées dans des fichiers JSON. Beaucoup de lecteurs ont demandé : « concrètement, sur une vraie photothèque, ça se passe comment ? »

Voici la réponse, sans embellissement : la migration d'une photothèque Google Photos accumulée pendant plus de vingt-cinq ans (1998 → 2026), soit 1,2 To et plusieurs centaines de milliers de photos et vidéos. Les chiffres, les outils, les temps réels — et les pièges qu'on ne soupçonne pas en lisant la doc Google.

Phase 1 — Le téléchargement : une journée entière

Première décision : où poser les fichiers ? Avec 1,2 To en sortie, l'ordinateur portable (SSD 512 Go) est immédiatement disqualifié. Direction le NAS à la maison — monté dans le réseau, suffisamment de place, et accessible depuis n'importe quelle machine de la maison.

Le piège : Takeout veut tout vous envoyer d'un coup

Quand on demande à Google Takeout d'exporter 1,2 To de photos, l'outil découpe en archives de 50 Go (la taille maximale) et propose les liens un par un. Sur le papier, on télécharge tout depuis le navigateur. Dans la vraie vie :

• Les liens expirent après quelques jours — il faut maintenir le rythme.
• Lancer tous les téléchargements en parallèle fait planter le navigateur, sature la connexion, et provoque des fichiers tronqués impossibles à détecter avant décompression.
• Les téléchargements interrompus repartent rarement de là où ils s'étaient arrêtés — il faut souvent recommencer le fichier entier.

Bilan de la phase 1 : une journée entière de téléchargement (par paquets de 3, en surveillant régulièrement). Connexion fibre 1 Gbit/s, NAS branché en filaire, navigateur dédié laissé ouvert. Pas un travail compliqué, mais une journée pendant laquelle on ne fait pas autre chose de gourmand sur le réseau.

Phase 2 — La décompression : 7 h 23 minutes

Une fois les 24 fichiers ZIP en sécurité sur le NAS, place à la décompression. Là encore, on apprend vite que la parallélisation est l'ennemie : lancer plusieurs unzip en même temps sur un même NAS fait s'effondrer le débit (tous les processus se battent pour les mêmes têtes de lecture / cache), et le total est plus long qu'en séquentiel.

Méthode retenue : un script qui décompresse une archive après l'autre, dans un seul dossier de destination (les ZIP Google Takeout partagent la même racine Takeout/Google Photos/), avec écrasement silencieux en cas de doublon — les photos d'albums sont effectivement dupliquées entre archives, et la déduplication par nom de fichier est ici sans risque.

Les fichiers ZIP d'origine sont conservés en filet de sécurité : si quelque chose se passe mal en aval (réinjection des EXIF par exemple), on peut tout ré-extraire en 7 h sans relancer la phase 1. Ça consomme 1,2 To de plus sur le NAS pendant tout le reste du projet — un investissement raisonnable au regard du risque.

Phase 3 — La réinjection des métadonnées EXIF

C'est l'étape la plus pernicieuse. Comme expliqué dans l'article précédent, Google Takeout sort les métadonnées (date de prise de vue, GPS, description) des photos et les place dans un fichier JSON séparé pour chaque image :

La solution : utiliser le fork actif (gpth-neo)

Il existe un fork actif maintenu par la communauté : Xentraxx/GooglePhotosTakeoutHelper (alias gpth-neo). Version 6.1.5 publiée en mai 2026, il reconnaît à la fois l'ancien et le nouveau format de sidecar, gère la troncature de noms, traite correctement les photos Pixel (formats .MP/.MV), reconstitue les albums via des symlinks (sans dupliquer les fichiers) et réorganise tout par année/mois selon la vraie date.

Installation : deux outils, zéro sudo

Sur la machine de travail (Ubuntu 24.04, sans accès root), tout s'installe dans ~/.local/. Pas besoin d'apt, donc pas besoin du mot de passe administrateur. Deux outils suffisent :

1. gpth-neo v6.1.5 — un seul binaire Dart natif Linux x64 (11 Mo) téléchargé depuis les releases GitHub, posé dans ~/.local/bin/gpth avec un chmod +x. Pas d'environnement Dart à installer.
2. exiftool 13.58 — c'est en réalité un script Perl autoportant : on télécharge le tarball depuis exiftool.org, on l'extrait dans ~/.local/exiftool-dist/, et on fait un symlink vers ~/.local/bin/exiftool. Perl est déjà sur la machine (Ubuntu en a une par défaut), donc rien à compiler.

Avec ~/.local/bin dans le PATH, les deux commandes sont accessibles. Total : moins de 5 minutes d'installation pour 12 h de traitement à venir.

La commande exacte du run complet

Une fois les outils en place, tout le traitement tient en une seule invocation gpth. Voici la commande utilisée, lancée en arrière-plan avec nohup et journalisée dans un fichier dédié :

Le pipeline en 8 étapes : combien chaque étape coûte vraiment

gpth-neo découpe le travail en huit étapes successives. Chacune écrit dans un fichier progress.json (450 Mo à la fin) qui sert de point de reprise en cas d'interruption — point essentiel sur lequel on revient plus bas. Voici la durée mesurée de chaque étape sur 283 050 médias :

L'étape qui domine, de très loin, c'est Write EXIF Data (11 h sur 16). C'est elle qui appelle exiftool pour chaque fichier non-JPEG et chaque fichier dont la date EXIF était absente ou fausse. Les photos qui avaient déjà une bonne date sont identifiées avec le message « existing EXIF date found, skipping JSON-derived date write » et ne consomment quasiment rien — heureusement, parce que ça représente la majorité des Pixel récents.

L'interruption et la reprise : ce que gpth sait (et ne sait pas) reprendre

À 53 % de l'étape 7, on a dû interrompre le run pour récupérer le NAS. Bonne nouvelle : gpth écrit son progress.json au fil du temps. Mauvaise nouvelle : le checkpointing fonctionne aux frontières des étapes, pas à l'intérieur. Concrètement :

• ✅ Étapes 1 à 6 (terminées) : rechargées instantanément depuis progress.json avec le message « Auto-Resume enabled: step already completed previously ».
• ❌ Étape 7 (en cours au moment du Ctrl+C) : repart de zéro. Les 53 % déjà traités lors du premier passage ne sont pas perdus dans le résultat (l'EXIF a bien été écrit), mais gpth doit ré-examiner chaque fichier pour le confirmer.

Conséquence : sur le second run, l'étape 7 a tout de même mis 11 h 07 (légèrement plus rapide que le premier passage parce que la majorité des fichiers se font sauter avec « existing EXIF date found »). Pour planifier la reprise sans rester devant l'écran, on a programmé l'exécution via un timer systemd utilisateur :

Le résultat final en chiffres

Une fois le run terminé, gpth affiche un récap brut. Voici le bilan honnête de la restauration EXIF sur cette photothèque :

Les 4,2 % sans date sont essentiellement des screenshots et des fichiers générés (images sans EXIF d'origine et sans JSON exploitable). Sur ceux-là, l'outil n'a rien à offrir : il garde la date filesystem comme fallback, qui correspond à la date d'export Takeout. Pour la quasi-totalité des photos prises avec un téléphone ou un appareil, en revanche, la restauration est parfaite — spot-checks faits sur photos Pixel 2024 (date + GPS), Panasonic Lumix 2010 (date) et vidéos MP4 : tout est en place.

Chronologie totale et coût réel

L'espace disque, le sujet caché

À aucun moment on ne travaille sur 1,2 To. À l'instant le plus chargé, l'occupation disque ressemble à ceci :

• 1,2 To de ZIP d'origine (gardés en filet de sécurité)
• 1,24 To du dossier décompressé brut
• 1,24 To du dossier de sortie réorganisé par gpth (mode rapide, sans copie temporaire)

Soit ≈ 3,7 To d'espace disque utilisé au pic, pour une photothèque qui en pesait 1,2 To. C'est mathématique : il faut prévoir au minimum trois fois le volume à migrer, sans quoi on se retrouve coincé en cours de route — et impossible de revenir en arrière si on a déjà supprimé les ZIP d'origine.

Prérequis et niveau technique réel

Ne nous mentons pas : cette migration n'est pas accessible à un utilisateur grand public. Voici la liste honnête de ce qu'il faut savoir faire ou avoir, à minima, pour mener l'opération à bien.

Ce qu'on aurait fait différemment

• Vérifier d'abord la disponibilité de gpth-neo avant de télécharger : si le fork avait été cassé lui aussi, il aurait fallu basculer sur exiftool scripté à la main — un travail beaucoup plus long.
• Lancer la décompression et le run gpth en arrière-plan dès le départ, avec journalisation : sur des opérations de plusieurs heures, ne jamais bloquer un terminal interactif.
• Anticiper : commencer ce travail un soir de week-end. Le mardi à 10 h, ça gêne tout le reste.

Conclusion : ce qu'on retient vraiment

Sortir de Google Photos sur 1,2 To, c'est techniquement faisable, humainement coûteux. Trois à quatre jours pour quelqu'un qui sait ce qu'il fait — probablement deux semaines pour quelqu'un qui découvre les outils en route, voire un échec silencieux pour qui ignore l'histoire des sidecars JSON.

Au-delà du temps brut, c'est surtout une preuve par l'absurde de ce que cache la commodité de Google Photos : la facilité d'usage en entrée s'accompagne d'une dette technique massive en sortie. Plus vous laissez la photothèque grossir, plus la sortie devient coûteuse — et plus le risque de renoncer est élevé. C'est précisément le lock-in évoqué dans notre article sur le vrai coût de Google Photos : pas une clause contractuelle, mais une friction technique qui pousse à rester.

Le bon moment pour partir, c'est maintenant — quand la photothèque est encore manipulable. Et le bon réflexe, c'est de choisir un service qui respecte le standard EXIF dès le départ et qui n'externalise pas vos métadonnées dans des sidecars propriétaires.