# Storybook audit — avant / après remédiation

## Conditions

- **Avant** : audit initial (timestamp 2026-02-05T09:15:44 dans `storybook_audit_detailed.json`).
- **Après** : rebuild Storybook avec les 5 commits de remédiation, puis même protocole : serve static sur 6007, `node scripts/audit-storybook.js`.
- **Build** : `npm run build-storybook` (VITE_API_URL=/api/v1, VITE_STORYBOOK=true).

---

## Métriques brutes

| Métrique | Avant | Après | Évolution |
|----------|-------|--------|-----------|
| Stories en erreur | 641 | 101 | **-84 %** |
| Total erreurs capturées | 1 250 | 144 | **-88 %** |

---

## Répartition des erreurs (après)

- **Réseau** : 144 (toutes les erreurs restantes).
- **Console** : 0.
- **Page errors** : 0.
- **Navigation** : 0.

---

## Nature des 144 erreurs réseau restantes

**Aucune** n’est un appel API applicatif.

Toutes concernent des assets **Storybook** (manager / addons) :

| Pattern | Occurrences | Signification |
|---------|-------------|----------------|
| `GET /sb-manager/globals-runtime.js` | 97 | Runtime du manager Storybook |
| `GET /sb-addons/.../manager-bundle.js` | 11 × 4 | Bundles addons (controls, viewport, a11y, etc.) |
| `GET /sb-manager/runtime.js` | 2 | Runtime manager |
| `GET /index.json` | 2 | Index Storybook |

Ces URLs **existent** dans `storybook-static/` (fichiers présents). Les `net::ERR_ABORTED` viennent très probablement du **timing** du script d’audit : navigation vers la story suivante avant la fin du chargement de ces ressources (wait 100 ms), pas d’échec applicatif.

---

## Ce qui a disparu (effet des commits)

| Catégorie (avant) | Avant | Après |
|-------------------|-------|--------|
| `GET /api/v1/auth/me` | 601 | **0** |
| `POST /api/v1/logs/frontend` | 94 | **0** |
| Erreurs console (ex. "Error at y", "e is not iterable", etc.) | 191+ | **0** |
| Autres API (audit, users, dashboard, tracks, etc.) | nombreuses | **0** |
| Assets externes (picsum, dicebear, transparenttextures) | plusieurs | **0** |

---

## Conclusion

1. **Phase 1 (environnement clos)** : côté **app**, objectif atteint :
   - **0** appel API non mocké.
   - **0** endpoint inconnu.
   - **0** erreur console.
   - Assets externes neutralisés (handlers MSW + logger désactivé en Storybook).

2. Les **101 stories** encore marquées en échec le sont uniquement à cause des requêtes **sb-manager / sb-addons** (ERR_ABORTED de timing), pas à cause du code applicatif.

3. **Recommandation** : pour un indicateur “app only”, le script d’audit peut **exclure** les URLs dont le path commence par `/sb-manager/`, `/sb-addons/` ou qui correspondent à `index.json` (optionnel). On peut aussi augmenter légèrement le délai après `domcontentloaded` pour réduire les aborts sur ces assets.

---

## Checklist Phase 1 (binaire)

- [x] MSW intercepte 100 % des appels API (plus aucun `auth/me`, `logs/frontend`, etc. dans le rapport).
- [x] Aucun `net::ERR_ABORTED` **applicatif** persistant (les seuls restants sont Storybook interne).
- [x] Aucun appel réseau “surprise” (dashboard, stats, settings, etc.) — tous mockés ou absents du rapport.
- [x] Assets externes neutralisés (dicebear, transparenttextures, picsum mockés ; logger ne fait plus de POST en Storybook).

**Audit "app only"** : le script a été modifié pour ignorer les requêtes `/sb-manager/`, `/sb-addons/`, `/index.json`, `/project.json`. Avec ce filtre : **0 stories en erreur**, **0 erreurs capturées**.

**Phase 1 peut être considérée close** pour la partie “environnement clos côté app”. Les prochaines étapes sont Phase 2 (décorateur global unique) et affinage du script d’audit (filtrage sb-manager/sb-addons ou délai) pour que le nombre de “stories en erreur” reflète uniquement les vrais échecs applicatifs.