Étude de cas

Distinguer un défaut logiciel d’un défaut du harnais

Un test peut échouer parce que le logiciel présente un défaut ou parce que son environnement d’exécution contredit une règle légitime. Pour distinguer ces situations, il faut identifier le point de refus, corriger le montage et conserver les protections du programme.

Lors d’une revue interne du 15 octobre 2026, une suite a produit 26 échecs liés à l’emplacement de ses fichiers temporaires. L’analyse a montré pourquoi le résultat diagnostique ne suffisait pas, puis quelles conditions permettaient de retenir la réexécution comme preuve.

Un dossier temporaire au mauvais endroit

La première exécution indépendante a enregistré 1 549 tests réussis, 26 échecs et 74 sous-tests réussis. Le dossier temporaire imposé par le brief se trouvait dans un worktree Git, c’est-à-dire un répertoire de travail rattaché à un dépôt.

Deux protections ont refusé ce placement : l’une interdit d’établir un coffre dans un dépôt, l’autre interdit d’y écrire certaines sorties de précontrôle. Les erreurs vault_in_repository et c2_preflight_output_in_repository correspondaient à ces règles. Un dossier présenté comme temporaire au lanceur restait situé dans Git pour le programme.

Le nombre d’échecs ne permettait donc pas, à lui seul, de conclure à 26 régressions du produit. Il fallait vérifier si les cas atteignaient le comportement qu’ils devaient éprouver ou s’ils étaient arrêtés auparavant par une contrainte d’environnement.

Le diagnostic explique sans valider

Une première investigation a masqué la présence de .git dans le processus de test. Les 26 cas ont alors réussi. Ce résultat appuyait l’hypothèse d’un problème de placement, mais il ne validait pas l’exécution avec les protections normales : une condition utilisée par ces protections avait été modifiée.

Conserver cette distinction évite un raisonnement circulaire. Si le programme refuse une situation et que l’on altère la manière dont il détecte cette situation, la réussite obtenue ne prouve pas que le parcours normal fonctionne. Le diagnostic sert à localiser une cause possible; la preuve finale doit rétablir les conditions prévues.

Réexécuter les cas avec les gardes intactes

La réexécution retenue a utilisé un dossier neuf, hors de tout dépôt Git, et les 26 identifiants de tests concernés. Elle n’a ajouté aucun plugin de masquage et a conservé la configuration de test suivie par le dépôt. Les gardes du coffre et du précontrôle sont restées présentes.

Des vérifications distinctes ont comparé leur état avant et après. Elles ont confirmé la présence normale du fichier .git du worktree, l’absence d’ancêtre Git pour le dossier temporaire et l’absence de remplacement de la méthode de vérification d’existence utilisée pendant le diagnostic.

Les 26 tests ont réussi en 27.67 secondes. Le processus a terminé avec le code de sortie 0; le rapport JUnit contient 26 tests, zéro échec, zéro erreur et zéro test ignoré. Les comparaisons des gardes avant et après sont identiques.

Compter les résultats sans réécrire l’historique

Le résultat indépendant se décrit comme 1 549 réussites lors du premier passage, puis 26 réussites lors de la réexécution ciblée. Les 74 sous-tests appartiennent au premier passage. Il serait inexact de présenter cet ensemble comme une nouvelle exécution complète unique de 1 575 tests sans échec.

Cette précision conserve l’origine de chaque observation. Elle distingue aussi cette revue de la suite complète exécutée séparément par le producteur. Deux résultats compatibles peuvent renforcer l’examen sans devenir une seule et même exécution.

Une démarche réutilisable

Lorsqu’une série de tests échoue, le premier travail consiste à relever le code de refus et l’étape atteinte. Il faut ensuite comparer les contraintes de cette étape avec l’environnement fourni par le harnais. Si le montage est en cause, sa correction doit permettre de répéter les cas concernés avec les gardes du produit intactes.

Le rapport final doit conserver l’échec initial, identifier le changement d’environnement et attribuer chaque résultat à son exécution. Cette démarche permet de corriger le harnais sans affaiblir le programme et de reconnaître un défaut réel lorsque l’échec persiste dans des conditions valides.

Provenance de l’étude

Cette étude s’appuie sur le rapport indépendant du 15 octobre 2026, son supplément, les identifiants des 26 cas, le résultat JUnit de leur réexécution native et les contrôles des gardes. Le masquage de .git est conservé dans l’historique comme diagnostic et exclu de la preuve finale.