l’expérience a été un échecLe marché de l’IA évolue à un rythme que je n’ai jamais vu auparavant.

Les fournisseurs emballent des cas d'utilisation agentiques plus rapidement que les clients ne peuvent les évaluer. Les clients approuvent des feuilles de route d’IA davantage en raison de l’anxiété face à la concurrence que d’une clarté d’objectif. Et quelque part dans cette course mutuelle — dans les démonstrations, les présentations, les preuves de concept — un intervenant a complètement disparu.

Le client du client.

J’appelle cela le problème du client du client — et c’est l’échec de conception le plus courant en IA d’entreprise aujourd’hui. On se concentre tellement sur la vente à l’acheteur et sur l’impressionner le décideur que l’on oublie de se demander qui l’organisation de l’acheteur sert réellement. Et c’est cette personne — l’utilisateur final, l’employé, l’humain de l'autre côté du flux de travail — dont l’expérience déterminera en fin de compte si l’investissement en IA en valait la peine.

Nous résolvons le mauvais problème

Asseyez-vous dans la plupart des conversations sur l’IA d’entreprise aujourd’hui et l’encadrement du cas d’utilisation ressemble à ceci : « Nous allons déployer un agent IA pour résoudre automatiquement les billets L1, réduire le MTTR et libérer votre équipe du service d’assistance. »

C’est un argument convaincant. Les mesures sont réelles. La technologie fonctionne.

Mais voici la question que personne ne pose : pourquoi ces billets L1 sont-ils soumis en premier lieu ?

L’acheteur dans la salle est le responsable TI ou le DSI. Le problème résolu est leur problème — utilisation des agents, volume des billets, coût par résolution. Ce sont des problèmes légitimes. Mais ils sont un niveau éloignés de la personne dont l’expérience détermine réellement si l’investissement en valait la peine.

Cette personne est l’employé qui tente de faire réparer son portable avant un appel client. Le nouvel employé qui ne peut pas accéder à trois systèmes lors de sa première journée. L’analyste financier dont le flux d’approbation est bloqué depuis 48 heures.

Ce sont les clients des clients. Et la plupart des cas d’utilisation agentiques vendus aujourd’hui ne sont pas conçus en fonction d’eux.

Ce qui se passe quand on va un niveau plus loin

Laissez-moi vous décrire une situation que vous avez probablement déjà vécue vous-même.

Le portable d’un employé plante une heure avant une présentation client. Stressé, pressé par le temps, il ouvre le chatbot d’auto-assistance TI et tape : « mon portable ne fonctionne pas ». Le bot répond : « Veuillez sélectionner une catégorie. » Il choisit Matériel. Le bot retourne une liste de sept articles de la base de connaissances. Aucun n’est pertinent. Il reformule. Le bot revient aux mêmes articles. Il réessaie, cette fois de façon plus précise—et le bot lui demande de soumettre un billet.

Après trois minutes, il abandonne. Il décroche le téléphone, attend en ligne et explique tout depuis le début à un agent humain — arrivant à son appel client frustré et avec cinq minutes de retard.

L’agent IA a techniquement fonctionné. Il a classé la requête. Il a généré des résultats. Selon tous les indicateurs internes, il a performé. Mais l’expérience a été un échec — parce que personne ne l’a conçue en fonction de ce dont cet employé avait réellement besoin à ce moment-là.

C’est l’écart entre construire de l’IA et la concevoir. Et il est partout.

Il y a une vraie différence entre deux versions d’un même cas d’utilisation.

Version A : Un agent IA qui intercepte les requêtes entrantes, les classe, tente la résolution automatique à l’aide d’articles de la base de connaissances et fait une escalade lorsque la confiance est faible. Résolution plus rapide. Coût inférieur. Mesurable.

Version B : Un agent IA conçu après avoir réellement observé les employés interagir avec le chatbot — remarquant qu’ils abandonnent les conversations dans les 90 secondes lorsque les réponses sont génériques et que la frustration atteint son paroxysme le lundi matin et le lendemain des mises à jour système. Cet agent est conçu pour comprendre le contexte, se rétablir avec grâce lorsque la première réponse ne répond pas aux attentes et offrir une transition humaine chaleureuse avant que l’utilisateur ne jette l’éponge. Il ne fait pas que résoudre — il gagne la confiance.

La version A est construite autour de l’indicateur de l’acheteur. La version B est construite autour de la réalité émotionnelle de l’utilisateur final. Les deux utilisent la même technologie sous-jacente. La différence réside entièrement dans la façon dont le cas d’utilisation a été conçu.

La version B est ce qui arrive quand on applique le design thinking. Et l’histoire du chatbot est l’illustration parfaite pour montrer exactement comment.

C’est exactement à cela que sert le design thinking

Le design thinking n’est pas une nouvelle idée. Mais appliqué au développement de cas d’utilisation d’IA agentique — utilisant l’expérience du chatbot comme fil conducteur — il devient une discipline que la plupart du marché saute complètement.

