Transparency in Software Defect Prediction: A Dual Approach using Explainability and Tradeoff Analysis

Imaginez que vous êtes un détective essayant de trouver un unique traître caché dans une foule de mille citoyens innocents. Votre tâche est de désigner qui est le traître avant qu'il ne cause des problèmes. C'est la réalité quotidienne des ingénieurs logiciels, qui agissent comme des détectives numériques traquant les « bugs » ou les défauts dans le code informatique. Dans le monde de l'ingénierie logicielle, cette chasse est appelée Prédiction de Défauts Logiciels. C'est un jeu à enjeux élevés où l'objectif est de repérer le mauvais code avant qu'il ne casse le système.

Pour jouer à ce jeu, les ingénieurs utilisent des programmes informatiques appelés modèles d'Apprentissage Automatique (Machine Learning). Considérez ces modèles comme des assistants super intelligents qui ont parcouru des millions de lignes de code par le passé. Ils examinent une nouvelle portion de code et lui attribuent un « score de suspicion » compris entre 0 et 1. Un score de 0 signifie « totalement innocent », et un score de 1 signifie « coupable déclaré ». La partie délicate consiste à décider où tracer la ligne. Si vous fixez la ligne trop bas, vous pourriez accuser des innocents (fausses alertes), gaspillant ainsi le temps de tout le monde. Si vous la fixez trop haut, vous pourriez laisser passer le véritable traître (défauts manqués), ce qui pourrait être désastreux. Pendant longtemps, la plupart des détectives utilisaient une règle standard : « Si le score est supérieur à 0,5, il est coupable. » Mais comme cette nouvelle recherche le suggère, cette règle standard pourrait passer à côté de la plaque.

---

La grande idée du papier : Trouver la ligne parfaite

Dans leur article, « Transparency in Software Defect Prediction: A Dual Approach using Explainability and Tradeoff Analysis », Nitin Sai Bommi, Umamaheswara Sharma Bhutamapuram et Atul Negi soutiennent que l'ancienne règle du « 0,5 » est comme utiliser un chapeau de taille unique pour une foule de personnes ayant des tailles de tête très différentes. Cela ne convient à personne.

Les auteurs proposent une nouvelle façon de jouer au jeu. Au lieu de faire aveuglément confiance à la limite par défaut, ils suggèrent deux astuces ingénieuses pour trouver la ligne parfaite pour chaque situation spécifique. Leur objectif est de maximiser la différence entre attraper les méchants (Probabilité de Détection) et éviter les fausses accusations (Probabilité de Fausse Alerte). Ils veulent attraper le traître sans perdre de temps avec les spectateurs innocents.

Astuce n°1 : Le changement de poteau de but (Seuil Optimal)

La première astuce consiste à ajuster la « ligne de suspicion ». Les chercheurs ont testé trois types différents d'assistants de détection : la Régression Logistique, le Naïve Bayes et les Réseaux de Neurones. Ils ont découvert que le chiffre magique n'était pas 0,5 pour aucun d'entre eux.

• Pour l'assistant de Régression Logistique, le point idéal se situait autour de 0,35.
• Pour le Naïve Bayes, il était encore plus bas, à 0,3.
• Pour le Réseau de Neurones, il était de 0,38.

Voyez cela comme l'accordage d'une radio. Si vous laissez le cadran au milieu, vous pourriez entendre des parasites. Mais si vous le déplacez légèrement vers la gauche ou la droite, soudain, la musique devient parfaitement claire. En abaissant le seuil (vers 0,3 ou 0,4), ces modèles sont devenus bien meilleurs pour repérer les réels défauts tout en maintenant un faible nombre de fausses alertes. Dans leurs tests sur 36 versions différentes de 10 projets logiciels, cet ajustement simple a systématiquement surpassé la méthode standard.

Astuce n°2 : Le jeu du « Et si ? » (Explications Contrefactuelles)

La deuxième astuce est un peu plus magique. Les auteurs ont utilisé ce qu'on appelle des Explications Contrefactuelles. Imaginez que vous avez la photo d'un suspect « coupable » (un module de code défectueux). Le modèle dit : « Ceci est mauvais. » Maintenant, imaginez que vous puissiez demander au modèle : « Et si je changeais cette toute petite chose ? Est-ce que cela deviendrait innocent ? »

Les chercheurs ont fait exactement cela. Ils ont pris du code que le modèle savait déjà être bon ou mauvais et ont demandé : « Quel petit changement ferait basculer ceci de bon à mauvais, ou de mauvais à bon ? » Ils ont utilisé ces scénarios « et si » pour créer de nouveaux exemples synthétiques de code. Ensuite, ils ont réinjecté ces nouveaux exemples dans le modèle pour lui donner un entraînement supplémentaire.

C'est comme un entraîneur montrant à un joueur la vidéo d'un jeu parfait, puis lui demandant : « Et si tu avais raté le ballon d'un pouce ? » et utilisant cela pour lui apprendre comment s'ajuster. L'article a montré que cette méthode aidait les modèles à mieux comprendre les données, bien qu'elle ne batte pas toujours l'astuce simple du « changement de poteau de but ».

Ce qu'ils ont trouvé (et ce qu'ils n'ont pas trouvé)

Les résultats étaient prometteurs mais spécifiques. Les auteurs ont mesuré leur succès à l'aide de deux outils principaux :

1. Taux d'Omission Faux (FOR) : À quelle fréquence ont-ils manqué un défaut réel ? (Ils voulaient que cela soit bas).
2. Pourcentage de Budget Économisé (PSB) : Combien de temps et d'argent ont-ils économisés en ne testant pas le code propre ?

Lorsqu'ils ont utilisé leur nouvelle méthode de « changement de poteau de but », les modèles ont été plus performants que l'ancienne méthode. Par exemple, avec le modèle de Régression Logistique, le seuil optimal moyen était de 0,35, et cela a considérablement réduit le taux de défauts manqués par rapport au seuil standard de 0,5.

Cependant, les auteurs prennent soin de ne pas présenter cela comme une solution miracle. Ils déclarent explicitement que, bien que ces méthodes améliorent l'équilibre entre la détection des bugs et l'évitement des fausses alertes, elles ne résolvent pas tout. La méthode contrefactuelle (le jeu du « et si ? ») a aidé, mais elle n'a pas toujours donné les meilleurs résultats car le modèle n'est pas parfait pour générer ces exemples fictifs en premier lieu.

Ils soulignent également que leurs conclusions sont basées sur des ensembles de données spécifiques (le dépôt PROMISE) et pourraient différer si elles étaient appliquées à des types de projets logiciels totalement différents. Ils n'ont pas prouvé que cela fonctionne pour chaque logiciel de l'univers, mais ils ont montré que pour les projets testés, s'éloigner de la règle par défaut de 0,5 est une décision intelligente.

Pourquoi cela importe

Cet article est un rappel que dans le monde du logiciel, le « taille unique » est souvent un piège. La façon standard de décider ce qu'est un bug et ce qu'il n'est pas peut être trop rigide. En demandant simplement à l'ordinateur : « Quel est le meilleur trait à tracer pour ce travail spécifique ? » et en utilisant des questions de type « et si ? » pour apprendre davantage, nous pouvons construire des logiciels plus sûrs et moins coûteux à maintenir. C'est un petit changement de perspective, mais pour les détectives traquant les bugs dans l'obscurité numérique, c'est peut-être la lampe de poche dont ils avaient besoin.