Les tests de performance dans la CI/CD : seuils, cadence et limites

Une campagne de tests en quatre phases convient à une grande évolution. Quand l'application change tous les jours, elle arrive trop tard. On installe alors dans la chaîne d'intégration et de livraison un contrôle de performance court, qui tourne à chaque modification et fait échouer la chaîne quand une exigence n'est plus tenue.

Le mécanisme : un seuil, un code de sortie

La documentation de k6 décrit les seuils comme des critères de réussite sur des métriques, que l'on utilise souvent pour traduire des objectifs de niveau de service. Un seuil s'écrit sous la forme méthode d'agrégation, opérateur, valeur. Quand l'un d'eux est franchi, k6 termine avec un code de sortie non nul, que n'importe quel outil de CI lit comme un échec. Gatling suit le même principe avec ses assertions : si l'une échoue, la simulation échoue. Azure Load Testing propose des critères d'échec sur le temps de réponse moyen ou le nombre d'erreurs. JMeter, lui, se lance en ligne de commande, sans interface graphique, pour ce type d'usage : sa documentation écrit en toutes lettres de ne pas lancer un test de charge en mode graphique.

Un essai, rejoué

Le script ci-dessous fixe deux seuils : moins de 1 % de requêtes en échec, et un 95e percentile du temps de réponse sous 200 ms.

import http from 'k6/http';
import { sleep } from 'k6';

export const options = {
  vus: 5,
  duration: '10s',
  thresholds: {
    http_req_failed: ['rate<0.01'],      // moins de 1 % de requêtes en échec
    http_req_duration: ['p(95)<200'],    // 95e percentile sous 200 ms
  },
};

export default function () {
  http.get(`${__ENV.CIBLE}/${__ENV.CHEMIN}`);
  sleep(1);
}

CIBLE=http://localhost:8089 CHEMIN=produit k6 run seuils.js
echo "code de sortie : $?"

L'essai a été exécuté le 5 novembre 2026 avec k6 v2.3.0, lancé par l'image Docker officielle (la commande ci-dessus en est la forme native), contre un petit serveur HTTP local écrit pour l'occasion : le chemin produit répond aussitôt, le chemin produit-lent attend 0,4 seconde. L'essai est artificiel ; il montre le mécanisme, pas une performance.

Sur le chemin rapide, les deux seuils sont tenus et le code de sortie est 0 :

✓ 'p(95)<200' p(95)=2.13ms
✓ 'rate<0.01' rate=0.00%
code de sortie : 0

Sur le chemin lent, le premier seuil est franchi et le code de sortie est 99 :

✗ 'p(95)<200' p(95)=402.19ms
✓ 'rate<0.01' rate=0.00%
level=error msg="thresholds on metrics 'http_req_duration' have been crossed"
code de sortie : 99

Dans une chaîne, il suffit que l'étape de test lance cette commande : le code non nul arrête le pipeline et renvoie le problème à l'équipe qui a poussé la modification. La documentation de k6 liste douze intégrations (GitHub Actions, GitLab, Jenkins, Azure Pipelines, CircleCI, TeamCity et d'autres) ; celle de Gatling cite GitHub Actions, GitLab CI/CD, Jenkins, Azure DevOps, TeamCity et Bamboo, pour l'exécution de simulations Gatling Enterprise.

Ce qu'il faut mettre dans le pipeline, et ce qu'il faut en sortir

Le guide de k6 sur les tests automatisés pose lui-même des réserves. Mettre la performance dans la chaîne de livraison allonge sensiblement le processus de livraison, et les gros tests sont mieux placés hors du pipeline. La page donne des cadences en exemple : des tests de fumée à chaque changement de branche en recette technique, des tests de pré-livraison plusieurs fois par jour en période de livraison, une recette deux à trois fois par semaine, un test de fumée synthétique en production toutes les cinq minutes. Elle ajoute qu'il ne faut pas se fier au seul résultat réussi ou échoué, et recommande de démarrer avec un seuil qui avertit avant d'en faire un seuil qui bloque.

Une répartition qui découle de ces réserves : un test court de quelques minutes à chaque changement, avec des seuils sur les temps de réponse et le taux d'erreurs ; les tests de charge nominale, d'endurance et aux limites, plus longs, à une cadence plus basse, par exemple chaque nuit, sur un environnement proche de la production.

Shift-left : l'idée et sa limite

On dit « shift-left » pour déplacer les tests plus tôt dans le calendrier. La documentation de k6 n'emploie pas ce terme ; elle parle de détecter plus tôt les problèmes dans le cycle de développement. L'idée est la même que celle de ce guide : plus tôt, moins cher à corriger. Sa limite tient à l'environnement : un test de cinq minutes dans la chaîne peut tourner sur une machine éloignée de la production, et décèle une régression plutôt qu'une capacité. Il prévient d'une dégradation entre deux versions ; il n'établit pas combien d'utilisateurs l'application peut servir.

Ce que disent les mesures de livraison

L'organisation DORA mesure la performance de livraison avec cinq indicateurs : le délai de livraison d'un changement, la fréquence de déploiement et le temps de rétablissement après un déploiement raté pour le débit ; le taux d'échec des changements et le taux de reprise des déploiements pour l'instabilité. Son rapport 2025, présenté le 23 septembre 2025, associe l'adoption de l'IA à un meilleur débit de livraison et toujours à une moindre stabilité, qu'il attribue à des volumes de changements supérieurs aux contrôles automatiques en aval. Le texte intégral du rapport n'a pas été lu ici, seulement son annonce. La lecture pour un testeur de performance reste simple : plus on livre souvent, plus les contrôles automatiques pèsent.

À faire dès maintenant

• Choisissez deux ou trois seuils tirés des exigences du besoin de tests : un percentile de temps de réponse et un taux d'erreurs.
• Lancez-les d'abord en mode avertissement, sans bloquer, et regardez plusieurs séries de résultats avant d'en faire un blocage.
• Gardez la campagne de capacité à part, sur l'environnement représentatif.

Rédigé avec l’aide d’une IA, relu et validé par Philippe Naveau.