1. Introduction

L’automatisation robotisée des processus a fait une promesse modeste et, pendant un temps, l’a tenue. Là où une personne déplaçait des données entre des systèmes qui ne pouvaient communiquer entre eux, se connectant à un portail, recopiant des chiffres dans un tableur, les saisissant dans un ERP, un robot RPA pouvait apprendre à faire de même, cliquant sur les mêmes boutons dans le même ordre, plus vite et sans se fatiguer. L’attrait tenait à ce qu’elle n’exigeait aucune modification des systèmes sous-jacents : le robot pilotait les écrans existants exactement comme le faisait une personne, de sorte qu’un service pouvait automatiser un processus en quelques semaines sans attendre que l’informatique construise une interface. Sur cette base, la RPA est devenue l’une des technologies d’entreprise les plus rapidement adoptées de la dernière décennie.

Le problème tient au mot robotisée. Un robot RPA ne comprend pas la tâche ; il répète un enregistrement. Il sait que le total de la facture se trouve dans la troisième case du deuxième onglet, non ce qu’est un total de facture, de sorte que lorsque le portail est redessiné et que la case se déplace, le robot ne s’adapte pas, il échoue, et s’il échoue silencieusement il continue à inscrire le mauvais nombre jusqu’à ce que quelqu’un s’en aperçoive. Chaque processus qu’une organisation exécute se situe dans un environnement qui dérive : les logiciels sont mis à jour, les formulaires sont redessinés, les fournisseurs envoient une nouvelle mise en page, une réglementation ajoute un champ, un cas limite survient que l’enregistrement n’a jamais vu. Face à un environnement qui dérive, un jeu de règles figé est un actif qui se déprécie. Le nom que l’industrie donne à cette conséquence est maintenance des robots, et c’est le scandale silencieux du domaine : une large part de l’effort d’un programme RPA mûr va non pas à l’automatisation de nouvelles tâches mais à la réparation d’automatisations que le monde a brisées, de sorte que le coût d’exploitation augmente avec le temps et que l’argumentaire économique s’érode par en dessous.

Cet article porte sur ce qui remplace la RPA, et sur la raison pour laquelle le remplacement est une chose de nature différente plutôt qu’un robot plus rapide. Un agent IA compétent, un modèle capable de lire un écran ou un document, de raisonner sur sa finalité, d’appeler des outils et de vérifier son propre travail, peut accomplir la tâche administrative que faisait la RPA, mais ce n’est pas là l’affirmation intéressante, car faire la même chose fragile avec un moteur plus coûteux n’est pas un progrès. L’affirmation intéressante est qu’un agent peut faire ce qu’un robot est structurellement incapable de faire : il peut améliorer l’automatisation à partir de son propre fonctionnement. Chaque fois qu’il traite un cas, il produit des preuves, ce qu’il a fait, si le résultat a été accepté, là où il a hésité ou a été corrigé, et ces preuves peuvent être réinjectées pour réviser la manière dont l’automatisation se comportera la fois suivante. L’automatisation cesse d’être un enregistrement réalisé une fois et se dégradant ensuite pour devenir une boucle qui s’améliore d’autant plus qu’elle s’exécute. Nous appelons cela l’automatisation récursive, et c’est la première des deux pierres angulaires de l’article.

La seconde pierre angulaire est celle qui rend la première sûre, et sans elle la récursivité est un fardeau plutôt qu’un atout. Une boucle qui modifie son propre comportement à partir de ses propres sorties est, en termes de contrôle, un système à rétroaction, et les systèmes à rétroaction peuvent converger ou s’emballer. Un agent laissé à se régler lui-même contre un signal bruité poursuivra le bruit, optimisera la mesure qu’on lui a donnée plutôt que le résultat qu’elle était censée servir, et régressera de façons que personne n’a choisies. La discipline qui transforme une boucle d’auto-amélioration d’un danger en un moteur fiable d’amélioration n’est pas nouvelle ; l’industrie la possède depuis les années 1920 et l’a formalisée ces trente dernières années sous le nom de Six Sigma, dont le cœur opérationnel est le cycle DMAIC : Définir l’objectif et les tolérances, Mesurer ce qui se produit réellement, Analyser les sources d’erreur et de variation, Améliorer par un changement délibéré, et Maîtriser afin que le gain soit tenu et non perdu. Lu comme une méthodologie de projet, le DMAIC est familier. Lu comme la structure de contrôle d’une automatisation qui s’améliore elle-même, exécutée en continu plutôt qu’une seule fois, il est exactement le régulateur dont la boucle récursive a besoin, et cet appariement est le sujet de cet article.

