Le processus qualité le plus efficace que personne n’utilise

En 1976, Michael Fagan a publié un article dans l’IBM Systems Journal décrivant un processus de revue si efficace qu’il est devenu la référence en matière de qualité logicielle. Les Fagan Inspections capturaient de 60 à 90 pour cent de tous les défauts avant qu’un seul test ne soit exécuté. Une étude de la NASA en 2002 a révélé que chaque heure passée en inspection prévenait en moyenne 33 heures de travail de maintenance plus tard.

Selon toute mesure, c’était le meilleur processus de revue que l’ingénierie logicielle ait jamais produit.

Presque personne ne l’utilise aujourd’hui.

La question n’est pas de savoir si les Fagan Inspections fonctionnaient. Elles fonctionnaient presque trop bien. La question est de savoir pourquoi un processus avec un tel bilan a disparu du développement courant, et si nous avons perdu quelque chose d’important en le remplaçant.

À quoi ressemblaient réellement les Fagan Inspections

Fagan n’a pas inventé le code review. Il a inventé un rituel spécifique et hautement structuré pour trouver des défauts.

Le processus comportait six phases rigides :

  1. Planning : Un modérateur sélectionnait les participants et vérifiait que le matériel répondait aux critères d’entrée.
  2. Overview : L’auteur expliquait le contexte. Il s’agissait de poser le contexte, pas de faire la revue.
  3. Preparation : Chaque participant examinait le matériel de manière indépendante, à environ 150 lignes par heure, avec une liste personnelle de défauts suspects.
  4. Inspection Meeting : L’équipe se réunissait pendant au plus deux heures. Un reader narrait la logique à haute voix. Un recorder consignait les défauts. Le modérateur veillait à ce que la réunion reste concentrée sur la recherche de défauts, pas sur leur résolution.
  5. Rework : L’auteur corrigeait chaque défaut consigné.
  6. Follow-up : Le modérateur vérifiait que les corrections avaient été apportées et qu’aucun nouveau défaut n’avait été introduit.

Les rôles étaient spécifiques et non chevauchants. Le modérateur dirigeait le processus mais n’était pas l’autorité technique. Le reader narrait le code mais ne le défendait pas. L’auteur était présent mais interdit d’expliquer son intention pendant la réunion. Le but n’était pas la collaboration. C’était la détection froide et systématique des défauts.

C’est cette partie qui faisait fonctionner le processus. La dynamique sociale des réunions d’ingénierie normales était éliminée par conception.

Pourquoi les chiffres étaient si bons

Le taux de détection des défauts n’était pas un accident. Il résultait de quelques choix de conception délibérés.

La préparation indépendante signifiait que six personnes examinaient le même code en isolation avant que toute discussion de groupe ne puisse les influencer. Le chevauchement entre leurs listes indiquait à quel point un défaut était évident. Les éléments que seule une personne avait trouvés étaient souvent les plus précieux.

La limite stricte de deux heures empêchait la fatigue de détruire le jugement. Fagan savait que l’efficacité de l’inspection chute dramatiquement après environ deux heures. Le rythme de 150 lignes par heure était également délibéré. Si vous allez plus vite, vous commencez à voir ce que vous attendez de voir au lieu de ce qui est réellement là.

La règle de non-résolution maintenait le focus des réunions. Rien ne détruit une inspection plus vite qu’une salle pleine d’ingénieurs concevant une solution pour un défaut qu’ils n’ont pas encore complètement caractérisé.

Ces contraintes n’étaient pas une charge bureaucratique. Elles étaient le mécanisme. Les supprimer donne quelque chose de plus convivial mais moins efficace.

Ce qui a tué les Fagan Inspections

Si le processus était si efficace, pourquoi a-t-il disparu ?

La réponse courte est qu’il était coûteux exactement de la manière que le développement logiciel moderne refuse de tolérer.

Une seule Fagan Inspection consommait de 15 à 20 pour cent de l’effort dépensé pour écrire le code en cours de revue. Dans un cas documenté, 348 lignes ont nécessité 27,3 heures-personne d’inspection. Ce ratio est inconcevable lorsque les équipes déploient plusieurs fois par jour.

Seule la planification était un travail à plein temps. Il fallait cinq ou six personnes dans une salle pendant deux heures, plus la préparation, plus le suivi. Dans une grande organisation, trouver un créneau de deux heures où un modérateur, un reader, deux reviewers, un recorder et un auteur étaient tous disponibles pouvait prendre des jours.

