RPA, automatisation des flux de travail et agents IA : ce que signifie chaque terme

Trois mots, employés dans les offres comme trois niveaux de prix d’un même service, sont trois mécanismes distincts. En quoi chacun diffère, ce que l’acheteur reçoit et pourquoi la différence est désormais aussi juridique.

Trois mots tendent à apparaître dans une même offre comme s’il s’agissait de trois niveaux de prix d’un seul et même service : l’automatisation robotisée des processus, l’automatisation des flux de travail et les agents IA. Pour l’acheteur, cela donne l’impression qu’il faut choisir l’un des trois produits, et c’est en général le plus cher qui l’emporte, parce qu’il sonne plus moderne.

En réalité, ce sont trois mécanismes distincts, qui répondent à des problèmes distincts, et la plus grande part des tâches réelles exige précisément celui qui coûte le moins. Cet article ne compare pas des outils et ne recommande pas de plateforme ; il explique en quoi chaque mécanisme diffère techniquement, ce que l’acheteur reçoit dans chaque cas, et pourquoi précisément cette différence est devenue, ces deux dernières années, une question juridique.

Trois mécanismes qui répondent à trois questions différentes

Le moyen le plus simple de les tenir à part est de demander comment chacun sait ce qu’il doit faire. L’automatisation robotisée des processus répète les actions qu’un humain lui a montrées ; l’automatisation des flux de travail suit le chemin que quelqu’un a dessiné ; l’agent IA infère lui-même le chemin à partir de l’objectif qui lui a été donné. De cette seule différence découle presque tout le reste, y compris le prix, la fragilité et ce qui se passe lorsque la situation est inattendue. Le mécanisme qui répète s’arrête dans une situation inattendue ; celui qui suit un chemin dessiné prend la branche d’erreur, si elle a été prévue ; celui qui infère invente quelque chose de nouveau, et c’est précisément pour cela qu’il a besoin d’une supervision dont les deux autres se passent.

Il vaut la peine de l’essayer sur une tâche concrète, qui dans presque chaque entreprise se présente de la même façon : une facture arrivée dans la messagerie doit être saisie dans le système comptable. L’automatisation robotisée des processus s’y prendrait en ouvrant le programme de messagerie, en téléchargeant la pièce jointe, en ouvrant la fenêtre de la comptabilité et en remplissant les champs exactement dans l’ordre où le ferait un salarié. Un flux de travail s’y prendrait en recevant le document par une interface et en appelant l’interface du système comptable avec les champs déjà prêts, sans ouvrir aucune fenêtre. Un agent s’y prendrait en recevant la tâche « comptabilisez cette facture » et en décidant lui-même quels outils appeler, et que faire s’il manque quelque chose.

Les trois variantes peuvent accomplir cette tâche, et c’est précisément cela qui induit en erreur. La différence n’apparaît pas lorsque tout va bien, mais lorsque le fournisseur change le formulaire de facture, lorsqu’un nouveau champ obligatoire apparaît dans le système, ou lorsqu’un même article est nommé de deux façons, et ce sont précisément ces cas qui forment la plus grande part du travail réel.

L’automatisation robotisée des processus répète des actions à l’écran

L’automatisation robotisée des processus, appelée au quotidien par le sigle anglais RPA, est un robot logiciel qui travaille dans exactement les mêmes interfaces qu’un humain : il ouvre une fenêtre, clique, copie un champ, appuie sur enregistrer. Les systèmes avec lesquels il travaille restent entièrement inchangés, et c’est à la fois son principal avantage et sa principale faiblesse. L’avantage, c’est que la RPA s’en sort avec des programmes qui n’ont aucune interface d’échange de données et que plus personne ne reconstruira, si bien que c’est souvent le seul chemin vers d’anciens systèmes comptables ou métier. La faiblesse, c’est que le robot voit l’écran, non les données, si bien que tout changement à l’écran — bouton déplacé, nouveau champ, autre version de mise à jour — arrête le travail, et la maintenance devient un coût permanent, non un coût unique.

