Pourquoi mon agent IA ne connaît aucun de mes mots de passe

Mon agent IA travaille la nuit. Pendant que je dors, il rédige des articles, envoie des rapports, interroge des API, publie. Pour faire tout ça, il lui faut des clés : des jetons d'accès, des mots de passe d'application, des identifiants de service. Et pendant longtemps, je les ai rangés n'importe comment.

Avoue : toi aussi, tu as déjà collé une clé API en clair dans un fichier de config « en attendant de faire propre ». Ce fichier attend toujours. Cet article, c'est le « propre ». On va brancher l'agent sur un coffre-fort auto-hébergé, et tu vas voir que c'est plus sûr, pas plus compliqué.

Le problème : l'agent éparpille tes clés

Un agent qui agit a besoin d'accès. Publier sur un blog, prévenir sur une messagerie, lire une boîte mail, appeler un service de génération d'images. Chaque service a son jeton.

La méthode du bricoleur, c'est de coller chaque clé dans le fichier de configuration de l'outil concerné. Résultat : un fichier par outil, des copies dans chaque sauvegarde, des fragments dans les logs, et parfois même la clé qui s'affiche dans la conversation quand l'agent explique ce qu'il fait. Une vraie passoire. Et le pire : pour changer une clé, il faut courir partout. J'ai vécu ça avec mes tâches planifiées de nuit, des « crons », des réveils qui lancent une commande toute seule à heure fixe. Chaque tâche avait besoin d'un identifiant différent, et ils vivaient dans trois endroits distincts. Rotation de clé ? Journée perdue.

L'idée : un seul coffre, un seul point de passage

Un coffre-fort de mots de passe, tu connais : c'est le gestionnaire qui garde tous tes identifiants chiffrés derrière un seul mot de passe maître. Vaultwarden, c'est la version libre de ce serveur que tu héberges chez toi, j'avais déjà raconté son installation ici même.

Le principe du branchement : tes clés d'agent vivent dans le coffre, et l'agent va y puiser à chaque démarrage. Plus aucune clé dans un fichier de config. Un seul endroit pour changer un mot de passe, et il se propage partout au redémarrage suivant. Un seul endroit pour révoquer, et tout l'agent perd l'accès d'un coup.

Le principe avant les commandes

Avant de sortir le terminal, il faut comprendre qui demande quoi à qui.

Quand l'agent démarre, il ne demande pas le mot de passe à l'humain. Il le demande au coffre, par l'intermédiaire d'un petit pont : une commande qui répond en quelques secondes, sans jamais poser de question, et qui imprime les paires nom=valeur des secrets. L'agent remplit ensuite sa « variable d'environnement », la poche de mémoire que chaque programme remplit au démarrage et où il va chercher ses réglages sensibles.

Le mot de passe maître, lui, reste dans ta tête. L'agent ne le connaît pas et ne le connaîtra jamais : le coffre est déverrouillé avec une clé de session temporaire, et l'agent ne voit que les clés d'API que tu as décidé de lui mettre à disposition. Pas le contenu entier du coffre.

Mon agent s'appelle Hermes et prévoit exactement ce cas de figure : trois façons de brancher un coffre au démarrage. Bitwarden Secrets Manager (la version hébergée officielle), 1Password, et le « command helper », un pont générique qui accepte n'importe quel coffre équipé d'une CLI, un programme en ligne de commande. Comme Vaultwarden. C'est cette troisième voie qu'on détaille ici.

