Défauts : classification, prédiction et coût¶

Les défauts sont la matière première du contrôle qualité. Trois traditions de recherche les étudient : leur classification (pour lire le processus à travers eux), leur prédiction (pour savoir où chercher), et leur coût (pour savoir quand chercher). Chacune a une leçon pour la surveillance des agents — et la troisième contient l'un des mythes les plus tenaces du génie logiciel.

Lire le processus dans les défauts : la classification orthogonale¶

La classification orthogonale des défauts (ODC, Chillarege et al., IBM, IEEE TSE 1992, copie de l'auteur) est la tentative la plus aboutie de faire du SPC à partir des défauts. Chaque défaut reçoit deux attributs indépendants :

un type parmi huit (fonction, interface, vérification, affectation, synchronisation, construction, documentation, algorithme). La distribution des types indique où en est le développement : une proportion anormale de défauts de « fonction » tard dans le cycle signale un problème de conception ;
un déclencheur : la condition qui a fait apparaître le défaut. La distribution des déclencheurs mesure la complétude de la vérification.

Pourquoi c'est pertinent pour les agents

L'ODC est le précédent direct des taxonomies de défaillances d'agents (MAST, les dix motifs de Tambon et al., les anti-motifs de trajectoires). Sa leçon méthodologique s'applique telle quelle : une taxonomie n'est utile que si l'on suit l'évolution de sa distribution dans le temps, sous carte de contrôle — par exemple la part de « vérification absente » dans les échecs d'un orchestrateur, mois après mois.

Prédire où sont les défauts¶

Les mesures de processus battent les mesures de code¶

Graves, Karr, Marron et Siy (IEEE TSE 2000, rapport) : « les mesures de processus fondées sur l'historique des modifications sont plus utiles pour prédire le taux de défauts que les mesures du code » ; le nombre de fois qu'un code a été modifié prédit mieux ses défauts que sa longueur.
Nagappan et Ball (Microsoft, ICSE 2005, résumé) : le churn relatif (volume de modifications rapporté à la taille) sépare les binaires de Windows Server 2003 sujets aux défauts des autres avec 89 % de précision ; le churn absolu prédit mal.
Nagappan, Murphy et Basili (ICSE 2008, PDF) : sur Windows Vista, des mesures de structure organisationnelle (combien d'équipes et d'ingénieurs touchent un binaire, depuis quel niveau hiérarchique) prédisent les binaires défaillants avec 86,2 % de précision et 84,0 % de rappel — mieux que le churn, la complexité, les dépendances ou la couverture.

Les modèles ne se transportent pas¶

Zimmermann et al. (ESEC/FSE 2009, résumé) ont testé 622 prédictions « croisées » (un modèle entraîné sur un projet, appliqué à un autre) entre 12 applications : seulement 3,4 % fonctionnaient directement. Même domaine ou même processus ne suffit pas.

La revue de Hall et al. (IEEE TSE 2012) retient 36 études sur 208 comme suffisamment documentées, et constate que la méthodologie de construction du modèle influence fortement sa performance. Shepperd, Bowes et Hall (IEEE TSE 2014) vont plus loin : dans une méta-analyse de 42 études, le groupe de recherche explique 31 % de la performance rapportée, contre 1,3 % pour le choix de l'algorithme — un résultat contesté depuis, que les auteurs maintiennent.

Leçon pour un orchestrateur

Deux résultats se transposent directement. D'abord, les mesures de processus (churn relatif, nombre de modifications, nombre d'acteurs) prédisent mieux que l'inspection du code — ce qui justifie de surveiller les étiquettes et le volume des runs plutôt que de relire chaque diff. Ensuite, une ligne de base ne se transporte pas : les limites d'une carte calculées sur un dépôt, un type de tâche ou un modèle ne valent pas pour un autre (3,4 % de transfert réussi).

La fiabilité ne se mesure pas aux très hauts niveaux¶

Les modèles de croissance de fiabilité (Goel et Okumoto 1979, Musa 1987) modélisent la décroissance du taux de défaillance à mesure qu'on corrige les défauts trouvés en test. Ils reposent sur des hypothèses fortes (correction parfaite et instantanée, défauts indépendants), et une calibration de la NASA sur dix modèles concluait qu'il n'existe « pas de meilleur modèle pour tous les cas » (NTRS).

Butler et Finelli (IEEE TSE 1993, NTRS) ont montré que démontrer statistiquement une fiabilité de l'ordre de \(10^{-7}\) à \(10^{-9}\) défaillance par heure exige des quantités de test « exorbitantes », et que les modèles de croissance ne lèvent pas cette impossibilité. C'est la version extrême de la limite rencontrée dans Mesurer un agent et dans l'horizon à 99 % de METR : démontrer une très haute fiabilité par l'essai est hors de portée ; on la construit par la conception et le contrôle, on ne la prouve pas par la mesure.

Le mythe du « coût multiplié par 100 »¶

Ce qu'on répète¶

Une affirmation circule dans presque tous les cours de génie logiciel : un défaut coûte 100 fois plus cher à corriger en production qu'en conception, et le coût croît exponentiellement avec le retard.

Ce que disent les sources¶

Boehm et Basili (IEEE Computer, 2001, PDF) écrivent que corriger un problème après livraison est « souvent » 100 fois plus cher — et précisent dans le même paragraphe que pour les petits systèmes non critiques, le facteur est « plutôt 5 pour 1 que 100 pour 1 ». Le même article indique que les revues par les pairs attrapent environ 60 % des défauts.
Laurent Bossavit, dans The Leprechauns of Software Engineering, a remonté la chaîne de citations du graphique classique jusqu'à des notes de cours internes d'IBM dont les données n'ont pas pu être retrouvées (selon les comptes rendus de The Register et Hillel Wayne ; le livre n'a pas été lu pour ce rapport).
Menzies, Nichols, Shull et Layman (Empirical Software Engineering 2017, arXiv 1609.04886) ont testé l'effet sur 171 projets (47 376 enregistrements de défauts) : « nous n'avons trouvé aucune preuve de l'effet de retard ». Réserves : tous les projets utilisaient le Team Software Process, et l'étude mesure l'effort de correction, pas le coût total d'une défaillance en production.

Pourquoi ce mythe compte pour les agents

L'argument « il faut tout attraper le plus tôt possible, parce que ça coûte 100 fois plus cher après » sert souvent à justifier une revue exhaustive en amont. Les données ne soutiennent pas un facteur constant et universel. Cela ne rend pas la détection précoce inutile — un identifiant secret fusionné ou une faille exploitée ont un coût réel —, mais cela autorise à raisonner par type de défaut et par risque, ce que fait l'échantillonnage à sévérité variable, plutôt qu'à exiger de tout contrôler avant fusion.

À retenir

L'ODC montre comment lire le processus dans la distribution des défauts — le modèle à suivre pour les taxonomies de défaillances d'agents.
Les mesures de processus (churn relatif, organisation) prédisent mieux les défauts que les mesures du code ; les modèles ne se transportent pas d'un projet à l'autre.
Une très haute fiabilité ne se démontre pas par l'essai.
Le « coût ×100 » est au mieux « souvent » vrai pour les grands systèmes ; une étude sur 171 projets ne trouve pas d'effet de retard.