L’acheteur reçoit ici la licence du robot, son environnement d’exécution et un outil de gestion, une description du processus et un journal des actions effectuées. Il vaut la peine de savoir que, dans le métier lui-même, ce nom est considéré comme mal choisi : ce que la RPA automatise est en général une tâche isolée, non un processus entier, et c’est précisément ce décalage entre le nom et le contenu qui nourrit une part des attentes des acheteurs, lesquelles ensuite ne sont pas tenues.

Une autre caractéristique qui, dans les projets de RPA, a l’habitude de surprendre, c’est que le robot travaille avec le même niveau d’accès que la personne dont il répète les actions. Cela veut dire que le robot a besoin de son propre utilisateur dans chaque système, que les droits de cet utilisateur doivent être pensés comme pour n’importe quel autre, et que les actions du robot, dans le journal du système, ressemblent à celles d’un humain, sauf s’il a un compte distinct. Dans les entreprises où l’on n’y a pas pensé, il est ensuite difficile de répondre à une question simple : qui a effectué cet enregistrement.

L’automatisation des flux de travail relie les systèmes, non les écrans

L’automatisation des flux de travail travaille un niveau plus profond : elle ne parle pas à l’écran, mais aux systèmes eux-mêmes, par leurs interfaces logicielles. Un flux de travail est un graphe d’étapes dessiné à l’avance — un événement déclenche une chaîne, la chaîne appelle des actions dans d’autres systèmes, et entre elles peut aussi se trouver une étape où un humain confirme quelque chose. Comme l’échange de données passe par une interface, non par une image, les changements d’apparence du système n’affectent pas ce mécanisme, et c’est la principale raison pour laquelle, là où l’interface est disponible, c’est presque toujours un choix plus robuste et moins cher à maintenir que la répétition à l’écran. L’inconvénient est évident : si le système n’a pas d’interface, ou si elle n’est pas disponible au niveau de votre licence, ce chemin n’existe tout simplement pas.

L’acheteur reçoit ici le flux de travail lui-même, les identifiants d’accès, le journal d’exécution et la branche d’erreur, et c’est précisément ce dernier élément qu’il vaut la peine de prendre pour juger une offre, parce qu’un flux de travail sans traitement des erreurs ne fonctionne que tant que tout va bien. En français, ce mécanisme a son mot : flux de travail est le terme que retiennent les textes professionnels, si bien qu’il n’est pas nécessaire d’ajouter le mot anglais entre parenthèses.

Le mot qui sert ici et qu’il vaut la peine d’employer avec précision est robot logiciel : c’est un programme qui imite les actions d’un humain dans une interface, et ce n’est en rien un robot physique. Cette distinction est, en français, plus importante qu’en anglais, parce que le mot « robot » désigne au quotidien une machine, et c’est précisément de ce malentendu que viennent une partie des questions sur ce que le robot « voit » et ce qu’il « comprend ». Il ne comprend rien : il répète ce qu’on lui a montré.

L’agent IA infère le chemin lui-même

L’agent se distingue des deux précédents en ce qu’on ne lui donne pas un chemin, mais un objectif, et qu’il choisit lui-même le chemin, en appelant les outils qui lui sont disponibles — une recherche, une base de données, l’interface d’un système, un autre modèle. C’est précisément le fait d’agir avec des outils qui est le trait qui distingue l’agent du chatbot : le chatbot répond, l’agent fait. Il s’ensuit que l’agent s’en sort avec des tâches dont la séquence d’étapes n’est pas connue à l’avance, et qu’en même temps c’est le seul des trois mécanismes dont le résultat n’est pas entièrement prévisible. Deux lancements identiques peuvent choisir des chemins différents, et cela veut dire qu’il faut à la fois une supervision et des limites clairement fixées à ce que l’agent a le droit de faire tout seul, et où il doit s’arrêter et demander à un humain.

Dans le travail pratique, cela veut souvent dire que l’agent est le bon mécanisme là où les données d’entrée sont non structurées et diverses, mais le mauvais là où la tâche est strictement définie et se répète des centaines de fois par jour. Dans le second cas, le flux de travail est à la fois moins cher et plus sûr, et y employer un agent, c’est dépenser de l’argent pour une imprévisibilité dont personne n’avait besoin.