La contribution est un argument et un petit modèle, non un banc d’essai. La section 2 situe l’affirmation au regard de l’historique de la RPA, de l’automatisation intelligente, de l’amélioration continue et des agents IA. La section 3 expose pourquoi un robot à règles fixes se dégrade, avec un modèle de dérive et de maintenance. La section 4 décrit la boucle récursive qu’un agent rend possible. La section 5 est le cœur de l’article : le DMAIC comme structure de contrôle qui fait converger la boucle, avec la phase de Maîtrise comme cliquet de non-régression. La section 6 dérive la condition de substitution, un unique nombre qui indique quand l’agent dépasse le robot. La section 7 retrace un cas construit de comptes fournisseurs ; les sections 8 à 11 en tirent les conséquences pour la manière de conduire une fonction d’automatisation, répondent aux objections, énoncent les limites et concluent. La question qui traverse tout est : une fois que l’automatisation peut apprendre de sa propre exécution, qu’est-ce qui la maintient dans l’apprentissage de la bonne chose, et quand cela rend-il obsolète le robot enregistré ?

2. Contexte

2.1 La RPA et son plafond

La RPA a été caractérisée dans la littérature des systèmes d’information comme une automatisation « légère » : un logiciel qui opère la couche de présentation des systèmes existants plutôt que leurs données ou leur logique, de sorte qu’elle est déployée par le métier, en dehors du projet informatique traditionnel, sur des back-ends inchangés (van der Aalst, Bichler & Heinzl, 2018 ; Hofmann, Samp & Urbach, 2020). Les premiers retours de terrain étaient véritablement positifs sur le coût et la rapidité (Lacity & Willcocks, 2016 ; Willcocks, Lacity & Craig, 2015). La même littérature, à mesure que le domaine mûrissait, a nommé le plafond. Syed et al. (2020), passant en revue l’état de la recherche et de la pratique en RPA, identifient la dépendance à des entrées stables et structurées et la fragilité des robots face aux changements d’interface et de processus comme des thèmes récurrents et non résolus, et situent la maintenance et la gouvernance parmi les défis centraux du domaine ; Wewerka et Reichert (2023), cartographiant le domaine de manière systématique, recensent la gestion limitée des exceptions et l’effort de maintenance parmi ses problèmes persistants. Le plafond n’est pas un défaut d’un produit particulier ; il est intrinsèque à l’automatisation par imitation de la surface. Un robot encode comment une personne compétente s’est trouvée à cliquer, non ce que la tâche exige, et l’écart entre les deux est exactement la marge dont l’environnement dispose pour la briser.

2.2 De la RPA à l’automatisation intelligente et agentique

Les praticiens ont réagi en greffant de l’intelligence sur le robot : la reconnaissance optique de caractères pour lire les documents, un classifieur pour les trier, un modèle pour traiter l’entrée non structurée que la RPA ne pouvait pas gérer. Cette automatisation intelligente ou hyperautomatisation a élargi l’éventail des entrées qu’un pipeline pouvait accepter, mais elle a laissé la structure de contrôle inchangée, une orchestration fixe aux composants plus intelligents câblés dans des positions fixes, et elle a donc hérité de la même fragilité un cran plus haut. Le basculement plus récent est d’une autre nature. Un agent IA n’occupe pas une position fixe dans un organigramme dessiné à la main ; on lui donne un objectif et un ensemble d’outils et il décide des étapes, ce qui lui permet d’absorber une variation qui aurait brisé une orchestration fixe, et, parce qu’il raisonne sur la tâche plutôt que de rejouer un enregistrement, on peut lui demander d’expliquer, de vérifier et de réviser ce qu’il a fait. La littérature sur les agents en apprentissage automatique en donne la mécanique, entrelaçant le raisonnement et l’usage d’outils (Yao et al., 2023), réfléchissant sur les tentatives échouées pour mieux faire à la suivante (Shinn et al., 2023), ainsi que l’étude plus large des agents autonomes (Wang et al., 2024). Notre intérêt ne porte pas sur le mécanisme dans l’abstrait mais sur une conséquence pour les opérations : l’exécution d’un agent produit des preuves inspectables, et les preuves sont ce dont une boucle a besoin pour s’améliorer.

2.3 L’amélioration continue est plus ancienne que la machine

L’idée qu’un processus devrait être mesuré et amélioré à partir de sa propre sortie n’est pas une idée de l’IA ; c’est le fondement de la gestion de la qualité du vingtième siècle, et l’article s’y appuie délibérément. Shewhart (1931) a distingué la variation inhérente à un processus stable, la cause commune, de la variation assignable, la cause spéciale, qui signale que quelque chose a changé, et a donné la carte de contrôle comme l’instrument qui les départage, afin que l’on réagisse aux déplacements réels et non au bruit, le mode de défaillance exact d’une boucle d’apprentissage non gouvernée ; le traitement statistique moderne est celui de Montgomery (2024). Deming (1986) a bâti le système de management autour d’elle et a popularisé le cycle Planifier-Faire-Étudier-Agir de l’amélioration itérative. Le Six Sigma (Harry & Schroeder, 2000 ; Pyzdek & Keller, 2023) a conditionné la pratique en DMAIC et l’a lié à un taux de défauts quantifié ; les traitements académiques lui donnent une théorie (Linderman et al., 2003) et un compte rendu franc de sa tension avec l’innovation (Benner & Tushman, 2003). Un courant est particulièrement proche de cet article : l’opération évolutionnaire de Box (1957), qui faisait tourner un processus de production comme une expérience lente et continue, ajustant ses réglages et conservant ce qui améliorait mesurablement le rendement, est de l’auto-amélioration récursive sous contrôle statistique, des décennies avant le terme, et c’est le bon ancêtre de ce qu’un agent fait désormais à la vitesse du logiciel.

