Vaultwarden : un coffre léger à auto-héberger, pas une sécurité automatique

Vaultwarden est un serveur open source de gestion de mots de passe, compatible avec les applications Bitwarden et conçu pour un auto-hébergement léger. Il permet de garder ses coffres sur sa propre infrastructure, mais transfère aussi la responsabilité du HTTPS, des mises à jour et des sauvegardes à l’administrateur. Pour un particulier, une famille ou une petite équipe, le bon choix dépend donc autant des fonctionnalités que de la capacité à maintenir le service.

Vaultwarden et Bitwarden : mêmes clients, serveurs différents

Écrit en Rust, Vaultwarden est une implémentation alternative de l’API utilisée par les clients Bitwarden. Le projet portait auparavant le nom Bitwarden_RS : les anciens tutoriels peuvent encore employer cette appellation. Il n’est pas affilié officiellement à Bitwarden.

Vous utilisez les extensions de navigateur, applications mobiles et applications de bureau officielles Bitwarden, en les configurant pour votre serveur. Cette compatibilité ne signifie toutefois pas que toutes les fonctions du serveur officiel sont reproduites à l’identique. Les nouveautés des clients et les fonctions avancées doivent être vérifiées dans la documentation de la version déployée.

Vaultwarden propose notamment le coffre personnel, les notes sécurisées, les pièces jointes, les organisations et les collections partagées. S’y ajoutent Send pour transmettre des informations, l’authentification multifacteur et l’accès d’urgence. Les méthodes disponibles, notamment TOTP et WebAuthn, ainsi que les fonctions collaboratives doivent être contrôlées selon la version.

Une famille peut ainsi séparer les identifiants personnels des comptes communs. Une petite organisation doit aussi vérifier ses besoins en rôles, journaux et assistance avant de retenir cette solution. Si personne ne peut assurer la maintenance, un service hébergé sera souvent plus raisonnable.

Préparer le réseau et le stockage avant Docker

Un petit serveur Linux, un VPS ou une machine domestique peuvent convenir. Docker ou Podman simplifient le déploiement, sans supprimer les exigences d’administration : espace disque surveillé, système maintenu et sauvegardes externes. Il n’existe pas ici de dimensionnement universel : les pièces jointes et le nombre d’utilisateurs influencent les besoins.

HTTPS n’est pas une finition facultative

Le Web Vault, l’interface web du coffre, nécessite un contexte sécurisé pour utiliser la Web Crypto API. Prévoyez donc un nom de domaine et un certificat TLS valide avant d’y importer vos identifiants. Un reverse proxy comme Traefik reçoit les connexions HTTPS puis les transmet au conteneur Vaultwarden.

Dans une architecture classique, le proxy gère les ports 80 et 443. Vaultwarden écoute sur le port 80 dans le conteneur ; un port local comme 8000 peut servir de relais si le proxy fonctionne sur l’hôte. Ne publiez pas ce relais directement sur Internet. Avec un proxy conteneurisé, préférez un réseau Docker partagé et correctement isolé.

Le proxy doit également transmettre les WebSockets, utilisés pour les notifications de synchronisation. Les anciens exemples mentionnent parfois le port 3012 : ne les recopiez pas sans vérifier la documentation actuelle. Une instance accessible uniquement par VPN reste possible, mais le VPN ne remplace pas le HTTPS nécessaire au coffre web.

Le volume persistant protège les données, pas contre les pannes

Les données doivent être montées dans /data à l’intérieur du conteneur, par exemple depuis /vw-data/ sur l’hôte. Sans stockage persistant, recréer un conteneur peut entraîner une perte de données. Ce volume n’est cependant pas une sauvegarde : une panne du disque ou une suppression accidentelle peut toujours le détruire.

Déployer Vaultwarden avec Docker Compose, étape par étape

L’image couramment utilisée est vaultwarden/server. Sélectionnez une version publiée et vérifiée plutôt que de laisser les mises à jour changer implicitement votre installation. Le dépôt GitHub dani-garcia/vaultwarden et son wiki servent de références pour les images, les paramètres et les exemples de proxy.

