L’automatisation par règles est déterministe, auditable, quasiment gratuite à l’exécution, et elle fait exactement la même chose à chaque fois. Ce sont des avantages, pas des limites. Si votre workflow tient dans un moteur de règles, un agent IA est une régression : plus lent, plus cher et non déterministe, en échange d’un jugement dont vous n’avez pas besoin.
La question n’est pas de savoir quelle technologie est la plus avancée. Elle est de savoir si votre workflow a un problème d’exceptions.
Ce que les règles font bien
Tout ce qui s’exprime sous la forme si ceci, alors cela avec un ensemble de conditions fini et connu. Router selon la valeur d’un champ, déplacer des données d’un système à l’autre, déclencher une action au franchissement d’un seuil, lancer des traitements planifiés. Zapier, Make, n8n et les outils de RPA le font très bien et continueront à le faire.
Ils ont aussi des propriétés qu’un agent ne peut pas égaler : vous pouvez lire la logique, un auditeur peut la vérifier, chaque exécution ne coûte à peu près rien, et le comportement est identique à la dix-millième exécution. Dans un contexte réglementé, ce déterminisme est parfois une exigence, pas une préférence.
Ne remplacez pas des règles qui fonctionnent par un agent sous prétexte que les agents sont plus récents. C’est l’erreur coûteuse la plus fréquente dans ce domaine.
Le signal qui montre que les règles ne suffisent plus
Ce n’est pas la complexité, c’est le taux d’exceptions. Les règles traitent les cas que vous aviez prévus. La question est de savoir quelle part du volume réel leur échappe et retombe sur un humain.
Mesurez-le pendant un mois : sur tout ce qui entre dans le workflow, quel pourcentage l’automatisation oriente-t-elle correctement sans aucune intervention humaine ? En ordre de grandeur :
| Taux d’exceptions | Ce que cela signifie | Que faire |
|---|---|---|
| Moins de 10 % | Les règles conviennent au travail | Gardez-les et ajustez les cas limites |
| 10 à 25 % | Les règles atteignent leurs limites | Ajoutez d’abord des règles, puis mesurez à nouveau |
| Plus de 25 % | Le travail demande du jugement | Un agent est probablement justifié |
| Le nombre de règles ne cesse d’augmenter | Vous codez du jugement sous forme de branches | Un agent, ou une refonte |
Cette dernière ligne est le vrai révélateur. Quand un système de règles accumule des dizaines de conditions qu’une seule personne comprend, vous n’avez pas automatisé le jugement : vous l’avez codé sous une forme que personne ne peut maintenir. Le coût, ce n’est plus la licence, c’est la maintenance.
Les trois différences qui comptent
- Les entrées non structurées. Les règles ont besoin de champs. Si le travail arrive sous forme de texte libre, de fil d’e-mails, de PDF ou de photo, les règles ne peuvent agir que sur ce que quelqu’un d’autre a déjà structuré, et ce quelqu’un est en général une personne qui fait du tri à la main.
- Le jugement face à l’ambiguïté. Cette réclamation est-elle urgente ? n’a pas de seuil. Les règles s’en approchent avec des indices indirects (mots-clés, domaine de l’expéditeur) qui fonctionnent jusqu’au jour où ils ne fonctionnent plus.
- Le travail en plusieurs étapes avec un état. Un agent garde le contexte d’une étape à l’autre et s’adapte quand une étape échoue. Une chaîne de règles exécute sa branche et s’arrête.
Si aucun de ces points ne décrit votre workflow, vous n’avez pas besoin d’un agent. C’est une bonne nouvelle : cela coûte moins cher.
L’approche qui l’emporte le plus souvent
Les deux. Les meilleures architectures de production que nous développons placent les règles en premier et un agent sur les exceptions : la logique déterministe traite les 70 à 80 % qu’elle traite parfaitement et à bas coût, et l’agent ne prend que ce qui en sort.
C’est mieux que l’un ou l’autre seul. Vous gardez le déterminisme et l’auditabilité là où ils sont possibles, vous ne payez le modèle que sur les cas réellement difficiles et, ce qui est bien utile, la file des exceptions constitue déjà un jeu de données étiqueté qui montre précisément ce que l’agent devra traiter. Cela réduit aussi l’étendue des dégâts possibles, puisque l’agent ne touche qu’une minorité du volume et non sa totalité.
Ce qui change quand vous passez à un agent
Un agent ne se substitue pas tel quel à des règles, et son exploitation n’a pas la même forme. Des règles fonctionnent ou lèvent une erreur. Un agent peut se tromper discrètement et avec assurance. Vous héritez donc d’obligations que les règles n’ont jamais imposées : un jeu d’évaluations (evals) pour noter l’exactitude, des traces pour reconstituer les décisions, des garde-fous pour borner le pire scénario, et quelqu’un pour l’exploiter après la mise en production (en anglais).
C’est là le vrai coût du passage à un agent, et non les tokens, qui se comptent en centimes par transaction. C’est pourquoi le taux d’exceptions doit réellement le justifier. Si vous hésitez entre étendre vos règles et faire développer un agent, notre article développer ou acheter traite la question du mode d’approvisionnement, et les cinq signes (en anglais) vérifient si le workflow s’y prête. Quand c’est le cas, un projet Gigabit Agents se paie au forfait, à partir de 8 000 $ par agent.
