L’ingénierie logicielle Cleanroom offre 0,1 défaut par mille lignes de code. La moyenne industrielle est de 10 à 50. Le hic, c’est que le Cleanroom complet exige que vous divisiez votre équipe en auteurs et vérificateurs, rédigiez des spécifications formelles avant chaque module, et interdisiez aux développeurs d’exécuter leur propre code jusqu’à ce qu’une équipe de test distincte l’ait validé statistiquement.

La plupart des managers d’ingénierie regardent ce processus, font un rapide calcul sur les effectifs, et décident que la qualité ne vaut pas le overhead. Ils ont moitié raison. Le processus Cleanroom complet est lourd. Mais les principes sous-jacents sont légers, et vous pouvez les adopter sans embaucher une armée de vérification ou interdire cargo test.

Ce qu’est Vraiment Cleanroom

Cleanroom est un processus de développement logiciel développé chez IBM dans les années 1970 par Harlan Mills. Le nom vient de la fabrication de semiconducteurs : vous empêchez les conditions qui créent des défauts, plutôt que de les inspecter après coup. L’affirmation centrale est que le logiciel peut être correct par construction si vous le concevez avec assez de soin pour que les bugs soient impossibles avant que le code ne soit écrit.

La méthode repose sur trois pratiques : le développement incrémental sous contrôle statistique des processus, la conception fonctionnelle avec des structures de boîtes, et les tests statistiques d’usage réalisés par une équipe séparée. Ces trois pratiques sont interdépendantes. En briser une, et les autres perdent leur pouvoir.

Cette interdépendance est l’origine du mythe du overhead. Les équipes supposent qu’elles doivent adopter les trois ou rien. Ce n’est pas vrai. Les pratiques se renforcent mutuellement, mais chacune produit de la valeur par elle-même.

Où Vit Réellement le Overhead

Les 80% de overhead que les gens craignent viennent de deux exigences spécifiques.

Premièrement, la règle de non-exécution. En Cleanroom complet, le développeur qui écrit le code ne le compile pas, ne l’exécute pas, ne le unit teste pas. Une équipe de vérification séparée gère toute l’exécution. Cela force les développeurs à raisonner sur chaque cas avant de taper, ce qui est exactement pourquoi le code fonctionne du premier coup. Cela exige aussi de doubler vos effectifs d’ingénierie ou de diviser votre équipe existante en deux groupes qui se ressentiront mutuellement.

Deuxièmement, l’étape de vérification formelle. Avant d’écrire l’implémentation de boîte claire, l’équipe rédige une spécification de boîte noire et un raffinement de boîte d’état, puis prouve à la main que la boîte d’état est équivalente à la boîte noire. C’est une preuve au crayon-papier, pas un assistant de preuve. Ça marche, mais cela prend du temps et une formation que la plupart des équipes n’ont pas.

La troisième pratique, le développement incrémental avec contrôle statistique des processus, est en fait gratuit si vous faites déjà des sprints. Vous livrez de petits incréments, mesurez la densité de défauts par incrément, et arrêtez le processus quand un incrément dépasse son objectif de défauts pour comprendre ce qui a mal tourné avec la méthode. Ce sont simplement des rétrospectives data-driven avec une définition plus stricte de “done.”

Le Sous-Ensemble Pragmatique : Garder la Structure, Supprimer la Bureaucratie

Vous pouvez obtenir la majeure partie de la réduction de défauts de Cleanroom en gardant la discipline structurelle et en écartant les mandats organisationnels.

Voici ce qu’il faut garder.

Écrivez le contrat avant le code. Pas une spécification formelle en notation Z. Juste une déclaration claire des inputs, outputs, préconditions et postconditions. Si vous ne pouvez pas écrire ce que correct signifie, vous ne pouvez pas écrire de code correct.

Encodez les machines à états explicitement. La plupart des bugs vivent dans des transitions d’état que le développeur supposait impossibles. Définissez vos états et transitions dans une table ou une structure de données avant d’écrire la logique.

Faites tester votre logique par quelqu’un d’autre. La séparation d’autorité et de vérification est l’idée la plus puissante de Cleanroom. Vous n’avez pas besoin d’une équipe séparée. Vous avez besoin d’une personne qui n’a pas écrit le code pour concevoir les cas de test. Quand vous testez votre propre code, vous testez vos propres hypothèses.

Mesurez la densité de défauts par incrément. Suivez combien de bugs échappent à chaque phase. Si les bugs d’intégration continuent de passer à travers, le problème n’est pas des développeurs négligents. Le problème est que votre processus permet aux bugs d’intégration d’exister.

Voici ce qu’il faut abandonner.

Abandonnez la règle de non-exécution. Laissez les développeurs exécuter leur propre code. La discipline de raisonner d’abord est précieuse même si vous vous permettez une rapide vérification de cohérence après. Le point est de réfléchir avant de lancer le compilateur, pas de prétendre que le compilateur n’existe pas.

Abandonnez la preuve formelle à la main. À moins d’écrire du logiciel avionique, la preuve au crayon-papier est excessive. Remplacez-la par des property-based tests et du design guidé par les types. Ce sont des versions mécanisées du même raisonnement, et elles tournent en CI.

Abandonnez l’exigence de tests statistiques d’usage. Le Cleanroom complet teste contre des profils d’usage, pas contre la code coverage. C’est excellent si vous avez les données. Si vous ne les avez pas, le property-based testing et le mutation testing vous donnent quasiment la même confiance avec des outils que vous utilisez déjà.

Un Workflow Cleanroom Léger en Python

