La correction du code et des tests générés¶

Au-delà de la sécurité, deux questions intéressent directement le contrôle qualité : quel genre d'erreurs fait un modèle qui écrit du code, et les tests qu'il écrit sont-ils un instrument de mesure fiable ? La seconde question est la plus importante, parce que les orchestrateurs s'appuient de plus en plus sur des tests générés par l'agent lui-même.

Le genre d'erreurs¶

Les « bugs simples et stupides »¶

Jesse, Ahmed, Devanbu et Morgan (MSR 2023, arXiv 2303.11455) ont confronté Codex à un corpus de bugs d'une seule instruction déjà connus (simple, stupid bugs : mauvais opérateur, mauvaise variable, condition inversée). Le modèle reproduit le bug connu, mot pour mot, jusqu'à deux fois plus souvent que la version correcte. L'explication probable : ces bugs sont fréquents dans le code d'entraînement, et le modèle a appris ce qui est fréquent, pas ce qui est juste.

Une taxonomie des bugs du code généré¶

Tambon et al. (Empirical Software Engineering 30(3), 2025, arXiv 2403.08937) ont classé 333 bugs produits par trois modèles (CodeGen, PanGu-Coder, Codex) en dix motifs, validés par une enquête auprès de 34 praticiens et chercheurs. Parmi ces motifs : la mauvaise interprétation de la demande, l'objet halluciné (une fonction ou un attribut qui n'existe pas), le cas limite oublié, l'erreur de syntaxe. La liste complète n'a pas été vérifiée sur le texte intégral pour ce rapport.

Lecture qualité

Deux de ces motifs — l'objet halluciné et le cas limite oublié — passent facilement une relecture rapide, parce que le code a l'air plausible. Le premier se détecte mécaniquement (compilation, analyse statique, vérification des imports), le second seulement par des tests qui couvrent les limites. Le contrôle doit donc combiner les deux, et ne pas compter sur l'œil du relecteur pour l'un ni pour l'autre.

Des tests trop faibles surestiment la correction¶

EvalPlus : 80 fois plus de tests¶

Liu, Xia, Wang et Zhang (NeurIPS 2023, arXiv 2305.01210) ont repris le banc d'essai HumanEval en multipliant par 80 le nombre de tests de chaque problème. Sur 26 modèles, le taux de réussite pass@k chute alors de 19,3 % à 28,9 %. Une partie des « réussites » du banc d'origine étaient du code faux que des tests trop pauvres laissaient passer.

C'est un résultat de mesure au sens du chapitre Mesurer un agent : l'instrument (la suite de tests) avait une sensibilité insuffisante, et tous les scores calculés avec lui étaient biaisés vers le haut.

Les tests générés figent le comportement réel, pas le comportement voulu¶

Konstantinou, Degiovanni et Papadakis (arXiv 2410.21136, 2024, révisé en 2026) ont étudié les oracles de test — l'assertion qui dit ce que le programme devrait renvoyer — générés par des modèles sur 24 dépôts Java. Leur conclusion :

Les approches de génération de tests fondées sur les LLM capturent principalement le comportement réel du programme.

Autrement dit, quand on demande à un modèle d'écrire des tests pour du code existant, il lit le code et écrit des assertions qui décrivent ce que le code fait — y compris ses bugs. Le test passe, le bug est désormais protégé par un test. Les auteurs notent que des noms de tests et de variables explicites aident le modèle à retrouver l'intention, et que les oracles générés gardent un meilleur pouvoir de détection que ceux de l'outil classique EvoSuite.

Limite importante pour les orchestrateurs

Un agent qui écrit le code et ses tests produit un instrument de mesure calibré sur sa propre production. C'est l'équivalent industriel d'un opérateur qui réglerait son pied à coulisse sur la pièce qu'il vient d'usiner. Les tests générés peuvent servir de non-régression (ils figent un comportement accepté), mais pas de réception (ils ne disent pas si ce comportement est le bon). La réception exige des tests écrits avant le code, à partir de la spécification — ou par un autre agent qui ne voit pas l'implémentation.

Ce que fait l'industrie : filtrer les tests générés¶

Meta a déployé en 2024 un outil, TestGen-LLM, qui fait générer des tests unitaires supplémentaires par un modèle (Alshahwan et al., FSE 2024, arXiv 2402.09171 ; étude de l'éditeur sur son propre outil). Le pipeline écarte tout test qui ne compile pas, qui ne passe pas de façon fiable sur plusieurs exécutions, ou qui n'augmente pas la couverture :

Étape	Part des tests générés
Compilent	75 %
Passent de façon fiable	57 %
Augmentent la couverture	25 %

73 % des tests qui ont franchi ces filtres ont été acceptés par les ingénieurs. Meta parle d'ingénierie logicielle « assurée » : la sortie du modèle n'est jamais prise telle quelle, elle passe une série de contrôles déterministes.

Lecture SPC

Le pipeline de Meta est un poka-yoke en série : trois contrôles mécaniques avant toute intervention humaine. Seul un test sur quatre survit. C'est une illustration chiffrée de la règle du chapitre Jidoka, andon, poka-yoke : tout ce qui peut être vérifié mécaniquement doit l'être avant de solliciter un humain.

À retenir

Les modèles reproduisent volontiers les bugs fréquents (jusqu'à 2 fois plus que la version correcte) ; deux familles d'erreurs — objets hallucinés et cas limites — échappent à la relecture rapide.
Des tests trop pauvres surestiment la correction de 19 à 29 % (EvalPlus).
Les tests générés à partir du code figent ses bugs : bons pour la non-régression, pas pour la réception.
L'industrie filtre mécaniquement les tests générés ; chez Meta, un sur quatre survit.