Demander et partager mots de passe et accès en toute sécurité
Demandez mots de passe, clés d'API et identifiants via un lien à usage unique, chiffré de bout en bout. Le serveur ne voit jamais le texte en clair.
Chiffré localement dans votre navigateur Lecture unique Sans compte Open source
Arrêtez de demander à vos clients d'envoyer leurs mots de passe par e-mail.
Trois façons dont Vault remplace les transmissions risquées que vous faites chaque semaine.
Demander des identifiants en toute sécurité
Générez un lien de demande à usage unique. Votre interlocuteur chiffre le secret avec une paire de clés qui n'existe que dans votre navigateur. Vous recevez du texte chiffré, jamais un mot de passe par e-mail.
Partager des secrets via un lien à usage unique
Chiffrez dans votre navigateur, partagez un lien qui s'autodétruit. La première lecture supprime définitivement le secret côté serveur. Aucune copie ne traîne dans les boîtes mail ni dans l'historique des conversations.
Vérifier le code et le déploiement
Chaque ligne de cryptographie est publiée sous AGPL-3.0 sur un miroir public. La page d'état expose le SHA du commit déployé ainsi que le SHA-256 du bundle navigateur, que vous pouvez recalculer vous-même.
Des secrets pour les agents IA : vault-ask
Votre agent de code a besoin d'une clé d'API ou d'un mot de passe de base de données ? Avec vault-ask, vous saisissez la valeur dans votre navigateur, et elle ne part que vers la seule commande que vous avez vue. Par CLI ou serveur MCP, liée à son usage et masquée dans la sortie, pour qu'elle n'apparaisse jamais dans le chat ni dans le journal de session.
Le chiffrement et le déchiffrement se font dans votre navigateur via l'API WebCrypto native. La clé vit dans le fragment de l'URL et ne nous parvient jamais.
Structurellement, il n'existe aucun texte en clair que nous puissions divulguer, remettre sur réquisition ou perdre.
AES-256 Chiffrement authentifié GCM
X25519 Échange de clés par demande
0 Octet de texte en clair sur le serveur
Demandez un secret sans jamais le voir en clair
C'est le flux de demande qui distingue Vault. Ne demandez plus à vos clients de vous envoyer leurs mots de passe par e-mail ou sur Slack.
Créez la demande
Votre navigateur génère localement une paire de clés X25519. La clé privée ne quitte jamais votre appareil.
Partagez le lien de demande
Envoyez le lien à la personne qui détient les identifiants. E-mail, messagerie, ou même sur papier : le serveur ne voit jamais la clé.
Elle transmet le secret
Son navigateur chiffre le secret avec votre clé publique et n'envoie que du texte chiffré.
Vous le récupérez chiffré
Ouvrez votre lien de récupération. Votre navigateur déchiffre localement. Exposition du texte en clair côté serveur : zéro.
Toute la demande en vingt secondes
Créez le lien de demande, l'autre personne dépose son secret, vous le récupérez une seule fois. Enregistré sur vault.erseni.com d'une seule traite ; l'interface de la vidéo est en allemand.
À quoi ça ressemble
Trois étapes. Aucun compte. Aucun texte en clair sur le serveur.
Conçu pour les vraies transmissions d'identifiants
Le flux qui protège un mot de passe ponctuel protège aussi chaque transmission d'identifiants récurrente de votre quotidien.
Les agences qui collectent les accès de leurs clients
Envoyez un seul lien de demande au lieu de relancer le client sur trois fils d'e-mails. Rien n'atterrit en clair dans votre boîte mail.
Les développeurs qui partagent des clés d'API
Transmettez une clé Stripe, un PAT GitHub ou un identifiant AWS sans en laisser de copie dans Slack ou dans l'historique Git.
Le support qui reçoit des données sensibles
Vos clients envoient codes de secours 2FA, pièces d'identité ou clés de licence via un lien à usage unique plutôt que par ticket.
Les indépendants qui intègrent de nouveaux clients
Collectez les accès aux systèmes historiques que votre client ne peut pas passer en SSO. Chiffré dans son navigateur, déchiffré dans le vôtre.
Les accès temporaires en DevOps
Transmettez à un collègue un accès de production éphémère pendant un incident. Le lien expire, aucun nettoyage oublié.
Les équipes internes qui partagent des secrets
Ne collez plus de mots de passe dans des documents partagés. Un lien à usage unique, supprimé définitivement après la première lecture, compatible avec vos exigences d'audit.
La première lecture réussie supprime définitivement l'enregistrement côté serveur, avant même que la réponse ne quitte la machine. Aucune copie ne reste dans les boîtes mail ni dans l'historique des conversations, et les sauvegardes des serveurs ne contiennent au plus que du texte chiffré illisible, jusqu'à leur écrasement au bout de 7 jours.
Rouvrez le même lien et vous n'obtiendrez qu'un « expiré ».
Construit à ciel ouvert, vérifiable de bout en bout
Six propriétés que nous nous imposons. Chacune est vérifiable dans le code source public.
Zero-knowledge par conception
Le serveur ne stocke votre secret que sous forme chiffrée. La clé de déchiffrement vit dans le fragment de l'URL et ne nous parvient jamais.
Chiffrement côté navigateur
AES-GCM-256 et X25519 s'exécutent via l'API WebCrypto native du navigateur. Aucune bibliothèque cryptographique tierce, aucun texte en clair sur le réseau.
Séparation de la clé dans le fragment d'URL
Les navigateurs n'envoient jamais la partie située après le # dans les requêtes HTTP. Nous y plaçons la clé volontairement, afin que le serveur soit structurellement incapable de la voir.
Open source, miroir public
Chaque ligne qui traite votre secret est sous licence AGPL-3.0 et publiée sur un miroir GitLab public. Lisez-la, forkez-la, hébergez-la vous-même.
Vérification du build déployé
La page d'état expose le commit de l'application, celui du composant, celui du miroir et le SHA-256 du bundle livré à votre navigateur.
Limites documentées
Nous listons ce contre quoi cette architecture ne protège pas, y compris le risque lié à la livraison du JavaScript et la fuite de métadonnées. Aucune promesse de sécurité absolue.
Pourquoi ne pas simplement utiliser OneTimeSecret, Password Pusher, PrivateBin ou Bitwarden Send ?
Sur la base de la documentation publique et du code source à la date de publication. Chaque outil optimise pour un modèle de menace différent. Cette comparaison porte sur la transmission d'identifiants à usage unique depuis le navigateur.
Une limite que nous nommons nous-mêmes : une note facultative que vous attachez à un secret dans le tableau de bord est stockée en clair. Le secret lui-même reste illisible pour nous.
Sources
Chaque affirmation est vérifiable auprès de la source liée du concurrent. Si une valeur n'est plus à jour, ouvrez un ticket sur le miroir public et nous corrigerons le tableau.
OneTimeSecret (GitHub) Chiffrement côté serveur avec une clé détenue par le serveur ; la phrase secrète optionnelle n'est pas la voie par défaut. Incoming Secrets (version 0.26.0 du 19/07/2026) est une page de dépôt sur un domaine propre vérifié par DNS : ce n'est donc pas une demande ciblée auprès d'une personne, et elle exige un compte du côté de celui qui collecte ; l'envoi fonctionne sans compte. Open source et auto-hébergeable. Pour le chiffrement côté serveur, nous suivons la description du projet ; nous ne l'avons pas vérifiée dans son code source.
Password Pusher (GitHub) Chiffrement côté serveur avec une clé détenue par le serveur ; pas de zero-knowledge par conception. Propose une fonctionnalité de demandes entrantes, mais les envois utilisent la même clé détenue par le serveur : le flux de demande n'est donc pas zero-knowledge. Sous licence Apache-2.0, auto-hébergeable, aucun compte requis.
PrivateBin (GitHub) Chiffrement AES-GCM dans le navigateur avec la clé dans le fragment de l'URL, le serveur ne stocke que du texte chiffré. Licence Zlib, auto-hébergeable, sans compte.
Bitwarden Send FAQ Chiffré côté serveur avec une clé dérivée du compte ; les destinataires utilisent un lien à usage unique. La fonctionnalité Send exige un compte expéditeur. Le serveur est sous AGPL-3.0 ; le client officiel et les applications sont distribués sous une licence propriétaire comportant des composants fermés, d'où la mention « partiel » pour l'open source.
Vérifiez notre code
La confiance se gagne par la vérifiabilité. Le backend et la cryptographie du navigateur sont publiés sous licence AGPL-3.0.
Code source : gitlab.erseni.net/open-source/secrets-component
Modèle de menace : docs/architecture.md
Build actuel : page d'état indique le SHA du commit déployé. Comparez-le au miroir public pour vérifier.
Tarifs
Utilisation gratuite, sans limite de volume. Aucun compte. Aucun traçage. Aucune publicité.
Business est disponible dès maintenant, et vous pouvez inviter des membres de votre équipe. Des questions ? Écrivez à hello@erseni.com.
Partagez votre prochain secret de la bonne façon
Aucun compte, aucun texte en clair, aucune trace. Chiffré de bout en bout dans votre navigateur et détruit à la première lecture.