Un prompt, un verdict : ce que les tests express des nouvelles IA ne vous disent pas

Un nouveau modèle sort le matin. À midi, mon fil LinkedIn est plein de verdicts : « J’ai testé X, il écrase Y », « Ce modèle vient de changer le métier de développeur pour toujours ». Le soir, une vidéo YouTube au titre spectaculaire explique que tout le reste est bon pour la poubelle.

Quand on regarde ce qui a été testé, on trouve presque toujours la même chose : un prompt, une seule fois. Un Snake en HTML, une landing page pour une startup imaginaire, un pélican à vélo dessiné en SVG, ou la question piège du nombre de « r » dans « strawberry ». Le résultat est joli ou raté, et le verdict tombe.

Je comprends l’envie. Je suis le premier à ouvrir un nouveau modèle le jour de sa sortie pour voir ce qu’il a dans le ventre. Mais entre jouer avec et en tirer une conclusion, il y a un pas que ces tests ne permettent pas de franchir.

Le Benchy des LLM

Ceux qui ont une imprimante 3D connaissent le Benchy. C’est un petit bateau de quelques centimètres que tout le monde imprime en premier en déballant sa machine. Il a été dessiné pour ça : ses parties en surplomb, que l’imprimante doit poser dans le vide, sa cheminée creuse et ses petits détails révèlent en une heure si l’imprimante est bien réglée.

C’est un bon test de calibration. Personne ne conclut pour autant, sur la foi d’un joli Benchy, que la machine réussira ses pièces mécaniques en PETG ou une grande plaque sans qu’elle se décolle du plateau. Et comme tout le monde connaît le Benchy, les profils d’impression par défaut sont réglés pour le réussir, et certains fabricants mettent en avant le temps qu’il leur faut pour l’imprimer.

Le Snake est devenu le Benchy des modèles de langage. Avec une différence de taille : le Benchy a au moins été conçu comme un test.

Le même prompt, dix Snake différents

« Fais-moi un Snake » ne précise presque rien, et un modèle de langage ne donne jamais deux fois la même réponse. Posez-lui la même demande dix fois, vous obtiendrez dix Snake différents, jusque dans la technologie choisie : un canvas en JavaScript pur, une version React avec une bibliothèque de jeu, parfois du Python. Certains fonctionnent du premier coup, d’autres plantent au démarrage.

Un test en un seul essai mesure donc autant la chance que le modèle. Et quand on compare deux modèles de cette façon, on compare souvent deux programmes qui n’ont presque rien en commun, avec un verdict qui dépend en bonne partie de la technologie que le testeur préfère.

Le test est choisi pour la vidéo

Le Snake, le pélican et la landing page ont un point commun : ils se regardent en trois secondes. Ils sont faits pour la capture d’écran, et c’est bien leur rôle dans une vidéo.

Votre travail ne ressemble pas à ça. Il ressemble à un contrat de quarante pages à résumer sans rien inventer, à une base de code de dix ans où il faut corriger un bug sans en créer deux, ou à un appel d’offres où une erreur de chiffre coûte le marché. Qu’un modèle réussisse un beau Snake ne dit rien de la façon dont il relira votre contrat.

Et comme pour le Benchy, ces prompts célèbres circulent depuis des mois dans les articles, sur les forums et dans les jeux de tests publics. Rien ne garantit qu’un modèle ne les a pas déjà croisés pendant son entraînement, et réussir un exercice dont on a vu cent corrigés ne prouve pas grand-chose.

Plus personne ne travaille en un seul coup

On sait aujourd’hui que les meilleurs résultats sortent d’un échange avec le modèle. Les agents de code planifient avant d’écrire, lancent les tests, lisent l’erreur et corrigent. C’est ce que fait l’agent qui corrige les failles de sécurité de mes projets : il corrige, vérifie que le scan de sécurité repasse au vert, puis ouvre une pull request que je relis avant de la merger. D’autres montages font relire une réponse par une seconde passe, découpent un problème en étapes ou vont chercher l’information qui leur manque avec des outils. Ces façons de faire se sont multipliées ces deux dernières années, et c’est là que se joue la qualité d’un modèle en situation réelle.