2.4 Rétroaction, variété et les limites d’une règle fixe

La cybernétique fournit la raison pour laquelle un robot fixe doit perdre face à un monde changeant. La loi de la variété requise d’Ashby (1956) veut qu’un régulateur ne puisse absorber une perturbation qu’en proportion de la variété qu’il peut lui-même produire : seule la variété peut détruire la variété. Un robot RPA n’en a, par construction, presque aucune, une réponse par chemin enregistré, de sorte qu’il ne peut réguler qu’un environnement qui ne quitte jamais ces chemins, et tout environnement réel finit par le faire. Un agent gouverné par une boucle d’apprentissage fabrique de la variété à la demande, générant une réponse à un cas pour lequel il n’a pas été explicitement conçu, ce qui lui permet de suivre une cible mouvante qu’une règle fixe ne peut suivre. Wiener (1948) a donné le récit fondateur du contrôle par rétroaction, et la tradition de l’apprentissage automatique consistant à apprendre d’un signal de récompense (Sutton & Barto, 2018) et celle des organisations qui apprennent en corrigeant l’erreur (Argyris & Schön, 1978) sont le même principe à d’autres échelles. La contribution ici est de réunir ces deux anciens corpus de connaissances sur un objet nouveau : l’agent fournit la variété, et le DMAIC fournit le contrôle qui maintient la variété orientée vers l’objectif.

3. Pourquoi un robot à règles fixes se dégrade

L’argument contre la RPA n’est pas qu’elle échoue le premier jour ; c’est qu’elle est conçue pour être optimale le premier jour et pour se dégrader chaque jour ensuite. Fixez un processus et déployez un robot qui traite correctement une part de ses cas. L’environnement dérive alors, à un certain rythme, en s’éloignant de l’état contre lequel le robot a été enregistré : les formulaires changent, les systèmes sont mis à niveau, de nouvelles variantes d’entrées arrivent, les politiques ajoutent une étape. Chaque incrément de dérive transforme certains cas que le robot savait traiter en cas qu’il traite désormais mal, de sorte que le taux d’erreur du robot augmente à peu près en proportion de la dérive accumulée. Entre les interventions,

où $\varepsilon_0$ est le taux d’erreur au déploiement, $t$ est le temps, et $\delta$ est le taux de dérive, le rythme auquel le monde laisse l’enregistrement derrière lui. La seule chose qui abaisse $\varepsilon^{\mathrm{rpa}}$ est une personne : un ingénieur remarque la défaillance, réenregistre le chemin et ramène le taux d’erreur vers $\varepsilon_0$, à un coût, et jusqu’à la dérive suivante. Le robot trace donc une dent de scie, montant avec la dérive et chutant à chaque réparation manuelle, et ne s’améliorant jamais par rapport à sa conception d’origine, parce que rien en lui n’apprend. Son erreur moyenne sur sa durée de vie est fixée par la vitesse à laquelle le monde bouge ($\delta$) et par la fréquence à laquelle l’organisation peut se permettre d’envoyer quelqu’un le réparer.

Deux traits de ce tableau importent. Premièrement, la maintenance est réactive et sans borne : à mesure qu’un parc de robots grandit, la dérive qu’ils accumulent collectivement grandit avec lui, de sorte que l’effort de maintenance croît avec le nombre d’automatisations plutôt qu’avec le nouveau travail automatisé, ce qui est le mécanisme par lequel le coût d’exploitation d’un programme RPA dépasse ses économies. Deuxièmement, la défaillance est souvent silencieuse : un robot qui inscrit une valeur à partir du mauvais champ ne lève pas d’erreur, il produit un résultat plausible et faux, et le coût de cela n’est borné que par la durée pendant laquelle il passe inaperçu. Une règle fixe dans un monde mouvant n’est pas seulement limitée ; c’est un passif dont l’organisation ne maîtrise pas la taille.

4. L’automatisation récursive : la boucle qu’un robot ne peut fermer

Un agent change le tableau parce que son exécution est une source d’information qui peut être retournée vers l’automatisation elle-même. Lorsqu’un agent traite un cas, il laisse une trace : l’entrée qu’il a vue, les étapes qu’il a choisies, les appels d’outils qu’il a faits, la sortie qu’il a produite, et, surtout, le signal en aval indiquant si cette sortie a été acceptée, corrigée ou annulée. Cette trace est une preuve de là où l’automatisation est forte et de là où elle est faible, et parce que le comportement de l’agent s’exprime dans des éléments qui peuvent être édités, ses instructions, les exemples qu’on lui donne, les outils et vérifications qu’il doit utiliser, l’acheminement des cas difficiles, cette preuve peut être réinjectée sous forme de révision. L’automatisation s’améliore à partir de son propre fonctionnement. Là où l’équation (1) n’a qu’une main externe pour abaisser l’erreur, la boucle récursive l’abaisse de l’intérieur, à chaque cycle :

