Étape 5 · Mettre en ligne

`/pulse:secrets`

Les secrets du projet : inventaire sans aucune valeur, renouvellement sans coupure, réaction à une fuite de clé (révoquer d'abord) ; la valeur ne passe jamais par la conversation.

Description

Un secret (clé d'accès à un service, mot de passe, adresse de base de données avec son mot de passe) permet d'agir à votre place. Cette commande tient la liste de vos secrets dans docs/secrets.md, avec leurs noms et leurs dates, jamais leurs valeurs. Elle repère aussi ce qui manque : une clé absente chez l'hébergeur, un fichier de clés mal protégé.

Elle sait changer une clé sans couper le site : la nouvelle serrure d'abord, l'ancienne ensuite. Et si une clé a été vue ailleurs que dans votre fichier .env (dans le dépôt, dans la conversation, à l'écran), elle vous guide calmement : on condamne l'ancienne serrure tout de suite, puis on la remplace. La valeur d'une clé va de votre éditeur à .env, puis à l'hébergeur par un outil qui n'affiche rien.

Vos secrets (aucune valeur affichée) :
  SMTP_PASSWORD        .env ✅   hébergeur ✅ Secret
  BETTER_AUTH_SECRET   .env ✅   hébergeur ✅ Secret
  STRIPE_SECRET_KEY    .env ✅   hébergeur ⚠️ à envoyer

⚠️ Règle qui empêche l'IA de lire vos clés : absente

L'inventaire de /pulse:secrets : des noms et des états, jamais une valeur.

La clé est créée chez le fournisseur, collée par vous dans le fichier .env, puis envoyée à l'hébergeur par un outil qui n'affiche rien. La conversation ne voit que les noms des clés. En cas de fuite, quatre étapes dans l'ordre : 1. révoquer l'ancienne clé d'abord, 2. créer la nouvelle, 3. la mettre partout (.env et hébergeur), 4. vérifier que le site marche en production.

Pourquoi l'utiliser

Vous savez où sont vos clés. Un tableau clair : chaque clé, son rôle, où elle vit, où la renouveler.
Vous changez une clé sans couper le site. L'ancienne reste valide jusqu'à la preuve que la nouvelle marche en ligne.
Une fuite se traite dans le bon ordre. La première action arrive dans les 30 premières secondes : rendre l'ancienne clé inutilisable.
Vos valeurs restent hors de la conversation. Pulse travaille avec les noms ; vous seul manipulez les valeurs.

Quand l'utiliser

1 Démarrer
2 Décrire
3 Préparer
4 Construire
5 Mettre en ligne
6 Être trouvé
7 À tout moment

Tout de suite, dès qu'une clé a été vue ailleurs que dans .env : dépôt, conversation avec l'IA, écran partagé, capture, e-mail, alerte de GitHub ou d'un fournisseur. C'est fuite, prioritaire sur tout le reste.
Avant une mise en ligne, ou quand /pulse:deploy et /pulse:security vous le proposent : l'inventaire.
Pour un changement prévu : départ d'une personne, fin de mission d'un prestataire, revue annuelle, clé montrée par erreur sans exposition publique.

Comment la lancer

/pulse:secrets [inventaire | renouveler <NOM> | fuite [<NOM>]]

Entre crochets [ ] : facultatif. Entre chevrons < > : à remplacer par votre valeur. La barre | sépare les choix possibles. Par défaut : inventaire.

inventaire (par défaut) : le tableau de vos clés, puis les points à corriger, du plus grave au moins grave.
renouveler suivi du nom de la clé : changer une clé sans coupure. La nouvelle est créée à côté de l'ancienne, envoyée en ligne et testée ; l'ancienne est coupée seulement après votre « Ça marche ».
fuite, avec ou sans nom : réagir à une clé exposée. Sans nom, Pulse vous montre la liste de vos clés, avec « Je ne sais pas laquelle ».

/pulse:secrets

/pulse:secrets renouveler SMTP_PASSWORD

/pulse:secrets fuite

Ce qu'elle produit

Fichier	À quoi il sert
`docs/secrets.md`	L'inventaire (noms, rôles, fournisseurs, où renouveler), les protections en place et le journal des changements de clés. Des noms et des dates, jamais une valeur.
`docs/incidents/<date>-<sujet>.md`	Après une fuite : le journal d'incident (chronologie, traces regardées, décision sur les données personnelles, prévention), sans aucune valeur.
`.env`	Des lignes préparées sans valeur ; vous y collez la valeur vous-même.
`.claude/settings.json`	Si vous l'acceptez : la règle qui empêche l'IA de lire vos fichiers de clés.
`docs/lexique.md`	Les mots expliqués en chemin : révoquer, délai de grâce, redéployer…

Risques et précautions

Créer, envoyer ou retirer une valeur, et redéployer, touchent la production. Claude Code vous demande l'accord à chaque fois ; Pulse vous dit avant, en une phrase, ce que vous allez autoriser.
Après une fuite, la coupure est voulue. Pendant quelques minutes, le site ne pourra plus, par exemple, envoyer d'e-mails : cela ferme la porte.
Lors d'un changement prévu, l'ancienne clé reste active jusqu'à votre « Ça marche ✅ » en production. Si la nouvelle ne marche pas, rien n'est cassé.
L'historique Git reste tel quel. Une clé révoquée ne sert plus à rien. Réécrire l'historique reste votre choix, à faire avec une personne compétente.
Pour les données personnelles, Pulse informe et vous décidez. Trois questions, puis l'information utile (en Europe, une violation qui présente un risque se notifie à la CNIL, si possible dans les 72 heures). Votre décision est notée dans le journal d'incident.

Problèmes et solutions

J'ai collé ma clé dans le chat

Pulse le signale tout de suite, sans répéter la valeur, et enchaîne sur fuite. C'est rapide : révoquer chez le fournisseur, créer la nouvelle clé, la coller vous-même dans .env, puis la mettre en ligne.

GitHub ou un fournisseur m'a envoyé une alerte

L'exposition est certaine : des robots lisent les dépôts publics en quelques minutes. Lancez /pulse:secrets fuite sans attendre.

Je ne sais pas quelle clé a fuité

Choisissez « Je ne sais pas laquelle ». Pulse cherche les traces dans l'historique Git et vous demande où la clé a pu être vue.

Le site utilise encore l'ancienne clé

Le site en ligne garde l'ancienne valeur tant qu'il n'est pas reconstruit. Pulse redéploie après chaque envoi, puis vérifie en production.

« Secret enregistré en type Config chez l'hébergeur »

Une valeur de type Config se relit dans les réglages. Supprimez-la vous-même chez l'hébergeur, puis recréez-la en type Secret, qui ne se relit plus.

Exemples

/pulse:secrets fuite

On s'en occupe tout de suite. Première chose : rendre l'ancienne clé inutilisable chez le fournisseur. Je vous guide. Quelle clé ? SMTP_PASSWORD · STRIPE_SECRET_KEY · BETTER_AUTH_SECRET · Je ne sais pas laquelle

SMTP_PASSWORD

Chez votre fournisseur d'e-mail, supprimez l'identifiant d'envoi actuel. Votre site ne pourra plus envoyer les confirmations de rendez-vous pendant quelques minutes : c'est voulu, cela ferme la porte. Dites-moi « C'est fait ».

C'est fait.

pulse-aidd secrets preparer SMTP_PASSWORD

Créez le nouveau mot de passe d'envoi, collez-le dans .env juste après « SMTP_PASSWORD= », enregistrez, puis fermez l'onglet. Je vérifie ensuite, sans rien afficher, puis je l'envoie à l'hébergeur et je redéploie, avec votre accord.

/pulse:secrets renouveler STRIPE_SECRET_KEY

Cette clé a un délai de grâce : l'ancienne et la nouvelle marchent ensemble jusqu'à la date que vous choisissez. 1. Créez la nouvelle clé chez Stripe en gardant l'ancienne active. 2. Collez-la dans votre fichier de production. 3. Je l'envoie, je redéploie, puis vous faites un paiement de test.

pulse-aidd secrets verifier STRIPE_SECRET_KEY --fichier .env.envoi

✅ Clé reconnue. Le paiement de test fonctionne-t-il ? Ça marche ✅ · Ça ne marche pas ❌ · Je ne sais pas comment tester

Ça marche ✅

Vous pouvez maintenant révoquer l'ancienne clé chez Stripe. Je note le changement dans le journal de docs/secrets.md.

Commandes liées

/pulse:security : l'audit, si aucun audit récent n'existe après une fuite.
/pulse:deploy : mettre les clés en production lors du mode production.
/pulse:commit : enregistrer docs/secrets.md et le journal d'incident.
/pulse:init : la protection des clés posée dès le départ.