Le marché de l’IA évolue à un rythme que je n’ai jamais vu auparavant.

Les fournisseurs emballent des cas d’utilisation agentiques plus vite que les clients ne peuvent les évaluer. Les clients approuvent des plans d’IA davantage motivés par l’anxiété compétitive que par une clarté d’objectif. Et, quelque part dans cette précipitation partagée — dans les démos, les présentations, les preuves de concept — un intervenant a complètement disparu.

Le client du client.

J’appelle ça le problème du client du client — et c’est la défaillance de conception la plus courante dans l’IA d’entreprise aujourd’hui. On est tellement concentré à vendre à l’acheteur et à impressionner le décideur qu’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 dans l’IA valait la peine.

Nous ne réglons pas le bon problème

Entrez dans la plupart des discussions sur l’IA d’entreprise aujourd’hui et la formulation 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 technique. »

C’est une proposition convaincante. Les indicateurs sont réels. La technologie fonctionne.

Mais voici la question que personne ne pose : Pourquoi ces billets L1 sont-ils créés au départ?

L’acheteur dans la pièce est le responsable TI ou le DSI. Le problème qu’on veut résoudre, c’est le leur — utilisation des agents, volume des billets, coût par résolution. Ce sont de vrais problèmes. Mais ils sont à un niveau d’écart de la personne dont l’expérience déterminera vraiment si l’investissement en valait la peine.

Cette personne, c’est l’employé qui essaie de faire réparer son portable avant un appel avec un client. Le nouvel employé qui ne peut accéder à trois systèmes dès son premier jour. L’analyste financier dont le processus d’approbation est coincé depuis 48 heures.

Ceux-ci sont les clients du client. Et la plupart des cas d’utilisation agentiques vendus aujourd’hui ne sont pas conçus autour d’eux.

Ce qui se passe quand on va un cran plus loin

Laissez-moi vous brosser un tableau que vous avez probablement déjà vécu.

Le portable d’un employé plante une heure avant une présentation à un client. Débordé et à court de temps, il ouvre le chatbot libre-service TI et tape : « mon portable ne fonctionne plus ». Le robot répond : « Veuillez sélectionner une catégorie. » L’employé choisit Matériel. On lui propose une liste de sept articles de la base de connaissances. Aucun ne s’applique. Il reformule. Le robot affiche à nouveau les mêmes articles. Il réessaie, cette fois plus précisément — et le robot lui propose de créer un billet.

Après trois minutes, il abandonne. Il prend le téléphone, attend en ligne, puis réexplique tout à un agent humain — arrivant à son appel client stressé et avec cinq minutes de retard.

L’agent IA a fonctionné techniquement. Il a classé la demande. Il a retourné des résultats. Selon tous les indicateurs internes, il a fait son travail. Mais l’expérience était un échec — parce que personne ne l’avait conçue selon ce dont cet employé avait réellement besoin à ce moment-là.

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

Il y a une réelle différence entre deux versions du même cas d’utilisation.

Version A : Un agent IA qui intercepte les demandes entrantes, les classe, tente une résolution automatique à partir des articles de la base de connaissances et fait une escalade quand la confiance est basse. Résolution plus rapide. Coût réduit. Mesurable.

Version B : Un agent IA conçu après avoir réellement observé des employés utiliser le chatbot — en notant qu’ils abandonnent la conversation après 90 secondes si les réponses sont génériques, et que la frustration culmine le lundi matin et le lendemain des mises à jour systèmes. Cet agent est construit pour comprendre le contexte, se réajuster gracieusement si la première réponse ne convient pas, et offrir une transition chaleureuse vers un humain avant que l’utilisateur n’abandonne. Il ne fait pas que résoudre, il inspire la confiance.

La version A est construite autour du critère de l’acheteur. La version B est pensée selon la réalité émotionnelle de l’utilisateur final. Les deux utilisent la même technologie sous-jacente. La différence est totalement dans la conception du cas d’utilisation.

La version B est ce qui arrive quand on applique la pensée design. Et l’histoire du chatbot est l’exemple parfait pour le démontrer.

C’est exactement à cela que sert la pensée design

La pensée design n’est pas une idée nouvelle. Mais appliquée au développement de cas d’utilisation d’IA agentique — en prenant l’expérience chatbot comme fil conducteur — elle devient une discipline que la majorité du marché néglige complètement.

