📊 statistics

An Upper Bound on the Probability That a User Encounters an Undiscovered Defect

Cet article propose une borne supérieure sans distribution pour la probabilité qu'un utilisateur rencontre un défaut logiciel non découvert, démontrant que la fraction de défauts signalés exactement une seule fois durant la phase de test bêta ( $s/n$ ) sert d'estimation conservatrice et indépendante du modèle, adaptée aux décisions de mise en production.

Auteurs originaux : Carlos M. Hernández-Suárez, Karla Hernández-Cuevas

Publié 2026-07-21

📖 7 min de lecture🧠 Analyse approfondie

CC BY 4.0

Auteurs originaux : Carlos M. Hernández-Suárez, Karla Hernández-Cuevas

Article original sous licence CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Ceci est une explication générée par l'IA de l'article ci-dessous. Elle n'a pas été rédigée ni approuvée par les auteurs. Pour une précision technique, consultez l'article original. Lire la clause de non-responsabilité complète

La Grande Chasse aux Bugs : Pourquoi compter les bugs ne suffit pas

Imaginez que vous êtes un chef s'apprêtant à servir un banquet géant à des milliers d'invités. Avant d'ouvrir les portes, vous avez une équipe de dégustateurs (vos testeurs bêta) qui ont mangé la nourriture et crié : « Hé, cette soupe est trop salée ! » ou « Il y a un caillou dans ce gâteau ! ». Vous réparez les problèmes qu'ils trouvent. Mais voici la question effrayante : si vous ouvrez les portes dès maintenant, quelle est la probabilité qu'un invité qui entre au hasard morde dans un caillou que vous avez manqué ?

C'est le cœur d'un problème en informatique appelé « fiabilité logicielle ». Depuis des décennies, les développeurs tentent de répondre à cela en comptant. Ils demandent : « Combien de cailloux reste-t-il dans la cuisine ? ». Ils utilisent des mathématiques complexes pour deviner le nombre total de bugs cachés. Mais il y a un piège : savoir qu'il reste dix cailloux ne vous dit pas si ces dix sont tous au fond du garde-manger (où une seule personne pourrait les trouver) ou si un énorme rocher est posé juste devant la porte d'entrée (où tout le monde trébuchera dessus). Les anciennes méthodes restent souvent bloquées à essayer de compter les cailloux, ignorant que certains cailloux sont bien plus dangereux que d'autres à cause de leur emplacement.

Pour résoudre cela, nous devons arrêter de compter les cailloux et commencer à compter les gens. Nous devons savoir la probabilité qu'un utilisateur soit réellement confronté à un problème. Cet article s'attaque précisément à cette question : au lieu de demander « Combien de bugs reste-t-il ? », il demande « Quelle est la chance qu'un utilisateur rencontre un bug qu'il n'a jamais vu auparavant ? ». Il s'avère qu'il existe un moyen étonnamment simple de le deviner, en utilisant une astuce qui observe la fréquence à laquelle les testeurs trouvent le même bug plus d'une fois.

La grande idée de l'article : La règle de la « merveille unique »

Les auteurs, Carlos M. Hernández-Suárez et Karla Hernández-Cuevas, proposent un raccourci ingénieux. Ils suggèrent que pour deviner le risque qu'un utilisateur tombe sur un bug caché, vous n'avez pas besoin de connaître le nombre total de bugs, la façon dont le logiciel est construit, ni même combien de personnes l'utilisent. Vous avez juste besoin d'examiner vos rapports de bugs et de compter quelque chose de très spécifique : les bugs qui ont été signalés exactement une seule fois.

Utilisons une analogie. Imaginez que vous êtes un détective essayant de découvrir combien de types différents d'espèces extraterrestres visitent votre ville. Vous avez un registre de signalements.

Si vous voyez « Zog » 50 fois, vous savez que Zog est un extraterrestre commun.
Si vous voyez « Xyl » 3 fois, Xyl est un peu plus rare.
Mais si vous voyez « Blorp » exactement une fois, et jamais plus, qu'est-ce que cela vous dit ?

