Gérer ses secrets proprement

Un secret commité par erreur, et c'est la clé de ta base ou de Stripe sur GitHub pour toujours. Voici où les secrets doivent vivre, comment les injecter selon l'environnement, et quoi faire quand l'un fuit.

Stack.envSecrets ManagerCI variablesrotationgit

La règle d’or

Un secret ne vit jamais dans le code, ni dans le dépôt git. Il vit dans l'environnement, injecté au moment de l'exécution. Le code lit process.env ; il ne connaît jamais la valeur.

.gitignoreBASHCopier

# .gitignore — la premiere ligne de defense
.env
.env.local
.env*.local
# et si un secret a DEJA ete commite : le retirer de l'historique
# (git rm --cached + git filter-repo) ET le faire tourner immediatement

Attention

Un .env commité une fois reste dans l'historique git à jamais, même supprimé ensuite. Le seul vrai correctif : faire tourner (révoquer + régénérer) le secret exposé.

Où ils vivent, par environnement

local.env.local, gitignoré, jamais partagé par git

CIvariables masquées dans GitLab/GitHub, pas dans le YAML

prod (managé)variables d’env de Vercel / Amplify

prod (AWS)Secrets Manager ou SSM Parameter Store

À retenir

Les variables CI/CD masquées sont exactement celles de bien utiliser GitLab CI/CD.

Les lire proprement

Deux réflexes : ne jamais mettre un secret dans une variable NEXT_PUBLIC_ (elle finit dans le bundle client), et valider la présence des secrets au démarrage plutôt que de découvrir qu'il en manque un en pleine requête prod.

config.tsTSCopier

// on lit les secrets via process.env, jamais en dur dans le code
const stripe = new Stripe(process.env.STRIPE_SECRET_KEY);
// valider leur presence au boot : mieux vaut crasher au demarrage
// qu'a la premiere requete en prod
["STRIPE_SECRET_KEY", "DATABASE_URL"].forEach((k) => {
  if (!process.env[k]) throw new Error(`Missing env var: ${k}`);
});

À retenir

La frontière NEXT_PUBLIC_ est le même piège que dans les failles de sécurité de base sur Next.js.

Rotation & fuite

·fais tourner les secrets régulièrement, et immédiatement dès qu'un doute existe ;

·un secret par environnement : la clé de staging n'est pas celle de prod ;

·un scan de secrets en CI (gitleaks) pour attraper une fuite avant le merge ;

·en cas de fuite : révoquer d'abord, enquêter ensuite. L'ordre compte.

Sources & ressources

01OWASP — Secrets Management Cheat SheetLe cadre général : stockage centralisé, cycle de vie, rotation automatisée, réponse à incident.↗02Next.js — How to use environment variablesOrdre de chargement des .env et pourquoi une variable NEXT_PUBLIC_ est inlinée dans le bundle client au build.↗03GitHub Docs — Removing sensitive data from a repositoryLa procédure officielle : révoquer/faire tourner le secret d'abord, réécrire l'historique avec git filter-repo ensuite.↗04gitleaks — Secret detection for git reposL'outil à brancher en CI ou en pre-commit pour attraper une clé avant le merge.↗05AWS — Rotate AWS Secrets Manager secretsRotation automatique planifiée, avec intégrations natives pour les bases de données.↗06AWS — Systems Manager Parameter StoreSecureString chiffré par KMS, hiérarchies de paramètres, IAM — l'alternative moins chère quand la rotation n'est pas requise.↗07Vercel — Sensitive environment variablesVariables non relisibles après création, redaction dans les logs de build, politique d'équipe.↗

En résumé

Gérer ses secrets, c'est une discipline simple : hors du code, hors de git, injectés par l'environnement, validés au boot, et tournés sans hésiter. Un scan en CI comme filet, et la clé de ta base ne finira jamais dans un dépôt public.

AWS — Secrets Manager ↗

À lire ensuite

Guide

Coder un SaaS en 24h avec Claude Code

Du repo vide au produit en ligne en une journée : le plan, les raccourcis, et ce qui casse quand on va trop vite.

Technique

Les erreurs courantes avec Claude Code

Méga-prompts, pas de CLAUDE.md, jamais de tests, aucun commit : les pièges qui transforment l'agent en boulet.

Guide

Bien utiliser GitLab CI/CD

Un pipeline propre de bout en bout : stages, cache, artefacts, environnements et déploiement automatique.