La moyenne de l’industrie logicielle dans les années 1980 était de 30 à 60 défauts par millier de lignes de code. L’équipe Cleanroom d’IBM a livré un incrément de compilateur de 20 000 lignes avec 53 défauts trouvés lors des tests. Soit 2,6 par KLOC. Certains incréments individuels de 10 000 lignes sont entrés en test système sans aucun défaut détecté.

La partie la plus étrange ? Les programmeurs étaient interdits d’exécuter leur propre code.

Ce que signifie réellement Cleanroom software engineering

Cleanroom software engineering, développé par le mathématicien Harlan Mills chez IBM dans les années 1980, est un processus fondé sur la théorie qui repose sur la formal specification, le structured design et la mathematical correctness verification au lieu du Unit Testing et du debugging. Le nom vient de la fabrication de semi-conducteurs. Dans une usine de puces, on n’introduit pas de poussière pour l’essuyer plus tard. On prévient la contamination dès le départ.

En Cleanroom, les développeurs ne font pas de Unit Testing. Ils ne debugguent pas. Ils vérifient.

Le processus partitionne le logiciel en incréments, généralement de 5 000 à 15 000 lignes de code. Chaque incrément est spécifié, conçu, vérifié, puis testé statistiquement comme une unité complète. Les développeurs écrivent le code, mais ils ne sont pas autorisés à le compiler ni à l’exécuter pendant le développement. La première fois que le code s’exécute est lors des tests système formels.

Comment la box structure verification remplace le debugging

Le mécanisme central est la box structure specification. Chaque composant est défini sur trois niveaux.

La black box spécifie le comportement externe. Elle définit les stimuli et les réponses sans mentionner l’état interne.

La state box ajoute les variables d’état internes et la fonction de transition d’état.

La clear box est l’implémentation réelle, qui doit être un raffinement structuré de la state box.

Cette hiérarchie compte car elle permet de vérifier la correction à chaque niveau indépendamment. On prouve que la state box implémente la black box, et que la clear box implémente la state box.

Voici à quoi cela ressemble en pratique pour une fonction avec un correctness argument non trivial :

from typing import Optional

def binary_search(arr: list[int], target: int) -> Optional[int]:
    """
    Black box spec:
      Pre:  arr is sorted in non-decreasing order.
      Post: Returns index i such that arr[i] == target,
            or None if target is not present.
    """
    low, high = 0, len(arr) - 1

    while low <= high:
        mid = (low + high) // 2

        if arr[mid] == target:
            return mid
        elif arr[mid] < target:
            low = mid + 1
        else:
            high = mid - 1

    return None

Le verification argument de la boucle est ce qui compte. L’équipe examine cela ensemble et confirme trois faits. Premièrement, si arr[mid] == target, la postcondition est satisfaite immédiatement. Deuxièmement, si arr[mid] < target, la cible ne peut exister qu’à des indices supérieurs à mid, donc définir low = mid + 1 préserve l’invariant que la cible est dans arr[low:high+1] si elle existe du tout. Troisièmement, si arr[mid] > target, l’argument symétrique s’applique pour high = mid - 1.

Ce n’est pas une Code Review où quelqu’un demande si vous avez pensé aux tableaux vides. C’est une preuve de groupe structurée que chaque entrée possible produit la sortie spécifiée.

Les chiffres d’IBM derrière l’affirmation de zéro défaut

IBM a appliqué Cleanroom à trois projets majeurs à la fin des années 1980 et au début des années 1990 : la COBOL Structuring Facility (40 000 lignes), un programme de vol d’hélicoptère de l’Air Force (35 000 lignes) et un système de planification de transport spatial de la NASA (45 000 lignes).

Les données COBOL/SF sont les plus détaillées. Le premier incrément de 20 000 lignes a été développé avec des formal specifications, un box structure design et une correctness verification de groupe. Les développeurs n’étaient pas autorisés à compiler ni à exécuter leurs modules pendant le développement. Le code est allé directement en test système.

Résultat : 53 défauts trouvés pendant les tests. Plus de 90 % de tous les défauts ont été capturés pendant la phase de vérification avant que le code ne s’exécute.

Pour comparaison, les projets IBM conventionnels de l’époque trouvaient environ 60 % des défauts avant l’exécution. Cleanroom a inversé la proportion.

Certains incréments, particulièrement les plus petits de moins de 10 000 lignes, ont rapporté zéro défaut trouvé en test système. C’est de là que vient l’affirmation des “10 000 lignes avec zéro défaut”. Cela s’est produit. Ce n’était pas universel, mais c’était suffisamment reproductible pour qu’IBM en fasse une référence standard.

Pourquoi ne pas exécuter son propre code produit moins de bugs

C’est la partie qui fait exploser le cerveau des développeurs. Comment ne pas tester peut-il produire un meilleur code ?

La réponse est cognitive, pas technique. Quand vous savez que vous ne pouvez pas exécuter le code pour vérifier votre travail, vous concevez plus soigneusement. Vous écrivez des fonctions plus petites. Vous pensez aux Edge Cases avant de taper. Vous vous appuyez sur le Type System et la programmation structurée parce que vous n’avez pas de filet de sécurité.

