Arrêtez la sur-ingénierie : workflows vs agents d’IA expliqués
On est en 2026, et des mots comme workflows, agents, outils et systèmes multi-agents sont encore souvent mélangés. Au-delà de la terminologie, ça a aussi conduit à des solutions sur-ingénierées. Heureusement, on vient justement de créer une cheatsheet pour vous aider à comprendre ce que vous devez construire, que je partagerai dans un instant.
Mais avant ça, commençons par clarifier deux choses qui trompent souvent.
D’abord, toutes les applications basées sur des LLMs ne sont pas des agents. La différence clé, c’est l’autonomie. Dans un workflow, c’est vous qui contrôlez le flux, vous décidez des étapes et de leur ordre. Dans un agent, c’est le modèle qui contrôle le flux; il décide quoi faire ensuite en fonction de l’objectif que vous lui donnez. Si vous pouvez écrire à l’avance la séquence exacte des étapes, vous construisez un workflow, pas un agent.
Ensuite, et c’est là que beaucoup de personnes se trompent, les outils ne sont pas des agents. Un outil est une capacité, comme une calculatrice, une requête de base de données, un navigateur web, un validateur ou un appel d’API. Un agent est le décideur qui choisit quels outils utiliser et quand. Donc si quelqu’un vous dit qu’il a construit un « système multi-agents » alors qu’il s’agit en réalité d’un seul modèle qui appelle dix APIs différentes, ce n’est pas du multi-agent. C’est un seul agent avec dix outils. Cette distinction définit la manière dont vous allez architecturer, déboguer et scaler votre système. Elle pilote le choix d’architecture de base : un workflow, un agent unique avec des outils, ou plusieurs agents.
Ce curseur ou spectre rend le choix d’architecture beaucoup plus simple. Pensez-le comme un spectre de complexité, et votre objectif est de rester aussi à gauche que possible tout en résolvant votre problème.
Le premier niveau, ce sont les workflows, où vous enchaînez plusieurs appels à des LLMs. Le deuxième niveau, c’est un agent unique avec des outils, où le modèle prend des décisions sur quoi faire ensuite. Le troisième niveau, ce sont les systèmes multi-agents, où vous avez plusieurs décideurs qui doivent se coordonner entre eux.
Le principe fondamental est le suivant : ne vous déplacez vers la droite sur ce spectre que lorsque vous y êtes absolument obligé. Chaque pas vers la droite augmente vos coûts, votre latence et la complexité du débogage. Plus d’appels à des LLMs signifie plus de tokens, plus de traces à suivre et plus d’endroits où les choses peuvent mal tourner. Les meilleurs systèmes d’IA sont les plus simples qui résolvent le problème de manière fiable.
Et dans la majorité des cas, ça veut dire commencer par des workflows.
Les workflows sont la bonne solution lorsque les étapes sont connues et stables. Si le processus est globalement le même à chaque fois, peu importe l’input, un workflow est presque toujours le meilleur choix parce qu’il est prévisible, facile à tester, facile à déboguer, et bien moins cher que les approches basées sur des agents. Vous pouvez écrire des tests unitaires pour chaque étape, tracer précisément ce qui s’est passé quand quelque chose casse, et vous ne gaspillez pas de tokens pour que le modèle devine quoi faire ensuite.
Prenons un système de tickets de support. Un ticket arrive. Vous le classez, vous le routez vers la bonne équipe, vous rédigez une réponse à partir de templates et de contexte, vous la validez par rapport aux règles internes, puis vous l’envoyez. Chacune de ces étapes peut impliquer un appel à un LLM, mais le modèle n’a pas besoin de décider s’il doit classifier avant de router; l’ordre est toujours le même. C’est un workflow, et le construire comme un agent ajouterait de la complexité sans ajouter de capacité.
Parfois, l’ordre du travail n’est pas fixe, et vous ne pouvez réellement pas écrire les étapes à l’avance. Pas parce que la tâche est impossiblement complexe, mais parce que le chemin change en fonction de ce que vous découvrez en cours de route. Peut-être que le premier appel d’API échoue et que vous devez en essayer un autre. Peut-être que les données récupérées sont incomplètes et que vous devez demander des clarifications. C’est là que les agents excellent.
Mais voici la règle : commencez avec un seul agent. Un agent unique avec des outils fonctionne le mieux lorsque les tâches sont fortement couplées et majoritairement séquentielles, lorsque le contexte global est important parce que l’étape un influence l’étape cinq, lorsque vous avez besoin de peu d’outils, et lorsque les contraintes de budget ou de latence vous poussent vers un overhead minimal.
Imaginez une plateforme marketing qui veut de la génération de contenu assistée par IA pour des emails, des SMS et des messages promotionnels. Leur spécification initiale prévoyait une configuration multi-agents avec une longue liste d’agents spécialisés : un orchestrateur, un agent d’analyse de requête, un agent de génération de contenu, un agent de génération de structure, de validation syntaxique, de validation sémantique, de prévention du spam, d’optimisation, de sécurité, de scoring, de normalisation HTML, de migration, et même des agents de comparaison et d’analyse. Sur le papier, ça semblait propre : des spécialistes qui font chacun leur spécialité.
Mais ici, un seul agent fonctionne bien mieux, parce que les tâches sont fortement couplées et séquentielles. Le choix du template influence le contenu, la personnalisation dépend à la fois du contenu et des données de contact, et la validation dépend de la sortie finale. Répartir ça entre plusieurs décideurs crée des silos d’information et des erreurs de transmission, parce que chaque agent ne voit qu’une partie du tableau. Et ils n’avaient pas non plus besoin de parallélisme. Le flux était simple : planifier, générer, valider, corriger si nécessaire.
Un outil peut avoir son propre system prompt et même utiliser un modèle différent, spécialisé pour cette tâche. L’outil de validation peut utiliser son propre LLM avec des instructions pour détecter les erreurs. L’outil de personnalisation peut avoir un validateur et un système de références de champs, pour que le modèle récupère la bonne syntaxe au lieu de l’inventer. L’outil de génération de SMS peut traiter les limites de caractères et la détection de mots spam comme des contraintes d’ingénierie déterministes, pas comme des problèmes de prompting. Vous gardez des spécialistes, mais avec un seul cerveau pour maintenir le contexte et prendre les décisions finales. Le résultat est un système plus rapide à construire, moins cher à exécuter et plus facile à déboguer, avec les mêmes capacités, mais sans le coût de coordination.
À mesure que la liste d’outils s’allonge, la sélection des outils devient plus difficile, ce qui est l’une des principales raisons pour lesquelles les systèmes à base d’agents se dégradent silencieusement, et l’un des signaux les plus clairs qu’un découpage en plusieurs agents pourrait valoir le coup. Chaque outil que vous donnez à un agent a un nom, une description et un schéma que le modèle doit avoir en contexte pour l’utiliser correctement. Plus vous ajoutez d’outils, plus vous consommez votre budget de contexte avant même que l’agent commence à réfléchir à la tâche réelle.
Les instructions système, les exemples few-shot, les documents récupérés et l’historique de conversation prennent aussi de la place. C’est pour ça qu’un agent unique fonctionne généralement mieux quand vos tâches nécessitent moins de 10 à 20 outils. Au-delà de ce seuil, la sélection des outils se dégrade, parce que l’agent doit choisir parmi trop d’options dans un contexte déjà saturé.
Si vous dépassez ce seuil, la gestion du contexte peut seulement réduire l’historique et le contenu récupéré, pas la charge liée aux schémas des outils. La seule approche qui réduit réellement le nombre de définitions d’outils que le modèle voit par appel est de répartir les outils entre plusieurs agents. Si un agent ne voit que les outils email et un autre ne voit que les outils de validation, chaque appel reste plus petit et la sélection d’outils devient plus simple. C’est souvent la vraie force motrice qui pousse vers des architectures multi-agents. À partir du moment où vous répartissez les outils entre des agents pour garder des appels légers, vous êtes dans du multi-agent.
Les systèmes multi-agents sont justifiés pour quelques raisons spécifiques. La première est le vrai parallélisme. Si les tâches sont réellement indépendantes et que vous avez besoin qu’elles s’exécutent en même temps, plusieurs agents aident. La deuxième raison est la surcharge de contexte : quand instructions, outils, récupération de documents et historique saturent le contexte au point de dégrader les performances, des agents spécialisés opérant dans des contextes plus petits et ciblés peuvent être la bonne solution. La troisième raison est la modularité ou l’intégration externe : si vous devez vous connecter à des systèmes d’agents tiers que vous ne contrôlez pas, ou à des composants réutilisables et autonomes. La quatrième raison concerne les séparations strictes, comme les frontières de sécurité, l’isolation pour la conformité ou la gestion de données sensibles.
Quand nous avons construit notre générateur d’articles pour du contenu technique, nous avons commencé avec l’idée d’un agent unique pour la recherche et l’écriture. Mais nous avons dû pivoter parce que la phase de recherche est exploratoire et dynamique, alors que la phase d’écriture est contrainte et déterministe. La recherche nécessite de la flexibilité et un large accès à des outils comme la recherche web, la transcription YouTube, le scraping GitHub et le traitement de documents. L’écriture nécessite des contraintes strictes, une application cohérente du style et des boucles d’itération par rapport à des grilles d’évaluation fixes. Nous avons donc pivoté vers un système multi-agents et fini avec deux agents distincts : un agent de recherche et un agent rédacteur.
Dans ce système multi-agents, l’agent de recherche cherche, lit, pivote en fonction de ce qu’il trouve, cherche à nouveau, et itère en fonction du feedback humain sur les directions à explorer. Et l’agent rédacteur suit des guides de style et des règles de formatage, avec des boucles de validation qui vérifient chaque section selon des critères précis.
Les agents communiquent via des artefacts explicites; l’agent de recherche produit un fichier structuré research.md que l’agent rédacteur consomme comme contexte. Pas d’orchestration runtime complexe, juste un passage de relais séquentiel avec un contrat clair entre les deux. Chaque agent a son propre contexte optimisé, sans le poids inutile des outils et instructions de l’autre.
Si vous partez sur du multi-agent, le pattern qui fonctionne le mieux en général n’est pas “tout le monde parle à tout le monde”, mais le pattern orchestrateur-workers. Un orchestrateur maintient le contexte principal et délègue des tâches spécifiques à des agents workers, puis synthétise les résultats. Ça évite les silos d’information qui tuent les systèmes multi-agents.
Les systèmes multi-agents peuvent simplifier les contextes individuels et permettre la parallélisation et la spécialisation, mais ils augmentent les coûts de coordination. Plus de tokens, plus de latence, plus de points de défaillance, et plus de complexité dans les passages de relais. N’acceptez ces coûts que lorsque vous avez atteint une vraie contrainte que des architectures plus simples ne peuvent pas résoudre.
Et comme promis, nous avons transformé ce contenu, et plus encore, en une cheatsheet complète pour vous aider à savoir quoi construire dans chaque scénario, des workflows simples aux systèmes multi-agents. Vous pouvez la télécharger gratuitement sur mon site : links.louisbouchard.ai.
Si vous construisez quelque chose en ce moment, laissez un commentaire avec ce que vous construisez et ce que vous avez choisi. Merci d’avoir lu. À la prochaine.
