Le RPA et un agent AI diffèrent sur un seul point : qui choisit le chemin d’exécution, et quand. Avec le RPA, un humain choisit le chemin au moment de la construction et le logiciel le rejoue à l’identique indéfiniment. Avec un agent AI, le modèle choisit le chemin à l’exécution, à partir d’un objectif que vous avez formulé. Le modèle de coût, le mode de défaillance, la piste d’audit et la tolérance au changement découlent tous de cette seule différence — c’est pourquoi « lequel est meilleur » est la mauvaise question, et « cette tâche contient-elle des décisions » la bonne.
Un agent AI n’est pas un bot RPA plus intelligent, et le RPA n’est pas un agent obsolète. Le RPA n’est pas non plus de l’AI sous quelque forme que ce soit : un robot classique ne contient aucun modèle. C’est un script lié à des sélecteurs d’UI, des XPaths et des object IDs sur les écrans d’applications que vous possédez déjà, plus des appels API là où l’éditeur les a exposés. Il clique là où vous lui avez dit de cliquer. Un agent, à l’inverse, n’a aucun chemin fixe à rejouer — ce qui signifie qu’il peut traiter un cas que vous n’aviez pas anticipé, et aussi faire quelque chose que vous n’aviez jamais autorisé.
Ce qui découle de cette seule différence
La tolérance au changement va dans des directions opposées. Le RPA casse quand l’écran change : l’éditeur publie une release, un nom de classe change, le sélecteur ne résout plus, le robot s’arrête. Les agents survivent à ce même changement d’UI et dérivent à la place — le modèle lit le nouvel écran, décide quelque chose de plausible et continue dans une direction que personne n’a relue. Vous choisissez entre un système qui casse visiblement et un système qui plie invisiblement.
Les modes de défaillance sont inversés, et la conception du QA aussi. Un robot cassé lève une exception et atterrit dans une file ; vous l’apprenez parce que le nombre d’exécutions est tombé à zéro. Un agent qui échoue produit un résultat complet, bien formé, assuré et faux, puis signale un succès. La supervision d’uptime attrape le premier et est aveugle au second. Si vous déplacez un processus du RPA vers un agent en gardant la même supervision, vous n’avez pas migré le processus — vous avez retiré l’alarme.
L’unité de facturation passe de la capacité à la consommation. Un robot RPA se licencie comme un siège de capacité : vous louez le travailleur, puis vous le faites tourner autant que vous voulez. Un agent est facturé à ce qu’il consomme, donc une tâche devenue plus complexe devient plus chère sans que personne ne touche à une licence. La variance budgétaire passe de zéro à illimitée, sauf si vous la plafonnez.
La piste d’audit doit être reconstruite. Un script RPA est sa propre piste d’audit — le rejeu déterministe signifie que le code documente exactement ce qui s’est passé à chaque exécution, et c’est précisément pour cela que les processus back-office réglementés se sont standardisés dessus. Les actions d’un agent ne sont reconstituables que si l’éditeur journalise le raisonnement à côté des actions. Les journaux d’actions seuls vous disent ce qui a changé, pas pourquoi, et « le modèle a décidé » ne survit pas à un audit.
L’arithmétique du coût
Microsoft publie les deux côtés de cet arbitrage sur une même grille tarifaire, ce qui en fait la comparaison la plus propre disponible. Vérifié le 2026-07-26 : Power Automate Premium coûte $15 par utilisateur/mois et inclut les desktop flows attended ; Power Automate Process coûte $150 par bot/mois pour les desktop flows unattended ; Power Automate Hosted Process coûte $215 par bot/mois avec une VM gérée par Microsoft. Copilot Studio coûte $200/mois pour 25 000 crédits. UiPath publie un palier d’entrée Automation Cloud à partir de $25/mois et chiffre les robots unattended sur demande.
La licence du bot unattended est fixe, donc son coût par exécution vaut simplement $150 divisé par votre nombre mensuel d’exécutions :
- 100 exécutions/mois → $1,50 par exécution
- 1 000 exécutions/mois → $0,15 par exécution
- 10 000 exécutions/mois → $0,015 par exécution
Mesurez donc le coût réel par exécution de votre agent sur un échantillon de cas réels — appelons-le C — et le bot l’emporte au-delà d’environ 150 / C exécutions par mois. Un agent dont l’exécution coûte $0,15 atteint le seuil de rentabilité à 1 000 exécutions/mois ; un agent à $0,50 l’atteint à 300. Sous ces volumes, la licence fixe du bot est l’option chère et la flexibilité de l’agent est quasi gratuite. Bien au-dessus, faire redériver par un modèle le même chemin déterministe des milliers de fois par mois revient à payer à l’exécution une décision déjà prise.
Comment décider
Classez la tâche sur deux axes : à quel point le chemin varie, et à quelle fréquence il s’exécute.
- Faible variance, fort volume (saisie de factures, synchronisation de statuts, assemblage de rapports) : RPA, ou mieux, une intégration API. N’achetez pas du jugement pour une tâche qui n’en contient aucun.
- Forte variance, volume faible à modéré (traitement des exceptions, tri de contrats, recherche inbound) : agent. La file d’exceptions est le coût que vous attaquez réellement.
- Forte variance, fort volume : l’agent décide, le robot ou l’API exécute. C’est le motif composé décrit plus bas.
- Faible variance, faible volume : ni l’un ni l’autre. Un humain qui le fait 20 fois par mois coûte moins cher que l’une ou l’autre licence.
L’option que les éditeurs des deux camps escamotent : si le système cible dispose d’une API documentée, la couche UI est un contournement d’une intégration que vous pourriez simplement construire. Le RPA existe en grande partie parce que les logiciels d’entreprise ont été livrés sans API. Cherchez-en une avant de louer un robot pour taper dans un formulaire — et avant de louer un modèle pour faire la même chose plus cher.
Ils se composent plus qu’ils ne s’affrontent
La position des éditeurs des deux côtés en 2026 est la composition, pas le remplacement. UiPath présente sa plateforme comme des agents, des robots et des personnes coordonnés par une couche d’orchestration nommée Maestro, avec Agent Builder et Autopilot, et résume la division du travail ainsi : les agents pensent, les robots font, les personnes dirigent. Automation Anywhere vend un système d’Agentic Process Automation qui orchestre ensemble des agents pilotés par objectif, des bots RPA, des API et des validations humaines, et est resté Leader au Gartner Magic Quadrant for RPA 2026.
Lisez cela comme un motif de conception plutôt que comme du marketing : le modèle est bon pour décider ce qui doit arriver à un cas donné et mauvais pour exécuter les mêmes frappes de façon fiable 10 000 fois ; le robot fait l’inverse. Mettez le jugement dans l’agent, la répétition dans le robot ou l’API, et la porte de validation entre les deux.
Questions de diagnostic à poser à un éditeur
Elles séparent un vrai agent d’un produit RPA avec un modèle de langage devant — un jeu distinct de celui de AI agent pour les ops, qui teste l’autonomie en général plutôt que la décision de migration.
- Le chemin d’exécution est-il figé à la construction ou choisi à l’exécution ? C’est toute la question. Le reste est du détail.
- Lancez deux fois le même input — est-ce que j’obtiens le même chemin ? Des chemins identiques signifient que vous achetez du RPA. C’est un achat légitime, au prix du RPA.
- Pilote-t-il l’UI ou l’API ? Les produits qui pilotent l’UI héritent du profil de casse du RPA, quoi que fasse le modèle.
- Quelle est l’unité de facturation — bot, exécution ou token ? La réponse indique quel budget absorbe un processus qui se complexifie.
- Quand l’application cible livre un changement d’UI, qu’est-ce qui casse et qui le répare ? « Rien ne casse » n’est pas une réponse ; demandez ce que fait le modèle quand l’écran ne correspond plus.
Pièges courants
Remplacer un RPA qui fonctionne parce que le RPA fait daté. Un robot qui exécute depuis trois ans un processus stable, à fort volume et sans jugement n’est pas de la dette technique. Le migrer achète de la variance et un coût par exécution plus élevé.
Garde-fou : Ne migrez que les processus où la file d’exceptions — et non le chemin nominal — absorbe le travail. Si les exceptions représentent moins de 5% du volume, laissez le robot tranquille.
Traiter la flexibilité de l’agent comme gratuite. La flexibilité se facture à l’exécution, et les cas complexes coûtent plus cher que les cas simples : la facture croît donc exactement avec les cas pour lesquels vous avez adopté l’agent.
Garde-fou : Fixez un plafond de coût ferme par tâche dans la plateforme avant la mise en production, et remesurez le coût par exécution sur du trafic réel après 30 jours, pas sur l’échantillon de la démo.
Conserver la supervision de l’ère RPA après la bascule. Les tableaux de bord de nombre d’exécutions et d’uptime signalent un agent qui hallucine comme parfaitement sain.
Garde-fou : Remplacez les contrôles d’uptime par une revue échantillonnée des sorties — un pourcentage fixe d’exécutions terminées lues chaque semaine par un humain — plus un taux de reprise mesurant la fréquence à laquelle un humain a défait ce que l’agent a fait.
Perdre la piste d’audit déterministe sur un processus réglementé. Les processus Legal Ops et TA couverts par NYC LL 144, l’EU AI Act ou des contrôles SOX internes doivent montrer ce qui a été décidé et pourquoi.
Garde-fou : Exigez des enregistrements de décision structurés — entrées consultées, règle appliquée, ce qui a été escaladé — avant la bascule, et gardez le robot déterministe sur le segment réglementé du processus pendant que l’agent gère la réception et le tri autour.
Rubriques associées
- AI agent pour les ops — ce qui qualifie un agent, et les tests d’autonomie à faire passer à tout éditeur qui en revendique un
- Le serveur MCP expliqué — l’alternative côté API au pilotage d’une UI, et comment les agents se connectent aux systèmes sans sélecteurs
- n8n et Make — la couche workflow vers laquelle la plupart des équipes ops se tournent avant le RPA ou les agents
- GTM engineering — la discipline qui porte cette décision construire-ou-louer en RevOps