Robots ou interconnexion : lequel pour quel flux
Un robot pilote une application par ses écrans, une interconnexion parle son langage. Le bon choix dépend de ce que l'application expose, pas d'une préférence de principe.
La question revient à chaque rendez-vous : faut-il des robots ou des connexions ? Posée comme ça, elle n’a pas de réponse. Les deux techniques répondent à des situations différentes, et la plupart des systèmes d’information de bailleurs ont besoin des deux.
Ce que chacune sait faire
Un robot pilote une application comme le ferait une personne : il ouvre les écrans, remplit les champs, valide. Sa force est immense et souvent sous-estimée : il fonctionne avec n’importe quelle application, y compris celles qui n’exposent rien. Il applique les contrôles de cohérence de l’outil et respecte les droits du compte utilisé, ce qui est une vraie garantie de qualité. C’est souvent le seul moyen d’écrire proprement dans un logiciel qu’on n’a pas écrit.
Une interconnexion parle le langage de l’application : elle appelle son API ou dépose un fichier au format attendu. Sa force est le volume et la finesse. Elle sait ne transmettre que ce qui a changé, reconnaître un doublon, reprendre après une coupure au bon endroit, et rendre compte de chaque envoi.
Aucune des deux n’est supérieure. Elles n’opèrent simplement pas au même endroit.
La règle de choix, en une question
Qu’est-ce que l’application en face expose ?
| Ce que l’application propose | Ce qu’on utilise |
|---|---|
| Une API de lecture et d’écriture | Interconnexion par API |
| Un import de fichier attendu | Interconnexion par fichier |
| Une base lisible, mais rien pour écrire | Lecture SQL à l’aller, écrans au retour |
| Ni API, ni import, ni base accessible | Automatisation par écrans |
Cette grille se lit flux par flux, pas outil par outil. Un même logiciel peut très bien être alimenté par API dans un sens et piloté par ses écrans dans l’autre.
Notre propre cas : le sens retour passe par les écrans
Nous appliquons cette grille à nous-mêmes. Quand une décision prise dans un outil métier doit redescendre dans l’ERP, nous n’écrivons pas dans sa base. C’est une règle que nous ne négocions pas : une écriture directe contourne les contrôles de l’éditeur, met en péril son support, et laisse une dette que personne ne saura porter dans trois ans.
Alors nous faisons ce que ferait un gestionnaire : nous passons par les écrans. C’est de l’automatisation par interface, et elle est ici la bonne réponse, la seule qui respecte l’outil.
Ce que nous ajoutons autour, en revanche, change tout :
- on cherche avant d’écrire. L’information est peut-être déjà là, saisie par quelqu’un ou par un passage précédent. Si elle y est, on ne fait rien. C’est ce qui garantit qu’aucun doublon n’apparaît, même après une coupure ;
- on relit après avoir écrit. Champ par champ, on vérifie que ce qui devait être saisi l’a été. Tout est bon, l’opération est close et tracée. Un champ manque, les équipes sont prévenues et décident ;
- on ne rejoue jamais tout seul. Une écriture qui a échoué ne repart pas en boucle : elle attend une décision.
Un geste d’interface encadré par une vérification avant et une relecture après n’a plus grand-chose à voir avec un script lancé dans le vide. C’est la même technique, avec la traçabilité d’un flux.
Quand une interconnexion vaut mieux
Pour les volumes et pour le rythme. Si un flux touche des milliers de lignes, ou s’il doit passer plusieurs fois par jour, l’API est plus rapide, moins coûteuse et plus facile à superviser. Trois propriétés y deviennent naturelles :
- le différentiel : seul ce qui a changé circule, ce qui divise les volumes dans des proportions considérables ;
- l’idempotence : rejouer un envoi ne crée pas de doublon ;
- la reprise : après une interruption, le traitement repart au bon endroit.
C’est pourquoi le sens aller, qui transporte l’essentiel du volume, passe par API ou par fichier chaque fois que l’outil destinataire le permet.
Comment faire cohabiter les deux
Gardez l’existant tant qu’il sert. Une automatisation en place qui fait le travail est un actif, et elle est aussi le meilleur point de comparaison qui existe : faites tourner le nouveau flux à côté et examinez les écarts. Chacun est soit un défaut du nouveau, soit une règle métier que l’ancien appliquait sans que personne ne l’ait jamais écrite.
Rassemblez la supervision. La vraie difficulté d’un parc mixte n’est pas technique, elle est de savoir où on en est. Qu’un flux passe par une API ou par des écrans, il doit répondre aux mêmes trois questions : qu’est-ce qui est parti, qu’est-ce qui attend, qu’est-ce qui a échoué. Une seule vue pour les deux, et le débat sur la technique perd beaucoup de son importance.
Documentez le choix. Pour chaque flux, écrivez pourquoi il emprunte ce canal. Le jour où l’éditeur ouvre une API, la décision se réexamine en cinq minutes au lieu de se redécouvrir.
Ce qu’il faut retenir
Le canal est un détail d’implémentation. Ce qui compte, c’est que l’information arrive, qu’elle arrive une seule fois, et qu’on sache dire à tout moment si elle est arrivée. Un robot bien encadré satisfait ces trois exigences. Une API mal supervisée ne les satisfait pas.
Vous voulez en parler pour votre organisme ? Écrivez-nous à contact@oxli.io ou demandez une démonstration.