Le guide des évals IA : comment tester, mesurer et monitorer vos features IA en production

Construire une feature IA est une chose, mais garantir qu'elle ne fasse pas n'importe quoi en production en est une autre ! Contrairement au code classique, l'IA ne valide pas un résultat binaire, mais une intention. Alors, comment sortir de la boucle infinie du "c'est presque bon" et éviter que vos utilisateurs ne soient vos premiers testeurs ? Dans cet article, Kevin Si partage la méthodologie en 7 étapes qu'il a déployée sur une plateforme publicitaire majeure pour automatiser l'évaluation de l'IA.

Construire une feature IA, aujourd'hui, la plupart des équipes Produit savent faire. La partie qui coince, c'est celle d'après : comment savoir si ce que l'IA produit est réellement bon ?

Un chiffre pour cadrer le problème : selon un rapport RAND Corporation de 2024, environ 80% des projets d'IA échouent, soit le double du taux d'échec des projets IT classiques. Sur la GenAI spécifiquement, les taux d'échec sont encore plus élevés selon les estimations de Gartner.

Quand on teste du code classique, on sait à quoi s'attendre. Un bouton affiche une pop-up, la réponse est A, on vérifie que c'est A. Avec l'IA, ce confort disparaît. La réponse ne sera jamais exactement la même deux fois. Pire, sur une feature IA, on ne vérifie pas un résultat, mais une intention. Demandez à deux personnes de noter la qualité d'un texte généré : l'une verra 70% de bonnes réponses, l'autre 47%.

Cet article présente la méthode que j'ai construite par itération pendant 6 mois et que j'ai pu présenter et validée par Google. Je l'ai également appliqué en entreprise, sur une grande plateforme publicitaire en ligne : génération d'alt text, modification d'images, génération de contenu.

La boucle d'évaluation IA en 7 étapes (vue d'ensemble)

Avant de détailler chaque étape, voici la séquence complète:

1. PRD IA : Définir les edge cases, les guardrails (entrée, process, sortie) et le seuil de réussite avant de lancer le développement.
2. Dataset représentatif : Le volume de ce dataset varie selon la fonctionnalité, cela va de quelques dizaines à quelques centaines généralement. Le plus important est qu'il doit refléter la diversité de la production.
3. Error Analysis : Analyser les premiers résultats de l'IA pour identifier les modes de défaillance spécifiques à votre domaine, plutôt que de plaquer des métriques génériques.
4. LLM-as-a-Judge : Construire un ou plusieurs juges spécialisés, les calibrer par comparaison avec les annotations du domain expert jusqu'à un taux de validation suffisant.
5. Test offline : Lancer la feature sur le dataset, vérifier qu'on atteint le seuil défini dans le PRD.
6. Observabilité : Déployer, brancher le LLM-as-judge en temps réel, surveiller les scores, les coûts et les logs d'interaction.
7. Impact et itération : Mesurer les métriques business et l'adoption, en croisant quantitatif et qualitatif. Réinjecter les données réelles dans le dataset. Recommencer.

Les risques de ne pas faire d'évaluation

Avant de rentrer dans le comment, un mot sur le pourquoi. Parce que la tentation de shipper sans eval est réelle, surtout quand votre démo impressionne tout le monde.

Voici ce qui arrive aux équipes qui sautent les étapes :

La boucle infinie "c'est presque bon" : Sans KPI explicite, on se retrouve dans un ping-pong permanent entre le dev et le PM. On fait une démo, on dit "ça marche bien, mais on voit encore tel truc." Le dev corrige, on refait une démo, on trouve autre chose. On ne sait jamais à quel moment c'est assez bon pour passer en production. J'ai vu des équipes passer 3 mois dans cette boucle sur des features qui auraient pu être livrées bien plus tôt avec un seuil clair.

La découverte des problèmes par les utilisateurs : Sans monitoring automatisé, on découvre les dégradations quand un client se plaint… c'est-à-dire, trop tard. Un changement de modèle, une mise à jour du prompt qui casse un edge cases, un nouveau type de données qu'on n'avait pas anticipé : sans observabilité, on est aveugle ! Impossible d'itérer sur la feature.

