Règles, RPA ou IA : comment choisir pour automatiser une tâche

« On veut automatiser la saisie des commandes. » D'accord. Mais avec quoi ? Un dirigeant qui pose cette phrase imagine souvent une seule chose sous le mot automatisation, un robot magique qui fait tout. La réalité est plus terre à terre, et plus intéressante : il existe trois façons très différentes d'y arriver, et le bon choix dépend entièrement de la tête de la tâche.

Se tromper de famille, ça coûte cher. On voit des projets partir sur de l'IA là où trois lignes de code auraient suffi, et d'autres s'entêter sur un script rigide qui casse chaque fois qu'un fournisseur change son modèle de facture. Résultat : du budget brûlé, une équipe déçue, et l'idée tenace que « l'automatisation, ça ne marche pas chez nous ».

On va poser les trois approches à plat. Les règles, le RPA, l'IA. Ce qu'elles savent faire, ce qu'elles coûtent, où elles cassent. Puis un arbre de décision concret pour trancher, tâche par tâche. Et on finira par le point qu'on répète le plus souvent en clientèle : dans la vraie vie, on les mélange.

Trois familles qu'on met dans le même sac

Commençons par la vue d'ensemble, parce qu'elle éclaire tout le reste. Les trois approches se rangent sur une échelle simple, du plus rigide au plus souple.

Les règles (des scripts, des automatismes « si ceci, alors cela ») sont la base. Déterministes, rapides, très peu chères, elles font exactement ce qu'on leur dit. Rien de plus, rien de moins. Le RPA vient au-dessus : un logiciel robot qui imite les clics et les frappes d'un humain dans une interface, utile quand un vieux logiciel n'offre aucune autre porte d'entrée. Enfin l'IA, les modèles de langage comme Claude d'Anthropic, capable de comprendre du texte désordonné, de saisir un sens, de décider dans le flou.

Plus on monte, plus c'est souple. Et moins c'est prévisible. Cette tension résume à peu près tout le sujet. Une règle fait toujours pareil, pour le meilleur et pour le pire. Une IA s'adapte, mais elle peut aussi vous surprendre. Le métier consiste à placer le curseur au bon endroit pour chaque tâche.

Les règles : la mécanique bête et fiable

Une automatisation par règles, c'est de la logique explicite écrite noir sur blanc. Un développeur, ou un outil no-code comme n8n, Make ou Zapier, enchaîne des conditions : si le fichier arrive dans ce dossier, alors le renommer et l'envoyer par mail. Si le montant dépasse 5 000 €, alors demander une validation. Une macro VBA dans Excel, une synchronisation par API entre Sage et un site e-commerce, un cron qui exporte un CSV chaque nuit : tout ça, ce sont des règles.

Le gros avantage tient en un mot : déterminisme. À entrée identique, sortie identique, à chaque fois, pour toujours. Vous pouvez auditer la logique ligne par ligne, la tester, la certifier. Pour tout ce qui touche à la comptabilité, à la paie, à une norme qualité type ISO 9001, cette prévisibilité vaut de l'or. Personne n'a envie d'une IA créative sur un calcul de TVA.

C'est aussi l'approche la moins chère. Une fois écrite, une règle tourne quasiment gratuitement. Pas de tokens à payer, pas de licence robot par poste, juste un peu de serveur. Pour une tâche stable et répétitive, rien ne bat un bon script.

Là où le bât blesse : la rigidité. Une règle ne comprend rien. Elle applique une recette. Le jour où un fournisseur déplace la colonne « référence » dans son export, ou passe son numéro de facture de huit à neuf chiffres, votre script trébuche. Il ne s'adapte pas, il casse. Parfois bruyamment, avec une erreur bien visible. Parfois en silence, en rangeant des données au mauvais endroit pendant trois semaines avant que quelqu'un s'en aperçoive.

Donc la question à se poser est simple. Le format d'entrée est-il stable ? Si oui, les règles sont souvent la meilleure réponse, la plus solide et la plus économique. Si le format part dans tous les sens, elles vont vous faire souffrir.

Le RPA : le robot qui clique à votre place

Le RPA, pour Robotic Process Automation, répond à un problème très concret et très fréquent dans l'industrie : le vieux logiciel qui ne parle à personne. Un ERP maison des années 2000, un applicatif métier sur AS/400, un portail fournisseur sans API, un logiciel de gestion qu'on ne peut ni exporter ni brancher proprement. Que faire quand aucune porte d'entrée technique n'existe ?

On passe par la porte des humains : l'écran. Un robot RPA (UiPath, Automation Anywhere, Power Automate Desktop de Microsoft) enregistre et rejoue une suite de gestes. Il ouvre le logiciel, clique dans le champ « client », tape la référence, valide, passe à l'écran suivant. Exactement ce que ferait une personne, à la souris et au clavier, mais sans pause déjeuner et sans faute de frappe.

