Le statistical debugging était censé mettre fin à l’ère du printf. Instrumentez votre code, collectez des traces de milliers d’exécutions, exécutez une analyse de corrélation, et regardez l’outil classer chaque branche et chaque null check par sa probabilité de causer le crash. Cela marchait magnifiquement dans les articles du milieu des années 2000. En pratique, la plupart des équipes qui l’ont essayé ont obtenu du bruit, de la surcharge, et un tableau de bord en qui personne ne croyait.

L’idée n’est pas morte, mais elle est sous assistance respiratoire. Si vous vous demandez pourquoi une technique avec des fondements théoriques si élégants n’est jamais devenue un outil standard, la réponse est que la réalité viole la plupart de ses hypothèses.

Ce qu’est réellement le statistical debugging

Le statistical debugging traite la localisation de bugs comme un problème de classification. Vous instrumentez un programme pour observer des prédicats, des choses comme x > 0, ptr == NULL, ou return_code != 0, pendant l’exécution. Certaines exécutions crashent ou échouent aux tests (échantillons négatifs). D’autres réussissent (échantillons positifs). Vous scorez ensuite chaque prédicat par la force avec laquelle sa présence corrèle avec l’échec.

La métrique classique est le increase score :

increase(p) = P(failure | p is true) - P(failure | p is false)

Un prédicat avec un increase score proche de 1 est presque toujours vrai quand le programme échoue et presque toujours faux quand il réussit. Ce prédicat est un fort candidat pour l’emplacement du bug.

L’approche est issue du travail fondateur de Ben Liblit, Alex Aiken, et d’autres sur Cooperative Bug Isolation (CBI). CBI a instrumenté GCC et collecté des traces de milliers d’utilisateurs. Dans des études contrôlées, il pouvait isoler de vrais bugs dans des programmes comme bc, exif, et rhythmbox.

Comment l’instrumentation fonctionne réellement

Au niveau de l’implémentation, vous insérez des probes légères. Une probe vérifie un prédicat et incrémente un compteur. Voici une version simplifiée de ce à quoi ressemble un predicate sampler en Python :

import atexit
import json
from collections import defaultdict

class PredicateSampler:
    def __init__(self):
        self.observations = defaultdict(lambda: {"true": 0, "false": 0})
        self.outcomes = defaultdict(lambda: {"true": 0, "false": 0})

    def observe(self, predicate_id: str, value: bool, failed: bool):
        bucket = "true" if value else "false"
        self.observations[predicate_id][bucket] += 1
        if failed:
            self.outcomes[predicate_id][bucket] += 1

    def compute_increase(self, predicate_id: str) -> float:
        obs = self.observations[predicate_id]
        out = self.outcomes[predicate_id]
        total_true = obs["true"] + obs["false"]
        if total_true == 0:
            return 0.0

        p_fail_given_true = out["true"] / obs["true"] if obs["true"] > 0 else 0
        p_fail_given_false = out["false"] / obs["false"] if obs["false"] > 0 else 0

        return p_fail_given_true - p_fail_given_false


sampler = PredicateSampler()

# Example probe inserted before a suspicious branch
user_id = 42
sampler.observe("user_id > 0", user_id > 0, failed=False)

Dans un vrai système, ces probes sont injectées à la compilation ou via bytecode rewriting. Les données sont uploadées vers un collecteur central après chaque exécution.

Le mur de la taille d’échantillon : la plupart des produits ne génèrent pas assez de crashes

Voici la première hypothèse qui casse. Le statistical debugging a besoin d’assez d’échantillons d’échec pour distinguer le signal du bruit. CBI s’appuyait sur des milliers d’utilisateurs bénévoles exécutant des builds instrumentées de GCC. Ce modèle fonctionne pour des compilateurs open source avec des bases d’utilisateurs massives. Il ne fonctionne pas pour un produit SaaS B2B avec cinquante clients.

