Gestionnaires de mots de passe pour développeurs : Bitwarden CLI vs 1Password CLI vs pass vs gopass 2026

Table des matières

• Pourquoi le CLI est essentiel pour les développeurs
• Bitwarden CLI en profondeur
• 1Password CLI en profondeur
• pass en profondeur
• gopass en profondeur
• Matrice comparative : 4 outils × 12 critères
• Recommandations par profil

Pourquoi le CLI est essentiel pour les développeurs

Un gestionnaire de mots de passe avec interface graphique est une couche de confort. Un gestionnaire en ligne de commande est de l'infrastructure. La différence devient évidente dès que vous avez besoin d'un secret dans un script shell, un pipeline CI/CD, un build Docker, un init container Kubernetes, ou un cron job qui tourne à 3h du matin sans aucun utilisateur connecté dans la chaîne.

Quatre workflows exposent systématiquement cette limite.

Scripting et automatisation. Scripts shell appelant des API authentifiées, migrations de base de données, scripts de déploiement qui renouvellent des certificats TLS — tous ont besoin d'identifiants à l'exécution. Le pattern de coder en dur un secret dans un script ou un fichier d'environnement est encore comment la plupart des équipes démarrent, et c'est aussi comme la plupart subissent leur première compromission. Un gestionnaire CLI casse ce pattern proprement : l'identifiant vit dans le coffre et est récupéré, utilisé et supprimé en une seule invocation de commande.

Rotation des secrets. Les référentiels de conformité (SOC 2, ISO 27001, contrôles opérationnels RGPD) exigent désormais une rotation des identifiants sur calendrier fixe — clés API à 90 jours, mots de passe de base de données à 30 jours dans certains environnements. Faire cela manuellement est lent et source d'erreurs. Un outil CLI couplé à un script de rotation rend cela mécanique : récupérer l'ancien secret, appeler l'API du service pour rotation, écrire le nouveau secret dans le coffre, mettre à jour les consommateurs en aval par injection de variables d'environnement.

Injection de secrets CI/CD. Le pattern devenu standard en 2026 : plus de secrets dans les paramètres de variables d'environnement de votre dashboard CI. À la place, un token de session court-lived authentifie le pipeline au coffre, les secrets sont récupérés au démarrage du job, injectés dans l'environnement du sous-processus, et la session expire. C'est ce qu'activent bw run, op run et le rendu de templates gopass.

Gestion des clés SSH. Les clés privées SSH sont des identifiants. Les stocker comme fichiers en clair sur les machines des développeurs équivaut à un mot de passe en texte brut. Les quatre outils de ce comparatif peuvent servir de store chiffré pour les clés SSH ; deux d'entre eux exposent un socket d'agent SSH natif qui gère les opérations de signature sans jamais placer la clé déchiffrée sur disque.

Les quatre outils se répartissent en deux catégories. Bitwarden CLI et 1Password CLI sont des frontends à des services de coffre synchronisés dans le cloud avec une infrastructure commerciale derrière. pass et gopass sont des outils locaux construits sur le chiffrement GnuPG et la synchronisation git, sans composant cloud obligatoire. Les compromis entre ces deux modèles — simplicité opérationnelle versus modèle de confiance — sont l'axe autour duquel la plupart des décisions d'équipe se jouent.

Bitwarden CLI en profondeur

Bitwarden est un gestionnaire de mots de passe open-source avec un serveur auto-hébergeable (Vaultwarden est le fork communautaire, le serveur officiel Bitwarden est également open-source). La CLI, bw, est un binaire Node.js distribué comme exécutable unique pour Linux, macOS et Windows.

Authentification et déverrouillage du coffre. Deux chemins d'authentification existent. La connexion interactive avec bw login demande email, mot de passe maître et token 2FA. La connexion par clé API avec bw login --apikey utilise les variables d'environnement BW_CLIENTID et BW_CLIENTSECRET — c'est le bon chemin pour les pipelines CI/CD. Après l'authentification, le déverrouillage du coffre est une étape séparée : bw unlock avec BW_PASSWORD défini retourne un token de session. Stocker le token de session dans BW_SESSION pour la durée du job.

