Tests

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.

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

IndicateurCible initialeMesure
LCP≤ 2,5 s au p75Terrain, segmenté par gabarit et terminal
INP≤ 200 ms au p75Terrain ; Lighthouse ne suffit pas
CLS≤ 0,1 au p75Terrain et tests synthétiques
Erreurs serveur< 1 % au pic projetéCharge et production
Disponibilité≥ 99,5 % mensuel, comme le pilotageMonitoring externe
Cache hit publicObjectif à définir par routeCDN, 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.
Last modified on