Intégration continue : performance et tests instables¶
L'intégration continue produit exactement ce que le SPC aime : des mesures nombreuses, répétées et comparables. Chaque commit relance les mêmes benchmarks et les mêmes tests. C'est là que les idées de Shewhart ont le mieux survécu dans le logiciel — sous d'autres noms.
Détecter une régression de performance¶
Le problème¶
Un benchmark de latence relancé à chaque commit donne une série temporelle bruitée : la même version du code peut varier de quelques pourcents d'un run à l'autre selon la machine, le cache, le voisinage. On veut savoir à quel commit la latence a réellement changé.
C'est un problème de carte de contrôle, avec une différence : on ne veut pas seulement savoir qu'il y a un changement, mais où il se situe dans la série. C'est le domaine de la détection de points de rupture (change point detection).
Trois grands projets, la même trajectoire¶
| Projet | Avant | Après |
|---|---|---|
| MongoDB | Inspection visuelle, puis seuils fixes | E-Divisive means + revue humaine |
| DataStax (Hunter, puis Apache Otava) | — | E-Divisive modifié, test de Student |
| Mozilla (Perfherder) | — | Test de Student sur 12 points avant/après |
| Chromium (Chromeperf) | — | Bissection + tests de Mann-Whitney et Kolmogorov-Smirnov |
MongoDB décrit son parcours dans un article de 2020 (Daly et al., ICPE 2020, arXiv 2003.00584) : l'équipe a d'abord inspecté les courbes à la main, puis utilisé un système à seuils, et « aucun des deux n'était suffisant ». L'algorithme E-Divisive means a « considérablement réduit le taux de faux positifs », et un humain revoit la liste des points de rupture avant toute action.
DataStax a dérivé de ce travail l'outil Hunter (ICPE 2023, arXiv 2301.03034). Détail révélateur : les auteurs remplacent le test de permutation d'origine par un test de Student parce que le premier « ne produisait pas de résultats déterministes » — un outil d'alerte qui ne donne pas la même réponse deux fois sur les mêmes données est inutilisable. La lignée se poursuit aujourd'hui dans le projet Apache Otava (arXiv 2505.06758).
Mozilla déclenche une alerte quand une régression est « soutenue dans le temps » : le point suspect plus 12 points suivants, comparés aux 12 précédents par un test de Student (wiki Perfherder). Une étude de juin 2026 menée avec des ingénieurs de Mozilla chiffre le résultat : 12,5 % des groupes d'alertes sont des faux positifs, et environ 6,8 % contiennent des régressions manquées. Un vote entre plusieurs méthodes de détection de rupture améliore le score F1 de 11 % (Besbes et al., arXiv 2606.18377).
Chromium utilise une bissection successive combinée à des tests de Mann-Whitney et de Kolmogorov-Smirnov, « pas exactement l'algorithme E-Divisive, mais assez proche » (code source).
Le lien avec Western Electric
La règle de Mozilla — « le point suspect et 12 points après » — est une
règle de séquence au sens de Western Electric : on n'alerte pas sur un
point isolé, on exige que le décalage persiste. Le filtre min_steppiness
de Chromium joue le même rôle. Ces équipes ont redécouvert, avec des
outils plus modernes, le compromis que les règles 2 à 4 encodaient en
1956 : sacrifier du délai de détection pour gagner en précision.
À retenir
Les trois projets ont convergé vers la même architecture : (1) pas de seuil fixe, (2) un test statistique qui cherche un changement durable, (3) un humain qui confirme avant d'agir. C'est exactement le schéma de Shewhart — signal statistique, puis enquête sur la cause — appliqué rétrospectivement plutôt qu'en temps réel.
Les tests instables¶
Le chiffre de Google¶
Un test instable (flaky test) est un test qui, d'après la définition de Google, « présente à la fois un résultat réussi et un échec avec le même code ». En 2016, John Micco publie sur le blog de test de Google (source) :
- environ 1,5 % de toutes les exécutions de tests donnent un résultat instable ;
- près de 16 % des tests présentent un certain degré d'instabilité ;
- environ 84 % des transitions de « réussi » à « échec » observées impliquent un test instable ;
- le taux d'apparition de nouveaux tests instables est à peu près égal au taux de correction.
Le troisième chiffre est le plus important pour notre sujet : 84 % des alarmes de l'intégration continue étaient des fausses alarmes. C'est le symptôme exact d'un système de détection dont l'ARL en contrôle est trop court (voir ARL).
« Trois échecs de suite » : une règle de séquence¶
La parade de Google : marquer un test comme instable pour qu'il ne signale un échec que s'il échoue trois fois de suite. Le prix est annoncé : un test de 15 minutes met 45 minutes à signaler une vraie casse.
Le script (§10) chiffre le gain, en supposant les échecs aléatoires indépendants :
| Taux d'échec aléatoire du test | Fausse alarme, 1 échec | Fausse alarme, 3 de suite |
|---|---|---|
| 1 % | 1 % | 1 sur un million |
| 5 % | 5 % | 1,3 sur dix mille |
| 20 % | 20 % | 8 sur mille |
C'est la règle 4 de Western Electric (« 8 points de suite du même côté ») transposée au monde binaire : exiger une séquence divise la probabilité de fausse alarme de façon géométrique, au prix d'un délai de détection fixe.
Limite importante : l'hypothèse d'indépendance
Ces chiffres supposent que les échecs successifs sont indépendants. Un test instable à cause d'une dépendance à l'ordre d'exécution ou à l'état d'une machine partagée échouera de manière corrélée — trois fois de suite sur la même machine — et la règle perd alors l'essentiel de son efficacité. L'étude de référence sur les causes des tests instables (Luo et al., FSE 2014, sur 201 correctifs dans 51 projets) identifie justement l'attente asynchrone, la concurrence et la dépendance à l'ordre parmi les causes dominantes ; les proportions exactes n'ont pas été vérifiées pour ce rapport.
Les durées de build¶
Les durées de build et de tests sont l'autre série naturelle de la CI. Elles ont une particularité qui disqualifie les règles de séquences : l'autocorrélation. Un cache chaud, une machine plus lente, une dépendance qui grossit — le build de 14 h ressemble à celui de 13 h.
Le script (§3) simule une série autocorrélée de coefficient 0,7 (modèle AR(1), illustratif) :
- la règle 1 seule signale 10 % des points ;
- les quatre règles de Western Electric en signalent 41 %.
La raison : la carte XmR estime la dispersion à partir des écarts entre points voisins, que l'autocorrélation rend artificiellement petits. Les limites sont trop serrées, et les séquences du même côté deviennent la norme.
Pour ce type de série, les options correctes sont celles des projets ci-dessus (détection de rupture), ou une carte construite sur les résidus d'un modèle qui absorbe l'autocorrélation — technique classique décrite dans les manuels de SPC, mais rarement outillée dans les plateformes de CI.