L'IA code plus vite que vous. Mais qui vérifie ce qu'elle raconte ?

Table des matières

Oui, je développe avec l’IA. Tous les jours.

Autant vous le dire tout de suite : je développe aujourd’hui augmenté par l’IA. Des agents de code — Claude Code en tête — font partie de mon quotidien de développeur, au même titre que mon IDE ou que Git. Ils écrivent du code, lancent mes tests, préparent mes commits, fouillent une codebase de plusieurs centaines de milliers de lignes en quelques secondes.

Et croyez-moi, le gain de vitesse est réel. Spectaculaire, même.

Mais voilà. Je travaille en ce moment sur un domaine où l’erreur ne pardonne pas : un système dont les règles viennent d’une spécification réglementaire publique — pensez à la réforme française de la facturation électronique, avec ses centaines de pages de PDF, ses tableurs d’annexes, ses codes de statut et ses délais légaux. Dans ce genre de domaine, la question n’est pas « est-ce que l’IA code vite ? », mais « est-ce que ce qu’elle affirme est vrai ? ».

Alors, comment je fais pour profiter de la vitesse sans avaler les inventions ? C’est tout l’objet de cet article : la discipline et les garde-fous que j’ai mis en place pour développer avec des agents IA sans jamais laisser passer une règle inventée. Et vous allez voir que ces garde-fous servent autant contre l’IA… que contre nous-mêmes.

Le pire bug n’est pas celui que vous croyez

Commençons par le vrai problème. Ce n’est pas le code qui plante. Un crash, une exception, un test rouge : ça se voit, ça se corrige, on passe à autre chose.

Non, le pire bug, c’est la règle plausible mais inventée. Celle qui « a l’air juste ». Celle qui survit à la revue de code parce que personne ne pense à la remettre en question.

Je l’ai vécu. Une référence du type §7.4.2 accompagnée d’une constante au nom très officiel-sonnant est née un jour… d’une extrapolation. Ni la référence ni la constante n’existaient dans la spécification. Mais c’était crédible. Alors ça a été recopié de commit en commit, cité en revue comme si c’était sourcé, jusqu’au jour où quelqu’un a posé LA question : « d’où ça sort, ça ? »

Réponse : de nulle part. Coût : plusieurs tours de revue et un commit correctif.

D’ailleurs, remarquez un point important : ce problème existait avant l’IA. Les développeurs ont toujours comblé les trous d’une spec par déduction. Mais les assistants IA ont un talent particulier pour ça : ils extrapolent avec aplomb, en produisant des références qui ont exactement la tête d’une vraie citation. Une règle inventée coûte d’autant plus cher qu’elle est crédible — et l’IA fabrique de la crédibilité à la chaîne.

Bref : si vous codez contre une spec dense avec un agent IA, il vous faut des garde-fous. Voici les miens.

Garde-fou n°1 : les vérifications automatiques, à chaque édition

Premier étage de la fusée, le plus simple : l’agent n’a pas le droit de me rendre du code non vérifié. Chaque fichier modifié déclenche automatiquement le formateur et le compilateur TypeScript. Si le type-check échoue, l’erreur revient directement à l’agent, qui corrige avant même que je voie le code.

Concrètement, avec Claude Code, ça se configure avec des hooks — des commandes exécutées automatiquement après chaque action de l’agent :

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [
          { "type": "command", "command": ".claude/hooks/format.sh" },
          { "type": "command", "command": ".claude/hooks/typecheck.sh" }
        ]
      }
    ]
  }
}

Rien de bien sorcier : le premier script lance Prettier sur le fichier modifié, le second lance tsc --noEmit. Si le type-check échoue, le script sort avec un code d’erreur qui renvoie la sortie du compilateur à l’agent. La boucle de correction se fait toute seule, sans moi.

Ce petit mécanisme change tout : je ne relis jamais du code qui ne compile pas. Mon attention est disponible pour les questions qui comptent — dont la plus importante : cette règle est-elle sourcée ?

Garde-fou n°2 : le SKIP honnête plutôt que l’arête inventée

