La réponse courte est non, mais la réponse longe vous fait gagner des heures

Une inspection Fagan complète nécessite un modérateur, un lecteur, deux à quatre inspecteurs et l’auteur. L’équipe passe deux heures à examiner environ 250 lignes de code à raison de 125 lignes par heure. Cela représente huit à douze heures-personne pour une petite modification.

Un LLM peut lire 250 lignes en moins d’une seconde. Il peut exécuter une checklist, signaler les motifs suspects et générer un journal de défauts avant qu’un humain n’ouvre le fichier.

Cela ne signifie pas qu’il peut remplacer l’équipe. Cela signifie que l’équipe ne devrait pas commencer la réunion avant que le LLM ait terminé ses devoirs.

Ce qu’un LLM peut réellement faire dans une inspection Fagan

Les inspections Fagan comportent quatre rôles distincts. Chaque rôle a une tâche qui se mappe différemment à ce qu’un LLM peut et ne peut pas faire.

Le modérateur planifie l’inspection, fait respecter les critères d’entrée et maintient la réunion sur la bonne voie. Un LLM peut générer une checklist, vérifier que les tests passent avant l’inspection et estimer le temps en fonction du nombre de lignes. Il ne peut pas dire si une salle pleine d’ingénieurs dérive vers un débat de conception. Le rôle de modérateur est social, et les LLMs ne sont pas sociaux.

Le lecteur paraphrase le code à voix haute pendant la réunion pour forcer le groupe à traiter la logique à la vitesse de compréhension plutôt qu’à la vitesse de survol. Un LLM peut résumer du code, mais il ne peut pas faire ralentir une salle d’humains. La vraie valeur du lecteur est l’application sociale. Le LLM n’a aucun levier.

Les inspecteurs trouvent des défauts en examinant le code par rapport aux checklists et aux connaissances métier. C’est ici que le LLM est le plus utile. Il peut vérifier les null dereferences, les fuites de ressources, les chemins d’erreur non gérés et les erreurs off-by-one plus vite que n’importe quel humain. Il ne se fatigue pas. Il ne saute pas les fonctions utilitaires ennuyeuses parce qu’elles semblent sûres.

L’auteur répond aux questions et corrige les défauts. Le LLM ne peut pas remplacer l’auteur parce qu’il n’a pas écrit le code et qu’il ne peut pas vérifier l’intention.

La réponse réaliste n’est donc pas le remplacement. C’est la substitution de rôle. Le LLM peut servir de pré-inspecteur infatigable qui gère les parties mécaniques du rôle d’inspecteur avant que les humains n’entrent dans la salle.

Où les LLMs aident réellement : la phase de préparation

La phase la plus importante d’une inspection Fagan est la préparation. Chaque inspecteur examine le matériel seul avant la réunion. Les études montrent que la préparation trouve environ la moitié des défauts découverts dans le processus complet. Si le LLM peut amplifier cette phase, la réunion humaine devient plus courte et plus percutante.

Voici une approche pratique. Fournissez au LLM le code, une checklist adaptée à votre langage et un prompt qui impose une sortie structurée. Utilisez la sortie du LLM comme point de départ pour les inspecteurs humains, pas comme un remplacement.

Le prompt compte plus que le modèle. Une demande vague comme “examinez ce code” vous donnera des banalités génériques. Un prompt structuré avec une checklist et un format de sortie vous donnera des défauts actionnables.

Voici ci-dessous un script Python qui exécute une pré-inspection basée sur LLM en utilisant une API compatible OpenAI. Il lit un fichier source, applique une checklist de style Fagan et produit un journal de défauts structuré.

#!/usr/bin/env python3
"""
LLM pre-inspection for Fagan-style review.
Produces structured defect log from a checklist.
"""

import argparse
import os
from pathlib import Path


def build_prompt(code: str, filepath: str, language: str) -> str:
    checklist = {
        "python": [
            "Missing null/None checks before dereferencing",
            "Unclosed file handles or missing context managers",
            "Bare except clauses that swallow exceptions",
            "Mutable default arguments in function signatures",
            "Race conditions in shared mutable state",
            "Missing input validation on public functions",
        ],
        "typescript": [
            "Non-null assertions (e.g., !) without justification",
            "Missing await on async calls",
            "Any types that should be narrowed",
            "Unhandled promise rejections",
            "Missing input validation on public functions",
        ],
        "rust": [
            "Unwrap or expect without comment explaining invariants",
            "Missing error propagation where Result is returned",
            "Unsafe blocks without safety comments",
            "Clone on large data structures in hot paths",
            "Missing input validation on public functions",
        ],
    }

    items = checklist.get(language, checklist["python"])
    checklist_text = "\n".join(f"  - {item}" for item in items)

    return (
        "You are a Fagan inspection assistant. Review the following code "
        "against the checklist. For each defect found, output a JSON object "
        "with keys: line, category, severity (minor/major/critical), description. "
        "If no defect is found for a checklist item, omit it. "
        "Be specific about line numbers and exact variable names. "
        "Do not suggest fixes. Fagan inspections only log defects, they do not solve them.\n\n"
        f"File: {filepath}\n"
        f"Language: {language}\n\n"
        "Checklist:\n"
        f"{checklist_text}\n\n"
        "Code:\n```\n"
        f"{code}\n"
        "```\n\n"
        "Output strict JSON array of defects only. No markdown, no preamble."
    )


