Blog · IA & décision

Agent IA ou RPA : quelle automatisation pour la supply chain ?

La RPA automatise des tâches répétitives à règles fixes, un agent IA traite une situation nouvelle et prend une décision bornée. Glossaire comparatif : ce que chacun fait, quand la RPA suffit, quand elle casse, et pourquoi les deux cohabitent dans une supply chain.

Par Nelson Mukuze, CTO & CAIO, cofondateur de Clevizio·Publié le 19 septembre 2026·7 min de lecture

Agent IA ou RPA : quelle automatisation pour la supply chain ?

L'essentiel

RPA : définition et ce qu'elle automatise

La RPA, pour robotic process automation, désigne des robots logiciels qui reproduisent ce qu'un opérateur fait à l'écran : ouvrir une application, lire un champ, le copier dans une autre, cliquer sur valider, selon un script écrit à l'avance et exécuté à l'identique. Les éditeurs les plus connus sont UiPath, Automation Anywhere et Blue Prism, et la catégorie a prospéré parce qu'elle permet d'automatiser sans toucher aux systèmes existants, en passant par leur interface plutôt que par une intégration. En supply chain, les cas classiques sont la saisie dans l'ERP d'un accusé de réception fournisseur reçu par mail, la création de commandes à partir d'un fichier client et le rapprochement entre bon de livraison et facture. On y ajoute la récupération des statuts de suivi sur les portails transporteurs, ou l'extraction hebdomadaire d'un rapport de stock vers un tableur. Le robot fait exactement ce qu'on lui a dit, autant de fois qu'on veut, sans fatigue et sans écart, et cette prévisibilité est sa qualité première. Une RPA bien construite est auditable ligne par ligne, ce qu'aucun système à base de modèle de langage ne peut prétendre au même degré.

Agent IA : définition et ce qu'il fait de plus

Un agent IA est un système construit autour d'un objectif et d'une boucle : il perçoit un état, décide de la prochaine étape, agit à travers des outils, observe le résultat et recommence jusqu'à ce que l'objectif soit atteint ou qu'une condition d'arrêt se déclenche. Le composant qui choisit l'étape suivante est le plus souvent un modèle de langage, ce qui lui donne deux capacités que la RPA n'a pas. Il lit une entrée qui n'a pas de format fixe, un mail rédigé librement ou un document jamais vu, et il choisit entre plusieurs actions selon la situation plutôt que selon un embranchement prévu dans un script. La différence tient en une phrase que je répète aux équipes : la RPA suit un chemin, l'agent poursuit un but. Cette capacité a un prix, l'agent est probabiliste, il peut se tromper avec assurance, et il coûte plus cher à chaque exécution qu'un script. Elle a aussi une condition, l'agent doit être borné par un périmètre d'outils, des seuils de validation et un journal complet, faute de quoi sa liberté d'action devient une liberté d'erreur. Un agent sérieux confie par ailleurs tout calcul, un impact en euros ou une couverture en jours, à un moteur déterministe, et réserve le modèle à l'interprétation et au choix de l'étape.

Règle fixe contre situation nouvelle : la ligne de partage

Le critère pour choisir entre les deux est plus simple que ne le laissent penser les présentations commerciales, et il tient en deux questions. L'entrée est-elle structurée, c'est-à-dire toujours au même format, dans les mêmes champs ? Et la décision est-elle énumérable, c'est-à-dire peut-on écrire à l'avance tous les cas et ce qu'il faut faire dans chacun ? Si les deux réponses sont oui, la RPA est le bon outil, elle sera moins chère, plus rapide et plus fiable qu'un agent. Dès qu'une réponse est non, il faut un agent, ou un humain. L'accusé de réception fournisseur illustre bien la ligne : tant qu'il arrive dans un fichier EDI ou un PDF au gabarit constant, un robot le saisit. Le jour où il arrive sous la forme d'un mail qui dit que la moitié partira jeudi et le reste « dans le courant de la semaine prochaine, sous réserve de la matière », le robot s'arrête ou, pire, saisit une date fausse. Il faut alors quelqu'un ou quelque chose qui comprenne la phrase, en déduise deux livraisons partielles avec une date incertaine, et décide s'il faut relancer. Dans la plupart des processus supply chain, on trouve les deux régimes côte à côte, la routine structurée et l'exception rédigée, et c'est ce mélange qui explique que ni l'un ni l'autre ne suffise seul.

