« Où est censé vivre le fichier .env d’un projet Bedrock quand plusieurs développeurs et plusieurs environnements se le partagent ? » Cette question, posée sur presque tous les projets qui grandissent, appelle rarement une réponse évidente. Bedrock structure déjà la configuration autour d’un fichier .env par environnement, mais rien dans cette structure ne dit comment le distribuer, le faire évoluer et le sécuriser en équipe.
Trois approches répondent à ce besoin avec des philosophies différentes : Doppler et Infisical, deux services de gestion de secrets avec une interface web et une CLI, et sops, un outil de chiffrement qui garde les secrets versionnés directement dans le dépôt de code, sous forme chiffrée.
Doppler : le confort d’un service géré
Doppler centralise les secrets dans un tableau de bord web, organisé par projet et par environnement, avec une CLI qui injecte les variables au moment de l’exécution sans jamais les écrire en clair sur le disque. Pour Bedrock, cela signifie remplacer la lecture du fichier .env par un appel doppler run -- wp server qui injecte les variables directement dans l’environnement du processus.
L’avantage principal est l’historique des modifications et la gestion fine des droits d’accès par environnement, utile quand plusieurs clients partagent la même équipe technique mais ne doivent pas voir les secrets des autres projets.
Infisical : une alternative ouverte, auto-hébergeable
Infisical propose une expérience proche de Doppler, avec une CLI et un tableau de bord équivalents, mais son code est ouvert et l’outil peut être auto-hébergé sur une infrastructure existante, ce qui répond à une contrainte fréquente pour une équipe qui refuse de confier ses secrets à un service tiers non contrôlé.
infisical run --env=production -- wp serverCette commande reproduit le même principe d’injection à l’exécution, avec en plus la possibilité de synchroniser les secrets vers des variables d’environnement de la plateforme de déploiement utilisée, réduisant la duplication manuelle entre outils.
sops : le choix du chiffrement versionné
sops prend le problème dans l’autre sens : plutôt que de sortir les secrets du dépôt vers un service externe, il les chiffre directement dans un fichier qui reste versionné avec le code, en s’appuyant sur une clé de chiffrement (souvent via age ou une clé GPG). Le fichier chiffré peut être committé sans risque, seule la clé de déchiffrement doit rester hors du dépôt.
sops --encrypt --age age1xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx .env > .env.enc
sops --decrypt .env.enc > .envComparatif selon budget et besoin d’auto-hébergement
| Critère | Doppler | Infisical | sops |
|---|---|---|---|
| Modèle | Service cloud géré | Cloud ou auto-hébergé | Fichier chiffré dans le dépôt |
| Coût pour une petite équipe | Offre gratuite limitée | Offre gratuite plus généreuse | Gratuit, coût nul |
| Interface de gestion | Tableau de bord complet | Tableau de bord complet | Aucune, en ligne de commande |
| Dépendance à un tiers | Totale | Optionnelle si auto-hébergé | Aucune |
Ce que chaque option implique pour Bedrock concrètement
- Doppler et Infisical remplacent l’usage direct du fichier
.envpar une injection à l’exécution, ce qui demande d’adapter les scripts de déploiement du projet. - sops garde le fichier
.envcomme point central, simplement chiffré, ce qui change moins les habitudes existantes d’une équipe déjà organisée autour de Bedrock. - Aucune des trois approches ne gère nativement la rotation automatique des identifiants, qui reste un sujet distinct à traiter séparément.
Le meilleur outil de gestion de secrets reste celui que l’équipe utilisera réellement à chaque déploiement, pas celui qui a le plus de fonctionnalités sur le papier.
Notre verdict
Pour une petite équipe ou un projet Bedrock unique, sops offre le meilleur rapport simplicité-coût, sans dépendance externe et sans budget récurrent. Une équipe qui gère plusieurs projets clients avec des droits d’accès à différencier tirera davantage profit de Doppler ou d’Infisical, ce dernier étant préférable dès que l’auto-hébergement est une contrainte imposée par le client ou par la politique interne de l’agence.
