Un modèle d’exemple existe. Le build du front lit le même fichier
Secrets du monitoring (Cloudflare)
Jetons d’accès, clé maître du coffre
Posés depuis la console Cloudflare ou en ligne de commande. Les réglages publics du fichier de configuration ne sont pas secrets
Coffre à clés (base du monitoring)
Clés des fournisseurs de renseignement
Chiffré avec la clé maître du coffre, géré depuis l’admin du backend
Tableau de bord Pages (site vitrine)
Réglages publics au build, mot de passe d’aperçu et interrupteur de la barrière à l’exécution
Les réglages publics finissent dans le code servi : aucun n’est secret
Fichiers locaux de développement
Valeurs de développement
Ignorés par git
Stripe, DocuSign, Sentry, Slack, Cloudflare
Émetteurs
À renouveler dans leur console
Les noms exacts des secrets, par dépôt, sont dans le tableau « Correspondance technique » en bas de page. Fournisseurs du coffre à clés : Shodan, Intelligence X, AbuseIPDB, GreyNoise, Google Web Risk, ProjectDiscovery Chaos, CertSpotter, HackerTarget, GitHub, NVD, SecurityTrails, ransomware.live PRO.
Jeton du backend vers le monitoring : changez le jeton des deux côtés en même temps. Les appels sont refusés (erreur 401) entre les deux changements. L’adresse de la notification automatique de Shodan dérive de ce jeton. L’ancienne adresse cesse de marcher aussitôt ; la tâche planifiée de 02:15 UTC supprime l’ancienne alerte Shodan et enregistre la nouvelle adresse, donc les appels de Shodan sont perdus jusque-là.
Jeton du scanner : mettez d’abord le jeton du monitoring à l’ancienne valeur du jeton du scanner (l’interface se rabat sur ce dernier tant que le premier n’est pas défini), puis renouvelez le jeton du scanner. Les jetons par nœud se créent, se révoquent et se renouvellent depuis l’admin Monitoring (journalisé).
Clé d’un fournisseur de renseignement : dans la page des clés d’API de l’admin Monitoring, ajoutez la nouvelle clé (libellé, secret, priorité), choisissez la stratégie (solution de repli, tourniquet ou épuisement de quota), puis désactivez ou supprimez l’ancienne. Chaque action est auditée par le monitoring. Révéler une clé exige le mot de passe de l’admin et est limité à 10 par minute. Un fournisseur désactivé dans l’admin ne se rabat pas sur le secret Cloudflare.
Clés d’authentification du serveur MCP : un commentaire dans le workflow de tests dit de ne jamais ajouter l’option de régénération forcée à la CI, car cela renouvellerait les vraies clés. Rien ne l’impose.
Clé maître du coffre : le code ne prévoit aucune rotation. La changer rend toutes les clés stockées illisibles ; il faut les ressaisir.
Secret des notifications Stripe : régénérez-le dans Stripe, mettez à jour le fichier de configuration, redémarrez les programmes en arrière-plan. Sans lui, en production, le point d’accès des notifications répond par une erreur 500.
Clé principale de l’application : les liens signés (magic links, adresses de paiement) sont vérifiés avec la clé principale puis avec chaque ancienne clé listée à part. Mettez l’ancienne clé dans cette liste pour garder valides les liens déjà envoyés ; sans cela ils cassent.
DocuSign, Pappers, CBE, OpenAI, Slack, Sentry : renouvelez chez l’émetteur, puis dans le fichier de configuration.
L’ancien dossier de docs contient un fichier nommé pour des clés d’API à supprimer (non ouvert ici). Supprimez-le et décidez si les clés qu’il liste doivent être renouvelées ; cette décision n’est pas prise.
Le fichier d’exemple déclare deux fois l’identifiant de compte Cloudflare : un seul compte sert aux deux.
Barrière d’aperçu du site vitrine : désactivée sauf si son interrupteur est activé. Quand elle l’est et que le mot de passe d’aperçu est absent ou vide, le site se rabat sur un mot de passe par défaut écrit dans la source. Définissez le mot de passe avant d’activer la barrière.
APP_KEY (signe aussi les magic links et les URL de succès de paiement ; APP_PREVIOUS_KEYS, séparées par des virgules et absentes de .env.example, garde les anciennes signatures valides), DB_PASSWORD, REDIS_PASSWORD, AWS_SECRET_ACCESS_KEY
MONITORING_API_TOKEN, SCANNER_TOKEN, KEY_VAULT_KEY, SHODAN_API_KEY, ABUSEIPDB_API_KEY, INTELX_API_KEY, GITHUB_TOKEN, CLOUDFLARE_API_TOKEN. TURNSTILE_SECRET_KEY est déclarée dans worker-configuration.d.ts mais rien dans src ne la lit
Landing
PREVIEW_PASSWORD. Le cookie ne stocke qu’une empreinte SHA-256 du mot de passe
