Votre code review est probablement défectueux

La plupart des code reviews détectent entre 15 et 30 pour cent des défauts qu’elles sont censées trouver. Ce n’est pas une supposition. IBM l’a mesuré dans les années 1970, et des études chez AT&T, HP et Microsoft ont confirmé la même fourchette décennie après décennie.

La revue informelle est bon marché, asynchrone et socialement acceptable. Elle est aussi largement inefficace pour trouver des bugs. Les ingénieurs lisent trop vite, passent les error paths et évitent de signaler de vrais problèmes parce que personne ne veut être celui qui bloque le merge.

Il existe une alternative qui rapporte constamment des taux d’élimination de défauts de 60 à 90 pour cent. Elle a été inventée chez IBM en 1976 par Michael Fagan. Elle ne nécessite aucun outil, aucune IA et aucun budget. Elle nécessite cependant quelque chose que la plupart des équipes d’ingénierie refusent de donner : de la structure.

Qu’est-ce qu’une Fagan inspection ?

Une Fagan inspection est un processus de revue formellement défini, en plusieurs étapes, avec des rôles spécifiques, des limites de temps, des critères d’entrée et des checklists. Contrairement à un pull request review typique, ce n’est pas une conversation entre auteur et relecteur. C’est une réunion structurée avec un modérateur, un reader, des inspecteurs et l’auteur.

L’auteur reste principalement silencieux. La réunion est strictement timeboxée. Et le seul objectif est de trouver des défauts.

Le processus suit six étapes :

  1. Planning. Le modérateur sélectionne le matériel, vérifie les critères d’entrée, assigne les rôles et planifie la réunion. Les critères d’entrée existent pour une raison. On n’inspecte pas un brouillon. Le document doit être complet, compilable et testé avant de mériter de consommer le temps de quatre personnes.

  2. Overview. Facultatif. L’auteur explique le contexte si les inspecteurs ne connaissent pas le domaine.

  3. Preparation. Chaque inspecteur examine le matériel seul avant la réunion. C’est non négociable. On n’arrive pas à froid. Les inspecteurs utilisent des checklists adaptées aux types de défauts courants et annotent les issues en privé.

  4. Inspection. La réunion elle-même. Le reader, qui n’a pas écrit le code, le parcourt ligne par ligne et le paraphrase à voix haute. Les inspecteurs soulèvent des issues quand ils repèrent des divergences. L’auteur écoute. Personne ne propose de correction. Le modérateur fait respecter les limites de temps et garde la réunion focalisée uniquement sur l’identification des défauts.

  5. Rework. L’auteur corrige les défauts.

  6. Follow-up. Le modérateur vérifie que chaque défaut a été traité. Si trop de défauts ont été trouvés, une reinspection a lieu.

Quatre rôles gardent le processus honnête. Le modérateur planifie et contrôle. L’auteur a créé le travail et ne répond aux questions que sur demande. Le reader paraphrase le code pendant la réunion, forçant une compréhension plus lente et plus soigneuse. Les inspecteurs, généralement deux à quatre personnes, trouvent les défauts.

Pourquoi la revue informelle échoue là où les Fagan inspections réussissent

La différence n’est pas le talent. C’est la conception du processus.

Dans un pull request review typique, le relecteur lit le diff dans un navigateur, survole le happy path, laisse quelques commentaires et approuve. Il n’y a pas de temps de préparation. Il n’y a pas de checklist. Il n’y a pas de mécanisme qui force le relecteur à examiner la gestion des erreurs ou les conditions aux limites. Les dynamiques sociales récompensent la vitesse et la politesse, pas la minutie.

Les Fagan inspections inversent ces incitations.

La préparation individuelle signifie que chaque inspecteur a réellement lu le code avant que la réunion ne commence. La paraphrase du reader force le groupe à traiter le code à la vitesse de la compréhension au lieu de la vitesse du survol. Les checklists dirigent l’attention vers des catégories de défauts connues au lieu de ce qui attire le regard. La pression du temps empêche la réunion de dériver vers des débats de conception. Et séparer la recherche de défauts de leur correction empêche le groupe de s’ancrer sur la première solution suggérée.

Le résultat est que les Fagan inspections détectent la plupart des défauts avant qu’ils n’atteignent le testing ou la production.

Le coût est concentré en amont en person-hours.

Le vrai trade-off : Person-hours vs. escape de défauts

Voici pourquoi la plupart des équipes n’utilisent pas les Fagan inspections.

Une seule inspection nécessite quatre à six personnes dans une salle pendant jusqu’à deux heures pour examiner environ 250 lignes de code. Cela représente 8 à 12 person-hours pour un petit changement. Dans un workflow CI/CD moderne où les équipes déploient plusieurs fois par jour, cela semble absurde.

Le processus semble aussi bureaucratique. Critères d’entrée, rôles formels, checklists imprimées, vérification de suivi. La plupart des ingénieurs le détesteront par principe. Et il ne passe pas à l’échelle pour les gros diffs. Un refactor de deux mille lignes nécessiterait huit réunions d’inspection séparées.

Mais le calcul change quand on regarde le coût total au lieu du coût de la réunion.

Les données originales d’IBM ont montré que trouver et corriger un défaut pendant l’inspection coûtait environ un dixième de ce que cela coûtait de trouver et corriger le même défaut pendant le testing. Quand il échappait à la production, le ratio passait à vingt ou trente pour un.

Donc oui, l’inspection est chère. Elle reste pourtant moins coûteuse que de déboguer des incidents de production, de brûler de la capacité de sprint sur des correctifs réactifs et de perdre la confiance des clients.

Le problème est que les économies sont invisibles. On ne peut pas mesurer le bug qu’on a prévenu. Le coût de la réunion est immédiat et évident. C’est pourquoi la revue informelle l’emporte dans la plupart des organisations. Elle optimise la vitesse visible plutôt que la qualité invisible.