1. Préparez les répertoires. Créez le dossier du projet Compose et celui des données, puis limitez leurs permissions aux comptes nécessaires.
2. Déclarez le service. Dans compose.yaml, indiquez l’image retenue, une politique de redémarrage et le montage /vw-data:/data. SQLite convient comme base de départ.
3. Raccordez le réseau. Reliez le service au réseau du reverse proxy ou publiez uniquement sur l’interface locale, par exemple 127.0.0.1:8000:80.
4. Définissez les variables essentielles. Configurez le domaine public, les inscriptions et, si nécessaire, l’administration et le SMTP.
5. Démarrez et vérifiez. Exécutez docker compose up -d, consultez docker compose logs, puis ouvrez le domaine en HTTPS avant de créer les comptes.

La génération du hash Argon2 et son échappement dans Compose doivent suivre les instructions du projet : les caractères dollar peuvent notamment être interprétés par Compose. Ne stockez pas vos secrets dans un dépôt public. Testez aussi un véritable envoi SMTP, car une configuration enregistrée ne garantit pas la réception des invitations.

Connecter les utilisateurs sans ouvrir inutilement l’instance

L’interface située au chemin /admin sert à administrer l’instance lorsque ADMIN_TOKEN est configuré. Son accès doit être restreint, idéalement par le réseau ou le reverse proxy. Le jeton administrateur n’est pas le mot de passe principal d’un utilisateur et ne permet pas, à lui seul, de déchiffrer ses coffres.

Dans chaque client Bitwarden, choisissez l’environnement auto-hébergé avant la connexion, puis renseignez l’adresse HTTPS de Vaultwarden. Créez un élément de test depuis un appareil et vérifiez sa présence sur un autre. En cas d’échec, contrôlez d’abord l’adresse du serveur, le certificat et les journaux du proxy.

Pour partager des identifiants, utilisez une organisation et des collections plutôt qu’un compte commun. Attribuez les accès nécessaires à chacun, puis testez avec un utilisateur non administrateur. Désactiver les inscriptions ne suffit pas à définir une politique d’invitation : vérifiez séparément les paramètres correspondants.

Lors d’une migration, importez d’abord quelques éléments et vérifiez les champs, notes et pièces jointes. Les exports peuvent contenir des secrets en clair : limitez leur circulation et supprimez les copies temporaires après validation.

Prévoir la panne, la perte du mot de passe et les mises à jour

Le contenu du coffre est chiffré côté client. Cela ne dispense ni de sécuriser le serveur ni de choisir un mot de passe principal robuste. Activez le MFA et conservez ses codes de récupération hors du coffre concerné. Sans mécanisme de récupération préalablement configuré, oublier le mot de passe principal peut rendre les données inaccessibles ; le SMTP ne constitue pas un déchiffrement de secours.

Pensez aussi aux dépendances en boucle : si les seuls identifiants du serveur, du fournisseur DNS et du stockage de sauvegarde sont enfermés dans Vaultwarden, une panne peut bloquer sa propre réparation. Préparez une enveloppe de secours, physique ou numérique chiffrée, contenant les accès indispensables à la reprise, et conservez-la indépendamment de l’instance.

Sauvegardez la base, les pièces jointes et la configuration nécessaire à une reconstruction. Avec SQLite, utilisez une procédure de sauvegarde cohérente ou arrêtez proprement le service pendant la copie ; copier uniquement le fichier principal pendant des écritures peut être insuffisant. Chiffrez les sauvegardes et appliquez une stratégie 3-2-1 : trois copies, deux supports différents, dont une hors site.

Enfin, testez une restauration dans un environnement isolé. Avant chaque mise à jour, lisez les notes de version et réalisez une sauvegarde. Après le redémarrage, vérifiez connexion, synchronisation et pièces jointes. Revenir à une ancienne image peut nécessiter de restaurer aussi la base correspondante : la maintenance se prépare avant l’incident.

• À propos
• Articles récents

Laurent Faure

Les derniers articles par Laurent Faure (tout voir)

• Sous-traitance informatique : déléguer sans perdre la maîtrise des coûts et des données - 29 octobre 2026
• Hébergement Docker : le VPS coûte moins cher, mais qui gère les pannes ? - 28 octobre 2026
• Vaultwarden : un coffre léger à auto-héberger, pas une sécurité automatique - 26 octobre 2026

Articles qui pourraient vous intéresser :

Typosquattage : quand une simple faute de frappe menace vos identifiants Infogérance OVHcloud : clarifier les responsabilités et sécuriser la reprise Smart DNS pour le streaming : accès ciblé, vitesse préservée, confidentialité limitée Trouver le propriétaire d’une adresse IP : un fournisseur, pas forcément une personne