Code généré par IA : créer un banc de test fiable

1.Introduction

L'IA accélère réellement le développement : exploration d'API, squelette de service, tests, migration d'endpoint, documentation technique. Pour une équipe produit, ce gain de vitesse est trop important pour être ignoré.

Mais cette vitesse crée un nouveau problème : la qualité perçue augmente plus vite que la qualité vérifiée.

Une démo peut convaincre. Le code compile. Les tests passent. Et pourtant, l'agent peut introduire une dépendance inutile, contourner un invariant métier, dupliquer un pattern dangereux ou choisir une architecture vite coûteuse à maintenir.

La bonne réponse n'est pas de bloquer l'IA. C'est de l'encadrer : objectifs clairs, garde-fous, tests reproductibles, traces, arbitrage humain et variance mesurée.

Un mot sur le vocabulaire : harness n'est pas un anglicisme gratuit ici. En tests logiciels, "test harness" est un terme standard ; le glossaire CFTL/ISTQB le traduit même par "harnais de test". Dans l'écosystème LLM, on parle aussi de "Language Model Evaluation Harness". Pour un article français orienté SEO et business, le meilleur compromis est donc d'écrire banc de test IA dans les zones visibles, tout en expliquant qu'il s'agit du harness d'évaluation côté ingénierie.

Prenons un cas concret : évaluer des skills d'agents Go. L'objectif n'est pas de prouver qu'un modèle est "meilleur" dans l'absolu, mais de répondre à une question professionnelle : ce workflow IA améliore-t-il vraiment la qualité du code dans mon contexte ?

2.Pourquoi les benchmarks IA sont souvent trompeurs

Un benchmark IA peut mentir sans intention de mentir. Il suffit qu'il soit trop petit, trop flou, trop dépendant du juge ou impossible à reproduire.

2.1.Des scores globaux non reproductibles

Un score du type "87% de réussite" ne veut pas dire grand-chose si l'on ne connaît pas :

• les prompts exacts utilisés ;
• la version du modèle ;
• la température, les outils et les limites de contexte ;
• le nombre de runs par cas ;
• les sorties brutes ;
• les critères de notation ;
• la variance observée.

Deux runs du même modèle peuvent diverger : outils appelés, fichiers lus, stratégie de refactor. Sans traces, le score final perd son contexte.

2.2.Le piège du LLM-as-judge

Utiliser un LLM comme juge est pratique. Pour des critères qualitatifs comme "la solution respecte-t-elle l'architecture existante ?" ou "le code est-il idiomatique Go ?", il permet de scaler l'évaluation.

Mais un juge LLM reste un modèle avec ses biais. La recherche a documenté plusieurs effets importants :

• biais de position : le juge favorise parfois la réponse placée en premier ;
• biais de verbosité : une réponse longue peut sembler plus sérieuse qu'une réponse correcte et concise ;
• self-enhancement : un modèle peut préférer un style proche du sien ou de sa famille de modèles ;
• biais d'autorité : une réponse qui cite une source ou une "bonne pratique" peut être surévaluée, même si l'application au contexte est mauvaise.

2.3.Absence de transcripts et prompts trop visibles

Pour évaluer un agent de développement, le transcript est aussi important que le résultat final. Il montre si l'agent a lu les bons fichiers, lancé les tests, inspecté l'erreur ou simplement produit un patch plausible.

Autre erreur fréquente : exposer au candidat les assertions exactes du benchmark. Si le prompt dit explicitement "ne jamais importer de librairie utilitaire externe", l'agent peut optimiser pour l'assertion au lieu de raisonner sur l'architecture. Ce n'est plus une évaluation de compétence, c'est un exercice de conformité au texte visible.

La bonne pratique consiste à séparer ce qui guide l'exécution de ce qui sert à juger. Le développeur humain peut connaître les standards d'équipe. Le candidat IA ne doit pas recevoir la grille cachée item par item.

2.4.Trop peu de tests, trop vite publiés

Un smoke test de cinq prompts est utile. Il permet de vérifier que le pipeline tourne, que les clés API fonctionnent, que les artefacts sont bien générés. Mais ce n'est pas un benchmark publiable.

Un benchmark publiable doit permettre de refaire l'expérience : cas versionnés, runs multiples, outputs bruts et méthode de scoring documentée.

3.Ce que disent la recherche et les bonnes pratiques

Les documentations officielles autour des evals détaillent les notions de datasets, runs, graders code, modèle et humains. Les travaux académiques rappellent aussi que la statistique compte. Comme la plateforme Evals d'OpenAI est en dépréciation, je parle ici de principes transférables, pas d'un outil unique à adopter.

"Meilleur" est trop vague. On doit préciser :

• le code compile-t-il ?
• les tests déterministes passent-ils ?
• la solution conserve-t-elle l'API publique ?
• la dépendance ajoutée est-elle justifiée ?
• la décision d'architecture est-elle traçable ?
• le patch est-il plus simple ou plus complexe que le baseline ?

3.1.Prioriser les graders déterministes