Source : schéma réalisé par la rédaction (illustration, pas une capture de l'outil).

La mise en place pas à pas

Quatre étapes, et à chaque fois je te dis ce que ça fait avant de te montrer.

Étape 1 : ranger le coffre

Dans ton coffre, crée un item par clé, et donne-lui exactement le nom de la variable que l'agent attend. Si le service de publication s'attend à trouver CLE_API_BLOG, l'item s'appelle CLE_API_BLOG. Pas « cle api blog », pas « cle_api_blog ». C'est la convention du pont : il imprime nom=valeur, et l'agent associe par le nom exact. Un tiret là où il fallait un underscore, et rien ne marche, sans message d'erreur, parce que pour le système, un nom inconnu n'est pas une erreur, c'est juste une variable qu'il n'a pas.

Étape 2 : installer la CLI du coffre

Sur la machine qui fait tourner l'agent, installe bw, le client en ligne de commande de Bitwarden, et connecte-le à ton serveur auto-hébergé. Deux détails qui font gagner une soirée : prendre la version standalone (la version installée via npm casse sur certains systèmes à cause d'un bug de chiffrement), et s'authentifier avec une clé API dédiée, bw login --apikey, plutôt qu'avec le mot de passe maître, qu'on ne copie nulle part.

Étape 3 : écrire le pont

Le pont, c'est un script de quelques lignes. Sa mission : déverrouiller le coffre avec la clé de session, puis imprimer les paires nom=valeur sur la sortie standard. Rien d'autre.

#!/bin/bash
# pont-coffre.sh : imprime les secrets sous forme NOM=valeur
BW_SESSION=$(cat ~/.config/hermes/bw-session)
export BW_SESSION
bw list items | jq -r '.data[] | "\(.name)=\(.login.password)"'

Deux règles d'or pour ce script : il doit être rapide (l'agent lui impose un délai serré, quelques secondes), et il doit marcher sans aucune interaction, pas de question, pas de demande de déverrouillage à l'écran. Si le coffre est verrouillé, c'est ton script qui gère, pas l'agent.

Étape 4 : brancher l'agent

Dans la configuration de l'agent (le fichier config.yaml, qui contient les réglages et jamais les secrets), on déclare le pont :

secrets:
  command:
    enabled: true
    command: "/home/toi/.local/bin/pont-coffre.sh"
    helper_timeout_seconds: 8
    override_existing: true

Ligne par ligne : on active la source, on indique la commande à lancer, on lui laisse 8 secondes (le défaut de 3 est très serré, un coffre sur un petit serveur peut être plus lent), et on demande au coffre d'écraser les valeurs déjà présentes. Ce dernier point compte : par défaut, une valeur déjà écrite en local gagne, et ta rotation dans le coffre ne s'applique jamais. Avec override_existing à true, le coffre devient la source de vérité.

Au démarrage suivant, l'agent lance le pont une seule fois, lit la sortie comme un fichier de configuration, et remplit sa poche de mémoire. Si le pont échoue, le démarrage continue quand même avec les clés déjà en local. Le coffre enrichit, il ne bloque jamais.

Le test qui prouve que ça marche

On redémarre, et on demande à l'agent une action qui a besoin d'une clé : publier un brouillon, envoyer un message via une API, ce que tu veux.

Ce qui doit se passer : l'action réussit, sans que tu aies tapé quoi que ce soit. La valeur du secret n'apparaît ni dans la réponse, ni dans les logs. C'est voulu : la sortie d'erreurs du pont est carrément jetée par l'agent, parce que les diagnostics des clients de coffres peuvent contenir du matériel sensible. Et le coffre, de son côté, te permet de vérifier que la consultation a bien eu lieu.

Mon test de référence : je liste les clés que l'agent a détectées, et chaque valeur porte une étiquette d'origine qui dit d'où elle vient. Une clé qui vient du pont est affichée comme venant d'une source de secrets. Plus aucune clé « anonyme » dans la config.

Les pièges que j'ai rencontrés pour de vrai

Le jeton mal nommé. L'agent cherche CLE_API_BLOG, ton item s'appelle cle-api-blog : silence radio, sans erreur. Le nom de l'item est le nom de la variable, point.