Un test en un seul coup n’en mesure que la première étape. Un modèle un peu moins brillant au premier jet peut très bien être meilleur pour comprendre son erreur quand on la lui montre, et c’est souvent cette qualité-là qui fait gagner du temps dans une vraie journée de travail.

Personne ne commande une maison en une phrase

Il y a aussi une question de posture, que je vis tous les jours. Je considère un agent comme un assistant, et avec un assistant on travaille par allers-retours : je donne une intention, il propose, je corrige, il reprend.

Personne ne dit à un constructeur « construisez-moi une maison avec une piscine », paie rubis sur l’ongle et se déclare satisfait à la remise des clés. Il y a des plans, des réunions de chantier, des choix à faire et des retours sur ce qui ne va pas. Juger un modèle sur une phrase lancée sans rien derrière, c’est lui demander ce qu’on n’attendrait d’aucun professionnel. Et l’inverse est vrai aussi : aucun professionnel ne supporterait de travailler comme ça. Imaginez le chef de chantier à qui l’on lance « Michel, fais-moi une piscine pour la semaine prochaine », sans plan, sans budget et sans jamais répondre à ses questions. Le travail bien fait se construit par itérations, et c’est déjà ce que je défendais à propos du code parfait.

Derrière ces tests en un coup, il y a enfin l’idée que tout doit aller vite, toujours plus vite. Les LLM réduisent déjà de façon spectaculaire le temps d’exécution, et potentiellement les coûts : ce qui prenait deux jours se fait parfois en une heure. Et pourtant ce n’est jamais assez, il faudrait en plus que le résultat soit juste en une phrase et du premier coup. Quelques échanges de plus se comptent en minutes, sur un travail qui demandait des jours. J’en parlais déjà dans le shot du samedi soir et le mur du lundi : une application qui marche sur un écran le samedi soir doit encore tenir en production le lundi, et c’est là que le temps se dépense.

Chaque modèle se prompte à sa façon

On ne parle pas tout à fait de la même manière à deux modèles différents. L’un préfère des consignes structurées en balises, l’autre des instructions courtes, un troisième a besoin qu’on active son mode de raisonnement pour donner le meilleur de lui-même. L’écart se réduit à chaque génération, mais il existe encore.

Copier le même prompt dans deux modèles pour les comparer revient donc souvent à avantager celui pour lequel le prompt a été écrit, en général celui qu’on utilise tous les jours.

Le modèle n’est qu’une pièce du montage

En usage réel, un modèle ne travaille jamais seul. Il tourne dans un harnais, un agent de code ou une application, qui lui ajoute des consignes sans le dire. Il dispose de compétences préparées à l’avance, d’outils branchés par MCP, d’une base de connaissances sur votre projet ou vos documents. Et la qualité de cette base pèse lourd, comme je l’ai montré à propos des angles morts du RAG en entreprise et de ce que les modèles oublient au milieu d’un long contexte.

Tout ce montage influe sur le résultat, parfois plus que le choix du modèle. Prenez un seul et même modèle : dans l’application grand public, appelé directement par l’API ou piloté par un agent de code, il ne répondra pas de la même façon, parce que chacun de ces outils lui envoie ses propres consignes avant même votre question. Le jour de la sortie, il faut encore compter avec des serveurs saturés, qui ralentissent les réponses.

Deux personnes qui disent avoir « testé le même modèle » n’ont donc presque jamais testé la même chose. Chacun a son harnais, ses compétences, ses fichiers de contexte et ses habitudes de prompt, et la comparaison porte sur tout ce montage autant que sur le modèle.

Pourquoi ces verdicts sont si tranchés

Si ces tests express sont partout, c’est aussi une question d’audience. YouTube et LinkedIn mettent en avant les contenus qui font cliquer et réagir, et le jour de la sortie d’un modèle, il faut publier vite pour arriver avant les autres.

Dans cette course, un titre comme « un peu meilleur sur mes cas, un peu plus cher, à confirmer sur la durée » ne fait pas de vues, alors que « il écrase tout » en fait. Les créateurs le savent, et leur format récompense le verdict rapide et tranché.