Dans le cas de l’agent, l’acheteur reçoit autre chose que dans les deux autres cas, et les offres souvent ne le décrivent pas du tout. Outre l’agent lui-même, il faut les outils qu’il a le droit d’appeler, les limites de ce qu’il a le droit de faire sans confirmation, un journal de ce qu’il a fait à chaque lancement, et un moyen de l’arrêter. Une offre qui ne contient qu’un modèle et un prompt décrit une démonstration, non un outil de travail.

Il y a aussi une différence de coût qui, dans les plans de projet, a l’habitude de manquer. L’exécution d’un flux de travail ne coûte presque rien, parce que ce sont quelques appels, et les coûts de la RPA sont surtout la licence et la maintenance. Chaque lancement d’un agent, lui, se paie à l’usage du modèle, et ce coût croît avec le volume, si bien que le mécanisme qui, à l’essai, paraissait bon marché, peut, à des centaines de lancements par jour, s’avérer le plus cher des trois.

Où s’arrête l’automatisation et où commence l’intelligence artificielle

Cette frontière est devenue, ces dernières années, une question juridique, parce que le règlement de l’Union européenne sur l’intelligence artificielle attache ses obligations précisément à la définition du système d’IA. L’article 3, paragraphe 1, du règlement le décrit comme un système qui infère comment, à partir des entrées reçues, produire une sortie — une prédiction, du contenu, une recommandation ou une décision. Tout aussi important est ce qui reste en dehors. Les considérants du règlement disent explicitement que les systèmes qui fonctionnent uniquement selon des règles définies par des personnes, afin d’exécuter automatiquement des opérations, ne correspondent pas à cette définition, et les lignes directrices de la Commission européenne le répètent plus concrètement encore, en nommant l’inférence comme le trait indispensable et l’exécution d’instructions prédéterminées comme ce qui n’entre pas dans la définition.

La même frontière figure dans le considérant 12 du règlement lui-même : la définition ne couvre pas les systèmes fondés sur les règles définies uniquement par les personnes physiques pour exécuter automatiquement des opérations. Ce n’est pas une loi distincte, c’est la formulation authentique. La conséquence pratique est directe : un robot RPA qui recopie des données d’une fenêtre à l’autre, et un flux de travail qui appelle une interface selon un chemin dessiné, ne font pas naître les obligations du règlement sur l’intelligence artificielle. Un agent qui infère peut les faire naître, et c’est précisément pour cela que mélanger les noms dans une offre n’est pas seulement une question de style.

Ce que l’acheteur reçoit dans chaque cas

Comparer les offres est plus facile si l’on regarde non pas le nom, mais ce qui, une fois le travail fini, reste dans l’entreprise. Dans le cas de l’automatisation robotisée des processus, il reste une licence, un environnement d’exécution, un outil de gestion, une description du processus et un journal des actions effectuées, et de tout cela le plus important est la description du processus, parce que c’est elle qui dit ce que le robot fait lorsque quelque chose ne correspond pas à l’attendu.

Dans le cas du flux de travail, il reste le flux lui-même, les identifiants d’accès à chaque système relié, le journal d’exécution et la branche d’erreur, et ici il vaut la peine de prêter attention à qui appartiennent les identifiants et où le flux de travail s’exécute. S’il s’exécute dans le compte du fournisseur avec les clés du fournisseur, alors une rupture des relations signifie aussi une rupture du travail, et il est plus facile de l’organiser au moment de conclure le contrat que plus tard.

Dans le cas de l’agent, il reste en plus de tout ce qui précède la responsabilité de ce qu’il a fait, et c’est précisément pour cela que le journal n’est pas là un détail technique, mais le fond même. Si l’on ne peut pas dire pourquoi l’agent, dans un cas concret, a agi comme il a agi, on ne peut pas non plus répondre au client qui demande pourquoi sa demande a été traitée de cette façon-là.

Quelles échéances ont déjà commencé