Exécuter une Fagan inspection allégée en 2026

Vous n’avez pas besoin d’adopter toute la cérémonie. La plupart des équipes peuvent obtenir soixante-dix pour cent des bénéfices avec vingt pour cent de la charge en conservant les mécanismes de base et en supprimant la paperasse.

Voici une séquence pratique :

Exigez une préparation individuelle avant toute revue synchrone. Si vous n’avez pas lu le code, vous n’assistez pas.

Assignez un reader qui n’a pas écrit le code pour parcourir la logique à voix haute. Ne laissez pas l’auteur piloter. La paraphrase force le groupe à traiter chaque branche.

Utilisez une checklist adaptée aux types de défauts les plus courants de votre équipe. Commencez avec la liste ci-dessous et ajoutez des items au fur et à mesure que vous apprenez des défauts échappés.

Timebox à quatre-vingt-dix minutes. Terminez à l’heure, même si vous n’avez pas fini. Planifiez une deuxième session plutôt que de laisser la fatigue détruire la qualité.

Gardez l’auteur passif. Ils ne répondent qu’aux questions de clarification. Pas de défense des choix de conception.

Enregistrez les défauts, pas les solutions. Corrigez les défauts après la réunion.

Pour concrétiser cela, voici un petit script Python qui planifie une inspection, estime le temps et imprime des checklists spécifiques par rôle :

#!/usr/bin/env python3
"""
Plan a Fagan-style inspection: estimate time and emit checklists.
"""

import argparse


def count_lines(filepath):
    """Count non-blank lines."""
    try:
        with open(filepath, "r") as f:
            return sum(1 for line in f if line.strip())
    except Exception:
        return 0


def plan_inspection(files, rate=125):
    """
    rate: reviewable lines per hour. Fagan recommended 100-125 for code.
    """
    total = sum(count_lines(f) for f in files)
    hours = total / rate
    minutes = hours * 60

    print(f"Total reviewable lines: {total}")
    print(f"At {rate} lines/hour, schedule: {hours:.1f} hours ({minutes:.0f} min)")

    if hours > 2:
        sessions = int(hours / 2) + 1
        print(f"WARNING: exceeds 2-hour limit. Split into {sessions} sessions.")

    print("\n--- ROLE: Reader ---")
    print("Paraphrase each block aloud. Do not just read variable names.")
    print("Pause at every conditional, loop boundary, and API call.")

    print("\n--- ROLE: Inspector ---")
    checklist = [
        "Off-by-one in loops and array or slice access",
        "Null, None, or undefined dereferences",
        "Resource leaks: files, connections, locks, contexts",
        "Error paths: are they handled, returned, and tested?",
        "Return values: are they checked before use?",
        "Shared mutable state and thread safety",
        "Boundary conditions and input validation",
        "Invariant violations: what should stay true, and does it?",
    ]
    for item in checklist:
        print(f"  [ ] {item}")

    print("\n--- ROLE: Moderator ---")
    print("Start on time. End on time.")
    print("No design debates. No solution proposals.")
    print("Record each defect with: file, line, severity, type.")


if __name__ == "__main__":
    parser = argparse.ArgumentParser(description="Plan a Fagan inspection")
    parser.add_argument("files", nargs="+", help="Source files to inspect")
    parser.add_argument("--rate", type=int, default=125, help="Lines per hour")
    args = parser.parse_args()

    plan_inspection(args.files, args.rate)

Enregistrez-le sous inspect.py, exécutez python inspect.py src/auth.py src/orders.py, et vous avez une estimation de temps et une checklist.

Questions fréquemment posées

Qu’est-ce qu’une Fagan inspection ?

Une Fagan inspection est un processus de revue structuré en six étapes avec des rôles définis, des critères d’entrée et des checklists. Il a été développé par Michael Fagan chez IBM en 1976 pour trouver des défauts dans les produits de travail logiciels avant le testing.

Quelle est la différence entre une Fagan inspection et un pull request review ?

Un pull request review est généralement asynchrone, informel et piloté par l’auteur. Une Fagan inspection est une réunion synchrone avec des rôles assignés, une préparation individuelle obligatoire, des limites de temps strictes et une règle selon laquelle l’auteur reste silencieux pendant que les autres trouvent des défauts.

Pourquoi les Fagan inspections ne sont-elles pas plus courantes ?

Elles sont coûteuses en person-hours, semblent bureaucratiques aux équipes modernes et ne passent pas bien à l’échelle pour les changements grands et fréquents. Le coût est visible et immédiat. Les défauts prévenus sont invisibles.

Les Fagan inspections peuvent-elles fonctionner dans un environnement agile ou CI/CD ?

Oui, mais avec des modifications. La plupart des équipes utilisent des versions allégées : préparation individuelle obligatoire, un reader qui paraphrase, une checklist et un timebox strict. Le processus formel complet est généralement réservé aux modules critiques ou à haut risque.

Essayez sur un module

Vous n’avez pas besoin de réécrire votre processus. Choisissez un module qui a eu des défauts échappés le mois dernier. Rassemblez trois ingénieurs qui ne l’ont pas écrit. Donnez-leur le code et une checklist vingt-quatre heures à l’avance. Planifiez quatre-vingt-dix minutes. Assignez un reader. Faites écouter l’auteur.

Mesurez ce que vous trouvez. Puis décidez si la réunion a coûté plus cher que les bugs ne l’auraient fait.

Si vous voulez les données originales, l’article de 1976 de Fagan “Design and Code Inspections to Reduce Errors in Program Development” reste la meilleure référence. Il a cinquante ans, et la plupart des équipes n’ont toujours pas rattrapé ce niveau.