Les maths sont impitoyables. Si votre bug se manifeste dans 1 % des exécutions, et que vous voulez un intervalle de confiance de 95 % sur votre score de corrélation, vous avez besoin de centaines d’échecs avant que les classements ne se stabilisent. De nombreux bugs de production sont encore plus rares. Une race condition qui se déclenche une fois par millier de requêtes sous des conditions de charge spécifiques sera invisible au statistical debugging pendant des mois.

Les outils d’observabilité modernes font face au même problème de rareté, mais le résolvent différemment. Le distributed tracing capture le chemin d’échec exact quand le bug se produit. Vous n’avez pas besoin de mille exemples. Vous avez besoin d’une trace avec assez de contexte.

La surcharge de l’instrumentation : l’effet observateur est réel

Le deuxième problème est le coût. Chaque vérification de prédicat ajoute des cycles CPU et de la pression mémoire. Les premières implémentations de CBI rapportaient des surcharges entre 10 % et 100 %. C’est bien pour une étude de recherche. Ce n’est pas bien pour un service de paiement le jour du Black Friday.

Des chercheurs ont ensuite développé des stratégies d’échantillonnage sparse, comme échantillonner seulement une fraction des évaluations de prédicats ou utiliser des schémas adaptatifs qui se concentrent sur les branches rarement vues. Cela aide, mais cela introduit un nouveau problème : vous pourriez manquer le prédicat exact qui explique l’échec parce que vous ne l’échantilloniez pas pendant l’exécution qui crashe.

Les équipes de production se battent déjà pour chaque milliseconde de latence p99. Ajouter un profiler qui ralentit tout de 15 % pour détecter un bug qui arrive deux fois par semaine est un argument difficile à vendre à n’importe quel responsable d’ingénierie.

Les faux positifs noient le signal

Même avec assez de données et peu de surcharge, les classements mentent. Un prédicat peut être fortement corrélé avec l’échec sans être causal. L’exemple classique : une instruction de logging qui s’exécute uniquement dans le chemin de gestion d’erreur. logger.error() est vrai dans 100 % des exécutions qui échouent et 0 % des exécutions qui réussissent. Son increase score est parfait. Il est aussi complètement innocent.

Distinguer la corrélation de la causalité exige des connaissances du domaine que le modèle statistique n’a pas. Vous vous retrouvez avec une liste top dix où trois entrées sont des logs d’erreur inoffensifs, deux sont des vérifications défensives qui se déclenchent après le vrai bug, et une est une fausse piste d’une bibliothèque tierce. Le vrai bug est classé septième.

C’est la partie qui a tué l’adoption au sein des équipes qui l’ont réellement essayé. Les développeurs ont cessé d’ouvrir le rapport statistique parce qu’ils n’y croyaient pas. Un outil en qui vous ne croyez pas est pire que pas d’outil. Vous perdez du temps à enquêter sur de fausses pistes et commencez à ignorer de vraies.

Les systèmes distribués ont cassé le modèle monolithique

Le statistical debugging suppose que vous pouvez instrumenter un seul programme, collecter une seule trace, et attribuer l’échec à des prédicats à l’intérieur de ce programme. Les logiciels modernes ne fonctionnent pas comme ça.

Une requête API échouée peut toucher un load balancer, trois microservices, deux caches, une file de messages, et une base de données. Le bug pourrait être un timeout dans le service A, un retry manquant dans le service B, ou une entrée de cache périmée dans le service C. Le statistical debugging n’a aucun mécanisme pour attribuer un échec à travers les service boundaries.

La corrélation de prédicats fonctionne quand l’échec est local et déterministe. Elle s’effondre quand l’échec émerge des effets d’interaction entre des services déployés indépendamment. La recherche était construite pour des programmes monolithiques en C, pas pour des clusters Kubernetes.

Ce qui fonctionne à la place : l’observabilité ciblée

Le statistical debugging essayait de trouver des bugs sans savoir quoi chercher. C’est un problème plus difficile qu’il n’y paraît. La plupart des équipes obtiennent de meilleurs résultats avec des outils qui se concentrent sur des signaux spécifiques à forte valeur.

