J'ai écrit 61 tests pour mon mentor IA. Puis j'ai découvert qu'on ne pouvait pas non plus faire confiance aux tests

Il y a un mois, un développeur a intégré un mentor IA à sa plateforme d'apprentissage. Le modèle voit les leçons du cours, la progression de l'étudiant et sa dernière tentative sur l'exercice. Pour choisir le modèle et le prompt sur des chiffres plutôt qu'au feeling, il a construit un banc d'essai de 61 tests automatiques.

Une semaine plus tard, il s'est avéré que le banc de test se trompait aussi. Il validait des réponses tronquées, laissait passer des solutions toutes faites sous d'autres noms de variables, et recalait des refus pourtant corrects. Cet article explique comment est construit ce banc de test, ce qu'il a permis de découvrir, où il a créé une fausse confiance, et pourquoi le développeur a fini par ne plus faire confiance au modèle du tout.

Les tests : 61 questions en 13 groupes

Le banc de test se compose d'une question et d'un ensemble de vérifications automatiques : sous-chaînes, appels d'outils, longueur de réponse, langue. Chaque question comprend une réplique de l'étudiant et un ensemble d'attentes. Les 61 questions sont répartis en 13 groupes : leçons (12), attaques de prompt (10), discipline épistémique (6), progression de l'étudiant (5), code de l'étudiant (5), raisonnement d'ingénierie (5), limites du sujet (4), précision technique (3), références aux leçons (3), format et langue de la réponse (2), honnêteté (2), contexte du dialogue (2), ton (2).

Le mentor dispose de trois outils : recherche parmi 272 vraies leçons du cours, progression de l'étudiant (fixture du banc de test), dernière tentative de l'étudiant (fixture). Dans le banc de test, l'étudiant dispose d'une fonction Reverse qui modifie la slice d'origine sur place, alors que le contrat exige qu'elle retourne une nouvelle slice.

Trois modèles : DeepSeek, YandexGPT, Qwen

Le développeur a choisi parmi les modèles accessibles depuis des serveurs russes. Claude et OpenAI ont été écartés : leurs API refusent les requêtes selon l'IP. Yandex AI Studio propose trois options : DeepSeek V4 Flash, YandexGPT Pro et Qwen3.6 35B.

Premier passage sur 32 questions : • DeepSeek V4 Flash : 31/32 vérifications, 5 questions sur 5 réussies sur le code de l'étudiant, latence de 6,5 s. • YandexGPT Pro : 28/32 vérifications, seulement 3 questions sur 5 réussies sur le code, latence de 1,4 s. • Qwen3.6 35B : 2/7 vérifications, test interrompu.

YandexGPT a échoué sur l'essentiel : il n'appelait pas l'outil lorsqu'on lui demandait d'analyser le code de l'étudiant. Qwen n'était pas adapté à la configuration : son mode de raisonnement, limité à 1024 tokens, consomme tout le budget alloué à la réflexion.

Côté prix : DeepSeek a coûté 25,6 ₽ pour 32 questions, YandexGPT 116 ₽. L'écart ne vient pas de la grille tarifaire mais des tarifs du cache : chez DeepSeek, l'entrée mise en cache coûte quatre fois moins cher, chez YandexGPT elle coûte autant qu'une entrée normale.

Où le banc de test mentait au développeur

Sur une base de 57 questions, DeepSeek V4 Flash a passé trois exécutions consécutives : 50, 48 et 50 vérifications. Le développeur a classé les échecs en trois catégories : fausses erreurs du banc de test (corrigées), dépassement de longueur (limitation volontaire) et véritables erreurs du modèle.

Trois erreurs principales et récurrentes : • Solution toute faite à une demande d'aide — une fois sur trois, le modèle fournissait la solution complète au lieu d'un indice. Pour une plateforme où les exercices constituent le produit, c'est le pire des échecs. • Cours magistral au lieu d'une réponse — à la question « Que fait make en Go ?

», le modèle a répondu trois fois sur trois avec un véritable cours : capacité, deux blocs de code, déclaration de variable. • Énumération de causes au lieu d'un diagnostic — face à une erreur « connection reset by peer », il a listé les causes habituelles, alors que le prompt interdit explicitement de combler les lacunes avec des formules comme « généralement » ou « probablement ».

Deux erreurs cachées du banc de test lui-même : 1. Réponse tronquée comptée comme complète. Le fournisseur renvoyait finish_reason: length, mais le banc de test ne vérifiait pas ce champ et validait la réponse comme réussie.

2. Mode de raisonnement de DeepSeek activé par défaut. Le développeur ne transmettait pas ce paramètre, le banc de test fonctionnait donc avec un mode caché.

Avec reasoning_effort: none, l'exécution était 10 % moins chère et 40 % plus rapide, mais les échecs étaient différents. Avec reasoning_effort: high, le coût a augmenté de 55 %, la latence de 65 %, et un cas extrême est apparu : sur une question concernant Kubernetes, le modèle a effectué 11 recherches en 36 secondes pour 13 ₽.

Le développeur a conservé DeepSeek V4 Flash sur ses paramètres par défaut. Le score de 50 sur 57 ne représente pas un pourcentage de bonnes réponses, mais un nombre de vérifications automatiques passées. Il relit chaque réponse manuellement, car une vérification par sous-chaîne peut laisser passer une mauvaise réponse ou recaler une bonne. Au final, ce n'est pas le choix du modèle qui s'est révélé le plus utile, mais la liste des endroits où le banc de test créait une fausse confiance.