Voici ce que ça donne en pratique :

Empathiser — avec l’utilisateur, pas avec le système. On ne fait pas qu’une entrevue avec le responsable TI sur le volume des billets. On s’assoit avec l’employé. On l’observe taper dans le chatbot dans un langage naturel — « mon VPN coupe constamment » — puis frapper un mur quand le robot lui demande de choisir dans une liste de catégories qui ne lui parle pas. On remarque qu’il quitte la conversation après 90 secondes. On apprend que le pic de frustration survient le lundi matin et après chaque mise à jour système. Rien de tout cela n’est visible dans un tableau de bord. On ne le voit qu’en observant de vraies personnes, dans de vrais moments.

Définir — la vraie problématique. Le problème n’est pas « on a besoin d’un meilleur chatbot ». Après l’empathie, l’énoncé de problème devient : « Les employés sous pression de temps ont besoin d’une résolution immédiate axée conversation — pas d’un formulaire papier en version numérique. » Ce seul recadrage change tout. Ça fait passer la conception d’un simple système de classification de requêtes à une expérience sensible au stress et adaptée au contexte. Maintenant, l’agent est utile.

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

Prototyper — cartographier la conversation, pas juste la logique. Avant de configurer un seul flux, on cartographie l’expérience depuis l’état émotionnel de l’utilisateur — pas depuis l’arbre décisionnel du système. Que dit l’agent quand la première réponse ne passe pas? Comment rebondit-il sans sonner robotique? Quel est le moment du transfert et est-ce fluide ou perçu comme un échec? On le teste avec de vrais employés avant la mise en service. Un prototype papier du dialogue va révéler plus de défauts de conception que trois sprints de développement.

Tester — mesurer ce que l’utilisateur a ressenti, pas juste ce que le système a fait. La plupart des évaluations d’agent s’arrêtent au taux de résolution : est-ce que la requête a été traitée ? La pensée design pose la question la plus difficile : est-ce que l’utilisateur s’est senti écouté ? A-t-il abandonné en cours de route ? A-t-il quand même appelé le service ? Si les gens continuent d’appeler le helpdesk, l’agent n’a pas réussi — peu importe ce que disent les indicateurs internes. Le taux d’abandon, les signaux de sentiment et le comportement post-interaction sur d’autres canaux sont les vrais critères d’évaluation.

Ce qui se produit si on saute cette étape

Sauter la pensée design et vous obtenez le résultat prévisible : enthousiasme initial, adoption modérée et un rendement décevant dont personne ne veut parler publiquement. Les organisations qui achètent l’IA par peur de manquer le train auront un retour de réalité dans 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 ceux qui doivent vivre avec.

Le chatbot qui tourne en rond. L’agent qui escalade trop tard. Le flux qui fait gagner du temps à l’équipe TI mais irrite l’employé de l’autre côté. Ce ne sont pas des échecs technologiques. Ce sont des échecs de conception. Et ils sont tout à fait évitables.

Prendre le temps pour la conception n’est pas un désavantage concurrentiel en ce moment. C’est l’avantage concurrentiel. Les organisations qui réussiront auront les exemples à citer. Les autres auront les leçons à retenir.

Une question qui change tout

Vous n’avez pas à revoir à zéro tout votre processus de vente ou de livraison pour appliquer cette réflexion. Il suffit d’ajouter une question à chaque discussion sur un cas d’utilisation agentique :

Qui est le client de votre client — et de quoi a-t-il vraiment besoin?

Cette question stoppera la discussion technique nette. Elle redirigera le groupe de ce qu’une IA peut faire vers ce que l’utilisateur final a réellement besoin de ressentir. Elle mettra de l’avant la conception à laquelle personne n’a pensé budgéter — mais qu’on ne peut plus se permettre d’ignorer.

Les fournisseurs qui gagneront dans les deux prochaines années ne seront pas ceux qui auront bougé le plus vite. Ce seront ceux dont les cas d’utilisation ont fonctionné — parce que quelqu’un a pris le temps de poser cette question avant même d’écrire une ligne de logique d’automatisation.

Faites du design avant de déployer. Votre client du client compte sur vous.