Agent unique ou multi-agents ?

Regardez la vidéo!

La plupart des projets IA échouent avant même que l’implémentation commence. Les équipes choisissent des architectures en fonction des tendances plutôt que des besoins, sélectionnent des frameworks sans évaluer les alternatives, et sautent les conversations de cadrage qui déterminent le succès.

Je suis Louis-Francois, cofondateur et CTO chez Towards AI. Dans cet article, je vais vous montrer notre processus de prise de décision à travers deux réalisations réelles: un système à agent unique pour la génération de contenu marketing et un pipeline multi-agents pour l’écriture d’articles. Les deux projets demandaient des choix d’architecture différents selon leurs contraintes, et les deux ont livré des systèmes fonctionnels. Je vais aussi partager une fiche mémo qu’on a créée pour vous aider à comprendre quand et quoi construire dans cette nouvelle ère agentique.

À la fin, vous saurez quelles questions poser pour concevoir des systèmes d’agents IA et éviter de devoir refaire l’architecture en plein milieu du projet.

Commençons par la première question qui change tout. Ce n’est pas une question d’agents, de modèles, ou d’outils. C’est une question de périmètre.

Comprendre ce dont le client a vraiment besoin

C’est plus simple: qu’est-ce que le client veut réellement?

Ça paraît évident, mais voici ce qui se passe en pratique. Une demande comme “génération de contenu marketing propulsée par l’IA” n’est pas un livrable. Il faut encore définir à quoi ressemble le succès: est-ce qu’ils veulent une fonctionnalité en production, une intégration, un prototype, ou un livrable que leur équipe mettra en production elle-même? Et il faut aussi obtenir les exigences cachées tôt: la cadence des démos, la documentation, et jusqu’à quel point on s’attend à ce que vous expliquiez vos choix de conception.

C’est exactement ce qui s’est passé dans notre projet CRM. La demande initiale ressemblait à un produit de chatbot, mais le vrai livrable était du code Python en proof-of-concept sur un ensemble de scénarios, plus des démos hebdomadaires et une documentation claire pour que leur équipe puisse l’implémenter plus tard.

Et même pour notre système interne d’écriture d’articles, la même discipline de cadrage comptait. On n’avait pas besoin d’une UI soignée. On avait besoin de faible coût, d’itérations rapides, de sorties fiables, et d’une façon simple d’ajouter du feedback humain parce qu’on l’exécutait depuis un IDE et qu’on optimisait pour la vitesse et la qualité, pas pour l’emballage produit.

Faire correspondre l’architecture à la forme de la tâche

Une fois que vous avez verrouillé le périmètre, vous gagnez le droit de parler architecture. La règle est simple: la forme de la tâche dicte la structure. Ne partez pas de “multi-agent ou pas”. Partez de la façon dont le travail se déroule réellement.

Voici le cadre de décision. Si vos tâches sont prévisibles et linéaires (étape A, puis B, puis C, avec un raisonnement cohérent tout du long), utilisez un workflow ou un agent unique. Si les tâches divergent mais restent dans un seul domaine, où le style de raisonnement est similaire, même si les sorties varient, un agent unique avec des outils spécialisés est généralement suffisant. Les systèmes multi-agents méritent leur complexité quand le travail contient des modes fondamentalement différents qui se mélangent mal dans une seule boucle, surtout quand une phase a besoin d’exploration et qu’une autre a besoin de contraintes strictes.

Comme plafond pratique: si vous êtes dans environ quinze outils bien cadrés, un agent unique reste gérable. Au-delà, envisagez de découper par domaine.

Vous voyez ce contraste dans nos deux réalisations.

Pour le système CRM marketing, le travail était séquentiel, et le raisonnement restait cohérent à travers les sorties. Que ce soit un email, un SMS ou une notification push, l’agent suit la même logique: comprendre le brief, respecter le format, respecter les contraintes. Ça a fait d’un agent unique avec un ensemble d’outils bien organisé le point de départ le plus propre.

