# Plan de tests de performance Web et de résilience
> **En bref :**
> - **POC de novembre** : mesures synthétiques (Lighthouse, WebPageTest) sur les gabarits, sans mesure terrain faute de trafic.
> - **Avant lancement** : charge anonyme, cache CDN, résilience quand CRISalid est indisponible, mesures terrain au p75 dès l’ouverture.
> - Les seuils sont des **cibles de travail** ; les indicateurs suivis en exploitation sont dans [Exploitation & pilotage](/01-cadrage-saclay/exploitation-pilotage).

La campagne doit répondre à trois questions différentes :

1. la page paraît-elle rapide pour un utilisateur réel ?
2. l’architecture absorbe-t-elle le trafic anonyme et les robots ?
3. le service continue-t-il à fonctionner lorsqu’une dépendance ralentit ou tombe ?

## Budgets initiaux à valider

| Indicateur | Cible initiale | Mesure |
| --- | ---: | --- |
| LCP | ≤ 2,5 s au p75 | Terrain, segmenté par gabarit et terminal |
| INP | ≤ 200 ms au p75 | Terrain ; Lighthouse ne suffit pas |
| CLS | ≤ 0,1 au p75 | Terrain et tests synthétiques |
| Erreurs serveur | < 1 % au pic projeté | Charge et production |
| Disponibilité | ≥ 99,5 % mensuel, comme le [pilotage](/01-cadrage-saclay/exploitation-pilotage) | Monitoring externe |
| Cache hit public | Objectif à définir par route | CDN, après préchauffage |

Il faut également fixer des budgets de TTFB, JavaScript, CSS, images, polices et nombre de requêtes pour chaque gabarit.

## Matrice de test

### Pages

- accueil ;
- annuaire paginé ;
- recherche avec et sans résultat ;
- fiche chercheur ;
- fiche structure ;
- fiche projet ou production ;
- page riche en relations et médias ;
- page bilingue.

### Contextes

- mobile milieu de gamme avec réseau contraint ;
- desktop ;
- cache navigateur vide et chaud ;
- CDN froid, chaud et après purge ;
- origine nominale, lente et indisponible ;
- fiche populaire et longue traîne ;
- génération complète à chaque synchronisation.

## 1. Performance frontend

- [ ] Mesurer LCP, CLS et métriques de blocage sur chaque gabarit.
- [ ] Identifier l’élément LCP et vérifier sa priorité réelle.
- [ ] Dimensionner les images et générer `srcset`, `sizes`, AVIF/WebP.
- [ ] Vérifier qu’aucun script tiers ne bloque le rendu initial.
- [ ] Mesurer le JavaScript hydraté et retirer les composants clients inutiles.
- [ ] Tester les polices auto-hébergées, leur sous-ensemble et leur stratégie de chargement.
- [ ] Tester les contenus longs, traductions et images absentes pour éviter le CLS.
- [ ] Ajouter Lighthouse CI comme garde-fou, sans le confondre avec la mesure terrain.

## 2. Cache et origine

Pour chaque route, documenter : TTL, clé, `Vary`, `ETag`, invalidation, contenu périmé autorisé et comportement d’erreur.

- [ ] Capturer `Cache-Control`, `Age`, `Vary`, `ETag` et les réponses `304` depuis l’extérieur.
- [ ] Mesurer hit, miss et bypass par type de page.
- [ ] Vérifier l’isolation des langues, pages et variantes.
- [ ] Tester qu’un cookie ne rend pas accidentellement toutes les réponses non cacheables.
- [ ] Tester une purge de fiche et des pages parentes.
- [ ] Tester une purge massive sans cache stampede.
- [ ] Mesurer la charge atteignant réellement l’origine (frontend et API) après CDN.
- [ ] Définir combien de temps une version périmée peut être servie si la source échoue.

## 3. Charge anonyme

Le scénario doit représenter les visiteurs et les robots, pas seulement quelques utilisateurs authentifiés.

- [ ] Construire un modèle de trafic par parcours et popularité des pages.
- [ ] Documenter le dataset, le nombre de relations et la taille des payloads.
- [ ] Tester montée progressive, pic, rafale et endurance.
- [ ] Tester séparément cache froid et chaud.
- [ ] Publier p50, p95 et p99 de chaque couche.
- [ ] Collecter CPU, mémoire, saturation des pools, latence base/index et erreurs.
- [ ] Répéter la campagne au moins trois fois dans des conditions comparables.
- [ ] Exécuter au minimum deux fois le pic projeté avant ouverture.

## 4. Résilience

- [ ] Couper CRISalid/Apollo/Neo4j après publication d’une fiche.
- [ ] Ralentir l’API amont au-delà du timeout prévu.
- [ ] Rendre l’index de recherche indisponible.
- [ ] Simuler une réponse partielle ou incompatible.
- [ ] Vérifier circuit breaker, retries bornés et absence d’amplification.
- [ ] Vérifier que la dernière version publiée reste disponible.
- [ ] Tester la reconstruction de l’index et le réchauffement des caches.
- [ ] Mesurer le RTO et le RPO pendant un exercice de restauration.

## 5. Génération des pages

La vitrine régénère ses pages à chaque synchronisation. Tester spécifiquement :

- [ ] durée de génération complète sur la volumétrie cible ;
- [ ] consommation mémoire et espace disque ;
- [ ] comportement lorsqu’une seule entité est invalide ;
- [ ] rapport exhaustif des pages rejetées ;
- [ ] génération déterministe à données identiques ;
- [ ] publication atomique sans mélange entre deux versions ;
- [ ] rollback vers la version publiée précédente ;
- [ ] correction urgente d’une seule fiche sans attendre le cycle suivant.

## Preuves attendues

- scripts de test versionnés ;
- corpus et hypothèses documentés ;
- configuration de l’infrastructure testée ;
- rapport brut et synthèse ;
- dashboards horodatés ;
- commit et image déployée ;
- écarts, décisions et propriétaire de correction.

## Critères de go

Une moyenne favorable ne compense pas :

- un contenu absent du HTML initial ;
- une erreur critique de sécurité ;
- une origine qui sature dès que le cache est froid ;
- l’indisponibilité des fiches publiées lors d’une panne amont ;
- l’absence de données p95/p99 ou de test reproductible.