Définition
La RPA automatise le travail en pilotant l’écran : se connecter, cliquer, saisir, copier d’une fenêtre à l’autre. Elle existe parce que beaucoup de systèmes d’affaires n’offrent aucune autre voie de connexion, ce qui la rend précieuse exactement là où les meilleures options manquent.
À quoi sert réellement la RPA
On décrit souvent la RPA comme un robot qui fait le travail d’une personne. Description plus juste : c’est un programme qui se fait passer pour une personne, parce que le système auquel il doit parler n’accepte les entrées que de la part d’humains.
Ce cadrage explique à la fois sa valeur et sa réputation. Quand un ERP vieux de vingt ans n’a aucune API, aucune exportation au-delà d’un rapport imprimé, et aucun fournisseur disposé à en construire une, la RPA est la seule voie qui n’implique pas de remplacer le système. Elle sauve réellement des situations sans autre issue.
Cela explique aussi sa fragilité. La RPA dépend du fait que l’écran reste où il était. Une mise à jour du fournisseur qui déplace un bouton, une boîte de confirmation ajoutée ou une page lente peuvent briser une automatisation qui tournait sans faute depuis un an, et elle se brise d’une façon qui exige que quelqu’un s’en aperçoive.
RPA ou intégration par API
| RPA | Intégration par API | |
|---|---|---|
| Se connecte par | L’interface utilisateur | Une interface programmatique |
| Casse quand | L’écran change | Le contrat change (généralement versionné) |
| Vitesse | Au rythme humain | Immédiate |
| Mise en place | Rapide, sans coopération du fournisseur | Exige que le système en expose une |
| Passage à l’échelle | Mauvais, une session à la fois | Bon |
| Entretien | Continu et imprévisible | Faible et planifié |
La règle est simple : utilisez une API s’il en existe une. Recourez à la RPA quand le système n’offre aucune autre porte, quand un fournisseur ne veut ou ne peut pas aider, ou quand le processus doit fonctionner maintenant alors que l’intégration propre est un projet plus long. Entrez simplement en sachant ce que coûte l’entretien.
Où la RPA garde sa place
Les systèmes hérités demeurent le cas principal : le logiciel comptable, l’application sectorielle, le portail gouvernemental qui n’accepte qu’une soumission manuelle. Ajoutez les portails fournisseurs sans API partenaire, les processus éphémères où bâtir une vraie intégration ne se justifie pas, et les migrations où un robot déplace des données une fois avant d’être retiré.
Le schéma à éviter : la RPA comme substitut permanent à l’intégration. Une douzaine de robots masquant des systèmes qui auraient pu être correctement raccordés devient son propre service d’entretien, et le coût reste invisible jusqu’à l’année où il ne l’est plus.
L’approche Automathing
Nous cherchons une véritable voie d’intégration avant de proposer de la RPA, quitte à interroger directement le fournisseur, parce qu’une API coûte presque toujours moins sur trois ans qu’un robot. Quand la RPA est réellement la bonne réponse, nous la traitons comme un pont dont la durée de vie est annoncée : surveillé, documenté, avec un plan de remplacement. Un robot sans responsable est une panne à venir.
Foire aux questions
La RPA est-elle dépassée maintenant qu’il y a l’IA ?
Non, mais son rôle s’est resserré. La RPA excelle au clic déterministe ; elle n’a jamais su lire un document ni porter un jugement. L’IA couvre l’interprétation, la RPA couvre l’accès aux systèmes qui refusent de parler autrement, et les deux se combinent de plus en plus : le modèle décide de ce qui doit arriver, le robot l’exécute dans un système sans API.
La RPA coûte-t-elle moins cher qu’une vraie intégration ?
Moins cher à démarrer, souvent plus cher à conserver. La mise en place est rapide puisqu’elle ne demande aucune coopération du fournisseur, mais l’entretien est continu et imprévisible, dépendant d’interfaces que vous ne contrôlez pas. Sur un horizon de plusieurs années, l’intégration par API l’emporte généralement en coût total, d’où la nécessité d’inclure l’entretien dans la comparaison et pas seulement la construction.
Qu’est-ce qui casse un robot RPA ?
Les changements d’interface, surtout : un bouton déplacé, un champ renommé, une nouvelle fenêtre de consentement, une page plus lente. Aussi l’expiration des identifiants, les délais de session et tout ce qui exige une authentification à plusieurs facteurs. Chaque cause est triviale individuellement et explique collectivement pourquoi la RPA exige une surveillance et un responsable nommé.
La RPA peut-elle gérer les exceptions ?
Seulement celles qu’on lui a décrites. La RPA suit un chemin défini : tout imprévu la fait échouer ou, pire, la fait continuer de travers. La conception habituelle consiste à lui confier le chemin standard et à acheminer le reste vers une personne, ou à placer une étape d’IA devant elle pour interpréter l’entrée avant que la partie déterministe s’exécute.