Ce que votre agent IA ne peut pas gérer, c'est l'entreprise que vous n'avez pas encore construite

Le chatbot d'IKEA a créé des emplois.

Pas en faisant plus, mais en révélant ce qu'il ne savait pas faire.

Billie, l'agent de service client d'IKEA, résout 47% des demandes entrantes depuis 2021 sans intervention humaine. 3,2 millions d'interactions, 13M€ d'économies, et chaque présentation de transformation digitale en Europe a maintenant sa slide là-dessus. Ce chiffre de 47% a été copié-collé dans tellement de pitch decks qu'il est devenu le "ça marche sur ma machine" des business cases IA : tout le monde le cite, personne ne vérifie ce qui tourne en dessous.

Personne n'a couvert l'autre colonne.

Les 53% que Billie n'arrivait pas à gérer ont alimenté un programme de reconversion : 8 500 employés de centres d'appels recyclés en conseillers déco à distance. Ce canal a généré 1,3Md€ en 2022. Pour être précis sur ce que ça signifie : ce chiffre couvre toute l'activité de vente à distance d'Ingka, et une partie de ce chiffre d'affaires existait avant le programme de reconversion. Le lien de causalité n'est pas parfaitement net. Mais l'ordre de grandeur tient, et l'insight stratégique n'a pas besoin d'une causalité parfaite. Ce n'est pas une histoire RH. C'est un signal produit que tout le monde a lu à l'envers.

Le Ratio Dont Personne N'a Parlé

La presse business a couvert le cas IKEA et l'a immédiatement cadré comme une histoire de transformation des équipes. "L'IA crée des emplois, elle ne les détruit pas." Joli titre. Vrai, même. Mais ça a enterré le vrai insight sous une couche de narratif rassurant surtout conçu pour que le comex se sente mieux sur le budget IA et l'optique sociale en même temps.

IKEA n'a pas trouvé 1,3Md€ en construisant un meilleur chatbot. Ils l'ont trouvé en se demandant ce que le chatbot ne savait pas faire et en traitant cette réponse comme une opportunité business. Les 53% n'étaient pas une métrique d'échec. C'était une carte de la demande que personne n'avait pensé à lire.

Chaque fois que Billie transférait une conversation, il signalait un besoin client que le produit ne savait pas encore servir. 53% des interactions clients étaient de la demande non satisfaite qui dormait dans le fichier de log. La demande non satisfaite n'est pas un problème à contourner, c'est un gap produit avec une étiquette de prix. Et plus vous optimisez les 47%, plus les 53% deviennent invisibles, parce que le dashboard donne l'impression que le système fonctionne très bien.

Vous Regardez le Mauvais Dashboard

Toutes les équipes d'agents IA que je connais surveillent le taux de déflection. C'est la métrique évidente : combien de demandes l'agent résout-il sans escalader ? Plus c'est haut, mieux c'est. Vous l'optimisez, vous la reportez, vous la mettez dans le deck de revue mensuelle. La courbe monte, tout le monde se sent bien sur le trimestre.

Le problème n'est pas que le taux de déflection soit inutile. Il est structurellement aveugle à ce que les utilisateurs voulaient vraiment dans les conversations que l'agent a abandonnées. La métrique mesure ce qui a réussi. Elle ne vous dit rien sur la forme de ce qui a échoué.