Quand la RPA suffit, quand elle casse

La RPA suffit, et je la recommande sans hésiter, sur les tâches à volume élevé, à format stable, à règle documentée et à faible enjeu, où le coût d'une erreur est une ressaisie et non une décision fausse. Cela couvre les saisies de statuts, les rapprochements, les extractions, les transferts entre deux systèmes qui ne se parlent pas. Elle casse dans trois situations bien identifiées. Quand l'interface change, un champ déplacé dans une mise à jour de l'ERP ou du portail suffisant à arrêter le robot, ce qui crée une charge de maintenance que les projets sous-estiment presque toujours. Quand l'exception arrive, parce qu'un script ne sait pas quoi faire d'un cas qu'on n'a pas prévu, et qu'il le traite soit en s'arrêtant, soit en appliquant la branche par défaut, ce qui est la manière la plus discrète de saisir une mauvaise donnée avec assurance. Et quand la tâche demande de juger, par exemple de décider si un retard signalé mérite une relance, une source alternative ou rien, parce qu'un jugement suppose de peser des éléments que le script ne voit pas. Le signe qu'une RPA a dépassé son domaine se lit dans les files d'exceptions : quand la liste des cas que le robot n'a pas su traiter grandit plus vite que ce qu'il traite, on a automatisé le mauvais morceau du processus.

Pourquoi les deux cohabitent

L'architecture que je considère comme saine ne remplace pas la RPA par des agents, elle les empile. Les robots RPA restent les mains, la couche qui sait agir dans des systèmes anciens sans API, saisir, extraire et transférer de façon déterministe. L'agent est la tête, la couche qui lit ce qui n'a pas de format, décide de l'étape suivante et appelle les robots comme des outils, au même titre qu'il appelle un calculateur ou une messagerie. Dans le cas de l'accusé de réception ambigu, l'agent interprète le mail, en déduit deux dates dont une incertaine, chiffre l'exposition avec un moteur déterministe, décide de relancer et demande au robot de saisir dans l'ERP ce qui est certain, en marquant le reste à confirmer. Cette répartition évite deux erreurs symétriques. La première consiste à utiliser un agent là où une règle suffit, ce qui coûte cher et introduit de l'aléa dans une tâche qui n'en avait pas ; la seconde à demander à un robot de décider, ce qu'il fait toujours de la même façon, y compris quand c'est faux. Elle a aussi un avantage d'exploitation qu'on découvre en production : le journal du robot est exhaustif, celui de l'agent explique ses choix, et la lecture des deux ensemble permet de rejouer un incident de bout en bout.

Glossaire express des termes qu'on vous servira

Quelques définitions pour tenir une réunion avec un éditeur sans se laisser impressionner. Un robot logiciel est un script qui manipule des applications par leur interface ; il est dit assisté quand un opérateur le déclenche et surveille, non assisté quand il tourne seul sur un serveur. L'orchestrateur est le composant qui planifie, lance et journalise les robots, et c'est lui qu'il faut regarder pour juger de la maturité d'une plateforme RPA. Le traitement intelligent de documents, ou IDP, désigne l'extraction de données de documents non structurés par des modèles, souvent vendue comme la porte d'entrée de l'IA dans la RPA, et c'est une brique de perception, pas un agent. L'hyperautomation est un terme d'analystes pour désigner la combinaison de tout cela, et il ne décrit aucun produit précis. Un outil, au sens des agents, est une fonction que l'agent a le droit d'appeler, un robot RPA pouvant en être un. Un garde-fou est une règle qui limite ce que l'agent peut faire seul, seuil, périmètre ou validation obligatoire, et l'expression « humain dans la boucle » désigne le point du processus où une personne valide avant l'action. Automatiser le routinier ne supprime pas l'imprévu ; ce qui distingue les deux familles, au fond, c'est ce qui se passe le jour où le script rencontre un cas qu'il n'a jamais vu, et c'est sur cette question qu'il faut interroger le fournisseur.