RPA en centre d'appels : ce qu'il automatise et où il échoue

Ce qu'est vraiment le RPA en centre d'appels

J'ai passé ces dernières années à construire des agents IA qui opèrent sur des files d'attente de support en direct, et la première chose que je dirai, c'est que le RPA a gagné sa réputation honnêtement. Il fait quelque chose de réel.

L'automatisation robotisée des processus est, selon les propres termes des fournisseurs, des robots logiciels qui imitent les actions humaines dans les systèmes numériques pour exécuter des "tâches répétitives et basées sur des règles comme la saisie de données, le déplacement de fichiers ou le traitement de transactions". Le bot fait littéralement ce qu'un agent ferait avec une souris et un clavier, en cliquant dans les mêmes écrans, mais plus vite et sans se lasser. Automation Anywhere présente les choses de la même façon : le RPA est "les bras et les jambes" de l'automatisation, l'exécution fiable d'étapes structurées et répétables.

La raison pour laquelle il convient à un centre d'appels est qu'une grande partie du travail d'un centre de contact est réellement codifiable et répétitive. Quand un chef d'équipe passe sa matinée à copier des champs de tickets dans un outil de facturation, c'est une règle qu'on peut écrire, et tout ce qu'on peut écrire comme règle, un bot peut l'exécuter.

Il existe deux variantes qu'il vaut la peine de connaître, car elles correspondent à des tâches différentes sur le terrain :

• Le RPA non supervisé fonctionne seul, selon un calendrier ou un déclencheur, sans qu'aucun humain ne surveille. Automation Anywhere l'oriente vers des processus de back-office comme la saisie massive de données et les intégrations système. Pensez au traitement par lots nocturne.
• Le RPA supervisé accompagne un agent en direct, intervenant en plein appel pour remplir un formulaire ou extraire un enregistrement. Le fournisseur nomme explicitement cette catégorie pour le travail de service client et de helpdesk informatique, avec un humain dans la boucle. C'est le bot classique du "bureau de l'agent".

Aucun des deux ne comprend quoi que ce soit. Ce n'est pas une critique, c'est la conception. Le RPA est déterministe par nature, c'est précisément pour cela qu'il est fiable et auditable, et précisément pour cela qu'il s'effondre dès que le travail cesse d'être déterministe.

Ce que le RPA en centre d'appels automatise bien

Voici où le RPA démontre vraiment sa valeur. La plupart de ces tâches sont peu reluisantes et grignotent silencieusement la journée d'un agent, et les confier à un bot est une vraie victoire.

Automation Anywhere liste exactement ces éléments dans ses cas d'usage pour le service client : traitement automatisé des demandes, ticketing et routage, et saisie de données d'intégration. Et les résultats, quand le processus est stable, sont réels. Leur étude de cas sur la ville de Seattle est concrète et parlante : la ville a résorbé un arriéré de plus de 6 000 demandes de programmes de services publics, automatisé 700 demandes quotidiennes de déblocage de mots de passe, et économisé plus de 30 heures par mois, le tout avec du RPA basé sur des règles avant même d'y ajouter une couche d'IA.

Si votre centre d'appels croule sous ce genre de tâches répétitives de back-office, le RPA est une réponse légitime, et il s'insère à côté du reste de votre flux de travail de service client sans grand drame. C'est la partie de l'histoire que les fournisseurs de RPA racontent bien, et ils n'ont pas tort.

Où le RPA en centre d'appels échoue

Passons maintenant à la partie que la brochure omet. Le modèle même du RPA, un bot qui fait semblant d'être un humain cliquant sur un écran, est aussi sa ligne de faille. J'ai vu des équipes essayer de lui faire porter la vraie file d'attente de support, et il a tendance à échouer de trois façons prévisibles.

Il est fragile. Le bot cible des boutons et des champs spécifiques sur une page. Change la mise en page, renomme un champ, ou déploie une mise à jour de l'interface, et l'automatisation casse. Les praticiens sur r/rpa le disent sans détour :

"UI automation is brittle, so we built an AI-based solution... that makes UI-based automation on websites extremely easy."

r/rpa, on constant UI changes breaking automations

