AgentsAgent IA vs workflow : quelle différence, lequel choisir
· 6 min de lecture · par l'équipe Agenticiel
Quand on parle d’automatiser un processus, deux mots reviennent sans cesse : workflow et agent IA. On les emploie souvent l’un pour l’autre, à tort : ils ne se conçoivent pas de la même façon, ne coûtent pas la même chose et ne cassent pas de la même manière.
La différence tient à une question simple : savez-vous, à l’avance, la liste des cas que votre système va rencontrer ? Si oui, vous pouvez écrire des règles et concevoir un workflow. Si non, si les entrées sont libres et imprévisibles, il faut un agent, un système qui décide lui-même, à chaque passage, de l’action à mener. C’est cette variabilité qui commande tout le reste.
Voici des critères de décision que vous pouvez appliquer au premier processus qui vous vient à l’esprit, avec ce qu’ils impliquent en fiabilité, en coût et en évaluation. À la fin, vous saurez quel cadre convient à votre cas, et comment composer les deux quand le besoin est mixte.
Ce qu’est un workflow : des étapes décidées à l’avance
Un workflow est une suite d’étapes définies par avance, avec des branchements déterministes. Chaque étape fait une chose connue : lire un fichier, vérifier une condition, appeler une API, envoyer un email. Si la condition est vérifiée, on prend le chemin A, sinon le chemin B. Les mêmes entrées produisent toujours le même résultat.
Prenons le traitement d’une commande Shopify : identification du client, vérification du stock, calcul du total, envoi de la facture. Les règles sont connues, le parcours est stable, les cas particuliers se listent dans un document. C’est la force d’un workflow : la prévisibilité.
Cette prévisibilité a un prix : il faut avoir tout prévu. Si un cas imprévu arrive, le workflow s’arrête ou fait une erreur grossière. Il n’invente pas de chemin. Pour beaucoup de processus d’entreprise, une erreur visible vaut mieux qu’une réponse plausible.
Ce qu’est un agent : une boucle de décision
Un agent IA est d’une autre nature. Il reçoit une tâche, choisit une action parmi celles qui lui sont offertes, observe le résultat, puis décide de la suite. C’est une boucle, pas un circuit. La décision à chaque tour est prise par un modèle de langage, donc elle n’est pas déterministe : deux exécutions du même cas peuvent emprunter des chemins différents.
C’est utile dès que l’entrée est du langage libre, imprécis ou inattendu. Un email de client qui mélange une demande de remboursement et une question de livraison : personne ne peut écrire à l’avance la liste des formulations possibles. Un agent, lui, peut extraire l’intention, choisir l’action adaptée, et compléter les informations manquantes.
Cette souplesse a un coût. L’agent peut se tromper, et ses erreurs sont difficiles à reproduire. Il faut donc l’encadrer : des outils limités, des contrôles de sortie, des évaluations. C’est le rôle des frameworks d’agents comme LangGraph, l’OpenAI Agents SDK ou le Claude Agent SDK, qui structurent cette boucle et les outils auxquels l’agent a accès. Un agent n’est pas un choix par défaut, c’est un choix par nécessité, quand les règles ne suffisent pas.
Le critère décisif : la variabilité des cas
La question qui tranche : pouvez-vous énumérer les cas que votre système doit traiter ? Si oui, fût-ce avec une liste longue, un workflow est plus simple, plus fiable et moins cher. Si non, parce que les formulations et les situations sont infinies, il faut un agent.
Un exemple concret : l’extraction de factures. Les champs sont connus (numéro, date, montant, TVA), les mises en page varient mais restent peu nombreuses. Un workflow avec des règles de positionnement et des expressions régulières couvre l’essentiel, et un modèle de lecture ne sert qu’à rattraper les formats inconnus. Au contraire, le tri des emails de support : chaque message est un cas nouveau, la catégorie dépend du sens, pas de la forme. Là, un agent qui lit et catégorise est la solution naturelle.
Le mauvais choix, dans les deux sens, se paie. Un agent sur un problème à règles fixes apporte une instabilité inutile : des réponses qui varient pour le même cas, des coûts de tokens. Un workflow sur un problème ouvert s’effondre dès le premier cas imprévu, et on passe des semaines à ajouter des règles contradictoires.
Les signaux qui pointent vers un workflow
Quatre signaux font pencher vers le workflow. La fiabilité : le processus touche la production ou les paiements, chaque décision doit être justifiable. L’audit : un régulateur ou un client doit pouvoir relire le chemin emprunté. Le coût : pas d’appel à un modèle à chaque étape. La latence : une réponse rapide et reproductible.
Un exemple : le routage d’un ticket vers un service. Si les critères sont nets, comme le numéro de contrat ou le type d’abonnement, des règles suffisent. Un outil comme n8n, Make, Zapier ou Power Automate (si vous êtes sur Microsoft 365) fait alors très bien l’affaire (voir notre tour d’horizon n8n, Make, Zapier : l’automatisation en 2026).
Conclusion pratique : quand vous hésitez, commencez par chercher la règle. Si vous trouvez une description, même laborieuse, de ce qu’est une bonne décision, le workflow suffit.
Les signaux qui pointent vers un agent
L’agent se justifie quand le texte est libre, quand l’intention se devine, quand le cas d’usage ne se laisse pas énumérer. Trois situations type : répondre à des demandes client formulées de mille façons, résumer l’essentiel de documents longs, et orchestrer des outils en fonction d’un objectif dont la trajectoire n’est pas connue à l’avance.
Prenons la préparation d’un compte rendu de réunion. Les participants s’expriment librement, les points d’action ne sont pas marqués dans la transcription produite par Whisper ou l’outil de visio. Un agent lit la conversation, identifie les décisions, extrait les tâches et les responsables. Aucune règle écrite ne couvre ce travail, parce que la langue ne se laisse pas réduire à des conditions. Nous détaillons ce cas dans notre guide pour automatiser les comptes rendus avec un agent IA.
Dans ces cas, l’agent apporte ce qu’un workflow ne peut pas : la capacité de traiter l’inattendu. Mais il faut l’accepter pour ce qu’il est, une machine probabiliste encadrée, et lui donner les outils de son encadrement : des evals, des logs, une supervision humaine sur les décisions sensibles.
L’hybride : le workflow d’abord, l’agent là où il manque
La plupart des systèmes qui marchent en production sont hybrides. Le squelette est un workflow, et l’agent intervient à des points précis, là où l’interprétation est nécessaire. C’est le meilleur des deux mondes : la stabilité là où elle est possible, la souplesse là où elle est indispensable.
Un exemple : une saisie comptable. Le workflow récupère le document, applique les contrôles de cohérence ; l’agent lit et remplit les champs ; le workflow vérifie, signale les cas douteux à un humain, archive dans Pennylane ou Odoo. Dans n8n, ce découpage est natif : un nœud AI Agent s’insère à une étape d’un workflow classique. Chaque couche fait ce qu’elle sait faire, et le point faible de l’une est couvert par l’autre.
Cette architecture se construit dans cet ordre : d’abord le parcours déterministe, ensuite l’intervention de l’agent, ensuite son évaluation. On évite ainsi de confier tout un processus à un modèle et de découvrir tardivement qu’il dérive sur les cas simples. Côté outillage, le choix entre un orchestrateur de workflows et un framework d’agents se pose dans les mêmes termes : nous le comparons dans n8n vs LangGraph.
Trancher sur votre propre processus
Prenez le processus que vous voulez automatiser et listez vingt cas réels, tels qu’ils arrivent. Si vous parvenez à écrire la règle qui traite chacun, partez sur un workflow. Si une partie des cas résiste à toute règle, isolez précisément cette partie : c’est là, et seulement là, qu’un agent a sa place. Dans la grande majorité des projets, on aboutit à un hybride dont l’agent n’occupe qu’une ou deux étapes.
Ce découpage est le cœur de notre façon de construire des agents IA : on part de vos cas concrets, on sépare ce qui doit rester prévisible de ce qui demande de l’interprétation, et on construit la solution la plus simple qui tienne réellement en production.
