docs: rewrite DEV.md with detailed dev and security guidelines

Replace the terse DEV.md with a comprehensive French-language guide
covering code standards, security rules, and the npm publish workflow.

Key changes:
- Expand code principles into readable prose (single responsibility,
  control flow, input validation, promise handling, minimal scope)
- Add concrete security sections: parameterized queries, secret
  management via env vars, dependency auditing, and opaque error
  messages
- Document the full publish procedure (version bump, build, audit,
  npm publish with provenance, git tag)
- Remove the NASA Power of Ten bullet list in favor of actionable,
  project-specific guidelines

docs/DEV.md

@@ -1,62 +1,108 @@
-# DEV
+# Guide de développement
 
-## Standards
+Ce document couvre les conventions de code, les règles de sécurité et la procédure de publication du package `@zen/core`.
 
-On suit ces deux guides :
+Pour les conventions de rédaction : [LANGUE.md](./dev/LANGUE.md) et [REDACTION.md](./dev/REDACTION.md).
-
-- [GUIDE.md](./dev/GUIDE.md) : conventions générales de rédaction et de structure
-- [REDACTION.md](./dev/REDACTION.md) : règles de style, ton et formatage
 
 ---
 
-## Philosophie de développement
+## Standards de code
 
-### Power of Ten
+### Principes généraux
 
