Agents IA vs RPA : pourquoi les entreprises migrent en 2026

Pendant une décennie, le RPA a été l’outil de référence de l’automatisation en entreprise. UiPath, Blue Prism, Automation Anywhere : ces plateformes ont permis à des milliers d’entreprises d’automatiser la saisie de données, les réconciliations, la génération de rapports et des dizaines d’autres tâches répétitives. Le résultat a été réel et mesuré.

Pourtant, un problème persistant n’a jamais été résolu : dès qu’un processus s’écarte du chemin prévu, le bot s’arrête. Un champ déplacé dans une interface, un document PDF légèrement différent du template, une exception commerciale non anticipée : le robot plante, une alerte part, un humain intervient pour débloquer la situation. Cette fragilité structurelle devient insupportable à mesure que les volumes augmentent et que les processus se complexifient.

C’est précisément là que les agents IA autonomes changent la donne. Cet article analyse les forces et limites respectives de ces deux technologies, explique pourquoi la migration est en cours, et décrit comment la conduire de façon progressive et sans rupture.

Ce que le RPA fait bien et continuera de faire

Soyons honnêtes : le RPA a des mérites indéniables, et certains cas d’usage lui appartiennent encore.

La force du RPA est le déterminisme. Un robot RPA correctement configuré sur un processus stable exécute exactement la même séquence d’actions à chaque fois. Il n’interprète pas, il ne décide pas, il n’improvise pas. C’est une limitation, mais c’est aussi une garantie. Pour un auditeur ou un responsable conformité, un comportement parfaitement prévisible et loggé est une valeur réelle.

Les cas où le RPA excelle restent nombreux :

• Génération de rapports périodiques depuis des systèmes avec une interface stable (ERP, SIRH) : le robot ouvre, extrait, formate, envoie. Le taux d’erreur sur ce type de tâche est proche de zéro.
• Réconciliation comptable entre deux fichiers aux colonnes connues : aucune ambiguïté, aucune exception, règles de matching explicites.
• Migration de données en lot entre deux systèmes à schémas fixes : le RPA est plus rapide et plus fiable qu’un développement ETL léger.
• Formulaires de saisie structurés dans des applications legacy sans API : le RPA peut simuler des clics sur des interfaces graphiques que les agents IA ne peuvent pas toujours atteindre par des moyens programmatiques.

Ces cas représentent encore une part significative des automatisations en place. Les remplacer par des agents IA serait une perte de temps et d’argent.

Où le RPA montre ses limites

Trois situations rendent le RPA structurellement inadapté, et ce sont précisément celles qui consomment le plus de temps humain dans les entreprises.

La gestion des exceptions

Un processus métier réel contient des exceptions. Dans une chaîne de traitement des commandes, 80 % des commandes suivent le chemin nominal. Les 20 % restants contiennent une adresse invalide, une référence produit inconnue, une remise commerciale non standard, un conflit de stock. Le RPA traite les 80 % et échoue sur les 20 %. Un humain est rappelé pour chaque cas.

Un agent IA lit l’exception, comprend le contexte, consulte les règles métier disponibles, prend une décision motivée et exécute. Si l’exception sort de son périmètre de compétence, il escalade vers un humain avec un résumé structuré et une proposition. La proportion de cas nécessitant une intervention humaine tombe typiquement de 20 % à 2-3 %.

Le traitement de documents non structurés

Un flux d’emails entrants, des devis fournisseurs en PDF avec des formats variables, des comptes-rendus de réunion, des notes manuscrites numérisées : le RPA ne sait pas lire ces documents. Il peut extraire des données structurées depuis un formulaire connu, pas depuis un texte libre.

Les agents IA avec capacité de compréhension de documents (tous les modèles cités dans notre guide salarié IA) lisent, comprennent, extraient et structurent ces informations sans template préalable. Un agent chargé du traitement des bons de commande fournisseurs peut gérer simultanément des PDFs de 15 fournisseurs différents avec des structures radicalement différentes.