Pensez à Google Analytics. Les pages vues vous disent ce qui marche. Les pages de sortie vous disent où votre produit est cassé. Les pages de sortie sont presque toujours plus précieuses pour décider quoi construire ensuite. (Ça m'est arrivé dans GA4 une fois. 6 mois à construire des features basées sur ce que les gens regardaient le plus longtemps, qui s'est avéré être la page de prix parce qu'ils étaient confus, pas intéressés. Side quest de manuel. Je farmais le mauvais mob. Ça pique.) Vous ne corrigez pas un taux de sortie de 38% sur votre page de checkout en vous félicitant des 62% qui sont passés. Vous regardez où les gens sont partis et vous demandez pourquoi.

Les logs d'agents fonctionnent pareil. Vous optimisez les 47%. Vous ne lisez pas les 53%.

Une raison de plus pour commencer : si vos agents tournent sur une architecture CLI-native, ces logs sortent structurés. Pas une soupe de texte conversationnel mais de l'output réellement lisible par machine que vous pouvez piper dans un prompt d'audit sans passer un après-midi à nettoyer les données d'abord. Je suis rentré dans l'argument complet pour pourquoi les agents CLI-native produisent des logs plus exploitables, ça vaut le coup de lire avant d'essayer cet audit sur des logs bordéliques et de se demander pourquoi le clustering revient inutile.

Votre Log d'Échecs Est une Carte de la Demande

Tout ce que votre agent refuse n'est pas une opportunité. Évacuons ça d'abord. Les blocages délibérés, les murs d'auth tiers, les opérations destructives, les trucs hors scope par policy : ça fonctionne correctement. Ce ne sont pas des gaps produit. Le filtre est simple : fréquence combinée avec reformulation égale signal réel. Une occurrence unique est probablement du bruit.

4 signaux qui valent le coup d'être lus dans ce que votre agent abandonne, du plus fort au plus subtil.

Signal 1 : Questions refusées récurrentes. Quand différents utilisateurs tapent le même mur avec le même type de question sur une fenêtre de 30 jours, ce mur est une demande de feature avec un échantillon attaché. Vous ne regardez pas 1 utilisateur confus. Vous regardez de la demande que vous n'avez pas encore servie.

Signal 2 : Reformulations répétées en session. Un utilisateur qui reformule la même demande 3 ou 4 fois sans obtenir de réponse utile n'est pas confus sur comment le produit fonctionne. Il persiste parce que le besoin est réel et qu'il ne peut le trouver nulle part ailleurs. Le nombre de boucles est une mesure de à quel point il le veut.

Signal 3 : Patterns de fallback systématiques. Regardez quelle catégorie de demande tape systématiquement le fallback, pas les demandes individuelles, les catégories. "Les utilisateurs veulent comparer 2 options directement." "Les utilisateurs veulent un suivi programmé." Ce ne sont pas des échecs aléatoires. C'est le contour de ce que vos utilisateurs veulent vraiment versus ce que vous avez construit.

Signal 4 : Retries haute-énergie. Quand un utilisateur fait la même demande 5 fois dans une seule session avec une spécificité croissante à chaque fois, ce n'est pas un utilisateur confus. C'est quelqu'un qui ne peut pas trouver ce dont il a besoin ailleurs. Le nombre de retries est un proxy de la volonté de payer. Plus l'effort est élevé, plus vous regardez probablement un besoin premium qui n'a pas de place dans votre produit actuel.

1 caveat que je pense vraiment : les signaux sont réels. Votre interprétation d'eux pourrait ne pas l'être. Lancez l'audit, mais ne construisez pas directement depuis l'output sans au moins une validation informelle d'abord. Un appel de 30 minutes avec 2 utilisateurs bat un clustering IA haute-confiance à chaque fois.

Le log d'échecs est la seule spec produit que vos utilisateurs ont vraiment écrite.

Ce Que 3,5 GB de Logs M'ont Appris

J'ai lancé l'audit sur 3,5 GB de transcripts Claude Code : 2 801 fichiers, 30 jours, 101 projets.

Le pattern le plus comptable était exactement ce que le dashboard me disait : 112 fallbacks d'auth sur des panels tiers. Visible, attendu, et complètement non-actionnable parce que le fix dépend de vendors qui n'ont aucune raison de se soucier de mon use case. Je sais ça depuis des mois.

C'était mes 47%.

Ce qui se cachait dans l'autre colonne ressemblait à ça. Environ 20 occurrences brutes d'une boucle de reformulation, ce qui sonne comme du bruit jusqu'à ce que vous regardiez ce qu'il y a dans ces sessions et réalisiez que "pareil" ou "toujours cassé" revenait 2 à 5 fois par session, à chaque fois la même séquence qui se jouait : l'agent livrait une feature UI et déclarait que c'était fini, je testais manuellement sur mobile, quelque chose cassait, l'agent repartait d'un angle légèrement différent au tour suivant, toujours incapable d'enregistrer que "fini" signifiait fonctionnel sur toutes les surfaces et pas juste dans le sandbox auquel il avait accès pendant la session, et au 4ème loop je brûlais du temps que je n'avais pas prévu sur un problème que j'avais techniquement "résolu" deux fois déjà. Au loop 4 ça ressemblait à un run Dark Souls où quelqu'un avait patché le bonfire et j'essayais encore le même pattern d'esquive sur le même boss. (Dark Souls au moins vous dit "YOU DIED" donc vous savez quand arrêter.)

Le log d'échecs encodait quelque chose de spécifique : j'avais besoin d'un hook bloquant qui refuse de fermer un tour sans preuve end-to-end réelle, un test et pas une déclaration, desktop et mobile. 1 jour de travail à construire, et c'était caché dans 20 lignes de log que personne ne lisait.

Puis 7 occurrences de quelque chose qualitativement différent : du contenu qui sentait l'IA, le genre de taglines génériques et de copy hors-persona qui atterrit sur un site lifestyle et signale immédiatement qu'un humain ne l'a pas écrit. (Je peux toujours le dire quand ça arrive. Il y a une platitude spécifique, comme si le modèle avait atteint la première formulation acceptable et s'était arrêté là.) Ce n'était pas de la demande utilisateur externe. C'était un gap de spec interne : pas de gate qualité contenu avec des anti-patterns explicites et des contraintes de persona par site. Le log d'échecs n'avait pas fait surface une demande de feature utilisateur. Il avait fait surface une absence que je n'avais jamais formalisée. Mécanisme différent du pattern de boucle, même source.