export BW_SESSION=$(bw unlock --passwordenv BW_PASSWORD --raw)
bw get password "production/postgres"

Le token de session est une clé AES-256 locale qui déchiffre le blob chiffré du coffre en cache. Il a une durée de vie courte par défaut (15 minutes d'inactivité) et ne quitte pas la machine.

Modèle de synchronisation. Le coffre est mis en cache localement comme blob chiffré après bw sync. En environnement CI, lancez toujours bw sync au début d'un job pour garantir que le cache local correspond au serveur. La synchronisation est un pull complet : pas de synchronisation partielle disponible, ce qui signifie que l'opération est O(taille du coffre). Pour les coffres de moins de 10 000 éléments, la latence de sync est inférieure à 2 secondes.

Spécification du chiffrement. Bitwarden chiffre les données du coffre avec AES-256-CBC avec un IV aléatoire par champ. La clé du coffre est dérivée du mot de passe maître avec Argon2id (64 Mo de mémoire, 3 itérations, 4 threads). La clé étendue ne quitte jamais le client. Toutes les opérations cryptographiques se font localement ; le serveur ne stocke que le texte chiffré. Le code source du client et du serveur est sur GitHub et a été audité par des tiers — le plus récent par Cure53 publié en mars 2025.

Patterns de variables d'environnement. Pour les secrets applicatifs, Bitwarden supporte le chargement direct des identifiants dans les environnements de sous-processus :

bw get notes "app/env-vars" | source /dev/stdin
# ou avec bw run :
bw run -- ./mon-script.sh

La commande bw run n'est pas encore aussi complète que op run, mais couvre les cas courants.

Tarifs. Gratuit : mots de passe illimités, pas de partage d'éléments, pas de récupération 2FA, pas de TOTP. Plan individuel : 10 $/an — ajoute support TOTP, pièces jointes chiffrées, accès d'urgence. Plan Teams : 4 $/utilisateur/mois — ajoute les coffres d'organisation partagés, gestion des groupes, console admin, journaux d'événements, accès API. L'option auto-hébergée est disponible sur tous les plans payants sans coût supplémentaire : déployez le serveur Bitwarden sur votre propre infrastructure et la CLI s'y connecte.

1Password CLI en profondeur

1Password est un gestionnaire de mots de passe commercial à source fermée. La CLI, op, est un binaire Go distribué via les dépôts de paquets 1Password et Homebrew. C'est le plus complet des quatre outils du point de vue CI/CD et workflows développeur.

Authentification et comptes de service. 1Password CLI 2.x a introduit les comptes de service spécifiquement pour les usages non-interactifs. Un compte de service a un token (OP_SERVICE_ACCOUNT_TOKEN) qui accorde un accès lecture ou lecture-écriture à des coffres spécifiques. Il n'y a pas de mot de passe maître dans la boucle. C'est le modèle correct pour les pipelines CI/CD, les secrets partagés dans des containers, et tout système automatisé qui a besoin d'un accès long-lived aux identifiants.

export OP_SERVICE_ACCOUNT_TOKEN="ops_..."
op read "op://DevVault/postgres/password"

Intégration SSH agent. C'est la fonctionnalité qui distingue 1Password des trois autres outils pour les workflows développeur individuels. L'app 1Password expose un socket d'agent SSH (/tmp/1password-ssh-agent.sock). Ajoutez IdentityAgent dans votre ~/.ssh/config et vos clés SSH sont signées par l'agent sans que la clé privée touche jamais le système de fichiers en clair. Combiné au déverrouillage biométrique (Touch ID sur macOS, Windows Hello), c'est le workflow de clés SSH le plus ergonomique disponible aujourd'hui.

Intégrations développeur. 1Password CLI a des intégrations first-class avec plusieurs outils développeur :

• op run injecte des secrets depuis des fichiers template .env avec la syntaxe op://vault/item/field. Aucun secret en clair n'est écrit sur disque.
• Signature de commits Git via l'intégration SSH agent : op signe les commits avec une clé SSH stockée dans le coffre.
• Provider Terraform : le provider 1password/onepassword lit et écrit des secrets depuis les plans Terraform.
• Injection de secrets Kubernetes : op inject rend les manifests Secret Kubernetes avec les références coffre résolues au moment du déploiement.

Spécification du chiffrement. 1Password utilise AES-256-GCM pour les données du coffre, avec des clés protégées par le modèle à double clé Secret Key + Mot de passe maître. La clé secrète (128 bits d'entropie aléatoire générée à la création du compte) n'est stockée que sur les appareils de l'utilisateur, jamais sur les serveurs 1Password. La dérivation de clé utilise PBKDF2-SHA256 (650 000 itérations pour le composant mot de passe maître). Le modèle combiné signifie qu'une compromission du serveur seule ne peut déchiffrer aucune donnée du coffre.

Tarifs. Individuel : 36 $/an (2,99 $/mois) — mots de passe illimités, 1 Go de stockage de documents, Travel Mode. Teams Starter : 19,95 $/mois pour jusqu'à 10 utilisateurs — comptes invités, coffres partagés, permissions granulaires. Business : 8 $/utilisateur/mois — RBAC avancé, rôles personnalisés, intégration Splunk/SIEM, API journaux d'audit. Enterprise : tarif personnalisé — provisionnement SSO/SCIM, revues de sécurité personnalisées, support dédié. Pas de niveau gratuit. Pas d'option auto-hébergée.

pass en profondeur

pass est le Gestionnaire de Mots de Passe Unix Standard. Créé par Jason Donenfeld (également auteur de WireGuard), c'est un script Bash — le programme entier, y compris la synchronisation, la génération et l'édition, fait moins de 600 lignes de shell. La philosophie de conception est explicite : un fichier texte par secret, chiffré avec GPG, stocké dans une arborescence de répertoires, synchronisé via git.

Mécanique de base. Le store de mots de passe vit dans ~/.password-store par défaut. Chaque entrée est un fichier .gpg dont le texte en clair est typiquement un mot de passe à la première ligne suivi de métadonnées (URL, nom d'utilisateur, notes) sur les lignes suivantes. La convention est respectée par tous les clients compatibles pass.

~/.password-store/
  production/
    postgres.gpg        # mot de passe ligne 1, notes en dessous
    api-key-stripe.gpg
  personal/
    email.gpg

Chiffrement d'un nouveau secret :

pass insert production/redis-password
# ou en multiligne :
pass insert --multiline production/postgres

Lecture :

pass production/postgres            # affiche sur stdout
pass -c production/postgres         # copie dans le presse-papier, efface en 45s

Modèle GPG. Chaque fichier .gpg est chiffré pour un ou plusieurs IDs de clé GPG publique spécifiés dans les fichiers .gpg-id au niveau du répertoire. C'est ainsi que fonctionne l'accès multi-destinataires : ajoutez les empreintes de clé des membres de l'équipe à .gpg-id, puis re-chiffrez avec pass init --reencrypt. Chaque secret du sous-arbre est re-chiffré pour toutes les clés listées.

Le modèle de sécurité est aussi transparent qu'il est possible de faire : vous faites confiance à GnuPG, à votre propre gestion de clés, et à l'hébergeur git. Aucun middleware, aucun binaire propriétaire, aucun flux d'authentification cloud. Le modèle de menace est proportionnellement simple à raisonner.

Synchronisation git. pass git proxifie directement les commandes git. pass git push, pass git pull. L'historique git stocke chaque changement avec un message de commit qui révèle intentionnellement uniquement le type d'opération (ajout, édition, suppression) et le chemin de l'entrée — le contenu reste chiffré. Pour les équipes, un dépôt bare partagé sur un hébergeur git privé est la configuration standard.

Écosystème. pass dispose d'un large écosystème :

• passff / browserpass : extensions navigateur pour Firefox et Chrome.
• Android Password Store (maintenant OpenKeychain + APS) : client Android compatible.
• QtPass : GUI multiplateforme.
• pass-otp : plugin pour codes TOTP — pass otp production/totp-key.

Limitations. La philosophie Unix a ses revers. Pas d'interface de gestion d'équipe, pas de journaux d'accès, pas de détection de brèche, pas de help desk. La gestion des clés GPG à l'échelle est réellement pénible : quand un membre de l'équipe part, vous retirez sa clé du .gpg-id et re-chiffrez chaque secret auquel il avait accès. Pour une équipe de 20 personnes, cela peut prendre plusieurs minutes. gopass adresse la plupart de ces points de friction.

Prix. Gratuit. Licence MIT.

gopass en profondeur

gopass est pass, réécrit en Go, avec des secrets structurés, des commandes d'équipe et un backend pluggable. Créé par des ingénieurs chez Codecentric, il est activement maintenu en 2026. Le binaire principal, gopass, est un remplacement direct de pass — il lit et écrit le même format de store — tout en ajoutant des capacités manquantes à l'échelle.

Secrets structurés. Là où pass stocke un blob de texte par entrée, gopass supporte un format clé-valeur de type YAML à l'intérieur du fichier chiffré :

gopass insert --multiline production/postgres
# texte en clair à l'intérieur du .gpg :
---
password: hunter2
username: postgres
host: db.prod.example.com
port: 5432

Les champs sont ensuite accessibles individuellement :

gopass show production/postgres password   # juste le mot de passe
gopass show production/postgres host       # juste le host

C'est significatif pour CI/CD : les champs individuels peuvent être injectés dans des variables d'environnement sans analyser une sortie multiligne.

Mounts. gopass supporte plusieurs stores de mots de passe (« mounts ») accessibles sous des préfixes d'espace de noms :

gopass mounts add work   git@github.com:monentreprise/passwords.git
gopass mounts add home   ~/.personal-pass

Les secrets vivent à work/production/postgres ou home/personal/email. Chaque mount est un dépôt git séparé avec son propre .gpg-id. C'est le bon modèle pour un développeur qui a un coffre professionnel et un coffre personnel qui ne doivent jamais être mélangés.

Workflows d'équipe. gopass dispose de commandes de gestion d'équipe first-class :

• gopass recipients add --store work "collegue@example.com" — ajoute la clé GPG d'un destinataire depuis votre trousseau, puis re-chiffre uniquement le mount concerné.
• gopass recipients rm --store work "parti@example.com" — supprime une clé et re-chiffre.
• gopass audit — vérifie les mots de passe faibles et les entrées dupliquées sur tous les mounts.

Support du chiffrement age. Depuis la version 1.14, gopass supporte age (un outil de chiffrement moderne par Filippo Valsorda) comme alternative à GPG. age a un format de clé plus simple (clés X25519, clés SSH, ou clés dérivées d'une passphrase), aucune dépendance à un serveur de clés, et une base de code plus auditable. Pour les nouveaux stores, age est recommandé sur GPG si l'équipe n'a pas d'infrastructure GPG existante.

gopass init --crypto age

Rendu de templates. gopass a une sous-commande gopass env qui résout les références de secrets dans un template d'environnement :

DATABASE_URL=postgres://{{ gopass "production/postgres/username" }}:{{ gopass "production/postgres/password" }}@{{ gopass "production/postgres/host" }}:5432/mydb

Pas aussi abouti que op run, mais fonctionnel pour la plupart des cas de pipeline.

Prix. Gratuit. Licence MIT.

Matrice comparative : 4 outils × 12 critères

Notes chiffrement. AES-256-GCM (1Password) fournit un chiffrement authentifié nativement, tandis qu'AES-256-CBC (Bitwarden) nécessite un MAC séparé. En pratique, les deux implémentations sont solides. Le chemin GnuPG pour pass et gopass a une surface d'attaque plus large en termes de complexité de bibliothèque, mais le code a été abondamment audité. age est l'option la plus propre du point de vue de la conception cryptographique : échange de clé X25519, chiffrement de payload ChaCha20-Poly1305, aucun piège d'agilité algorithmique.

Notes sync. Les outils synchronisés dans le cloud (Bitwarden, 1Password) sont plus simples à exploiter : installer, authentifier, c'est fait. Les outils basés sur git nécessitent d'héberger un dépôt, de gérer la discipline clone/push/pull, et de gérer les conflits de fusion si deux membres de l'équipe éditent simultanément. L'avantage est qu'ils n'ont aucune dépendance cloud obligatoire — le coffre peut vivre entièrement sur une infrastructure que vous contrôlez.

Recommandations par profil

Développeur indépendant (solo, sans équipe). Utilisez Bitwarden CLI sur un compte gratuit pour tout ce qui ne nécessite pas l'intégration SSH agent, et 1Password si vous voulez la gestion des clés SSH clé en main. Pour le développeur solo très soucieux de la vie privée qui veut zéro dépendance cloud : gopass avec chiffrement age sur un dépôt git privé que vous hébergez. La courbe d'apprentissage est réelle mais le modèle de confiance est le plus propre disponible.

Équipe de 5 à 20 développeurs. Commencez avec 1Password Teams si le budget le permet — l'intégration SSH agent, op run pour le CI/CD, les comptes de service pour les pipelines, et le journal d'audit couvrent 95% de ce dont une équipe de cette taille a besoin, avec une surcharge opérationnelle minimale. Si le budget est une contrainte ou si l'auto-hébergement est une exigence absolue, Bitwarden Teams (4 $/utilisateur/mois, auto-hébergeable via Vaultwarden) est le bon choix. Évitez pass ou gopass à cette échelle sauf si l'équipe dispose d'une expertise dédiée en gestion de clés GPG.

Enterprise (100+ développeurs). 1Password Business ou Bitwarden Enterprise (auto-hébergé). Les facteurs différenciants sont le provisionnement SSO/SCIM (1Password a OIDC et SAML ; Bitwarden a un connecteur d'annuaire SCIM), l'export du journal d'audit vers SIEM (les deux le supportent au niveau supérieur), et les rapports de conformité. Le niveau enterprise de 1Password inclut des politiques de protection avancées et des revues de sécurité à la demande. Le chemin auto-hébergé de Bitwarden est préféré par les organisations qui ne peuvent pas tolérer une dépendance cloud pour le matériel de clé.

Power user paranoïaque / spécialiste rotation de secrets. gopass avec age sur un dépôt git privé, clé GPG maître sur un appareil air-gapped ou un Yubikey, opérations quotidiennes signées avec une sous-clé. Pour la rotation des secrets, construisez un script de rotation qui appelle gopass show <secret>, frappe l'API du service pour rotation, et appelle gopass insert <secret> avec la nouvelle valeur. L'ensemble du pipeline tourne localement sans appel cloud sauf vers le service cible. Ajoutez gopass audit à votre cron hebdomadaire pour détecter les secrets faibles ou dupliqués avant qu'ils ne deviennent un problème de conformité.

Pour une lecture fondatrice sur le modèle de menace plus large qui rend la gestion des secrets critique, consultez notre pillar état de la vie privée des navigateurs 2026. Pour une référence sur le durcissement de la couche OS, notre analyse du mode Isolement couvre comment la surface d'attaque au niveau OS interagit avec les stores d'identifiants au niveau applicatif.

Quel que soit l'outil choisi, la ligne de base non négociable est celle-ci : aucun identifiant en clair ne touche un dépôt, un fichier de log, ou un dashboard de variables d'environnement. Un gestionnaire de mots de passe CLI est le mécanisme qui rend cette ligne de base maintenable à la vitesse d'ingénierie.