Performance Engineering
Mesurer avant de conclure, et savoir ce que le chiffre veut dire.
01 — Le problème
On vous dit que l'application « rame ». Vous avez un chiffre — un temps de réponse moyen — qui ne correspond à l'expérience de personne. Les tests de charge, quand ils existent, tournent sur un environnement qui ne ressemble pas à la production, avec un jeu de données dix fois plus petit. Les résultats ne se comparent pas d'une campagne à l'autre.
02 — Ce que nous faisons
- 01
Définir ce qu’il faut tenir, et pour qui
Objectifs exprimés en percentiles sur des parcours réels, pas en moyenne globale. La moyenne masque exactement les utilisateurs qui souffrent.
- 02
Construire un environnement de test représentatif
Volumétrie de données, configuration, dépendances externes. Sans cela, les résultats ne sont pas transposables.
- 03
Exécuter les bons types de tests
Montée en charge, stress, endurance, capacité. Chacun répond à une question différente ; les confondre produit des conclusions fausses.
- 04
Analyser jusqu’à la cause
Profilage applicatif, plans d’exécution SQL, contention, saturation. Un rapport qui s’arrête au symptôme ne sert à rien.
- 05
Installer la mesure dans la durée
Campagne rejouable en CI, résultats comparables dans le temps, seuil d’alerte sur régression.
04 — Ce que vous recevez
Des livrables nommés, pas des promesses. Vous savez ce que vous recevez avant de commencer.
Objectifs de performance chiffrés et justifiés
Scénarios de charge rejouables
Rapport d’analyse avec causes identifiées
Recommandations priorisées par gain estimé
05 — Écosystème technique
Les outils ne font pas la qualité. Nous les maîtrisons pour pouvoir choisir le bon, pas pour en faire un argument.
- k6
- Gatling
- JMeter
- Grafana
- Prometheus
- OpenTelemetry