Pour le système d’écriture d’articles, la forme de la tâche se sépare en deux modes différents. La recherche est exploratoire: chercher sur le web, évaluer les sources, décider si on en a assez, pivoter selon ce qu’on trouve. L’écriture est contrainte: suivre des guides de style, appliquer des règles de formatage, et garder une voix cohérente. Donc on les a séparés en deux agents avec un handoff simple, et on n’a pas ajouté d’orchestrateur parce que le pattern d’utilisation réel était naturellement séquentiel.

Garder les agents “minces” et les outils “lourds”

Maintenant, même avec la bonne architecture, vous pouvez quand même construire le mauvais système si l’agent fait trop. Une fois l’architecture choisie, la question suivante est: comment structurer le travail entre votre agent et ses outils?

Une erreur fréquente, c’est de mettre la logique d’implémentation à l’intérieur de la boucle de raisonnement de l’agent. Quand ça arrive, l’agent dépense des tokens à faire du travail bas niveau au lieu de prendre des décisions haut niveau.

La règle qu’on suit est: agent mince, outils lourds. L’agent raisonne, planifie, et décide quel outil appeler. Les outils exécutent le travail réel.

Cette séparation compte pour trois raisons. D’abord, le debug: quand quelque chose casse, vous savez tout de suite si c’est un problème de raisonnement ou un problème d’exécution. Ensuite, la réutilisabilité: des outils bien conçus peuvent être partagés entre agents ou projets. Enfin, la maintenabilité: d’autres développeurs peuvent ajouter de nouveaux outils sans toucher à la logique d’orchestration de l’agent.

Qu’est-ce qui fait un bon outil? Chaque outil doit bien faire une seule chose, retourner des sorties structurées, et gérer ses propres cas d’erreur. Si un outil échoue, il doit renvoyer un feedback spécifique sur lequel l’agent peut agir, pas du texte vague. Et dès que vous pouvez appliquer des règles de façon déterministe en code, faites-le dans l’outil plutôt que de demander au LLM de se souvenir des contraintes.

C’est ce qu’on a fait dans le système CRM marketing. L’agent orchestraït trois catégories d’outils: des outils de retrieval pour les données client et la documentation, des outils de génération pour créer le contenu, et des outils de validation pour vérifier les limites de caractères et la syntaxe des templates. L’agent décidait quoi générer et quand valider. Les outils géraient la mécanique.

Dans le système d’écriture d’articles, l’agent de recherche s’appuyait sur des outils pour la recherche web, le scraping, la transcription, et l’extraction de code depuis des repos. L’agent “writer” s’appuyait sur des outils pour le formatage, les diagrammes, et la structure. Les deux agents restaient concentrés sur le raisonnement pendant que les outils géraient la complexité.

Choisir un framework d’orchestration

Une fois les outils en place, la décision suivante est de savoir si vous avez besoin d’un framework pour exécuter la boucle ou si c’est overkill.

Même un agent unique a besoin d’orchestration. Il faut des boucles pour la planification, la sélection d’outils, l’itération, la gestion des erreurs, et la gestion du contexte. La vraie décision, c’est de construire ça vous-même ou d’utiliser un framework existant.

Voici comment penser aux options. Si vous avez besoin d’une gestion d’état complexe (checkpointing, branches d’exécution, reprise après échec), LangGraph est fait pour ça. Si vous avez besoin d’une coordination multi-agents par rôles avec des handoffs définis, CrewAI convient. Si vous avez besoin d’une boucle d’agent simple avec appel d’outils, LangChain, ou une implémentation custom légère fonctionne. Et si le coût de n’importe quel framework ne vaut pas le coup, construisez from scratch.

La règle est: ne payez pas pour des features dont vous n’avez pas besoin.