Je trouve ça dommage. Beaucoup de ces créateurs sont passionnés et compétents, et ils savent très bien tout ce que je viens d’écrire. La course aux vues et aux likes les pousse vers des sujets légers, qui ne résistent pas à deux secondes d’examen, et chacun de ces verdicts entame un peu la crédibilité qu’ils ont construite par ailleurs.

Comparer, oui, mais quand ça compte

Soyons réalistes : presque personne ne va comparer sérieusement deux modèles. Pour un usage personnel, cela veut souvent dire payer deux abonnements, et on garde en général celui qu’on a. C’est un choix raisonnable, et un verdict lu un soir sur LinkedIn ne justifie pas d’en changer.

Comparer deux modèles devient utile dans deux situations : quand on choisit le modèle qui fera tourner une application appelée des milliers de fois par jour, et quand le fournisseur retire la version qu’on utilise pour imposer la suivante. Dans les deux cas, on passe par l’API : on paie à l’usage, sans abonnement, et quelques dizaines d’appels de test coûtent peu.

Ce second cas est celui que je rencontre le plus souvent. Les fournisseurs retirent les anciennes versions à leur rythme, et passer à la suivante ne se résume pas à changer un nom de modèle dans la configuration. Il faut souvent adapter le harnais : les consignes, la description des outils, la façon de lire et de contrôler les réponses.

Dans une application qui passe par l’API, on dispose normalement de tests pour ça. Une série de cas fixes, dont on connaît la bonne réponse, est rejouée à chaque changement de version, et des vérifications automatiques contrôlent que le modèle prend les mêmes décisions sur les mêmes entrées et respecte le format attendu. C’est cette série de tests qui dit si la nouvelle version tient.

Si vous devez comparer deux modèles, voici ce que je conseille pour que la comparaison ait un sens :

• Décider avant de regarder ce qu’est une bonne réponse. Sinon on juge à l’impression, et l’impression favorise le modèle qu’on a envie d’aimer.
• Rassembler une vingtaine de vrais cas. Des demandes tirées de votre quotidien, chacune avec sa bonne réponse écrite à l’avance. Les cas faciles, et surtout ceux où le modèle actuel se trompe.
• Tester dans votre montage. Le même harnais, les mêmes outils et la même base de connaissances que ceux de votre usage quotidien, avec un prompt adapté à chaque modèle.
• Laisser le modèle échanger. Jugez-le sur la tâche terminée, corrections comprises.
• Faire tourner chaque cas plusieurs fois. Trois passages suffisent pour voir si un modèle est régulier ou s’il réussit un coup sur deux.
• Noter le coût et le temps de réponse. Un modèle un peu meilleur mais trois fois plus cher n’est pas forcément le bon choix pour une tâche qui tourne mille fois par jour.

Ce banc d’essai demande une demi-journée la première fois, puis il se rejoue à chaque nouvelle version. C’est beaucoup plus long qu’un Snake, mais cela donne une idée bien plus fiable de ce qu’un modèle vaut sur ce qui compte pour vous.

Le Snake a quand même son intérêt

Comme le Benchy, un test express reste utile pour vérifier qu’une machine fonctionne et pour avoir un premier aperçu de ce qu’elle sait faire. J’en ai fait l’expérience avec POPZ. Deux lignes de prompt et quinze minutes ont suffi pour obtenir un Puzzle Bobble jouable, et il m’a fallu ensuite une journée entière pour en faire un jeu.

Si j’avais jugé le modèle sur ces quinze minutes, je n’aurais rien vu de ce qui m’a occupé toute la journée. Un verdict en un prompt s’arrête au même endroit, au début du travail, là où tout paraît facile.

Je ne veux pas pour autant dénigrer le travail de ces créateurs. Les lire et les écouter reste intéressant, et une de leurs vidéos peut faire tilt chez quelqu’un et lui donner envie d’essayer un modèle qu’il n’aurait jamais regardé. Pour évaluer un nouveau LLM, il faut simplement lui laisser une période d’essai, comme on le fait au travail avec quelqu’un qui rejoint l’équipe.

Vous devez choisir le modèle d’une application, ou préparer le passage à une nouvelle version ? Je vous propose d’en parler lors d’un premier échange. Il me permettra de comprendre votre usage et de vous dire comment tester les modèles sur vos propres cas.