Adrian McDermott (CTO Zendesk) : comment recomposer un service client à l’ère des agents IA

Architecte technique de la nouvelle direction stratégique de Zendesk, l’Autonomous Service Workforce annoncée cette semaine à Denver, Adrian McDermott porte une thèse claire : l’IA ne sert pas à automatiser ce qu’on faisait avant, mais à construire ce qu’on ne pouvait pas faire. Le Chief Technology Officer global est revenu pour BDM sur la stratégie d’acquisition, le concept de service debt qu’il a popularisé, le rôle du Model Context Protocol et la recomposition des métiers humains à venir. Un manuel de l’architecte IA, signé d’un patron technique qui rappelle avoir « beaucoup échoué » avant d’arriver là.

En 2025, Zendesk présentait la Resolution Platform. Cette année, l’Autonomous Service Workforce est annoncé. Qu’est-ce qui change vraiment avec ce positionnement ?

L’IA évolue tellement vite que notre vision évolue avec elle. Si on remonte un an, dix-huit mois en arrière, on commençait à comprendre comment utiliser l’IA agentique pour avoir des conversations avec nos clients, et comment l’utiliser pour aider nos agents à avoir de meilleures conversations en mode human in the loop (avec un humain dans la boucle, ndlr). On a posé ces premières briques.

Mais ce qu’on fait, fondamentalement, c’est du service client. Et l’enjeu dans le service client, c’est de se demander comment utiliser l’IA à l’échelle de toute l’équipe. L’Autonomous Service Workforce part de l’idée que chaque aspect de notre travail va être touché par l’IA agentique. Soit elle assiste, soit elle automatise une bonne partie des tâches. Soit, et c’est ce qu’on commence à voir avec les Custom Agents Zendesk et nos premiers clients qui les utilisent, elle ouvre de nouveaux cas d’usage qui n’étaient pas possibles avant : là où la seule manière d’avoir de la réflexion et de la capacité cognitive, c’était l’humain.

L’humain est une ressource précieuse. Il y a tellement de choses qu’on aurait pu faire et qu’on ne faisait pas parce que ce n’était pas viable économiquement. Maintenant on peut. L’Autonomous Service Workforce, ce n’est pas automatiser ce qu’on faisait avant. C’est réfléchir à ce qu’on peut faire, à ce qu’on peut construire.

Zendesk a opéré de nombreuses acquisitions ces dernières années. Pour les lecteurs qui découvrent cette stratégie, comment expliqueriez-vous ce qui motive cette suite de rachats plutôt que de tout construire en interne ?

Quand on acquiert des entreprises, il y a trois choses qu’on achète.

1. La première, c’est l’innovation. On rachète des gens qui ont créé quelque chose qu’on aimerait posséder. Je placerais l’acquisition de HyperArc, qui propulse notre Analytics Copilot tout juste présenté, dans cette catégorie. C’est une innovation unique dans la manière de penser la mémoire dans les données et la compréhension de la donnée. On ne l’aurait trouvée nulle part ailleurs.
2. La deuxième, c’est l’équipe. On acquiert un groupe de personnes dont l’ADN se place dans un domaine de problèmes qu’elles comprennent fondamentalement bien. Oui, si je démarrais aujourd’hui, je pourrais embaucher dix personnes et on pourrait commencer à travailler dessus. Mais il faut souvent échouer plusieurs fois pour devenir bon. Et j’ai beaucoup échoué. Donc on acquiert du talent.
3. La troisième chose qu’on acquiert, c’est le temps. À ne pas sous-estimer. La plupart des acquisitions arrivent avec un peu des trois. Si on prend quelques-unes des nôtres, on est entré sur des marchés où on n’avait pas de produit : workforce management pour le service client, QA pour le service client. Tymeshift à Lisbonne et Klaus à Tallinn en sont de bons exemples. Parfois on acquiert du temps, parfois on acquiert de l’innovation.

En parallèle, on lance notre plateforme Custom Agents, on vient de lancer notre ITAM (IT Asset Management, la gestion du parc informatique, ndlr), et notre AI Actions Platform agentique pour l’intégration. Tout ça, c’est ce qu’on appelle de l’innovation « zero to one » (créée de toutes pièces, ndlr). Pour l’ITAM par exemple, après avoir regardé les acteurs du secteur, on a décidé de le construire de zéro.

À chaque fois qu’on regarde un marché, une entreprise ou une innovation à creuser, on passe par cette réflexion « build, buy, partner » (construire, acheter ou devenir partenaires, ndlr) pour déterminer ce qui va marcher le mieux.

Forethought a été intégré directement dans vos agents IA Zendesk, pas comme un produit séparé. Vous parlez d’agents qui s’auto-améliorent en continu via votre Resolution Learning Loop. Concrètement, qu’est-ce que ça change pour un client qui utilise Zendesk depuis des années ?