Quand un critère peut être vérifié par du code, il doit l'être par du code. En Go, cela veut aussi dire vérifier les conventions mécaniques et idiomatiques, pas seulement le résultat fonctionnel :

• go test ./... ;
• go test -race quand c'est pertinent ;
• gofmt ou goimports ;
• go vet ;
• analyse statique ;
• vérification de go.mod ;
• tests d'intégration ciblés ;
• comparaison de l'API exposée.

Le LLM-as-judge intervient ensuite pour ce que les tests capturent mal : cohérence architecturale, simplicité, style de projet, qualité de justification.

3.2.Séparer candidat, juge et calibration humaine

Un banc de test fiable ne demande pas au même modèle de produire le code et de se noter lui-même. Le juge doit être séparé du candidat, idéalement en aveugle : pas de nom du modèle, pas d'indication "avec skill" ou "sans skill".

Il faut ensuite construire un calibration_sample.jsonl : un sous-ensemble relu par des humains, avec verdicts attendus et cas ambigus. On mesure si le juge automatique s'aligne avec le jugement humain. Quand il diverge, on ajuste la rubrique, pas le score final à la main.

Un bon juge doit aussi pouvoir répondre unknown. S'il manque un transcript, si les tests n'ont pas tourné ou si le diff est incomplet, le verdict correct n'est pas pass ni fail. C'est unknown, avec une raison explicite.

3.3.Mesurer la variance, pas seulement la moyenne

Sur des evals IA, un score moyen sans intervalle de confiance est trop pauvre. Anthropic recommande de reporter des erreurs standards, intervalles de confiance et comparaisons par paires quand on compare des modèles.

Dans un contexte d'entreprise, on peut rester pragmatique :

• score par item ;
• différence with-skill - without-skill par item ;
• bootstrap ou intervalle de confiance à 95% ;
• taux de unknown ;
• taux de divergence humain vs juge ;
• coût et latence par run.

Si le skill gagne 3 points mais que l'intervalle de confiance va de -4 à +10, la conclusion honnête est : "signal intéressant, pas encore prouvé".

4.Cas concret : évaluer des skills d'agents Go

Prenons un skill destiné à guider un agent de développement Go. Il dit, par exemple : privilégier la standard library, limiter les dépendances, respecter les idiomes Go, écrire des tests lisibles, éviter l'abstraction prématurée, documenter les décisions non évidentes.

La question n'est pas : "est-ce que ce skill sonne bien ?" La question est : est-ce qu'il améliore les décisions de l'agent sur des tâches réalistes ?

4.1.Comparer with-skill et without-skill

Le protocole minimal :

1. même modèle ;
2. mêmes tâches ;
3. même budget de tokens et de temps ;
4. même dépôt de départ ;
5. run avec skill ;
6. run sans skill ;
7. juge aveugle ;
8. tests déterministes ;
9. analyse statistique par paire.

Les tâches doivent ressembler à de vrais tickets :

• ajouter une commande CLI Go ;
• refactorer une configuration ;
• remplacer une dépendance inutile ;
• corriger un bug concurrent ;
• écrire un middleware HTTP ;
• simplifier un graphe de dépendances.

4.2.Go stdlib-first ne veut pas dire "zéro dépendance"

En Go, une approche stdlib-first est souvent saine. Le langage fournit déjà beaucoup : HTTP, JSON, flags, tests, context, sync, errors. Ajouter une dépendance doit rester une décision.

Mais il ne faut pas transformer cette règle en dogme. Une librairie de CLI peut être pertinente pour un outil complexe. Un chargeur de configuration peut aider quand les sources se multiplient. Un conteneur d'injection peut se justifier dans un service avec un graphe d'initialisation lourd. Une librairie de helpers peut aussi rendre le style moins idiomatique si l'équipe n'en veut pas.

Un bon skill Go ne dit donc pas "interdit toutes les libs". Il force l'agent à justifier : quel problème cette dépendance résout-elle ? Quelle alternative standard library existe ? Quel coût ajoute-t-elle à la maintenance ?

5.Architecture d'un banc de test IA fiable

Un banc de test IA professionnel, ou harness d'évaluation, ressemble davantage à une mini-chaîne CI/CD qu'à un notebook jetable.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
evals/
  go-agent-skills/
    cases/
      cli_config_refactor.jsonl
      dependency_policy.jsonl
    rubrics/
      architecture.md
      go_idioms.md
    calibration_sample.jsonl
    run.yaml
artifacts/
  run-2026-06-26/
    transcripts/
    diffs/
    test-results/
    judge-inputs/
    judge-outputs/
    report.json

5.1.Evals versionnées

Les cas d'évaluation doivent vivre dans Git, comme les tests. Chaque changement de dataset, de rubrique ou de prompt doit être reviewable. Sinon, un score peut évoluer parce que le modèle s'améliore ou parce que le benchmark a changé.

Chaque cas devrait contenir une fixture de départ, une instruction réaliste, les contraintes visibles, les assertions cachées, les tests à lancer, les critères de jugement et les métadonnées attendues.

5.2.CI GitHub Actions et secrets API