La structure rigide des rôles ne passait pas non plus à l’échelle. Les Fagan Inspections supposaient une équipe stable avec suffisamment de personnes pour remplir tous les rôles. Dans une startup, une équipe de cinq personnes pourrait ne pas avoir quelqu’un capable de servir de modérateur dédié sans détruire la vélocité.

Le plus grand facteur était culturel. Les Fagan Inspections étaient délibérément inconfortables. L’auteur restait assis en silence pendant que ses collègues narraient son code et consignaient ses défauts. Il n’y avait pas de place pour “ce n’est qu’une première ébauche”. Le processus partait du principe que les défauts sont coûteux et que la friction sociale est bon marché. L’ingénierie moderne repose sur l’hypothèse opposée.

Ce avec quoi nous l’avons remplacé

L’industrie n’a pas abandonné la revue structurée. Elle l’a remplacée par des pull requests.

La revue de pull request est asynchrone, peu cérémonielle, et intégrée directement dans le workflow de développement. Un reviewer peut regarder un diff entre deux réunions, sur son téléphone, ou en attendant que CI se termine. Il n’y a pas de rôles assignés. L’auteur et le reviewer sont souvent la même personne qui a juste besoin d’une approbation de plus pour faire un merge.

C’est une amélioration massive en accessibilité, vitesse et developer experience. C’est aussi une régression massive en détection de défauts.

Plusieurs études ont trouvé que la revue informelle attrape environ la moitié des défauts que l’inspection structurée attrape. Une expérience de 2009 menée par Basili et d’autres a comparé l’inspection de style Fagan avec la revue lightweight et a trouvé que le processus plus léger capturait significativement moins de défauts dans le même matériel.

Le problème n’est pas que les reviewers sont paresseux. Le processus n’est pas conçu pour trouver des défauts. Il est conçu pour permettre aux gens d’expédier du code avec un second regard, ce qui n’est pas la même chose.

Ce que nous avons réellement perdu

La revue de pull request optimise le débit. L’inspection Fagan optimisait la rigueur. Ce sont des objectifs véritablement différents, et aucun n’est faux. L’erreur est de supposer que le processus plus léger est un sur-ensemble strict du plus lourd.

Voici ce qui a disparu :

Preparation indépendante. Dans un pull request, le reviewer voit le diff à froid. Il n’a pas passé une heure à lire le contexte environnant, à tracer le flux de données et à construire un modèle mental. Il réagit à une notification. La profondeur de l’examen n’est pas comparable.

Le rôle de reader. Faire narrer le code à haute voix force le groupe à avancer à un rythme que la personne la plus lente peut suivre. Cela met en lumière des hypothèses que la lecture silencieuse cache. Un diff sur un écran permet à vos yeux de sauter les parties ennuyeuses. Un reader ne saute pas.

Focus uniquement sur les défauts. Les commentaires de pull request dérivent vers des opinions de style et d’architecture. Celles-ci ont de la valeur, mais ce n’est pas de la détection de défauts. Chaque minute passée à débattre de l’indentation est une minute non passée à trouver un null dereference.

Données de processus mesurables. Les Fagan Inspections produisaient des chiffres concrets : défauts par heure, temps de préparation, temps de retravail, defect density par module. Les outils de revue modernes comptent les commentaires et les approbations, qui ne vous disent presque rien sur la qualité de la revue.

Un compromis pratique

Vous n’allez pas exécuter des Fagan Inspections complètes dans un environnement de continuous deployment moderne. Mais vous pouvez emprunter les parties qui comptent.

L’idée la plus importante transferable est la préparation indépendante structurée. Avant une revue async approfondie, exigez que les reviewers passent du temps avec le matériel seuls. Pas un survol rapide. Une véritable préparation.

Au lieu d’un générique “LGTM”, imposez une checklist lightweight qui imite la discipline que Fagan a intégrée dans les rôles et les règles :

from dataclasses import dataclass, field
from typing import List, Optional
from enum import Enum

class DefectSeverity(Enum):
    MINOR = "minor"
    MAJOR = "major"
    CRITICAL = "critical"

@dataclass
class ReviewEntry:
    line_number: Optional[int]
    category: str
    severity: DefectSeverity
    description: str

@dataclass
class InspectionReport:
    reviewer: str
    prep_time_minutes: int
    entries: List[ReviewEntry] = field(default_factory=list)

    def defect_count(self) -> int:
        return len(self.entries)