L’adaptation aux changements d’interface

Chaque mise à jour d’une application web peut casser les sélecteurs XPath ou CSS d’un robot RPA. Les équipes RPA passent une partie non négligeable de leur temps à maintenir les bots en condition opérationnelle après des updates d’interfaces. Certains clients citent 30 à 40 % du temps de l’équipe consacré à la maintenance pure.

Un agent IA qui passe par une API ne dépend pas de l’interface graphique. Et si l’API elle-même change, la gestion de version et la description de l’API au format MCP permettent à l’agent de s’adapter avec une modification de son outillage, pas de son comportement.

Tableau comparatif : agent IA vs RPA selon les critères clés

Critère	RPA	Agent IA autonome
Gestion des exceptions	Échec + intervention humaine	Traitement autonome dans le périmètre
Documents non structurés	Non	Oui (emails, PDFs, texte libre)
Adaptation au changement	Maintenance manuelle	Résilience via raisonnement
Prévisibilité comportement	Très élevée (déterministe)	Élevée (bornée par rules)
Coût de setup initial	Moyen à élevé	Variable selon voie de déploiement
Coût de maintenance	Élevé (mises à jour fréquentes)	Faible (pas de sélecteur à maintenir)
Intégration SI legacy	Excellent (simulation clics)	Nécessite API ou MCP
Souveraineté données	Dépend du cloud éditeur	Choix total (Voie 1/2/3)
Scalabilité	Linéaire (nombre de bots)	Élastique (tokens)
Capacité de raisonnement	Aucune	Élevée selon modèle

Pourquoi la migration s’accélère en 2026

Plusieurs facteurs convergent pour rendre la migration RPA → agents IA plus rationnelle qu’elle ne l’était en 2024.

Les licences RPA coûtent cher. UiPath Enterprise, Blue Prism Cloud et Automation Anywhere ont des coûts de licence annuels qui varient entre 10 000 et 50 000 euros par an selon le nombre de bots et les modules. Ces coûts sont fixes, indépendamment de l’utilisation réelle. Par contraste, un agent IA sur Claude Managed Agents ne coûte que lorsqu’il tourne : 0,08 dollar par heure de session active, plus les tokens consommés.

Les modèles de langage ont atteint un niveau de fiabilité production. Claude Sonnet 4.6 en Voie 1, Gemma 4 31B en Voie 2, Mistral Large 2 en Voie 3 : ces modèles sont capables de suivre des instructions complexes avec un taux de conformité suffisant pour des processus métiers bornés, à condition que le system prompt et les outils soient bien conçus.

L’outillage de déploiement s’est industrialisé. Le MCP (Model Context Protocol), les Claude Managed Agents, Ollama en production sur Scaleway : les composants nécessaires à déployer un agent IA en entreprise sont désormais matures et documentés. Il n’est plus nécessaire de développer des frameworks d’orchestration maison.

La stratégie de migration progressive

La bonne approche n’est pas de remplacer tout le parc RPA d’un coup. C’est d’identifier les segments où l’agent IA apporte le plus de valeur et de migrer par vagues.

Phase 1 : cartographie des processus automatisés

Avant de migrer quoi que ce soit, listez tous vos processus RPA actifs avec, pour chacun :

• Le taux d’exception (combien de fois par semaine un humain intervient-il ?)
• La stabilité de l’interface sous-jacente
• La présence ou non de documents non structurés dans le flux
• Le coût de maintenance mensuel en temps humain

Ce diagnostic SOP est l’étape zéro de toute migration réussie.

Phase 2 : sélection des candidats à la migration

Deux catégories sont prioritaires :

1. Les bots qui plantent régulièrement : chaque exception traitée par un humain est un coût caché. Ces processus sont les premiers candidats à remplacer par des agents IA capables de gérer les cas limites.

2. Les processus impliquant des documents non structurés : traitement d’emails entrants, extraction d’informations depuis des PDFs variés, interprétation de notes manuscrites numérisées. Le RPA ne peut pas gérer ça. L’agent IA si.

