Google Docs : voir un fichier ne veut pas dire l’avoir sauvegardé

Un document apparaît dans un dossier, avec un nom et une petite icône. Tout est à sa place. J’aurais assez naturellement tendance à croire qu’en copiant ce dossier sur un autre disque, je mets aussi le document à l’abri. C’est précisément ce que l’histoire des raccourcis Google Docs oblige à vérifier.

Le détail m’intéresse parce qu’il déplace la question. Avant même de choisir un cloud français, un disque chez soi ou un autre service, encore faut-il savoir ce qu’on emporte. Une adresse bien rangée n’est pas le contenu auquel elle conduit. Photocopier la couverture du livre ne donne pas beaucoup de lecture pour le week-end.

Un nom de fichier peut cacher une adresse

Dans son billet du 4 février 2026, Jay décrit le piège des fichiers .gdoc, .gsheet et .gslides visibles avec Google Drive pour ordinateur. Ces éléments servent à retrouver des documents Google en ligne ; copier leur petit contenu de raccourci ne revient pas à exporter le texte, le tableur ou la présentation.

La nuance compte : le document existe bel et bien, mais pas sous la forme autonome que suggère son apparition dans l’explorateur. Dire que tous les fichiers de Drive seraient vides serait faux. Un PDF ou un document Word déposé dans le service n’est pas le même cas qu’un document créé dans Google Docs.

Ce n’est donc pas seulement une affaire d’extension mystérieuse. L’interface rassemble des objets qui se ressemblent pour nous simplifier la vie, alors que leur fonctionnement diffère. Le problème arrive quand on attribue à cette ressemblance une garantie qu’elle ne donne pas.

Je retiens un premier réflexe de raisonnement : voir un nom dans un dossier prouve qu’un accès est présenté, pas qu’une copie indépendante du contenu a été produite. La sauvegarde commence par cette distinction assez peu spectaculaire.

Hors connexion, export et sauvegarde : trois besoins

Google prévoit bien un accès hors connexion pour Docs, Sheets et Slides, à préparer dans un navigateur compatible. On peut alors travailler sans Internet et synchroniser les modifications ensuite. Il serait donc inexact d’affirmer que ces documents exigent en permanence une connexion pour la moindre lecture.

Mais travailler dans un environnement préparé pour fonctionner hors ligne et disposer d’un fichier ouvert par un autre logiciel sont deux choses différentes. Le premier répond à une interruption de connexion. Le second permet aussi d’envisager une sortie du service.

L’export transforme le document en un format récupérable ailleurs. La sauvegarde ajoute une autre exigence : conserver une copie que l’on sait retrouver et relire. Si le seul exemplaire exporté reste dans le même espace synchronisé, on n’a pas encore beaucoup diversifié les risques.

Cette différence vaut au-delà de Google. La synchronisation rend plusieurs emplacements cohérents ; elle ne promet pas, à elle seule, un exemplaire indépendant préservé de toutes les mauvaises manipulations. Ce qui m’intéresse n’est pas le nombre d’icônes vertes, mais ce qui restera lisible quand le chemin habituel ne fonctionnera plus.

Takeout n’est pas une impasse

Le billet de départ se montre très réservé sur Google Takeout. Il faut corriger un point : l’aide officielle de Google indique explicitement que l’export couvre les documents, feuilles de calcul et présentations, avec différentes données associées. On ne peut donc pas présenter cet outil comme incapable de récupérer le trio Docs, Sheets et Slides.

La procédure générale de Takeout permet de sélectionner les produits à exporter et propose, pour certains, des choix supplémentaires. L’idée d’un export nécessairement limité à un bloc aveugle de tout le compte est trop sommaire. Cela ne veut pas dire que chaque archive sera immédiatement pratique pour chaque usage.

Pour quelques documents, le téléchargement depuis le menu Fichier reste également une voie officielle. On choisit un format, puis on récupère une copie. Pour un ensemble volumineux, le temps de traitement et l’organisation de l’archive deviennent des critères à part entière.

