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.
Ce qui suit n’est pas une théorie. Ce sont 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 en ligne : 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. 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.
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. 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.
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. 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.
L’accompagnement Agenticiel pour trancher et construire
Trancher entre workflow et agent est un choix d’architecture, et un choix d’architecture se paie deux fois : une fois dans le développement, une fois dans la maintenance. Le faire avec un regard extérieur, habitué aux deux approches, évite les erreurs de cadrage les plus coûteuses.
Agenticiel accompagne les entreprises sur ce choix, de l’étude du processus jusqu’à la livraison. On regarde vos cas réels, on identifie ce qui relève de la règle et ce qui relève de l’interprétation, et on vous propose une architecture à la mesure du besoin, pas à la mesure de la technologie. Le premier échange se fait sur la base d’un audit facturé 1 500 €, déduit du devis.
Ce travail est mené par des développeurs offshore francophones, à Madagascar. La sous-traitance de développement donne accès à une équipe complète, dans votre langue et sur des fuseaux proches, ce qui rend l’itération rapide et le budget maîtrisé.
Notre approche consiste à partir de vos cas concrets, à séparer ce qui doit être prévisible de ce qui doit être souple, et à construire la solution la plus simple qui tienne vraiment la route.