Entrons dans le dur. Quand on implémente un cycle de vie réglementaire, la spec est forcément trouée : un code de statut listé sans sémantique précise, un ordonnancement non décrit, un cas particulier passé sous silence.

La pente glissante — pour un humain comme pour une IA — c’est de combler le trou par déduction : « le code 206 existe, il ressemble au 205, donc je le traite comme le 205 ». Trois commits plus tard, personne ne sait plus ce qui est écrit dans la spec et ce qui est deviné.

Ma règle : quand un cas est hors périmètre ou non spécifié, on ne devine jamais le comportement manquant. On l’ignore explicitement — ce que j’appelle le SKIP honnête :

// Résolveur : mappe un code de statut entrant vers une étape interne.
// Renvoie null = "hors périmètre" → l'appelant SKIP (jamais une erreur,
// jamais une étape inventée).
function resolveInboundStage(code: string): StageDecision | null {
  if (FINAL_STAGES[code]) return { kind: "FINAL", stage: FINAL_STAGES[code] };
  if (INTERMEDIATE_STAGES[code])
    return { kind: "INTERMEDIATE", stage: INTERMEDIATE_STAGES[code] };
  return null; // code non modélisé OU émis par un autre acteur → SKIP documenté
}

// Côté appelant :
const decision = resolveInboundStage(code);
if (!decision) {
  log.info(`statut ${code} hors périmètre — SKIP (voir doc de provenance)`);
  return Ok({ skipped: true }); // succès, pas échec : on n'y reviendra pas
}

Deux nuances importantes dans ce petit bout de code :

• le SKIP est un succès, pas une erreur. Re-tenter en boucle un code hors périmètre serait tout aussi faux qu’inventer son traitement ;
• un code que je sais hors périmètre (c’est un autre acteur qui l’émet) et un code dont l’ordonnancement n’est pas décrit sont tous deux des SKIP — mais pour des raisons différentes, et je documente laquelle.

« Inventer l’arête manquante » n’est jamais une option. Ni pour moi, ni pour l’agent.

Garde-fou n°3 : tagger la provenance de chaque règle

Celui-là, c’est mon préféré, parce qu’il est d’une simplicité désarmante. Chaque règle de ma table de transitions porte une étiquette de provenance :

• [R] : règle réglementaire explicite — écrite ou dessinée dans la spec ;
• [V] : séquence vérifiée par un test de conformité qui passe ;
• [D] : règle dérivée — une interprétation assumée, pas une flèche explicite ;
• [E] : étape purement technique, sans équivalent dans la spec.

flèche suspecte sans étiquette mise en évidence]

Le simple fait d’être obligé d’écrire la lettre force la question : « est-ce que je peux citer ça ? ». Une règle qu’on n’arrive à étiqueter ni [R] ni [V] est suspecte par construction — c’est au mieux du [D] à assumer en connaissance de cause, au pire une invention à retirer.

Et devinez quoi : quand je demande à un agent IA d’ajouter une règle, il doit fournir l’étiquette. S’il propose [R], je lui demande la citation. S’il ne peut pas la produire, la règle ne rentre pas. C’est aussi simple que ça.

Garde-fou n°4 : « not verified against source » est une valeur valide

Parfois, l’information dont vous avez besoin n’existe tout simplement pas dans la spec. Exemple vécu : le canal de transport d’un type de message entre deux plateformes n’était pas spécifié. Silence radio dans la documentation.

Dans ce cas, je ne tranche pas en silence. J’écris littéralement, noir sur blanc :

/**
 * Le canal de transport de ce message inter-plateformes n'est PAS spécifié
 * dans la documentation publique ("not verified against source").
 * Décision opérationnelle : on consomme depuis le canal Z. À revalider si la
 * spec se précise. Ce consommateur est volontairement transport-agnostique.
 */

Mieux vaut un trou assumé et visible qu’une certitude fabriquée. Le prochain lecteur — humain ou IA, d’ailleurs — sait exactement ce qui est gravé dans le marbre réglementaire et ce qui est une décision d’équipe susceptible de changer.

Cette convention est même inscrite dans les instructions de mes agents : quand une affirmation ne peut pas être vérifiée contre une source primaire, la réponse attendue n’est pas une extrapolation plausible, c’est la mention explicite du trou.