Il reste surtout une différence entre récupérer le contenu et reconstruire à l’identique un espace de travail collaboratif. Les droits d’accès, les liens de partage et les habitudes d’équipe ne se transportent pas simplement parce qu’un fichier Word s’ouvre. Une migration réussie demande de définir ce que l’on veut retrouver, plutôt que de cocher seulement « export terminé ».

Le script aide, mais son nom ne suffit pas

Jay propose Export-GoogleShortcuts, un script PowerShell qui repère les raccourcis dans une arborescence locale, puis utilise l’API de Drive pour demander des versions Word, Excel ou PowerPoint. Il les place à côté des éléments d’origine avec un suffixe distinct. C’est une réponse ciblée au besoin de conserver l’organisation des dossiers.

J’ai examiné le code de sa version du 4 février, sans l’exécuter ni lui confier un compte. Un détail change la lecture : pour retrouver le document distant, cette version cherche son nom et son type, puis retient le premier résultat. Elle ne récupère pas simplement un identifiant unique en lisant chaque raccourci.

Si deux documents portent le même nom dans des dossiers différents, cette méthode peut donc sélectionner le mauvais. La recherche élargie prévue en secours peut ajouter de l’ambiguïté. Avant de considérer une série d’exports comme fidèle, il faudrait comparer les résultats aux documents attendus, pas seulement compter les fichiers créés.

Autre limite précise : la référence officielle de files.export fixe un maximum de 10 Mo pour le contenu exporté par cette méthode. Ce n’est pas une taille maximale générale de Google Docs, ni la preuve qu’une erreur vient toujours d’un délai dépassé. Le chiffre de 95 % de réussite avancé par l’auteur n’est pas un résultat que j’ai mesuré et je n’en fais pas une garantie.

Enfin, l’accès demandé est en lecture seule, mais porte sur Drive, pas uniquement sur le dossier local indiqué. Le code conserve aussi des jetons d’accès dans un fichier local : ils doivent rester privés. Utiliser une API officielle ne dispense ni d’examiner les permissions ni de protéger ce qui permet de se reconnecter.

Ce script peut fournir une piste intéressante ; il ne mérite pas pour autant un lancement automatique au milieu de documents précieux. Sa commodité répond à un problème d’organisation. Elle ne remplace ni un contrôle des conversions ni une vérification de sécurité, que cette lecture de code ne prétend pas constituer.

Le vrai test consiste à rouvrir la copie

Je commencerais par un échantillon varié : un texte simple, un document avec images, un tableur comportant des formules et une présentation. Le but n’est pas de produire une collection de nouvelles extensions, mais de vérifier les éléments utiles dans le logiciel qui devra effectivement les relire.

Une mise en page décalée n’a pas toujours la même gravité qu’une formule mal reprise ou qu’une information manquante. Il faut pouvoir distinguer les imperfections tolérables des pertes qui rendent le document inutilisable. Une archive n’a pas besoin d’être parfaite pour être utile ; elle doit répondre au besoin annoncé.

Je garderais ensuite l’original tant que cette vérification n’est pas faite, et une copie séparée de l’environnement que l’on envisage de quitter. Fermer un compte avant d’avoir vérifié ce qu’on en a extrait serait une drôle de manière de tester sa liberté : on découvrirait la porte de sortie après l’avoir claquée.

Ce que cette histoire change dans mon regard est assez simple. Le confort du cloud consiste souvent à effacer les détails techniques. Pour partir, sauvegarder ou transmettre durablement, il faut en faire réapparaître quelques-uns : où est le contenu, dans quel format et avec quelle dépendance ?

Je ne vois pas là une raison de renoncer aux outils collaboratifs. Je vois plutôt une question à poser avant d’en avoir besoin : si demain le service disparaît de mon quotidien, est-ce que je garde mes documents, ou seulement les pancartes qui indiquaient où les trouver ?