Voici à quoi cela ressemble en pratique :

Faire preuve d’empathie — envers l’utilisateur, pas le système. Vous n’interrogez pas seulement le gestionnaire TI à propos du volume des billets. Vous vous asseyez avec l’employé. Vous le regardez taper dans le chatbot, en langage naturel — « mon VPN cesse de fonctionner » — et vous l’observez frapper un mur lorsque le bot lui demande de sélectionner dans une liste de catégories auxquelles il ne s’identifie pas. Vous remarquez qu’il abandonne la conversation en moins de 90 secondes. Vous apprenez que le pic de frustration survient le lundi matin et après chaque mise à jour du système. Rien de tout cela n’apparaît dans les tableaux de bord. Vous ne le découvrez qu’en observant de vraies personnes dans de vrais moments.

Définir — l’énoncé réel du problème. Le problème n’est pas « il nous faut un meilleur chatbot ». Après avoir fait preuve d’empathie, l’énoncé du problème devient : « Les employés sous pression de temps ont besoin d’une résolution instantanée et conversationnelle — pas d’une version numérique d’un formulaire papier. » Ce simple recadrage change tout. Il fait passer la conception d’un système de classification des demandes à une expérience sensible au stress et au contexte. Là, l’agent a un vrai rôle.

Idéation — le bon niveau d’autonomie. Chaque problème n’a pas besoin d’un agent entièrement autonome. Ici, l’étape d’idéation pourrait révéler que la résolution complète n’est même pas la priorité, mais bien la rapidité vers un humain. La bonne conception pourrait être un agent qui détecte tôt les signes de frustration (reformulations répétées, réponses courtes, silence), les reconnaît de façon conversationnelle et offre une transition humaine chaleureuse avant que l’utilisateur ne renonce et n’appelle. C’est une décision de conception. Sans idéation, vous ne la prendriez jamais de façon intentionnelle.

Prototyper — cartographier la conversation, pas juste la logique. Avant de configurer le moindre flux, cartographiez l’expérience à partir de l’état émotionnel de l’utilisateur — et non de l’arbre de décision du système. Que dit l’agent quand la première réponse tombe à plat ? Comment se rétablit-il sans avoir l’air robotisé ? Quel est le moment de la transition, et est-ce fluide ou perçu comme un échec ? Testez-le avec de vrais employés avant la mise en production. Un prototype papier de l’écoulement de la conversation fera ressortir plus de défauts de conception que trois sprints de développement.

Tester — mesurer ce que l’utilisateur a ressenti, pas seulement ce que le système a fait. La plupart des évaluations d’agents s’arrêtent au taux de résolution : a-t-il répondu à la demande ? Le design thinking pose la question la plus difficile : l’utilisateur s’est-il senti écouté ? A-t-il quitté la conversation en cours ? A-t-il quand même appelé ensuite ? Si les gens appellent encore le centre d’assistance, l’agent n’a pas réussi — peu importe ce que disent les indicateurs internes. Le taux d’abandon, les signaux de sentiment et les comportements d’après-interaction sont les vrais indicateurs.

Ce qui se passe si vous sautez cette étape

Sauter le design thinking vous mène à un résultat prévisible : enthousiasme initial élevé, adoption modérée et ROI décevant dont personne ne veut parler publiquement. Les organisations qui achètent l’IA à cause de la FOMO en feront les frais d’ici 12 à 18 mois — non pas parce que la technologie a échoué, mais parce que les cas d’utilisation n’ont jamais été conçus pour les personnes qui devaient vivre avec.

Le chatbot qui tourne en boucle. L’agent qui escalade trop tard. Le flux de travail qui fait gagner du temps à l’équipe TI, mais frustre l’employé à l’autre bout. Ce ne sont pas des échecs technologiques. Ce sont des échecs de conception. Et ils sont totalement évitables.

Prendre le temps de concevoir n’est pas un désavantage compétitif en ce moment. C’est l’avantage compétitif. Les organisations qui le font correctement auront de vraies histoires de référence. Les autres n’auront que des leçons apprises.

Une question qui change tout

Vous n’avez pas besoin de réviser complètement votre processus de vente ou de livraison pour appliquer cette approche. Vous devez simplement ajouter une question à chaque discussion sur un cas d'utilisation agentique :

Qui est le client de votre client — et de quoi a-t-il réellement besoin ?

Cette question arrêtera une discussion sur les fonctionnalités net. Elle redirigera la conversation de ce que l’IA peut faire vers ce dont l’utilisateur final a besoin de ressentir. Elle fera apparaître le travail de conception que personne n’avait budgété — et que personne ne peut se permettre de négliger.

Les fournisseurs qui réussiront au cours des deux prochaines années ne seront pas ceux qui ont bougé le plus vite. Ce seront ceux dont les cas d’utilisation ont fonctionné — parce que quelqu’un a pris le temps de poser la question avant que quiconque n’écrive une seule ligne de logique d’automatisation.

Concevez avant de déployer. Le client de votre client compte sur vous.