L'evaluation suite. L'ingénierie sans paillettes derrière les agents qui partent en production.

Évaluation offline. La spec que l'agent doit à l'équipe.

L'evaluation suite offline est ce qui se rapproche le plus d'une spécification pour un AI agent. C'est un ensemble croissant de cas réels que l'agent doit traiter correctement, avec des sorties attendues, qui tourne chaque fois que l'équipe modifie un prompt, change de modèle ou met à jour un index de retrieval. Bien la rédiger force l'équipe à expliciter ce que veut dire bien, ce que le prompt engineering seul tend à laisser implicite.

Golden sets. Un échantillon représentatif de cas réels tirés du trafic de production ou d'exemples opérateurs, avec les sorties attendues documentées. Le golden set doit grandir avec le temps à mesure que de nouveaux cas sont ajoutés, en particulier les cas où l'agent a surpris l'équipe. Nous sommes entrés dans des missions où l'équipe disposait de quelques dizaines de cas golden. Nous sommes entrés dans d'autres missions où l'équipe en avait plusieurs milliers, organisés par cas d'usage et par difficulté. La bonne taille dépend de l'étendue du périmètre de l'agent, mais d'après notre expérience le golden set est rarement trop grand et fréquemment trop petit.

Regression suites. Chaque changement de l'équipe passe automatiquement contre le golden set. Une régression, c'est un cas qui passait avant et qui échoue désormais. L'équipe doit savoir dans les minutes qui suivent un déploiement si la nouvelle version régresse sur des cas que l'ancienne traitait. Les équipes avec lesquelles nous travaillons qui tiennent cette discipline gardent généralement leurs agents stables au travers des changements de modèle et des itérations de prompt. Les équipes qui exécutent la régression manuellement découvrent généralement les échecs par les utilisateurs.

Sondes adversariales. Un ensemble séparé de cas conçus pour faire échouer l'agent de manière instructive. Prompt injections, instructions ambiguës, entrées contradictoires, cas limites que l'opérateur ne produirait peut-être jamais un jour normal mais qu'un adversaire déterminé ou une situation inhabituelle produirait. Le set adversarial est là où les propriétés de sécurité de l'agent sont testées, et il doit grandir avec le temps à mesure que de nouveaux motifs d'attaque émergent dans l'écosystème.

Évaluation online. Ce que fait l'agent dans la nature.

L'évaluation offline donne à l'équipe la confiance que l'agent passe un ensemble défini de cas. L'évaluation online dit à l'équipe ce que l'agent fait réellement en usage réel, ce qui est toujours plus riche qu'aucun set offline ne peut capturer. Les trois schémas qui comptent sont le shadow traffic, l'A/B routing et l'échantillonnage pour revue humaine.

Shadow traffic. Une nouvelle version de l'agent tourne en parallèle de la version de production, sur les mêmes entrées, sans exposer les sorties de la nouvelle version aux opérateurs. L'équipe compare les deux versions cas par cas et fait émerger les divergences. Le shadow traffic est la manière la plus sûre de valider un changement majeur avant de l'exposer à de vrais utilisateurs, et les équipes qui construisent l'infrastructure pour cela une fois tendent à l'utiliser à chaque déploiement significatif.

A/B routing. Quand l'équipe est prête à exposer une nouvelle version, une fraction du trafic réel y est routée tandis que le reste continue sur la version existante. Les indicateurs qui comptent, satisfaction opérateur, taux d'override, latence, coût par session, sont comparés entre les deux. L'A/B routing dit à l'équipe si le changement a amélioré l'expérience pour de vrais utilisateurs, ce qui est le seul test qui compte au final.

Échantillonnage pour revue humaine. Une petite fraction des sessions réelles est mise de côté pour une revue humaine par les opérateurs, par des experts du domaine, ou par l'équipe build. Les relecteurs taggent les cas qui les ont surpris, que l'agent a mal traités, ou qui ont exposé un nouveau motif. Ces cas alimentent le golden set et les sondes adversariales. La boucle se referme, l'evaluation suite grandit, et l'agent s'améliore sur les cas qui comptent pour les vrais utilisateurs.

Détection de dérive. Le système d'alerte précoce.

Le troisième composant d'une evaluation suite sérieuse, c'est la détection de dérive, et c'est celui qui manque le plus souvent dans les équipes que nous auditons. La dérive vient sous quatre formes, dont chacune doit être surveillée explicitement par la suite.

Dérive d'entrée. La distribution des entrées qui arrivent à l'agent se déplace. Une nouvelle ligne de produits est lancée, une saison change, les opérateurs commencent à utiliser l'agent pour un autre type de tâche que celle initialement conçue. La dérive d'entrée est généralement l'alerte précoce que l'agent est utilisé d'une manière que l'équipe n'avait pas anticipée, et elle devrait déclencher une conversation plutôt qu'une dégradation silencieuse de la qualité.

Dérive de sortie. La distribution des sorties de l'agent se déplace. L'agent produit des types de réponses différents de ce qu'il produisait, ou les mêmes réponses dans des proportions différentes. La dérive de sortie peut signaler un problème avec le modèle sous-jacent, un problème de retrieval, ou simplement la dérive d'entrée qui rattrape le côté sortie. Dans tous les cas, c'est une information que l'équipe doit voir.