Le harness doit tourner en CI, avec des secrets stockés dans GitHub Actions : OPENAI_API_KEY, ANTHROPIC_API_KEY, GEMINI_API_KEY. Les clés ne doivent jamais apparaître dans le dépôt ni dans les artefacts.

La CI doit publier les artefacts bruts : transcripts, diffs, résultats de tests, entrées du juge, sorties du juge, rapport agrégé. Sans eux, impossible d'auditer une conclusion.

5.3.Providers IA : rester agnostique

Un harness solide doit abstraire le provider, non pour prétendre que tous les modèles sont interchangeables, mais pour éviter une évaluation prisonnière d'une API.

En pratique :

• Gemini peut servir à valider à faible coût la mécanique du pipeline, mais son free tier reste borné par des limites par modèle et par projet : RPM, TPM et RPD ;
• les runs représentatifs doivent utiliser le provider réellement retenu par l'équipe : Anthropic, OpenAI, Google AI, modèle open source ou modèle interne ;
• les versions de modèles doivent être figées dans le rapport ;
• les paramètres doivent être sauvegardés avec chaque run.

Le bon score est celui qui répond à votre décision. Si votre équipe code avec un modèle, un agent de développement ou un workflow interne précis, évaluez ce workflow exact.

5.4.Judge aveugle et artefacts bruts

Le juge ne doit pas savoir quelle réponse vient du run with-skill. Il reçoit deux solutions anonymisées, les résultats de tests, les diffs et la rubrique. L'ordre est randomisé. Les noms de modèles sont masqués.

Le rapport doit distinguer :

• résultat déterministe ;
• verdict du juge ;
• verdict humain sur l'échantillon calibré ;
• unknown ;
• coût ;
• latence ;
• variance.

Cette séparation évite de confondre "ça compile", "c'est maintenable" et "le juge préfère cette réponse".

6.Ce que je recommande aux entreprises

Commencez petit, mais propre.

6.1.1. Un dry-run avant tout chiffre

Prenez 10 à 20 cas internes, non sensibles, et faites tourner le pipeline. Le but n'est pas de publier un résultat. Le but est de trouver les erreurs de harness : prompts mal injectés, fixtures instables, artefacts absents, parsing fragile, secrets mal configurés.

6.2.2. Valider à faible coût, sans surinterpréter Gemini Free

Si vos quotas Gemini le permettent, utilisez-le pour tester la mécanique. Mais traitez le free tier comme un environnement contraint : limites de requêtes par minute, tokens par minute, requêtes par jour, reset quotidien et erreurs 429 possibles si le harness parallélise trop. Vérifiez les limites actives dans Google AI Studio, limitez la concurrence et prévoyez un backoff. C'est un moyen de valider le pipeline, pas une preuve de performance production.

Ensuite seulement, lancez les runs coûteux sur les modèles réellement représentatifs : les modèles payants, les agents de développement ou la stack agentique interne que votre équipe utilise vraiment.

6.3.3. Ne jamais publier un chiffre sans artefacts

Un benchmark sans artefacts est une opinion chiffrée.

Avant de communiquer un score à une direction, un board ou une équipe produit, assurez-vous de pouvoir montrer :

• dataset versionné ;
• prompts ;
• transcripts ;
• diffs ;
• tests ;
• rubriques ;
• calibration humaine ;
• intervalle de confiance ;
• limites connues.

Ce niveau de rigueur change la conversation. On ne vend plus "l'IA marche mieux" : on montre où le workflow améliore la maintenabilité avec un signal mesuré.

7.Checklist rapide pour votre équipe

Cadrage

• Les tâches évaluées ressemblent à vos vrais tickets.
• Les critères de succès sont écrits avant les runs.
• Les assertions cachées ne sont pas visibles par le candidat.

Exécution

• Les versions de modèles sont figées.
• Les paramètres et budgets sont sauvegardés.
• Les transcripts complets sont conservés.
• Les diffs et résultats de tests sont exportés.

Scoring

• Les tests déterministes passent avant le juge LLM.
• Le juge est séparé du candidat.
• Le juge est aveugle au modèle et à la condition.
• Le verdict unknown existe.
• Un échantillon est calibré par un humain.

Publication

• Le score est accompagné d'un intervalle de confiance.
• Les artefacts bruts sont disponibles.
• Les limites du benchmark sont explicitement documentées.
• Le chiffre n'est pas extrapolé au-delà du contexte testé.

8.Questions fréquemment posées

9.Conclusion

L'IA rend la gouvernance technique plus importante.

Un bon CTO ne bloque pas l'IA par principe. Il l'encadre : zones d'accélération, décisions humaines, garde-fous CI/CD, critères qualité et preuves nécessaires avant généralisation.

Le sujet n'est plus de savoir si l'IA peut écrire du code, mais de distinguer un patch séduisant d'un patch maintenable, un smoke test d'un benchmark, et un score isolé d'une mesure fiable.

Si vous voulez utiliser l'IA pour coder sans créer de dette technique invisible, commencez par le banc de test IA. C'est moins spectaculaire qu'une démo, mais c'est ce qui transforme l'IA en capacité d'ingénierie durable.