C’est la même raison pour laquelle les chirurgiens utilisent des listes de contrôle. La contrainte force un mode mental différent.

Il y a aussi une couche de contrôle qualité statistique. Cleanroom utilise le statistical usage testing basé sur un operational profile. Les cas de test sont tirés de la distribution de probabilité du comportement réel de l’utilisateur, pas de la supposition du développeur sur l’emplacement des bugs. Cela signifie que vous mesurez la fiabilité, pas seulement que vous chassez les bugs.

Les trade-offs qui ont maintenu Cleanroom dans une niche

Cleanroom n’a pas conquis le monde. Il y a des raisons.

Premièrement, la barrière de formation est sévère. Vous avez besoin d’équipes capables d’écrire des formal specifications et de construire des mathematical correctness arguments. La plupart des diplômés en CS en 2025 n’ont jamais fait une preuve formelle d’une fonction non triviale.

Deuxièmement, le coût de conception initial est élevé. IBM a rapporté que le texte de specification dépassait le texte de design par quatre à un sur le projet COBOL/SF. Vous échangez du temps de conception contre du temps de test. Cela fonctionne pour les compilateurs et les logiciels de vol. Cela ne fonctionne pas pour une application CRUD avec des exigences de pivot hebdomadaires.

Troisièmement, l’affirmation de zéro défaut concerne la defect density, pas l’absence de tous les bugs. Un incrément Cleanroom peut encore avoir des specification errors. Si la black box est fausse, la clear box vérifiée est aussi fausse, juste par construction.

Comment voler la discipline Cleanroom sans la bureaucratie

Vous ne pouvez probablement pas adopter Cleanroom complet. Votre Chef de Produit n’attendra pas un ratio specification-à-code de quatre à un. Mais vous pouvez voler les morceaux de grande valeur.

1. Écrivez le contract avant l’implémentation.

Utilisez des preconditions, postconditions et invariants pour définir votre black box. Même des commentaires informels vous forcent à réfléchir aux limites avant d’optimiser.

from typing import List, Tuple

def partition(nums: List[int], pivot: int) -> Tuple[List[int], List[int]]:
    """
    Black box spec:
      Pre:  True (any list of integers is valid).
      Post: left contains exactly the elements of nums where x <= pivot.
            right contains exactly the elements of nums where x > pivot.
            len(left) + len(right) == len(nums).
    """
    left = [x for x in nums if x <= pivot]
    right = [x for x in nums if x > pivot]

    # Runtime checks act as lightweight verification witnesses.
    assert all(x <= pivot for x in left)
    assert all(x > pivot for x in right)
    assert len(left) + len(right) == len(nums)

    return left, right

2. Remplacez certains Unit Tests par des verification arguments.

Avant d’écrire le test, écrivez un argument d’une phrase sur pourquoi le code est correct. Si vous ne pouvez pas construire cette phrase, la conception est trop complexe. C’est la pratique Cleanroom la plus efficace pour les équipes modernes.

3. Utilisez le property-based testing comme statistical usage testing.

Des outils comme Hypothesis en Python ou fast-check en JavaScript génèrent des entrées à partir d’une distribution. C’est spirituellement plus proche du statistical testing de Cleanroom que les Unit Tests basés sur des exemples.

4. Séparez la compilation de la vérification.

Si vous avez l’habitude d’écrire une ligne, compiler, corriger la faute de frappe, écrire une autre ligne, vous debugguez par réflexe de secousse. Essayez d’écrire une unité logique complète avant de l’exécuter. L’inconfort est le but.

FAQ

Cleanroom est-il encore utilisé aujourd’hui ?

Il survit dans les domaines critiques pour la sécurité et la mission. La NASA, la FAA et certains fabricants de dispositifs médicaux utilisent des variantes du processus. Il est rare dans le logiciel commercial.

Puis-je vraiment livrer du code sans Unit Testing ?

Seulement si vous le remplacez par quelque chose d’aussi rigoureux. Les équipes Cleanroom ont passé plus d’heures en vérification que la plupart des équipes en testing. Le temps n’a pas disparu. Il a été déplacé vers la gauche.

Cleanroom garantit-il zéro bug ?

Non. Il garantit que l’implémentation correspond à la specification avec une haute probabilité. Si la specification est fausse, le bug est conservé parfaitement.

Quel a été l’impact sur la productivité ?

IBM a rapporté une productivité de plus de 400 lignes de code par personne-mois sur le projet COBOL/SF, en grande partie parce que le temps de test fortement réduit a compensé l’effort de conception accru.

Conclusion

La prochaine fois que quelqu’un affirme qu’une méthodologie livre du logiciel zero-defect, demandez les données du projet. Les chiffres Cleanroom d’IBM sont réels, mais ils provenaient d’un contexte spécifique : des équipes expérimentées, une formation formelle, une livraison incrémentale et une volonté de vérifier au lieu de debugguer.

L’incrément de 10 000 lignes avec zéro défaut est réalisable. Il coûte juste plus de prévoyance que la plupart des organisations ne sont prêtes à payer.