Agents, RPA ou workflows : quelle automatisation pour quelle tâche

Une entreprise mène trois chantiers d’automatisation en parallèle. Une équipe RPA automatise le travail d’écran dans l’ancien ERP. La DSI construit des circuits d’approbation dans un outil de workflow. Une équipe innovation pilote des agents d’IA. Tous trois revendiquent le processus des factures fournisseurs.

Le robot RPA casse dès que l’écran de l’ERP change. Le workflow exige que chaque cas soit conçu à l’avance, si bien que la facture atypique en sort. L’agent traite bien les factures atypiques, et personne ne sait expliquer après coup pourquoi il a fait ce qu’il a fait. Chaque équipe reproche les trous aux deux autres.

La cause : trois outils différents, faits pour trois formes de travail différentes, ont été choisis selon qui détenait le budget, et non selon la tâche. Ils ne sont pas concurrents. Chacun excelle là où les autres sont faibles.

Trois outils, trois métiers

Les workflows (moteurs de processus, BPM) font tourner un processus explicite : états, transitions, règles, responsables et approbations, tous conçus à l’avance. Ils sont prévisibles et auditables, et rigides par conception. Ils conviennent au travail dont le processus est connu et stable.

La RPA (automatisation robotisée des processus) est un logiciel qui manipule l’interface utilisateur d’autres logiciels comme le ferait une personne, par clics et frappes au clavier. C’est une passerelle vers des systèmes dépourvus d’interface de programmation. Elle est fragile dès que les écrans changent, et elle automatise le contournement plutôt que le processus.

Les agents sont des modèles de langage qui lisent, planifient et appellent des outils. Ils savent traiter des entrées non structurées et des cas que personne n’avait prévus. Ils ne sont pas déterministes : il leur faut donc des limites écrites, un journal de ce qu’ils ont fait et des approbations pour tout ce qui compte.

Les erreurs d’attribution courantes

La RPA comme stratégie d’intégration. Un robot qui recopie des champs d’un système à l’autre est une intégration sans contrat. Quand l’un des deux écrans change, il échoue, souvent sans bruit, et le problème est découvert en aval.

Des workflows pour du travail non structuré. Vouloir modéliser chaque type d’e-mail client comme une branche d’un diagramme produit un diagramme que personne ne peut maintenir, et qui rate malgré tout le prochain type d’e-mail inédit.

Des agents pour des étapes déterministes. Utiliser un modèle de langage pour calculer une taxe ou appliquer un seuil d’approbation fixe est plus lent et plus coûteux que du code, et peut se tromper d’une manière dont le code est incapable.

Des agents sans limites. Un accès en écriture sans plafond de montant, sans liste de ce qui peut être modifié et sans étape d’approbation. Cela fonctionne jusqu’à la première erreur commise avec aplomb.

Trois outils, trois états. Chacun tient son propre suivi de l’avancement d’un dossier, si bien que « où en est cette facture ? » a trois réponses et nécessite une réunion pour les rapprocher.

Choisir selon la tâche

Pour chaque étape d’un processus, posez cinq questions, dans l’ordre.

1. L’entrée est-elle structurée ? Si ce n’est pas le cas, un agent la lit et la transforme en données structurées.
2. La règle est-elle connue et stable ? Si oui, elle relève d’un workflow ou de code simple, et s’exécute de la même façon à chaque fois.
3. Existe-t-il une interface ou un modèle de données commun ? Si oui, utilisez-le. La RPA seulement comme passerelle temporaire vers un système qui en est dépourvu, avec une date à laquelle elle sera retirée.
4. L’étape exige-t-elle du jugement sur un cas que personne n’avait prévu ? Alors un agent prépare une proposition argumentée et une personne décide.
5. Que coûte une erreur, et peut-elle être annulée ? C’est ce qui détermine l’approbation, quel que soit l’outil qui fait le travail.

La réponse habituelle est une combinaison. Le workflow forme la colonne vertébrale : états, responsables et approbations. Les agents prennent en charge, à l’intérieur, les étapes non structurées comme la lecture, la rédaction et le classement. Le code déterministe fait les calculs. La RPA ne sert de passerelle vers un système existant que jusqu’à ce que celui-ci soit remplacé ou expose une interface.

C’est la structure autour de laquelle est conçue la couche Logique agentique de Hurukan : des agents métier travaillant dans des modèles de processus, avec des limites d’autonomie écrites, l’approbation d’une personne pour les étapes critiques et chaque action journalisée. Les propositions qui appellent une décision arrivent dans une seule boîte, décrite dans Décisions et tâches. Les deux sont en construction. Quels que soient les outils retenus, la plupart des échecs se produisent entre les étapes plutôt qu’à l’intérieur, ce que développe l’hyperautomatisation échoue au passage de relais.

Un test à faire dès aujourd’hui

Dressez la liste de toutes les automatisations qui tournent dans votre entreprise : robots, workflows, scripts planifiés, macros, agents. Pour chacune, notez quatre choses :

1. Ce qu’elle fait, en une phrase.
2. Lequel des trois types elle est.
3. Lequel elle devrait être, d’après les cinq questions ci-dessus.
4. Qui est prévenu lorsqu’elle échoue, et comment.

Toute automatisation pour laquelle les réponses aux deuxième et troisième points diffèrent est candidate à une refonte. Toute automatisation pour laquelle la réponse au quatrième est « personne » ou « on finirait par s’en apercevoir » est la première à corriger, quel que soit son type. La page d’accueil de Hurukan explique comment les agents s’insèrent dans le reste du système.