PD-19 — Retour d'expérience (REX)¶

1. Résumé exécutif¶

2. Métriques de convergence¶

2.1 Temps et itérations¶

2.2 Scores de convergence par gate¶

2.3 Écarts par catégorie¶

3. Points fluides¶

Ce qui a bien fonctionné : - Extension de l'existant : Helmet v7.1.0, CORS natif, RateLimitService Redis — aucune nouvelle dépendance requise - ConfigModule avec validation Joi : fail-fast naturel, multi-env sans modification de code - Pattern middleware NestJS : séparation claire des responsabilités (SecurityHeaders → CORS → RateLimit) - Code contracts YAML : contrat d'interface explicite accélérant l'implémentation et les tests - Correction automatique Gate 3→v2 : delta +2.25 en une itération (prompt de correction complet)

4. Points difficiles¶

Obstacles rencontrés : - Spec v1 rejetée : 4 paramètres contractuels critiques absents (socle headers, CORS, seuils limitation, eIDAS) - 8 règles non testables : critères d'acceptation non mesurables — score testability 4/10 - Trust proxy et X-Forwarded-For : vulnérabilité XFF bypass identifiée en review sécurité (SEC-01 HIGH) - Validation IPv6 permissive : regex insuffisante (SEC-02 HIGH) - Headers sur erreurs : res.on('finish') nécessaire pour garantir les headers sur 404/500/429

5. Hypothèses révélées tardivement¶

Hypothèses non explicites découvertes en cours de workflow : - eIDAS non testable HTTP — découverte à l'étape 3 : les exigences de valeur probatoire (signature, horodatage qualifié) ne sont pas observables au niveau HTTP pur → exclusion explicite du périmètre - Rétention 90 jours = infra — découverte à l'étape 5 : la rétention des logs de sécurité est une configuration infrastructure (ELK/Loki lifecycle) et non applicative - Vary: Origin obligatoire — découverte à l'étape 8 : header nécessaire pour éviter les problèmes de cache CORS multi-origines

6. Invariants complexes¶

Invariants difficiles à implémenter ou sensibles aux régressions : - INV-01 (socle headers) + INV-11 (headers sur erreurs) — TC-NOM-05, TC-ERR-02 : garantir les headers même sur les exceptions non gérées via res.on('finish') plutôt que dans le middleware - INV-06 (résolution IP) — TC-INT-01 : chaîne de proxy de confiance avec Express trust proxy et validation de X-Forwarded-For - INV-07 (format 429) — TC-ERR-04 : corps JSON exact {"error":"rate_limited","message":"Too many requests","retryAfter":<seconds>}

7. Dette technique¶

Compromis acceptés et non bloquants : - ECT-01 (indépendance métier) — impact: faible : preuve par analyse code, pas par test explicite ; à documenter dans architecture - ECT-02 (format logs) — impact: faible : format JSON UTC couvert par configuration du transport (Winston/Pino), pas de test unitaire dédié - ECT-04 (Vary: Origin) — impact: faible : implémenté via res.setHeader() au lieu de res.vary() ; amélioration cosmétique future - TC-NOM-06 absent — impact: moyen : pas de test explicite de la journalisation ; couvert par tests d'intégration implicites

8. Risques résiduels¶

9. Patterns récurrents détectés¶

9.1 Patterns confirmés (déjà vus dans d'autres stories)¶

• Fail-fast config sécurité — aussi dans PD-22 (config Vault), PD-240 (account deletion)
• Validation croisée LLM — ChatGPT review / Claude implémentation — pattern standard du workflow
• Rate limiting Redis atomique — aussi dans PD-238 (MFA), guards auth existants
• Code contracts YAML — standard depuis PD-19

9.2 Nouveaux patterns identifiés¶

• res.on('finish') pour headers universels — à surveiller : garantit les headers même sur exceptions non catchées
• Trust proxy Express + TRUSTED_PROXIES env — pattern à documenter pour tous les rate limitings
• CORS contractuel sans wildcard — origines explicites par environnement, pas de * même en dev

10. Améliorations du workflow¶

10.1 Améliorations des prompts/templates¶

10.2 Améliorations des agents¶

10.3 Améliorations du processus¶

• Synchroniser PD-XX-tests.md après correction spec : le document de tests v1 n'a pas été mis à jour après la correction spec v2 (DIV-02 Gate 3 v2)
• Ajouter ticket suivi pour réserves infra : la rétention 90 jours (DIV-04 Gate 5) nécessite un ticket infra séparé

11. Enseignements clés¶

1. Paramètres contractuels explicites dès la spec — Les critères d'acceptation non mesurables (socle headers sans liste, CORS sans origines) sont les premières causes de rejet Gate 3. Définir les valeurs exactes dès l'étape 1.

2. Headers sur erreurs = res.on('finish') — Les security headers doivent être appliqués même sur les réponses d'erreur. Le pattern res.on('finish') garantit cette couverture là où les middlewares classiques échouent.

3. Trust proxy est une surface d'attaque — La résolution IP via X-Forwarded-For sans validation de la chaîne de confiance permet le bypass du rate limiting. Configurer trust proxy de manière restrictive.

4. Faux positifs reviews LLM = lecture partielle — Les 2 faux positifs Gate 5 (credentials/exposedHeaders "absents") étaient causés par la lecture de résumés plutôt que des documents complets. Injecter les documents inline.

5. Rétention logs = configuration infra — La rétention de 90 jours (INV-09) n'est pas codée dans l'application mais dans la configuration du système de logging (ELK lifecycle). Documenter comme prérequis déploiement.

12. Métriques cumulatives¶

Document produit par le workflow de gouvernance IA — Étape 9 (Claude mode créatif) Date : 2026-02-10