Pour vraiment faire de l’amélioration continue, il faut tirer parti de ce qu’on a : un système d’intelligence qui regarde chaque interaction, chaque donnée et qui peut formuler des recommandations pour améliorer le service. Prenez l’exemple d’un retailer dont les agents IA échouent à traiter automatiquement les demandes de retour produit au Canada quand le produit contient un liquide, parce que les règles d’expédition l’interdisent. Avec la Resolution Learning Loop (la boucle d’apprentissage continu de la plateforme, ndlr), quand un cas comme ça remonte, le système peut générer automatiquement la nouvelle procédure pour l’IA et la proposer à l’admin : « Voulez-vous approuver, ou modifier légèrement ? On pense qu’on pourrait donner un meilleur service en faisant comme ceci. »

C’est ce que faisait, jusqu’ici, le knowledge manager ou le service operations manager : récupérer du feedback d’un agent, le recouper avec un autre, repérer un pattern. Mais chaque agent du service client ne voit qu’un ticket à la fois. Vous pouvez avoir une expérience, et quelqu’un à Istanbul peut avoir exactement la même, sans qu’on les mette jamais en relation. Pour le faire à l’échelle d’une grande entreprise, il faudrait une organisation managériale qui n’existe pas. Donc on veut construire des systèmes qui le font à la place des humains, pour que les entreprises s’améliorent en continu et captent chaque signal.

Vous avez popularisé le concept de « service debt ». C’est un terme qui commence à circuler mais qui reste flou. Vous pouvez nous l’expliquer ?

Voici la donnée la plus contre-intuitive qu’on observe : quand un client automatise 40 % de ses interactions, son volume total d’interactions avec ses clients augmente de 176 %. Ma conviction, c’est qu’aucune entreprise ne devrait jamais dire « on a assez de service ». Les contact centers sont des usines qui tournent à la puissance humaine. Les métriques utilisées pour les piloter sont des métriques d’efficacité humaine : tickets par jour, délai de première réponse, durée moyenne de traitement d’un ticket. Optimiser ces métriques, c’est optimiser la quantité de tickets qu’un agent peut absorber dans la journée. Pas la qualité du service rendu.

Conséquence : toute entreprise a en réalité une support debt (dette de support, ndlr). Les clients abandonnent à cause du temps d’attente, ne trouvent pas d’aide, renoncent à des demandes qu’ils auraient voulu faire. C’est cette dette latente que l’automatisation révèle. Une fois qu’on automatise les expériences de façon correcte pour les clients, on découvre tout ce qu’ils essayaient de nous demander et qu’on ne voyait pas.

Au passage, on observe aussi que automation drives escalation (l’automatisation pousse l’escalade vers l’humain, ndlr) : la charge médiane des agents humains a augmenté de 87 %. Ils deviennent plus efficaces, comme dopés.

La service debt (la dette de service, ndlr), c’est l’idée qu’on ne sert pas vraiment tous ses clients avec tout ce qu’ils voudraient. Et plus on rend le service pratique, plus les gens l’utilisent. Les économistes parlent de paradoxe de Jevons, qui est devenu le terme à la mode dans l’IA en ce moment.

Et si une entreprise voulait s’attaquer à sa service debt à partir de demain, par où elle commencerait, et comment elle saurait qu’elle progresse ?

Je pense à la manière dont on aide nos clients à déployer nos agents IA. Chez Zendesk, on étiquette chaque contact client avec ce qu’on appelle l’intent (l’intention du client, ndlr) : qu’est-ce qu’il cherchait à faire ? Quelle était la raison du contact ? Quel est son sentiment, dans quelle langue parle-t-il ? On cartographie ensuite ces intents par volume et par durée moyenne, puis on évalue lesquels sont les plus automatisables. Et on aide le client à les automatiser, à les connecter aux systèmes nécessaires, à mettre en place l’authentification.

Trop de décisions en entreprise sont pilotées par « il me faut une stratégie globale et il faut que je sache où je vais avant de me lancer ». Il y a quelque chose à dire en faveur de l’itération vers le succès. Surtout si vous le faites en gardant un œil sur vos métriques de qualité. C’est l’une des raisons pour lesquelles Zendesk a lancé Quality Score cette semaine : se donner une mesure objective de la qualité de service délivrée.

L’exemple le plus parlant pour moi, c’est l’usage de Zendesk par Zendesk. On a commencé à utiliser notre propre agent IA, et, de manière presque contre-intuitive pour certains, on l’utilise plutôt agressivement. On automatise 60 à 70 % de nos demandes, et nos NPS, TNPS (transactional Net Promoter Score, mesuré à la fin d’une conversation de service client, ndlr) et CSAT (indice de satisfaction) progressent en parallèle. La leçon : construisez de bons parcours, branchez-les sur les capacités que l’IA met à votre disposition, et vous construirez mieux.

Vous lancez à la fois un MCP Client et un MCP Server. Pourquoi Zendesk a-t-il choisi de s’aligner sur ce standard ? Et entre le Client et le Server, lequel change le plus la donne pour vos clients ?

