Tech lead d’une petite ESN spécialisée dans les applications web métier.
1Password Teams Starter Pack récemment installé, avec 10 membres invités.
Déjà en place : extension Chrome, agent SSH 1Password, une clé SSH et quelques identifiants.
L’équipe utilise actuellement beaucoup pass / password-store et possède aussi des identifiants dans Google Password Manager.
Objectif général : déterminer comment organiser les accès et secrets, préparer une migration progressive et vérifier si 1Password Starter est suffisamment structurant face à Bitwarden.
Aucun secret, identifiant personnel ou chemin contenant des données sensibles n’a été fourni.
Il n’existe pas de dossiers d’éléments au sens classique.
Un vault/coffre est la frontière de permissions. Un item appartient à un seul coffre.
Les tags servent au classement, peuvent être multiples et imbriqués avec /, mais ne portent aucun droit.
Une collection 1Password est uniquement une vue regroupant plusieurs coffres ; elle ne modifie pas les permissions.
Sur Teams Starter, les groupes personnalisés ne sont pas disponibles. Les membres doivent être affectés directement aux coffres. Les groupes personnalisés nécessitent 1Password Business.
Pour une ESN, éviter un coffre global Production — Restreint mélangeant les clients. Préférer une séparation par client seulement lorsque les personnes autorisées diffèrent, par exemple :
Client — Acme
Client — Acme — Production si l’accès production est plus restreint.
Règle proposée : coffre = « qui peut lire ? », tag = « de quoi s’agit-il ? », collection = « quels coffres veux-je afficher ensemble ? ».
Le montage local .env via 1Password Environments utilise un FIFO/named pipe et évite le stockage en clair, mais demande une configuration graphique par projet et par poste.
Cette solution est en bêta, macOS/Linux uniquement, limitée à dix montages actifs par appareil et présente des limites d’accès concurrent / file watchers.
L’utilisateur trouve cette configuration « clic-clic » peu industrialisable ; conclusion partagée.
Recommandation actuelle : versionner un .env.op contenant des références op://..., puis masquer le wrapper derrière une tâche mise, par exemple mise run dev appelant op run --env-file=.env.op -- npm run start:dev.
Développement local : authentification humaine via l’application/CLI.
CI/CD : compte de service en lecture seule, limité aux coffres ou Environments nécessaires. Ne jamais versionner OP_SERVICE_ACCOUNT_TOKEN.
1Password Starter : modèle plus simple, tarif forfaitaire pour 10 membres, bons outils développeur intégrés, mais administration des accès manuelle faute de groupes.
Bitwarden Teams : modèle groupes × collections mieux adapté aux changements réguliers d’affectation client, audit/API plus riches dans l’offre intermédiaire, mais davantage de relations à administrer.
Pour comparer les secrets applicatifs, ne pas comparer uniquement 1Password Starter à Bitwarden Password Manager Teams : inclure le coût et le modèle séparé de Bitwarden Secrets Manager.
Avis déjà donné : pour une ESN où les collaborateurs changent souvent de mission, Bitwarden Teams est structurellement plus convaincant sur la gestion des droits ; 1Password peut rester préférable si la simplicité et le workflow développeur intégré dominent.
Ne pas reproduire mécaniquement toute l’arborescence de pass.
Pour pass : convertir les chemins portant une vraie différence d’accès en coffres/collections ; convertir les chemins purement classificatoires en tags 1Password ou collections Bitwarden.
Une migration automatisée depuis pass serait préférable à un CSV générique afin de préserver le chemin, la première ligne comme mot de passe, les métadonnées username:, url:, host:, etc., et le contenu non reconnu dans les notes.
Pour Google Password Manager : export/import CSV officiellement supporté vers 1Password, mais seulement pour les mots de passe/logins. Les passkeys, cartes et adresses ne sont pas importées.
Importer d’abord dans des zones temporaires de migration, contrôler les doublons et tester les accès avant de supprimer les sources. Les CSV sont en clair : éviter sauvegarde/synchronisation et les supprimer immédiatement après validation.
Les exports Google individuels peuvent mélanger personnel et professionnel ; importer initialement dans un espace individuel, puis déplacer seulement les items professionnels vers les conteneurs partagés.
Construire une matrice de décision pondérée pour 10 personnes : coût total, fréquence des changements de mission, nombre de clients/coffres, audit, groupes, migration, secrets CI/CD et charge d’administration.
Si l’utilisateur fournit uniquement la structure non sensible de password-store (pass ls sans valeurs), proposer une taxonomie et une correspondance précise vers 1Password ou Bitwarden.
Concevoir ensuite un plan de migration réversible : pilote limité, import en quarantaine, dédoublonnage, vérification, rotation des secrets critiques, bascule des extensions et retrait progressif de Google Password Manager / pass.
Ne pas implémenter de script de migration avant d’avoir inspecté les variantes de format présentes dans les entrées pass et décidé la destination finale.