L’orchestration est aussi différente selon que vous construisez un système à agent unique ou multi-agents. Pour un agent unique, l’orchestration concerne la boucle interne: comment il planifie, choisit les outils, gère les erreurs, et gère le contexte. Pour des systèmes multi-agents, vous ajoutez une couche de coordination au-dessus: comment les agents se passent la main, s’ils partagent un état ou restent isolés, et qui décide quand un agent a fini et qu’un autre doit commencer. Cette couche de coordination est là où la complexité s’accumule, donc évitez-la sauf si la tâche l’exige réellement.

C’est ce qu’on a fait dans le système CRM marketing. On a évalué toutes les options principales, mais le flow était simple: l’utilisateur envoie une demande, l’agent planifie, appelle les outils, génère le contenu, valide, et renvoie le résultat. Une boucle d’agent simple couvrait tout ce dont on avait besoin. Construire from scratch était tentant, mais un framework léger nous a donné des patterns fiables pour l’intégration des outils et la gestion des erreurs.

Dans le système d’écriture d’articles, on avait deux agents mais on a gardé la coordination minimale: un handoff simple, pas d’orchestrateur. La recherche fonctionnait comme une recette répétable sans état lourd. L’écriture bénéficiait de la gestion d’état parce qu’on voulait sauvegarder des versions après chaque révision pour que les utilisateurs puissent revenir en arrière. L’agent de recherche sort un fichier, et l’agent writer le lit. Chaque agent gérait sa propre orchestration en interne.

Choisir les modèles selon la difficulté de la tâche

Ok! Architecture, outils, orchestration. Maintenant vient la partie à laquelle tout le monde saute trop tôt: le choix du modèle.

La vraie réponse, c’est que ça dépend de la tâche. Ne partez pas du principe d’utiliser le plus gros modèle partout, et n’utilisez pas le modèle le moins cher partout juste pour économiser. Faites correspondre la capacité du modèle à la difficulté de l’étape.

En pratique, vous pouvez regrouper les étapes en niveaux. La planification, l’évaluation, et les tâches de jugement bénéficient souvent de modèles plus puissants parce qu’elles demandent un raisonnement cohérent. Les étapes d’exécution étroites (générer du texte court, nettoyer des pages scrapées, transformations simples) peuvent souvent tourner sur des modèles moins chers tant que la qualité reste acceptable. Testez le modèle moins cher d’abord. Montez en gamme uniquement quand la qualité l’exige.

Dans le système CRM marketing, on a utilisé des modèles plus forts pour l’orchestration et l’évaluation, et des modèles moins chers pour la génération routinière, comme les SMS et les emails courts. Dans le système d’écriture d’articles, on a utilisé des modèles plus forts pour la sélection des sources et l’écriture, et des modèles moins chers pour les étapes de nettoyage.

Déterminer si vous avez besoin de RAG

Une fois le modèle choisi, il reste une pièce que beaucoup traitent comme un défaut: le retrieval. Ce qui nous amène à la question suivante: est-ce que vous avez vraiment besoin de RAG?

La Retrieval-Augmented Generation est puissante, mais le retrieval n’est pas toujours le bon outil. La vraie question est: avez-vous besoin de données externes au moment de la génération, et si oui, quel type de données est-ce?

Voici l’arbre de décision. Si vous avez de grandes quantités de texte non structuré (documentation, exemples, politiques, sorties passées) et que vous devez récupérer des passages pertinents à l’exécution, c’est un problème de retrieval. Utilisez des embeddings et une recherche vectorielle. Si vous avez des enregistrements structurés (données clients, catalogues produits, historiques de transactions), c’est un problème de requête. Utilisez SQL ou une API pour récupérer exactement ce dont vous avez besoin. Et si votre matériel de référence tient dans la fenêtre de contexte du modèle et que vous avez besoin de cohérence entre documents, chargez-le directement.

Dans le système CRM marketing, on avait besoin des deux approches. Pour des sources non structurées comme la documentation et des exemples de campagnes, on a utilisé du retrieval via recherche par embeddings. Pour des données structurées comme les dossiers clients et l’information produit, on a utilisé des requêtes SQL.