Ici $\varepsilon_k$ est le taux d’erreur après $k$ cycles, $g \in (0,1)$ est le gain d’amélioration, la fraction de l’erreur remédiable qu’un cycle élimine, et $\varepsilon_\ast$ est le plancher incompressible, le résidu que le processus ne peut évacuer parce qu’il reflète une ambiguïté véritable, une information manquante ou un jugement irréductible, la difficulté essentielle plutôt qu’accidentelle de la tâche. L’itération de l’équation (2) donne la forme close

une chute géométrique de l’erreur initiale jusqu’au plancher. C’est la forme que la tradition de la qualité a toujours visée et la forme qu’un robot ne peut jamais tracer, parce qu’un robot n’a pas de $g$ : son gain d’amélioration est nul, et l’équation (2) se réduit à une constante interrompue seulement par des réinitialisations manuelles. La différence entre la RPA et l’automatisation agentique, dans ce modèle, est la différence entre $g = 0$ et $g > 0$ : entre une automatisation qui ne peut être réparée que de l’extérieur et une qui s’améliore elle-même de l’intérieur.

Trois conditions rendent $g$ positif et le maintiennent ainsi, et toutes trois sont des choses que l’exécution de l’agent fournit et que celle d’un robot ne fournit pas. Il faut un signal : un résultat mesurable pour chaque cas, afin que le meilleur et le pire puissent être distingués. Il faut une preuve attribuable : des traces assez riches pour localiser pourquoi un cas s’est mal passé, non pas seulement qu’il s’est mal passé. Et il faut une surface éditable : des leviers, invites, exemples, outils, acheminement, qu’une révision puisse réellement déplacer. Un agent produit les trois comme sous-produit de son travail ; un robot enregistré n’en produit aucun, ce qui est la raison plus profonde pour laquelle il ne peut apprendre. Mais un $g$ positif n’est pas encore un $g$ sûr. Une boucle qui se révise contre un signal peut tout aussi aisément élever l’erreur que l’abaisser, si le signal est bruité, l’attribution erronée, ou le changement une régression. Rendre $g$ fiablement positif, cycle après cycle, est le rôle de la structure de contrôle, et c’est le DMAIC.

5. Le DMAIC comme structure de contrôle

L’affirmation centrale de l’article est que la discipline qui transforme une boucle d’auto-amélioration d’un péril en un moteur fiable existe déjà, pleinement élaborée, dans le cycle DMAIC du Six Sigma, pourvu qu’on le lise non comme un projet d’amélioration ponctuel mais comme la structure de contrôle permanente de l’automatisation, exécutée en continu. Chaque phase fournit quelque chose dont la boucle récursive de la section 4 a besoin pour maintenir son gain positif et sa direction juste ; la figure 1 dessine le cycle et le tableau 3 associe chaque phase à son rôle.

Définir. La boucle a besoin d’un objectif qui ne soit pas le proxy qu’elle sera tentée de poursuivre. Définir énonce le résultat que l’automatisation sert, les tolérances qui comptent comme succès, et une estimation honnête du plancher $\varepsilon_\ast$ en deçà duquel tout effort supplémentaire est du gaspillage, afin que la boucle optimise le résultat métier et non un substitut commode de celui-ci. La plupart des défaillances de rétroaction emballée sont des défaillances du Définir : la boucle a amélioré exactement ce qu’on lui a dit, qui était la mauvaise chose.

Mesurer. Il n’y a pas de gain d’amélioration sans signal, et Mesurer est la phase qui en fabrique un, instrumentant chaque cas de sorte que le résultat, les corrections et les points d’hésitation soient enregistrés, non échantillonnés par anecdote. C’est la forme moderne de l’intuition de Shewhart selon laquelle on ne peut améliorer ce que l’on ne mesure pas, et c’est aussi là que l’exploration de processus (van der Aalst, 2016) gagne sa place, reconstituant ce que le processus a réellement fait à partir de ses propres journaux d’événements plutôt que de la façon dont on imaginait qu’il tournait.

Analyser. L’erreur caractéristique d’une boucle d’apprentissage est de réagir au bruit comme s’il était signal, se réglant à nouveau contre la dispersion normale d’un processus stable et s’agitant en vain. Analyser est le garde-fou : il sépare la variation de cause commune, à laisser tranquille, de la variation de cause spéciale, sur laquelle agir, et il attribue l’erreur actionnable à une cause assez spécifique pour être corrigée. C’est la distinction de Shewhart (1931) faisant exactement le travail pour lequel elle a été inventée, protégeant désormais une automatisation de la poursuite de sa propre queue.

Améliorer. Ce n’est que maintenant qu’un changement est fait : une révision des instructions de l’agent, de ses exemples, de ses outils, de ses vérifications, ou de l’acheminement qui envoie une classe de cas difficile vers un humain ou vers une voie spécialisée. Améliorer est l’étape de mutation de la boucle, l’endroit où le gain $g$ est réellement réalisé, et il se situe délibérément en aval de la mesure et de l’analyse afin que le changement réponde à une cause diagnostiquée plutôt qu’à une intuition.