def run_inspection_checklist(
    code: str,
    reviewer: str,
    prep_time_minutes: int
) -> InspectionReport:
    """Structured prep produces structured output.

    Mimics the Fagan prep phase: reviewer spends focused
    time with the material, then logs findings against a
    consistent taxonomy instead of ad hoc comments.
    """
    report = InspectionReport(
        reviewer=reviewer,
        prep_time_minutes=prep_time_minutes
    )

    # Example: check for missing null handling
    if "->" in code and "null" not in code.lower():
        report.entries.append(ReviewEntry(
            line_number=None,
            category="null-safety",
            severity=DefectSeverity.MAJOR,
            description="No explicit null handling in pointer function"
        ))

    return report

Ce n’est pas une Fagan Inspection. C’est un moyen de récupérer l’une de ses propriétés les plus importantes : le output de revue devrait être structuré, mesurable et concentré sur les catégories de défauts plutôt que sur des opinions.

Une autre idée transferable est la revue approfondie time-boxed. Choisissez un module critique par sprint. Planifiez une revue concentrée de 90 minutes avec préparation indépendante. Consignez uniquement les défauts. Pas de solutions, pas de débats de style, pas d’arguments de conception.

Le coût est réel. Mais si le ratio de la NASA se maintient même approximativement, une heure concentrée maintenant économise des dizaines d’heures de debugging plus tard.

La vérité inconfortable

Les Fagan Inspections n’ont pas échoué. Elles ont été rejetées parce que la rigueur qu’elles exigeaient était incompatible avec la vitesse que l’industrie priorisait.

Ce compromis avait du sens pour beaucoup de logiciels. Une faute de frappe sur un bouton d’une landing page ne nécessite pas une inspection formelle de cinq personnes. Mais la culture qui a remplacé les Fagan Inspections traite tout le code de la même manière, et c’est là que se cache le coût.

Les défauts les plus coûteux se trouvent dans le code qui semble correct, passe les tests et échoue en production de manières qui coûtent de l’argent réel. C’est exactement le code qui bénéficie le plus d’un processus conçu pour trouver des défauts plutôt que d’un processus conçu pour approuver des diffs.

La revue de pull request est là pour rester, et c’est bien. Mais prétendre qu’elle remplace l’inspection structurée n’est pas bien. C’est un outil différent pour un travail différent, et les équipes qui ne possèdent que l’un d’eux continueront à trouver des bugs coûteux qu’un meilleur processus aurait détectés avant l’expédition.

FAQ

Qu’est-ce qu’une Fagan Inspection ?

Un processus de revue structuré et multi-phases pour trouver des défauts dans des artefacts logiciels, développé par Michael Fagan chez IBM dans les années 1970. Il comporte six phases (Planning, Overview, Preparation, Inspection Meeting, Rework, Follow-up) avec des rôles spécifiques pour les participants. La réunion se concentre exclusivement sur la consignation des défauts, pas sur leur résolution.

Quelle était l’efficacité des Fagan Inspections ?

IBM a rapporté des taux de suppression de défauts supérieurs à 90 pour cent. Une étude de la NASA en 2002 a trouvé que chaque heure d’inspection prévenait en moyenne 33 heures de maintenance. Des études indépendantes ont constamment trouvé que l’inspection structurée attrape environ deux fois plus de défauts que la revue informelle.

Pourquoi les équipes ont-elles cessé d’utiliser les Fagan Inspections ?

Le processus consommait de 15 à 20 pour cent de l’effort total du projet, nécessitait une planification difficile de plusieurs participants, et était culturellement rigide. Alors que les équipes logicielles se sont orientées vers des cycles de release plus rapides, le overhead est devenu insoutenable. La revue de pull request l’a remplacé par défaut car elle est plus rapide et plus facile à intégrer dans le workflow normal, même si elle attrape moins de défauts.

Les équipes modernes peuvent-elles encore bénéficier des Fagan Inspections ?

Pas sous leur forme originale. Le processus complet de six phases avec rôles assignés ne convient pas au continuous deployment. Mais les idées centrales — préparation indépendante, revue concentrée time-boxed, enregistrement structuré des défauts, et séparation de la recherche de défauts de la conception de solutions — peuvent être adaptées. Les équipes qui les appliquent sélectivement au code critique obtiennent une grande partie du bénéfice sans le overhead.