Agent IA ou automatisation classique (RPA, scripts) : comment choisir en 2026 ?

Quelle est la différence entre un agent IA et une automatisation classique ?

Une automatisation classique exécute des règles écrites à l'avance. Un script, un cron job ou un robot RPA suit un chemin défini : si la condition A est vraie, exécuter l'action B. Le comportement est déterministe. La même entrée produit toujours la même sortie.

Un agent IA fonctionne sur une boucle différente : observer, décider, agir. Il reçoit un objectif, analyse le contexte à chaque étape, puis choisit l'action suivante parmi des outils disponibles (API, base de données, envoi d'e-mail). Le chemin n'est pas écrit à l'avance. C'est un modèle de langage qui le construit à l'exécution.

Cette différence a une conséquence directe sur les exceptions. Un script qui rencontre un cas imprévu s'arrête ou échoue silencieusement. Un agent peut interpréter le cas imprévu : un libellé de facture inhabituel, un e-mail ambigu, un champ manquant. C'est sa raison d'être — et sa source de risque, car une interprétation peut être fausse.

Le comparatif : coût, fiabilité, maintenance, cas d'usage

Le tableau résume les trois approches sur les critères qui pèsent dans la décision d'un CTO : coût initial, coût récurrent, fiabilité, maintenance et nature des entrées.

La fragilité de la maintenance RPA est documentée. Dans une enquête Pega de 2019 (plus de 500 décideurs interrogés), 41 % jugeaient que la gestion courante des bots demande plus de temps que prévu.

Un point mérite d'être isolé : le profil de coût. Un script coûte à la construction, presque rien ensuite. Un agent coûte à la construction et à chaque exécution, car chaque tâche consomme des appels au modèle. À fort volume sur un processus simple, l'agent est structurellement plus cher que le script — sans apporter davantage.

L'arbre de décision : quand un cron job suffit-il en 2026 ?

Quatre questions, dans l'ordre, tranchent la majorité des cas :

1. Les entrées sont-elles structurées (API, base de données, fichiers au format fixe) ? Si oui : script ou cron. Un LLM n'apporte rien à un flux déjà structuré.
2. Le processus a-t-il des exceptions qui demandent une interprétation (texte libre, documents hétérogènes) ? Si non : automatisation classique. Si les exceptions se comptent sur les doigts d'une main, les coder en dur reste moins cher qu'un agent.
3. Le coût d'une erreur est-il tolérable ou rattrapable ? Un agent se trompe parfois. Si une erreur coûte cher (virement, engagement contractuel, donnée client), il faut une validation humaine dans la boucle — ce qui réduit le gain d'automatisation.
4. Le volume d'exceptions justifie-t-il un coût par exécution ? Quelques cas par semaine se traitent à la main, moins cher qu'un agent maintenu en production.

La réponse la plus robuste sur un processus métier est souvent hybride : un script orchestre le flux nominal, l'agent ne traite que les exceptions. Le flux principal garde le déterminisme et le coût marginal du script ; l'agent n'est facturé que sur les cas qui le justifient.

Exemple sur un traitement de factures fournisseurs. La majorité des factures arrivent dans des formats connus : un script connecté à l'API comptable les traite sans erreur. Les factures restantes, aux formats inconnus ou aux lignes ambiguës, partent vers un agent qui extrait les champs et propose une écriture, validée par un humain. Le script porte le volume ; l'agent porte la variabilité. Ce découpage limite aussi le risque : une erreur de l'agent ne touche jamais le flux principal.

Pourquoi un agent coûte plus cher à fiabiliser qu'un script ?

Un script se teste une fois : les cas d'entrée sont finis, les tests unitaires couvrent le périmètre. Un agent est non déterministe. La même entrée peut produire deux sorties différentes. Fiabiliser un agent demande donc un outillage que le script n'exige pas.

• Des jeux d'évaluation (evals) : un corpus de cas réels, rejoué à chaque modification de prompt ou de modèle, avec un taux de réussite mesuré — l'équivalent des tests de non-régression, mais statistique.
• Des garde-fous en sortie : validation de schéma, plafonds d'action (montant maximal, liste blanche de destinataires), blocage des actions irréversibles sans confirmation.
• Une supervision humaine dimensionnée : qui relit quoi, à quelle fréquence, et comment une erreur détectée réintègre le jeu d'évaluation.
• Une journalisation des décisions : pour chaque tâche, quelles données l'agent a lues et pourquoi il a agi — indispensable en cas de litige ou d'audit.

Cet outillage conditionne la confiance de l'équipe métier. Un agent supervisé, dont les erreurs sont mesurées, s'améliore de version en version. Un agent déployé sans mesure perd la confiance des utilisateurs à la première erreur visible — et le projet s'arrête là.

Ce poste est celui que les démonstrations ne montrent jamais : faire fonctionner un agent prend des jours, le rendre digne de confiance prend des semaines. Les causes d'annulation relevées par Gartner en 2025 — coûts croissants et contrôles de risque insuffisants — désignent ce même angle mort. Le budget de fiabilisation, absent des maquettes, apparaît au passage en production.

Les erreurs fréquentes dans le choix entre agent et automatisation

Cinq erreurs reviennent régulièrement dans les projets d'automatisation. Chacune se détecte en amont, avec les questions de l'arbre de décision ci-dessus.

• Mettre un LLM là où une expression régulière suffit : sur des entrées structurées, l'agent ajoute du coût, de la latence et un risque d'erreur, sans gain fonctionnel.
• Sous-estimer le coût de fonctionnement : le budget de construction est visible, la consommation d'inférence mensuelle ne l'est pas au moment de la décision.
• Déployer un agent sans journalisation des décisions : la première erreur en production devient impossible à diagnostiquer.
• Reconstruire en RPA un processus dont l'application cible expose une API : le robot casse à chaque mise à jour de l'interface, l'appel d'API non.
• Automatiser un processus avant de l'avoir stabilisé : un agent qui exécute un processus mal défini produit des erreurs plus vite qu'un humain.

Comment décider pour votre processus ?

La méthode qui évite les deux excès (tout scripter, tout « agentifier ») tient en trois étapes. Cartographier le processus et isoler les exceptions réelles sur un mois d'historique. Chiffrer le flux nominal en automatisation classique. Puis évaluer un agent uniquement sur les exceptions restantes, avec un critère de réussite mesurable défini avant le développement.

Le critère de réussite se formule en chiffres avant d'écrire le premier prompt : taux d'exceptions résolues sans intervention, délai de traitement, coût par tâche. Sans ce chiffre, le projet reste une expérimentation qui ne passe jamais en production.

Cette discipline rejoint la trajectoire du marché. Gartner prévoit que 33 % des applications d'entreprise incluront de l'IA agentique en 2028, contre moins de 1 % en 2024. Les agents qui survivront sont ceux choisis pour un périmètre justifié. C'est l'approche que nous appliquons aux projets d'intégration d'IA dans des applications existantes, et en TMA quand un client nous confie une automatisation existante à faire évoluer.