L'article soutient que ces « Blorps » — les bugs vus exactement une fois — sont la clé. Ils appellent la fraction de ces signalements uniques ( $s$ ) divisée par le nombre total de signalements ( $n$ ) une « borne supérieure conservatrice ». En langage clair : Le pourcentage de bugs qui ont été signalés exactement une fois est une estimation prudente, du « pire cas », du pourcentage d'utilisateurs qui seront confrontés à un nouveau bug jamais vu.

Pourquoi cela fonctionne (La logique de la « porte fermée »)

Vous pourriez vous demander : « Et s'il y avait des bugs cachés derrière d'autres bugs ? Comme une pièce secrète derrière une porte verrouillée ? » Les auteurs abordent cela avec un raisonnement brillant.

Imaginez que le logiciel est un immense manoir avec de nombreuses pièces. Certains bugs sont dans le couloir (faciles à trouver). Certains sont dans une pièce secrète derrière une porte verrouillée (difficiles à trouver).

Si un utilisateur frappe la porte verrouillée (un bug), il ne peut pas accéder à la pièce secrète située derrière.
Par conséquent, le nombre de personnes pouvant atteindre la pièce secrète est toujours inférieur ou égal au nombre de personnes qui frappent la porte verrouillée.

Les auteurs démontrent qu'en raison de cette structure « imbriquée », vous n'avez pas besoin de vous soucier des pièces cachées. Les bugs à « signalement unique » que vous avez trouvés tiennent déjà compte du risque des bugs cachés. Si un bug est signalé une fois, il agit comme une « porte » qui limite le risque de tout ce qui se trouve derrière lui. Ainsi, compter les signalements uniques suffit à couvrir toute la maison.

Ce qu'ils ont fait et ce qu'ils ont trouvé