Dérive de latence. Les temps de réponse augmentent. C'est généralement la première dimension à dériver silencieusement, parce que l'agent produit encore des réponses utiles, simplement plus lentement. Les équipes qui suivent la latence au niveau des percentiles plutôt qu'à la moyenne attrapent les problèmes de queue de distribution avant qu'ils ne deviennent visibles pour l'utilisateur.

Dérive de coût. Le coût par session monte, parfois à cause d'une longueur de contexte accrue, parfois à cause de plus d'appels d'outils, parfois à cause d'un changement de tarif modèle. Sans suivi de coût à l'exécution, le premier signal que reçoit l'équipe est un rapport finance en fin de trimestre, et ce n'est pas une conversation que quiconque souhaite avoir.

L'équipe et l'outillage.

La composition de l'équipe qui possède l'évaluation compte plus que les outils spécifiques qu'elle utilise. D'après notre expérience, un ingénieur compétent qui possède l'évaluation à temps plein sur un agent en production sérieux, travaillant aux côtés de l'équipe build et des opérateurs, produit de meilleurs résultats qu'une équipe plus grande sans propriété. La discipline est l'actif. Les outils suivent.

Sur la question outillage, notre pratique est délibérément neutre. Le paysage comprend des frameworks open-source pour l'orchestration d'évaluation, des plateformes d'observability avec support natif des traces LLM, et des fournisseurs commerciaux pour des besoins spécifiques d'industries réglementées. Le bon outil pour un client donné dépend de ce qu'il exploite déjà, de ce que sa posture sécurité autorise, et de ce que l'équipe peut maintenir dans le temps. Nous recommandons généralement de construire au-dessus de l'existant plutôt que d'ajouter une stack parallèle, sauf si la stack existante ne peut réellement pas répondre aux exigences.

Build versus buy, voilà la question pratique. Notre recommandation par défaut est d'acheter la couche fondamentale, l'ingestion de traces, les dashboards, l'alerting de base, et de construire la couche spécifique au cas d'usage, les golden sets, les regression suites, l'outillage de revue opérateur. Le temps expert de l'équipe est mieux dépensé sur les cas spécifiques à leur agent que sur la reconstruction d'une infrastructure qui existe sur le marché.

Comment justifier le coût de l'évaluation au CFO.

Le travail d'évaluation est sans paillettes et tend à être sous-financé pour la même raison. Il ne produit pas de sortie démontrable. Il ne reçoit pas d'applaudissements en comité de pilotage. La conversation sur son coût, quand elle surgit avec un dirigeant finance qui revoit le budget IA, intervient généralement au mauvais moment, après que la suite a tourné tranquillement pendant un certain temps en épargnant au programme des problèmes qui ne se sont pas produits.

La manière dont nous recommandons de conduire cette conversation, c'est de documenter les moments où l'évaluation a gagné sa place. La régression attrapée avant déploiement. La dérive détectée avant que les utilisateurs ne la remarquent. Le cas adversarial trouvé avant qu'un vrai adversaire ne le fasse. La pointe de coût attrapée la semaine même où elle a commencé plutôt qu'à la fin du trimestre. Les équipes qui maintiennent un journal courant de ces moments défendent généralement leur budget évaluation facilement. Les équipes qui ne le font pas découvrent généralement que la conversation budget a déjà eu lieu en leur absence.

L'evaluation suite, c'est la partie du programme IA qui fait son meilleur travail quand rien ne se passe. L'art consiste à rendre l'absence d'échec visible aux personnes qui financent le travail.

Là où se construit la crédibilité d'un programme IA.

Quand un régulateur, un auditeur ou un comité du board demande comment l'équipe peut défendre la sûreté et la fiabilité d'une capacité IA en production, la réponse à apporter est ancrée dans l'evaluation suite. Les golden sets, les historiques de régression, les rapports de dérive, les taux d'override, les échantillons de revue humaine. Ce sont les livrables qui distinguent un programme IA qui opère sérieusement d'un programme qui opère par espoir. Ce sont aussi les livrables que l'AI Act et les régimes similaires exigeront de plus en plus explicitement, en particulier pour les catégories à haut risque où la charge de la preuve incombe à l'organisation déployante.

Construire l'evaluation suite avec les exigences réglementaires et d'audit en tête dès le premier sprint est significativement moins cher que de les ajouter après coup. Les équipes que nous conseillons dans les services financiers, la santé et d'autres contextes réglementés l'ont appris. Les équipes qui le découvrent encore sont généralement au milieu d'une conversation douloureuse sur des preuves qu'elles ne peuvent pas produire.

Si votre équipe construit des AI agents et que la discipline d'évaluation n'a pas encore été traitée comme un investissement de premier rang, la conversation par laquelle nous ouvrons est courte. À quoi ressemble votre golden set aujourd'hui. Qui le fait tourner à chaque changement. Que montre votre dashboard de dérive. Si ces trois questions ont des réponses claires, vous êtes plus avancés que la plupart. Sinon, la bonne prochaine étape est d'investir dans la suite avant de financer le prochain pilote.