Comme les exigences du règlement entrent en vigueur par étapes, il vaut la peine de savoir ce qui s’applique déjà aujourd’hui et ce qui ne s’applique pas encore. L’obligation d’informer une personne qu’elle s’adresse à un système d’IA est applicable depuis le 2 août 2026, et elle concerne un agent IA ou un chatbot visible des clients sur votre site web. S’il y en a un d’installé, c’est une question à résoudre maintenant, non dans le futur.

Les exigences relatives aux systèmes à haut risque, qui portent sur des domaines tels que le recrutement et les décisions d’emploi, commencent à s’appliquer le 2 décembre 2027, et cette date a récemment été reportée, si bien que dans une partie des articles on trouve encore une année plus ancienne. Les pratiques interdites et la définition même du système, elles, sont déjà en vigueur.

Indépendamment du règlement sur l’intelligence artificielle, reste également en vigueur l’exigence de protection des données relative aux décisions fondées exclusivement sur un traitement automatisé et qui produisent des effets juridiques ou affectent de manière similaire et significative une personne. Cette exigence ne dépend pas de ce que le mécanisme soit un agent ou un simple flux de travail : ce qui compte, c’est de savoir si la décision concernant une personne est prise par une machine seule.

Il vaut aussi la peine de comprendre pourquoi cette frontière a été tirée précisément à travers l’inférence, et non à travers la complexité. Un programme peut être très complexe et n’être toujours pas un système d’IA, si chacune de ses étapes a été fixée par un humain, et inversement — une solution tout à fait petite, qui utilise un modèle pour décider quoi faire, entre dans la définition. Cela veut dire que la réponse à la question des obligations ne vient ni du budget du projet, ni du nombre de lignes, mais seulement de la façon dont est prise la décision sur l’action suivante.

Dans la pratique, ces échéances portent le plus souvent sur une chose concrète que beaucoup d’entreprises ont déjà : un chatbot ou un assistant sur le site web. S’il est visible du client et qu’il s’appuie sur un modèle de langage, alors l’obligation de dire que l’interlocuteur n’est pas un humain s’applique déjà, et on s’en acquitte concrètement par une mention claire dans l’interface, non par un paragraphe dans la politique de confidentialité. S’il s’agit d’un simple arbre de règles avec des réponses écrites à l’avance, alors ce n’est pas un système d’IA et cette obligation ne naît pas, mais il vaut la peine de figer la différence par écrit, parce que dans un an plus personne ne se souviendra de comment c’était construit.

Pourquoi les noms se mélangent sur le marché

Le mélange a aussi une raison tout à fait objective, et ce n’est pas seulement le marketing. Des outils qui autrefois faisaient une chose en font maintenant plusieurs : des plateformes nées comme outils de flux de travail proposent aujourd’hui aussi une étape d’agent, tandis que des entreprises qui vendaient de l’automatisation robotisée des processus décrivent maintenant les mêmes produits comme des produits qui agissent tout seuls.

Cela veut dire que l’on ne peut plus déterminer le mécanisme d’après le nom du produit, et la seule question sûre à poser à une offre est de savoir comment, dans la solution concrète, le chemin des actions est déterminé : est-ce un humain qui l’écrit, est-ce un graphe que l’on dessine, ou est-ce le modèle qui le choisit à chaque lancement. La réponse à cette seule question dit à la fois le prix, la fragilité, et si les obligations du règlement peuvent même naître.

Il y a aussi des mots auxquels, en français, il faut faire attention. Le sigle RPA, en français, est déjà occupé par d’autres domaines, notamment les résidences pour personnes âgées, si bien qu’il ne faut jamais le poser seul dans un texte, sans la forme complète à la première mention. De même, la forme que l’on rencontre automatisation de la robotique des processus est une erreur : la robotique, ce sont les robots physiques, et il s’agit ici de logiciel.

L’autre endroit où les noms se mélangent, c’est l’emploi même du mot « automatisation ». En français, il désigne à la fois la conduite des processus industriels et l’automatisation du travail de bureau, et ce sont deux marchés tout à fait distincts, avec des fournisseurs distincts. Si vous cherchez une offre, il vaut la peine de dire laquelle des deux est visée, faute de quoi une partie des offres reçues viendra d’un tout autre secteur.