Dans le système d’écriture d’articles, aucun des deux agents n’utilisait RAG. Les sorties de recherche étaient écrites dans un fichier de notes et passées directement au writer. Pour les guides de style et les articles exemples, on avait un petit ensemble curaté (peut-être cinquante mille tokens au total) qui tenait confortablement dans la fenêtre de contexte. On l’a chargé directement au lieu de construire un pipeline de retrieval.

Construire des boucles de validation

À ce stade, le système peut tourner, mais “ça tourne” n’est pas la même chose que “c’est fiable”. C’est là que beaucoup d’équipes s’arrêtent. Elles ont leur architecture, leurs modèles, leur pipeline de données. Mais elles sautent la partie qui rend vraiment le système fiable.

La vraie question devient donc: comment rendre la qualité des sorties non négociable?

Vous ne pouvez pas espérer que le LLM fasse juste du premier coup. Si les sorties comptent, vous avez besoin de checks explicites et d’une manière structurée de corriger les échecs.

La règle, c’est: construire des boucles generate-validate-fix avec un feedback actionnable. La validation doit être une barrière avec des raisons d’échec spécifiques sur lesquelles le système peut agir, pas un score de qualité vague.

Voilà ce que ça donne en pratique. D’abord, vérifiez les contraintes dures: limites de longueur, validité de syntaxe, champs requis, conformité au format. Ces checks sont rapides et déterministes. Ensuite, ajoutez des checks plus “soft”: respect du ton, cohérence de style, exactitude factuelle. Ceux-ci nécessitent souvent une approche LLM-as-judge avec des rubriques claires.

Quand quelque chose échoue, ne réessayez pas à l’aveugle. Renvoyez un feedback spécifique à l’agent: “Trop long de quinze caractères”, “Erreur de syntaxe à la ligne trois”, “Le ton est trop formel pour cette audience”. L’agent régénère avec ce feedback. Bouclez jusqu’à ce que les checks passent ou jusqu’à atteindre une limite de retries.

Deuxième règle: planifiez vos checkpoints human-in-the-loop de manière intentionnelle. Décidez dès le départ où une personne doit revoir les sorties avant que le système avance, surtout avant des étapes coûteuses ou des actions irréversibles. Intégrez-le dès le design.

Dans le système CRM marketing, on validait les limites de caractères pour les SMS, la syntaxe des templates pour leur format propriétaire, et le ton par rapport aux guidelines de marque. Chaque outil de validation renvoyait un feedback spécifique que l’agent pouvait utiliser pour corriger.

Dans le système d’écriture d’articles, la validation était plus granulaire. On vérifiait chaque section pour la structure, le flow narratif, les citations, les règles de grammaire, les exigences de formatage, et les contraintes de vocabulaire. On a aussi intégré des checkpoints humains: l’agent de recherche s’arrête pour demander si l’utilisateur veut plus de sources, et le writer sauvegarde l’état après chaque révision pour que les utilisateurs puissent revenir en arrière.

Le cadre de décision: douze questions

Si vous prenez du recul, vous allez remarquer un pattern: on ne faisait pas des “choix IA”. On faisait des compromis. Voici quelques-unes des questions clés qu’on s’est posées sur ces projets. Il y en a d’autres, évidemment, mais celles-ci sont les grandes qui ont façonné notre architecture et notre implémentation, et ces walkthroughs devraient vous donner un cadre solide pour démarrer vos propres projets.

Pour vous simplifier la vie, on a catégorisé nos apprentissages tirés de ces projets et d’autres en une checklist des questions suivantes que vous pouvez vous poser au début de n’importe quel projet IA pour décider de la bonne architecture et des bons outils.

NOTE: On peut aussi attacher ça sous forme d’un PDF notebook séparé derrière un email sign-up. Ça va nous aider à collecter des emails et ça donnera quelque chose de solide à emporter pour les utilisateurs avec des CTAs vers Towards AI

Je vais les regrouper en quatre catégories.