def inspect_file(filepath: str, api_key: str, base_url: str) -> list:
    """Run LLM pre-inspection and return parsed defect list."""
    from openai import OpenAI

    path = Path(filepath)
    code = path.read_text()

    # Infer language from extension
    ext_map = {
        ".py": "python",
        ".ts": "typescript",
        ".tsx": "typescript",
        ".rs": "rust",
    }
    language = ext_map.get(path.suffix, "python")

    client = OpenAI(api_key=api_key, base_url=base_url)
    response = client.chat.completions.create(
        model=os.environ.get("INSPECTION_MODEL", "gpt-4.1-mini"),
        messages=[
            {"role": "system", "content": "You are a precise code inspection tool."},
            {"role": "user", "content": build_prompt(code, filepath, language)},
        ],
        temperature=0.2,
        max_tokens=2048,
    )

    raw = response.choices[0].message.content.strip()

    # Some models wrap JSON in markdown fences. Strip them.
    if raw.startswith("```json"):
        raw = raw[7:]
    if raw.startswith("```"):
        raw = raw[3:]
    if raw.endswith("```"):
        raw = raw[:-3]
    raw = raw.strip()

    import json
    try:
        defects = json.loads(raw)
        if not isinstance(defects, list):
            return []
        return defects
    except json.JSONDecodeError:
        print("Warning: LLM returned non-JSON output:")
        print(raw[:500])
        return []


def main():
    parser = argparse.ArgumentParser(description="LLM pre-inspection for Fagan review")
    parser.add_argument("files", nargs="+", help="Source files to pre-inspect")
    parser.add_argument("--api-key", default=os.environ.get("OPENAI_API_KEY"))
    parser.add_argument(
        "--base-url",
        default=os.environ.get("OPENAI_BASE_URL", "https://api.openai.com/v1"),
    )
    args = parser.parse_args()

    if not args.api_key:
        raise SystemExit("Error: set OPENAI_API_KEY or pass --api-key")

    all_defects = []
    for f in args.files:
        defects = inspect_file(f, args.api_key, args.base_url)
        all_defects.extend({"file": f, **d} for d in defects)

    if not all_defects:
        print("No defects flagged by LLM pre-inspection.")
        return

    print(f"LLM pre-inspection found {len(all_defects)} defect(s):\n")
    for d in all_defects:
        print(
            f"[{d['severity'].upper()}] {d['file']}:{d.get('line', '?')} "
            f"({d['category']}) {d['description']}"
        )


if __name__ == "__main__":
    main()

Installez le SDK OpenAI avec pip install openai, configurez votre clé API et exécutez python inspect.py src/auth.py. Le script produit un journal de défauts structuré que les inspecteurs humains peuvent utiliser comme checklist de départ.

Ce n’est pas l’inspection. C’est la préparation. Les défauts ont encore besoin d’un jugement humain.

Ce que les LLMs manquent : les défauts qui coûtent de l’argent réel

Les défauts les plus coûteux ne sont pas des erreurs de syntaxe. Ce sont des hypothèses erronées.

Un LLM attrapera le null check manquant. Il n’attrapera pas que le cas null ne devrait jamais se produire parce que le service upstream garantit le champ, et le vrai bug est que votre équipe a changé le contrat il y a trois semaines et a oublié de mettre à jour le code downstream.

Un LLM signalera une exception non gérée. Il ne remarquera pas que le exception handler est manquant parce que l’auteur a supposé que la transaction de base de données ferait un rollback automatique, et cette hypothèse est fausse pour le niveau d’isolation spécifique que votre équipe utilise.

Ce sont des défauts au niveau de l’intention. Ils nécessitent des connaissances métier, un contexte historique et la capacité de se demander “qu’est-ce que l’auteur a supposé qui n’est pas vrai ?” Un LLM n’a pas accès aux hypothèses non documentées de votre équipe. Il n’a pas de mémoire de la décision d’architecture du trimestre dernier. Il ne peut pas regarder un document d’exigences et remarquer que le code implémente la mauvaise exigence.

Les inspections Fagan ont été conçues pour attraper exactement ces défauts. Les inspecteurs humains apportent différents modèles mentaux et différents contextes. Lorsqu’ils ne sont pas d’accord sur ce que le code devrait faire, l’écart entre leurs hypothèses est là où vivent les vrais bugs.

Un LLM a un seul modèle mental, et il est entraîné sur du code public, pas sur votre codebase.

Le vrai trade-off : couverture vs. compréhension

La pré-inspection par LLM vous donne de la couverture. Il lit chaque ligne, vérifie chaque fonction et n’est jamais distrait par une notification Slack. C’est l’inspecteur étroit parfait.

