- Automatisation
RPA ou API : le critère de choix, et pourquoi la réponse évidente est souvent la mauvaise
Quand une API existe, elle est presque toujours préférable. Mais l'attente d'une API qui n'arrivera pas avant dix-huit mois coûte parfois plus cher qu'un robot.
· 4 min de lecture · AzerOps
Le débat est ancien et généralement mal posé. « Le RPA est une rustine, il faut faire des API » est une affirmation d'architecte. « L'API prendra dix-huit mois, on fait un robot » est une affirmation d'opérationnel. Les deux ont raison sur des horizons différents.
Ce que chacun coûte réellement
Une intégration par API coûte cher à mettre en place quand l'API n'existe pas : il faut la spécifier, la développer côté système source, la sécuriser, la documenter, la faire valider. Sur un progiciel tiers, cela suppose que l'éditeur l'expose, ce qui n'est pas acquis. En revanche, une fois en place, elle ne casse presque jamais : un contrat d'interface est stable par construction.
Un robot RPA coûte peu à mettre en place et beaucoup à maintenir. Il dépend de l'interface graphique, donc de choses qui changent sans préavis : une mise à jour de l'application, un champ déplacé, un nouveau message d'avertissement. Comptez quinze à vingt-cinq pour cent du coût de développement par an, chaque année.
Le point de croisement se situe généralement entre deux et quatre ans. En dessous, le robot est plus économique. Au-delà, l'API l'emporte.
La grille de décision
Faites une API si elle existe déjà, ou si le système source est le vôtre et que l'exposer est raisonnable, ou si le processus est stratégique et durable, ou si les volumes sont élevés.
Faites un robot si le système cible est un progiciel fermé sans interface programmatique, ou si le processus a une durée de vie limitée connue, ou si l'ouverture d'une API dépend d'un projet dont l'échéance n'est pas maîtrisée.
Faites un robot maintenant et une API ensuite si le besoin est urgent mais durable. C'est un choix légitime à condition d'être explicite : le robot est une solution de transition, avec une date de fin prévue et un budget d'API inscrit à la feuille de route. Ce qui pose problème n'est pas le robot temporaire, c'est le robot temporaire dont plus personne ne se souvient qu'il était temporaire.
Le cas hybride qui fonctionne bien
Sur des applications anciennes dont le code source est disponible, une troisième voie est souvent la meilleure : exposer une API mince par-dessus l'existant, sans réécrire le cœur applicatif.
Cela vaut particulièrement pour les applications de gestion développées en interne, où l'accès direct à la base de données ou à une couche de services permet de construire une interface propre pour une fraction du coût d'un robot maintenu sur cinq ans.
La question à poser à votre prestataire
« Dans quels cas déconseillez-vous le RPA ? » Un prestataire spécialisé RPA qui n'a pas de réponse précise vend un outil plutôt qu'une solution. Un prestataire qui répond « quand une API existe ou peut exister à moindre coût » a fait le calcul, et vous pouvez lui faire confiance pour le refaire sur votre cas.