chore(sec): révoquer les clés exposées et sortir les secrets du champ « Variables d'environnement »

[arenier]

Aucune valeur de clé n'est reproduite ici : ce dépôt est public, et une issue est le dernier
endroit où recopier un secret. Les clés concernées sont nommées, pas citées.

De quoi il s'agit

Les clés NEON_API_KEY et GEMINI_API_KEY sont renseignées dans le champ Variables
d'environnement de l'environnement Claude Code (claude.ai/code). Ce champ affiche lui-même
l'avertissement : « Ces informations sont visibles par toute personne utilisant cet environnement —
n'ajoutez pas de secrets ni d'identifiants. »

Ces deux valeurs ont par ailleurs transité en clair dans une capture d'écran partagée en
conversation. Elles doivent être considérées comme compromises, indépendamment de la question de
savoir qui a réellement eu accès à l'environnement : une clé qui a quitté son coffre ne se
« dé-divulgue » pas.

Ce qui n'est pas en cause

Vérifié avant d'ouvrir cette issue — le dépôt lui-même est sain :

• aucun .env suivi par git ; .gitignore couvre .env et .env.*, avec l'exception
  !.env.example ;
• .env.example ne porte que des placeholders vides pour GEMINI_API_KEY et OPENROUTER_API_KEY,
  et sa notice dit déjà « Never commit a real value here » ;
• recherche des préfixes de clés sur les 50 derniers commits de toutes les branches : aucun résultat.

Le problème est donc entièrement côté configuration d'environnement, pas côté code. Rien à
réécrire dans l'historique.

À faire

1. Révoquer et régénérer NEON_API_KEY (console Neon) et GEMINI_API_KEY (Google AI Studio).
   Vérifier au passage si OPENROUTER_API_KEY a suivi le même chemin.
2. Vider ces variables du champ de l'environnement Claude Code.
3. Décider où elles vivent à la place, et le documenter :
   • en production, c'est déjà tranché — Secret Manager, injecté par Cloud Run
     (ADR 0004, ADR 0006) ;
   • en local, .env ignoré par git ;
   • en session Claude Code distante, rien n'est tranché — c'est le vrai sujet de cette issue.
4. Vérifier les traces éventuelles côté fournisseurs : journaux d'usage Neon et Google AI Studio sur
   la période d'exposition, pour distinguer une fuite théorique d'une fuite exploitée.

À instruire

• Un environnement distant a-t-il besoin de clés réelles ? SHELF_SCANNER_PROVIDER=stub fait
  démarrer l'API sans aucune clé (ADR 0005),
  et c'est déjà le défaut du script de configuration. Le bench (feat(recognition): V1 reconnaissance texte sur photo d'étagère — adapters VLM (Gemini + Qwen) derrière ShelfScannerPort + endpoint POST /scan #10) a besoin d'appels réels, mais
  il a de toute façon besoin d'une vérité terrain humaine — donc de la machine de l'auteur.
  L'hypothèse par défaut devrait être : pas de clé en session distante.
• Si un appel réel devient nécessaire depuis une session distante, quelle est la voie acceptable
  (clé de test à quota plafonné et durée de vie courte, plutôt qu'une clé de production) ?
• Faut-il une note dans CLAUDE.md ou dans le README pour que la règle survive à cette issue —
  le champ « Variables d'environnement » n'est pas un coffre.

Références

.env.example, .gitignore, apps/api/src/config/environment.ts (validation au démarrage),
ADR 0004, 0005 et 0006.