À retenir
- Les problèmes d’architecture commencent généralement avant le code, lorsque les équipes choisissent des agents, des workflows ou des frameworks avant de définir le travail.
- Le périmètre vient d’abord : ce que le système doit décider, les outils qu’il peut utiliser et les endroits où les humains doivent encore approuver le travail.
- Il est plus facile de faire confiance à un agent unique lorsque l’ensemble d’outils est petit, la boucle est claire et les modes d’échec sont visibles.
Regardez la vidéo!
La plupart des projets d’IA échouent avant le début de l’implémentation. Les équipes sélectionnent des architectures selon les tendances plutôt que les exigences, adoptent des frameworks sans évaluer les solutions de rechange et sautent les discussions de cadrage qui déterminent la réussite.
Je suis Louis-François, cofondateur et directeur technique de Towards AI. Dans cet article, je vais présenter notre processus décisionnel à partir de deux vrais projets : un système à agent unique pour générer du contenu marketing et un pipeline multi-agents pour rédiger des articles. Ces deux projets exigeaient des choix architecturaux différents en fonction de leurs contraintes, et les deux ont produit des systèmes fonctionnels. Je partagerai aussi un aide-mémoire que nous avons préparé 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 reprendre l’architecture au milieu d’un projet.
Commençons par la première question qui change tout. Elle ne porte pas sur les agents, les modèles ou les outils. Elle porte sur le périmètre.
Comprendre ce dont le client a réellement besoin
C’est plus simple : que veut réellement le client?
Cela semble évident, mais voici ce qui se produit en pratique. Une demande comme « génération de contenu marketing propulsée par l’IA » n’est pas un livrable. Vous devez encore préciser à quoi ressemble la réussite. Le client veut-il une fonctionnalité de production, une intégration, un prototype ou un transfert que son équipe rendra prêt pour la production? Et vous devez connaître tôt les exigences cachées : la fréquence des démos, la documentation et le niveau de détail attendu pour expliquer vos choix de conception.
C’est exactement ce qui s’est produit dans notre projet CRM. La demande initiale ressemblait à un produit de chatbot, mais le vrai livrable était du code Python de proof of concept couvrant un ensemble de scénarios, accompagné de démos hebdomadaires et d’une documentation claire afin que leur équipe puisse l’implémenter plus tard.
Même pour notre système interne de rédaction d’articles, cette discipline de cadrage comptait. Nous n’avions pas besoin d’une interface utilisateur soignée. Nous avions besoin de faibles coûts, d’itérations rapides, d’outputs fiables et d’une façon simple d’ajouter du feedback humain, parce que nous exécutions le système dans un IDE et optimisions la vitesse et la qualité, pas sa présentation comme produit.
Adapter l’architecture à la forme de la tâche
Une fois le périmètre bien défini, vous gagnez le droit de parler d’architecture. La règle est simple : la forme de la tâche dicte la structure. Ne commencez pas par « multi-agents ou non ». Commencez par la façon dont le travail se déroule réellement. Voici le cadre décisionnel. Si vos tâches sont prévisibles et linéaires, étape A, puis B, puis C, avec un raisonnement cohérent tout au long du processus, utilisez un workflow ou un seul agent. Si les tâches divergent, mais demeurent dans un seul domaine où le style de raisonnement reste semblable même si les outputs varient, un agent unique avec des outils spécialisés suffit généralement. Les systèmes multi-agents méritent leur complexité lorsque le travail comprend des modes fondamentalement différents qui se mélangent mal dans une seule boucle, surtout lorsqu’une phase exige de l’exploration et une autre, des contraintes strictes. Comme plafond pratique, si vous avez environ une quinzaine d’outils bien délimités ou moins, un seul agent demeure gérable. Au-delà, pensez à diviser le travail par domaine. Vous pouvez voir ce contraste dans nos deux projets. Pour le système marketing du CRM, le travail était séquentiel et le raisonnement demeurait cohérent d’un output à l’autre. Qu’il s’agisse d’un email, d’un SMS ou d’une notification push, l’agent suivait la même logique : comprendre la demande, respecter le format et suivre les contraintes. Un agent unique avec un ensemble d’outils bien organisé constituait donc le point de départ le plus simple et clair. Pour le système de rédaction d’articles, la forme de la tâche se divisait en deux modes différents. La recherche est exploratoire : chercher sur le Web, évaluer les sources, décider si on en a assez et changer de direction selon ce qu’on trouve. La rédaction est contrainte : suivre les guides de style, imposer les règles de formatage et conserver une voix cohérente. Nous avons donc séparé le travail entre deux agents avec un simple transfert et n’avons ajouté aucun orchestrateur, parce que le pattern d’utilisation réel était naturellement séquentiel.
Garder les agents légers et confier le gros du travail aux outils
Même avec la bonne architecture, vous pouvez encore construire le mauvais système si l’agent en fait trop. Une fois l’architecture choisie, la prochaine question est la suivante : comment devriez-vous structurer le travail entre votre agent et ses outils?
Une erreur courante consiste à placer la logique d’implémentation dans la boucle de raisonnement de l’agent. Lorsque cela se produit, l’agent dépense des tokens à effectuer du travail de bas niveau au lieu de prendre des décisions de haut niveau.
Notre ligne directrice est la suivante : agent léger, outils qui font le gros du travail. 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. Premièrement, le débogage : lorsque quelque chose se brise, vous savez immédiatement s’il s’agit d’un problème de raisonnement ou d’exécution. Deuxièmement, la réutilisabilité : des outils bien conçus peuvent être partagés entre les agents ou les projets. Troisièmement, 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 devrait bien accomplir une seule tâche, renvoyer des outputs structurés et gérer ses propres cas d’erreur. Si un outil échoue, il devrait renvoyer un feedback précis sur lequel l’agent peut agir, pas un texte vague. Et chaque fois que vous pouvez imposer des règles de façon déterministe dans le code, faites-le dans l’outil au lieu de demander au LLM de mémoriser les contraintes.
C’est ce que nous avons fait dans le système marketing du CRM. L’agent orchestrait trois catégories d’outils : des outils de recherche pour les données des clients 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 le valider. Les outils s’occupaient de la mécanique.
Dans le système de rédaction d’articles, l’agent de recherche comptait sur des outils pour la recherche Web, le scraping, la transcription et l’extraction de code provenant de dépôts. L’agent de rédaction utilisait des outils pour le formatage, les diagrammes et la structure. Les deux agents demeuraient 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 déterminer si vous avez besoin d’un framework pour exécuter la boucle ou si ce serait excessif. Même un seul agent a besoin d’orchestration. Il faut des boucles pour la planification, la sélection des outils, l’itération, la gestion des erreurs et la gestion du contexte. La vraie décision est de construire cela vous-même ou d’utiliser un framework existant. Voici comment réfléchir aux options. Si vous avez besoin d’une gestion complexe de l’état, avec des points de contrôle, des chemins d’exécution qui se ramifient et la reprise après des échecs, LangGraph est conçu pour cela. Si vous avez besoin d’une coordination multi-agents fondée sur des rôles avec des transferts définis, CrewAI convient. Si vous avez besoin d’une boucle d’agent simple avec appel d’outils, LangChain ou une implémentation personnalisée légère fonctionnent. Et si le surplus de n’importe quel framework n’en vaut pas la peine, construisez le tout vous-même. La règle est la suivante : ne payez pas pour des fonctionnalités dont vous n’avez pas besoin. L’orchestration diffère aussi selon que vous construisez un système à agent unique ou multi-agents. Pour un seul agent, l’orchestration concerne la boucle interne : comment il planifie, sélectionne ses outils, gère les erreurs et gère le contexte. Pour les systèmes multi-agents, vous ajoutez une couche de coordination par-dessus : comment les agents se passent le travail, s’ils partagent leur état ou demeurent isolés et qui décide quand un agent a terminé et qu’un autre devrait commencer. C’est dans cette couche de coordination que la complexité s’accumule. Évitez-la donc à moins que la tâche l’exige réellement. Voilà ce que nous avons fait dans le système marketing du CRM. Nous avons évalué toutes les principales options, mais le flow était simple : l’utilisateur envoie une demande, l’agent planifie, appelle des outils, génère le contenu, le valide et renvoie le résultat. Une simple boucle d’agent couvrait tous nos besoins. Tout construire nous-mêmes était tentant, mais un framework léger nous donnait des patterns fiables pour intégrer les outils et gérer les erreurs. Dans le système de rédaction d’articles, nous avions deux agents, mais avons gardé la coordination minimale : un simple transfert, aucun orchestrateur. La recherche fonctionnait comme une recette répétable sans gestion d’état complexe. La rédaction profitait d’une gestion de l’état, parce que nous voulions sauvegarder des versions après chaque révision afin que les utilisateurs puissent revenir en arrière. L’agent de recherche produit un fichier et l’agent de rédaction le lit. Chaque agent gérait sa propre orchestration à l’interne.
Choisir les modèles selon la difficulté de la tâche
Très bien! Architecture, outils, orchestration. Voici maintenant la partie vers laquelle tout le monde saute trop tôt : le choix du modèle. La vraie réponse est qu’il dépend de la tâche. N’utilisez pas le plus gros modèle partout par défaut et n’utilisez pas non plus le modèle le moins cher partout simplement pour réduire les coûts. Adaptez les capacités du modèle à la difficulté de l’étape. En pratique, vous pouvez regrouper les étapes par niveaux. Les tâches de planification, d’évaluation et de jugement profitent généralement de modèles plus puissants parce qu’elles exigent un raisonnement cohérent. Les étapes d’exécution bien délimitées, comme générer du texte court, nettoyer des pages extraites du Web et effectuer de simples transformations, peuvent souvent utiliser des modèles moins coûteux tant que la qualité demeure acceptable. Testez d’abord le modèle moins cher. Passez à un modèle supérieur seulement lorsque la qualité l’exige. Dans le système marketing du CRM, nous avons utilisé des modèles plus puissants pour l’orchestration et l’évaluation et des modèles moins coûteux pour la génération courante, comme les SMS et les courts emails. Dans le système de rédaction d’articles, nous avons utilisé des modèles plus puissants pour sélectionner les sources et rédiger, puis des modèles moins coûteux pour les étapes de nettoyage.
Déterminer si vous avez besoin du RAG
Une fois le modèle choisi, il reste un élément que les gens traitent comme un choix par défaut : la recherche d’information. Ce qui nous mène à la prochaine question : avez-vous vraiment besoin du RAG? La génération augmentée par recherche d’information est puissante, mais la recherche d’information n’est pas toujours le bon outil. La vraie question est la suivante : avez-vous besoin de données externes au moment de la génération et, si oui, de quel type de données s’agit-il? Voici l’arbre de décision. Si vous avez de grandes quantités de texte non structuré, comme de la documentation, des exemples, des politiques et des outputs passés, et devez récupérer des passages pertinents à l’exécution, c’est un problème de recherche d’information. Utilisez des embeddings et la recherche vectorielle. Si vous avez des enregistrements structurés, comme des données clients, des catalogues de produits ou des 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 les documents, chargez-le directement. Dans le système marketing du CRM, nous avions besoin des deux approches. Pour les sources non structurées comme la documentation et les exemples de campagne, nous avons utilisé la recherche avec des embeddings. Pour les données structurées comme les dossiers clients et les renseignements sur les produits, nous avons utilisé des requêtes SQL. Dans le système de rédaction d’articles, aucun des deux agents n’utilisait le RAG. Les outputs de recherche étaient écrits dans un fichier de notes et transmis directement à l’agent de rédaction. Pour les guides de style et les articles d’exemple, nous avions un petit ensemble soigneusement sélectionné, peut-être cinquante mille tokens au total, qui tenait facilement dans la fenêtre de contexte. Nous l’avons chargé directement plutôt que de construire un pipeline de recherche d’information.
Construire des boucles de validation
À ce stade, le système peut fonctionner, mais « ça roule » ne veut pas dire « c’est fiable ». C’est là que beaucoup d’équipes s’arrêtent. Elles ont leur architecture, leurs modèles et leur pipeline de données. Mais elles sautent la partie qui rend réellement le système fiable.
La vraie question devient donc la suivante : comment rendre la qualité des outputs non négociable? Vous ne pouvez pas espérer que le LLM réussisse du premier coup. Si les outputs comptent, il vous faut des vérifications explicites et une façon structurée de corriger les échecs. La règle est la suivante : construisez des boucles générer, valider, corriger avec du feedback exploitable. La validation devrait être une étape bloquante qui fournit des raisons précises de l’échec sur lesquelles le système peut agir, pas un score de qualité vague. Voici ce que cela donne en pratique. Vérifiez d’abord les contraintes strictes : les limites de longueur, la validité de la syntaxe, les champs obligatoires et le respect du format. Ces vérifications sont rapides et déterministes. Ajoutez ensuite des vérifications plus souples : le respect du ton, la cohérence du style et l’exactitude factuelle. Elles exigent souvent une approche LLM-as-judge avec des rubriques claires. Lorsqu’un élément échoue, ne réessayez pas aveuglément. Renvoyez un feedback précis à l’agent : « trop long de quinze caractères », « erreur de syntaxe à la ligne trois », « ton trop formel pour cette audience ». L’agent régénère à partir de ce feedback. Répétez la boucle jusqu’à ce que les vérifications réussissent ou que vous atteigniez une limite de tentatives. Deuxième ligne directrice : planifiez vos points de contrôle humains avec soin. Décidez dès le départ où une personne devrait réviser les outputs avant que le système continue, surtout avant des étapes coûteuses ou des actions irréversibles. Intégrez-les dès la conception. Dans le système marketing du CRM, nous avons validé les limites de caractères des SMS, la syntaxe des templates dans leur format propriétaire et la conformité du ton aux lignes directrices de la marque. Chaque outil de validation renvoyait un feedback précis que l’agent pouvait utiliser pour corriger les problèmes. Dans le système de rédaction d’articles, la validation était plus granulaire. Nous avons vérifié chaque section pour sa structure, son flow narratif, ses citations, ses règles de grammaire, ses exigences de formatage et ses contraintes de vocabulaire. Nous avons aussi intégré des points de contrôle humains : l’agent de recherche s’arrête pour demander si l’utilisateur veut plus de sources et l’agent de rédaction sauvegarde son état après chaque révision afin que les utilisateurs puissent revenir en arrière.
Le cadre décisionnel : douze questions
Si vous prenez du recul, vous remarquerez un pattern : nous ne faisions pas des « choix d’IA ». Nous faisions des compromis. Voici quelques-unes des principales questions que nous avons posées sur ces projets. Il y en a d’autres, bien sûr, mais celles-ci sont les plus importantes pour notre architecture et notre implémentation. Ces explications devraient vous donner un cadre solide pour commencer vos propres projets.
Pour vous faciliter la tâche, nous avons regroupé ce que nous avons appris de ces projets et d’autres projets dans la checklist de questions suivante. Vous pouvez vous les poser au début de n’importe quel projet d’IA afin de choisir la bonne architecture et les bons outils.
Je vais les regrouper en quatre catégories.
Premièrement, comprendre la tâche.
Q1 : la forme de votre tâche est-elle séquentielle ou ramifiée? Les tâches séquentielles conviennent aux workflows. Les tâches ramifiées ont besoin d’agents.
Q2 : votre raisonnement est-il exploratoire ou déterministe? Un raisonnement exploratoire exige de la flexibilité. Un raisonnement déterministe exige des contraintes.
Deuxièmement, la conception du système.
Q3 : de combien d’outils avez-vous besoin? S’il y en a plus de vingt, pensez à répartir le travail entre plusieurs agents ou les outils entre plusieurs domaines.
Q4 : avez-vous besoin de données internes ou propriétaires? C’est ce qui détermine votre choix du RAG.
Q5 : avez-vous besoin d’un état persistant? Si oui, vous avez besoin d’un framework comme LangGraph. Sinon, un simple script suffit.
Troisièmement, la qualité et les contraintes.
Q6 : vos outputs ont-ils besoin de boucles de validation ou de points de contrôle qualité?
Q7 : quelle place l’humain doit-il occuper dans la boucle et où faut-il placer ces points de contrôle pour réviser les plans, la recherche ou les brouillons?
Q8 : avez-vous des données d’évaluation? Si oui, construisez des évaluations automatisées. Sinon, commencez à recueillir des exemples et des évaluations humaines avant de faire de la sur-ingénierie.
Quatrièmement, les contraintes opérationnelles.
Q9 : quelles sont vos tolérances de latence? Une faible tolérance exige moins de transferts entre agents, de plus petits modèles et davantage de workflows. Une grande tolérance vous permet un raisonnement plus approfondi, une coordination multi-agents et davantage de validation.
Q10 : quel est votre budget par tâche? Un petit budget exige des modèles moins chers, moins d’appels d’outils et davantage de mise en cache. Un budget plus élevé permet des modèles de raisonnement plus puissants et plus de réflexion.
Q11 : comment assurerez-vous l’observabilité? Décidez où les logs et les traces seront stockés. Utilisez un outil comme Opik ou, au minimum, des logs structurés pour chaque exécution. Sans observabilité, vous avancez à l’aveugle.
Q12 : votre problème peut-il être décomposé proprement en compétences distinctes? Si oui, utilisez plusieurs agents ou plusieurs workflows. Sinon, utilisez un seul agent ou un seul workflow.
Les mêmes douze questions. Des réponses différentes. Des architectures différentes.
Et comme promis, nous avons transformé ce contenu et plus encore en un aide-mémoire complet pour vous aider à déterminer ce que vous devez construire dans chaque scénario, des workflows simples aux systèmes multi-agents. Téléchargez-le gratuitement sur mon site Web : links.louisbouchard.ai.
Appliquer le cadre
Comment utiliser ce cadre en pratique?
Ne le traitez pas comme un formulaire où vous remplissez les douze réponses dans l’ordre. Utilisez-le comme outil de réflexion. Commencez par quelques questions, suivez la direction des réponses et revenez-y à mesure que le projet évolue. Vous pourriez commencer avec un seul agent, puis réaliser que vous devez le diviser. Vous pourriez commencer avec un workflow, puis réaliser que vous avez besoin de plus de flexibilité. C’est normal. Ce ne sont pas des règles rigides. Ce sont des lignes directrices qui vous aident à faire des compromis en toute connaissance de cause.
Et une habitude compte plus que ce à quoi la plupart des équipes s’attendent : documentez vos décisions. Ne documentez pas seulement ce que vous avez choisi. Documentez pourquoi. Lorsque quelqu’un demande « pourquoi utilisons-nous ce framework plutôt qu’un autre? », vous devriez pouvoir répondre en termes de forme de tâche, de besoins d’état, de complexité des outils, d’exigences de qualité et de contraintes opérationnelles. Cette documentation aide aussi les nouveaux membres de l’équipe à s’intégrer et vous aide à vous souvenir du raisonnement derrière le projet.
Si vous voulez approfondir notre façon de construire ces systèmes, nous enseignons tout cela dans nos cours chez Towards AI. Le but n’est pas seulement la théorie. C’est du travail pratique où vous construisez les systèmes, les déployez et apprenez à gérer les compromis en vous y heurtant réellement.
FAQ
Que permettent de décider les 12 questions sur l’architecture IA?
Elles aident à décider si vous avez besoin d’un workflow, d’un seul agent ou d’un système multi-agents plus complexe avant de vous enfermer dans la mauvaise conception.
Quand un seul agent IA suffit-il encore?
Un seul agent suffit souvent lorsque les outils sont bien délimités, l’objectif est clair et vous pouvez évaluer l’output sans ajouter une surcharge de coordination.
Quelle erreur coûteuse ces questions permettent-elles d’éviter?
L’erreur coûteuse consiste à construire autour d’une architecture à la mode, puis à découvrir à mi-chemin que le produit avait besoin d’un flow plus simple ou de contrôles plus stricts.
Pourquoi les agents devraient-ils rester légers pendant que les outils font le gros du travail?
Garder le travail déterministe dans des outils bien délimités facilite le test des échecs, tandis que l’agent demeure concentré sur la planification, la sélection et l’itération.
Que devrait renvoyer une boucle de validation lorsqu’un outil échoue?
Elle devrait renvoyer un feedback précis et exploitable que l’agent peut utiliser lors de sa prochaine tentative, plutôt qu’une erreur vague qui le force à deviner.
Pourquoi documenter les décisions d’architecture IA?
Consigner pourquoi vous avez choisi un framework, un modèle, un outil et une approche de gestion de l’état rend les compromis révisables et aide les nouveaux coéquipiers à comprendre le système.