Le dashboard comptait 112 fallbacks d'auth. Le coût réel était dans les boucles et les 7 livraisons hors-ton. Et si 7 sur 2 800 fichiers sonne trop petit pour s'en soucier : chacun m'a coûté une session complète de réécriture manuelle.

Lancez l'Audit 53% sur Vos Logs

3 prompts. Copier-coller dans Claude avec vos logs d'agent. Lancez-les en séquence, ou commencez juste par le Prompt 1 si vous êtes à court de temps.

Prompt 1 : Clusteriser les demandes refusées et détecter les boucles de reformulation (Signaux 1+2)

Analysez ces logs d'agent et faites ce qui suit :

1. Extrayez toutes les demandes que l'agent a refusées, n'a pas pu gérer, ou a transmises au fallback.
2. Clusterisez-les par thème. Nommez chaque cluster en langage simple.
3. Pour chaque cluster : comptez la fréquence, signalez toute session où la même demande
   a été reformulée 2+ fois sans succès.
4. Classifiez chaque cluster : gap feature | bug | hors scope par design | pas clair.
5. Estimez la valeur potentielle : faible | moyenne | élevée (basé sur fréquence et effort de retry).

Pour chaque cluster, sortez : nom, fréquence, sessions de reformulation, catégorie, valeur potentielle.

Terminez par 1 phrase : "Si vous deviez construire 1 chose depuis cet output, ce serait ___."

Prompt 2 : Isoler les boucles de reformulation (Signal 2 deep dive)

Depuis ces logs d'agent, trouvez toutes les sessions où l'utilisateur a reformulé la même 
demande 2 fois ou plus sans réponse réussie.

Pour chaque session :
- Quelle était la demande originale ?
- Combien de fois l'utilisateur a-t-il reformulé ?
- Quel était le résultat final (fallback / partiel / abandonné) ?
- Ce pattern se répète-t-il sur plusieurs sessions, ou est-ce ponctuel ?

Groupez les sessions par besoin sous-jacent, pas par formulation exacte. Séparez la vraie 
demande récurrente de la friction ponctuelle.

Prompt 3 : Scorer par fréquence x effort (Signaux 3+4)

Depuis ces logs d'agent, scorez chaque pattern d'échec :
Fréquence x Effort utilisateur = Score de priorité

Effort utilisateur = nombre de retries + nombre de reformulations par session.

Classez tous les patterns par score de priorité, le plus élevé d'abord.
Pour le top 5 : que faudrait-il pour gérer cette demande avec succès ? 
1 phrase par pattern.

Signalez tout pattern où l'effort utilisateur est élevé mais la fréquence faible.
Ce sont vos outliers haute-valeur.

Le Prompt 2 fait spécifiquement surface quelque chose qui vaut le coup d'être lu avec un cadre plus large : les boucles de session répétées ne signifient pas juste "l'agent a échoué répétitivement," elles signalent ce qu'on demande à votre agent de devenir. J'ai déballé ce que les boucles de session répétées signalent sur votre agent en détail, le cadrage s'applique directement ici.

2 Lectures, Mêmes Logs

IKEA n'a pas construit un meilleur chatbot. Ils ont lu la queue d'abandons et demandé ce qu'elle leur disait sur le business qu'ils n'avaient pas encore construit.

Vous avez les mêmes logs. Vous ne les lisez probablement pas (peut-être que je me trompe là-dessus, peut-être que votre équipe lance déjà cet audit chaque sprint et la queue d'échecs est vide et vous construisez précisément ce que les utilisateurs ne peuvent trouver nulle part ailleurs). En 3 ans à faire tourner des agents sur différents produits et pipelines, je n'ai jamais vu cette config. Ce que je vois c'est un taux de déflection sur un dashboard et un dossier de logs que personne n'ouvre.

Collez vos logs dans le Prompt 1. Lisez la colonne valeur potentielle. Vérifiez si ce qui fait surface est quelque chose que vous connaissez depuis des mois mais que vous n'avez jamais construit.

Si la réponse est oui, c'est votre 1,3Md€ qui se cache en pleine vue.

Sources

• Ingka Group. AI and Remote Selling bring IKEA design expertise to the many. Ingka Newsroom, 2023.
• Clancy, Will. How IKEA turned a €13 million chatbot into a €1.3 billion activity. CIO.com, June 2026.
• Robertson, Scott. How IKEA Turned 8,500 Call Centre Workers Into Interior Design Advisors Using AI. Substack, April 2026.

Cet article peut contenir des liens d'affiliation. Si vous cliquez dessus, je pourrais gagner une petite commission (ça ne vous coûte rien, et ça m'aide à continuer de livrer des articles de qualité chaque jour pour votre plaisir de lecture).