Chaque semaine, quelqu’un annonce que le RPA est mort et que les agents IA l’ont mis à la retraite. Bon titre, mauvaise décision d’architecture. Parce que celui qui tue le RPA par effet de mode finit par demander à l’agent de faire le travail de manœuvre —déplacer une donnée du système A au système B, mille fois, sans réfléchir— et c’est cher, lent et absurde. Et celui qui s’accroche au RPA par habitude lui demande de trancher sur une facture bizarre, et le bot se fige. La vraie question n’est pas lequel gagne. C’est quelle partie du travail fait chacun.
Agents IA vs RPA : le combat est mal posé
Le RPA (Robotic Process Automation) est un robot qui imite les clics et les frappes sur un écran. On lui enregistre les étapes et il les rejoue à l’identique, à toute vitesse, sans fatigue ni improvisation. Il est déterministe : même entrée, même sortie, toujours. Un agent IA, c’est autre chose : il lit du texte sans structure, comprend l’intention, décide dans certaines limites et s’adapte quand quelque chose change. L’un est le muscle. L’autre est le jugement. Les faire concourir, c’est comme demander ce qui vaut mieux, un tournevis ou un électricien : ils ont besoin l’un de l’autre.
La confusion vient du fait que les deux "automatisent", donc on les prend pour des substituts. Ils ne le sont pas. Ils automatisent des couches différentes du même processus. Et l’erreur qui coûte cher —celle qu’on voit sans cesse— c’est de mettre l’un à faire le travail de l’autre. Avant de décider quoi que ce soit, il faut savoir ce que veut vraiment dire automatiser un processus avec des agents, parce que la moitié des projets ratés n’échouent pas sur l’outil : ils échouent sur le mauvais partage des rôles.
Ce que le RPA fait bien (et pourquoi il n’est pas mort)
Le RPA brille là où le travail est répétitif, structuré et stable. Aucune nuance : règles fixes, zéro exception, le même écran tous les jours. Sur ce terrain, il est imbattable —bon marché, rapide, auditable— et aucun agent ne le dépassera, parce qu’il n’y a rien à raisonner. Cas où le RPA reste la bonne réponse :
- Déplacer des données entre systèmes qui ne se parlent pas par API : copier d’une feuille vers l’ERP, de l’ERP vers le portail de la banque, toujours pareil.
- Remplir des formulaires identiques à partir d’un modèle, en gros volume et complexité nulle.
- Générer des rapports programmés : extraire, coller, exporter, envoyer. Aucune décision au milieu.
- Rapprochements triviaux où la règle est « si le montant correspond, marque comme payé » et il n’y a pas de zone grise.
Le talon d’Achille du RPA est connu : il est fragile. Comme il travaille en imitant l’écran, le jour où quelqu’un déplace un bouton, renomme un champ ou que le fournisseur met à jour le portail, le bot casse et il faut le réparer à la main. Cette maintenance n’est pas anecdotique. Des synthèses de marché citant Deloitte estiment que la maintenance engloutit entre 70 % et 75 % du budget RPA (Neomanex, 2025). Ce n’est pas une raison pour le jeter : c’est une raison pour ne pas lui demander ce qu’il ne sait pas faire.
Ce que l’agent fait bien (et là où le RPA casse)
L’agent intervient précisément là où le RPA se fige : quand il faut lire quelque chose sans format, comprendre le contexte et décider. Il ne suit pas un script enregistré ; il interprète. C’est pourquoi il encaisse l’exception, le courriel mal écrit, la facture avec l’intitulé à un endroit bizarre. Terrain de l’agent :
- Données sans structure : courriels, PDF, contrats, chats. L’agent lit et extrait l’essentiel même si chaque document arrive différemment.
- Exceptions avec jugement : un écart sur une facture, une commande bizarre, un cas qui ne rentre pas dans la règle. L’agent raisonne dans ses limites au lieu de se figer.
- Coordonner plusieurs systèmes par leur sens, pas par leur écran : il croise CRM, ERP et boîte de réception en comprenant ce qu’est chaque chose.
- Classer et prioriser quand la réponse n’est pas dans un tableau : tri des tickets, routage des leads, catégories qui dépendent du contexte.
L’agent a aussi son prix : il coûte plus par opération qu’un bot, il faut lui poser des garde-fous et une supervision, et on ne veut pas qu’il décide seul sur des choses sensibles dès le premier jour. En monter un qui tienne en production —pas une démo— est un métier, et on le détaille dans comment on crée un agent IA qui marche vraiment. La règle : n’utilise pas un agent pour ce qu’une règle fixe résout déjà. C’est comme embaucher un avocat pour faire des photocopies.
| Dimension | RPA | Agent IA |
|---|---|---|
| Comment il travaille | Imite clics et frappes sur un écran | Lit, raisonne et décide sur le sens |
| Type de donnée | Structuré seulement (tableaux, champs fixes) | Structuré + sans structure (courriels, PDF, chats) |
| Exceptions | Se fige et escalade à un humain | Raisonne dans ses limites |
| Quand l’écran change | Casse, il faut le réparer | S’adapte par le contexte |
| Coût par opération | Très bas | Plus élevé |
| Son terrain | Répétitif, stable, sans zone grise | Complexe, avec exceptions, multi-système |
Le schéma qui gagne en 2026 : l’hybride
Voici la thèse, et elle va à contre-courant du titre facile : ne choisis pas de camp, combine-les. Le schéma rentable, ce n’est pas « l’agent à la place du RPA » ni « le RPA de toujours ». C’est l’hybride, avec un partage propre : l’agent lit et décide, le RPA exécute le répétitif. Le jugement en haut, le muscle en bas. Chacun faisant ce qu’il fait pour pas cher et bien.
Un exemple qui se comprend tout seul : extraire les données d’une facture et les intégrer dans ton système. La facture arrive en PDF, chaque fournisseur la met en page à sa façon, parfois il manque un champ ou la TVA est mal placée —ça, c’est de la lecture et du jugement, terrain de l’agent—. Une fois que l’agent a compris et validé les données, les saisir dans l’ERP champ par champ, mille fois pareil, c’est du muscle répétitif pur —terrain du RPA ou d’une intégration par API—. L’agent fait la partie qui pense ; le bot fait la partie qui sue. L’agent ne gaspille pas de tokens à taper, et le bot ne se fige pas sur un PDF bizarre.
Comment décider dans ton cas, sans acheter du vent
Tu n’as pas besoin d’un comité pour choisir. Tu dois regarder le processus et répondre à ces questions dans l’ordre :
- Les données arrivent-elles rangées ou en vrac ? Si tout arrive en tableaux propres et stables, commence par le RPA. Si ça arrive en courriels, PDF et pièces jointes, il te faut un agent qui lit.
- Y a-t-il des exceptions qui demandent de décider ? Si le processus est « toujours pareil, sans zone grise », c’est du RPA. S’il y a souvent un « ça dépend », c’est un agent.
- L’écran ou le format changent-ils souvent ? Si le portail se met à jour tout le temps, un bot vivra cassé ; là l’agent revient moins cher à la longue même s’il coûte plus par opération.
- Peux-tu couper le processus en deux couches ? Presque toujours oui : le bout qui pense et le bout qui répète. C’est le moment hybride, et c’est souvent la bonne réponse.
Et un avertissement pour ne pas trébucher sur l’habituel : l’outil n’est pas le projet. Choisir agent ou RPA, c’est 10 % du travail ; les 90 % restants, c’est comprendre le processus, lui poser des limites et le laisser tourner avec quelque chose qui se mesure. Ça, c’est de l’automatisation des opérations sur ce que tu as déjà, pas un achat de technologie. Celui qui te vend des « agents » sans t’interroger sur ton processus te vend l’étiquette à la mode, comme il te vendait avant du « RPA » sans regarder. La mode change ; le métier de bien partager le travail, non.