Phase 3 : cohabitation

Pendant la transition, les deux technologies peuvent cohabiter. Un processus hybride fréquent : le RPA gère la mécanique d’interaction avec un legacy system sans API (ouverture d’application, navigation dans les menus), et expose les données extraites à un agent IA via un fichier ou une queue. L’agent IA prend ensuite le relais pour le raisonnement, la décision et les actions sur les systèmes dotés d’APIs modernes.

Cette architecture permet de préserver les investissements RPA sur les parties où ils fonctionnent bien, tout en apportant la flexibilité des agents là où c’est nécessaire.

Phase 4 : décommissionnement progressif

À mesure que les agents IA prouvent leur valeur en production, les licences RPA peuvent être réduites. Le budget de licences économisé finance la supervision mensuelle des agents et le compute.

Les 5 processus les plus fréquemment migrés

Parmi les projets que nous avons accompagnés, cinq catégories de processus RPA font l’objet des migrations les plus fréquentes vers des agents IA :

1. Traitement des commandes entrants : lecture d’emails et de PDFs de commandes, vérification de stock, création d’entrées ERP, réponse au client. Le RPA plantait sur les PDFs non standards. L’agent IA traite tous les formats.

2. Qualification et routage de leads : lecture des formulaires entrants, enrichissement CRM, scoring, routage vers le bon commercial. Impossible avec du RPA pur sur des champs libres.

3. Réconciliation avec exceptions : la réconciliation de base reste RPA, mais l’identification et le traitement des lignes non réconciliées passe à un agent IA capable de chercher la cause de la divergence.

4. Synthèse de documents : compte-rendu de réunion, résumé de rapport annuel, fiche de synthèse d’un appel d’offres. La lecture compréhensive de documents longs est hors du périmètre RPA.

5. Support client de niveau 1 : classification et premier traitement des tickets entrants. Le RPA peut router un ticket selon un mot-clé exact. L’agent comprend l’intention, identifie la catégorie, consulte la base de connaissance et rédige une première réponse personnalisée.

Quelle voie de déploiement pour votre migration ?

Le choix entre les trois voies dépend de la nature des données traitées par vos processus actuels.

Si vos processus RPA ne traitent pas de données personnelles ou confidentielles sensibles (automatisation de reporting interne, production de statistiques, veille), la Voie 1 Agent Express Claude est la plus rapide et la moins coûteuse. Setup en quelques jours, zéro infrastructure à gérer.

Si vos processus RPA touchent des données de santé, des données financières réglementées ou des informations couvertes par le secret professionnel, la Voie 2 Agent Souverain Europe sur Scaleway ou OVHcloud est obligatoire. Toutes les données restent en France, aucun transfert vers des serveurs américains.

Si vous traitez des données classifiées ou si votre conformité exige une architecture air-gapped, la Voie 3 On-Prem sur votre propre infrastructure avec Gemma 4 ou Mistral via Ollama est la seule option.

Notre guide complet sur les 3 voies de déploiement détaille les critères de sélection, les coûts comparés et les délais typiques.

Concrètement, comment commencer

La meilleure façon de commencer n’est pas de choisir un processus RPA et de le remplacer directement. C’est d’organiser un diagnostic de 30 minutes avec notre équipe pour identifier le premier candidat à migration qui maximise le ROI à court terme.

Nos packs commencent à 1 990 € en Voie 1 pour un Solo Agent, avec une supervision mensuelle de 99 €. Le retour sur investissement sur un processus qui libère ne serait-ce que deux heures par semaine d’un collaborateur est typiquement atteint en moins de trois mois.

Pour aller plus loin avant ce premier échange, notre guide diagnostic SOP vous permet de préparer votre cartographie des processus candidats. Il est disponible en téléchargement libre dans notre bibliothèque de ressources.

Le RPA a eu sa décennie. L’agent IA aura la sienne. La différence, c’est que la migration n’est pas forcée : elle se fait processus par processus, preuve par preuve, ROI par ROI.