Recette : Audit de stack

Un audit de stack répond à trois questions : Notre graphe de dépendances est-il sain ? Accumulons-nous de la dette technique ? Que doit-on mettre à niveau ensuite et dans quel ordre ?

Cette recette utilise les outils du flux H de SpecForge pour effectuer un audit de santé complet de la stack et construire un plan de mise à niveau actionnable.

---

Étape 1 — Exécuter l'audit complet de la stack

Prompt :

Audite la stack pour le projet proj_abc123

Ce à quoi s'attendre :

Stack Health Score : 71/100

Statut des dépendances :
  up_to_date:    34 paquets  ✅
  outdated:      12 paquets  ⚠️
  vulnerable:     3 paquets  🚨
  unmaintained:   1 paquet   ❌

Critique (corriger immédiatement) :
  - lodash 4.17.20 → CVE-2021-23337 (Prototype pollution)
  - axios 0.21.1 → CVE-2023-45857 (Vulnérabilité CSRF)
  - follow-redirects 1.14.7 → CVE-2023-26159

Priorité haute (prochain sprint) :
  - typescript 4.9.5 → 5.7.2 (13 versions mineures de retard)
  - vitest 0.34.0 → 3.1.0 (version majeure de retard)
  - express 4.18.0 → 5.0.1 (version majeure disponible)

Priorité moyenne (ce trimestre) :
  - 8 paquets 1–3 versions mineures de retard

---

Étape 2 — Détecter les API dépréciées

Prompt :

Détecte les API dépréciées dans le projet proj_abc123

Cela scanne les fichiers source (sans réseau requis) pour l'utilisation d'API dépréciées :

Utilisation d'API dépréciées trouvée :

src/middleware/session.ts:14
  express-session secret comme string — déprécié, utiliser un tableau de secrets
  Effort pour corriger : 0,5h

src/utils/crypto.ts:8
  crypto.createCipher — déprécié depuis Node 10, utiliser createCipheriv
  Risque sécurité : ÉLEVÉ
  Effort pour corriger : 2h

src/config/database.ts:22
  callback mongoose.connect — déprécié dans Mongoose 7, utiliser promise
  Effort pour corriger : 1h

Dette technique totale : ~3,5h

---

Étape 3 — Planifier les mises à niveau prioritaires

Pour chaque élément critique ou haute priorité, générez un plan de mise à niveau :

Prompt :

Planifie la mise à niveau d'axios 0.21.1 vers la dernière version stable pour le projet proj_abc123

Ce à quoi s'attendre :

## Plan de mise à niveau Axios : 0.21.1 → 1.7.9

### Changements cassants
- AbortController remplace CancelToken (déprécié en v0.22)
- Content-Type par défaut pour POST changé en application/json (aucun changement nécessaire)
- Types de réponse changés dans les définitions TypeScript

### Étapes de migration
1. Mettre à jour package.json : axios ^1.7.9
2. Remplacer toute utilisation de CancelToken :
   - Chercher : axios.CancelToken.source()
   - Remplacer : AbortController / AbortSignal
3. Mettre à jour les types TypeScript (le générique AxiosResponse a changé)
4. Exécuter la suite de tests — les intercepteurs axios sont compatibles ascendants

### Fichiers affectés (5) :
- src/api/client.ts (utilisation CancelToken lignes 34, 67)
- src/api/interceptors.ts (annulation token ligne 89)
- src/utils/request.ts (gestion du timeout)
- tests/api/client.test.ts (mises à jour de mocks nécessaires)
- tests/api/interceptors.test.ts (mises à jour de mocks nécessaires)

### Effort estimé : 3h
### Rollback : épingler à 0.27.2 (dernier stable 0.x)

---

Étape 4 — Créer des specs pour les mises à niveau majeures

Pour les mises à niveau de version majeure affectant plusieurs fichiers, créez une spec correcte :

Prompt :

Crée une spec pour la mise à niveau d'Express de 4.18 à 5.0 dans le projet proj_abc123

Cela vous donne :

• Des critères d'acceptation pour la mise à niveau (tous les endpoints fonctionnent encore, aucun comportement cassant)
• Un plan de migration
• Des exigences de couverture de tests (comparaison avant + après)

---

Étape 5 — Vérification de gouvernance des données

Si le projet gère des données utilisateur :

Prompt :

Lance une vérification de gouvernance des données pour le projet proj_abc123

Ce à quoi s'attendre :

Détection PII :
  spec SPEC-003 (inscription utilisateur) : email, nom, téléphone — politique de rétention nécessaire
  spec SPEC-007 (analytique) : adresse IP stockée — intérêt légitime RGPD requis

Conformité RGPD :
  ✅ Minimisation des données — les specs collectent un minimum de PII
  ⚠️  Politique de rétention manquante pour user.email (SPEC-003)
  ⚠️  Droit à l'effacement non spécifié dans aucune spec
  ❌  Aucune spec d'avis de confidentialité n'existe

Recommandations :
  1. Créer une spec pour la conformité RGPD (droit à l'effacement, export de données)
  2. Ajouter une politique de rétention à SPEC-003
  3. Générer un template d'avis de confidentialité

---

Étape 6 — Prioriser le backlog de remédiation

Prompt :

Crée des specs pour les 3 principales vulnérabilités de sécurité trouvées dans l'audit de stack pour le projet proj_abc123

SpecForge crée des specs pour chaque correctif CVE, correctement délimitées avec des critères d'acceptation.

---

Étape 7 — Suivre la progression

Planifiez des audits réguliers et suivez le StackHealthScore dans le temps :

Prompt :

Audite la stack pour le projet proj_abc123

Objectif : StackHealthScore ≥ 85, zéro paquet vulnerable ou unmaintained.

---

Recommandations de cadence d'audit

Déclencheur	Action
Mensuel	audit_stack — scan complet des dépendances
Trimestriel	detect_deprecations — scan des sources
Avant release	audit_stack + security_check sur les specs paiement/auth
Post-incident	capture_learning + mise à jour des specs affectées
LTS Node.js majeur	detect_deprecations + plan_upgrade pour les paquets affectés

---

Problèmes courants et correctifs

Problème	Outil	Durée typique de correction
CVE dans dépendance directe	plan_upgrade	1–4h
CVE dans dépendance transitive	plan_upgrade + override manuel	2–8h
API dépréciée dans les sources	detect_deprecations	0,5–3h par fichier
Paquet non maintenu	Remplacer par un fork maintenu	4–16h
Version majeure de retard	plan_upgrade	2–12h