La RPA automatise une tâche en pilotant les écrans qu'une personne utiliserait : elle se connecte avec son propre compte, trouve le bouton par un sélecteur ou sa position, saisit dans le champ et clique sur Enregistrer. Un agent IA automatise la même tâche en appelant un outil que le système expose pour les appels machine, avec un nom, une entrée saisie et une vérification de permission derrière. La différence réside dans l'interface, et l'interface décide comment l'automatisation se comporte lorsque quelque chose change.
La RPA reste le bon choix lorsque le système n'a aucune interface pour les machines : une application de bureau héritée, un émulateur de terminal, un portail fournisseur que vous ne contrôlez pas. Lorsqu'un système expose ses actions comme des outils, un agent qui les appelle est moins fragile, agit sous les permissions de la personne qu'il représente et peut gérer des variations pour lesquelles un bot devrait être scripté. Les fournisseurs de RPA eux-mêmes décrivent désormais les robots comme une couche d'exécution que les agents appellent, ce qui est l'image exacte.
Ce que fait réellement un bot
Commencez par l'architecture, car la comparaison entre les agents IA et la RPA est déterminée par celle-ci. UiPath, le plus grand fournisseur de RPA, décrit ses robots logiciels comme "imitant les actions humaines dans l'interaction avec les écrans et les systèmes" pour gérer "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". Les flux de bureau de Microsoft, son produit RPA intégré à Power Automate, disent la même chose en termes mécaniques : vous pouvez "interagir avec la machine en utilisant des éléments d'interface utilisateur d'application, des images ou des coordonnées", contre "des applications héritées, telles que des émulateurs de terminal, des applications web et de bureau modernes, des fichiers Excel et des dossiers". Un bot peut fonctionner en présence d'un utilisateur, aux côtés d'une personne au bureau, ou de manière autonome, sur une machine qui lui est propre.
Prenez une tâche concrète : enregistrer un bon de réception dans un ancien système de stock qui n'a pas d'API. Le bot ouvre l'application, navigue dans le menu jusqu'au formulaire des réceptions, recherche le bon de commande, passe dans le champ de quantité pour chaque ligne, saisit le nombre et appuie sur la touche Enregistrer. Une personne a enregistré ces étapes une fois ; le bot les rejoue des milliers de fois, plus rapidement et sans transposer les chiffres. Pour une application stable avec un volume élevé et aucun autre moyen d'accès, c'est un bon compromis, et cela s'est rentabilisé dans de nombreuses équipes financières et opérationnelles.
Les fournisseurs indiquent où cela s'intègre, et ils ont raison. Le propre cadre d'UiPath est "des tâches répétitives, basées sur des règles et à fort volume, en particulier celles qui s'étendent sur plusieurs systèmes" : volume, déterminisme et accès à des systèmes qui n'offrent rien d'autre. Une comparaison honnête garde ces éléments sur la table.
Pourquoi cela échoue, et pourquoi ce n'est pas un défaut
Un écran est un contrat avec une personne. Sa mise en page, ses étiquettes, l'ordre des onglets et la position du bouton Enregistrer sont des promesses faites aux yeux et à un pointeur, et aucune d'elles n'est promise à une machine. Lorsque le fournisseur déplace le champ de quantité dans un nouvel onglet, ajoute une fenêtre contextuelle de confirmation ou renomme un menu, la personne s'adapte en quelques secondes sans s'en rendre compte. Le bot échoue, ou pire, saisit la quantité dans le mauvais champ et enregistre. Cet échec ne dit rien sur la compétence du fournisseur RPA ; l'interface qui a été donnée au bot se révèle.
La même limitation s'applique à un modèle linguistique lorsqu'il est utilisé pour piloter des écrans. L'utilisation de l'ordinateur d'Anthropic donne à Claude "contrôle d'écran, de souris et de clavier d'un environnement de bureau", et c'est réellement utile là où rien d'autre n'existe. Mais la documentation d'Anthropic vous éloigne de cela chaque fois qu'une interface plus étroite est disponible, recommandant son outil de navigateur pour le travail qui reste à l'intérieur d'une page web, et demande "qu'un humain confirme des décisions qui pourraient avoir des conséquences réelles significatives", nommant parmi elles les transactions financières. Un modèle pilotant un écran hérite de la fragilité de l'écran et ajoute sa propre variabilité par-dessus. C'est la combinaison la moins attrayante des deux catégories, et c'est ce que beaucoup de propositions de "RPA alimentée par l'IA" représentent.
Ce qu'un agent appelle à la place
Un agent qui opère un système commercial conçu pour des agents ne voit jamais un écran. Il demande au système ce qu'il peut faire et reçoit une liste d'outils, chacun avec un nom, une description écrite pour le modèle, un schéma pour ses entrées, et des annotations optionnelles qui indiquent s'il ne fait que lire, s'il peut détruire des données, et si l'appel à deux reprises est sûr. Le Model Context Protocol standardise cet échange : le client envoie une demande pour lister les outils, le modèle en choisit un, le client l'appelle avec des arguments typés, et le serveur l'exécute et renvoie un résultat. La spécification exige que les serveurs "valident toutes les entrées des outils" et "mettent en œuvre des contrôles d'accès appropriés", et dit aux clients de "journaliser l'utilisation des outils à des fins d'audit". Voici la forme d'un tel outil, utilisant le bon de réception mentionné précédemment.
{
"name": "receiveStock",
"description": "Book goods received against a purchase order into a warehouse location. Fails if the order is closed or the caller cannot receive at that location.",
"inputSchema": {
"type": "object",
"properties": {
"order_ref": { "type": "string", "description": "Purchase order reference" },
"location_id": { "type": "string", "description": "Warehouse location to receive into" },
"lines": {
"type": "array",
"items": {
"type": "object",
"properties": {
"sku": { "type": "string" },
"quantity": { "type": "integer", "minimum": 1 }
},
"required": ["sku", "quantity"]
}
}
},
"required": ["order_ref", "lines"]
},
"annotations": { "readOnlyHint": false, "destructiveHint": false, "idempotentHint": false }
}Une définition d'outil MCP dans la forme que décrit la spécification, pour le même bon de réception dans lequel le bot était en train de taper dans un formulaire. Les noms des champs sont illustratifs ; l'idée est qu'un outil est un contrat, et un contrat peut être versionné, validé et autorisé de manières qu'un écran ne peut pas.
Comparez ce qui se passe lors d'un changement. Le fournisseur redessine l'écran des reçus : le bot échoue, l'outil reste intact. Le fournisseur ajoute un champ requis à l'outil : c'est un changement versionné d'un contrat publié, annoncé dans la liste des outils, et l'agent lit le nouveau schéma lors de son prochain appel. Comparez l'identité. Le bot se connecte en tant que compte de service avec l'accès que quelqu'un lui a donné il y a des années. L'agent appelle l'outil en tant que personne qu'il représente, et la vérification des autorisations s'exécute à l'intérieur de l'outil, à chaque appel, par rapport au rôle de cette personne.
Déterministe contre probabiliste : le compromis que personne ne devrait cacher
Il y a un coût du côté de l'agent, et les fournisseurs RPA l'indiquent avec précision dans leur propre documentation pour agents : les robots "suivent une logique structurée et des règles fixes", tandis que les agents adoptent "une approche probabiliste pour prendre des décisions basées sur des modèles et des données en temps réel". Un bot qui rejoue les mêmes étapes donne le même résultat pour la même entrée, et cela peut être prouvé. Un agent ayant la même intention emprunte un chemin défendable, généralement le même, mais pas toujours. Pour une étape réglementée où la répétabilité doit être démontrée, ou pour un million de transactions identiques par mois, l'option déterministe est le meilleur choix, et dire le contraire serait trompeur.
L'avantage de l'agent est limité à la variation. Lorsque le bon ne correspond pas à la commande, lorsque le fournisseur a envoyé deux livraisons contre une seule ligne, lorsque la quantité est plausible mais que l'unité est incorrecte, le bot n'a pas de branche pour cela et s'arrête, ou fait la mauvaise chose avec confiance. L'agent lit la divergence, vérifie la commande, réserve ce qui correspond, et demande à une personne pour le reste. C'est le travail qui était autrefois une file d'attente d'exceptions sur le bureau de quelqu'un, et c'est le travail pour lequel un agent est conçu.
Optez pour la RPA quand, optez pour un agent quand
| Question | Optez pour RPA | Optez pour un agent |
|---|---|---|
| Le système expose-t-il des actions aux machines ? | Non : uniquement des écrans, une application de bureau héritée, un terminal | Oui : une API ou un serveur MCP avec des outils typés |
| Contrôlez-vous le système ? | Non, et cela ne changera pas pour vous | Oui, ou le fournisseur publie et versionne ses outils |
| Dans quelle mesure la tâche varie-t-elle ? | Très peu : les mêmes champs dans le même ordre | Chaque cas nécessite une lecture et un jugement |
| L'entrée doit-elle toujours donner la même sortie ? | Oui, et vous devez être en mesure de le prouver | Un résultat défendable avec un journal complet suffit |
| Qui représente-t-il ? | Un compte de service avec son propre identifiant | La personne qu'il représente, sous ses autorisations |
| Qu'est-ce qui le casse ? | Un champ déplacé, un menu renommé, un pop-up inattendu | Un contrat d'outil modifié, qui est versionné et annoncé |
| Volume et coût par exécution | Volume très élevé à coût quasi nul par exécution | Volume modéré avec un appel de modèle par exécution |
| Où vont les exceptions | À une personne, en tant qu'exécution échouée | L'agent réconcilie ce qu'il peut et demande le reste |
La première ligne décide de la plupart des cas. Tout le reste dans le tableau découle du fait que le système a été conçu avec un appel machine à l'esprit.
Utiliser les deux, et ce que le système sous-jacent décide
Le modèle que les fournisseurs décrivent maintenant, et celui qui fonctionne en pratique, est que l'agent décide et le bot exécute sur des systèmes qui n'ont rien d'autre. UiPath le formule ainsi : les robots jouent "un rôle complémentaire dans la pile d'exécution" aux côtés des agents. Dans cet arrangement, le bot est l'un des outils de l'agent : une action déterministe encapsulée contre un écran hérité, l'agent étant responsable de choisir quand l'appeler et de gérer ce que le bot retourne. Au fil du temps, les bots se retirent un par un à mesure que les systèmes derrière eux acquièrent leurs propres outils, et rien du côté de l'agent n'a besoin de changer lorsqu'ils le font.
Ce qui ramène la décision au système d'affaires. Sois est conçu de manière à ce que le bot ne soit jamais nécessaire contre lui : un espace de travail est un serveur MCP, chaque action qu'une personne peut entreprendre est exposée comme un outil nommé, et l'agent que vous utilisez déjà, Claude, ChatGPT ou tout client MCP, se connecte en ajoutant l'adresse de l'espace de travail et en se connectant une fois. Les outils sont filtrés par le rôle de la personne avant que l'agent ne les voie et vérifiés à nouveau lorsqu'ils s'exécutent, donc l'accès échoue en mode fermé ; les dépenses sont plafonnées par intégration ; chaque appel est enregistré avec ses entrées et son résultat. Là où vous exécutez encore un système hérité à côté, le bot reste sur ce système et l'agent le considère comme un outil de plus.
Si votre système principal n'a que des écrans, la RPA est le pont et il n'y a pas de honte à cela. La décision qui compte est de savoir si le prochain système que vous achèterez en aura besoin.
Questions que les gens posent
La RPA est-elle obsolète maintenant que des agents IA existent ?
Non. Pour un travail à volume élevé basé sur des règles contre des systèmes qui n'exposent rien d'autre qu'un écran, un bot reste l'option déterministe la moins chère, et les fournisseurs de RPA positionnent maintenant leurs robots comme la couche d'exécution sur laquelle les agents s'appellent. Ce qui a changé, c'est que les systèmes construits avec des outils typés n'ont plus du tout besoin d'un bot.
Un agent IA peut-il contrôler un écran comme le fait un bot RPA ?
Oui. L'utilisation de l'ordinateur par Anthropic donne à Claude le contrôle des captures d'écran, de la souris et du clavier, et c'est utile là où aucune interface plus étroite n'existe. Il hérite de la fragilité de l'écran et ajoute la variabilité du modèle, et les conseils d'Anthropic sont de préférer des outils plus étroits lorsque disponibles et de faire confirmer les actions conséquentes par une personne.
La RPA est-elle moins chère qu'un agent IA ?
Par exécution, généralement : un bot rejoue des étapes enregistrées à un coût marginal proche de zéro, tandis qu'un agent coûte un appel de modèle à chaque fois. La comparaison change lorsque vous comptez la maintenance que chaque changement d'écran impose au bot et les exceptions que le bot ne peut pas gérer, qui retombent toujours sur une personne.
Les bots RPA et les agents IA peuvent-ils travailler ensemble ?
Oui, et c'est le modèle que décrivent les fournisseurs. L'agent lit, décide et appelle des outils ; là où un système n'a pas d'outils, un bot encapsulé comme une action déterministe effectue l'exécution sur cet écran. À mesure que les systèmes acquièrent leurs propres outils, les bots se retirent sans changer l'agent.
- UiPath : qu'est-ce que l'automatisation des processus robotiques ? la définition propre du fournisseur de l'APR, les tâches qu'elle convient, et les robots comme une couche d'exécution complémentaire pour les agents
- Microsoft Learn : introduction aux flux de bureau APR dans Power Automate : éléments d'interface utilisateur, images ou coordonnées, pour les applications héritées et modernes
- Anthropic : outil d'utilisation de l'ordinateur contrôle d'écran pour Claude, ses limites déclarées, et les conseils pour confirmer les actions conséquentes
- spécification du Protocole de Contexte de Modèle : outils définitions des outils, annotations, découverte et messages d'appel, et les exigences de sécurité sur les serveurs et les clients
Cet article est révisé lorsque les produits qu'il décrit changent. Prochaine révision prévue : 4 décembre 2026.