La maintenance vous dévore vivant. Chaque bot fragile est un bot que quelqu'un doit surveiller. C'est la facture cachée, et les chiffres le confirment : dans l'enquête mondiale de Deloitte, seules les organisations avec 51 automatisations ou plus en production comptent comme des "scaleurs", et la plupart des programmes s'arrêtent bien avant. Un tiers des équipes utilisant l'automatisation en tant que service externalisent spécifiquement la gestion et la maintenance de leurs bots, car les maintenir en vie est un travail en soi. Comme le disait un fil r/automation, sans une ingénierie sérieuse derrière, "la charge de maintenance va vous dévorer vivant à moyen et long terme".

Il ne peut pas gérer le langage, les exceptions ou le jugement. C'est le gros problème pour un centre d'appels, car c'est le vrai travail. Au moment où un client reformule une question, joint un document inattendu, ou tombe sur un cas limite sans règle, le bot n'a plus rien. Même les fournisseurs de RPA l'admettent : sans IA, le RPA "ne peut fonctionner efficacement qu'avec des données structurées... cela limite l'efficacité du RPA et renvoie davantage d'exceptions aux travailleurs humains". Le consensus de la communauté est le même, et étonnamment juste à ce sujet :

"RPA thrives in rules based end to end process so it's more reliable for structured tasks, while agents thrive on processes having lots of nuances... Not everything needs an LLM to perform rules based decisions."

r/rpa, "RPA vs AI agents vs Agentic Process Automation"

Cette dernière citation est le cadrage honnête. Le RPA n'est pas mauvais, il est étroit. Et une file d'attente de support, c'est surtout ce contenu nuancé et conversationnel qui vit hors de sa voie, ce qui explique pourquoi ajouter encore du RPA aux tickets fait rarement bouger l'aiguille sur l'automatisation des tickets.

RPA contre agents IA : qui fait quoi

La version inutile de ce débat est "RPA contre IA, qui gagne". La version utile est : ils font des travaux différents, et les bonnes configurations utilisent les deux. Voici la répartition des tâches que je proposerais.

L'agent IA lit le message entrant, détermine ce que le client veut vraiment, et décide de la prochaine étape. Le bot RPA, si on en a encore besoin, effectue l'exécution déterministe : se connecter à l'ERP, déplacer les données, suivre les règles fixes. L'humain gère les véritables exceptions et garde un œil sur l'ensemble. UiPath décrit la même répartition : les agents analysent et décident, le RPA agit de façon fiable sur ces décisions, et les personnes assurent la supervision.

C'est pourquoi le cadrage est passé discrètement de "l'IA remplacera-t-elle le RPA" à "l'IA au-dessus, le RPA en dessous", et pourquoi les calculs de coût IA contre humain favorisent de plus en plus le fait de placer l'agent sur la conversation. La catégorie a grandi en trois étapes.

D'abord est venue la simple automatisation des tâches (le RPA des années 2010 que tout le monde imagine). Puis l'automatisation intelligente, qui a associé le RPA à l'apprentissage automatique et aux modèles de langage pour pouvoir lire des données non structurées comme des e-mails et des documents. Maintenant l'IA agentique, où l'agent se charge de comprendre et de décider, et le RPA devient la couche d'exécution qu'il appelle. Gartner a enregistré une hausse de 750 % des demandes clients concernant l'automatisation agentique rien qu'au second semestre 2024, ce qui indique où va la demande.

Pour un responsable support, la lecture pratique est simple. Si vous décidez comment automatiser une tâche donnée, demandez-vous de quel type de tâche il s'agit. Utilisez l'outil ci-dessous pour vérifier.

Où eesel s'intègre

C'est le niveau sur lequel je travaille réellement : le niveau conversationnel pour lequel le RPA n'a jamais été conçu. eesel AI est un agent IA pour le helpdesk qui lit le ticket ou le chat entrant, extrait la réponse de vos propres connaissances, et le résout, ou rédige une réponse qu'un agent enverra. C'est la moitié "l'IA décide" du tableau, et en tant qu'élément de l'IA dans le service client, il s'intègre dans le helpdesk que vous utilisez déjà plutôt que de vous demander de tout reconstruire.

Quelques éléments rendent cela différent du fait de diriger le RPA vers vos tickets :

