Secrets management dans une équipe de 4: notre setup sans Vault ni AWS Secrets Manager

Le premier réflexe quand on cherche "secrets management" : HashiCorp Vault. Le second réflexe : voir qu'il faut un serveur dédié, une politique d'accès, une PKI, et un opérateur qui sait ce qu'il fait. Pour une équipe de 4 développeurs sur des projets clients de taille intermédiaire, c'est disproportionné.

L'autre extrême, les .env dans un channel Slack, on l'a vécu. Un collaborateur qui quitte l'équipe avec un .env de production dans sa messagerie, c'est un risque qu'on a décidé d'éliminer.

Voici ce qu'on a mis en place concrètement.

Le problème qu'on résout

Quatre types de secrets circulent dans un projet web :

• Variables d'environnement de développement (API keys sandbox, URLs locales, credentials de base de données de dev)
• Variables d'environnement de staging et production
• Secrets de déploiement CI/CD (tokens Docker, accès cloud)
• Credentials partagés ponctuels (accès admin client, identifiants de services tiers)

Chaque type a des besoins différents : qui y accède, avec quelle fréquence, quel niveau de rotation, quelle auditabilité.

Doppler pour les variables d'environnement

Doppler est un gestionnaire de secrets SaaS. Il stocke les variables d'environnement par projet et par environnement (dev, staging, production), avec un contrôle d'accès par membre et un historique des modifications.

L'intégration dans le workflow de dev est simple :

# Installation
brew install dopplerhq/cli/doppler

# Authentification
doppler login

# Sélection du projet
doppler setup

# Lancement de l'app avec injection des secrets
doppler run -- npm run dev

doppler run injecte les variables dans l'environnement du processus sans les écrire sur le disque. Aucun fichier .env ne circule. Quand un développeur quitte l'équipe, on révoque son accès dans Doppler : les variables ne sont plus accessibles depuis sa machine.

Pour le CI/CD (GitHub Actions), on utilise le Doppler Service Token :

- name: Load secrets
  uses: dopplerhq/[email protected]
  with:
    doppler-token: ${{ secrets.DOPPLER_TOKEN }}

Le DOPPLER_TOKEN est le seul secret stocké dans GitHub Actions. Il donne accès à l'environnement correspondant (staging pour la branche main, production pour les tags).

Limite principale : Doppler est un service tiers. Si Doppler est indisponible, le déploiement est bloqué. On maintient un fallback : les variables de production sont aussi stockées chiffrées dans un vault 1Password d'équipe, utilisable manuellement en cas de nécessité.

SOPS pour les secrets de déploiement versionnés

Certains secrets doivent vivre dans le dépôt : configurations Terraform, fichiers Helm, variables Kubernetes. On ne peut pas les mettre en clair dans Git.

SOPS (Secrets OPerationS, de Mozilla) chiffre des fichiers YAML/JSON/ENV tout en laissant les clés en clair. On peut voir quelles variables existent et les diff Git restent lisibles, seules les valeurs sont chiffrées.

Exemple de fichier .env.prod.enc.yaml tel qu'il apparaît dans Git :

DATABASE_URL: ENC[AES256_GCM,data:xyz123...,type:str]
STRIPE_SECRET_KEY: ENC[AES256_GCM,data:abc456...,type:str]
sops:
    kms:
    -   arn: arn:aws:kms:eu-west-3:123456789:key/mrk-abc...
    lastmodified: '2026-01-19T09:00:00Z'
    version: 3.8.1

On utilise AWS KMS comme backend de chiffrement. La clé KMS est gérée par IAM : seuls les rôles autorisés peuvent chiffrer et déchiffrer. En pratique, les développeurs ont accès via leurs credentials AWS personnels (gérés par AWS SSO), et le CI/CD via un rôle IAM dédié.

# Chiffrer un fichier
sops --encrypt --kms arn:aws:kms:eu-west-3:... .env.prod.yaml > .env.prod.enc.yaml

# Éditer un fichier chiffré (ouvre l'éditeur avec les valeurs en clair)
sops .env.prod.enc.yaml

# Déchiffrer pour un déploiement
sops --decrypt .env.prod.enc.yaml > .env.prod.yaml

1Password CLI pour les credentials ponctuels

Pour les credentials qui ne rentrent pas dans les deux catégories précédentes, accès admin d'un client, identifiants d'un service utilisé une fois par mois, on utilise 1Password Teams avec la CLI op.

# Récupérer un secret dans un script
export ADMIN_PASSWORD=$(op read "op://Apogée/Client X Admin/password")

# Lancer un processus avec injection de secrets 1Password
op run --env-file=.env.1password -- ./scripts/deploy.sh

L'avantage de op run est identique à doppler run : pas de fichier temporaire, pas de variable dans l'historique du shell.

Ce qu'on n'a pas fait et pourquoi

HashiCorp Vault : excellent outil, mais il nécessite un serveur à maintenir, une politique de renouvellement des tokens, et une connaissance opérationnelle que notre équipe n'a pas intérêt à construire pour la taille de nos projets.

AWS Secrets Manager seul : les coûts par secret (0,40$/secret/mois) et par appel API deviennent significatifs sur un grand nombre de secrets. Surtout, l'intégration dans le workflow de développement local est moins fluide que Doppler.

Fichiers .env chiffrés avec GPG : on l'a testé. La gestion des clés GPG dans une équipe est une source de friction constante (expiration, révocation, partage de la clé publique). SOPS avec KMS est plus robuste opérationnellement.

Ce qu'on surveille encore

La rotation automatique des secrets reste manuelle dans notre setup. Doppler supporte des webhooks pour notifier en cas de modification, mais on n'a pas encore automatisé la rotation périodique des clés API. Sur des projets avec des exigences de conformité (ISO 27001, SOC 2), c'est un gap.

Est-ce qu'une équipe qui grandit au-delà de 8-10 personnes doit investir dans Vault ou dans un service managé comme AWS Secrets Manager ? Probablement oui, à partir d'un certain seuil, la granularité des accès et l'audit trail justifient la complexité opérationnelle supplémentaire.