Dans Zendesk, Claude arrive sous forme d’actions dans des flux automatisés. Personne n’est là au moment où le flux tourne. La sortie peut donc partir au client sans qu’un humain la relise.
Les deux sections qui suivent viennent de la page d’aide de Zendesk. Modifiée le 1er mai 2026, relevée le 13 septembre 2026. Le reste est notre lecture.
Ce que Zendesk met à disposition
Un administrateur relie le constructeur d’actions à Claude. Les flux d’action appellent ensuite le modèle. Zendesk appelle actions externes les étapes d’un flux qui parlent à un système extérieur.
Les tâches citées : envoyer une consigne, résumer un texte, analyser le sentiment, extraire des mots-clés.
Ce sont des briques. Vous les assemblez dans un flux, et c’est l’assemblage qui décide du comportement.
Le choix du modèle
Au 13 septembre 2026, la page propose trois modèles au choix, avec ses propres libellés.
Claude Opus 4.6 pour le raisonnement complexe. Claude Sonnet 4.6 pour l’équilibre entre performance et vitesse. Claude Haiku 4.5 pour les tâches simples et les gros volumes.
Ces libellés peuvent changer. La page d’aide fait foi pour votre compte.
Pourquoi le support client est un cas à part
Sur un CRM, une erreur reste interne et quelqu’un la corrige. Sur un espace de documentation, un collègue la repère.
Ici, la sortie part au client.
C’est ce qui déplace la question. Le branchement est un travail d’administrateur. Décider à quel moment un flux répond seul prend une réunion avec les gens qui répondent aujourd’hui.
Nos quatre paliers d’autonomie, dans l’ordre
Ces quatre paliers sont notre découpage, pas une structure publiée par Zendesk. Il faut les monter un par un.
Palier un, rien ne sort. Résumer un ticket pour l’agent qui le prend. Proposer une catégorie. Extraire les mots-clés pour le routage. L’agent voit, décide, répond lui-même.
Palier deux, une aide à la décision. Détecter un client mécontent pour l’escalader plus vite. Là encore, personne ne reçoit rien d’automatique.
Palier trois, une proposition de réponse. Le flux rédige, l’agent relit et envoie. C’est le palier où le gain de temps devient visible. C’est aussi le dernier où un humain valide avant l’envoi.
Palier quatre, la réponse part seule. À réserver à des cas fermés, définis à l’avance, où la réponse est toujours la même. Un accusé de réception, un renvoi vers une procédure connue.
La plupart des équipes ont intérêt à rester longtemps au palier trois.
Ce qui se décide avant de brancher
Trois décisions se prennent avant le branchement, et elles s’écrivent.
Quels types de tickets peuvent recevoir une réponse automatique, nommés précisément. Ce qu’un flux ne traite jamais seul, par exemple une réclamation ou un litige de facturation. Et comment un client demande un humain, en une action évidente pour lui.
Zendesk recommande par ailleurs un compte de service dédié pour la gestion des clés d’API. C’est une bonne pratique standard, et elle évite qu’une clé disparaisse avec le compte de quelqu’un.
Ce que l’équipe doit savoir faire
Aucune des deux compétences utiles ici n’est technique.
Écrire la consigne qui cadre un flux. Ça suppose de savoir décrire le ton de vos réponses. Et ce qu’on ne promet jamais à un client.
Et relire une proposition de réponse en repérant ce qui cloche. Une réponse générée est polie et bien construite. Elle est donc plus difficile à corriger qu’une réponse maladroite.
C’est l’objet de la formation IA pour la relation client, qui se fait sur vos vrais tickets. Les usages du métier, indépendamment de l’outil, sont dans notre article sur l’IA au service client.
Le cadre écrit
Un flux qui parle aux clients mérite une ligne dans votre charte d’usage. Elle dit les paliers autorisés, et qui peut les changer. La trame est dans notre article sur la charte IA en entreprise.