Pourquoi votre contrat avec un prestataire IA doit inclure une clause d'évaluation

Si votre prestataire IA ne peut pas vous montrer un jeu de tests scoré prouvant que son système fonctionne sur des cas qu'il n'a jamais vus, vous n'achetez pas un produit — vous achetez une démo. Demandez les évaluations avant de signer, pas après avoir reçu la facture.

Les fondateurs et les CTOs qui évaluent des prestataires IA sont devenus habiles à repérer une démo bien rodée. Ce que la plupart n'ont pas encore appris, c'est comment distinguer une démo qui fonctionne parce qu'elle a été répétée d'un système qui fonctionne parce qu'il a été testé. L'écart entre ces deux situations, c'est précisément ce à quoi servent les évaluations — et c'est la question la plus utile que vous puissiez poser dans un processus de sélection de prestataire.

Ce qu'est réellement une évaluation

Une évaluation, c'est un ensemble fixe d'entrées — des vraies questions, de vrais documents, de vrais cas limites issus de votre domaine — associées à des sorties attendues et notées, exécuté automatiquement à chaque modification du prompt sous-jacent, du modèle ou de la logique de récupération. Au lieu de « ça avait l'air de marcher quand j'ai essayé », vous obtenez un chiffre : 87 % des cas passent, contre 74 % au sprint précédent.

Ce n'est pas de la tooling exotique. OpenAI a publié en open source un framework de base à cet effet dès 2023 (openai/evals), et toutes les équipes IA sérieuses ont depuis construit une version équivalente, qu'elle soit sur mesure ou clé en main. Le concept est antérieur aux LLMs — c'est simplement du test automatisé, appliqué à un système dont les modes d'échec sont probabilistes plutôt que déterministes.

La raison pour laquelle cela compte davantage pour l'IA que pour une application web classique : un endpoint REST retourne soit le bon JSON, soit non. Une fonctionnalité LLM peut retourner une mauvaise réponse qui semble plausible dans 15 % des cas, et une démo de dix prompts soigneusement choisis ne le révélera jamais. Les évaluations sont le seul moyen de mesurer le taux d'échec avant que vos clients ne le découvrent.

Pourquoi c'est un enjeu pour l'acheteur, pas seulement pour l'ingénierie

Que vous recrutiez pour un chatbot sur mesure, un système de support basé sur le RAG ou un workflow agentique, le pitch deck du prestataire vous montrera systématiquement le chemin idéal. Ce n'est pas malhonnête — simplement, ce n'est pas une information. Les questions qui réduisent vraiment le risque à l'achat sont :

• Quelle est la taille de votre jeu d'évaluations, et d'où viennent les cas ?
• Quel est le taux de réussite actuel, et quelle est la tendance sur le dernier mois ?
• Que se passe-t-il au score d'évaluation quand vous changez de modèle ou modifiez le prompt ?
• Réexécutez-vous les évaluations avant chaque déploiement, ou seulement quand quelque chose casse ?

Un prestataire qui dispose de cette instrumentation répondra en chiffres. Un prestataire qui ne l'a pas répondra en adjectifs — « c'est vraiment solide », « on a beaucoup testé ». C'est le signal révélateur.

Ce qu'il faut mettre dans le contrat

Traitez les évaluations comme vous traiteriez la couverture de tests dans un cahier des charges logiciel classique — comme un livrable, pas comme une courtoisie :

• Taille et composition minimales du jeu d'évaluations. Pour la plupart des produits IA à fonctionnalité unique, 50 à 150 cas tirés de données réelles ou réalistes constitue un plancher raisonnable. Un bot de support doit disposer de cas issus de vrais tickets passés, pas de questions synthétiques inventées par le prestataire.
• Un seuil de réussite, défini avant le démarrage du développement. 80 % peut suffire pour un outil interne ; une fonctionnalité orientée client ou tout ce qui touche à des données de santé ou soumises à la conformité exige un seuil plus élevé et une revue humaine des échecs, pas seulement du score.
• Une obligation de réexécution. Toute montée de version de modèle, toute modification de prompt ou de logique de récupération doit déclencher le même jeu d'évaluations. Les régressions silencieuses sont la façon la plus courante dont « ça marchait en démo » devient « ça a cassé en production trois semaines après le lancement ».
• La propriété du jeu d'évaluations à la livraison. À la fin de la mission, vous devez repartir avec les cas de test et la logique de scoring — pas seulement avec la fonctionnalité livrée. Si le prestataire refuse de vous les transmettre, c'est un point à noter dès le cadrage.

Rien de tout cela n'a besoin d'alourdir le contrat. Une courte annexe — taille du jeu d'évaluations, seuil de réussite, déclencheur de réexécution, et propriétaire du harness en fin de mission — suffit à tout couvrir.

Ce que ça coûte, et pourquoi ça vaut la peine

La construction d'une suite d'évaluations initiale représente généralement environ 10 à 15 % du coût de la fonctionnalité IA elle-même : le temps passé à collecter des cas représentatifs, à rédiger la grille de notation (ou à brancher un LLM-as-judge pour les sorties ouvertes), et à intégrer le harness dans la CI pour qu'il s'exécute automatiquement. C'est un vrai poste budgétaire — et un prestataire qui propose un développement IA anormalement rapide et bon marché omet souvent cette étape discrètement.

C'est peu comparé à l'alternative. Le coût réel d'un MVP IA ne se limite pas au développement : il comprend aussi le coût de découvrir après le lancement que le système échoue sur 1 question réelle sur 5, puis de re-architechter sous pression pendant que les clients voient déjà de mauvaises réponses. Les évaluations déplacent cette découverte avant le lancement, quand elle relève d'une conversation de code review plutôt que d'un incident.

Le signal d'alarme, en une phrase

Si la réponse d'un prestataire à « montrez-moi vos évaluations » est une démo plutôt qu'un tableau de bord, il ne dispose pas d'un système testé — il dispose d'un système qu'il n'a pas encore testé, et c'est vous qui découvrirez où il casse. C'est le même instinct qui sous-tend la plupart des autres signaux d'alarme dans une mission logicielle : demandez des preuves, pas de la confiance.

Évaluer des prestataires IA n'est pas fondamentalement différent d'évaluer n'importe quel autre partenaire logiciel — vous cherchez la preuve d'une rigueur, pas seulement la preuve d'un résultat. Les évaluations sont simplement l'endroit où cette rigueur se manifeste pour le travail IA en particulier, et elles coûtent suffisamment peu cher à demander qu'un prestataire sérieux n'a aucune bonne raison de s'y opposer.

Si vous cadrez une fonctionnalité IA et souhaitez un partenaire qui construit la suite d'évaluations en parallèle de la fonctionnalité — et non après qu'une chose casse — parlons-en.