Les auteurs ne se sont pas contentés de deviner ; ils ont construit un modèle mathématique appelé la « Forme Canonique » (imaginez cela comme un type spécial d'urne ou de bocal rempli de balles colorées). Ils ont prouvé mathématiquement que si vous traitez vos rapports de bugs comme des tirages de balles dans ce bocal, la fraction des balles qui apparaissent une seule fois ( $s/n$ ) est l'estimation exacte du maximum de vraisemblance pour la « masse manquante » (les bugs invisibles).

Crucialement, ils ont montré que cette estimation est conservatrice. Cela signifie qu'elle a tendance à surestimer le risque plutôt qu'à le sous-estimer.

Pourquoi c'est une bonne chose : Si vous êtes un développeur décidant de sortir un logiciel, vous voulez être prudent. Si les mathématiques disent « Il y a 5 % de chances d'un bug », et que la chance réelle est de 3 %, vous êtes en sécurité. Si les mathématiques disaient 3 % et que la chance réelle était de 5 %, vous seriez en difficulté. Cette méthode garantit que vous êtes toujours du bon côté, en privilégiant la prudence.

Ils ont testé cette idée à l'aide de simulations informatiques (création de populations de bugs fictives avec des réponses connues).

Dans un test portant sur 20 bugs, ils ont constaté qu'en augmentant le nombre d'utilisateurs testés (augmentant la taille de l'échantillon de 25 à 400), leur estimation ( $s/n$ ) était toujours supérieure ou égale au nombre réel de bugs invisibles.
Par exemple, avec 100 utilisateurs de test, le risque invisible réel était de 0,0059, et leur estimation était de 0,0063. L'estimation était légèrement trop élevée (conservatrice), mais jamais trop basse.

Ce que ce n'est PAS (Les règles du jeu)

L'article est très clair sur ce que cette méthode ne peut pas faire, et il est important de bien comprendre cela :

Ce n'est PAS pour compter les bugs. Cela ne vous dit pas « Il reste 50 bugs ». Cela vous dit « Il y a 2 % de chances qu'un utilisateur rencontre un bug ».
Ce n'est PAS pour les listes de bugs publiques. Les auteurs excluent explicitement l'utilisation de cette méthode sur les bases de données de bugs standards (comme celles sur Internet). Pourquoi ? Parce que dans ces listes, un bug est généralement signalé une fois par une personne, même si 1 000 personnes l'ont trouvé. Le « compte » est perdu. Pour utiliser cette méthode, vous avez besoin de données indiquant : « Ce bug a été rencontré par 50 utilisateurs différents », et non pas seulement « Ce bug a été signalé ».
Ce n'EST PAS une boule de cristal magique pour le futur. Cela donne un instantané du risque en ce moment même. Si vous réparez les bugs et testez à nouveau, vous devez recalculer.

L'essentiel

Cet article offre une réponse directe et sans détour à la décision de mise en production. Il dit : « Ne vous inquiétez pas de savoir combien de bugs se cachent dans l'obscurité. Regardez simplement combien de bugs vos testeurs ont trouvés exactement une seule fois. Ce nombre, divisé par votre nombre total de tests, est votre estimation prudente de la limite supérieure de la probabilité qu'un utilisateur reste bloqué sur un bug que vous avez manqué. »

C'est un outil qui transforme une incertitude complexe et effrayante en un chiffre simple et sûr, garantissant que lorsque le logiciel est livré, les développeurs ont une vision claire et conservatrice du risque pour leurs utilisateurs.

Résumé Technique : Une borne supérieure de la probabilité qu'un utilisateur rencontre un défaut non découvert

Énoncé du problème
L'article traite d'une lacune critique dans la prise de décision relative à la gestion des versions logicielles : déterminer la probabilité qu'un utilisateur d'un produit publié rencontre un défaut qui n'a pas été découvert lors des tests bêta. La littérature existante se concentre principalement sur l'estimation du nombre de défauts restants (en utilisant des modèles de croissance de la fiabilité logicielle ou des méthodes de capture-recapture) ou sur la couverture des classes non vues dans les contextes de fuzzing. Cependant, ces approches ne parviennent pas à répondre directement à la question de la mise en production car :

Les méthodes basées sur le comptage nécessitent un « profil opérationnel » (la distribution de la manière dont le logiciel est utilisé sur le terrain) pour convertir un nombre de défauts en une probabilité de défaillance rencontrée par l'utilisateur. Ce profil est notoirement difficile à estimer.
Les méthodes de couverture (par exemple, Good-Turing) ont été appliquées au fuzzing logiciel, où l'échantillonneur est une machine générant des entrées. Dans ce contexte, l'abondance d'un bug reflète la randomicité de la machine, et non la fréquence avec laquelle les utilisateurs humains le rencontrent.
Complexité structurelle : Le logiciel n'est pas une population plate et échangeable comme les espèces biologiques ; il possède une structure de joignabilité (arbres ou DAG) où certains défauts sont « verrouillés » derrière d'autres. Les méthodes existantes ne tiennent pas compte de la manière dont cette architecture affecte la probabilité qu'un utilisateur rencontre un défaut spécifique.

Les auteurs soutiennent que la décision de mise en production nécessite une estimation directe de la masse manquante pondérée par l'utilisateur : la probabilité qu'un utilisateur aléatoire exécute un défaut non vu lors des tests.

Méthodologie
L'article propose un estimateur sans distribution basé sur la construction canonique d'urnes (Hernández-Suárez [10]), adaptée au contexte de la mise en production logicielle.

Interprétation des données : Chaque rapport de test bêta est traité comme un tirage de la population d'utilisateurs, et chaque défaut distinct est traité comme une « classe ». Les données d'entrée sont l'ensemble des comptes de rapports pour chaque défaut.
La forme canonique : Les auteurs définissent un modèle de population où les classes se divisent en :
- Classes ordinaires : Défauts observés plusieurs fois.
- Le Réservoir (composante de type « tous différents ») : Une composante théorique contenant un nombre infini de classes avec des probabilités dérisoires, de telle sorte que tout tirage dans celle-ci produit une classe unique, auparavant non vue.
Estimation du maximum de vraisemblance (MLE) :
- L'article démontre que sous la forme canonique, la fraction des défauts rapportés exactement une seule fois ( $s/n$ ), où $s$ est le nombre de singletons et $n$ le nombre total de rapports, est l'estimation exacte du maximum de vraisemblance (MLE) de la proportion non vue ( $U$ ).
- Biais conservateur : La forme canonique assigne chaque singleton (un défaut vu exactement une fois) au « réservoir non vu » plutôt que de le traiter comme une classe ordinaire rare. Par conséquent, l'estimation $s/n$ surestime systématiquement la véritable proportion non vue. Cela crée une borne supérieure unilatérale et conservatrice, ce qui est la direction souhaitée pour une décision de mise en production (errer du côté de la prudence).
Gestion de l'architecture : La méthode est invariante à la structure interne du logiciel (arbre vs DAG). Les auteurs soutiennent que la « joignabilité » d'un défaut est déjà encodée dans les comptes de rapports : un défaut derrière une porte fermée est rapporté par zéro utilisateurs, tandis qu'un défaut sur un chemin commun est rapporté par de nombreux utilisateurs. Puisque l'estimateur repose uniquement sur ces comptes, il limite automatiquement le risque des défauts imbriqués et cachés sans avoir besoin de modéliser le graphe de joignabilité.

Principales contributions

Recadrage de l'estimand : L'article déplace l'attention de l'estimation d'un nombre de défauts résiduels vers l'estimation de la probabilité de rencontrer un défaut non vu par l'utilisateur, éliminant ainsi le besoin d'un profil opérationnel.
Justification théorique : Il fournit un fondement rigoureux de MLE pour l'estimateur $s/n$ dans le cadre de l'urne canonique, prouvant que $s/n$ est l'exact MLE de la masse non vue sous cette construction.
Borne supérieure conservatrice : Il établit que $s/n$ n'est pas seulement un estimateur mais une borne supérieure conservatrice sur le risque utilisateur, car la construction canonique force les singletons dans le réservoir non vu, garantissant que l'estimation ne sous-estime jamais le risque.
Invariance structurelle : Il démontre que l'estimateur est robuste à la complexité de l'architecture logicielle, car la multiplicité des rapports capture intrinsèquement les contraintes de joignabilité.
Validation : L'estimateur est validé par rapport à des populations synthétiques ayant une vérité de terrain connue, confirmant que l'estimation moyenne atteint ou dépasse systématiquement la masse manquante réelle ( $E[s/n] \geq E[U]$ ).

Résultats

Validation synthétique : Les expériences sur des populations synthétiques (tant uniformes que à queue lourde) montrent que l'estimateur $s/n$ est précis mais systématiquement conservateur. Dans les scénarios où la population est presque saturée (tous les défauts trouvés), la véritable masse manquante approche de zéro, pourtant $s/n$ reste positif en raison de la sur-attribution des singletons au réservoir non vu.
Nature unilatérale : La probabilité que l'estimation dépasse la véritable proportion non vue est élevée (par exemple, de 0,89 à 1,00 dans les scénarios testés), confirmant la fiabilité de la borne pour les décisions prudentes.
Exigences en données : L'article souligne que la méthode nécessite des données de niveau rencontre (par exemple, la télémétrie du canal bêta ou les rapports de plantage qui enregistrent le nombre d'utilisateurs affectés par défaut). Il précise explicitement que les archives publiques de défauts standards ne sont pas adaptées car elles enregistrent généralement une seule entrée par bug, quel que soit le nombre d'utilisateurs l'ayant rencontré, détruisant ainsi les données de multiplicité nécessaires à l'estimateur.

Signification et affirmations
L'article prétend fournir une réponse directe et sans distribution à la question de la mise en production logicielle. Sa signification réside dans :

Combler le fossé : Il relie la théorie statistique de la couverture (Good-Turing) aux contraintes pratiques de la mise en production logicielle, en traitant spécifiquement la nature « face à l'utilisateur » du risque.
Élimination des hypothèses : Il supprime le besoin de profils opérationnels, d'hypothèses sur le nombre total de défauts ou de modèles de la structure interne du programme.
Aide à la décision : Il offre une métrique conservatrice et fondée ( $s/n$ ) qui permet aux développeurs de décider quand publier : continuer les tests jusqu'à ce que la borne supérieure de la probabilité de rencontrer un défaut non vu tombe en dessous d'un seuil de risque toléré.

Les auteurs restent modestes quant aux limites de la méthode, notant qu'elle s'applique à l'état du logiciel au moment du calcul et nécessite des types spécifiques de données de télémétrie (niveau rencontre) plutôt que des journaux de suivi de bugs standards. Ils ne prétendent pas résoudre le problème de l'estimation du nombre total de défauts, mais plutôt celui de la probabilité spécifique d'exposition de l'utilisateur à l'inconnu.