-Tout le code produit suit les principes du [NASA Power of Ten](https://en.wikipedia.org/wiki/The_Power_of_10:_Rules_for_Developing_Safety-Critical_Code) :
+**Une fonction, une responsabilité.** Si elle fait deux choses, c'est deux fonctions. Si elle ne tient pas sur un écran, la découper.
 
-1. **Flux de contrôle simples** — pas de `goto`, pas de récursion non bornée, pas de pointeurs de fonctions imbriqués.
+**Le flux de contrôle se lit de haut en bas.** Pas de récursion non bornée, pas de callbacks imbriqués à plus de deux niveaux. Quelqu'un qui lit le code pour la première fois doit pouvoir suivre l'exécution sans se perdre.
-2. **Boucles bornées** — toute boucle doit avoir une limite maximale d'itérations statiquement vérifiable.
-3. **Pas d'allocation dynamique après l'initialisation** — allouer les ressources en amont, libérer proprement.
-4. **Fonctions courtes et ciblées** — une fonction = une responsabilité, tient sur un écran.
-5. **Densité d'assertions élevée** — valider les préconditions, postconditions et invariants explicitement.
-6. **Portée des données minimale** — déclarer les variables au plus près de leur utilisation, limiter l'exposition.
-7. **Vérification systématique des retours** — chaque valeur de retour ou promesse rejetée doit être gérée.
-8. **Préprocesseur minimal** — éviter la magie implicite ; préférer la clarté à la concision.
-9. **Limiter les pointeurs** — une seule indirection par niveau ; pas d'aliasing caché.
-10. **Warnings = erreurs** — le linter et le compilateur doivent passer sans avertissement.
 
-### Sécurité
+**Les données entrantes sont suspectes.** On valide en entrée de fonction. On ne suppose pas que l'appelant a fait le travail.
 
-Chaque contribution doit intégrer la sécurité dès la conception (*security by design*) :
+**Les promesses ne s'ignorent pas.** Chaque `Promise` est `await`ée ou `.catch()`ée. Une promesse silencieuse qui échoue est un bug invisible.
 
-- **Validation des entrées** — toute donnée externe (utilisateur, API tierce, fichier) est considérée malveillante jusqu'à preuve du contraire. Valider côté serveur, jamais uniquement côté client.
+**La portée des variables est minimale.** On déclare au plus près de l'usage. Pas de variables réutilisées pour deux rôles différents.
-- **Moindre privilège** — un module n'accède qu'aux ressources strictement nécessaires à sa fonction.
+
-- **Pas de secrets dans le code** — tokens, clés API, mots de passe passent exclusivement par des variables d'environnement ou un gestionnaire de secrets.
+**ESLint passe sans avertissement.** Un warning ignoré aujourd'hui est un bug non détecté demain.
-- **Dépendances auditées** — lancer `npm audit` avant chaque publication ; ne pas introduire de dépendance avec des vulnérabilités connues non corrigées.
+
-- **Gestion des erreurs opaque** — les messages d'erreur exposés à l'utilisateur ne révèlent pas de détails internes (stack trace, chemin de fichier, requête SQL…).
+---
-- **Protection contre les injections** — utiliser exclusivement des requêtes paramétrées ou des ORM éprouvés ; jamais de concaténation de chaînes SQL/shell.
+
-- **Authentification et sessions** — tokens signés, durée de vie limitée, révocation possible, rotation des secrets régulière.
+## Sécurité
-- **En-têtes HTTP de sécurité** — `Content-Security-Policy`, `X-Content-Type-Options`, `Strict-Transport-Security` configurés sur toutes les routes.
+
+### Données entrantes
+
+Toute donnée externe est considérée malveillante par défaut : requêtes HTTP, données formulaire, réponses d'API tierce, contenu de fichier. On valide côté serveur. Le client ne contrôle rien de critique.
+
+### Base de données
+
+On n'écrit jamais de SQL par concaténation de chaînes. Uniquement des requêtes paramétrées :
+
+```ts
+// ✓
+await pool.query('SELECT * FROM users WHERE id = $1', [userId])
+
+// ✗
+await pool.query(`SELECT * FROM users WHERE id = '${userId}'`)
+```
+
+### Secrets
+
+Aucun token, clé API ou mot de passe dans le code. Tout passe par des variables d'environnement. Les clés Stripe, les tokens Resend et les credentials PostgreSQL ne sont jamais commités.
+
+```bash
+# .env.local — jamais dans git
+DATABASE_URL=...
+STRIPE_SECRET_KEY=...
+RESEND_API_KEY=...
+```
+
+### Dépendances
+
+Avant chaque publication :
+
+```bash
+npm audit
+```
+
+Ne pas publier avec des vulnérabilités de sévérité `high` ou `critical` non corrigées.
+
+### Erreurs exposées
+
+Les messages d'erreur retournés à l'utilisateur ne contiennent pas de détails internes : pas de stack trace, pas de nom de table, pas de requête SQL. On log côté serveur, on renvoie un message générique côté client.
 
 ---
 
 ## Publier le package
 
-Le package `@zen/core` est publié sur le registre npm à `https://git.hyko.cx`.
+Le package `@zen/core` est publié sur le registre npm privé à `https://git.hyko.cx`.
 
-### 1. Configurer l'authentification
+### Configurer l'authentification (une seule fois)
 
-Créer un token d'accès dans Gitea (Settings → Applications → Generate Token), puis l'enregistrer localement :
+Créer un token dans Gitea : **Settings → Applications → Generate Token**, puis :
 
 ```bash
 npm config set //git.hyko.cx/api/packages/zen/npm/:_authToken TOKEN
 ```
 
-Remplacer `TOKEN` par le token généré.
+### Checklist avant publication
 
-### 2. Build et publish
+- [ ] `npm audit` — aucune vulnérabilité `high` ou `critical`
+- [ ] `npm run build` — build sans erreur ni warning TypeScript
+- [ ] Version mise à jour dans `package.json`
+
+### Versionner
+
+On suit [semver](https://semver.org) :
+
+- **patch** (`1.3.x`) — correction de bug, sans changement d'interface
+- **minor** (`1.x.0`) — nouvelle fonctionnalité, rétrocompatible
+- **major** (`x.0.0`) — changement cassant
+
+```bash
+npm version patch   # ou minor, ou major
+```
+
+### Publier
 
 ```bash
 npm publish
 ```
+
+Le script `prepublishOnly` lance le build automatiquement. Si le build échoue, la publication est annulée.

docs/dev/LANGUE.md

@@ -1,4 +1,4 @@
-# GUIDE
+# LANGUE
 
 ## Langue du code
 

docs/dev/REDACTION.md

@@ -1,4 +1,4 @@
-# GUIDE DE RÉDACTION
+# RÉDACTION
 Dernière modification : 2026-04-12
 
 ## La voix de l'entreprise