Ajouter des métriques n’améliore pas nécessairement la compréhension. De nombreux tableaux de bord comportent plusieurs mesures d’un même comportement sous-jacent. Les métriques deviennent plus diagnostiques lorsqu’elles sont associées en paires mutuellement destructrices : coût et qualité, confinement et sentiment, ou précision et latence.
Les bonnes paires évoluent à mesure qu’un produit d’IA passe du pilote à la production. La mesure doit suivre les décisions que l’équipe doit prendre à chaque étape.
Le suivi opérationnel et la mesure stratégique répondent à des objectifs différents. Les équipes peuvent suivre des centaines de signaux système tout en n’utilisant que quelques paires pour guider les décisions produit.
Les indicateurs phares peuvent raconter une histoire convaincante tout en laissant une décision produit importante sans réponse.
L’assistant d’IA de Klarna a été publiquement associé à un débit supérieur, à des coûts moindres et à des scores de satisfaction client comparables à ceux des agents humains. L’année suivante, l’entreprise a décidé d’élargir l’accès à l’assistance humaine, son directeur général reconnaissant qu’une importance excessive avait été accordée à la réduction des coûts.
Il ne s’agissait pas d’un rejet de l’assistant d’IA ni de sa technologie sous-jacente. Il s’agissait de rééquilibrer l’automatisation et le service humain à mesure que l’entreprise tirait les enseignements de l’exploitation du produit. À mesure que l’automatisation prenait en charge davantage de requêtes simples et fréquentes, les agents humains dont Klarna avait besoin étaient ceux capables de traiter des cas complexes et sensibles.
Après avoir défini dès le départ ce qu’un produit doit accomplir, la plupart des organisations qui développent des produits d’IA finiront par se poser la même question : fonctionne-t-il réellement ?
Lorsque la réponse n’est pas claire, le réflexe consiste souvent à ajouter des métriques. Trois deviennent 10, puis 10 deviennent 30. Le tableau de bord s’enrichit, mais la compréhension de l’équipe ne s’améliore pas forcément.
Le problème ne tient pas toujours à la qualité des mesures individuelles, mais à leur relation. La satisfaction client, le Net Promoter Score, les avis et les taux d’appréciation peuvent tous fournir des signaux utiles, mais refléter des évolutions similaires du sentiment général. Lorsqu’ils évoluent ensemble, ils confirment qu’un événement s’est produit sans nécessairement en expliquer la raison.
Les équipes d’IA doivent donc aller au-delà des métriques concordantes et identifier les mesures qui révèlent des résultats concurrents. Ces paires mutuellement destructrices révèlent et aident à suivre l’impact des compromis qui sous-tendent les performances du produit, afin de prendre de meilleures décisions.
Dans le cadre d’un déploiement avant lancement, l’équipe conjointe développait un agent vocal d’IA en temps réel pour les appels entrants au service client. L’une des questions les plus difficiles ne concernait ni le choix du modèle ni l’orchestration. Il s’agissait de savoir comment l’organisation déterminerait si le produit fonctionnait une fois utilisé à grande échelle par les clients.
Le cadre initial reposait sur trois mesures :
Taux de confinement : fréquence à laquelle l’IA résout un appel sans le transférer à une personne.
Taux d’escalade : fréquence à laquelle un appel est transféré à un agent humain.
Taux de résolution : fréquence à laquelle le problème du client est finalement résolu.
Chaque mesure était pertinente. Ensemble, toutefois, elles ne permettaient pas de répondre à une question évidente : si l’escalade augmente, qu’est-ce que cela nous apprend ?
L’équipe a décomposé l’escalade en huit sous-types. Elle a ensuite ajouté des mesures d’abandon, de parcours et de durée, des scores de compréhension linguistique et le taux de résolution par type de requête. Le cadre a fini par comporter 31 métriques réparties en six catégories.
Il pouvait décrire l’escalade en détail, mais n’en diagnostiquait toujours pas la cause de manière fiable. La plupart des métriques étaient des variations du même comportement : elles évoluaient donc ensemble au lieu de tester des explications concurrentes.
Le tableau de bord était devenu descriptif plutôt que diagnostique.
L’équipe n’avait pas besoin d’un niveau de décomposition supplémentaire. Elle avait besoin de métriques qui se contraignent mutuellement.
Nous les appelons paires mutuellement destructrices : deux mesures pour lesquelles l’amélioration isolée de l’une peut nuire au résultat représenté par l’autre. Ce nom décrit le mode d’échec créé par une optimisation unilatérale, et non l’état recherché.
Lorsque les deux dimensions restent saines, le produit peut fonctionner durablement. Lorsqu’elles divergent, le sens de cette divergence aide l’équipe à déterminer où enquêter.
Ce que nous avions | Paire mutuellement destructrice | Ce que la paire peut révéler |
|---|---|---|
Taux d’escalade divisé en huit sous-types | Taux d’escalade ↔ délai avant escalade | Une escalade immédiate peut révéler un problème de confiance ou de cadrage ; une escalade tardive peut indiquer que le système ne peut pas accomplir la tâche. |
Taux de confinement et taux de résolution présentés séparément | Taux de confinement ↔ sentiment du client | Si le confinement correspond à une résolution satisfaisante ou à l’abandon de la tentative par le client. |
Taux de résolution par type d’intention | Taux de résolution ↔ profondeur de la conversation | Si la résolution réussie est efficace ou exige une interaction épuisante. |
Pour approfondir la manière dont cela se manifeste et exploiter cet enseignement, examinons le taux d’escalade et le délai avant escalade. L’équipe ne saura pas comment les clients se comportent avant de recevoir de vrais appels, mais elle peut définir les hypothèses à tester.
Si davantage d’appels commencent à être transférés et que les clients quittent l’expérience d’IA dans les 30 premières secondes, l’équipe doit examiner la confiance, la transparence, le ton et les interactions initiales. Si les clients demandent une escalade après plusieurs minutes consacrées à une tâche, le problème vient plus probablement des capacités ou de la couverture du workflow.
Le taux d’escalade global est le même. La décision produit est différente.
Une paire utile ne prouve pas à elle seule la cause. Elle circonscrit l’investigation et clarifie la prochaine décision.
L’exemple de Klarna présenté plus haut montre comment ce principe s’applique lorsque le coût et la qualité du service interagissent. Il montre comment un modèle opérationnel fondé sur l’IA peut évoluer à mesure qu’une entreprise suit l’impact des compromis et tire les enseignements de son déploiement.
En février 2024, l’entreprise a indiqué que son assistant d’IA avait traité 2,3 millions de conversations au cours de son premier mois, accompli un travail équivalent à celui de 700 agents à temps plein et obtenu des scores de satisfaction client comparables à ceux des agents humains. Klarna estimait que l’assistant contribuerait à une hausse des bénéfices de 40 millions de dollars en 2024. Il s’agissait de résultats déclarés par Klarna, et non d’une évaluation indépendante.
En mai 2025, le directeur général de Klarna a déclaré que l’entreprise avait trop privilégié la réduction des coûts du service client et a présenté des projets visant à élargir l’accès à l’assistance humaine. Cela constituait un ajustement de l’équilibre entre service automatisé et humain, plutôt qu’un rejet de l’assistant d’IA ou de sa technologie sous-jacente.
Les informations publiques montrent pourquoi les mesures d’efficacité doivent être examinées au regard des besoins des différents clients et types d’interactions. Un système d’IA peut obtenir de bons résultats en moyenne, tandis que certains cas complexes, sensibles ou inhabituels bénéficient toujours d’un canal humain accessible.
Le suivi des deux dimensions de cette relation aide une entreprise à déterminer où l’automatisation crée de la valeur, où l’assistance humaine reste importante et comment ajuster l’équilibre à mesure que de nouvelles données apparaissent.
D’autres paires mutuellement destructrices applicables aux produits d’IA peuvent inclure :
Paire mutuellement destructrice | Risque qu’elle aide à révéler |
|---|---|
Précision des réponses ↔ latence des réponses | Un système techniquement précis, mais trop lent pour le workflow. |
Exécution des tâches ↔ taux de remplacement par l’utilisateur | Un workflow d’IA qui exécute des tâches que les utilisateurs refont systématiquement. |
Coût par interaction ↔ qualité évaluée des résultats | Des économies obtenues au détriment de l’expérience client ou collaborateur. |
Adoption ↔ délai de création de valeur | Une hausse des inscriptions sans valeur correspondante pour les utilisateurs. |
L’objectif n’est pas de faire augmenter indéfiniment les deux mesures. Il s’agit de rendre le compromis visible avant qu’une optimisation unilatérale ne crée un problème opérationnel.
Un défi connexe est apparu lors du déploiement d’un service d’assistance aux joueurs pour une entreprise de jeux mobiles. Le système traitait des problèmes à fort volume, tels que la perte de progression, les litiges de paiement et l’accès aux comptes.
Les mesures d’efficacité étaient importantes, car le système fonctionnait à grande échelle. Mais l’assistance aux joueurs n’est pas une simple file d’attente opérationnelle. Les joueurs arrivent souvent frustrés, car un problème s’est déjà produit ailleurs dans leur expérience.
Cette situation initiale change la manière d’interpréter les données de satisfaction client. Un joueur dont le problème est correctement résolu peut tout de même déclarer une faible satisfaction parce qu’il a perdu sa progression au départ. Interpréter ce score sans contexte peut pénaliser l’interaction d’assistance pour une frustration apparue plus tôt dans le parcours client.
L’équipe devait donc distinguer le sentiment initial du client de l’effet de l’expérience d’assistance. La question la plus utile n’était pas : « Le joueur était-il satisfait ? » Il s’agissait plutôt de demander : « L’interaction a-t-elle amélioré la situation par rapport au point de départ du joueur ? »
Cette comparaison peut aider à distinguer la frustration liée au produit de la qualité de l’assistance, à condition que l’équipe dispose d’une méthode fiable pour mesurer les deux.
Les produits d’IA évoluent, mais leurs métriques restent souvent figées.
Pendant un pilote, la question centrale peut être de savoir si le système est suffisamment fiable pour justifier la poursuite des investissements :
Exécute-t-il la tâche principale de manière fiable ?
Les utilisateurs lui font-ils assez confiance pour continuer ?
Comment se comporte-t-il hors des scénarios les plus courants ?
Peut-on identifier les défaillances et les corriger en toute sécurité ?
Ces questions favorisent des paires telles que :
réussite de la tâche principale ↔ performances dans les cas limites ;
taux d’automatisation ↔ taux de remplacement par un humain ; et
vitesse d’exécution ↔ confiance des utilisateurs.
Une fois le produit devenu important sur le plan opérationnel, les questions changent :
Peut-il passer à l’échelle sans réduire la qualité ?
Sa rentabilité s’améliore-t-elle avec l’utilisation ?
Les performances restent-elles stables à mesure que l’adoption progresse ?
Les interventions humaines ont-elles lieu aux bons endroits ?
Les paires correspondantes peuvent alors devenir :
coût par interaction ↔ qualité évaluée des résultats ;
étendue de l’adoption ↔ profondeur d’utilisation ; et
taux d’automatisation ↔ exposition au risque opérationnel.
Les premières métriques ne sont pas nécessairement erronées. Elles répondent aux questions qui comptaient à une étape antérieure.
Le risque survient pendant la transition. Les métriques du pilote persistent souvent parce que les équipes savent les présenter et que personne n’est chargé de décider de leur retrait. Les mesures qui favorisaient autrefois l’apprentissage peuvent progressivement devenir des métriques de vanité.
Les paires doivent donc avoir un cycle de vie. Les équipes doivent les introduire pour une décision définie, vérifier qu’elles révèlent toujours un compromis important et les retirer lorsque le produit ou la décision change.
Les systèmes d’IA exigent une observabilité détaillée, des alertes, une assurance qualité et des évaluations. Supprimer ces signaux rendrait plus difficile l’exploitation sûre du produit. Mais le suivi opérationnel n’est pas la même chose que la mesure destinée à la direction.
Le suivi aide les équipes à détecter les incidents, à retracer les défaillances et à comprendre le comportement du système. Les métriques décisionnelles aident les responsables produit et métier à décider d’investir, d’intervenir, de changer de direction ou d’accepter un compromis.
Une organisation peut suivre des centaines de signaux techniques et opérationnels tout en ne mettant en avant que deux ou trois paires mutuellement destructrices pour une décision produit donnée. Limiter ce niveau décisionnel facilite la hiérarchisation des priorités.
La fréquence d’examen appropriée dépend du produit. Un système nouveau ou évoluant rapidement peut nécessiter des revues décisionnelles hebdomadaires, tandis qu’un produit mature peut se satisfaire d’un rythme mensuel ou trimestriel. Le principe compte davantage que l’intervalle : examinez la paire assez souvent pour agir avant que le compromis ne devienne coûteux ou dangereux.
Une paire ne devient utile que lorsque l’organisation convient de ce qui se passera si elle se dégrade.
Cela exige plus que de définir une limite critique de divergence. Les équipes doivent envisager trois situations :
Échec absolu : une mesure franchit un seuil inacceptable, indépendamment de l’autre.
Divergence : une mesure s’améliore tandis que son contrepoids se dégrade.
Dégradation conjointe : les deux dimensions reculent, ce qui suggère un problème plus général lié au produit ou à son exploitation.
Chaque paire doit avoir :
un responsable désigné ;
une décision claire qu’elle étaye ;
des seuils ou critères d’évaluation convenus ;
une procédure d’investigation ; et
un ensemble d’interventions possibles.
Sans ces éléments, l’organisation observe le produit au lieu de le gérer.
Avant d’ajouter une mesure, choisissez une décision produit importante et examinez les questions suivantes. Notez les réponses afin que la revue débouche sur une prochaine étape convenue.
1. Quelle décision ces métriques doivent-elles nous aider à prendre ?
Soyez précis : devons-nous décider d’étendre l’automatisation, de changer de modèle ou d’améliorer le transfert vers un humain ? Nommez la décision avant de choisir les mesures.
2. Si ce chiffre s’améliore, qu’est-ce qui pourrait empirer ?
Identifiez le résultat à protéger et une mesure qui révélerait un préjudice. Par exemple, associez le coût par interaction à la qualité évaluée des résultats pour vérifier si les réponses moins coûteuses restent utiles.
3. Que pourraient masquer les chiffres clés ?
Analysez les deux mesures pour les mêmes utilisateurs, tâches et périodes, puis recherchez les groupes qui obtiennent de moins bons résultats. Tenez également compte de la situation initiale : une faible satisfaction peut refléter une frustration antérieure à l’interaction avec l’assistance.
4. Qu’est-ce qui nous ferait agir, et qui est responsable de la réponse ?
Définissez des critères d’action lorsqu’une mesure franchit une limite inacceptable, que l’une s’améliore tandis que l’autre se dégrade, ou que les deux reculent. Convenez de la personne qui enquêtera, de ce qu’elle vérifiera en premier et de la date à laquelle elle rendra compte.
5. Cette paire correspond-elle toujours au stade actuel du produit ?
Décidez de la conserver, de la remplacer ou de la retirer. Un pilote peut se concentrer sur la fiabilité des tâches et la confiance des utilisateurs ; un service en production peut exiger un examen plus poussé du coût et de la qualité. Fixez une date pour réexaminer ce choix.
La mesure des produits d’IA doit aller au-delà de la description des performances. Elle doit révéler les compromis consentis par l’organisation et clarifier la prochaine décision.