Proton Drive CLI : utiliser Proton Drive depuis des scripts et un serveur
Depuis juin 2026, Proton propose un outil officiel en ligne de commande pour Proton Drive. Cet article décrit les commandes, l’authentification sur des serveurs sans bureau, les stratégies de conflit pour les scripts et les limites par rapport à Rclone.
Le 9 juin 2026, Proton a publié Proton Drive CLI, un outil officiel en ligne de commande pour Windows, macOS et Linux. Il repose sur le même SDK que les applications Drive officielles, chiffre de bout en bout et est disponible sous la forme d’un unique fichier exécutable proton-drive. Le code source se trouve dans le dépôt public du SDK, sous cli/.
La CLI est conçue pour des opérations individuelles et ponctuelles : téléverser des fichiers après un build, sauvegarder un dossier selon un calendrier, vérifier ou retirer des partages. Elle ne synchronise pas en arrière-plan et ne monte pas de système de fichiers. La version actuelle est la 0.8.0 du 13 août 2026 ; son numéro indique que les commandes et options peuvent encore changer (la version 0.8.0 a renommé les stratégies de conflit avec une modification incompatible).
La place de cet outil parmi les autres options Linux (Rclone, client de bureau annoncé) est décrite dans l’article de statut Proton Drive sous Linux.
Aperçu des commandes
Les commandes sont organisées en groupes : proton-drive <gruppe> <befehl> [optionen] [argumente]. Les noms de groupes peuvent être abrégés tant qu’ils restent non ambigus ; pour filesystem, l’alias fs est également disponible. Sans argument, un shell interactif démarre. L’aide complète est fournie par proton-drive help ou proton-drive <gruppe> <befehl> --help.
Les chemins dans Proton Drive sont toujours des chemins POSIX, y compris sous Windows. La racine / contient des zones virtuelles : /my-files (fichiers personnels), /devices (ordinateurs sauvegardés), /shared-by-me, /shared-with-me, /trash ainsi que les zones Photos /photos, /albums, /photos-shared-by-me, /photos-shared-with-me et /photos-trash.
Installation sous Linux
Proton propose les builds sur une page de téléchargement dédiée, chacun avec une somme de contrôle SHA-512. Cinq variantes sont disponibles pour Linux :
| Build | Usage |
|---|---|
linux/x64 | Standard pour les systèmes x86-64 actuels |
linux/x64-baseline | x86-64 sans AVX2, p. ex. appareils NAS et processeurs de serveur plus anciens |
linux/arm64 | Serveurs ARM et ordinateurs monocarte avec glibc |
linux/x64-musl, linux/arm64-musl | Distributions utilisant musl au lieu de glibc, p. ex. Alpine Linux et les images de conteneurs qui en dérivent |
Si le build standard s’interrompt au démarrage avec Illegal instruction, l’extension AVX2 manque au processeur ; le build x64-baseline est alors le bon choix. Le fichier embarque l’environnement d’exécution Bun et ne nécessite aucune autre dépendance :
chmod +x proton-drive
sudo install -m 0755 proton-drive /usr/local/bin/proton-drive
proton-drive version
Sans droits d’administrateur, il suffit de copier le fichier dans ~/.local/bin, à condition que ce répertoire se trouve dans le PATH.
Connexion, y compris sur des serveurs sans bureau
auth login ne demande pas de mot de passe en ligne de commande. La CLI tente d’ouvrir un navigateur et affiche également l’URL de connexion. Cette URL peut être ouverte sur un autre appareil ; le terminal attend que la connexion y soit terminée. L’authentification à deux facteurs s’effectue normalement dans le navigateur. La connexion fonctionne ainsi également par SSH sur un serveur sans interface graphique.
proton-drive auth login
Après une connexion réussie, la CLI enregistre la session, et non le mot de passe. Son emplacement est déterminé par la variable d’environnement PROTON_DRIVE_CREDENTIALS_STORE :
| Valeur | Emplacement de stockage |
|---|---|
keychain (standard) | Gestionnaire de clés du système d’exploitation : Windows Credential Manager, macOS Keychain, sous Linux libsecret (GNOME Keyring, KWallet) |
pass | Entrée chiffrée avec GPG ch.proton.drive/drive-sdk-cli/auth-session dans le gestionnaire de mots de passe pass |
unsafe_file | Fichier texte brut auth-session.json dans le répertoire de données ; selon Proton, uniquement destiné aux tests |
Sur un serveur sans session de bureau, il n’y a généralement pas de trousseau libsecret déverrouillé. Depuis la version 0.6.0, l’option pass est prévue pour ce cas. L’utilisateur exécutant les scripts doit disposer d’un magasin de mots de passe initialisé et d’une clé GPG que le gpg-agent peut déverrouiller sans saisie interactive. La session doit être trouvée via la même variable à chaque appel, qui doit donc aussi être définie dans les tâches Cron et les unités systemd :
export PROTON_DRIVE_CREDENTIALS_STORE=pass
proton-drive auth login
C’est un progrès par rapport à Rclone : ni mot de passe ni clé TOTP ne se trouvent sur le serveur, et auth logout met fin à l’accès. La session conserve toutefois l’étendue complète du compte. Il n’existe aucune restriction à des dossiers individuels ou à un accès en lecture seule. Pour les processus automatisés, un compte Proton distinct reste donc l’option la plus sûre.
Sous Linux, le cache, les données d’application et les journaux se trouvent dans les répertoires XDG (~/.cache/proton-drive-cli, ~/.local/share/proton-drive-cli, ~/.local/state/proton-drive-cli). Avec PROTON_DRIVE_CACHE_DIR, les trois peuvent être placés dans un seul répertoire, par exemple pour un conteneur avec un volume monté. Par défaut, la CLI écrit les journaux au niveau DEBUG ; PROTON_DRIVE_LOG_LEVEL=WARNING réduit leur quantité.
Téléversement et téléchargement dans des scripts
En mode interactif, la CLI demande quoi faire pour chaque conflit de noms. Cela n’est pas possible dans les scripts : avec --json, la question interactive est désactivée. Définissez donc toujours explicitement la stratégie de conflit pour les fichiers et dossiers.
proton-drive filesystem upload --json \
--file-conflict-strategy create-new-revision \
--folder-conflict-strategy merge \
--skip-thumbnails \
/srv/export/berichte /my-files/backup
create-new-revision est le choix approprié pour les sauvegardes : Proton Drive conserve les versions antérieures d’un fichier et, depuis la version 0.7.0, la CLI ignore automatiquement les fichiers dont le contenu n’a pas changé. La CLI ne réalise toutefois pas de synchronisation : les fichiers supprimés localement restent dans Proton Drive. Pour un miroir incluant les suppressions, il faut toujours recourir à rclone sync.
Le téléchargement fonctionne de façon symétrique. Les stratégies diffèrent car le côté local est ici écrasé :
proton-drive filesystem download --json \
--file-conflict-strategy remove \
--folder-conflict-strategy merge \
/my-files/backup/berichte /srv/restore
La CLI ignore Proton Docs et Proton Sheets lors du téléchargement ; ils ne peuvent actuellement pas être exportés en tant que fichiers.
Un téléversement régulier peut être planifié avec un minuteur systemd ou Cron. La sortie JSON peut ensuite être analysée avec jq, par exemple pour envoyer une notification à la supervision.
Gérer les partages
Pour l’offboarding ou les audits, la gestion des partages est souvent plus utile que le transfert de fichiers. sharing status affiche pour un élément tous les membres, les invitations en attente et les paramètres d’un lien public :
proton-drive sharing status --json /my-files/projekte/kunde-a
Une invitation avec droits de lecture :
proton-drive sharing invite \
--user person@example.com \
--role viewer \
/my-files/projekte/kunde-a
Un lien public avec mot de passe et date d’expiration :
proton-drive sharing set-url \
--role viewer \
--password 'Linkpasswort' \
--expiration 2026-12-31 \
/my-files/projekte/kunde-a/bericht.pdf
Un mot de passe transmis en ligne de commande apparaît dans l’historique du shell et reste visible dans la liste des processus pendant l’exécution. Dans les scripts, il devrait donc provenir d’une variable ou d’un stockage de secrets. sharing remove-url supprime à nouveau le lien sans affecter les membres directs ; sharing remove --user … retire l’accès à certaines personnes.
En cours : Takeout
Depuis le 10 septembre 2026, le dépôt du SDK contient une commande supplémentaire takeout run. Elle exporte une copie hors ligne du compte vers un dossier local, au choix avec --include my-files, devices, photos et revisions (toutes les versions antérieures des fichiers). Pour chaque dossier, elle écrit un fichier manifest.json décrivant l’export ; elle ne modifie rien au compte. La commande n’est pas encore incluse dans la version publiée 0.8.0. Dès qu’elle paraîtra, elle sera la solution évidente pour une sauvegarde locale complète du contenu de Proton Drive.
Limites par rapport à Rclone
| Exigence | Proton Drive CLI 0.8.0 | Rclone (protondrive-backend) |
|---|---|---|
| Prise en charge officielle | Oui, par Proton, Open Source | Non, ingénierie inverse, bêta |
| Connexion | Navigateur, également sur un autre appareil ; session dans le gestionnaire de clés ou pass | Mot de passe et clé TOTP dans le fichier de configuration |
| Téléversement, téléchargement | Oui, avec stratégies de conflit et versionnage | Oui |
Miroir incluant les suppressions (sync) | Non | Oui |
| Monter un système de fichiers (FUSE) | Non | Oui |
| Partages, invitations, liens | Oui | Non |
| Proton Photos | Oui | Non |
| Accès à portée limitée | Non | Non |
Pour les sauvegardes, les artefacts de build et la gestion des partages, la CLI est le meilleur choix, car elle est officiellement prise en charge et ne nécessite pas de mot de passe enregistré. Pour un montage, tel que le nécessite par exemple une archive documentaire Paperless, et pour les miroirs incluant les suppressions, Rclone reste pour l’instant indispensable. Dans les deux cas, la principale lacune demeure la même : Proton ne propose aucun accès machine pouvant être limité à certains dossiers ou à la lecture seule.
Commentaires
Les commentaires sont chargés depuis GitHub / Giscus.