Dans la plupart des projets d’IA vient un moment où quelqu’un dit : «Ça a l’air vraiment bien, passons en production.» Ce jugement repose généralement sur une douzaine d’exemples triés sur le volet et testés en réunion. Puis le système affronte le trafic réel, et les questions commencent. Pourquoi a-t-il inventé une date de livraison ? Pourquoi est-il moins bon depuis que nous avons modifié le prompt ? Est-il meilleur ou moins bon que le mois dernier ?
Aucune de ces questions ne trouve de réponse sans évaluations, ou evals: un ensemble fixe de cas de test dont les bonnes réponses sont connues, exécuté automatiquement à chaque modification. Les évaluations sont aux systèmes d’IA ce que les tests automatisés sont aux logiciels. Vous ne mettriez pas en service une solution de paiement sans tests ; un système d’IA qui lit des factures ou répond à des clients mérite la même rigueur.
Partir du travail, pas du modèle
Un jeu d’évaluation utile découle du processus que le système soutient, et non de benchmarks génériques. Les classements publics indiquent comment un modèle s’en sort face à des questions d’examen. Ils ne disent rien de sa capacité à extraire la bonne date d’échéance des factures de vos fournisseurs.
Nous commençons donc par réunir des cas réels, anonymisés si nécessaire :
- Des cas typiques, dans la proportion où ils se présentent réellement. Si 70 % des commandes reçues sont de simples commandes de réapprovisionnement, 70 % du jeu doivent l’être aussi.
- Des cas difficiles que les experts connaissent : le fournisseur qui place le total en page deux, le client qui écrit en trois langues.
- Des cas où la bonne réponse est «je ne sais pas»: données manquantes, questions hors périmètre, documents contradictoires. Un système qui répond toujours est plus dangereux qu’un système qui décline parfois.
- Des cas adverses: des entrées qui cherchent à faire dérailler le système, par exemple un e-mail contenant des instructions destinées à l’IA.
Cinquante cas bien choisis valent mieux que cinq cents cas pris au hasard. Le jeu s’enrichit avec le temps : chaque erreur constatée en production devient un nouveau cas de test, afin que la même erreur ne puisse pas revenir en silence.
Mesurer ce qui compte pour l’entreprise
«Précision» semble simple, mais ce terme cache des choix. Pour un agent de traitement des factures, un montant erroné est bien plus grave qu’un numéro de bon de commande manquant. Pour un assistant de connaissances, une réponse sans source peut être acceptable pour une FAQ interne, mais pas pour des questions de conformité.
Nous définissons les métriques avec les responsables du processus, typiquement :
- L’exactitude par champ ou par réponse, pondérée selon le coût d’une erreur.
- L’ancrage dans les sources: chaque affirmation repose-t-elle sur une source que le système a effectivement récupérée ?
- La qualité de l’abstention: le système décline-t-il quand il le doit, et seulement dans ce cas ?
- La latence et le coût par cas, car une réponse correcte qui prend une minute ou coûte un franc peut malgré tout ne pas tenir le business case.
Chaque métrique reçoit un seuil à atteindre avant la mise en production. Ce seuil est fixé par écrit avant que les résultats ne soient connus, pour que personne ne soit tenté de changer les règles en cours de route.
Automatiser l’évaluation, puis contrôler l’évaluateur
Certaines réponses se vérifient mécaniquement : un montant extrait correspond ou ne correspond pas. Les réponses en texte libre sont plus délicates. Un second modèle peut alors jouer le rôle d’évaluateur, en comparant la réponse à une référence et à une grille d’évaluation. Cela fonctionne bien, mais seulement si l’évaluateur est lui-même validé : nous faisons noter un échantillon par des humains, nous comparons, et nous ne faisons confiance à l’évaluateur automatique que là où il concorde avec eux.
Les évaluations ne s’arrêtent jamais
La mise en production ne marque pas la fin de l’évaluation. Les fournisseurs mettent à jour leurs modèles, les documents changent, les utilisateurs trouvent de nouvelles façons de formuler leurs questions. Trois habitudes empêchent la qualité de dériver :
- Exécuter l’ensemble du jeu d’évaluation à chaque modification: un nouveau prompt, une nouvelle version de modèle, un nouveau réglage de recherche. Si un score baisse, la modification n’est pas déployée.
- Prélever des échantillons du trafic de production pour un contrôle humain régulier, avec les données personnelles masquées.
- Surveiller les signaux qui annoncent des problèmes: hausse du taux d’abstention, davantage de corrections humaines, réponses plus longues, coûts plus élevés.
Ce que cela signifie en pratique
Avant la mise en production d’un pilote, vous devriez pouvoir consulter un court rapport : le jeu d’évaluation, les métriques convenues, les seuils et les résultats, avec des exemples des cas où le système échoue. Si un prestataire ne peut pas vous le montrer, la réponse honnête à «est-ce prêt ?» est «nous ne le savons pas encore».
Ce rapport est aussi le meilleur outil pour la décision suivante. Il montre quelles erreurs subsistent, ce qu’elles coûteraient et si davantage de travail, un autre modèle ou une étape de validation humaine est le moyen le moins coûteux de les corriger.