La console root peut recouvrir le .env, et pas n'importe où

Configurer par variables d'environnement est le bon choix pour qui tient la
machine, et un mauvais pour qui tient l'instance sans tenir la machine :
changer un relais SMTP ne devrait pas demander un accès SSH et un redémarrage.
Un onglet Configuration recouvre donc le fichier, sans le toucher.

L'étroitesse de la liste est le dispositif
  N'y figure que ce qui est adossé à un adaptateur muni d'un setter, donc
  reconfigurable à chaud : courriel, visioconférence, analyse antivirale,
  relais de heurtoir, adresse publique, offre de code. Seize réglages.

  Le reste est écarté, et pour des raisons différentes. DATABASE_URL, REDIS_URL
  et KASTELL_PORT sont consommées à la connexion ou par la composition :
  les afficher comme modifiables mentirait. S3_* se remplace à chaud, mais les
  documents déjà déposés ne suivent pas — on obtiendrait une instance qui
  marche et un dossier de crise amputé, ce qui est pire qu'un refus. APNS_* et
  FCM_* sont lues par le conteneur du relais, jamais par l'application :
  les surcharger ici n'atteindrait personne.

  Et SESSION_SECRET, qui dérive la clé chiffrant les identifiants de passerelle
  des organisations. La remplacer depuis une page web les rend illisibles,
  définitivement et sans recours. Ce n'est pas un réglage, c'est la serrure.

Les secrets se posent, ne se relisent pas
  La règle existait déjà pour les identifiants de passerelle — « administrer
  une instance n'est pas lire les secrets de ses clients ». Une page de
  configuration est précisément l'endroit où on l'oublie, parce qu'afficher la
  valeur qu'on vient de saisir paraît serviable.

  Elle est portée par la forme : le type que reçoit la page n'a pas de champ
  où faire remonter un secret. Chiffrés au repos, contexte distinct de celui
  des organisations, parce qu'un secret sert à une chose et à une seule.

  Le journal retient qu'un réglage a bougé, lequel et par qui — l'ancienne et
  la nouvelle valeur pour les réglages ordinaires, jamais pour un secret.

Retirer rend la main
  Une surcharge se retire, et la valeur du fichier reprend. C'est la sortie de
  secours : on revient d'une mauvaise saisie sans accès à la machine, ce qui
  est tout l'intérêt d'avoir la page.

Contrôlé — 23 garanties
  Que les huit variables interdites le soient, et que les poser soit refusé
  plutôt qu'ignoré. Qu'une surcharge agisse sans redémarrage — le transport
  devient « smtp » sous le contrôle. Qu'un secret n'apparaisse ni dans la
  réponse de l'API, ni en clair dans la base, ni au journal. Que retirer rende
  la main à l'environnement. Que les saisies absurdes soient refusées.

Deux défauts trouvés en écrivant ces contrôles, tous deux de la même famille :
poser un réglage reconstruit les adaptateurs, et la suite de vérification
tourne sur des doublures — une boîte qui intercepte les courriels, un antivirus
d'essai. Les remplacer par un vrai relais et un vrai ClamAV faisait échouer,
cent contrôles plus loin, des garanties sans rapport. La vérification rend
désormais chaque adaptateur tel qu'elle l'a trouvé.

Un troisième, dans l'ordre du démarrage : appliquer les surcharges après le
refus de démarrer sans courriel rendait la page inutile à qui n'a pas déjà
écrit son .env — c'est-à-dire à qui en a le plus besoin. Elles s'appliquent
avant, pour satisfaire ce contrôle et non le contourner.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>