Discipline de vérification du code généré

1. Vue d'ensemble du concept et problème systémique

Avec l'essor des outils de génération automatique, un fossé critique s'est creusé entre la simplicité de création du code et sa fiabilité réelle. Un modèle peut générer 400 lignes de code parfaitement formatées avec des noms de méthodes plausibles, donnant une impression d'autorité, mais qui plantent dès la première seconde d'exécution à cause d'un appel à une méthode inexistante ou d'une incompatibilité de types.

La Discipline de Vérification (Verification Discipline) est la barrière démocratique fondamentale entre un ingénieur logiciel professionnel et un amateur. Il s'agit d'une posture interne inébranlable :

• Aucun mot prononcé par le modèle de langage n'est pris pour argent comptant.
• Tout code généré est considéré comme potentiellement cassé jusqu'à preuve du contraire par un outil déterministe indépendant (compilateur, linter, runner de tests).
• L'ingénieur porte une responsabilité professionnelle personnelle sur chaque caractère fusionné dans le dépôt.

Sans discipline de vérification, le projet glisse vers l'état de « château de cartes fragile », où chaque nouvelle fonctionnalité en casse deux précédentes, et où l'équipe consacre toute son énergie à éteindre des incendies soudains en production.

Approche amateur (Confiance aveugle) :
[LLM : « J'ai tout corrigé, le code est prêt ! »] ---> [Clic sur « Accepter tout »] ---> [Commit & Push] ---> [Erreur 502 Bad Gateway en production]

Discipline d'ingénierie de vérification (Preuve d'abord) :
[LLM : « J'ai tout corrigé ! »]
          |
          v
[Étape 1 : tsc --noEmit] -----------------> [Erreur de type ! Renvoi à l'agent pour correction]
          | (Vert)
          v
[Étape 2 : vitest run] -------------------> [Échec du test ! Correction de la logique]
          | (Vert)
          v
[Étape 3 : git diff --cached] ------------> [Détection d'un console.log superflu et d'une bibliothèque hallucinée]
          | (Propre)
          v
[Étape 4 : Test de fumée dans le navigateur] --------> [Clic physique sur le formulaire]
          |
          v
[Commit en production conscient]

2. Taxonomie architecturale et modèle mental

Les niveaux de barrières défensives de la vérification (Le Modèle du Gruyère) :

1. Niveau 1 : Analyse syntaxique et sémantique statique (Compile-time) :
   • Compilateur strict (tsc --noEmit, rustc, cargo check).
   • Linters de style et de sécurité (ESLint, Biome, ShellCheck).
   • Élimine 70 % des hallucinations concernant des champs ou méthodes inexistants.
2. Niveau 2 : Tests dynamiques automatisés (Dynamic Verification) :
   • Tests unitaires : vérification des fonctions pures et des cas limites.
   • Tests d'intégration : vérification des interactions avec la base de données réelle ou le cache.
   • Protège contre les erreurs logiques et les régressions.
3. Niveau 3 : Audit des modifications (Diff Hygiene) :
   • Lecture humaine des différences de lignes via git diff.
   • Objectif : détecter le « bruit », les commentaires supprimés accidentellement, les violations des frontières architecturales.
4. Niveau 4 : Vérification au runtime (End-to-End & Observability) :
   • Exécution d'un scénario utilisateur réel via Playwright ou manuellement dans le navigateur/terminal.
   • Surveillance des logs après le déploiement pour détecter des pics d'erreurs 5xx.

3. Pipeline technique et mécanique interne

Hook Git Pre-Commit de vérification automatique (Husky / Lefthook)

L'être humain peut oublier de vérifier le code en raison de la fatigue. Pour protéger le système du facteur humain, le circuit de vérification bloque matériellement le commit :

# lefthook.yml — надійний та швидкий валідатор
pre-commit:
  parallel: false
  commands:
    typecheck:
      run: npx tsc --noEmit
    lint:
      run: npx @biomejs/biome check --staged --apply
    test:
      run: npx vitest run --passWithNoTests

Si au moins un test échoue ou si le compilateur détecte une divergence de types, la tentative de commit aboutit à un arrêt d'urgence.

Checklist d'audit manuel du diff (Diff Inspection Protocol)

Avant d'exécuter la commande git push, l'ingénieur vérifie :

- [ ] L'agent a-t-il supprimé du code important dans des sections non liées du fichier ?
- [ ] Les cas limites sont-ils gérés (null, undefined, tableau vide, 404) ?
- [ ] Des mots de passe, secrets et jetons de test codés en dur sont-ils absents ?
- [ ] Le diff contient-il des modifications de mise en forme aléatoires dans 50 fichiers étrangers ?
- [ ] Les noms des nouvelles entités respectent-ils les conventions standards du projet ?

4. Scénarios d'ingénierie pratiques en production

01. Détection d'une hallucination sournoise dans un module financier

Un agent a écrit une fonction de calcul de frais bancaires et a affirmé avec assurance : « La logique a été mise à jour conformément aux règles ». L'ingénieur a activé la discipline de vérification et a écrit un test passant une somme négative (amount: -100). Il s'est avéré que la fonction retournait des frais négatifs, ce qui aurait permis aux malveillants de voler de l'argent sur les comptes de l'entreprise. Le bug a été corrigé avant le déploiement.

02. Protection contre la suppression silencieuse de commentaires dans un système legacy

Lors d'un refactoring, un module contenait un commentaire crucial : // CRITICAL: do not reorder this call due to Safari bug #19284. Le modèle a jugé le commentaire superflu et l'a supprimé, modifiant l'ordre des appels. Grâce à une revue attentive du git diff, l'architecte a remarqué la suppression, a préservé le workaround de protection et a ajouté un test E2E de régression.

03. Reproduction complète du bug par test avant correction (Bug Repro First)

À la réception d'un rapport d'incident, l'ingénieur discipliné interdit à l'agent de toucher au code de production. On écrit d'abord un test qui reproduit exactement le bug et échoue avec une erreur rouge (Phase Red). Ce n'est qu'après avoir garanti que le bug est capturé par le test que l'agent apporte des modifications, jusqu'à ce que le test devienne vert (Phase Green).

5. Pièges, erreurs courantes et sécurité

1. "Diff Blindness" (Cécité de revue) : Lorsque le diff contient plus de 800 lignes, les yeux se fatiguent et, après 2 minutes de défilement, l'ingénieur clique simplement sur "Approve". Si la PR est trop volumineuse — ne validez jamais l'intégralité. Exigez que la tâche soit découpée en parties atomiques de 200 lignes maximum chacune.
2. Mocks toujours passants (Tautological Tests) : Les agents génèrent souvent des tests qui valident leurs propres mocks : mockService.get.mockReturnValue(true); expect(mockService.get()).toBe(true). Ce type de test est toujours vert, mais ne teste aucune ligne de code réel. Vérifiez toujours la sémantique des assertions dans les tests générés.
3. Ignorer les avertissements du compilateur (Compiler Warnings) : L'habitude d'ignorer les avertissements jaunes du linter ou de convertir implicitement les types via as unknown as Type détruit entièrement le système de sécurité TypeScript. Suivez la règle : zéro avertissement dans la console.