C'est puissant pour une raison précise : le RPA ne demande aucune modification du logiciel cible. Il travaille par-dessus, en surface. Pas besoin que l'éditeur ouvre une API, pas besoin de toucher aux entrailles d'un système fragile que personne n'ose plus modifier. Pour connecter deux applications qui s'ignorent, c'est parfois la seule voie raisonnable.

Mais le RPA partage un défaut avec les règles, en pire. Il est fragile face au changement d'interface. Le robot repère les champs par leur position ou leur libellé à l'écran. L'éditeur pousse une mise à jour, déplace un bouton, renomme un onglet, et le robot clique dans le vide. Il faut alors le reparamétrer. Sur un parc de robots, cette maintenance devient un vrai poste de coût qu'on sous-estime presque toujours au démarrage.

Autre limite : le RPA ne comprend rien non plus. Il déplace de l'information d'un écran à un autre, mais il ne saisit pas le sens de ce qu'il transporte. Donnez-lui une donnée propre et bien rangée, il excelle. Donnez-lui un email en texte libre à interpréter, il est perdu. C'est un exécutant discipliné, pas un cerveau. On développe ce point dans notre comparatif dédié entre RPA et IA dans l'automatisation industrielle.

L'IA : celle qui comprend le désordre

L'IA générative, portée par les modèles de langage, joue dans une autre catégorie. Sa force, c'est le non structuré. Le texte libre, le document mal cadré, l'exception, l'ambiguïté. Tout ce qui fait trébucher une règle ou un robot RPA.

Un exemple parle mieux qu'une définition. Un client vous écrit : « Bonjour, suite à notre échange, pouvez-vous me refaire le devis d'octobre avec 3 palettes au lieu de 2, et livrer sur le dépôt de Lyon cette fois. » Aucune règle ne sait lire ça. Aucun robot RPA non plus. Une IA, oui. Elle comprend qu'il s'agit d'une modification de commande, retrouve le devis, ajuste la quantité, note le changement d'adresse. Elle manipule du sens, pas des positions d'écran.

Ce que l'IA sait faire et que les deux autres ignorent : lire un email et deviner son intention, extraire les lignes d'une facture même mal scannée, classer une réclamation, résumer un cahier des charges, rédiger un premier jet de réponse. Elle absorbe la variété. Un fournisseur change son modèle de facture ? L'IA s'en moque, elle lit le contenu, pas le gabarit.

Cette souplesse a un revers qu'il faut regarder en face. L'IA est moins prévisible. Sur deux documents presque identiques, elle peut réagir légèrement différemment. Elle peut aussi se tromper avec aplomb, inventer une référence, mal lire un montant. On appelle ça une hallucination, et c'est le vrai sujet quand on met de l'IA en production. Elle ne remplace pas une règle sur un calcul exact ; elle brille là où il faut interpréter.

Elle coûte aussi plus cher à l'usage qu'une règle. Chaque document traité consomme des tokens facturés par l'éditeur du modèle. Rien d'astronomique sur les volumes d'une PME, mais ce n'est plus le quasi-gratuit d'un script. Et il faut l'encadrer : des garde-fous, une validation humaine sur ce qui engage l'entreprise, un choix de modèle selon l'enjeu du document. C'est tout le sens du travail avec un développement d'automatisation sur mesure plutôt qu'un branchement brut sur une interface grand public.

Le tableau qui les sépare

Pour fixer les idées, la comparaison ligne à ligne. Elle vaut mieux qu'un long discours.

Une nuance honnête : ces cases ne sont pas étanches. Un outil no-code moderne mélange déjà règles et appels d'IA dans un même flux, et certaines plateformes RPA embarquent des briques d'IA pour lire des documents. La frontière bouge. Mais pour raisonner sur un projet, cette séparation en trois tient très bien.

L'arbre de décision : quelle approche pour quelle tâche

Voici la méthode qu'on applique pour trancher. On la déroule dans l'ordre, question après question. La première qui donne un oui franc désigne l'approche.

Question 1. Les données d'entrée sont-elles structurées et stables ? Un tableur toujours au même format, un flux API propre, des champs qui ne bougent pas. Si oui, partez sur des règles. C'est le moins cher, le plus fiable, le plus facile à auditer. N'ajoutez pas d'IA là où un « si-alors » suffit : ce serait payer une Ferrari pour aller chercher le pain.

Question 2. La donnée est-elle propre, mais coincée dans un logiciel sans porte d'entrée ? Le contenu est clair, structuré, mais l'application refuse toute connexion, pas d'API, pas d'export exploitable. C'est le terrain du RPA. Le robot ira cliquer là où aucun autre outil ne peut entrer. Vérifiez juste que l'interface est assez stable pour ne pas passer votre vie à reparamétrer.

Question 3. Faut-il comprendre du texte, un document, une intention ? L'entrée est en langage humain, désordonnée, variable d'un cas à l'autre. Là, ni règle ni robot ne s'en sortent seuls. Il faut de l'IA pour saisir le sens. C'est le cas des emails de commande, des devis en texte libre, des réclamations, des factures qui ne se ressemblent jamais.

