Ajouter des indicateurs n’améliore pas nécessairement la compréhension. De nombreux tableaux de bord contiennent plusieurs mesures du même comportement sous-jacent. Les indicateurs deviennent plus révélateurs lorsqu’ils sont combinés en paires mutuellement destructrices : coût et qualité, confinement et sentiment, ou exactitude et latence.
Les bonnes paires changent à mesure qu’un produit d’IA passe du projet pilote à la production. La mesure devrait suivre les décisions que l’équipe doit prendre à chaque étape.
La surveillance opérationnelle et la mesure stratégique servent des objectifs différents. Les équipes peuvent suivre des centaines de signaux système tout en n’utilisant que quelques paires pour orienter les décisions sur le produit.
Les indicateurs phares peuvent raconter une histoire convaincante tout en laissant une importante décision sur le produit en suspens.
L’assistant d’IA de Klarna a été publiquement associé à un débit accru, à des coûts réduits et à des scores de satisfaction comparables à ceux des agents humains. L’année suivante, l’entreprise a décidé d’accroître l’accès au soutien humain, son chef de la direction reconnaissant qu’on avait trop insisté sur la réduction des coûts.
Il ne s’agissait pas de rejeter l’assistant d’IA ni la technologie qui le sous-tend. Il s’agissait plutôt de rééquilibrer l’automatisation et le service assuré par des agents humains à mesure que l’entreprise tirait des enseignements de l’utilisation du produit. À mesure que l’automatisation prenait en charge un volume croissant de demandes simples, Klarna avait surtout besoin d’agents humains capables de traiter les 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 créent des produits d’IA finiront par se poser la même question : fonctionne-t-il vraiment?
Si la réponse est incertaine, le réflexe consiste souvent à ajouter des indicateurs. 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é de chaque mesure, mais à leur relation. La satisfaction de la clientèle, le Net Promoter Score, les évaluations et le taux de mentions « J’aime » peuvent tous fournir des signaux utiles, mais refléter des changements semblables du sentiment général. Lorsqu’ils évoluent ensemble, ils confirment qu’un événement s’est produit sans nécessairement expliquer pourquoi.
Les équipes d’IA devraient donc aller au-delà des indicateurs qui concordent et repérer les mesures qui révèlent des résultats opposés. Ces paires mutuellement destructrices révèlent les compromis qui influencent le rendement du produit et aident à en surveiller les effets pour mieux décider.
Dans un déploiement avant lancement, l’équipe conjointe développait un agent vocal d’IA en temps réel pour les appels entrants au soutien à la clientèle. 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 lorsque la clientèle commencerait à l’utiliser à grande échelle.
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 raisonnable. 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 temps, des scores de compréhension du langage et la résolution par type de requête. Le cadre a fini par comprendre 31 indicateurs répartis en six catégories.
Il pouvait décrire l’escalade en détail, mais toujours pas en diagnostiquer la cause de façon fiable. La plupart des indicateurs étaient des variantes du même comportement; ils évoluaient donc ensemble au lieu de tester des explications opposées.
Le tableau de bord était devenu observationnel plutôt que diagnostique.
L’équipe n’avait pas besoin d’une nouvelle couche de décomposition. Elle avait besoin d’indicateurs qui se limitaient mutuellement.
Nous les appelons des paires mutuellement destructrices : deux mesures où l’amélioration isolée de l’une peut nuire au résultat représenté par l’autre. Le nom décrit le mode de défaillance créé par une optimisation unilatérale, et non l’état souhaité.
Lorsque les deux côtés demeurent sains, le produit peut fonctionner de façon durable. Lorsqu’ils 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 l’escalade | Une escalade immédiate peut signaler un problème de confiance ou de présentation; 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 de la clientèle | 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 une résolution réussie est efficace ou exige une interaction épuisante. |
Pour approfondir la façon dont cela se manifeste et l’utilisation de cette information, examinons le taux d’escalade et le délai avant l’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 à vérifier.
Si davantage d’appels sont escaladés et que les clients quittent l’expérience d’IA dans les 30 premières secondes, l’équipe devrait examiner la confiance, la divulgation, le ton et les premières interactions. Si les clients demandent une escalade après avoir tenté une tâche pendant plusieurs minutes, le problème est plus probablement lié aux capacités ou à la couverture du flux de travail.
Le chiffre phare de l’escalade est le même. La décision sur le produit est différente.
Une paire utile ne prouve pas à elle seule la cause. Elle circonscrit l’enquête et clarifie la prochaine décision.
L’exemple de Klarna présenté plus tôt montre comment ce principe s’applique lorsque le coût et la qualité du service interagissent. Il montre comment un modèle opérationnel reposant sur l’IA peut évoluer lorsqu’une entreprise surveille les effets des compromis et tire des leçons de son déploiement.
En février 2024, l’entreprise a déclaré que son assistant d’IA avait traité 2,3 millions de conversations durant son premier mois, effectué l’équivalent du travail de 700 agents à temps plein et obtenu des scores de satisfaction comparables à ceux des agents humains. Klarna estimait que l’assistant contribuerait à améliorer ses bénéfices de 40 millions de dollars en 2024. Il s’agissait des résultats déclarés par Klarna, et non d’une évaluation indépendante.
En mai 2025, le chef de la direction de Klarna a déclaré que l’entreprise avait trop insisté sur la réduction des coûts du service à la clientèle et décrit ses projets visant à accroître l’accès au soutien humain. Cela représentait un ajustement de l’équilibre entre le service automatisé et humain, plutôt qu’un rejet de l’assistant d’IA ou de sa technologie sous-jacente.
Les données publiques illustrent pourquoi les mesures d’efficacité devraient être considérées en parallèle avec les besoins des différents clients et types d’interactions. Un système d’IA peut afficher un bon rendement moyen, même si certains cas complexes, délicats ou inhabituels bénéficient encore d’un canal humain accessible.
Surveiller les deux côtés de cette relation aide une entreprise à déterminer où l’automatisation crée de la valeur, où le soutien humain demeure important et comment ajuster l’équilibre à mesure que de nouvelles données apparaissent.
Voici d’autres paires mutuellement destructrices possibles pour les produits d’IA :
Paire mutuellement destructrice | Risque qu’elle aide à révéler |
|---|---|
Exactitude de la réponse ↔ latence de la réponse | Un système techniquement exact, mais trop lent pour le flux de travail. |
Accomplissement de la tâche ↔ taux de contournement par l’utilisateur | Un flux de travail d’IA qui accomplit des tâches que les utilisateurs refont constamment. |
Coût par interaction ↔ qualité évaluée du résultat | Des économies réalisées au détriment de l’expérience de la clientèle ou du personnel. |
Adoption ↔ délai de rentabilisation | Une hausse des inscriptions sans valeur correspondante pour les utilisateurs. |
L’objectif n’est pas de faire augmenter indéfiniment les deux mesures. Il consiste à rendre le compromis visible avant qu’une optimisation unilatérale crée un problème opérationnel.
Un défi connexe est apparu lors du déploiement d’un service de soutien aux joueurs pour une entreprise de jeux mobiles. Le système traitait des problèmes fréquents comme la perte de progression, les contestations de paiement et l’accès aux comptes.
Les mesures d’efficacité importaient parce que le système fonctionnait à grande échelle. Mais le soutien aux joueurs n’est pas qu’une simple file d’attente opérationnelle. Les joueurs arrivent souvent frustrés parce qu’un problème est déjà survenu ailleurs dans leur expérience.
Cette situation initiale change la façon d’interpréter les données sur la satisfaction de la clientèle. Un joueur dont le problème est correctement résolu peut tout de même signaler une faible satisfaction parce qu’il a d’abord perdu sa progression. Interpréter ce score hors contexte peut pénaliser l’interaction de soutien pour une frustration créée plus tôt dans le parcours client.
L’équipe devait donc distinguer le sentiment initial du client de l’effet de l’expérience de soutien. La question la plus utile n’était pas « Le joueur était-il satisfait? » C’était plutôt « 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é du soutien, à condition que l’équipe puisse mesurer les deux de façon fiable.
Les produits d’IA changent, mais leurs indicateurs demeurent souvent fixes.
Pendant un projet pilote, la question centrale peut être de savoir si le système est assez digne de confiance pour justifier la poursuite des investissements :
Accomplit-il la tâche principale de façon fiable?
Les utilisateurs lui font-ils assez confiance pour continuer?
Comment se comporte-t-il hors des scénarios les plus courants?
Peut-on repérer les défaillances et rétablir la situation de façon sécuritaire?
Ces questions favorisent des paires comme :
réussite de la tâche principale ↔ rendement dans les cas limites;
taux d’automatisation ↔ taux d’intervention humaine; et
vitesse d’exécution ↔ confiance de l’utilisateur.
Lorsque le produit devient 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?
Le rendement demeure-t-il stable à mesure que l’adoption augmente?
Les interventions humaines ont-elles lieu aux bons endroits?
Les paires correspondantes peuvent alors devenir :
coût par interaction ↔ qualité évaluée du résultat;
étendue de l’adoption ↔ profondeur de l’utilisation; et
taux d’automatisation ↔ exposition aux risques opérationnels.
Les premiers indicateurs ne sont pas nécessairement erronés. Ils répondent aux questions qui importaient à une étape antérieure.
Le risque apparaît pendant la transition. Les indicateurs du projet pilote persistent souvent parce que les équipes savent les présenter et que personne n’est responsable de décider de les retirer. Les mesures qui favorisaient autrefois l’apprentissage peuvent peu à peu devenir des indicateurs de vanité.
Les paires devraient donc avoir un cycle de vie. Les équipes devraient les adopter pour une décision précise, vérifier si 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é, des alertes, une assurance qualité et une évaluation détaillées. La suppression de ces signaux rendrait l’exploitation sécuritaire du produit plus difficile. Mais la surveillance opérationnelle diffère de la mesure destinée à la direction.
La surveillance aide les équipes à détecter les incidents, à retracer les défaillances et à comprendre le comportement du système. Les indicateurs décisionnels aident les responsables du produit et de l’entreprise à décider s’il faut investir, intervenir, changer de cap ou accepter un compromis.
Une organisation peut surveiller des centaines de signaux techniques et opérationnels, tout en ne retenant que deux ou trois paires mutuellement destructrices pour une décision donnée sur le produit. Une couche décisionnelle restreinte facilite l’établissement des priorités.
La fréquence de révision appropriée dépend du produit. Un système nouveau ou en évolution rapide peut exiger des examens décisionnels hebdomadaires, tandis qu’un produit mature peut se prêter à un rythme mensuel ou trimestriel. Le principe importe plus que l’intervalle : examinez la paire assez souvent pour agir avant que le compromis devienne coûteux ou dangereux.
Une paire ne devient utile que lorsque l’organisation convient de ce qui arrivera si elle se détériore.
Cela exige davantage que de fixer une limite critique de divergence. Les équipes devraient 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étériore.
Détérioration conjointe : les deux côtés reculent, ce qui laisse entrevoir un problème plus général lié au produit ou à l’exploitation.
Chaque paire devrait avoir :
un responsable désigné;
une décision claire qu’elle appuie;
des seuils ou des critères d’évaluation convenus;
une démarche d’enquête; et
un ensemble d’interventions possibles.
Sans ces éléments, l’organisation observe le produit plutôt qu’elle ne le gère.
Avant d’ajouter une autre mesure, choisissez une décision importante sur le produit et répondez à ces questions. Notez les réponses afin que l’examen se termine par une prochaine étape convenue.
1. Quelle décision ces indicateurs doivent-ils nous aider à prendre?
Soyez précis : décidons-nous d’étendre l’automatisation, de changer de modèle ou d’améliorer le transfert à un humain? Nommez la décision avant de choisir les mesures.
2. Si ce chiffre s’améliore, qu’est-ce qui pourrait empirer?
Déterminez le résultat à protéger et une mesure qui révélerait les effets négatifs. Par exemple, jumelez le coût par interaction à la qualité évaluée du résultat afin de vérifier si les réponses moins coûteuses demeurent utiles.
3. Que pourraient cacher les chiffres phares?
Analysez les deux mesures pour les mêmes utilisateurs, tâches et périodes, puis cherchez les groupes qui obtiennent de moins bons résultats. Tenez aussi compte de la situation initiale : une faible satisfaction peut refléter une frustration antérieure à l’interaction de soutien.
4. Qu’est-ce qui nous inciterait à agir, et qui est responsable de la réponse?
Fixez des critères d’intervention lorsqu’une mesure franchit une limite inacceptable, que l’une s’améliore tandis que l’autre empire, ou que les deux se détériorent. Convenez de qui enquêtera, de ce qui sera vérifié en premier et du moment où cette personne fera rapport.
5. Cette paire convient-elle toujours à l’étape actuelle du produit?
Décidez de la conserver, de la remplacer ou de la retirer. Un projet pilote peut privilégier la fiabilité des tâches et la confiance des utilisateurs; un service en production peut exiger un examen plus attentif des coûts et de la qualité. Fixez une date pour réévaluer ce choix.
La mesure des produits d’IA devrait faire plus que décrire le rendement. Elle devrait révéler les compromis de l’organisation et clarifier la prochaine décision.