sodimo

Chapitre 37 / 39

Le coffre de comptes

Chaque compte numérique dont Sodimo dépend — la connexion Cloudflare, le registrar de domaine, les comptes partagés, les clés SSH qui donnent accès au Framework Desktop, les tokens API qu’utilisent les agents — a besoin d’un endroit unique, partagé et fiable pour exister. Cet endroit, c’est le coffre de comptes Sodimo.

Ce chapitre est la vue côté collaborateur : ce qu’est le coffre, comment y accéder, et dans quels cas vous l’utiliserez ou non. La spécification technique complète — comment le coffre est implémenté, sauvegardé et récupéré, ainsi que la liste officielle de qui a accès à quoi — se trouve dans le chapitre compagnon Le coffre (chapitre 37, dans la partie 30 L’infrastructure). Référez-vous à ce chapitre pour tout ce qui concerne l’implémentation, les sauvegardes, la reprise après incident ou la structure sur disque.

Statut : Prévu — le coffre s’active sur le Framework Desktop en même temps que le reste du harness. Avant sa mise en ligne, les identifiants sont gérés individuellement selon le chapitre Comment le système est construit (gestionnaire de mots de passe personnel + papier). La transition vers le coffre se fait en une seule session avec Thomas pendant l’engagement.

Ce qu’est le coffre, en un paragraphe

Le coffre est une instance Vaultwarden hébergée par Sodimo, tournant sur le Framework Desktop — un serveur compatible Bitwarden, de sorte que tous les clients Bitwarden (l’application web, les extensions navigateur pour Chrome, Firefox et Safari, les applications iOS et Android) fonctionnent avec lui sans modification. Chaque collaborateur dispose de son propre compte Vaultwarden, protégé par un mot de passe maître et un second facteur TOTP. Le coffre est accessible à l’adresse vault.sodimo.eu via Cloudflare Access — le portail d’entrée est donc le même identifiant Google Workspace que pour tous les autres outils Sodimo.

En clair : c’est le gestionnaire de mots de passe partagé que l’équipe souhaitait déjà avoir, hébergé sur du matériel physiquement propriété de Sodimo, et il ressemble et se comporte comme Bitwarden parce qu’il est Bitwarden sous le capot.

Ce qui entre dans le coffre

Quatre collections, une règle : si Sodimo possède un identifiant, il vit ici. Si ce n’est pas le cas, le coffre est incomplet et l’entrée manquante doit être ajoutée.

  • Mots de passe SaaS — Cloudflare, le registrar de domaine, le portail opérateur, les comptes téléphoniques, le prestataire de paiement, le logiciel de comptabilité, GitHub, et tout autre service avec un écran de connexion.
  • Clés SSH privées — les clés qui donnent accès au Framework Desktop, à tout serveur de développement, aux clés de déploiement utilisées par la CI. (Oui, les clés privées — tout l’intérêt du coffre est d’être l’unique endroit où elles peuvent vivre.)
  • JSONs de comptes de service — compte de service Google Workspace, identifiants de l’API WhatsApp Business, les identifiants de soumission SMTP.
  • Clés API pour les intégrations tierces — la clé API Anthropic, le token API Cloudflare, les tokens D1, tout token SaaS tiers.

Chaque entrée porte ses propres métadonnées — à quoi elle sert, qui l’utilise, quand elle a été renouvelée pour la dernière fois — conservées dans des champs personnalisés à côté du secret.

Ce qui n’entre pas dans le coffre

Quelques éléments vivent ailleurs délibérément :

  • Votre mot de passe Google Workspace personnel. C’est votre compte, pas celui de Sodimo. Gérez-le dans votre propre gestionnaire de mots de passe personnel (ou, mieux, avec une passkey).
  • Le jeu de récupération papier — accès de secours au registrar, accès root Cloudflare, clés de récupération LUKS, le token administrateur Vaultwarden lui-même. Ces éléments sont écrits sur papier et détenus par Jack et Paul, précisément parce que le coffre doit être récupérable même si le coffre est perdu. Le jeu papier est la clé de dernier recours ; le coffre est la clé du quotidien.
  • Tout ce qui est déjà en authentification unique via Google. Le launchpad, le CRM, OpenWebUI, Piler — aucun de ces services n’a besoin d’un mot de passe séparé dans le coffre. Si vous pouvez vous connecter à Gmail, vous êtes dedans.

