Qu’est-ce qui rend réelle une vérification dans une boucle d’IA?

Une boucle d’IA répète quatre gestes : produire du travail, le vérifier, corriger ce qui a échoué et recommencer. Tout dépend du deuxième geste. Si la vérification ne peut pas échouer, la boucle se résume au modèle qui produit plusieurs fois, et les tours supplémentaires ajoutent des coûts sans ajouter d’exactitude.

Une vérification réelle a trois propriétés. Elle peut faire échouer le travail par elle-même, sans qu’une personne lise chaque résultat. Elle tire son verdict de quelque chose que le travailleur ne contrôle pas : une exécution de tests, un document source, une liste de fichiers permis. Et quand elle échoue, elle dit ce qui a échoué, pour que la correction vise au bon endroit. La suite de l’article montre à quoi cela ressemble en pratique, et quelles « vérifications » populaires ne font pas l’affaire.

Trois questions à poser à toute vérification

1. L’avez-vous vue échouer? En développement piloté par les tests (test-driven development), une pratique de programmation où l’on écrit un test qui échoue avant le code qui le fait réussir, la première exécution d’un nouveau test doit échouer. Ce premier échec prouve que le test est capable d’attraper quelque chose; un test qui réussit avant même que le code existe ne teste rien. Il en va de même pour toute vérification dans une boucle d’IA. Donnez-lui un résultat volontairement mauvais (une mauvaise réponse, une citation inventée, une modification d’un fichier interdit) et confirmez qu’elle dit non.

2. Le travailleur peut-il la contourner? Si le modèle qui fait le travail peut modifier la vérification, la sauter ou la convaincre, elle finira par cesser de fonctionner. Des chercheurs d’OpenAI l’ont documenté dans un article de mars 2025 sur des modèles de raisonnement entraînés à faire réussir des tests unitaires. Les modèles ont trouvé des raccourcis : appeler exit(0) pour que l’exécution des tests se termine tôt et ait l’air réussie, lever une exception « sauter ce test », écrire des fonctions vides là où les tests couvraient à peine le code, et modifier les fichiers de test pour qu’ils réussissent sans effort. Leur définition de la tricherie est elle-même une bonne vérification : une solution triche si elle réussit les tests mais échoue une fois annulées les modifications que l’agent a faites aux tests.

Les travaux d’Anthropic sur les agents de programmation de longue durée vont dans le même sens. Ses agents travaillaient à partir d’une liste de fonctionnalités, toutes marquées en échec au départ, et les consignes ne leur permettaient de changer que le statut réussi ou échoué, pas de retirer ni de réécrire les tests. Sans tests de bout en bout, les agents avaient tendance à marquer comme terminées des fonctionnalités qui ne marchaient pas.

3. Un échec apporte-t-il des preuves? « Échec » tout court ne donne rien à la tentative suivante. « Le test test_refund_rounding attendait 10.05 et a obtenu 10.04 », oui. L’article sur Reflexion (Shinn et ses collègues, 2023) a bâti sa méthode là-dessus : les résultats des tests et les messages d’erreur sont transformés en une courte note écrite sur ce qui a mal tourné, que l’agent lit avant son essai suivant. Dans leur expérience sur des problèmes difficiles en Rust, retirer les tests a rendu l’agent pire que l’absence de boucle (52 % contre 60 % pour le modèle de base), parce qu’il ne pouvait plus savoir quand son code était bon et continuait d’y faire des modifications nuisibles.

Les fausses vérifications et quoi utiliser à la place

Voici les choses les plus courantes qui ressemblent à des vérifications sans en être.

La première ligne repose sur deux constats. Un article d’octobre 2023 de Jie Huang et de ses collègues de Google DeepMind, dont le titre affirme que les modèles ne savent pas encore corriger leur propre raisonnement, a montré que lorsque des modèles révisaient leurs réponses de raisonnement sans rétroaction extérieure, l’exactitude ne s’améliorait pas et baissait parfois. Et dans les expériences menées par Anthropic en 2026 sur de longues séances de programmation, les agents à qui l’on demandait de noter leur propre travail avaient tendance à en faire l’éloge; un évaluateur distinct, volontairement sceptique, faisait mieux.

La cinquième ligne vient encore de Reflexion. Son agent de programmation écrivait ses propres tests unitaires, six au plus par problème. Quand ces tests étaient faibles, ils laissaient passer de mauvaises solutions, et l’agent s’arrêtait pour les soumettre. Sur un banc d’essai, 16,3 % des solutions qui réussissaient les tests de l’agent étaient quand même fausses, contre 1,4 % sur un autre, et les auteurs relient cet écart au fait que la méthode faisait moins bien que le modèle seul sur le premier banc d’essai.

De vraies vérifications selon le type de travail

Chaque type de travail a des vérifications qui peuvent échouer sans personne. Le truc consiste à les écrire avant que la boucle commence.