Maîtriser. Maîtriser est la phase qui rend l’ensemble sûr, et c’est là que l’automatisation récursive diffère le plus nettement à la fois d’un robot et d’un système d’apprentissage non gouverné. Un changement proposé n’est pas adopté parce qu’il semble meilleur ; il n’est adopté que s’il est mesuré, contre des cas mis de côté, comme n’aggravant pas le résultat, et sinon il est rejeté et la version précédente conservée. Formellement, en écrivant $\widehat{\varepsilon}(m)$ pour l’erreur mesurée d’une révision candidate $m$,

où $\gamma \ge 0$ est une marge de confiance qui empêche la barrière d’être trompée par le bruit. La barrière a un effet précis sur la boucle : elle rend la suite des erreurs monotone en espérance,

de sorte que l’amélioration s’accumule et n’est jamais rendue. C’est ce qui convertit la récursivité brute de l’équation (2) d’une marche aléatoire qui pourrait dériver n’importe où en un cliquet qui ne fait que se resserrer, et c’est la discipline que la maîtrise statistique des procédés a apportée à la fabrication il y a un siècle, désormais appliquée à une automatisation qui se réécrit elle-même. Maîtriser accomplit aussi l’autre moitié, moins glorieuse, de sa tâche : elle standardise et tient le gain, fixant la version améliorée en place avec ses garde-fous de sorte que le cycle suivant parte du nouveau plancher et non de l’ancien.

L’appariement est l’essentiel. La récursivité sans le DMAIC est une boucle qui peut améliorer ou saccager avec une égale facilité ; le DMAIC sans la récursivité est le projet d’amélioration périodique que les équipes qualité ont toujours mené à la main, borné par la fréquence à laquelle les gens peuvent se réunir. Un agent qui exécute le DMAIC comme sa propre structure de contrôle permanente obtient les deux : la rapidité et la portée de l’amélioration logicielle et la garantie de convergence de la maîtrise statistique.

6. La condition de substitution

Nous pouvons maintenant dire précisément quand l’agent dépasse le robot. Les deux automatisations affrontent le même monde en dérive, au même taux de dérive $\delta$. Le robot n’a pas de gain interne et donc, par l’équation (1), son erreur grimpe avec la dérive jusqu’à ce qu’une personne la réinitialise. L’agent exécute sa boucle DMAIC avec un temps de cycle $\tau$, le temps de mesurer, d’analyser, de proposer et de franchir la barrière d’une révision, et un gain par cycle $g$, tandis que la même dérive $\delta$ pousse son erreur vers le haut. Sur un temps continu, les deux forces se combinent :

un terme d’apprentissage tirant l’erreur vers le bas en direction du plancher et un terme de dérive la poussant vers le haut. Son régime permanent, où la boucle suit exactement le rythme du monde, est

de sorte que l’automatisation se tient à une distance bornée au-dessus du plancher, fixée par le rapport de la vitesse à laquelle le monde dérive à la vitesse à laquelle la boucle apprend. Le robot, avec $g \to 0$, n’a aucun régime permanent fini : son erreur n’est bornée que par le calendrier de maintenance. Définissons le nombre de substitution sans dimension

le rapport de l’erreur qu’un cycle élimine à l’erreur que la dérive ajoute sur ce même cycle. Lorsque $\Sigma > 1$, la boucle élimine l’erreur plus vite que l’environnement ne l’injecte et l’automatisation converge vers une bande étroite au-dessus du plancher ; lorsque $\Sigma \gg 1$, elle se tient essentiellement au plancher. L’agent se substitue au robot précisément lorsqu’il peut faire tourner une boucle gouvernée avec $\Sigma > 1$, ce qui est un énoncé portant sur trois quantités maîtrisables : élever le gain $g$ par une meilleure mesure et attribution, raccourcir le cycle $\tau$ par l’automatisation de la boucle elle-même, et l’agent bat tout robot fixe dans tout environnement dont la dérive $\delta$ est finie. La figure 2 oppose les deux trajectoires. La lecture pratique est que la substitution n’est pas une question de savoir si l’agent est plus intelligent que le robot le premier jour, ce qu’il n’est souvent pas, mais de savoir si sa boucle tourne, sous contrôle, plus vite que ne tourne le monde ; et une fois que c’est le cas, la dent de scie du robot et la descente de l’agent divergent pour de bon.

7. Un cas construit : les comptes fournisseurs

Le cas est construit, non observé : ses chiffres sont illustratifs et cohérents en interne, et il vise à montrer les quantités du modèle prenant des valeurs plausibles, non à rapporter un résultat. Considérons la fonction comptes fournisseurs d’un groupe de taille moyenne qui reçoit des factures de fournisseurs sous de nombreux formats à travers plusieurs portails et doit rapprocher chacune d’un bon de commande et d’un bon de réception, la coder et l’enregistrer pour paiement. C’est la cible archétypale de la RPA, à fort volume, descriptible par des règles, ennuyeuse, et la déception archétypale de la RPA, parce que les formats dérivent constamment et que chaque fournisseur est une exception qui ne demande qu’à survenir.