Trois affirmations qui, dans les offres, sont fausses

La première, c’est que l’automatisation robotisée des processus serait de l’intelligence artificielle. Ce n’est pas seulement une question de terminologie, parce que des obligations en découlent : un système qui exécute des étapes écrites par un humain ne correspond pas à la définition du système d’IA, et une offre qui fait passer le robot pour de l’intelligence artificielle ou bien vend plus cher qu’il ne faut, ou bien crée des inquiétudes qui n’ont pas de fondement. La deuxième, c’est que l’agent ne serait qu’un chatbot plus intelligent. La différence n’est pas dans l’intelligence, mais dans l’action : le chatbot génère une réponse, l’agent appelle des outils et change l’état d’autres systèmes, et c’est précisément pour cela que l’agent a besoin de limites dont le chatbot n’a pas besoin. Une entreprise qui ne fait pas cette distinction a l’habitude de donner à l’agent un accès auquel personne n’a pensé.

La troisième, c’est que le choix entre ces trois serait un choix entre trois fournisseurs. En réalité, un même outil peut souvent faire les trois : des plateformes nées comme outils de flux de travail proposent aujourd’hui aussi une étape d’agent, et cela veut dire que la question n’est pas quoi acheter, mais comment, dans la solution concrète, le chemin des actions est déterminé.

Comment choisir le mécanisme pour un travail donné

Le choix, dans la pratique, est court si l’on pose les questions dans le bon ordre. Établissez d’abord si les systèmes en jeu ont une interface logicielle, parce que, si c’est le cas, le flux de travail sera presque toujours plus robuste et moins cher à maintenir que la répétition à l’écran, et la question ensuite n’est plus celle du mécanisme, mais celle du volume. S’il n’y a pas d’interface et que le système ne peut pas être changé, alors l’automatisation robotisée des processus est le bon outil, mais en le sachant : le budget doit prévoir la maintenance, et le projet doit avoir un responsable qui répare le robot lorsque l’écran change. Si les données d’entrée sont non structurées, chaque cas diffère et la séquence des étapes ne peut pas s’écrire à l’avance, seulement alors il vaut la peine de regarder du côté de l’agent, et même alors il faut savoir où il s’arrête et qui le supervise.

La solution pratique la plus fréquente est mixte : le flux de travail conduit la chaîne et exécute toutes les étapes prévisibles, mais à un endroit précis il appelle un modèle pour traiter une entrée non structurée, et remet le résultat dans la chaîne. Cela unit la prévisibilité et la souplesse exactement là où cette souplesse est nécessaire, et c’est aussi la moins chère des variantes qui fonctionnent vraiment.

Il y a encore une considération pratique qui tranche souvent le choix plus que la technique. Chacun des trois mécanismes exige un mainteneur différent : un flux de travail peut être maintenu par une personne qui comprend les interfaces des systèmes, le robot a besoin de quelqu’un qui connaît précisément l’outil et les écrans avec lesquels il travaille, mais l’agent a besoin en plus de quelqu’un qui regarde régulièrement ce qu’il fait vraiment. Si, dans l’entreprise, cette personne n’existe pas et qu’il n’est pas prévu d’acheter de la maintenance, alors le choix entre les mécanismes doit commencer par celui que l’on pourra réellement maintenir.

Il vaut aussi la peine de nommer l’erreur qui, dans ce choix, coûte le plus cher, et ce n’est pas le choix du mécanisme, mais l’ordre. Les entreprises ont l’habitude de choisir d’abord l’outil, puis de chercher quoi automatiser avec, et seulement ensuite de comprendre que le processus que l’on voulait automatiser n’est pas encore décrit. L’ordre juste est l’inverse : on décrit d’abord le travail avec ses exceptions, puis on établit si les systèmes ont des interfaces, et seulement alors on choisit le mécanisme, parce qu’à ce moment le choix est en général évident et tient en cinq minutes. Tout aussi fréquente est l’extrême inverse, où l’entreprise attend que tout soit rangé, et ne commence rien. Ici il est utile de se souvenir qu’un flux de travail peut aussi se construire pour un seul petit segment et s’élargir plus tard, et que c’est précisément le premier segment achevé qui montre d’ordinaire où se trouve vraiment le goulot d’étranglement, bien plus précisément que n’importe quelle évaluation préalable.