Le structured logging avec des correlation IDs vous permet de suivre une seule requête à travers chaque service qu’elle touche. Vous n’avez pas besoin de mille échecs. Vous avez besoin d’une trace complète.

L’error tracking avec le regroupement de stack traces vous dit où les crashes se regroupent. Les algorithmes de regroupement de Sentry font essentiellement une forme simplifiée de clustering statistique, mais ils opèrent sur des stack traces plutôt que sur des prédicats arbitraires. Le signal est plus fort parce que le modèle comprend la structure du code.

Des outils d’analyse dynamique comme les sanitizers et les fuzzers trouvent des bugs de manière déterministe, sans attendre la significativité statistique. AddressSanitizer attrape les use-after-free exactement quand ils se produisent. Vous n’avez pas besoin de mille exécutions pour voir le pattern.

Comment piquer les bonnes idées

Le statistical debugging a échoué en tant que plateforme autonome, mais certaines de ses techniques valent encore la peine d’être empruntées.

Si vous exécutez des tests A/B ou des canary deployments, vous pouvez appliquer la logique de corrélation à des métriques opérationnelles. Comparez des prédicats comme cache_hit == false ou retry_count > 0 entre le canary et le groupe de contrôle. Vous avez une expérience naturelle avec des milliers d’échantillons et un environnement contrôlé.

Vous pouvez aussi utiliser l’échantillonnage léger de prédicats comme une aide au débogage, pas comme un service de production. Exécutez-le en CI sur votre suite de tests d’intégration. Si une branche spécifique ou un null check est vrai dans chaque test échoué et faux dans chaque test réussi, c’est un indice fort pour savoir où placer votre point d’arrêt.

Voici un script minimal que vous pouvez exécuter contre une sortie JUnit XML pour trouver des prédicats suspects :

import xml.etree.ElementTree as ET
from collections import defaultdict


def find_suspicious_predicates(xml_path: str, predicate_log_path: str):
    tree = ET.parse(xml_path)
    failures = {
        tc.get("name")
        for tc in tree.iter("testcase")
        if tc.find("failure") is not None
    }

    predicate_counts = defaultdict(lambda: {"pass": 0, "fail": 0})

    with open(predicate_log_path) as f:
        for line in f:
            test_name, pred, value = line.strip().split(",")
            bucket = "fail" if test_name in failures else "pass"
            predicate_counts[pred][bucket] += 1

    for pred, counts in predicate_counts.items():
        total = counts["pass"] + counts["fail"]
        if total < 10:
            continue
        fail_rate = counts["fail"] / total
        if fail_rate > 0.8 and counts["fail"] >= 3:
            print(f"Suspect: {pred} (fail rate: {fail_rate:.2f})")


# Run this after a test suite that logs predicate evaluations
find_suspicious_predicates("test-results.xml", "predicates.log")

Ce n’est pas du CBI. C’est une version étroite et contrôlée de la même idée qui s’intègre réellement dans un workflow moderne.

Les hypothèses qui font échouer le statistical debugging en production

Le statistical debugging était une solution brillante à un problème que la plupart des équipes n’ont pas sous la forme que les chercheurs supposaient. Vous avez besoin d’une échelle massive, d’une instrumentation à faible surcharge, de codebases monolithiques, et de bugs qui apparaissent assez souvent pour atteindre la significativité statistique. Enlevez l’un de ces éléments et les maths cessent de fonctionner.

Les équipes qui ont bénéficié de la recherche étaient celles qui ont adapté son insight central, l’analyse de corrélation, à des contextes où les hypothèses tiennent. Les métriques de canary. Le feedback de fuzzing. L’analyse de suite de tests. Le reste d’entre nous a obtenu de meilleurs résultats avec le tracing, le logging structuré, et l’analyse dynamique déterministe.

Si vous êtes curieux au sujet du travail original, la thèse de doctorat de Ben Liblit sur Cooperative Bug Isolation vaut toujours la peine d’être lue. Ne vous attendez juste pas à la déployer comme votre stratégie de débogage principale le trimestre prochain.