Scénario illustratif. Le prestataire présente l’agent de support : il répond bien à six questions et la salle applaudit. Le jalon est facturé. Trois semaines plus tard, la responsable du service client déclare que « ce n’est pas terminé » parce qu’il se perd sur les commandes retournées ; le prestataire répond que ça n’a jamais fait partie du périmètre. Aucun des deux ne ment. Personne n’a écrit ce que « terminé » voulait dire.
La thèse en une ligne : un agent IA ne se livre pas quand il fonctionne en démo, mais quand il remplit des critères d’acceptation écrits avant le début et signés par quelqu’un du métier. Sans ce papier, le projet ne se termine jamais, ou se termine par lassitude.
Que sont les critères d’acceptation d’un agent IA, et pourquoi la démo ne suffit-elle pas ?
Les critères d’acceptation d’un agent IA sont les conditions mesurables que l’agent doit remplir, sur des cas réels et pendant une période convenue, pour que le client le considère comme livré. Sur un formulaire web, « ça marche » est binaire : la donnée est enregistrée ou non. Un agent répond différemment à chaque fois et a raison dans une certaine proportion des cas ; « ça marche » est donc toujours une question incomplète : à quelle fréquence, sur quels cas, et pour quel coût quand il échoue ?
Une démo ne répond à aucune des trois, parce que c’est celui qui vend qui la choisit : les meilleurs cas, le meilleur jour (on y revient dans la démo utilisait tes meilleurs cas). Et le problème de fond n’est pas technique. L’analyse de RAND sur les raisons de l’échec des projets d’IA, fondée sur des entretiens avec des ingénieurs et des data scientists, place parmi les causes les plus courantes un problème à résoudre mal compris ou mal communiqué (RAND, 2024). Les critères d’acceptation, c’est cette conversation mise par écrit, avec une date et des noms.
Que doit contenir le document d’acceptation d’un agent ?
Six choses, et les six tiennent sur une page. Si l’une n’y tient pas, c’est qu’on ne sait pas encore ce qu’on achète.
- Des cas de test issus de ton activité, pas de celle du prestataire. Un jeu fermé de cas réels, avec les cas difficiles et les exceptions dedans, figé avant de commencer. Si le jeu change en cours de projet, les résultats ne sont plus comparables. Comment évaluer : évaluer la qualité des agents IA et evals : sans mesure, tu ne sais pas si ça marche.
- L’erreur tolérée, par type d’erreur. Pas un « 95 % de réussite » global : se tromper de ton ne coûte pas ce que coûte la promesse d’un remboursement que la politique n’autorise pas. Pourquoi la moyenne trompe : 95 % de réussite ne suffit pas en production.
- Ce qu’il fait quand il ne sait pas. Des critères d’escalade : dans quelles situations il passe la main à une personne, avec quel contexte et en combien de temps. La conception est détaillée dans ce que fait un agent quand il ne sait pas.
- Ce qu’il peut toucher, et jusqu’où. Quels systèmes il lit, lesquels il modifie et quelles actions exigent une validation humaine, selon les niveaux d’autonomie d’un agent.
- Comment on mesure, et pendant combien de temps. Une période d’essai supervisée en production réelle, avec la métrique définie d’avance. Quoi mesurer sans se raconter d’histoires : mesurer la performance de tes automatisations.
- Qui signe. Un nom et une fonction côté métier, pas un service.
Qui doit signer que l’agent est terminé ?
La personne qui subit les conséquences s’il échoue : le propriétaire du processus. Pas celui qui achète la technologie, ni celui qui la construit. Le prestataire propose les critères et démontre qu’ils sont remplis ; le métier décide s’ils lui suffisent. Si seule l’équipe technique signe, ce qu’on accepte, c’est que le système tourne, pas que le travail est bien fait.
La signature inclut le droit de refuser. Un document qu’on ne peut que signer n’est qu’une formalité. Une seconde signature est utile : celle de la personne qui maintiendra l’agent ensuite. Accepter ce que personne ne saura exploiter, c’est repousser le problème au mois suivant (voir qui maintient les agents IA une fois en production).
| Ce qu’on écrit avant de commencer | Ce qui se passe si on ne l’écrit pas | Qui le définit |
|---|---|---|
| Un jeu de cas réels | Le prestataire teste avec ce qu’il sait qui marche | Le métier fournit, le prestataire aide à combler les trous |
| L’erreur tolérée par type | Une jolie moyenne cache l’erreur coûteuse | Le métier, selon ce que coûte chaque échec |
| Quand il escalade vers une personne | L’agent improvise exactement là où il ne devrait pas | Métier et prestataire, ensemble |
| Permissions et actions soumises à validation | On découvre le vrai périmètre le jour de l’incident | Métier et responsable sécurité |
| Période d’essai et métrique | « Terminé » se mesure au ressenti | Le métier, avec le prestataire comme conseil |
| Signature | Le projet ne se termine pas, ou par lassitude | Une fonction métier, avec un nom |
Que se passe-t-il quand il n’y a pas de critères d’acceptation ?
Il y a deux fins possibles, et aucune n’est bonne. Dans la première, le projet ne se termine jamais : chaque nouvelle demande est vécue comme un échec de l’agent, le prestataire voit le périmètre grossir sans limite et le client a l’impression de payer pour réparer ce qu’il a déjà acheté. Dans la seconde, il se termine par lassitude : on le déclare bon parce que personne ne supporte une réunion de plus, et l’agent part en production sans que personne connaisse son vrai taux d’erreur.
La seconde fin est pire, parce qu’elle ressemble à un succès. C’est la version contractuelle de ce qu’on explique dans pourquoi les projets d’automatisation par l’IA échouent : le projet n’échoue pas pendant la démo, il échoue dans le vide entre ce que chacun tenait pour acquis.
Comment rédiger un critère que l’on peut vraiment vérifier ?
Avec trois ingrédients : un jeu de cas, un seuil et une condition d’échec non négociable. Un exemple de rédaction (les chiffres sont illustratifs ; les tiens, tu les fixes selon ce que te coûte chaque erreur) :
Remarque l’asymétrie : le seuil se négocie, la condition d’échec non. Certaines erreurs sont tolérées dans une certaine proportion, d’autres pas du tout. L’écrire évite la discussion la plus coûteuse du projet, celle qui survient quand l’échec est déjà arrivé chez un client.
Quand un document d’acceptation formel n’est-il pas nécessaire ?
Quand c’est un prototype déclaré comme tel, une expérimentation interne sans clients ni données personnelles, ou un cas où se tromper coûte peu et se rattrape. Là, une phrase et une date suffisent : « ceci est un essai, revu le jour X ». Dès que l’agent touche des clients, de l’argent ou des données personnelles, la page s’écrit.
Si tu as déjà un agent en service et que personne ne se souvient de ce qui a été accepté, c’est maintenant qu’il faut écrire le document, avant la prochaine extension. Et si tu t’apprêtes à en engager un, évaluer la qualité des agents IA est le travail qui transforme cette page en un jeu de cas et un seuil exécutables.
La phrase à retenir : un agent n’est pas terminé quand il impressionne, mais quand quelqu’un du métier, avec un nom et une fonction, signe qu’il remplit ce qui a été écrit avant de commencer.
Sources (consultées le 27 octobre 2026) : « The Root Causes of Failure for Artificial Intelligence Projects and How They Can Succeed », RAND Corporation (2024). Le scénario d’ouverture et les chiffres de l’exemple sont illustratifs, pas un cas réel.