Pour rendre ça encore plus opérationnel, voici la checklist qu'on garde en tête quand on regarde une tâche :

• Format d'entrée figé, logique simple ? Règles. Un cron, une macro, un scénario n8n suffisent.
• Logiciel ancien sans API, mais données propres ? RPA. Le robot fait le pont par l'écran.
• Du texte à lire, une exception à juger ? IA. Elle absorbe la variété que les autres refusent.
• Un calcul qui doit être exact à 100 % ? Règles, jamais d'IA seule dessus.
• Un enjeu réglementaire ou comptable ? Règles pour le calcul, IA seulement pour préparer, humain pour valider.
• Un volume énorme de documents variés ? IA en tête de chaîne, règles derrière pour contrôler.

Un réflexe utile : toujours descendre l'échelle avant de la monter. Se demander d'abord si une règle suffit. Puis si le RPA fait l'affaire. Et n'appeler l'IA que pour la part qui exige vraiment de comprendre. C'est le contraire du réflexe à la mode, qui met de l'IA partout parce que c'est le mot qui fait vendre. Mettre de l'IA sur une tâche déterministe, c'est ajouter du coût et de l'imprévisibilité pour rien.

Pourquoi on les combine presque toujours

Voilà le point qu'on tient à faire passer, parce qu'il change la façon de voir un projet. Dans la vraie vie, on ne choisit quasiment jamais une seule brique. On les assemble. Une automatisation qui tient, c'est un relais où chaque coureur court la portion qu'il fait le mieux.

Prenons une tâche que beaucoup d'industriels connaissent : le traitement d'une commande qui arrive par email. Regardez comment les trois se répartissent le travail.

L'IA lit le mail, comprend qu'il s'agit d'une commande, extrait le client, les références, les quantités, même si le message est écrit à la va-vite. Elle transforme du désordre en données propres. Ensuite, une règle prend le relais : elle vérifie que le client existe, que les quantités sont cohérentes, que le montant ne dépasse pas un seuil sans validation. Du déterministe, du contrôlable, du fiable. Enfin, si l'ERP est un vieux système sans API, un robot RPA va saisir la commande écran par écran, là où rien d'autre ne peut entrer.

Trois briques, un flux. L'IA pour comprendre, la règle pour vérifier, le RPA pour agir dans le logiciel fermé. Chacune couvre l'angle mort des autres. L'IA seule serait imprévisible sur le contrôle des montants ; les règles seules seraient incapables de lire l'email. Ensemble, ça marche.

Ce découpage a un autre mérite, moins évident : il limite la surface de risque de l'IA. On ne lui confie que la part interprétation, celle où elle est irremplaçable. Tout ce qui doit être exact et vérifiable reste aux règles. On ne demande pas au modèle de langage de calculer une TVA ou de décider seul d'un paiement. On lui demande de comprendre, et on encadre le reste. C'est aussi ce qui rend l'articulation avec un ERP maîtrisable, un sujet qu'on détaille dans notre article sur comment connecter une IA à un ERP.

Notre parti pris d'agence

On assume une opinion, forgée à force de regarder des back-offices industriels. Trop de projets d'automatisation commencent par le choix de l'outil, « on va faire du RPA » ou « on veut de l'IA », avant même d'avoir regardé la tâche. C'est l'ordre inverse du bon sens.

On part toujours du processus, jamais de la techno. On observe une tâche réelle, on la décortique étape par étape, et à chaque étape on se demande : règle, robot, ou modèle ? La réponse tombe presque toute seule une fois qu'on regarde la nature exacte de ce qui entre et de ce qui doit sortir.

Notre biais penche vers la sobriété. La règle la plus simple qui fait le travail est presque toujours la bonne. On n'ajoute une couche de RPA ou d'IA que lorsque la précédente ne suffit plus. Cette discipline évite les usines à gaz, les coûts qui filent et les automatisations si complexes que personne n'ose plus y toucher six mois après.

Et on le dit quand une tâche ne mérite pas d'IA. Si trois lignes de logique règlent le problème, on ne va pas vous facturer un agent intelligent pour le plaisir du mot. C'est plus honnête, et franchement plus rentable pour vous sur la durée. Cette réflexion, on la mène en amont, pendant le cadrage, ce qui suppose de bien poser les besoins : c'est tout l'objet d'un bon cahier des charges d'automatisation.

En résumé

Retenez l'échelle. Les règles sont déterministes, économiques, fiables, et elles cassent quand le format change. Le RPA imite les clics pour dompter les vieux logiciels sans API, au prix d'une maintenance dès que l'interface bouge. L'IA comprend le non structuré, absorbe la variété et l'exception, mais elle coûte plus et demande des garde-fous.

La bonne question n'est pas « quelle techno est la meilleure ». C'est « de quoi cette tâche précise a-t-elle besoin ». Descendez l'échelle avant de la monter. Et le plus souvent, la meilleure réponse n'est pas une brique, mais un assemblage des trois, chacune sur sa portion.