Garde-fou n°5 : la base de connaissances citable

On arrive au cœur du réacteur. Tous les garde-fous précédents reposent sur une capacité : pouvoir citer la source, maintenant. Encore faut-il que la source soit à portée de main.

Alors j’ai construit, directement dans le dépôt du projet, une base de connaissances réglementaire : les passages pertinents de la spécification publique transcrits verbatim — mot pour mot, avec leur référence exacte — et organisés par thème. Pas des résumés. Pas des paraphrases. Le texte.

Pourquoi verbatim ? Parce qu’un résumé, c’est déjà une interprétation. Et qu’une IA qui lit un résumé d’interprétation vous ressort une interprétation d’interprétation. En transcrivant le texte officiel, la chaîne de citation reste intacte : le code cite la base, la base cite la spec, et n’importe qui peut vérifier en trente secondes.

spécification officielle, avec un panneau “interdit” sur le raccourci code → mémoire de l’IA]

Et j’y ai ajouté une règle d’or, la plus contre-intuitive de toutes : une citation d’une session précédente n’est pas une citation vérifiée. Citer un §x.y.z « de mémoire » — la mienne ou celle de l’agent — c’est une affirmation non sourcée déguisée. La référence ne s’écrit qu’après avoir ouvert le document, maintenant.

Un comble pour un développeur qui adore automatiser, me direz-vous ? Peut-être. Mais c’est précisément cette friction-là qui casse le piège le plus vicieux du travail avec l’IA : la boucle de confirmation. Vous paraphrasez une règle, l’IA confirme votre paraphrase (qu’elle tient… de vous), vous voilà deux à être sûrs d’un truc que personne n’a vérifié. Un faux consensus redoutablement convaincant, fabriqué en deux échanges.

« Mais avec tous ces garde-fous, tu vas moins vite, non ? »

Bien entendu, c’est la question qu’on me pose à chaque fois. Et ma réponse est claire : non. C’est même l’inverse.

Ce qui coûte cher, ce n’est pas d’étiqueter une règle ou d’ouvrir un PDF. Ce qui coûte cher, c’est la règle inventée découverte trois semaines plus tard, les tours de revue pour la débusquer, et la confiance à reconstruire dans tout le code autour. Mes garde-fous coûtent quelques secondes par règle ; une hallucination en production coûte des jours.

En réalité, cette discipline est exactement ce qui me permet de déléguer beaucoup à l’IA. Je peux laisser un agent implémenter une machine à états complète précisément parce que je sais que le système — hooks, étiquettes de provenance, base citable — attrapera ce que ma vigilance laisserait passer un vendredi à 18h.

L’IA fait la vitesse. La discipline fait la qualité. Et le développeur, dans tout ça ? Il fait ce qu’aucun des deux ne sait faire : il tranche.

Épilogue : une vieille discipline pour un nouvel outil

Vous l’aurez compris, rien de tout ça n’est fondamentalement nouveau. Sourcer ses affirmations, documenter ses interprétations, ne pas confondre déduction et citation : c’est de l’ingénierie de bon sens, celle qu’on devrait pratiquer même sans IA.

Ce que l’IA a changé, c’est l’échelle. Un développeur fatigué invente une règle de temps en temps ; un agent en pleine forme peut vous en proposer dix par jour, toutes plus crédibles les unes que les autres. La discipline de la source de vérité n’est plus un luxe de perfectionniste — c’est le prix d’entrée pour travailler sérieusement avec ces outils.

Et vous, comment gérez-vous les affirmations de vos assistants IA ? Vous avez d’autres garde-fous, d’autres rituels ? N’hésitez pas à les partager en commentaire — je me ferai une joie de vous répondre.

Pour aller plus loin, je vous recommande ces articles :

• L’architecture hexagonale — mon fil rouge pour isoler le domaine… et donc les règles à sourcer ;
• La dette technique — parce qu’une règle inventée est une dette invisible, la pire espèce ;
• Les tests unitaires — le filet qui transforme une règle [D] en règle [V].