Vous n’avez peut-être pas besoin d’un agent IA : 5 critères pour choisir entre workflow et agent

Workflow et agent ne résolvent pas le même problème

Dans un workflow, les chemins sont orchestrés à l’avance par des développeurs. Dans un agent, le modèle dirige lui-même son enchaînement d’étapes et son usage des outils. Ce n’est pas une différence de sophistication, c’est une différence de qui décide du chemin.

Prenons un processus de traitement de factures : recevoir la facture, extraire le montant, vérifier le fournisseur, appliquer une règle, router vers le bon circuit. Si toutes les règles sont connues, un workflow déterministe est la meilleure réponse. Il exécutera toujours les mêmes étapes, dans le même ordre, avec les mêmes résultats, ce qui est précisément ce qu’on attend d’un processus comptable.

L’agent devient intéressant quand la demande ressemble plutôt à : « analyse cette demande, comprends ce que veut le fournisseur, cherche les informations nécessaires dans nos systèmes, décide quelles vérifications effectuer, détermine la prochaine étape ». Cette fois, le chemin n’est pas connu à l’avance et le système doit raisonner sur la façon d’atteindre l’objectif.

Anthropic recommande explicitement de commencer par la solution la plus simple et de n’ajouter de la complexité que lorsqu’elle apporte une valeur mesurable. Pour des tâches bien définies, les workflows offrent davantage de prévisibilité ; les agents deviennent pertinents quand la flexibilité et la décision dynamique sont réellement nécessaires.

Critère 1 : le chemin est-il prévisible ?

Si le processus se dessine sous forme d’arbre de décision qu’une équipe peut maintenir, le workflow suffit. Demander à un modèle de redécouvrir à chaque exécution une règle que vous connaissez déjà revient à payer un raisonnement pour obtenir une constante.

Le test tient en un exercice de tableau blanc. L’équipe métier sait-elle écrire les règles sous la forme « si A, faire B ; si C, faire D », et accepte-t-elle de les maintenir ? Si oui, le chemin est connu, et il ne reste rien à décider au moment de l’exécution.

L’inverse est vrai aussi, et c’est ce qui rend le critère utile : quand le nombre de situations possibles rend les règles ingérables, l’agent redevient pertinent. OpenAI cite justement les processus fondés sur des règles devenues trop complexes à maintenir parmi les cas qui justifient une architecture agentique. Le signal n’est pas « c’est compliqué », c’est « personne n’ose plus toucher aux règles ».

Critère 2 : les données d’entrée sont-elles structurées ?

Un workflow traditionnel excelle quand il reçoit des champs bien définis. Il se dégrade dès que l’entrée devient un courriel, un contrat, une conversation, un PDF, une demande exprimée librement, ou plusieurs documents qui se contredisent.

C’est le terrain où un modèle apporte une valeur que rien d’autre n’apporte. Attention toutefois à la nuance : interpréter une entrée non structurée ne demande pas nécessairement un agent. Un workflow qui appelle un modèle à une étape précise pour extraire des champs reste un workflow, et il conserve toute la prévisibilité du reste de la chaîne.

Critère 3 : faut-il choisir dynamiquement les outils ?

Un enchaînement d’appels fixe se code, se teste et se débogue. Choisir en cours de route quelle source interroger est la seule chose qu’une boucle agentique fait mieux qu’un orchestrateur.

Si le processus appelle systématiquement l’API A, puis l’API B, puis l’API C, l’orchestration s’écrit une fois pour toutes, et elle coûte le prix de trois appels réseau.

Si le système doit décider en cours de route s’il a besoin du CRM, du moteur documentaire, d’une recherche externe, d’une précision supplémentaire ou de deux sources croisées, alors la décision fait partie du problème. C’est précisément ce qu’un enchaînement figé ne sait pas absorber.

Critère 4 : l’erreur est-elle détectable et réversible ?

Une architecture ne se choisit pas seulement sur ce que le système peut réussir, mais sur ce qui se passe quand il échoue.

Si une erreur peut provoquer une perte financière immédiate, une violation réglementaire ou une action irréversible, la liberté laissée au modèle doit être fortement encadrée. L’agent n’est pas exclu pour autant, mais ses points d’arrêt relèvent alors des décisions décrites dans quelles décisions un agent ne doit pas prendre seul.

À l’inverse, un agent devient beaucoup plus défendable quand l’erreur est détectable, réversible, bloquée avant l’action critique, ou transférable à un humain. Ces quatre propriétés se conçoivent, elles ne s’observent pas après coup.

Critère 5 : la flexibilité vaut-elle son coût ?

Un agent peut mobiliser plusieurs appels de modèles et plusieurs outils pour terminer une tâche que le workflow réglait en un appel. La question n’est donc pas « est-ce techniquement possible avec un agent ? », puisque presque tout finit par l’être. La question est de savoir si le gain obtenu justifie la complexité ajoutée.

