Charge
Le système tient-il le trafic attendu, avec des temps de réponse acceptables ? C'est la question du quotidien.
Tests de performance
Une application ne s’écroule pas un mardi creux. Elle s’écroule au lancement d’une campagne, un vendredi soir, le premier jour des soldes — précisément quand chaque minute d’indisponibilité se compte en chiffre d’affaires.
Prendre rendez-vousQuatre questions, quatre tirs
Le système tient-il le trafic attendu, avec des temps de réponse acceptables ? C'est la question du quotidien.
À partir de quel volume se dégrade-t-il, et comment ? Un effondrement brutal ne se traite pas comme une dégradation progressive.
Tient-il huit heures d'affilée ? C'est là qu'apparaissent les fuites mémoire et la saturation lente que trois minutes de tir ne montrent pas.
Que se passe-t-il quand tout le monde arrive en même temps — ouverture d'une vente, notification poussée, campagne télévisée ?
Comment on procède
La qualité d’un test de performance se joue avant le tir, dans ce qu’on décide de simuler.
Nous partons de vos données réelles — trafic observé, répartition des parcours, heures de pointe, saisonnalité — pour construire un modèle de charge qui ressemble à vos utilisateurs. Un tir qui rejoue mille fois la page d’accueil ne dit rien de la tenue d’un tunnel de commande.
Puis on mesure ce qui compte pour l’utilisateur et pour l’exploitant : temps de réponse par percentile — pas la moyenne, qui masque les pires cas —, taux d’erreur, débit tenu, et la consommation des ressources côté serveur. Le rapport dit où ça casse, à partir de quel volume, et ce qui coûte le moins cher à corriger.
Avec quoi
JMeter, Gatling ou k6 selon le protocole, le volume et ce que vos équipes savent reprendre après nous.
On se branche sur votre supervision existante plutôt que d'ajouter un outil de plus : la corrélation entre la charge injectée et l'état des serveurs est ce qui donne le diagnostic.
Un rapport qui distingue le constat, l'hypothèse et la recommandation — et qui se lit par un décideur, pas seulement par un expert.
Au-delà du tir
Beaucoup de problèmes de performance ne se reproduisent pas en environnement de test : jeu de données trop petit, cache trop chaud, infrastructure trop propre. Quand c’est le cas, on travaille sur ce que la production dit d’elle-même — journaux, métriques, requêtes lentes, files d’attente — plutôt que de fabriquer un laboratoire qui ne ressemble à rien.
C’est souvent le chemin le plus court : le défaut est déjà visible dans vos données, personne n’a encore eu le temps de les regarder.
Questions franches
Deux à quatre semaines pour un premier périmètre : une semaine de cadrage et de modèle de charge, une semaine de mise en place et de tirs, une semaine d'analyse et de recommandations. Les tirs eux-mêmes prennent quelques heures ; tout le reste est du travail de préparation et d'interprétation.
Parfois, à faible volume et hors heures de pointe, quand aucun environnement ne ressemble à la production. Cela se décide avec vos exploitants, avec un plan d'arrêt clair. Nous ne le proposons jamais par défaut.
Il ne se copie pas dans un référentiel : il se déduit de votre métier. Une seconde sur un tunnel de paiement n'a pas le même poids que trois secondes sur un écran de paramétrage. Nous aidons à poser des seuils défendables, puis à les tenir version après version.
Un test de charge une fois par an ne protège rien : la dérive se joue entre deux livraisons. La suite logique est d'automatiser un tir réduit dans votre chaîne d'intégration, avec des seuils qui bloquent.
Un audit de votre démarche de test, sans engagement, pour savoir où vous en êtes vraiment.
Prendre rendez-vous
French 
English 
Hebrew