Évaluer l’IA en 2026 : cycle concret et coût réduit

Les évaluations comportementales comblent le vide entre tests unitaires et contrôles manuels. Chiffres à l’appui, des praticiens décrivent un cycle simple: transformer chaque échec réel en cas d’or automatisé, sans alourdir la pile ni bloquer la CI. Le coût annoncé d’un passage complet tourne autour de 0,56 $, loin des références de recherche facturées des milliers.

Écrire des évaluateurs après les échecs observés, pas avant

Hamel Husain et Shreya Shankar indiquent que, face à la question du « développement piloté par évaluations », la bonne réponse est généralement non. Leur cours a formé plus de 4 500 personnes et leur recommandation, formulée en juillet 2026, est d’écrire des évaluateurs pour les erreurs constatées plutôt que d’anticiper toutes les dérives possibles. Leur justification tient à l’ampleur de la surface d’échec des LLM, trop vaste pour être couverte a priori. Le « piloté » renvoie donc aux échecs réels, et l’étape d’analyse d’erreurs, souvent évitée, devient la source de cas d’évaluation réellement utiles.

Démarrer petit et ne pas bloquer la CI : 20 à 50 cas d’or, juge binaire

Le démarrage recommandé se situe entre 20 et 50 cas issus d’échecs réels, chacun vérifié par un juge LLM binaire qui n’interrompt jamais l’intégration continue. Un retour d’expérience décrit 36 cas d’or sans dépendance additionnelle, avec une facture de test d’environ 0,56 $ par exécution complète. Cette approche ne requiert ni équipe de machine learning, ni plateforme d’évaluation, ni budget de recherche. À l’inverse, des références de recherche coûtent des milliers de dollars par campagne, alors que l’objectif ici est d’évaluer un produit en cours d’évolution.

Ce qu’une évaluation mesure et ce qu’elle n’est pas

Une évaluation d’IA consiste à fournir une entrée au système, appliquer une règle de score à la sortie et mesurer le succès : le cœur est le comportement observé. Cela diffère d’un test unitaire, qui affirme ce que fait le code, tandis qu’une évaluation affirme ce que fait le modèle avec ce code. Les tests simulés encodent l’hypothèse testée et un modèle simulé « se comporte », ce qui explique pourquoi certaines dérives passent inaperçues. Les évaluations, elles, sont des vérifications automatisées et rejouables d’un comportement non déterministe ; elles n’éliminent ni la vitesse et la gratuité des tests unitaires, ni la capacité unique de la revue manuelle à débusquer des échecs inédits. Un guide 2026 qualifie même cette couche d’élément que les équipes omettent avant de le regretter. Cette pratique, dite codage basé sur les évaluations, revient à transformer l’observation en infrastructure qui rejoue à chaque changement. Des travaux de recherche la définissent comme une validation par observation des résultats, plutôt que par compréhension ligne à ligne.

Le contrôle manuel rassure peu : chiffres sur la pratique et ses limites

La majorité des praticiens ont déjà testé des modèles manuellement : 82 % selon une étude d’avril 2026 (n=51), et 83 % souhaitent davantage de structure ou d’automatisation. Du côté des développeurs, 46 % déclarent se méfier de l’exactitude des sorties et 66 % citent le « presque correct, mais pas tout à fait » comme irritation principale dans une enquête 2025 d’environ 49 000 répondants. Le contrôle ponctuel reste utile à l’exploration, mais il n’échantillonne qu’une requête à un moment donné et forme un filet de régression fragile. Les retours de terrain indiquent que ces sorties « presque correctes » continuent d’apparaître, précisément la classe d’erreurs que le manuel saisit mal sur la durée.

Ce que manquent les simulations : deux échecs concrets attrapés en réel

Des modes d’échec discrets échappent aux tests simulés. Un changement infime dans la description d’un outil a suffi à faire cesser une suggestion d’appel par l’assistant, remplacée par une réponse en prose, alors que tout restait au vert côté simulation ; l’exécution du modèle réel sur des cas enregistrés a été nécessaire pour le détecter, puis l’échec a été figé en cas d’or dans le dépôt. Autre exemple : une fonctionnalité de mémoire a cessé d’ingérer de nouveaux faits parce qu’un modèle conservateur et économique renvoyait un tableau vide valide. Là encore, les simulations ne signalaient rien, et seule l’exécution du modèle réel a levé le lièvre. Ces situations montrent que des évaluations de comportement, adossées à des cas d’or, permettent de neutraliser des régressions qui passeraient autrement inaperçues.

Baromètre des équipes : observabilité élevée, évaluations encore lacunaires

Fin 2025, 89 % des équipes travaillant sur des agents disposaient d’une observabilité en place, mais à peine la moitié menaient des évaluations hors ligne face à un jeu de tests. Trois équipes sur dix n’avaient toujours pas d’évaluation, et la qualité arrivait en tête des freins à la mise en production, devant la latence et le coût, selon le même sondage. L’éditeur à l’origine de l’enquête commercialise par ailleurs des outils d’évaluation, ce qui invite à lire les répartitions comme directionnelles. Dans ce contexte, Garry Tan affirmait en février 2025 que les évaluations deviennent un rempart pour les startups d’IA.