La gestion de la performance des applications avec New Relic
change de nom...
Un site grand public, ce n’est pas qu’une vitrine. C’est parfois le canal principal et souvent le premier point de contact pour obtenir de l’information en temps réel, faire des démarches ou des réservations. Une lenteur ou une indisponibilité de quelques minutes se paie en termes d’ image, en appels au support. Et quand ça tombe le jour d’un lancement attendu par toute l’équipe, la tension monte vite en interne.
Les situations à risque se ressemblent : une migration de plateforme, une refonte, un pic saisonnier documenté chaque année dans vos analytics, une campagne qui concentre le trafic sur quelques URLs.
Un test de charge consiste à simuler du trafic sur un site pour voir comment il réagit quand le nombre de visiteurs augmente. Pour un client, nous organisons une campagne : cadrage, préparation des scénarios, plusieurs sessions de test à des niveaux de trafic différents, puis analyse des résultats ensemble.
Une campagne se prépare avec vous. Les simulations ont lieu sur des créneaux convenus, avec une intensité plafonnée. Votre équipe autorise nos adresses IP sur le pare-feu, et nous vérifions ensemble quels services externes les tests vont solliciter. Le but est de mesurer un périmètre précis et de le comparer aux critères de mise en production fixés au départ (le « GO »). Ce n’est pas une garantie qu’aucun incident n’arrivera jamais.
Tous les projets n’en ont pas besoin : un petit site interne avec peu de visiteurs a d’autres priorités.
L’objectif d’une campagne, c’est de tester l’affluence : le site encaisse-t-il le volume de visites et de parcours attendu, avec des temps de réponse acceptables ? On parle de capacité, de montée en charge, de saturation éventuelle. La sécurité (failles, intrusions, règles du pare-feu applicatif) relève d’un audit à part, qui répond à d'autres types de questions comme "est-ce qu’un attaquant peut entrer ?".
Ce n’est PAS un audit de sécurité, un pentest ni une validation de votre politique WAF au sens cybersécurité.
Les enjeux ne sont pas les mêmes : ici, la question est le service tient-il sous la foule légitime ? ; en sécurité, c’est quelqu’un de malveillant peut-il abuser du système ?
Les tests ne sont pas les mêmes (parcours utilisateurs réalistes, paliers de charge, seuils de latence et d’échec HTTP, pas recherche de failles ou d’injection).
Les moyens de mitigation non plus : dimensionner, optimiser, répartir la charge, ajuster le cache ou l’infra, plutôt que corriger une vulnérabilité, durcir l’authentification ou revoir les règles d’accès.
Test de charge | Audit de sécurité | |
| Question posée | Le site tient-il face à un afflux de visiteurs légitimes ? | Une personne malveillante peut-elle détourner le système ? |
| Ce qu’on teste | Parcours réalistes, paliers de trafic, temps de réponse, taux d’erreur | Failles, injections, contrôle d’accès |
| Ce qu’on corrige ensuite | Dimensionnement, cache, répartition de charge, infrastructure | Vulnérabilités, authentification, règles d’accès |
Les deux sujets se complètent sur un site grand public, mais il ne faut pas attendre d’un test de charge qu’il remplace le volet sécurité, ni l’inverse. Sur notre campagne, la whitelist IP ne servait qu’à permettre la simulation appelée aussi “le tir” dans un cadre maîtrisé ; elle ne constituait pas le livrable « sécurité » du projet.
Une mauvaise expérience se raconte vite, sur les réseaux sociaux comme autour de soi. Sur un site où l’on fait des démarches ou des réservations, une panne empêche aussi les gens de faire ce pour quoi ils sont venus. Et après une migration qui a demandé des mois de travail, une seule journée de panne peut suffire à faire passer tout le projet pour un échec, surtout si personne n’avait vérifié la tenue en charge avant.
3 questions avant de se lancer
Si vous avez une échéance, un ordre de grandeur de votre trafic et quelques parcours sensibles, une campagne sur deux paliers (trafic habituel et pic) est pertinente.
L’objectif n’est pas de « casser » l’infrastructure (palier de stress explicité plus loin). Elle sert à vérifier, chiffres à l’appui, que l’infrastructure tient à ces deux niveaux avant la bascule
Si toutes les visites simulées ciblent uniquement la page d’accueil, on obtient des chiffres flatteurs, et faux : c’est souvent la page la plus légère et la mieux mise en cache du site. Un vrai visiteur passe de l’accueil à une liste, ouvre une fiche détail, lance une recherche, consulte une page de service, parfois dans la version anglaise du site. Et tous les visiteurs ne suivent pas le même chemin.
Pour nos campagnes, nous sommes partis de trois mois de statistiques de fréquentation. Chaque visite simulée suit un parcours qui respecte les analytics observées sur le site. On retrouve ainsi 2,2 pages vues par visite en moyenne, comme dans la réalité.
| Palier | Ce que cela représente | Ordre de grandeur (campagne) |
| Nominal / Trafic habituel | Trafic cible quotidien | ~30 requêtes/s |
| Pic | Affluence forte (×3) | ~90 requêtes/s |
| Stress / au-delà | Marge exploratoire (sert à voir ce qui cède en premier) | Hors critère de mise en prod |
Le pic de référence peut venir d’une journée record dans vos outils d’audience.
Lors de la deuxième vague, nous avons ajouté de courtes pauses aléatoires entre les pages (comme quelqu’un qui lit, réfléchi entre deux clics, cherche le bouton…). Le débit mesuré baisse un peu ; le scénario devient plus crédible. Les temps de réponse moyens montent par rapport à une rafale « machine » et c’est ce qui est attendu, c’est ce qu’on voulait montrer en itérant sur la méthode. Le scénario se rapproche du comportement réel, donc les chiffres sont plus fiables pour décider.
k6 est un outil open source édité par Grafana Labs. Il rejoue en parallèle les parcours que nous avons décrits dans des scripts, en augmentant le trafic palier par palier. À la fin de chaque simulation, il produit des rapports chiffrés.
Il peut tourner sur nos machines ou sur un serveur chez vous, sans passer par l’offre cloud de Grafana. On garde ainsi la main sur les créneaux, et on sait exactement d’où part le trafic.
Si vous utilisez déjà Grafana pour surveiller votre infrastructure, rien ne change : c’est le même éditeur, mais un autre outil. Pendant la campagne, nous comparons ce que montre k6 avec vos propres tableaux de bord.
Ce que vous recevez
Vous validez les parcours issus de vos statistiques, les niveaux de trafic, les critères de succès et le cadre opérationnel (créneaux, services tiers réellement appelés part vos pages).
Pendant les simulations, l’équipe infra commente ses courbes et nous faisons le lien avec les nôtres. Les chiffres ne correspondent pas toujours : vos outils peuvent compter beaucoup moins de connexions que k6 ne compte de requêtes, parce qu’une seule connexion transporte plusieurs requêtes. Ce sont simplement deux façons de compter.
Acte I : Campagne « référence » (soir, deux stacks)
Objectif : comparer l’ancienne et la nouvelle plateforme CMS avant la bascule, sans pauses « lecture » entre les pages (charge serveur plus soutenue).
Au trafic habituel comme au pic (×3), nous n’avons constaté aucune régression notable. Au pic, moins de 0,5 % des requêtes ont échoué, et plus de 99 % des vérifications de contenu étaient bonnes.
Nous avons aussi poussé jusqu’à huit fois le trafic habituel. À ce niveau, environ 5 % des requêtes échouaient sur la nouvelle plateforme. Nous l’avons signalé comme une réserve, sans en faire une alerte, car les critères de GO fixés avant la campagne portaient sur le trafic habituel et le pic. Nous revenons plus bas sur la façon de lire ce chiffre.
La migration n’est pas validée sur un ressenti, mais sur des seuils écrits à l’avance.
Figure 1 — Synthèse trafic nominal, succès 100%
Cette fois, les visites simulées incluaient des pauses de lecture, et l’équipe infrastructure du client suivait les simulations en direct. L’environnement de test n’avait pas de CDN : tout le trafic arrivait directement sur les serveurs, ce qui rendait le test plus exigeant que les conditions réelles.
Campagne référence | Campagne réalisme | |
Profil visiteur | Charge soutenue (Visites enchaînées sans pause ) | Avec pauses de lecture |
Décision pic ×3 | GO | GO |
Au-delà du pic | Stress ~5 % échecs (exploratoire) | ×6 ~99 % succès |
Apprentissage (Ce que la campagne a apporté ) | Des seuils écrits et vérifiés | Alignement avec l’infra |
Pendant la session en direct, l’équipe infrastructure voyait ses propres courbes monter en même temps que les nôtres. La discussion a porté sur des chiffres observés ensemble, et plus sur des hypothèses.
Dans nos campagnes, les échecs aux paliers les plus hauts étaient surtout des délais dépassés (délai fixé, souvent 30 s), et non des pages en erreur. Autrement dit, le site ralentissait au point de ne plus répondre à temps, mais les pages n’étaient pas cassées.
5 % d’échec au stress, est-ce grave ?
Pour la mise en production, non, tant que les critères de GO portent sur le trafic habituel et le pic. C’est en revanche un signal utile pour la suite : il situe la limite actuelle et aide à prévoir l’évolution de l’infrastructure si le trafic augmente.
Les chiffres varient aussi d’une campagne à l’autre, selon les pauses de lecture, la présence ou non d’un CDN, ou le nombre de simulations enchaînées dans la journée. Le rapport explique ces écarts pour qu’ils ne soient pas lus comme des incohérences.
Les chiffres peuvent varier entre vagues (think time, chemin réseau avec ou sans CDN, enchaînement de tirs) : ce n’est pas une incohérence, c’est le contexte à expliquer dans le rapport PDF.
Pour les curieux
k6 simule des « utilisateurs virtuels » (VU). Chacun déroule un parcours complet, de la première à la dernière page : c’est ce que k6 appelle une itération.
Les rapports affichent donc deux compteurs. Les requêtes par seconde comptent chaque page demandée, les itérations par seconde comptent les parcours complets. Comme un parcours contient en moyenne 2,2 pages dans nos campagnes, le premier chiffre est toujours plus élevé que le second.
Figure 3 - Vue des métriques d'un tir/simulation avec le report k6
Quelques règles simples encadrent chaque campagne :
Nous prenons en charge la campagne de bout en bout, du cadrage à la présentation des résultats.
Les scripts sont versionnés et réutilisables : après une évolution du site, les mêmes simulations peuvent être relancées, depuis nos machines ou directement sur votre infrastructure.
Un test de charge réussi, ce n’est pas le chiffre le plus haut atteint : c’est une décision partagée avec des preuves. Nous simulons vos parcours les plus fréquents ( pas une rafale artificielle sur la page d’accueil). Grafana k6 apporte la précision ; votre équipe infra apporte le contexte ; ensemble, on limite les surprises le jour du pic.
| Question | Réponse |
| Pourquoi ? | Éviter de découvrir la saturation le jour J ou à la migration |
| Est-ce utile pour vous ? | Si trafic, échéance et/ou parcours critiques |
| Est-ce un test de sécurité ? | Non. On mesure la capacité face à l'affluence, et la sécurité demande un audit à part |
| Quel est votre rôle ? | Valider les parcours, les niveaux de trafic, les critères de GO et les créneaux, puis suivre une session en direct avec votre équipe infrastructure. |
| Quels sont les livrables ? | Une présentation des résultats, une synthèse d’une page, un rapport PDF, le rapport détaillé de chaque simulation et une liste d’actions classées par priorité. |
Documentation Grafana k6
https://grafana.com/docs/k6/latest/
k6 Web Dashboard (export HTML)
https://grafana.com/docs/k6/latest/results-output/web-dashboard/
