RPA, low-code ou code sur mesure : choisir pour un processus précis

Vous voulez transférer des commandes d’un logiciel à un autre. Avant de comparer les outils, je regarderais comment chaque application permet de faire entrer et sortir les données. Une API documentée, une exportation de fichiers et un écran sont des points de départ différents.

RPA, low-code et développement sur mesure ne sont pas non plus trois catégories séparées. Une plateforme visuelle peut appeler une API, exécuter du code et utiliser un robot de bureau dans le même processus. Il s’agit de choisir les composants que vous pourrez exploiter et entretenir.

Trois solutions pour la même exportation

Je prends un scénario hypothétique : chaque semaine, vous devez extraire une liste de commandes et l’ajouter à un registre interne. Cette étape n’émet pas de factures et ne confirme pas le stock.

Si le logiciel ne propose qu’un écran et un bouton d’exportation, un robot RPA pourrait l’ouvrir, sélectionner la période et télécharger le fichier. Je ne l’écarterais pas par principe. La documentation de Microsoft explique que les flux de bureau peuvent identifier les éléments avec des sélecteurs, sans dépendre de coordonnées absolues. Elle prévoit aussi des sélecteurs alternatifs et fondés sur le texte. Déplacer un bouton ne fait pas nécessairement échouer tous les robots.

Je testerais néanmoins les changements de session, les fenêtres inattendues et les mises à jour de l’application. Si le robot ne trouve pas le bon fichier, il doit s’arrêter. Pour une exportation hebdomadaire vérifiée par une personne avant l’importation, cela peut être une option raisonnable.

Si un connecteur compatible existe, un outil low-code peut récupérer les commandes et les écrire dans le registre. Il est utile lorsque l’équipe peut comprendre le flux et adapter des règles simples. Je vérifierais si le connecteur prend en charge tous les champs, comment il parcourt les pages de résultats et ce qui arrive aux limites d’utilisation. Le coût dépend de l’offre précise ; je ne supposerais pas qu’il est toujours calculé par utilisateur ou qu’il augmente toujours de la même façon.

Si une API existe mais que le processus demande des règles non couvertes par le connecteur, le code sur mesure permet de les exprimer directement. En contrepartie, quelqu’un doit le documenter, le tester et le mettre à jour. L’API peut aussi changer, limiter les requêtes ou disparaître : écrire son propre code ne supprime pas les dépendances.

Comparer l’entretien autant que la mise en service

Je demanderais le même périmètre pour les trois options : volume de commandes, champs, fréquence, gestion des doublons et réponse aux échecs. Sinon, un devis pour copier les données et un autre pour les rapprocher semblent comparables alors qu’ils ne répondent pas au même besoin.

Option	Ce que je vérifierais pendant l’essai	Travail ultérieur à budgéter
RPA à travers l’écran	Exportation correcte dans différentes sessions	Mises à jour de l’interface et de l’environnement de bureau
Connecteur low-code	Champs, limites et récupération après erreur	Changements du connecteur, de l’offre et des règles
Code avec API	Réponses incomplètes, doublons et nouvelles tentatives	Versions de l’API, tests et support

Pour un processus critique, j’exigerais des contrôles de données, des traces, une procédure de reprise et une personne responsable, quel que soit l’outil. Le nom de la méthode ne prouve pas que ces contrôles existent.

Je demanderais aussi comment exporter le flux ou le code, où se trouve la documentation et ce qu’il faut à une autre personne pour en assurer l’entretien. La possibilité de changer de prestataire se vérifie dans cette remise, pas dans une promesse d’indépendance.

Mon choix partirait de l’accès disponible et du coût total pour maintenir un résultat correct. Pour cette liste hebdomadaire, une solution simple et vérifiée peut suffire. Si elle doit ensuite confirmer des commandes sans intervention, il faudra réévaluer le risque et le périmètre.