Anthropic souligne explicitement ce compromis entre les performances obtenues sur certaines tâches et l’augmentation de la latence et des coûts. Le sujet rejoint alors ce que nous détaillons dans la variabilité du nombre d’appels, premier poste de surprise budgétaire.

Le workflow a lui aussi un coût caché

Le workflow n’est pas gratuit parce qu’il est déterministe. Il coûte peu à l’exécution et cher à la maintenance, alors que l’agent fait l’inverse. Choisir, c’est décider où l’on préfère payer.

Un workflow encode des règles. Ces règles vieillissent, se contredisent, accumulent des exceptions ajoutées par des personnes qui ne travaillent plus là. Au bout de quelques années, il arrive qu’un arbre de décision accumule des centaines de branches dont une part ne s’exécute plus jamais, sans que personne n’ose les retirer.

C’est exactement le seuil au-delà duquel l’agent redevient raisonnable, et c’est aussi pourquoi ce choix se réexamine périodiquement plutôt qu’une fois pour toutes. Un processus qui justifiait pleinement un workflow il y a trois ans peut avoir accumulé assez d’exceptions pour ne plus le justifier aujourd’hui.

Un exemple, les cinq critères appliqués

Prenons un cas courant : traiter les réclamations reçues par courriel dans un service après-vente. Les appréciations ci-dessous sont celles d’un cadrage type, pas une mesure relevée sur une mission.

L’enseignement de cet exemple n’est pas « workflow » ni « agent », mais « les deux, à des endroits différents ». C’est presque toujours la réponse quand on prend la peine de découper le processus avant de choisir la technologie, et la proportion exacte entre les deux ne se connaît qu’après avoir compté les cas réels.

Une grille de décision : quelle architecture tester en premier

La dernière ligne mérite une réserve. Passer de zéro à cinq agents ne rend pas un système cinq fois plus intelligent, mais crée cinq fois plus d’interactions à comprendre lorsqu’un résultat déraille, comme nous l’avons montré dans cinq agents, et cinq fois plus d’interactions à comprendre.

Commencer simple ne ferme aucune porte

L’argument le plus souvent opposé au workflow est qu’il faudrait tout refaire le jour où l’on passe à l’agent. C’est rarement vrai, à une condition : que les outils aient été construits comme des outils, et non comme des étapes.

Une fonction qui vérifie un fournisseur, exposée proprement, sert indifféremment un workflow qui l’appelle en troisième position et un agent qui décide de l’appeler. Ce qui change, c’est qui décide de l’appeler, pas ce qu’elle fait. Investir dans des outils bien délimités, journalisés et testables est donc le seul travail qui reste valable quelle que soit l’architecture retenue ensuite, et c’est aussi ce que suppose la connexion d’un agent au système d’information.

La trajectoire raisonnable est donc rarement de choisir une architecture définitive au cadrage. Elle consiste à traiter d’abord ce qui est prévisible, à instrumenter ce qui ne l’est pas, puis à ouvrir l’autonomie là où les mesures montrent que le déterminisme ne suffit plus.

Le meilleur système IA est parfois celui qui utilise le moins d’IA

Les architectures qui tiennent en production combinent presque toujours plusieurs registres : des règles déterministes pour ce qui est connu, un modèle pour interpréter certaines entrées, un workflow pour orchestrer, un agent uniquement sur les cas réellement ambigus, et un humain pour les exceptions critiques.

Il ne s’agit pas d’opposer automatisation classique et IA. Il s’agit de mettre le bon niveau d’intelligence au bon endroit, ce qui suppose d’avoir découpé le processus assez finement pour que « le bon endroit » veuille dire quelque chose.

Les questions à poser en cadrage

La dernière question est celle qui fait gagner le plus de temps. Si la réponse est oui, l’architecture raisonnable consiste souvent à traiter ces 80 % par un workflow et à router le reste vers un humain, quitte à introduire un agent plus tard, une fois les cas résiduels réellement connus. C’est aussi ce qui distingue un POC d’un système industrialisé, sujet que nous traitons dans les écarts qui séparent un POC d’un système industrialisé.

À retenir

Avant de construire un agent, une seule question suffit à orienter le cadrage : quelle décision sommes-nous incapables de coder à l’avance de façon raisonnable ?

Si la réponse est « aucune », vous n’avez probablement pas besoin d’un agent. Si elle est « le système doit comprendre la situation, choisir son chemin et adapter ses actions », alors l’approche agentique commence à se justifier. L’objectif n’est pas de rendre chaque processus agentique, c’est de réserver l’autonomie aux endroits où elle crée réellement de la valeur.