L'écran devant le coffre. J'ai mis l'interface web de mon coffre derrière un écran de connexion (Cloudflare Access). Bon réflexe pour les humains, piège pour la CLI : l'écran bloquait aussi le client en ligne de commande, avec une erreur 403 qu'on confond facilement avec « mauvais identifiant ». La règle : l'écran doit laisser passer les chemins techniques que la CLI utilise, pas seulement la jolie interface.

La session qui boucle. Relancer un déverrouillage alors que le précédent n'a pas fini de provisionner ses clés, et la connexion tourne en boucle. On attend la fin complète du premier déverrouillage avant de retenter. Patience, une minute.

Le mode d'approbation. Si ton agent demande une confirmation humaine pour chaque commande exécutée, tes tâches de nuit attendent un « oui » qui ne viendra jamais. Les commandes de confiance (comme le pont) doivent être autorisées explicitement.

L'override oublié. Tu tournes une clé dans le coffre, tu redémarres, rien ne change. Normal : sans override_existing à true, l'ancienne valeur locale gagne. Le symptôme est déroutant, le correctif tient en une ligne.

Les limites

Soyons honnêtes, parce que la sécurité qui raconte des mensonges flatteurs n'en est pas.

L'agent voit les secrets en clair dans sa poche mémoire quand il les utilise. C'est le contrat : pour appeler une API, il faut bien la clé en clair à un moment. Ce que le coffre élimine, c'est le reste, les clés qui traînent dans les fichiers, les sauvegardes, les conversations. Le coffre déverrouillé sur la machine, ça reste un coffre accessible à qui tient la machine. La protection, c'est l'endroit où vivent les choses, pas une magie.

Vaultwarden est un projet communautaire indépendant, pas un produit de la société Bitwarden. Le dépôt officiel le dit clairement, recommande des sauvegardes régulières et oriente le support vers sa communauté. C'est un outil formidable, massivement utilisé, mais il faut le savoir.

Le pont générique est POSIX : il repose sur /bin/sh, donc pas de pont de ce type sous Windows.

Et pour un usage d'équipe, la voie propre est l'alternative hébergée : Bitwarden Secrets Manager, que mon agent intègre nativement, avec un assistant de configuration, des comptes machines dédiés sans 2FA, la rotation centralisée et un cache chiffré en option. Le pont maison reste parfait pour une machine perso ; pour partager des secrets entre plusieurs agents et plusieurs humains, la version hébergée fait le travail sans bricolage.

Ce que ça change au quotidien

Changer une clé : un seul endroit, le coffre. Le redémarrage suivant, tout suit.

Révoquer l'accès d'un agent : une rotation de la clé API du coffre dans l'interface, et c'est tout l'agent qui est coupé d'un coup, plus besoin de chasser les fichiers.

Et le mot de passe maître ? Toujours dans ma tête. Mon agent connaît mes mots de passe. Moi, je n'ai jamais eu à lui dire.

Sources

Documentation Hermes Agent, page Secrets : les trois sources supportées et l'architecture « bootstrap token ».

Documentation Hermes Agent, page Command helper : le pont générique KEY=VALUE, les délais et le modèle de sécurité.

Documentation Hermes Agent, page Bitwarden Secrets Manager : l'alternative hébergée avec assistant de configuration.

Bitwarden, authentification CLI par clé API : le login sans mot de passe maître.

Dépôt officiel Vaultwarden : le projet, sa licence AGPL-3.0 et ses recommandations.

Selfhostr, Vaultwarden vs Bitwarden vs Passbolt (2026) : comparatif francophone des coffres auto-hébergés.

À lire aussi

Héberger son gestionnaire de mots de passe avec Vaultwarden : l'installation du coffre, l'étape d'avant.

mem0, Honcho ou co-engram : où ranger la mémoire de son agent IA : ce que l'agent retient, une fois qu'il a ses clés.

OpenBao, le gestionnaire de secrets open source : l'alternative orientée infrastructure.

—

Recherche, relecture et illustration assistées par IA. Le contenu reflète le travail éditorial de la rédaction.