Vous lancez votre application. Vous avez une clé API Stripe. Une clé AWS. Un token SendGrid.
Première question : où les mettre ?
Dans le code ? Dans un fichier ? Dans une variable d'environnement ?
Voici comment faire ça bien, sans se compliquer la vie.
Pourquoi c'est important
Une clé API, c'est comme la clé de votre maison.
Elle donne accès à vos services. À votre base de données. À votre compte bancaire (via Stripe). À vos emails. À votre infrastructure.
Vous ne laissez pas traîner les clés de votre maison. Vous ne les publiez pas sur Facebook. Vous ne les envoyez pas par email à tout le monde.
Vos clés API, c'est pareil.
Bien les gérer = tranquillité d'esprit.
Vous savez où elles sont. Qui y a accès. Comment les changer si nécessaire.
Mal les gérer = stress permanent. "Est-ce que j'ai pushé ma clé sur GitHub ?" "Est-ce que mon ancien dev y a encore accès ?"
C'est pas compliqué. C'est juste une habitude à prendre.
Les 4 principes de base
### Principe 1 : Séparer code et secrets
Votre code est partagé. Versionné sur Git. Déployé sur des serveurs. Vu par toute l'équipe.
Vos secrets sont uniques. Par environnement (dev, staging, prod). Par personne. Jamais versionnés.
Règle simple : Si ça ressemble à une clé, ça ne va pas dans le code.
Pas de `const STRIPE_KEY = "sk_live_abc123"` dans votre fichier JavaScript.
Jamais.
### Principe 2 : Accès minimal
Chaque personne, chaque service n'a accès qu'à ce dont il a besoin.
Votre dev frontend n'a pas besoin de la clé AWS de production.
Votre script de backup n'a pas besoin d'accès en écriture à la base de données.
Votre stagiaire n'a pas besoin des clés de prod le premier jour.
Règle simple : Donnez le minimum. Ajoutez au besoin.
### Principe 3 : Rotation régulière
Vous changez le mot de passe de votre email tous les 6 mois ? (Vous devriez.)
Vos clés API, c'est pareil.
Pas besoin de les changer toutes les semaines. Mais une fois par trimestre, ou quand quelqu'un quitte l'équipe, c'est une bonne idée.
Règle simple : Calendrier. Tous les 3 mois, vous changez les clés principales.
### Principe 4 : Traçabilité
Qui a accédé à quelle clé ? Quand ? Pourquoi ?
Pas pour surveiller. Pour comprendre. Pour débugger. Pour savoir si quelque chose d'anormal se passe.
Règle simple : Logs d'accès activés. Vous ne les regardez jamais, sauf quand vous en avez besoin.
Les bonnes pratiques par contexte
### Vous développez seul
Solution : Variables d'environnement (.env)
Créez un fichier `.env` à la racine de votre projet :
``` STRIPE_SECRET_KEY=sk_test_abc123 DATABASE_URL=postgresql://user:pass@localhost/db SENDGRID_API_KEY=SG.xyz789 ```
Ajoutez `.env` à votre `.gitignore` :
``` .env .env.local .env.production ```
Dans votre code, utilisez les variables :
```javascript const stripeKey = process.env.STRIPE_SECRET_KEY; ```
Temps de setup : 5 minutes.
Coût : 0 $.
Avantages : Simple. Efficace. Fonctionne partout.
Documentation : Créez un fichier `.env.example` avec les clés (sans les valeurs) pour que les autres devs sachent quoi configurer.
``` STRIPE_SECRET_KEY= DATABASE_URL= SENDGRID_API_KEY= ```
### Vous travaillez en équipe
Solution : Gestionnaire de secrets partagé
Quand vous êtes 3, 5, 10 personnes, le fichier `.env` ne suffit plus.
Qui a la dernière version ? Comment partager une nouvelle clé ? Comment révoquer l'accès d'un dev qui quitte ?
Options :
1Password for Teams (recommandé pour PME) - 8 $/utilisateur/mois - Interface simple - Partage par vault - Accès révocable instantanément - Logs d'accès
Doppler (pour devs) - Gratuit jusqu'à 5 utilisateurs - CLI intégré - Sync automatique - Environnements multiples (dev/staging/prod)
AWS Secrets Manager (si vous êtes déjà sur AWS) - 0.40 $/secret/mois - Rotation automatique - Intégration native avec services AWS - Logs CloudWatch
Workflow : 1. Nouveau dev arrive → accès au vault "Development" 2. Dev senior → accès au vault "Production" 3. Dev quitte → révocation en 1 clic 4. Nouvelle clé → ajoutée au vault, tout le monde sync
Temps de setup : 30 minutes.
Coût : 40-80 $/mois pour une équipe de 5.
Avantages : Centralisé. Sécurisé. Auditable.
### Vous gérez une app en production
Solution : Secrets Manager cloud
En production, vous avez besoin de : - Rotation automatique - Haute disponibilité - Intégration avec votre infrastructure - Monitoring
AWS Secrets Manager
```bash # Créer un secret aws secretsmanager create-secret \ --name prod/stripe/secret-key \ --secret-string "sk_live_abc123"
# Récupérer dans votre app const secret = await secretsManager.getSecretValue({ SecretId: 'prod/stripe/secret-key' }).promise(); ```
Rotation automatique : Configurez une Lambda qui change la clé tous les 90 jours.
Google Cloud Secret Manager
Similaire, mais pour GCP. 0.06 $/10k accès.
Azure Key Vault
Similaire, mais pour Azure. 0.03 $/10k opérations.
Temps de setup : 1-2 heures (première fois).
Coût : 5-20 $/mois selon volume.
Avantages : Automatisé. Scalable. Intégré.
Ce que ça coûte vraiment
Parlons chiffres.
Faire n'importe quoi : 0 $ aujourd'hui. Risque demain.
Variables d'environnement (.env) : 0 $ + 5 minutes de setup.
1Password Teams : 8 $/utilisateur/mois. Pour 5 devs = 40 $/mois. Le prix de 4 cafés.
AWS Secrets Manager : 0.40 $/secret/mois. Pour 10 secrets = 4 $/mois.
Doppler : Gratuit jusqu'à 5 utilisateurs. 7 $/utilisateur/mois après.
HashiCorp Vault : 0 $ (self-hosted) ou 0.03 $/heure (cloud, ~22 $/mois).
ROI : - Temps gagné : plus de "où est la clé de prod ?" par Slack - Tranquillité d'esprit : vous savez où tout est - Onboarding rapide : nouveau dev opérationnel en 10 minutes - Offboarding sécurisé : révocation en 1 clic
C'est pas une dépense. C'est un investissement dans votre santé mentale.
Pour les business owners
Vous n'êtes pas dev. Mais vous devez comprendre les risques.
Questions à poser à votre équipe technique :
1. Où sont stockées nos clés API ?
Réponse acceptable : "Dans AWS Secrets Manager" ou "Dans 1Password" ou "Variables d'environnement sur le serveur".
Réponse inquiétante : "Euh... dans le code je crois ?" ou "Je sais pas".
2. Qui y a accès ?
Réponse acceptable : "Les 3 devs seniors. Liste documentée."
Réponse inquiétante : "Tout le monde" ou "Je sais pas exactement".
3. Quand ont-elles été changées la dernière fois ?
Réponse acceptable : "Il y a 2 mois" ou "Rotation automatique tous les 90 jours".
Réponse inquiétante : "Jamais" ou "Y'a 3 ans".
4. Que se passe-t-il si un dev quitte ?
Réponse acceptable : "On révoque son accès et on change les clés critiques dans les 24h".
Réponse inquiétante : "Rien de spécial" ou "On y pense pas vraiment".
5. Avons-nous un backup de nos secrets ?
Réponse acceptable : "Oui, dans un vault sécurisé, accessible par 2 personnes".
Réponse inquiétante : "Non" ou "C'est sur le laptop du dev".
Ces questions ne sont pas pour auditer. Elles sont pour comprendre et améliorer.
Si les réponses sont inquiétantes, c'est pas grave. C'est l'occasion de mettre en place les bonnes pratiques.
Checklist progressive
Vous voulez améliorer votre gestion de secrets ? Voici par où commencer.
Aujourd'hui (5 minutes) :
✓ Vérifiez que `.env` est dans votre `.gitignore` ✓ Cherchez "api_key" ou "secret" dans votre code versionné ✓ Listez toutes vos clés actuelles (Stripe, AWS, SendGrid, etc.)
Cette semaine (30 minutes) :
✓ Créez un fichier `.env.example` documenté ✓ Choisissez un gestionnaire de secrets (1Password, Doppler, AWS) ✓ Migrez vos 3 clés les plus critiques
Ce mois (2 heures) :
✓ Migrez toutes vos clés vers le gestionnaire ✓ Configurez la rotation automatique (si possible) ✓ Documentez le process pour l'équipe ✓ Formez les nouveaux devs
Ce trimestre (1 journée) :
✓ Auditez qui a accès à quoi ✓ Révoquez les accès inutiles ✓ Changez les clés qui n'ont jamais été changées ✓ Mettez en place un calendrier de rotation
Pas besoin de tout faire d'un coup. Progressez étape par étape.
Les erreurs à éviter
Erreur 1 : Clés hardcodées "juste pour tester"
"C'est temporaire, je vais le changer après."
Vous ne le changerez pas. Ça finira en prod. Utilisez `.env` dès le début.
Erreur 2 : Partager des clés par Slack/email
"Envoie-moi la clé Stripe par Slack."
Non. Utilisez un gestionnaire de secrets. Ou au minimum, un message qui s'auto-détruit.
Erreur 3 : Même clé pour dev et prod
"On utilise la même clé de test partout, c'est plus simple."
Jusqu'au jour où vous pushez du code de test en prod avec la vraie clé.
Environnements séparés = clés séparées.
Erreur 4 : Jamais changer les clés
"Ça marche, pourquoi changer ?"
Parce que des gens ont quitté. Parce que des laptops ont été perdus. Parce que c'est une bonne hygiène.
Erreur 5 : Pas de backup
"Toutes nos clés sont dans 1Password. Seul le CTO a le master password. Il est en vacances. On a perdu l'accès."
Backup. Toujours. Au moins 2 personnes doivent pouvoir accéder aux secrets critiques.
Ce que j'ai appris
J'ai vu des équipes gérer leurs secrets de toutes les façons possibles.
Ce qui marche : - Commencer simple (.env) - Évoluer quand nécessaire (gestionnaire) - Documenter le process - Former l'équipe - Réviser tous les 6 mois
Ce qui ne marche pas : - Systèmes trop complexes que personne n'utilise - Pas de documentation - "On verra plus tard" - Faire confiance à la mémoire
La gestion de secrets, c'est comme les backups. Vous vous en foutez jusqu'au jour où vous en avez besoin.
Mais contrairement aux backups, c'est facile à mettre en place. Ça prend 30 minutes. Et ça vous fait gagner des heures de stress.
La vérité finale
Gérer vos secrets correctement n'est pas compliqué.
C'est une habitude. Comme commiter régulièrement. Comme écrire des tests. Comme faire des backups.
Ça fait partie du métier.
Vous n'avez pas besoin d'un système parfait dès le jour 1. Vous avez besoin d'un système qui fonctionne et qui évolue avec vous.
Commencez par `.env` et `.gitignore`. Quand vous êtes 3, passez à 1Password. Quand vous scalez, passez à AWS Secrets Manager.
L'important, c'est de commencer. Aujourd'hui.
Vos clés API méritent autant d'attention que votre code. Traitez-les bien.