Demandez à trois éditeurs ce que fait leur produit : les trois répondront « automatiser vos processus ». C'est exact et parfaitement inutile. La différence entre le RPA et l'iPaaS, et entre ces deux familles et un orchestrateur de workflows, n'est pas une nuance de vocabulaire commercial : elle détermine la robustesse de ce que vous construisez et le coût de sa maintenance sur trois ans.
La confusion est entretenue par les éditeurs eux-mêmes, qui ont tous élargi leur périmètre. Les plateformes d'intégration ont ajouté des modules de robotisation, les éditeurs de robotisation ont ajouté des connecteurs, et les orchestrateurs ont ajouté des interfaces graphiques. Résultat : les fiches produit se ressemblent, alors que les architectures sous-jacentes n'ont rien à voir.
Cet article remet les trois familles à leur place, décrit honnêtement leurs zones de recouvrement, et propose le seul critère de choix qui n'a pas bougé depuis dix ans : la nature de l'interface disponible du côté de l'outil que vous devez atteindre.
Différence RPA et iPaaS : trois familles, trois problèmes d'origine
Chacune de ces catégories est née pour résoudre un problème précis, et cette origine explique encore aujourd'hui ce qu'elle fait bien.
La plateforme d'intégration
Elle est née du besoin de faire circuler des données entre des systèmes qui exposent des interfaces de programmation. Son unité de travail est le message : un enregistrement part d'un système, il est transformé, il arrive dans un autre. Elle excelle sur les volumes importants, la reprise sur erreur, la transformation de formats et la gestion des files d'attente. Elle est en revanche mal armée quand l'outil cible n'expose rien.
L'orchestrateur de workflows
Il est né du besoin d'enchaîner des étapes hétérogènes avec de la logique conditionnelle, des attentes, des validations humaines et des branchements. Son unité de travail est l'exécution : un déclencheur, une suite d'étapes, un résultat. Il se moque de savoir si une étape appelle une interface de programmation, envoie un courriel ou attend l'approbation d'un responsable. C'est le chef d'orchestre, pas le tuyau.
La robotisation des processus
Elle est née d'une impasse : accéder à un logiciel qui n'offre aucune porte d'entrée technique. Sa solution est de simuler un utilisateur, en pilotant l'interface graphique, en cliquant et en saisissant. Son unité de travail est l'écran. Les éditeurs distinguent d'ailleurs clairement les automatisations qui pilotent une interface de bureau des flux qui appellent des services en ligne, ce qui est un aveu utile : ce ne sont pas les mêmes objets techniques.
Une manière courte de résumer : la plateforme d'intégration déplace des données, l'orchestrateur enchaîne des décisions, la robotisation des processus imite un humain devant un écran.
Ce que chaque famille fait bien, et ce qu'elle fait mal
| Famille | Point fort | Faiblesse principale | Cas typique |
| Plateforme d'intégration | Volume, fiabilité, transformation de données | Inutile sans interface exposée côté cible | Synchroniser un catalogue produits entre deux systèmes |
| Orchestrateur de workflows | Logique métier, validations, branchements | Peu adapté aux très gros volumes unitaires | Circuit de validation d'une demande d'achat |
| Robotisation | Atteint ce qui n'expose rien | Fragile à toute évolution d'interface | Saisie dans un progiciel de gestion ancien |
La colonne des faiblesses mérite plus d'attention que celle des points forts. Une plateforme d'intégration mal choisie ne fait rien du tout, ce qui se voit tout de suite. Un orchestrateur sous-dimensionné ralentit, ce qui se voit au bout de quelques mois. Une robotisation mal placée fonctionne parfaitement pendant six mois, puis casse un mardi matin parce qu'un éditeur a déplacé un bouton. Le troisième cas est le plus coûteux, précisément parce que la panne arrive après que tout le monde a cessé de surveiller.
Il faut ajouter un point rarement écrit noir sur blanc : la robotisation d'interface pose une question contractuelle. Beaucoup d'éditeurs considèrent que le pilotage automatisé de leur interface sort du cadre d'usage prévu, et le support peut se retourner contre vous en cas d'incident. Ce sujet est indissociable de celui des systèmes anciens, que nous avons traité dans notre article sur la cohabitation entre automatisations et logiciels métier anciens.
Les zones de recouvrement, et pourquoi elles existent
Les trois familles se chevauchent réellement, et il serait malhonnête de prétendre le contraire. Trois recouvrements sont fréquents.
- Orchestrateur contre plateforme d'intégration. Sur un flux simple entre deux services en ligne, les deux font le travail. Le départage se fait sur le volume et sur la complexité logique : quelques milliers d'exécutions par jour avec des conditions métier, l'orchestrateur suffit ; des millions d'enregistrements à transformer, la plateforme d'intégration est faite pour ça.
- Orchestrateur contre robotisation. La plupart des orchestrateurs savent aujourd'hui déclencher un script qui pilote un navigateur. C'est de la robotisation, même si le mot n'apparaît pas dans la fiche produit. Les mêmes précautions s'appliquent.
- Robotisation contre plateforme d'intégration. Certains éditeurs de robotisation vendent des connecteurs applicatifs. Utilisez-les : un connecteur qui passe par une interface de programmation est toujours préférable au pilotage d'écran, même s'il est vendu par un outil de robotisation.
Ces recouvrements expliquent pourquoi la question « quel outil choisir » n'a pas de réponse générale. Elle en a une, en revanche, dès qu'on la reformule correctement.
Le critère de choix qui ne bouge pas
Le critère stable ne dépend ni de l'éditeur, ni de la mode, ni de votre budget. Il dépend de ce que l'outil cible met à disposition. Posez la question dans cet ordre, et arrêtez-vous à la première réponse positive :
- L'outil cible expose-t-il une interface de programmation documentée et contractuelle ? Si oui, vous êtes dans le territoire de la plateforme d'intégration ou de l'orchestrateur. Le choix entre les deux se fait ensuite sur le volume et la complexité logique. La robotisation est à exclure : elle serait plus fragile pour un bénéfice nul.
- L'outil cible sait-il produire ou consommer des fichiers de façon planifiée ? Si oui, un orchestrateur qui dépose et relit des fichiers reste une solution solide, souvent sous-estimée parce qu'elle n'est pas vendeuse. Un export nocturne bien surveillé casse beaucoup moins souvent qu'un robot d'écran.
- L'outil cible s'appuie-t-il sur une base de données interrogeable en lecture ? Si oui, la lecture directe encadrée par des vues dédiées est préférable, en lecture seule uniquement.
- Rien de tout cela ? Alors la robotisation d'interface devient légitime, en connaissance de cause, avec une surveillance active et un budget de maintenance provisionné dès le premier jour.
Notez que ce raisonnement ne mentionne aucun nom de produit. C'est volontaire : la question « quelle famille » se tranche avant la question « quel éditeur », et se retrancher directement sur un comparatif de fonctionnalités est la meilleure façon d'acheter le mauvais type d'outil avec beaucoup de rigueur.
Combiner sans empiler
Dans la réalité, une organisation de taille moyenne finit avec deux briques, rarement trois. L'assemblage le plus fréquent, et le plus sain, place l'orchestrateur au centre comme point d'entrée unique des déclencheurs et de la logique métier, et n'appelle les autres briques que là où elles sont indispensables : la plateforme d'intégration pour les flux de masse, la robotisation pour les deux ou trois systèmes qui n'exposent rien.
Trois règles pour que cet assemblage ne devienne pas un empilement ingérable :
- Un seul endroit où lire l'état d'une exécution. Si vous devez ouvrir trois consoles pour savoir pourquoi une commande n'est pas partie, vous avez construit un système que personne ne saura dépanner en votre absence.
- Une seule politique de reprise sur erreur. Les mécanismes de nouvelle tentative des trois familles ne se comportent pas de la même façon. Décidez qui pilote les reprises, et désactivez-les ailleurs.
- Une frontière écrite. Une page suffit : ce qui passe par quelle brique, et pourquoi. Sans ce document, le choix se fera au cas par cas selon l'humeur de qui construit, et la cartographie deviendra illisible en dix-huit mois.
La question de l'hébergement se pose par-dessus, et de façon indépendante : chacune de ces familles existe en version hébergée par l'éditeur et en version installée chez vous. Nous avons détaillé cet arbitrage dans notre comparatif entre automatisation auto-hébergée et service en ligne.
Ce qu'il faut retenir
La différence entre le RPA et l'iPaaS ne tient pas à une liste de fonctionnalités mais à un point de départ : l'un imite un humain devant une interface parce qu'il n'a pas le choix, l'autre fait circuler des données entre des systèmes qui savent dialoguer. L'orchestrateur, lui, ne remplace ni l'un ni l'autre : il tient la logique et l'ordre des opérations.
Avant de comparer des outils, faites l'inventaire des interfaces réellement disponibles sur les systèmes que vous devez atteindre. Cet inventaire prend une demi-journée, il ne coûte rien, et il élimine à lui seul la moitié des mauvais choix d'architecture. La question n'est pas quel outil est le meilleur, mais quelle porte d'entrée existe du côté de la cible.
Laisser un commentaire