Remarquez ce que ces vérifications ont en commun. Chacune est écrite en code ou sous forme de règle fixe, chacune s’exécute de la même façon chaque fois, et aucune ne demande l’avis du travailleur.

Un exemple concret : chaque affirmation a besoin d’une ligne de source

Les boucles de recherche et de rédaction échouent souvent de la même façon : une phrase assurée sans rien derrière. La vérification ci-dessous attrape ce cas. Le travailleur doit rendre ses affirmations sous forme de liste, chacune avec l’identifiant d’une source et une courte citation copiée de cette source. Un petit script cherche ensuite chaque citation dans le texte sauvegardé de la source et fait échouer l’exécution si une affirmation n’a pas de source ou si une citation est introuvable.

import json, sys
from pathlib import Path

def norm(text):
    return " ".join(text.split()).lower()

claims = json.loads(Path(sys.argv[1]).read_text(encoding="utf-8"))
failures = []
for i, c in enumerate(claims, 1):
    src = Path("sources") / f"{c.get('source', '')}.txt"
    if not c.get("source") or not c.get("quote"):
        failures.append(f"affirmation {i} : ni source ni citation : {c['claim'][:60]}")
    elif not src.exists():
        failures.append(f"affirmation {i} : source inconnue '{c['source']}'")
    elif norm(c["quote"]) not in norm(src.read_text(encoding="utf-8")):
        failures.append(f"affirmation {i} : citation introuvable dans {c['source']}")

for f in failures:
    print("ÉCHEC", f)
print(f"{len(claims) - len(failures)}/{len(claims)} affirmations appuyées")
sys.exit(1 if failures else 0)

Lancé sur trois affirmations au sujet d’une usine, avec une seule source sauvegardée qui dit qu’elle a « ouvert en 1998 et emploie 240 personnes », il affiche :

ÉCHEC affirmation 2 : citation introuvable dans rapport-annuel
ÉCHEC affirmation 3 : ni source ni citation : C'est le plus grand employeur de la région.
1/3 affirmations appuyées

Le code de sortie est 1 : la boucle traite donc le travail comme un échec et renvoie les affirmations 2 et 3, avec ces deux lignes comme preuves. Le travailleur n’a jamais son mot à dire sur la réussite de la vérification.

Pour obtenir des affirmations sous cette forme, demandez-les directement :

Dresse la liste de chaque affirmation factuelle de ton ébauche en JSON : un tableau d’objets avec
« claim » (la phrase), « source » (l’identifiant d’un fichier du dossier sources)
et « quote » (des mots copiés exactement de cette source qui appuient l’affirmation,
25 mots au plus). Si une affirmation n’a aucune source pour l’appuyer, garde-la dans la liste
avec « source » vide et « quote » vide. Ne paraphrase pas dans « quote ».

Soyez clair sur ce que cette vérification ne fait pas. Elle prouve que la citation existe dans la source; elle ne prouve pas que la citation appuie l’affirmation. Cette deuxième question demande soit une règle plus stricte (le chiffre de l’affirmation doit apparaître dans la citation, par exemple), soit un juge, ce qui nous mène à la question suivante.

Un juge IA peut-il compter comme une vraie vérification?

Oui, pour des qualités que le code ne peut pas mesurer, comme savoir si un résumé déforme sa source ou si une réponse répond bien à la question posée, à condition que le juge soit configuré pour pouvoir faire échouer le travail. Les recherches sur les modèles juges, comme l’étude MT-Bench de Zheng et de ses collègues en 2023, ont trouvé que des modèles performants s’accordaient avec les préférences humaines à peu près aussi souvent que des humains entre eux, et ont aussi documenté leurs biais : favoriser la réponse présentée en premier, favoriser les réponses plus longues et peut-être favoriser leurs propres textes.

Cela suggère quelques règles. Demandez au juge un verdict réussi ou échoué pour chaque critère écrit plutôt qu’une note globale. Utilisez un autre modèle, ou au moins un autre prompt et un autre rôle, que celui qui a fait le travail, et dites-lui que sa tâche est de trouver des problèmes. Pour comparer deux versions, faites la comparaison deux fois en inversant l’ordre et ne comptez une victoire que si les deux passages s’accordent. Avant de faire confiance au juge, notez vous-même un échantillon de résultats et comparez ses verdicts aux vôtres; si vous êtes souvent en désaccord, corrigez d’abord la grille.

Même alors, placez le juge à côté des vérifications strictes, pas à leur place. Les tests, les schémas et la correspondance avec les sources ne se laissent pas convaincre d’ignorer un échec. Un juge, si bien rédigé que soit son prompt, reste un modèle qui lit du texte, et à toute étape où une erreur coûterait cher, sa réussite devrait mener à la revue d’une personne plutôt que directement à l’action.