Évaluer un POC d'agent IA avant de passer à l'échelle

Une démo convaincante n'est pas une preuve

Une démo montre un agent IA sous son meilleur jour, car elle tourne sur des exemples que ses concepteurs ont choisis et répétés. Avant de passer à l'échelle, la question est différente : à quelle fréquence l'agent fait-il correctement le vrai travail, combien coûte chaque tâche, et que se passe-t-il les jours où il se trompe ?

Traitez le POC comme une expérience qui se termine par une décision : étendre, modifier ou arrêter. Cette décision exige des critères écrits avant l'arrivée des résultats ; sinon, presque n'importe quel résultat peut être lu comme prometteur.

Écrivez les critères de réussite avant de construire l'agent

Définissez le niveau suffisant pour l'activité, puis traduisez-le en chiffres mesurables. Pour un agent qui trie les demandes de support, cela peut être la part des demandes envoyées à la bonne équipe, la part qu'il refuse à juste titre de traiter et le temps qu'une personne passe à vérifier chacune.

• Le taux de réussite sur des cas réalistes, avec une définition écrite d'un résultat correct
• Les erreurs que vous pouvez tolérer et celles qui sont inacceptables, comme une mauvaise réponse envoyée à un client
• Le coût par tâche accomplie, y compris l'usage du modèle et le temps de la personne qui vérifie le travail
• Un temps de réponse adapté au processus, selon que quelqu'un attend la réponse ou non
• La référence : combien de temps la tâche prend aujourd'hui à vos équipes, et à quelle fréquence elles la réussissent

Testez sur un jeu d'évaluation fixe, construit à partir de cas réels

Rassemblez des entrées réelles tirées de votre propre historique, notez le résultat correct pour chacune et gardez le jeu figé. Incluez des cas faciles, ambigus et rares, ainsi que quelques cas que l'agent devrait refuser. Un petit jeu de cas bien choisis en dit plus qu'un grand jeu de cas faciles.

Faites tourner l'agent sur l'ensemble du jeu à chaque changement de prompt, de modèle, d'outils ou de données, et comparez avec l'exécution précédente. Les sorties d'un modèle varient d'une exécution à l'autre : lancez chaque cas plusieurs fois et regardez la constance, pas seulement la meilleure réponse. Gardez ces cas hors du prompt et des exemples que l'agent voit, sinon le score le flattera.

Vérifiez aussi votre notation. Les contrôles automatiques conviennent aux sorties structurées. Le texte libre demande généralement une personne, ou un second modèle dont vous avez comparé les jugements à ceux d'une personne sur un échantillon.

Mesurez le coût et la latence au volume attendu

Un POC qui traite quelques dizaines de demandes par jour peut masquer des coûts qui comptent à plusieurs milliers. Enregistrez les appels au modèle, les tokens et les appels d'outils par tâche, ainsi que la durée de chaque tâche. Les agents qui bouclent, réessaient ou lisent de longs documents peuvent coûter bien plus que la moyenne sur certaines entrées : étudiez les cas les plus lents et les plus chers, pas seulement la moyenne.

Projetez ensuite le coût au volume attendu et comparez-le au coût actuel du travail, en incluant le temps que vos équipes passeront encore à relire. Fixez des limites strictes par tâche sur le nombre d'étapes, les tokens et la durée, pour qu'une seule entrée problématique ne puisse pas faire exploser la facture. L'OWASP Top 10 for LLM Applications range ce risque sous le nom de consommation non maîtrisée (unbounded consumption).

Concevez la relecture humaine délibérément, puis mesurez-la

La relecture humaine fait partie de la conception ; ce n'est pas un filet de sécurité provisoire. Décidez quelles actions l'agent peut mener seul, lesquelles il peut seulement proposer et lesquelles il ne doit jamais entreprendre. Tout ce qui est irréversible ou visible des clients, comme envoyer un message, modifier un enregistrement ou dépenser de l'argent, doit attendre l'approbation d'une personne tant que l'agent n'a pas fait ses preuves sur la durée.

Mesurez la relecture elle-même : combien de temps elle prend, à quelle fréquence les relecteurs modifient le résultat et à quelle fréquence ils approuvent sans vraiment vérifier. Si relire prend presque autant de temps que faire la tâche, l'agent ne fait pas encore gagner de temps. Si votre cas d'usage peut relever des systèmes à haut risque au sens du règlement européen sur l'IA (AI Act), un contrôle humain effectif est une obligation légale au titre de l'article 14, et non une préférence de conception : impliquez tôt vos conseillers juridiques.

Fixez les limites de données et de sécurité avant de passer à l'échelle

Passer à l'échelle apporte plus de données, plus d'utilisateurs et plus d'outils, et c'est là que des limites faibles commencent à peser. L'OWASP Top 10 for LLM Applications place la prompt injection en tête : un texte que l'agent lit, comme un e-mail, un ticket ou une page web, peut contenir des instructions qui le détournent. Il cite aussi l'excès d'autonomie (excessive agency), c'est-à-dire plus de fonctions, de permissions ou d'autonomie que la tâche n'en exige. Réglez ces points avant que le pilote ne grandisse.

• Quelles données l'agent peut lire, et si des données personnelles ou confidentielles partent chez un fournisseur de modèles, avec quel contrat et quelles conditions de conservation
• Quels outils il peut appeler, avec les permissions les plus étroites et des identifiants distincts pour chaque agent
• Ce qu'il peut modifier, et si chaque modification peut être tracée et annulée
• Ce qui est journalisé : chaque appel d'outil avec ses entrées et ses sorties, sans fuite de données personnelles
• Comment les données de chaque client ou de chaque équipe restent séparées de celles des autres

Étudiez ses échecs, puis tranchez

Avant de décider, lisez les échecs, pas seulement le score. Classez-les par type : réponses fausses données avec assurance, refus justifiés, étapes oubliées, mauvais usage d'un outil, dépassements de délai. Un agent qui échoue en demandant de l'aide est bien plus facile à déployer qu'un agent qui échoue en silence avec une réponse plausible.

Puis décidez. Étendez si les critères sont atteints sur le jeu d'évaluation et si les échecs restants sont de ceux que votre processus peut absorber. Réduisez le périmètre si l'agent ne réussit bien qu'une partie de la tâche. Arrêtez s'il ne fait pas mieux que la référence, et gardez le jeu d'évaluation pour la prochaine tentative. Nos projets d'agents IA suivent la même séquence : une tâche, des exemples réels, une relecture par votre équipe, et un périmètre élargi seulement quand l'agent a gagné la confiance. Si vous avez un POC à évaluer, vous pouvez le décrire via notre formulaire Démarrer un projet.

FAQ