Comment un collaborateur accède au coffre

Au quotidien, la plupart des collaborateurs ne touchent jamais au coffre pour les services où ils passent déjà par le SSO Google. Vous y accédez explicitement quand :

  1. Vous avez besoin du mot de passe d’un SaaS qui n’est pas derrière le SSO Google (le registrar, un portail opérateur, un tableau de bord de paiement).
  2. Vous configurez un nouvel ordinateur et devez y récupérer votre coffre.
  3. Vous remplacez Thomas sur une tâche de maintenance et avez besoin d’un token API ou d’une clé SSH spécifique.
  4. Vous effectuez une rotation de clé (voir le chapitre Rotation de clés).
  5. Vous accueillez un nouveau collaborateur et devez lui accorder l’accès à une collection.

Le flux est le même dans chaque cas, et il est entièrement dans le navigateur — pas de client VPN à installer, pas de Tailscale, pas de terminal. Simplement :

  1. Ouvrez vault.sodimo.eu dans votre navigateur.
  2. Cloudflare Access intercepte la requête et vous demande de choisir votre compte Google Workspace @sodimo.eu. Approuvez.
  3. La page de connexion Vaultwarden se charge. Saisissez votre mot de passe maître Vaultwarden et votre code TOTP.
  4. Vous êtes connecté. L’interface web affiche vos collections — mots de passe SaaS, clés SSH, JSONs de comptes de service, clés API — filtrées selon ce que votre rôle autorise.

C’est tout. Deux connexions (Google + Vaultwarden) plus un TOTP, entièrement dans le navigateur. Le réseau overlay Tailscale n’est pas dans ce chemin — Tailscale est un outil de maintenance que Thomas utilise pour ses travaux SSH, pas quelque chose que les collaborateurs Sodimo installent ou configurent.

Pour l’usage quotidien, installez l’extension navigateur et l’application mobile. Connectez-vous avec le même compte. Le remplissage automatique fonctionne alors sur tous les sites enregistrés ; l’application mobile vous couvre quand vous êtes loin de votre ordinateur. Configuration unique, bénéfice permanent.

Qui peut lire quoi

Vaultwarden organise les entrées en collections, et chaque collection dispose d’un ensemble de personnes et de services autorisés à la lire ou à l’écrire. La correspondance officielle se trouve dans le chapitre Le coffre ; les rôles en termes humains sont :

  • Opérateur principal — Thomas pendant l’engagement, Michel après la passation. Détient le token administrateur Vaultwarden, peut réinitialiser n’importe quel compte, peut modifier les listes d’accès.
  • Éditeurs — Thomas et Paul. Peuvent ajouter, modifier et partager des entrées dans toutes les collections.
  • Lecteurs — Rani, Jack, et tout autre collaborateur Sodimo. Limités par collection — Rani lit les identifiants CRM et mail, Jack lit les identifiants légaux et administratifs, aucun des deux ne lit les identifiants d’infrastructure.
  • Comptes de service — aucune connexion humaine. Accès restreint par service, de sorte que le service sodimo-etl peut lire son token D1 et rien d’autre. Ces comptes ne se connectent jamais via un navigateur ; ils s’authentifient avec un identifiant machine.

Accorder à un nouveau collaborateur un accès en lecture est une opération de deux minutes dans l’interface d’administration Vaultwarden. Le chapitre Rotation de clés couvre les mécanismes de départ.

Pour aller plus loin

  • Effectuer une rotation de clé, ou savoir quand la prochaine est due → chapitre Rotation de clés.
  • Créer une nouvelle clé SSH depuis zéro → chapitre Les bases de SSH.
  • La spécification technique, la stratégie de sauvegarde, la procédure de récupération et la matrice d’accès complète → chapitre Le coffre (chapitre 37, partie 30).

Le coffre est volontairement ennuyeux. Chaque fois que l’équipe se demande « où est ce mot de passe ? », la réponse tient en une phrase : « ouvrez vault.sodimo.eu ».