À retenir
- La plupart des systèmes appelés agents sont encore des workflows, et c’est très bien lorsque les étapes sont connues à l’avance.
- L’autonomie est la différence clé : dans un workflow, vous contrôlez les étapes, tandis qu’un agent décide quoi faire ensuite.
- Passez à un système multi-agents seulement lorsque le problème exige réellement plusieurs décideurs qui se coordonnent.
Regardez la vidéo!
SECTION 1 : CE QUE LES GENS CONFONDENT
Nous sommes presque en 2026, et les termes workflows, agents, outils et systèmes multi-agents sont encore mélangés. Au-delà de la terminologie, cette confusion a aussi mené à des solutions surconçues. Heureusement, nous venons de créer une fiche mémo que vous pourrez utiliser pour comprendre ce que vous devez construire, et je vais bientôt la partager. Mais d’abord, clarifions deux choses qui sèment la confusion.
Premièrement, toutes les applications basées sur un LLM ne sont pas des agents. La différence clé est l’autonomie. Dans un workflow, vous contrôlez le flux, vous décidez des étapes et de leur ordre. Dans un agent, le modèle contrôle le flux; il décide quoi faire ensuite selon l’objectif que vous lui donnez. Si vous pouvez écrire à l’avance la séquence exacte des étapes, vous créez un workflow, pas un agent. Deuxièmement, et c’est là que beaucoup de gens 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 les utiliser. Donc, si quelqu’un vous dit avoir créé un « système multi-agents », alors qu’il s’agit en fait d’un seul modèle qui appelle dix API différentes, ce n’est pas du multi-agent. C’est un seul agent avec dix outils. Cette distinction définit comment vous concevez l’architecture, déboguez et mettez votre système à l’échelle. Elle détermine le choix d’architecture central : un workflow, un seul agent avec des outils ou plusieurs agents.
SECTION 2 : LE SPECTRE (LE MODÈLE MENTAL)
Ce curseur, ou ce spectre, simplifie le choix de l’architecture. Voyez-le comme un spectre de complexité. Votre objectif est de rester aussi loin à gauche que possible tout en résolvant votre problème.
Le premier niveau est celui des workflows, dans lesquels vous enchaînez plusieurs appels de LLM. Le deuxième est un seul agent avec des outils, où le modèle décide quoi faire ensuite. Le troisième est celui des systèmes multi-agents, où plusieurs décideurs doivent se coordonner. Le principe central est le suivant : déplacez-vous vers la droite sur ce spectre seulement lorsque c’est absolument nécessaire. Chaque pas vers la droite augmente vos coûts, votre latence et la complexité du débogage. Plus d’appels de LLM 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. Ça signifie habituellement de commencer par des workflows.
SECTION 3 : QUAND UN WORKFLOW EST LA BONNE RÉPONSE
Les workflows sont la bonne réponse lorsque vos étapes sont connues et stables. Si le processus reste en grande partie 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 beaucoup moins coûteux qu’une approche basée sur des agents. Vous pouvez écrire des tests unitaires pour chaque étape, retracer exactement ce qui s’est passé lorsque quelque chose échoue et éviter de brûler des tokens pour que le modèle détermine quoi faire ensuite. Prenez un système de tickets de support. Un ticket arrive. Vous le classifiez, l’acheminez à la bonne équipe, préparez une réponse à partir de templates et du contexte, la validez selon la politique, puis l’envoyez. Chacune de ces étapes peut inclure un appel de LLM, mais le modèle n’a pas besoin de décider s’il doit classifier le ticket avant de l’acheminer; ce sera toujours l’ordre. C’est un workflow, et le construire comme un agent ajouterait de la surcharge sans ajouter de capacité.
SECTION 4 : QUAND UN SEUL AGENT AVEC DES OUTILS GAGNE
Parfois, l’ordre du travail n’est pas fixe et vous ne pouvez véritablement pas écrire les étapes à l’avance. Pas parce que la tâche est incroyablement complexe, mais parce que le chemin change selon ce que vous découvrez en cours de route. Le premier appel d’API échoue peut-être et vous devez essayer une solution différente. Les données récupérées sont peut-être incomplètes et vous devez demander une clarification. C’est ce que les agents gèrent bien. Mais voici la règle : commencez avec un seul agent. Un agent unique avec des outils fonctionne mieux lorsque les tâches sont étroitement liées et surtout séquentielles, lorsque le contexte global compte parce que la première étape influence la cinquième, lorsque vous avez besoin de moins d’outils et lorsque des contraintes de budget ou de latence vous poussent à réduire cette surcharge au minimum.
Imaginez une entreprise de plateforme marketing qui veut générer du contenu assisté par l’IA pour des emails, des SMS et des messages promotionnels. Ses spécifications initiales demandaient une architecture multi-agents avec une longue liste d’agents spécialisés. Un orchestrateur. L’analyse des requêtes. La génération de contenu. La génération de structure. La validation syntaxique. La validation sémantique. La prévention du spam. L’optimisation. La sécurité. Le scoring. La normalisation HTML. Des agents de migration. Même des agents de comparaison et d’analyse. Sur papier, ça semblait propre, avec des spécialistes qui font du travail de spécialistes. Mais ici, un seul agent fonctionnera beaucoup mieux parce que les tâches sont étroitement liées et séquentielles. Le choix du template influence le contenu, la personnalisation dépend à la fois du contenu et des données du contact, et la validation dépend de l’output final. Répartir tout ça entre plusieurs décideurs crée des silos d’information et des erreurs de handoff, puisque chaque agent ne voit qu’une partie du portrait. Ils n’avaient pas non plus besoin de parallélisme. Le flux consistait à planifier, générer, valider et corriger au besoin. Un outil peut avoir son propre system prompt et même utiliser un autre modèle spécialisé pour cette tâche. L’outil de validation peut utiliser son propre LLM avec des instructions pour repérer les erreurs. L’outil de personnalisation peut posséder un validateur et un système de référence des champs, afin que le modèle récupère la bonne syntaxe plutôt que de l’inventer. L’outil de génération de SMS peut traiter les limites de caractères et la détection de mots indésirables comme des contraintes d’ingénierie déterministes, pas comme des problèmes de prompting. Vous obtenez quand même des spécialistes, mais vous conservez un seul cerveau pour maintenir le contexte et prendre les décisions finales. Le résultat est un système plus rapide à créer, moins cher à exécuter et plus facile à déboguer, avec les mêmes capacités, mais sans le coût de coordination.
SECTION 5 : LE PROBLÈME DU NOMBRE D’OUTILS
À mesure que la liste d’outils grandit, leur sélection devient plus difficile. C’est l’une des principales façons dont les systèmes d’agents se dégradent discrètement et l’un des signes les plus clairs que les diviser entre plusieurs agents pourrait valoir la peine. Chaque outil donné à un agent possède un nom, une description et un schéma dont le modèle a besoin dans son contexte pour l’utiliser correctement. Plus vous ajoutez d’outils, plus vous brûlez votre budget de contexte avant même que l’agent commence à réfléchir à votre véritable tâche. Les instructions système, les exemples few-shot, les documents récupérés et l’historique de la conversation prennent aussi de la place. C’est pourquoi un seul agent tend à mieux fonctionner lorsque vos tâches nécessitent moins de 10 à 20 outils. Au-delà de ce seuil, la sélection se dégrade parce que l’agent doit choisir parmi trop d’options dans un contexte déjà rempli. Si vous dépassez ce seuil, la gestion du contexte peut seulement réduire l’historique et le contenu récupéré, pas le poids des schémas d’outils. La seule approche qui réduit réellement le nombre de définitions d’outils vues par le modèle à chaque appel consiste à les répartir entre des agents. Si un agent voit seulement les outils d’email et un autre seulement les outils de validation, chaque appel reste plus petit et la sélection devient plus facile. C’est souvent la véritable raison qui pousse vers les architectures multi-agents. Dès que vous répartissez les outils entre les agents pour garder les appels petits, vous êtes dans le territoire multi-agents.
SECTION 6 : QUAND LE MULTI-AGENT EST RÉELLEMENT LE BON CHOIX
Plusieurs agents se justifient pour quelques raisons précises. La première est le véritable parallélisme. Si les tâches sont réellement indépendantes et doivent être exécutées simultanément, plusieurs agents sont utiles. La deuxième est un contexte surchargé par les instructions, les outils, la recherche d’information et l’historique au point où la performance se dégrade. Des agents spécialisés qui travaillent dans des contextes plus petits et ciblés peuvent alors être le bon choix. La troisième est la modularité ou l’intégration externe, lorsque vous devez vous connecter à des systèmes d’agents tiers que vous ne contrôlez pas, ou à des composants autonomes et réutilisables. La quatrième concerne les exigences de séparation rigides, comme les frontières de sécurité, l’isolation pour la conformité ou la gestion de données sensibles. Lorsque nous avons créé notre générateur d’articles pour le contenu technique, nous avions commencé par construire un seul agent pour la recherche et l’écriture. Mais nous avons dû changer d’approche parce que la phase de recherche est exploratoire et dynamique, tandis que la phase d’écriture est contrainte et déterministe. La recherche exige de la flexibilité et un accès étendu aux outils pour la recherche web, la transcription YouTube, le scraping GitHub et le traitement de documents. L’écriture exige des contraintes ciblées, une application cohérente du style et des raffinements itératifs selon des grilles d’évaluation fixes. Nous avons donc dû passer à un système multi-agents et avons terminé avec deux agents distincts : un agent de recherche et un agent de rédaction.
Dans ce système multi-agents, l’agent de recherche cherche, lit, pivote selon ses découvertes, cherche de nouveau et itère selon le feedback humain sur les directions à suivre. L’agent de rédaction suit les guides de style et les règles de formatage, avec des boucles de validation qui vérifient chaque section selon des critères précis. Les agents communiquent par des artefacts explicites; l’agent de recherche produit un fichier research.md structuré que l’agent de rédaction utilise comme contexte. Aucune orchestration complexe pendant l’exécution, seulement un handoff séquentiel avec un contrat clair entre les deux. Chaque agent possède son propre contexte optimisé sans le poids des outils et des instructions de l’autre. Si vous choisissez le multi-agent, le pattern qui fonctionne habituellement n’est pas que tout le monde parle à tout le monde; c’est le pattern orchestrateur-travailleur. Un orchestrateur maintient le contexte principal et délègue des tâches précises aux agents travailleurs, puis synthétise les résultats. Ça empêche les silos d’information qui tuent les systèmes multi-agents. Ces systèmes peuvent simplifier les contextes individuels et permettre le parallélisme et la spécialisation, mais ils augmentent les coûts de coordination. Plus de tokens utilisés, une latence supplémentaire, davantage de points de défaillance et des handoffs plus complexes. Acceptez ces coûts seulement lorsque vous rencontrez une véritable contrainte que des architectures plus simples ne peuvent pas résoudre.
Et comme promis, nous avons transformé ce contenu et plus encore en une fiche mémo complète pour vous aider à savoir ce que vous devez construire dans chaque scénario, des workflows simples jusqu’aux systèmes multi-agents. Téléchargez-la gratuitement sur mon site : links.louisbouchard.ai.
Merci d’avoir lu. On se revoit la prochaine fois.
FAQ
Quelle est la différence entre un workflow et un agent?
Un workflow suit une séquence que vous définissez. Un agent reçoit un objectif, choisit ses outils ou ses étapes et contrôle davantage le chemin à suivre.
Quand devriez-vous utiliser un système multi-agents?
Utilisez plusieurs agents seulement lorsqu’un seul décideur ne suffit pas et que le coût de coordination justifie la flexibilité supplémentaire.
Quelle est l’erreur courante de sur-ingénierie?
L’erreur consiste à ajouter des agents parce que le terme semble avancé, même si un workflow fixe serait plus facile à tester, à déboguer et à livrer.
Quand un seul agent fonctionne-t-il mieux que plusieurs agents?
Un seul agent est habituellement préférable lorsque les tâches partagent leur contexte, se déroulent surtout en séquence, utilisent peu d’outils et exigent une faible latence ou un faible coût.
Quel coût supplémentaire accompagne une architecture multi-agents?
Chaque décideur supplémentaire crée plus d’appels de modèles, de tokens, de traces, de handoffs et de points de défaillance que l’équipe doit observer et déboguer.
Quel est le signe le plus clair qu’un workflow suffit?
Si vous pouvez définir les étapes et leur ordre avant le début du run, gardez le workflow. Ajoutez de l’autonomie seulement lorsque le chemin dépend réellement de ce que le système découvre.