Le parc RPA du groupe traite les mises en page de fournisseurs les plus propres et achemine tout le reste vers des personnes. Au déploiement, il enregistrait environ 55 pour cent des factures en traitement direct, mais au cours de dix-huit mois trois mises à jour de portail et une vague de nouveaux fournisseurs ont fait baisser le taux de traitement direct et monter le taux d’erreur silencieuse, de sorte qu’une équipe permanente passe une grande partie de sa semaine à réenregistrer des robots cassés et à traquer des erreurs d’enregistrement, le tableau 1 donne la colonne avant. Remplacer les robots enregistrés par un agent qui lit chaque facture pour ce qu’elle est, la rapproche par raisonnement plutôt que par coordonnées fixes, et achemine les exceptions véritables vers une personne, et envelopper cet agent dans une boucle DMAIC permanente, le taux de traitement direct est la chose que Mesurer suit, les corrections de chaque semaine sont la preuve sur laquelle Analyser travaille, les invites, exemples et vérifications de rapprochement de l’agent sont ce qu’Améliorer révise, et un échantillon mis de côté est la barrière qu’applique Maîtriser, change à la fois le niveau et sa direction. L’agent démarre à peine mieux que le robot mais, parce que sa boucle tourne plus vite que ne dérivent les portails ($\Sigma > 1$), son taux d’exception baisse de cycle en cycle vers le plancher fixé par les factures qui requièrent véritablement un jugement humain, tandis que la charge de maintenance s’inverse : au lieu d’ingénieurs réparant des enregistrements, le travail devient la revue des changements proposés par la boucle à la barrière de Maîtrise. Le tableau 1 retrace les quantités du modèle à travers le cas.

8. Ce qui change pour le modèle opérationnel

Substituer un agent à un robot n’est pas un échange à l’identique de moteurs sous le même capot ; cela change ce que fait la fonction d’automatisation et ce en quoi elle doit exceller. Le tableau 2 place les deux côte à côte. Le plus grand changement concerne l’endroit où va l’effort humain. Sous la RPA, le travail humain récurrent est la réparation : trouver et réenregistrer les robots que le monde a brisés, une tâche réactive qui croît avec la taille du parc et ne produit rien de neuf. Sous un agent gouverné par le DMAIC, le travail humain récurrent est la barrière de Maîtrise : revoir les révisions proposées par la boucle et décider de ce qui est validé, une tâche qui croît avec le rythme d’amélioration plutôt qu’avec la taille du parc et qui produit une meilleure automatisation à chaque fois qu’elle est accomplie. Les compétences changent en conséquence, de l’écriture de scripts de robots contre des écrans à la définition de résultats, à l’instrumentation de processus et au jugement de preuves, c’est-à-dire de l’ingénierie de l’automatisation vers la discipline de la gestion de la qualité, désormais menée à la vitesse du logiciel.

Il y a un second changement, dans la gouvernance. Un système qui réécrit son propre comportement est plus puissant qu’un enregistrement et exige plus de reddition de comptes, non moins, et le DMAIC fournit la piste d’audit comme sous-produit : chaque changement validé répond à une cause mesurée, a franchi une barrière enregistrée, et peut être attribué et annulé, de sorte qu’une automatisation qui s’améliore elle-même est, bien conduite, plus inspectable que le robot opaque qu’elle remplace, et non moins. La phase de Maîtrise est autant un instrument de conformité qu’un instrument de qualité. Cela importe le plus là où l’automatisation touche à des tâches réglementées, et c’est la même discipline, le changement mesuré derrière une barrière, que nous avons défendue ailleurs dans nos recherches sur l’informatique réglementée.

9. Objections et réponses

Un agent est bien plus coûteux par cas qu’un robot. Par cas, aujourd’hui, souvent oui, et pour une tâche étroite, stable, à fort volume dont l’environnement ne dérive véritablement pas, un robot enregistré peut rester le choix économique, et rien ici ne dit le contraire. L’argument mord là où l’environnement dérive, ce qui est la plupart des endroits, parce que là le vrai coût du robot n’est pas son prix par cas mais sa traîne de maintenance et ses erreurs silencieuses, et la boucle de l’agent paie son coût unitaire plus élevé en éliminant les deux. La comparaison à faire est le coût sur la durée de vie face à un environnement en dérive, non le coût unitaire le premier jour.

Ce n’est que de la RPA avec un modèle greffé dessus, ce que les fournisseurs vendent déjà. C’est l’inverse. Greffer un modèle dans une orchestration fixe, l’automatisation intelligente telle qu’elle est couramment vendue, conserve la structure de contrôle fragile et rend ses composants plus intelligents, de sorte qu’elle relève un peu le plafond et hérite de la dégradation. L’affirmation ici porte sur la structure de contrôle elle-même : remplacer l’orchestration fixe par une boucle gouvernée qui réécrit l’automatisation à partir de sa propre sortie. Le moteur est la plus petite moitié du changement ; la boucle en est la plus grande.