Le Client et le Server ont des cas d’usage différents, ce sont les deux faces d’un même protocole. Pour moi, Zendesk en tant que MCP Client, c’est une nouvelle manière de tout connecter. Je suis un homme d’un certain âge, je fais de la tech depuis longtemps : à l’origine c’était SOAP, puis REST, XML, et maintenant MCP. C’est utile parce que c’est un ensemble de manières standards de se connecter, très faciles à implémenter et flexibles. Vous pouvez le construire avec un modèle d’IA à partir d’une API REST. C’est devenu la lingua franca des agents IA, donc ça a du sens de l’adopter. Est-ce que MCP est une technologie révolutionnaire ? Non. Est-ce qu’elle a atteint la vitesse de libération et qu’elle est en orbite ? Oui. Si vous avez une plateforme d’intégration comme notre Zendesk AI Actions Platform, c’est absolument essentiel d’être capable de la consommer, parce que vous accédez alors à énormément de systèmes différents.

L’autre direction, c’est le MCP Server : c’est nous qui mettons à disposition nos données et workflows pour que des systèmes IA tiers puissent venir les chercher. Cette semaine on parle des LLM comme nouveau canal de service. Au passage, le trafic de Zendesk vers notre propre help center est en baisse de 20 %, parce que les questions trouvent leur réponse dans ChatGPT ou Gemini. Le MCP Server, c’est ce qui permet à nos clients d’aller dans cette direction : utiliser leur plateforme Zendesk comme brique d’une solution agentique plus large, branchée sur des assistants IA externes.

La façon de gagner pour n’importe quel éditeur logiciel à l’échelle, c’est d’être à la fois Client et Server, et de comprendre quand on apporte de la valeur dans chaque rôle. Certains de nos plus gros comptes construisent déjà leurs propres agents avec leurs données et leur expertise, ce qui ouvre des cas d’usage agent-to-agent fascinants.

Tom Eggemeier a parlé ce matin de la multiplication d’agents IA spécialisés : customer success agent, community agent, support agent. Pour les équipes humaines en service client, ça veut dire quoi concrètement ? Plus d’agents IA = moins d’humains, ou est-ce qu’on assiste à une recomposition des rôles ?

Une recomposition, sans aucun doute. Aujourd’hui, les contact centers d’envergure fonctionnent comme des usines à puissance humaine, avec des rôles bien hiérarchisés : le tier 0 (premier niveau, tri très basique, ndlr), les tiers 2 et 3 de plus en plus expérimentés, les team leads qui gèrent les agents humains et organisent les plannings, et enfin des rôles très spécialisés et très étroits comme l’expert en knowledge management. Pour penser comment ces métiers évoluent dans un monde IA, la bonne piste, c’est de ne pas confondre les tâches sur lesquelles les gens passent le plus de temps avec la finalité du métier.

Bon exemple avec Sir Geoffrey Hinton, prix Nobel et popularisateur du deep learning. Il a dit un jour aux étudiants : « Ne devenez pas radiologues, on n’en aura probablement plus besoin dans cinq ans. » Cinq ans plus tard, il y a plus de radiologues qu’avant. Pourquoi ? La FDA (Food and Drug Administration, l’autorité sanitaire américaine, ndlr) reconnaît que les scanners médicaux basés sur l’IA sont aujourd’hui plus précis que les humains. Mais regarder ces scans, c’était la tâche. La finalité du métier, c’est d’interpréter le patient dans son ensemble, d’établir le plan de traitement, de se connecter avec lui, de travailler avec d’autres médecins. D’être médecin.

Il faut regarder chacun des rôles du service client et se demander : quelle est la tâche, quelle est la finalité ? Une fois qu’on a fait ça, on peut redéfinir les rôles. Oui, les tier 0 et tier 1 seront, dans la plupart des cas, automatisés. Mais vous aurez besoin de plus de tier 2 et tier 3, parce que les processus human in the loop ne disparaissent pas. Et comme je l’ai dit, automation drives escalation : c’est ensuite un humain qui prend la main. Les team leads deviennent un métier plus sophistiqué, parce qu’il faut gérer à la fois les agents humains et les agents IA. Quant aux rôles très spécialisés et très étroits, ils s’élargissent en un nouveau métier : l’AI Service Architect, quelqu’un qui pense à la fois à la connaissance, aux intégrations et aux procédures qui pilotent l’IA.

Dans les services agentiques, le travail principal devient former les agents IA pour les tâches sur lesquelles ils sont vraiment très bons. Pas celles qui demandent des humains.

Adrian McDermott, Chief Technology Officer, Zendesk

Chief Technology Officer de Zendesk depuis avril 2021, Adrian McDermott pilote la R&D produit, l’IA et la stratégie M&A de l’éditeur. Il a rejoint l’entreprise dès août 2010. Diplômé en informatique de De Montfort University (Royaume-Uni), il avait auparavant été CTO d’Attributor, VP Engineering chez BEA Systems et VP Platform Engineering chez Plumtree Software.