Voici à quoi cela ressemble en pratique pour un seul module. Commencez par le contrat.

"""
Black Box: Token Bucket Rate Limiter

Stimuli: request(n), add_tokens(k)
Precondition: n > 0, k >= 0, capacity > 0
Postcondition:
  - request(n) grants iff available tokens >= n
  - request(n) reduces available tokens by n if granted
  - add_tokens(k) increases available tokens by k, capped at capacity
  - available tokens never negative, never exceeds capacity
"""

Puis encodez la state machine.

from enum import Enum, auto

class RateLimitState(Enum):
    READY = auto()      # tokens >= 1, requests may grant
    DEPLETED = auto()   # tokens == 0, requests deny

# Transitions depend on token count, not external events
# READY -> DEPLETED when tokens reach 0
# DEPLETED -> READY when tokens added above 0

Puis écrivez l’implémentation.

import time
from dataclasses import dataclass

@dataclass
class TokenBucket:
    capacity: int
    tokens: int
    refill_rate: float
    last_refill: float

    def _refill(self) -> None:
        now = time.monotonic()
        elapsed = now - self.last_refill
        added = int(elapsed * self.refill_rate)
        if added > 0:
            self.tokens = min(self.capacity, self.tokens + added)
            self.last_refill = now

    def request(self, n: int) -> bool:
        if n <= 0:
            raise ValueError("request must be positive")
        self._refill()
        if self.tokens >= n:
            self.tokens -= n
            return True
        return False

    def add_tokens(self, k: int) -> None:
        if k < 0:
            raise ValueError("cannot add negative tokens")
        self.tokens = min(self.capacity, self.tokens + k)

Le contrat vit dans le docstring. La state machine est explicite. L’implémentation est courte et vérifiable par inspection. Ce n’est pas du Cleanroom complet. Ce n’est pas non plus du cowboy coding.

L’Étape de Vérification que Vous Pouvez Vraiment Faire

En Cleanroom complet, une équipe séparée écrit des tests statistiques basés sur des profils d’usage. Dans la version pragmatique, vous écrivez des property-based tests et faites les réviser par un collègue.

from hypothesis import given, strategies as st

@given(
    capacity=st.integers(min_value=1, max_value=1000),
    initial=st.integers(min_value=0, max_value=1000),
    requests=st.lists(st.integers(min_value=1, max_value=100), max_size=50),
)
def test_token_bucket_never_overdrafts(capacity, initial, requests):
    bucket = TokenBucket(
        capacity=capacity,
        tokens=min(initial, capacity),
        refill_rate=0.0,
        last_refill=time.monotonic(),
    )

    for n in requests:
        granted = bucket.request(n)
        assert bucket.tokens >= 0
        if granted:
            # tokens were deducted, so pre-request balance was sufficient
            pass
        else:
            # request denied, current tokens insufficient
            assert bucket.tokens < n

Ce test ne vérifie pas des outputs spécifiques. Il vérifie une invariante : le bucket ne concède jamais plus de tokens qu’il n’en a. C’est la version property-based d’une preuve Cleanroom. Elle s’exécute automatiquement, trouve des edge cases auxquels vous n’aviez pas pensé, et n’exige pas d’équipe de vérification séparée.

Les Trade-Offs Sont Réels

Le Cleanroom pragmatique n’est pas gratuit. Écrire des contrats avant le code demande de la discipline. Les machines à états explicites donnent l’impression de boilerplate quand le code est “évident.” Faire tester sa logique par quelqu’un d’autre demande de la coordination.

C’est aussi moins puissant que la vraie chose. La règle de non-exécution du Cleanroom complet force une profondeur de raisonnement que vous ne pouvez pas reproduire quand le REPL est à un keystroke de distance. La preuve formelle attrape des erreurs logiques que les property-based tests pourraient manquer si vos properties sont fausses.

Mais la comparaison n’est pas Cleanroom pragmatique contre Cleanroom complet. La comparaison est Cleanroom pragmatique contre ce que vous faites maintenant. Si votre processus actuel livre 20 défauts par KLOC et que le Cleanroom pragmatique vous amène à 5, c’est une amélioration de 4× pour une fraction du overhead.

Quand Cela Vaut le Coup

N’utilisez pas cela pour chaque fonction utilitaire. Utilisez-le pour du code où un bug est coûteux : autorisation, facturation, protocoles distribués, machines à états avec plus de trois états, et tout ce qui a causé un incident en production deux fois.

Le signal que vous en avez besoin n’est pas la complexité. C’est la surprise répétée. Si votre équipe continue de trouver la même catégorie de bug en tests ou en production, le problème n’est pas que les développeurs sont négligents. Le problème est que le contrat du code n’a jamais été défini, donc “correct” n’a jamais été spécifié.

Commencez par un Module

Vous n’avez pas besoin d’approbation du management ou d’un overhaul de processus. Choisissez un module qui vous a déjà mordu. Écrivez son contrat dans un docstring avant de toucher à l’implémentation. Définissez les états et transitions. Demandez à un collègue d’écrire des tests sans regarder votre code. Lancez des property-based tests en CI.

C’est tout. Pas d’équipe séparée. Pas de notation formelle. Pas d’interdiction d’exécuter son propre code.

Les 0,1 défauts par KLOC de Cleanroom n’étaient pas de la magie. C’était le résultat d’un processus qui forçait les gens à définir correct avant de le construire. Vous pouvez obtenir la majeure partie de cet effet avec un docstring, une table de state machine, et un collègue qui teste vos hypothèses au lieu de votre code.