L’inspection humaine vous donne de la compréhension. Elle connecte le code à la spec, la spec au schéma de base de données et le schéma à la règle métier qui a changé lors de la dernière réunion de sprint planning. C’est le seul moyen de trouver des défauts qui vivent en dehors du code.

Le trade-off n’est pas humain contre machine. C’est profond contre large.

Si vous remplacez votre équipe d’inspection par un LLM, vous trouverez plus de défauts au niveau de la syntaxe et en manquerez plus au niveau de l’intention. Le résultat net dépend de quel type de bugs vous tue. Si vos incidents de production sont principalement des null dereferences et des fuites de ressources, un LLM aidera. Si vos incidents sont principalement une mauvaise logique métier et des cas edge manqués, un LLM vous donnera une fausse confiance.

Comment exécuter une inspection hybride en pratique

Voici un workflow pratique qui utilise le LLM pour ce qu’il fait bien et préserve l’équipe humaine pour ce que seuls les humains peuvent faire.

Avant la réunion, exécutez le script de pré-inspection LLM sur le code. Donnez à chaque inspecteur humain la sortie plus le code original. Exigez d’eux qu’ils vérifient ou rejettent chaque constat du LLM pendant leur préparation individuelle. Cela les oblige à examiner des lignes qu’ils auraient pu survoler.

Pendant la réunion, le lecteur continue de paraphraser le code à voix haute. Les inspecteurs continuent de soulever des problèmes. Mais maintenant ils partent d’une liste épurée de défauts mécaniques déjà triés. Le temps de réunion peut être réduit de deux heures à quatre-vingt-dix minutes, ou l’équipe peut examiner plus de code dans la même fenêtre de temps.

Le modérateur ajoute une nouvelle responsabilité : suivre la précision du LLM. Enregistrez combien de défauts signalés par le LLM étaient réels, combien étaient des faux positifs et combien de défauts uniquement humains le LLM a manqués. Après trois ou quatre inspections, vous saurez si votre prompt de checklist nécessite un ajustement.

C’est le même processus que la NASA a utilisé lorsqu’elle a expérimenté l’inspection assistée par outil dans les années 1990. Les vérificateurs automatisés ont trouvé les défauts faciles et ont laissé les difficiles aux humains. Les humains ont mieux performé parce qu’ils n’étaient pas mentalement épuisés d’avoir trouvé les faciles.

Le bilan

Un LLM ne peut pas remplacer une équipe d’inspection complète parce que l’inspection ne consiste pas seulement à lire du code. C’est un processus social structuré conçu pour mettre en lumière les écarts entre ce que l’auteur a supposé et ce que le code fait réellement.

Ce qu’un LLM peut faire, c’est rendre l’équipe humaine plus efficace en supprimant la charge mécanique. Il peut jouer un cinquième rôle : le pré-inspecteur infatigable qui prépare le champ de bataille avant que les humains n’arrivent.

Si vous sautez les inspections parce qu’elles sont trop coûteuses, un LLM ne les rend pas gratuites. Il les rend plus courtes. C’est souvent suffisant.

FAQ

Qu’est-ce qu’une inspection Fagan ?

Un processus de revue structuré en six phases inventé par Michael Fagan chez IBM en 1976. Il utilise des rôles définis (modérateur, lecteur, inspecteurs, auteur), une préparation individuelle obligatoire et des réunions en timebox pour trouver des défauts avant les tests. Il rapporte de manière constante des taux d’élimination des défauts de 60 à 90 pour cent.

Un LLM peut-il remplacer un relecteur de code humain ?

Pas pour les défauts qui comptent le plus. Un LLM attrape des problèmes mécaniques comme les null checks manquants et les fuites de ressources. Il manque des défauts au niveau de l’intention comme les hypothèses erronées sur les contrats upstream, la logique métier manquante et les écarts entre le code et les exigences.

Comment intégrer un LLM dans une inspection Fagan ?

Utilisez le LLM pendant la phase de préparation. Exécutez-le contre une checklist, transmettez sa sortie aux inspecteurs humains avant la réunion et exigez d’eux qu’ils vérifient chaque constat. Cela raccourcit la réunion et améliore la concentration humaine sans supprimer le jugement humain.

Qu’est-ce qui rend un prompt de checklist LLM efficace ?

La spécificité. Les prompts génériques produisent une sortie générique. Les prompts efficaces nomment des catégories de défauts exactes, exigent une sortie JSON structurée, interdisent les propositions de solution et demandent des numéros de ligne exacts et des noms de variables. La checklist doit correspondre à votre langage et aux défauts les plus courants que votre équipe laisse échapper.

Essayez-le sur un fichier

Choisissez un fichier qui a causé un incident de production le mois dernier. Écrivez une checklist de cinq types de défauts spécifiques qui intéressent votre équipe. Exécutez le script ci-dessus avec cette checklist. Donnez la sortie à deux ingénieurs qui n’ont pas écrit le fichier.

Comparez les constats du LLM avec les constats humains. Comptez le chevauchement. Comptez ce que chaque côté a manqué. Cet écart est votre réponse.