L'impossibilité de prioriser : Sans error analysis structurée, on corrige les problèmes dans l'ordre où on les remarque, pas dans l'ordre de leur impact. On peut passer une semaine à corriger un edge case qui affecte 0.5% des utilisateurs pendant qu'un bug qui touche 15% des cas passe inaperçu.

Le coût de mise en place d'une boucle d'évaluation est réel (comptez 2 à 4 semaines pour la première feature). Mais le coût de ne pas le faire est systématiquement plus élevé, et il se paie en temps perdu, en crédibilité, et en features IA qui finissent par être désactivées.

Étape 1 – Écrire le PRD avec les spécificités IA

Concrètement, dans le PRD d'un produit IA, trois éléments deviennent critiques en plus de tout ce qu'on fait habituellement.

Les edge cases

On en a beaucoup plus qu'avec du code classique, parce que le champ des possibles est plus étendu. Si on construit un chatbot conversationnel, l'utilisateur peut écrire n'importe quoi. Il faut lister ces cas limites en amont pour clarifier ce qu'on attend, et éviter que deux évaluateurs divergent de 20 points sur le taux de réussite (les résultats qu'on estime être bons).

Les guardrails

Ils interviennent à trois niveaux :

À l'entrée, en vérifiant ce que l'utilisateur soumet. Sur la plateforme où je travaillais, on ne voulait pas qu'une marque utilise notre outil de génération d'images pour traiter des photos de famille. Sinon, c'est nous qui payons le traitement, et l'utilisateur récupère gratuitement une image générée pour un usage qui n'a rien à voir avec notre produit.

Au milieu, c'est le process du modèle lui-même : comment le LLM traite la requête, quelles instructions il suit, quelles contraintes on lui impose dans le prompt (format de sortie, longueur, langue, périmètre thématique). C'est là qu'on cadre ce que le modèle a le droit de faire et comment il le fait.

En sortie : on vérifie qu'on ne produit pas de résultats indésirables et que le résultat correspond à l'intention qu'on avait définie. Avec du code classique, on attend une action précise. Avec l'IA, on attend que le résultat aille dans la bonne direction, sans pouvoir prédire sa forme exacte. Pour l'alt text, l'intention c'est "une description fidèle de la pub, avec les bons éléments dans le bon ordre". Le guardrail en sortie vérifie que cette intention est respectée : est-ce qu'on décrit bien la pub, et pas autre chose ? Est-ce que l'ordre des éléments est correct ? Est-ce qu'on n'a pas généré un texte hors sujet ?

Un exemple concret de ce qui se passe sans guardrails : un chatbot Chipotle qui répond à des questions de programmation Python au lieu de prendre des commandes de burritos. Le modèle fonctionne parfaitement, mais il répond aussi aux mauvaises questions.

Le seuil de réussite

C'est le point qui m'a le plus manqué au début. La solution : se donner un taux de succès cible avant de commencer le développement. Par exemple : "si on obtient 85% de bonnes réponses sur nos cas de test en recette, on passe en production."

Ce seuil dépend de la criticité de la feature. Pour l'alt text, on savait que le texte serait modifiable par l'utilisateur. Avant notre feature, les marques ne remplissaient même pas ce champ. Au pire, elles suppriment ce qu'on génère et écrivent autre chose : le risque est limité. Donc 70% de réussite, c'était déjà un vrai progrès.

Sans ce seuil, on risque de toujours vouloir faire mieux alors que passer de 85% à 90% coûtera infiniment plus cher que de passer de 0% à 85%. Au fond, le seuil de réussite est un outil de gouvernance. C'est lui qui met fin aux débats subjectifs ("moi je trouve que ça marche pas assez bien"). Et c'est lui qui permet d'arbitrer l'investissement : est-ce qu'on met deux semaines de dev supplémentaires pour gagner 5 points, ou est-ce qu'on shippe et on itère en production ? Sans seuil, cette décision est politique. Avec un seuil, elle est factuelle.

Etape 2 : Construire un dataset de test représentatif

Pour tester de manière fiable, il faut un dataset avec des données d'entrée, les résultats attendus (bonnes et mauvaises réponses), et suffisamment de diversité pour couvrir la réalité de la production.

Je prends un exemple concret. Sur la plateforme publicitaire où je travaillais, les marques uploadent des visuels de campagne. On a développé une feature IA qui génère automatiquement l'alt text de ces images. Dans mon PRD, j'avais défini des règles de génération différentes selon le type de contenu visuel : une pub avec du texte et un logo ne devait pas être décrite de la même façon qu'une image contenant uniquement un logo.

C'est cette granularité dans la spécification qui détermine ensuite la diversité du dataset de test. Il nous fallait également des pubs américaines, des pubs européennes, des pubs asiatiques, en proportions représentatives de ce qu'on reçoit en production. Parce que chaque variation de contenu visuel est un cas de test potentiel. On avait la chance d'avoir une équipe dédiée (Product Analytics) qui gérait cette partie. C'est un prérequis pour tout produit ou feature d'IA en général : de la donnée de qualité, bien ordonnée.

Si vous n'avez pas d'équipe data dédiée, il est possible de générer les données grâce à l'IA. Si on vérifie ce que l'IA génère et qu'on nettoie les hallucinations, des données synthétiques restent mieux que pas de données du tout. Et si on arrive à produire un dataset synthétique de plusieurs centaines de lignes propres, on est dans une bonne position.

Etape 3 : L'analyse d'erreur (error analysis)

C'est l'étape que la plupart des équipes sautent, et c'est pourtant celle qui a le meilleur ROI.

L'error analysis consiste à regarder les premiers résultats de l'IA, trace par trace, et à laisser émerger les catégories d'erreurs spécifiques à votre application.

Pourquoi les métriques génériques ne marchent pas

L'erreur la plus courante est de plaquer des métriques issues de la recherche académique ("hallucination", "toxicité", "helpfulness") sur un produit concret. Ces catégories sont trop larges pour être actionnables. Sur mon alt text, "hallucination" ne m'apprenait rien. Ce qui m'apprenait quelque chose, c'était : "le modèle ignore le texte incrusté quand il y a une apostrophe", "le modèle confond les patchs avec des logos", "le modèle se contente du nom de la marque au lieu de décrire l'image."

Ces catégories d'erreurs spécifiques, on ne peut pas les deviner en amont. Elles émergent quand on regarde les données.

Comment faire concrètement

Le process suit une logique empruntée à la recherche qualitative (open coding puis axial coding) :

Open coding. On lit les traces (input + output de l'IA) une par une, et on note ce qui ne va pas en langage libre. Pas de catégories prédéfinies, juste des observations brutes.

Axial coding. On regroupe les observations similaires en catégories. Ces catégories deviennent les modes de défaillance (failure modes) de votre application. Ce sont ces métriques qu'il faudra automatiser avec le LLM-as-a-Judge, pas des métriques génériques.

Re-coding. On repasse sur les traces avec les catégories affinées, on vérifie la cohérence, on fusionne ou découpe les catégories si nécessaire.

Combien de cas faut-il tester ? On travaillait avec 400 cas de test. Chez Atlassian, j'ai entendu parler de datasets de plus de 500 cas. Mais en fin de compte le chiffre absolu compte moins que la saturation théorique, c'est-à-dire le moment où chaque nouvelle erreur qu'on découvre est une erreur qu'on avait déjà identifiée. Tant qu'on trouve des catégories d'erreurs inédites, on continue.

Qui doit réaliser cette tâche ? Ça dépend des organisations. Dans l'idéal, c'est un domain expert qui a la légitimité pour juger si un résultat est bon ou mauvais : un médecin pour un chatbot santé, un juriste pour un outil contractuel, un pricing analyst pour un outil de tarification. Dans les équipes où ce profil existe, le PM cadre le process et le domain expert annote. Dans les entreprises où il n'y a pas de domain expert dédié, c'est au PM de le faire. C'est du temps, mais c'est non négociable : sans cette étape, tout ce qui suit repose sur une base instable.

Saturation théorique : quand s'arrêter de tester

En recherche, on appelle la saturation théorique l'idée qu'il n'y a pas UN nombre universel et absolu de cas à tester pour que les résultats soient concluants.

Je m'explique : à force d'ajouter des cas de test, il arrive un moment où chaque nouvelle erreur qu'on trouve est une erreur qu'on avait déjà identifiée. Les patterns se répètent, on ne découvre plus rien de nouveau. C'est le signal qu'on a couvert la quasi-totalité des cas.

Quand je testais mes 400 lignes d'alt text, je me suis rendu compte qu'au bout d'une centaine de cas, j'avais atteint la saturation. J'avais identifié les patterns d'erreur récurrents : quand l'image contenait un texte avec une apostrophe, le modèle ne le prenait jamais en compte ; quand il y avait un patch dans l'image, le modèle le considérait comme un logo et ignorait le texte à l'intérieur… Et ainsi de suite. J'ai quand même testé les 400 lignes, mais je n'ai pas trouvé de nouvelles catégories d'erreurs.

C'est le même principe que les entretiens utilisateurs bien ciblés : au bout de 5 ou 6 interviews, on retombe sur les mêmes problèmes. Ce qui compte, c'est davantage la diversité des cas couverts que le volume brut.

Ce que ça change pour la suite

L'error analysis détermine ce que le LLM-as-a-Judge va évaluer. Sans elle, on construit un juge qui vérifie les mauvaises choses. C'est la différence entre un test unitaire qui teste ce qui casse réellement, et un test qui vérifie des trucs qui ne tombent jamais en panne.

Etape 4 : automatiser l'évaluation avec un LLM-as-a-Judge

L'analyse d'erreur, ça marche. Mais ça ne passe pas à l'échelle. Vérifier 100 cas un par un me prenait une demi-journée. En production, avec des milliers d'utilisateurs par jour, c'est impossible de maintenir ce rythme. Et surtout, une fois la feature en ligne, il faut pouvoir détecter une dégradation rapidement, pas trois semaines plus tard quand quelqu'un pense à relancer une vérification manuelle. C'est là qu'intervient le LLM as a Judge.

Le LLM as a Judge, en deux mots : au lieu de vérifier moi-même ligne par ligne si chaque résultat est correct, je délègue ce travail à un autre LLM. On lance la feature IA sur chaque ligne du dataset, et le judge évalue automatiquement si la réponse est bonne ou non, selon les critères qu'on lui a donnés dans son prompt.

Par rapport à l'annotation manuelle, le gain est double. D'abord en volume : là où je testais péniblement 100 cas dans ma demi-journée, le judge peut en traiter des milliers en quelques minutes. Ensuite en continuité : le judge peut tourner en permanence en production. Il produit un score (de 0 à 1, par exemple 0,95), et si un jour ce score chute à 0,70, on le voit immédiatement. On peut remonter à la cause : une modification du prompt, un changement de modèle, un nouveau type de données qu'on n'avait pas anticipé. Sans ce monitoring, on est aveugle. On découvre les problèmes quand un client se plaint, c'est-à-dire trop tard.

C'est pour ça que le LLM as a Judge se construit avant le développement de la feature et pas après. Dès que le dev livre une première version, on peut la tester automatiquement sur tout le dataset au lieu de passer une demi-journée à vérifier 100 cas à la main. Et le jour du déploiement, le judge est déjà prêt pour tourner en production.

Comment le structurer

Le LLM as a Judge n'est pas forcément un seul prompt monolithique. On peut (et on devrait) le découper en plusieurs juges spécialisés. Dans le cas de la feature pour l'alt text :

• Un juge qui vérifie l'ordre des éléments dans la description
• Un juge qui vérifie la cohérence globale
• Un juge qui vérifie le nombre de caractères

L'avantage de ce découpage, c'est que certains juges sont réutilisables. Le juge "nombre de caractères" pourrait par exemple servir sur d'autres features IA sans modification.

L'annotation manuelle : calibrer le judge

L'annotation manuelle, ça marche. Mais ça ne passe pas à l'échelle. Vérifier 100 cas un par un me prenait une demi-journée. En production, avec des milliers d'utilisateurs par jour, c'est impossible de maintenir ce rythme.

Le principe

Au lieu de vérifier moi-même ligne par ligne si chaque résultat est correct, je délègue ce travail à un autre LLM. On lance la feature IA sur chaque ligne du dataset, et le judge évalue automatiquement si la réponse est bonne ou non, selon les critères qu'on lui a donnés dans son prompt.

Pourquoi faire confiance au judge plus qu'à la feature elle-même ? Parce qu'évaluer (est-ce que cette réponse est correcte, oui ou non ?) est une tâche plus simple que générer (produis la bonne réponse). À modèle équivalent, un LLM est meilleur pour discriminer que pour créer. Et comme l'évaluation se fait offline, on peut utiliser un modèle plus puissant que celui de la feature sans contrainte de latence.

Le gain est double. D'abord en volume : là où je testais 100 cas dans ma demi-journée, le judge peut en traiter des milliers en quelques minutes. Ensuite en continuité : le judge peut tourner en permanence en production. Il produit un score, et si ce score chute, on le voit immédiatement.

Comment le structurer

Le LLM-as-a-Judge n'est pas un seul prompt monolithique. On peut (et on devrait) le découper en plusieurs juges spécialisés, chacun focalisé sur un seul mode de défaillance identifié lors de l'error analysis. Dans le cas de l'alt text :

• Un juge qui vérifie l'ordre des éléments dans la description
• Un juge qui vérifie la cohérence globale
• Un juge qui vérifie le nombre de caractères

L'avantage de ce découpage : certains juges sont réutilisables sur d'autres features sans modification. Et surtout, quand un score chute, on sait immédiatement quel aspect pose problème.

Quelques bonnes pratiques issues de la recherche récente sur les LLM judges :

• Restreindre les évaluations à des décisions binaires (Pass/Fail) plutôt que des échelles de Likert. Les LLMs sont mauvais pour produire des scores cohérents sur une échelle de 1 à 5.
• Inclure des exemples (few-shot) de cas Pass et Fail clairs dans le prompt du juge.
• Ajouter des rubrics (définitions précises de ce qui constitue un Pass et un Fail) pour réduire l'ambiguïté.
• Utiliser un format de sortie structuré (JSON) pour faciliter le parsing automatique.

Calibrer le judge avec des annotations humaines

Avant de faire confiance au judge, il faut le calibrer. Le process : le développeur fait tourner la feature sur l'ensemble du dataset et produit un spreadsheet avec l'input et l'output. Le domain expert passe ensuite chaque ligne en revue. Le domain expert, c'est la personne qui a la légitimité pour juger : souvent le PM, mais ça peut être un médecin pour un chatbot santé ou un juriste pour un outil juridique.

Une fois ces annotations faites, on ajoute une colonne : ce que le LLM-as-a-Judge a noté pour chaque ligne. On compare. Là où ils divergent, on retravaille le prompt du juge. C'est une boucle itérative : on ajuste, on relance, on compare, jusqu'à obtenir un taux de validation suffisant.

Les trois métriques à suivre pour évaluer la fiabilité du judge :

• TPR (True Positive Rate) : quand le résultat est réellement bon, est-ce que le judge le reconnaît comme bon ? C'est la métrique la plus impactante à maximiser.
• TNR (True Negative Rate) : quand le résultat est mauvais, est-ce que le judge le détecte ?
• Matthews Correlation Coefficient (MCC) Score : c'est la mesure la plus importante, elle mesure la qualité des classifications binaires qui varie de -1 à +1. Un score de +1 représente une prédiction parfaite, 0 une prédiction aléatoire moyenne et -1 une prédiction inverse. (en savoir plus)

On n'atteindra jamais 100% d'alignement, mais à 90%, on sait qu'on peut faire confiance au juge pour tourner en autonomie.

Gérer l'imperfection d'une feature IA

Une feature IA fera des erreurs. La question, ce n'est pas comment les éliminer, c'est comment concevoir l'expérience pour que ces erreurs ne soient pas un problème pour l'utilisateur.

On avait plusieurs leviers selon les features. Pour la génération d'images, on proposait trois variantes et l'utilisateur choisissait celle qui lui convenait, avec un bouton pour régénérer s'il n'était satisfait par aucune des trois. Pour l'alt text, le texte généré était modifiable : si l'utilisateur n'était pas d'accord, il cliquait et corrigeait à la main. Dans les deux cas, on affichait un message prévenant que le résultat pouvait être imparfait.

Le point commun de ces approches : l'utilisateur garde la main. On ne lui présente pas le résultat de l'IA comme une vérité, on lui donne un point de départ qu'il peut ajuster. C'est une différence de posture dans la conception du produit.

Etape 5 : Surveiller la feature en conditions réelles (observabilité)

Un dataset de test, aussi bien construit soit-il, reste une approximation de la réalité. En production, ce sont de vrais utilisateurs avec de vraies données, et les écarts avec ce qu'on avait anticipé apparaissent vite. C'est pour ça que la première chose à mettre en place après le déploiement, c'est l'observabilité, avant même de regarder les métriques business.

Concrètement, on surveillait trois choses :

• Les scores du LLM as a Judge en temps réel. Le même judge qu'en phase de test, mais qui tourne maintenant en continu sur un échantillon des données réelles (typiquement 1 à 5% du trafic, évalué en asynchrone). Une chute de score est le premier signal qu'il faut investiguer.
• Les coûts d'utilisation du modèle. Si les utilisateurs régénèrent beaucoup, la facture monte, et c'est souvent le signe que la feature ne donne pas un résultat satisfaisant du premier coup.
• Les logs d'interaction. Comment les utilisateurs se servent réellement de l'outil. Ces logs alimentent aussi le dataset pour les itérations suivantes.

Je recommande de traiter cette couche d'observabilité avant de s'intéresser à l'impact business, parce que si la feature ne fonctionne pas correctement sur les données réelles, les métriques business ne veulent rien dire.

À quoi ressemble l'observabilité en pratique

Tout ce que je viens de décrire (scores, coûts, logs), il faut un outil pour le centraliser. Personnellement, j'utilise Langfuse. D'autres plateformes centralisent l'observabilité des features IA : LangSmith, Arize, Weave (W&B), DeepEval… Ce qui compte, c'est d'avoir un endroit unique qui donne une vue par feature IA avec les traces, les scores, et les coûts.

Un point souvent négligé : le judge drift. Les LLM judges peuvent dériver dans le temps, à cause de mises à jour du modèle sous-jacent ou de changements dans vos critères de qualité. Il faut pinner les versions de modèles utilisés pour l'évaluation, et re-valider régulièrement les judges contre des annotations humaines fraîches.

Quelques fonctionnalités pratiques dans ces outils

Traces. Chaque interaction utilisateur est enregistrée comme un enchaînement logique : l'action déclenchée, le prompt envoyé au modèle, le résultat reçu. C'est ce qui permet de reconstituer exactement ce qui s'est passé pour un cas donné, et de récupérer de la donnée réelle pour enrichir le dataset.

Evaluation score. Le score du LLM as a Judge, complété par d'autres métriques que l'outil propose nativement.

Running cost. Le coût de fonctionnement découpé par feature et par projet. On peut voir d'un coup d'œil que la génération de texte coûte tant avec tel score de qualité.

Prompt management. Je ne l'ai pas encore utilisé, mais le potentiel est fort. C'est du versioning de prompts, un peu comme Git mais pour les instructions qu'on donne au modèle. Concrètement, ça permet de lancer un A/B test entre deux versions d'un prompt et de comparer leurs scores.

Debugging. La partie technique : les logs détaillés pour comprendre ce qui a planté quand quelque chose ne fonctionne pas.

Le piège du monitoring passif

Même avec des juges automatisés bien calibrés, il faut continuer à regarder manuellement des traces aléatoires. Les juges automatisés ne détectent que les modes de défaillance qu'on a programmés. Les nouveaux types d'erreurs, ceux qu'on n'avait pas anticipés, ne se trouvent qu'en regardant les données. C'est un investissement de temps régulier, mais c'est ce qui empêche la qualité de dériver silencieusement.

Etape 6 : Mesurer l'impact réel sur le business et sur l'usage

Une fois qu'on sait que la feature fonctionne correctement en production, on peut s'intéresser à ce qu'elle apporte réellement.

La distinction AI metrics vs. product metrics

C'est un point critique souvent confondu :

• Les métriques d'évaluation IA (scores des juges, taux de réussite) mesurent si l'IA fait bien ce qu'on lui demande.
• Les métriques produit (adoption, satisfaction, impact business) mesurent si ce que l'IA fait a de la valeur pour l'utilisateur et pour le business.

On peut avoir des scores IA excellents et un produit qui ne marche pas : l'IA fait ce qu'on lui demande, mais ce qu'on lui demande ne résout pas le problème de l'utilisateur. L'inverse est vrai aussi : des métriques produit en hausse peuvent masquer une IA qui se dégrade.

Ce qu'on mesurait concrètement

Sur la plateforme publicitaire, on suivait l'adoption de la feature (combien d'utilisateurs l'activent, combien l'utilisent régulièrement), le taux de modification post-génération (si 80% des utilisateurs modifient le texte généré, c'est un signal de qualité insuffisante), et le coût par utilisation (qui combiné avec le taux de régénération donnait le vrai coût d'une "bonne" sortie IA). On avait aussi des boutons thumbs up / thumbs down dans l'interface : simple, mais ça donne un signal immédiat.

Les dimension importantes mais souvent négligées

Qui fixe le seuil de réussite ?

Le PM dit 85%, le CTO veut 95%, le business veut shipper la semaine prochaine. Sans processus clair, le seuil devient un terrain de négociation politique plutôt qu'une décision produit.

Ma recommandation : chez nous, le seuil est fixé par le PM en concertation avec le domain expert, validé par le leadership, et documenté dans le PRD avant le développement. Une fois fixé, il faut un consensus explicite pour le changer. Sinon, on finit par déplacer le poteau de but à chaque démo. Faites un RACI clair pour définir les rôles de chacun.

"La démo marche bien, on n'a pas besoin d'évaluer"

C'est le scénario le plus courant et c'est normal, c'est comme ça que toutes les boîtes commencent avec les fonctionnalités IA. Un stakeholder voit une démo impressionnante et veut shipper immédiatement. Le problème : une démo, c'est 5 cas bien choisis à la main. La production, c'est 5000 cas par jour que personne n'a choisis et que tout le monde veut essayer de démolir.

Il est vrai que le setup initial sur l'observabilité et le temps de prendre en main toutes les étapes prendront un peu de temps, mais par la suite, vous serez aussi rapide que de développer sans évaluer avec un niveau de confiance, de fiabilité beaucoup très élevé.

Le coût réel de l'évaluation

Mettre en place cette boucle prend du temps. Pour une première feature, comptez 2 à 4 semaines de travail PM + dev.

Mais le setup est réutilisable. Le deuxième produit IA ira beaucoup plus vite, parce que l'infrastructure (le LLM-as-a-Judg, les outils d'observabilité, les process d'annotation, le lancement du dataset sur la feature…) est déjà en place.

C'est un investissement de départ, et non un coût récurrent par feature.

Au début, ne soyez pas non plus trop dogmatique, il est possible que des fonctionnalités IA soient déjà en production chez vous, n'attendez pas que tout soit mis en place, commencez par de l'analyse d'erreur, testez à la main vous même. Cela vous donnera déjà beaucoup d'insights.