← Tous les articles

Google Docs ↔ Markdown : un vrai aller-retour avec rclone.

2026-07-16 · 5 min de lecture · par Nabil BA-MOH

Tes collaborateurs vivent dans Google Docs. Tes outils (git, éditeurs, assistants IA) vivent dans le markdown. La réponse habituelle : choisir un camp et souffrir. Pas besoin : Google Drive exporte les Docs en markdown natif, rclone le pilote en ligne de commande, et le retour met à jour le même doc sur place. Même id, même URL, même partage.

Tout ce qui suit a été vérifié sur rclone v1.74 en juillet 2026, y compris des contrôles de stabilité de l’id sur des envois répétés.

Récupérer un Doc en markdown propre

Google Drive peut exporter un Doc en markdown natif : pas du HTML à convertir ensuite, du vrai markdown. Avec rclone, un seul flag l’active :

rclone copy "remote:folder" ./local --drive-export-formats md

Les titres, le gras et l’italique passent proprement. Ton Doc arrive sur le disque sous forme de fichier .md que toute ta chaîne d’outils comprend.

Renvoyer le markdown, vers le MÊME doc

C’est dans l’autre sens que ça devient intéressant. Ceci crée un vrai Google Doc à partir d’un fichier markdown :

rclone copyto file.md "remote:folder/file.md" \
  --drive-import-formats md --drive-export-formats md

Et voici la partie qu’on a spécifiquement vérifiée : renvoyer plus tard met à jour le même document sur place. Même id de doc, même URL, mêmes réglages de partage. Le lien de tes collaborateurs ne casse jamais ; leurs commentaires restent attachés à un document vivant. On l’a confirmé par des contrôles de stabilité de l’id sur des envois répétés, pas en le supposant.

Le piège qui bloque tout le monde

À l’envoi, les flags de format d’import et d’export doivent TOUS LES DEUX être réglés sur md. Oublie le flag d’export et rclone refuse avec :

can't convert .md to a document with a different export filetype (.docx)

L’erreur ressemble à un problème de conversion ; c’est en fait un problème de flag. Mets les deux flags et ça marche. Cette ligne est probablement la raison pour laquelle tu lis cet article, alors la voilà.

Quatre autres pièges, tous réels

1. Le dossier de synchro desktop de Drive ne sert à rien ici. Dans le dossier synchronisé, les Docs et les Sheets apparaissent comme des fichiers .gdoc et .gsheet : ce sont des fichiers pointeurs, sans contenu. Tu ne peux pas lire un Doc via le système de fichiers. Passe par l’API, c’est exactement ce que fait rclone.
2. N’ouvre jamais le .md de ton miroir local depuis l’interface web de Drive. Si tu utilises « open with Google Docs » sur un .md envoyé, Drive crée un document en double au lieu de convertir sur place. Te voilà avec deux docs et une équipe perdue. La commande d’envoi ci-dessus est le seul chemin d’écriture sûr.
3. La synchro différentielle ne coûte rien. Relancer la même synchro rclone sans changement transfère 0 octet et se termine en 0,4 seconde environ. Tu peux la lancer en boucle ou en cron sans penser au quota.
4. Sépare lecture et écriture dans deux remotes. Configure un remote avec le scope drive.readonly pour récupérer et un second avec le scope complet drive pour envoyer. Le canal qui peut écrire n’existe alors qu’aux quelques endroits qui l’utilisent explicitement : une réduction réelle et peu coûteuse des dégâts possibles.

Une note pour la suite : le client_id Google par défaut partagé de rclone sera retiré au cours de 2026. Crée ton propre client_id dans la Google Cloud Console et mets-le dans la config du remote ; le toi du futur remerciera le toi d’aujourd’hui.

Ce que ça débloque : la co-écriture différée

Le schéma que ça permet mérite un nom. Les documents de travail restent dans Google, là où sont déjà les collaborateurs, les commentaires et le partage. Tes outils (et ton IA) travaillent sur le miroir markdown, avec gestion de versions et diffs. Quand une révision est prête, un envoi explicite la publie dans le même doc partagé que tout le monde a déjà ouvert. Personne ne change sa façon de travailler, sauf toi.

Nouveau dans cette façon de travailler ? Commence par notre guide de Claude Code pour non-développeurs.

FAQ