Mesurer le succès d'un projet IA : les bons indicateurs

Un projet d’intelligence artificielle n’est pas un projet comme les autres, et pourtant la plupart des équipes le pilotent avec les outils d’avant. On lance un assistant, un agent, une automatisation, puis on attend de voir si « ça marche ». Le problème est que « ça marche » ne veut rien dire tant qu’on n’a pas décidé, à l’avance, ce qu’on allait regarder pour le savoir.

Le réflexe le plus courant consiste à mesurer des choses faciles à mesurer : le nombre de requêtes traitées, le taux de disponibilité du service, le temps de réponse moyen. Ces chiffres disent quelque chose de l’état technique du système, mais presque rien de sa valeur pour l’entreprise. Un agent peut traiter dix mille requêtes par jour sans jamais résoudre le problème qu’il était censé résoudre.

Voici une façon de choisir les indicateurs avant d’investir, en distinguant le technique, le métier et le financier, applicable à un projet en cours comme à venir.

Séparer la métrique technique de la métrique métier

La première confusion, et la plus coûteuse, est de croire qu’une bonne métrique technique est une preuve de valeur. Une précision de 92 %, un temps de réponse de 300 millisecondes, un système qui ne tombe jamais : tout cela est nécessaire, rien de cela ne prouve que le projet rapporte ou économise quoi que ce soit.

Une métrique technique se constate, une métrique métier se décide. La première se lit dans les logs, la seconde se lit dans les outils de l’entreprise (Zendesk, HubSpot, Salesforce, l’ERP) : un délai de traitement raccourci, un coût par dossier abaissé, un taux de réponse client maintenu avec moins de personnes. Le travail consiste à relier les deux par une chaîne de causalité vérifiable. Si le temps de réponse du modèle baisse mais que le délai de clôture d’un dossier ne bouge pas, le gain technique n’a pas de valeur métier.

Concrètement, pour chaque indicateur technique que vous suivez, posez la question : « si ce chiffre s’améliore, quelle décision ou quel résultat d’activité s’améliore avec lui ? ». Si vous ne trouvez pas de réponse, ce n’est pas forcément une mauvaise métrique, mais ce n’est pas une preuve de valeur.

Le temps récupéré, l’indicateur le plus simple et le plus piégeux

Beaucoup de projets se vendent sur le temps gagné. C’est un indicateur séduisant parce qu’il est facile à calculer : on mesure combien de temps une tâche prenait avant, combien elle prend après, et on soustrait. La réalité est moins simple.

Le piège principal est la réaffectation. Si un collaborateur passe de trois heures à trente minutes sur une tâche, le gain n’existe économiquement que si les deux heures trente libérées servent à autre chose de productif. Quand ce temps redevient de la marge, des pauses, ou du travail non valorisé, l’entreprise n’a rien gagné. Mesurer le temps récupéré exige donc de mesurer aussi ce qui en est fait.

Le second piège est l’unité de compte. Compter en heures est plus fiable que compter en pourcentage, car un pourcentage ne dit pas sur quelle base il s’applique. « Gain de 40 % sur une tâche » ne veut rien dire si la tâche représente deux heures par semaine sur un poste. Raisonnez en heures par mois et par poste, et ramenez le tout à un coût.

La qualité de sortie mesurée sur les vrais cas

Pour les systèmes qui produisent du contenu, des réponses ou des décisions, la qualité ne se décrète pas, elle se mesure sur des échantillons réels. Le bon outil est un jeu d’évaluation : un lot de cas représentatifs, annotés par des humains, sur lesquels on teste le système régulièrement, avec des outils comme Promptfoo, DeepEval ou Ragas pour un RAG (on détaille la mécanique dans notre article sur les evals d’un agent IA).

Ce jeu d’évaluation doit être construit à partir de ce que le système rencontre vraiment en production, pas à partir de cas idéaux préparés pour la démonstration. Si votre assistant traite des réclamations clients, vos cas d’évaluation doivent contenir des réclamations ambiguës, incomplètes, mal orthographiées. C’est sur ces cas que la qualité moyenne se joue.

La mesure la plus utile n’est pas le score global, mais le taux d’échec par type de cas. Vous découvrirez souvent que le système est excellent sur 80 % des cas et médiocre sur 20 % précis. Savoir cela vaut mieux qu’un score moyen flatteur, parce que cela vous dit où investir : entraîner sur les cas faibles, ou décider de ne pas automatiser ces cas et de les garder en traitement humain.

Le coût réel par tâche traitée

Un projet IA a un coût d’infrastructure et d’appels de modèle qui se répète à chaque utilisation, contrairement à un logiciel classique dont le coût marginal est quasi nul. Cet aspect est trop souvent ignoré au moment de la démonstration, quand tout tourne sur un compte d’essai.

Il faut calculer un coût complet par tâche traitée : appels de modèle, stockage, traitement, et le temps humain de supervision et de correction. Pour la partie machine, un outil d’observabilité LLM comme Langfuse ou LangSmith donne le coût par exécution sans calcul manuel. Ce coût doit ensuite être comparé au coût de la tâche faite à la main. Si traiter une facture coûte 2,40 euros en main-d’œuvre et 2,30 euros en machine une fois la supervision comptée, le projet n’a de sens que s’il apporte autre chose : de la vitesse, de la constance, de la capacité à absorber les pics. Pour aller jusqu’au bout du raisonnement financier, voyez comment calculer le ROI d’un agent IA.

Ce calcul doit être refait à intervalles réguliers, parce que les modèles changent de prix et que les usages dérivent. Un projet rentable au lancement peut cesser de l’être si le volume explose sans que la valeur par tâche suive.

Ce qu’il faut suivre en continu, et ce qu’il faut arrêter de regarder

En régime de croisière, il faut un tableau de bord court, pas un inventaire. On recommande quatre catégories : la valeur métier, la qualité mesurée sur le jeu d’évaluation, le coût par tâche, et la disponibilité. Un tableau de bord Metabase ou Looker Studio suffit à les rassembler. C’est d’ailleurs le socle de notre méthode de mise en production : evals, suivi des coûts et garde-fous dès le premier jour.

Tout le reste est du bruit tant que ces quatre-là tiennent. Les métriques de vanité, comme le nombre total de requêtes ou le nombre d’utilisateurs qui ont « essayé » l’outil, doivent être regardées avec méfiance : elles montent souvent sans que la valeur suive.

L’essentiel est de choisir les indicateurs avant de lancer, de les documenter, et de s’y tenir. Les bons indicateurs ne sont pas ceux qui font bien paraître le projet, ce sont ceux qui permettent de décider.

Par où commencer pour choisir et suivre vos indicateurs

Choisir les bons indicateurs demande une double compétence : comprendre le métier qui doit être amélioré, et connaître la réalité technique de ce qui est mesurable. Sur nos projets, on fixe ces indicateurs avant d’écrire la première ligne de code, et la mesure fait partie du livrable : jeu d’évaluation, suivi du coût par tâche, tableau de bord lisible par ceux qui décident.

Si vous voulez savoir ce que coûte un projet cadré de cette façon, et à partir de quel volume il devient rentable, nos tarifs détaillent les formats possibles, du cadrage, offert, à l’agent en production. Vous saurez ainsi, chiffres à l’appui, si le projet mérite d’être lancé, poursuivi ou arrêté.