Il vaut aussi la peine de dire que changer de mécanisme plus tard n’est pas une catastrophe, si le processus lui-même est décrit. Les entreprises ont l’habitude de craindre un mauvais choix comme s’il était irréversible, mais dans la pratique la plus grande valeur du projet est précisément la description du processus avec ses exceptions, et elle reste valable que ce soit un robot, un flux de travail ou un agent qui l’exécute. Changer d’exécutant une fois la description en ordre est bien moins cher que d’écrire la description à nouveau.

Que demander au fournisseur

Si une offre est déjà sur la table, quatre questions suffisent en général pour comprendre ce qu’elle propose vraiment, indépendamment des mots qui sont dans le titre. La première porte sur ce qui décide de l’étape suivante : un script écrit, un graphe dessiné, ou un modèle au moment de l’exécution. C’est précisément cette réponse qui nomme le mécanisme plus précisément que n’importe quel nom de produit dans le titre.

La deuxième, c’est ce qui se passe lorsque quelque chose ne correspond pas à l’attendu, et ici il vaut la peine de demander un exemple concret, non une affirmation générale sur la fiabilité. La troisième, c’est à qui appartiennent les identifiants d’accès et où la solution s’exécute, parce que de cela dépend si le travail continue si les relations avec le fournisseur s’arrêtent. La quatrième, c’est combien coûte la maintenance par an et ce que l’on reçoit exactement pour cela, parce que c’est précisément la maintenance qui est le coût le plus souvent absent des offres.

Si la réponse à l’une de ces questions est floue, cela ne veut pas encore dire que l’offre est mauvaise, mais que l’on n’a pas encore pensé à cette part, et s’accorder là-dessus est bien moins cher avant le contrat qu’après le premier arrêt.

Il est utile aussi de connaître les questions inverses, celles qui ne tranchent rien, bien qu’on les pose souvent. La taille des entreprises que le fournisseur a servies, le nombre d’années passées sur le marché et le nombre de processus qu’il a automatisés renseignent sur l’expérience, mais ne disent pas si le mécanisme concret convient à la tâche concrète. De même, la question de savoir quelle plateforme le fournisseur utilise sert peu, parce qu’une même plateforme peut aujourd’hui fonctionner dans les trois mécanismes, et la réponse à cette question ne vous dit rien de la fragilité de la solution ni du coût de maintenance.

Enfin, il vaut la peine de demander au fournisseur de montrer un exemple déjà en fonctionnement et de raconter ce qui s’y est cassé depuis l’installation, et pourquoi. La réponse à cette question en dit plus sur la qualité du travail du fournisseur que n’importe quelle liste de témoignages, parce que tout ce qui fonctionne assez longtemps casse, et l’important est la vitesse à laquelle on l’a vu et réparé.

Il est honnête de dire aussi notre position, parce qu’elle explique pourquoi cet article est écrit précisément ainsi. Nous ne vendons pas de licences d’automatisation robotisée des processus et nous ne sommes partenaires d’aucune plateforme de ce type, si bien que nous n’avons aucun intérêt à ce que vous choisissiez le mécanisme le plus cher.

Notre travail, c’est l’automatisation des processus métier par des flux de travail et des interfaces entre les systèmes que vous avez déjà, y compris la variante mixte où la chaîne est conduite par un flux de travail et le modèle n’est appelé que dans une seule étape non structurée, et, séparément, les solutions d’IA là où la tâche exige vraiment d’inférer. Si vous avez en ce moment une offre où ces mots sont mélangés, ou si vous ne voyez simplement pas lequel des mécanismes convient à votre tâche, envoyez-nous une description : souvent la réponse est qu’une seule connexion suffit, et c’est la réponse la moins chère que l’on puisse recevoir.