D’abord, comprendre la tâche.

Q1: La forme de votre tâche est-elle séquentielle ou arborescente? Les tâches séquentielles collent aux workflows; les tâches arborescentes ont besoin d’agents.

Q2: Votre raisonnement est-il exploratoire ou déterministe? Le raisonnement exploratoire a besoin de flexibilité, le raisonnement déterministe a besoin de contraintes.

Ensuite, design système.

Q3: De combien d’outils avez-vous besoin? Si c’est plus de vingt, envisagez de découper en plusieurs agents ou de découper les outils par domaine.

Q4: Avez-vous besoin de données internes ou propriétaires? C’est votre décision RAG.

Q5: Avez-vous besoin d’un état persistant? Si oui, vous avez besoin d’un framework comme LangGraph. Si non, un script simple suffit.

Troisièmement, qualité et contraintes.

Q6: Vos sorties ont-elles besoin de boucles de validation ou de quality gates?

Q7: De combien de human-in-the-loop avez-vous besoin, et où devraient être ces checkpoints pour relire les plans, la recherche, ou les drafts?

Q8: Avez-vous des données d’évaluation? Si oui, construisez des evals automatisées. Si non, commencez à collecter des exemples et des ratings humains avant de sur-ingénier.

Quatrièmement, contraintes opérationnelles.

Q9: Quelles sont vos tolérances de latence? Une latence serrée signifie moins de “hops” d’agents, des modèles plus petits, et plus de workflows. Une latence plus lâche signifie que vous pouvez vous permettre un raisonnement plus profond, une coordination multi-agents, et plus de validation.

Q10: Quel est votre budget par tâche? Un budget faible signifie des modèles moins chers, moins d’appels d’outils, et plus de caching. Un budget plus élevé signifie des modèles de raisonnement plus forts et plus de réflexion.

Q11: Comment allez-vous faire l’observabilité? Décidez où vivent les logs et les traces. Utilisez un outil comme Opik, ou au minimum un logging structuré pour chaque run. Pas d’observabilité signifie que vous volez à l’aveugle.

Q12: Votre problème peut-il être décomposé proprement en compétences distinctes? Si oui, multi-agent ou multi-workflow. Si non, agent unique ou workflow unique.

Les mêmes douze questions. Des réponses différentes. Des architectures différentes.

Et comme promis, on a transformé ce contenu et plus encore en une fiche complète pour vous aider à savoir quoi 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.

Appliquer le framework

Donc comment est-ce que vous utilisez réellement ce framework?

Ne le traitez pas comme un formulaire où vous remplissez les douze réponses dans l’ordre. Utilisez-le comme un outil de réflexion. Commencez par quelques questions, suivez là où les réponses vous mènent, et revisitez-les à mesure que le projet évolue. Vous pouvez commencer avec un agent unique et réaliser plus tard qu’il faut le découper. Vous pouvez commencer avec un workflow et réaliser plus tard qu’il vous faut plus de flexibilité. C’est normal. Ce ne sont pas des règles rigides; ce sont des guidelines qui vous aident à faire des compromis de manière intentionnelle.

Et une habitude compte plus que ce que la plupart des équipes imaginent: documentez vos décisions. Ne documentez pas seulement ce que vous avez choisi, documentez pourquoi. Quand quelqu’un demande: “Pourquoi on utilise ce framework plutôt que celui-là?”, vous devriez pouvoir répondre en termes de forme de tâche, besoins d’état, complexité des outils, exigences de qualité, et contraintes opérationnelles. Cette documentation aide aussi les nouveaux membres à onboarder et vous aide à vous rappeler le raisonnement derrière la construction.

Si vous voulez aller plus loin sur comment on construit ces systèmes, on enseigne tout ça dans nos cours chez Towards AI. Le but n’est pas juste la théorie; c’est du hands-on où vous construisez les systèmes, vous les déployez, et vous apprenez les compromis en les rencontrant pour de vrai.