Un système qui s’améliore lui-même en changeant son propre comportement est un risque que l’on ne peut gouverner. C’est un risque, et non gouverné c’en est un sérieux, ce qui est toute la raison pour laquelle la seconde pierre angulaire de l’article est une discipline de contrôle et non un modèle. Un agent qui se règle à nouveau contre un signal bruité sans phase d’Analyse et sans barrière de Maîtrise va en effet dériver et régresser. La réponse n’est pas d’interdire la boucle mais de la gouverner avec la méthode que la fabrication utilise pour gouverner les processus à auto-ajustement depuis un siècle : mesurer, séparer le signal du bruit, changer contre une cause diagnostiquée, et ne valider que ce qu’une barrière prouve ne pas aggraver les choses. Une boucle gouvernée est plus redevable qu’un robot, non moins.

Votre modèle est trop simple ; l’erreur réelle ne décroît pas géométriquement. Le modèle est une simplification délibérée et ses constantes ne sont pas mesurées ; son but est de rendre la structure lisible, qu’un robot a $g = 0$ et qu’un agent gouverné a $g > 0$, et que la substitution se joue sur la question de savoir si la boucle devance la dérive. La forme géométrique est le comportement générique d’un contrôleur proportionnel face à un plancher, non une loi empirique précise, et la section 10 le dit. Le nombre de substitution $\Sigma$ est pensé comme une manière de penser, non comme un chiffre à citer à trois décimales.

10. Limites

Il s’agit d’un argument destiné aux praticiens, doté d’un modèle délibérément simple, et ses limites devraient être claires. Le modèle des sections 3 à 6 est illustratif : la dérive linéaire de l’équation (1), le gain constant de l’équation (2) et le plancher unique $\varepsilon_\ast$ sont des simplifications choisies pour la lisibilité, et la dérive réelle est irrégulière, le gain réel diminue à mesure que le plancher approche, et le plancher lui-même se déplace à mesure que la tâche change ; le nombre de substitution $\Sigma$ est une loupe, non une quantité mesurée, et nous ne l’avons pas estimé sur des données de terrain. L’argument est circonscrit aux processus qui dérivent et qui portent un signal de résultat utilisable ; une tâche véritablement stationnaire, à fort volume, peut encore favoriser un robot enregistré, et un processus sans résultat mesurable prive la boucle du signal dont dépend tout le mécanisme. L’affirmation porte sur une structure de contrôle, non sur un produit, et la technologie d’agent spécifique est naissante et évolue vite ; un lecteur devrait conserver la structure, une boucle récursive gouvernée bat une règle figée dans un monde mouvant, et réexaminer les composants à mesure qu’ils changent. Enfin, le gain n’est jamais plus honnête que les phases de Mesure et de Maîtrise : une organisation qui instrumente mal, ou qui laisse la barrière se dégrader en tampon de pure forme, obtiendra les risques de la récursivité sans sa convergence, ce qui est une raison de prendre la discipline au sérieux, non un défaut de l’idée.

11. Conclusion

L’automatisation robotisée des processus a fait quelque chose d’utile en enregistrant la façon dont une personne pilote un système et en la rejouant, mais elle a automatisé la surface d’une tâche et l’a figée, et une règle figée dans un monde mouvant se dégrade : son erreur grimpe avec la dérive, sa facture de maintenance monte avec son parc, et ses pires défaillances sont silencieuses. Les agents IA s’y substituent non en rejouant les mêmes règles avec un moteur plus coûteux mais en fermant une boucle qu’un enregistrement ne peut fermer, améliorant l’automatisation à partir de sa propre exécution, cycle après cycle. Cette récursivité est la première pierre angulaire et, seule, autant péril qu’aide. La seconde pierre angulaire est ce qui la rend fiable : le cycle DMAIC, lu non comme un projet ponctuel mais comme la structure de contrôle permanente de l’automatisation, Définir l’objectif et le plancher, Mesurer chaque cas, Analyser le signal du bruit, Améliorer contre une cause diagnostiquée, et Maîtriser avec une barrière qui ne valide que ce qui n’aggrave pas mesurablement les choses, de sorte que l’amélioration devient un cliquet et non un pari. Dans le modèle de l’article, la différence est la différence entre un gain d’amélioration nul et un gain maintenu fiablement positif, et l’agent dépasse le robot exactement lorsque sa boucle gouvernée élimine l’erreur plus vite que le monde ne l’injecte. L’ingénierie qui suit porte moins sur le modèle qui lit la facture que sur la boucle construite autour de lui, et la discipline dont cette boucle a besoin est une que l’industrie possède depuis un siècle et peut désormais exécuter à la vitesse du logiciel. Automatisez la tâche, mesurez ce qui se produit, améliorez contre ce que vous mesurez, et ne laissez rien changer l’automatisation qu’une barrière n’a pas montrée meilleure. Un robot est une photographie d’un processus ; un agent gouverné est le processus qui apprend. C’est cela, la substitution, et c’en est le tout.