• Il s'entraîne sur votre propre historique. eesel apprend de vos tickets passés, de votre centre d'aide et de vos macros, donc il répond avec votre propre voix dès le premier jour au lieu d'avoir besoin d'une règle écrite pour chaque scénario. C'est l'opposé du tapis roulant de maintenance dans lequel vous placent les scripts RPA.
• Vous pouvez simuler avant la mise en production. Ceci vient d'une cicatrice. Nous avons vu des bots à l'air confiant donner tranquillement de mauvaises réponses, donc eesel exécute une simulation sur vos tickets historiques et vous montre le taux de résolution et les réponses exactes avant qu'il ne touche un vrai client. Vous voyez comment il se comportera, puis vous l'activez pleinement.
• Il sait quand s'arrêter. La chose la plus courante que les acheteurs nous disent vouloir n'est pas l'automatisation totale, c'est le contrôle. Comme nous l'a dit un responsable support d'une marque DTC : "J'ai besoin d'une IA qui ne traite que les tickets pour lesquels elle est sûre d'elle, et qui laisse tous les autres tranquilles." eesel effectue une escalade et un transfert basés sur la confiance, il résout donc ce dont il est sûr et transmet proprement le reste.

Quand le processus est vraiment déterministe, eesel ne s'y oppose pas non plus : il déclenche le même type d'actions que le RPA le ferait (étiqueter, assigner, mettre à jour le statut, appeler une API) dans le cadre de la résolution d'un ticket. L'équipe de Gridwise, qui fonctionne sur Zendesk, a vu eesel résoudre 73 % de leurs demandes de niveau 1 dès le premier mois, et a noté que la plateforme "inclut même des automatisations pour l'étiquetage des tickets, l'assignation et les mises à jour de statut." C'est toute l'idée : l'IA sur la conversation, des actions déterministes sur l'exécution.

Cela répond aussi à la question "pourquoi ne pas simplement construire notre propre solution" que se posent beaucoup de centres d'appels très orientés ingénierie. L'équipe de GENERAL BYTES a résumé pourquoi ils ont acheté plutôt que construit : "Nous aurions pu essayer d'écrire notre propre application LLM, mais nous ne voulions pas y investir notre temps. Nous voulions quelque chose que nous n'aurions pas à maintenir." Ce point sur la maintenance est la même raison pour laquelle les scripts RPA deviennent coûteux, simplement à un niveau plus élevé.

Comment vraiment démarrer

Si vous pesez le pour et le contre du RPA en centre d'appels en ce moment, voici la séquence que je suivrais plutôt que de tout automatiser d'un coup.

1. Listez vos tâches et triez-les. Divisez la file d'attente entre le travail de back-office déterministe (saisie de données, extraction de rapports, mises à jour de statut) et le travail conversationnel (tout ce qu'un humain doit lire et interpréter). Le premier groupe est là où l'automatisation basée sur des règles a sa place ; le second est un travail pour le logiciel de service client IA.
2. Automatisez le stable et l'ennuyeux avec des règles. Pour des processus vraiment fixes, un bot basé sur des règles ou l'automatisation de workflow intégrée à votre helpdesk convient très bien, et c'est moins cher qu'un agent IA. Entrez simplement en sachant que vous devrez le maintenir quand les écrans changeront.
3. Placez un agent IA sur la conversation. Pour les tickets et chats qui nécessitent de la compréhension, utilisez un système de tickets IA qui lit l'intention et résout. C'est le niveau qui fait réellement bouger vos chiffres de résolution et de déviation de niveau 1, et où apparaissent les véritables économies de coûts de support.
4. Simulez, puis déployez progressivement. Testez sur de vrais tickets historiques avant la mise en production, démarrez l'IA sur les types de tickets où elle est la plus confiante, puis élargissez à partir de là. Ne basculez pas tout en automatique dès le premier jour.

L'erreur que je vois le plus souvent est de traiter cela comme un seul grand projet d'automatisation. Ce n'en est pas un. Ce sont deux tâches différentes, et les équipes qui gagnent utilisent le bon outil pour chacune.

Essayez eesel pour votre centre d'appels

Si votre file d'attente relève surtout du niveau conversationnel, c'est exactement à cela que sert eesel AI. C'est un agent IA qui s'intègre à votre helpdesk existant en quelques minutes, apprend de vos tickets passés et de votre base de connaissances, et résout la première ligne tout en transmettant proprement le reste à votre équipe. La partie qui a tendance à convaincre les gens : vous pouvez le simuler sur des tickets passés et voir le vrai taux de résolution avant même qu'un seul client ne lui parle, donc pas besoin de faire un pari à l'aveugle.

C'est gratuit à essayer, et vous pouvez le diriger vers votre helpdesk sans rien reconstruire. C'est tout l'argument : gardez le RPA pour la plomberie si vous l'avez, et laissez un agent IA prendre en charge les conversations pour lesquelles il n'a jamais été conçu.