Annexe A. Exécuter le DMAIC comme la boucle de contrôle d’une automatisation

Les pratiques ci-dessous sont ce qui maintient une automatisation récursive dans la convergence plutôt que dans la dérive. Aucune n’est propre à l’IA ; chacune est la tradition de la qualité appliquée à une automatisation qui se réécrit elle-même.

Références

Argyris, C., & Schön, D. A. (1978). Organizational learning: A theory of action perspective. Addison-Wesley. ISBN 978-0-201-00174-3.

Ashby, W. R. (1956). An introduction to cybernetics. Chapman & Hall. http://pcp.vub.ac.be/books/IntroCyb.pdf

Benner, M. J., & Tushman, M. L. (2003). Exploitation, exploration, and process management: The productivity dilemma revisited. Academy of Management Review, 28(2), 238–256. https://doi.org/10.2307/30040711

Box, G. E. P. (1957). Evolutionary operation: A method for increasing industrial productivity. Journal of the Royal Statistical Society: Series C (Applied Statistics), 6(2), 81–101. https://doi.org/10.2307/2985505

Deming, W. E. (1986). Out of the crisis. MIT Center for Advanced Engineering Study. ISBN 978-0-911379-01-0.

Harry, M. J., & Schroeder, R. (2000). Six Sigma: The breakthrough management strategy revolutionizing the world’s top corporations. Currency/Doubleday. ISBN 978-0-385-49437-3.

Hofmann, P., Samp, C., & Urbach, N. (2020). Robotic process automation. Electronic Markets, 30(1), 99–106. https://doi.org/10.1007/s12525-019-00365-8

Lacity, M., & Willcocks, L. P. (2016). Robotic process automation at Telefónica O2. MIS Quarterly Executive, 15(1), 21–35. https://aisel.aisnet.org/misqe/vol15/iss1/4/

Linderman, K., Schroeder, R. G., Zaheer, S., & Choo, A. S. (2003). Six Sigma: A goal-theoretic perspective. Journal of Operations Management, 21(2), 193–203. https://doi.org/10.1016/S0272-6963(02)00087-6

Montgomery, D. C. (2024). Introduction to statistical quality control (8th ed.). Wiley. ISBN 978-1-119-72309-7.

Pyzdek, T., & Keller, P. A. (2023). The Six Sigma handbook (6th ed.). McGraw-Hill. ISBN 978-1-26-514399-2.

Shewhart, W. A. (1931). Economic control of quality of manufactured product. D. Van Nostrand. ISBN 978-0-87389-076-2 (ASQ reprint).

Shinn, N., Cassano, F., Gopinath, A., Narasimhan, K., & Yao, S. (2023). Reflexion: Language agents with verbal reinforcement learning. In Advances in Neural Information Processing Systems 36 (NeurIPS 2023). https://arxiv.org/abs/2303.11366

Sutton, R. S., & Barto, A. G. (2018). Reinforcement learning: An introduction (2nd ed.). MIT Press. ISBN 978-0-262-03924-6.

Syed, R., Suriadi, S., Adams, M., Bandara, W., Leemans, S. J. J., Ouyang, C., ter Hofstede, A. H. M., van de Weerd, I., Wynn, M. T., & Reijers, H. A. (2020). Robotic process automation: Contemporary themes and challenges. Computers in Industry, 115, 103162. https://doi.org/10.1016/j.compind.2019.103162

van der Aalst, W. M. P. (2016). Process mining: Data science in action (2nd ed.). Springer. https://doi.org/10.1007/978-3-662-49851-4

van der Aalst, W. M. P., Bichler, M., & Heinzl, A. (2018). Robotic process automation. Business & Information Systems Engineering, 60(4), 269–272. https://doi.org/10.1007/s12599-018-0542-4

Wang, L., Ma, C., Feng, X., Zhang, Z., Yang, H., Zhang, J., Chen, Z., Tang, J., Chen, X., Lin, Y., Zhao, W. X., Wei, Z., & Wen, J.-R. (2024). A survey on large language model based autonomous agents. Frontiers of Computer Science, 18(6), 186345. https://doi.org/10.1007/s11704-024-40231-1

Wewerka, J., & Reichert, M. (2023). Robotic process automation: A systematic mapping study and classification framework. Enterprise Information Systems, 17(2), 1986862. https://doi.org/10.1080/17517575.2021.1986862

Wiener, N. (1948). Cybernetics: Or control and communication in the animal and the machine. MIT Press. ISBN 978-0-262-73009-9.

Willcocks, L. P., Lacity, M., & Craig, A. (2015). The IT function and robotic process automation (The Outsourcing Unit Working Research Paper Series). London School of Economics and Political Science, LSE Research Online item 64519. http://eprints.lse.ac.uk/64519/

Yao, S., Zhao, J., Yu, D., Du, N., Shafran, I., Narasimhan, K., & Cao, Y. (2023). ReAct: Synergizing reasoning and acting in language models. In International Conference on Learning Representations (ICLR 2023). https://arxiv.org/abs/2210.03629