Flux déterministe, agent unique ou système multi-agents : comment choisir le bon modèle pour une tâche

Avant de choisir une architecture, décrivez la tâche

La première décision n’est pas de savoir combien d’agents construire, mais quel travail vous souhaitez automatiser et comment reconnaître un résultat correct. Si l’objectif, les entrées et la séquence des étapes peuvent être décrits avec précision, un programme classique peut suffire. Si certaines décisions dépendent du contenu de chaque cas, il peut être utile de déléguer une partie du choix au modèle. Si des responsabilités distinctes doivent être assumées avec un certain degré d’indépendance, une composition d’agents peut être étudiée. Ce sont des options de conception, pas les étapes d’une progression où chaque choix serait nécessairement plus avancé ou meilleur que le précédent.

Pour comparer les différentes possibilités, rédigez une courte fiche décrivant la tâche. Indiquez l’objectif, les entrées attendues, les étapes connues, les variations rencontrées en pratique, le résultat observable et les conséquences d’une erreur. Précisez également les actions que le système peut effectuer et celles qui nécessitent une autorisation ou une vérification humaine. Cette description permet de ne pas confondre une tâche comprenant de nombreuses étapes avec une tâche qui exige de l’autonomie : une séquence longue mais stable peut tout à fait être programmée.

Les sources disponibles proposent des conseils pour choisir entre un agent unique et plusieurs agents, présentent des modèles de conception et comparent les agents aux flux de travail. Les extraits disponibles ne fournissent toutefois pas de mesures comparables des performances, des coûts ou des taux d’erreur de ces trois approches. La matrice et les exemples de ce guide constituent donc un cadre d’analyse pratique, et non l’affirmation qu’un modèle produit généralement de meilleurs résultats qu’un autre.

Modèle 1 : le flux déterministe

Dans un flux déterministe, le programme définit la séquence des opérations ainsi que les conditions qui permettent à chaque étape d’avancer, de se répéter ou de s’arrêter. Il peut inclure des appels à un modèle, par exemple pour classer un texte ou extraire des champs, sans pour autant transformer l’ensemble en agent autonome. La distinction utile porte sur le choix de l’étape suivante : dans un flux, cette décision est principalement spécifiée dans le code ou dans une configuration explicite.

Ce modèle convient généralement lorsque les entrées de la tâche sont connues, que les règles sont relativement stables, que les branches importantes sont peu nombreuses et que le résultat peut être validé à l’aide de contrôles précis. Un processus de traitement des factures pourrait extraire les données, vérifier la présence des champs obligatoires, rapprocher les montants et envoyer en révision les cas qui ne respectent pas une règle. Le processus peut prévoir des exceptions, mais l’équipe les représente par des conditions explicites au lieu de demander au modèle d’inventer un parcours de travail à chaque exécution.

Comme critère de conception, ce modèle permet à l’équipe d’examiner l’ordre prévu et de rattacher chaque décision à une règle ou à une étape. Cela ne garantit pas à lui seul le bon fonctionnement des composants : une extraction peut être erronée et une règle peut être mal définie. En revanche, les variations imprévues exigent de modifier les règles, d’ajouter des branches ou de transmettre le cas à une personne. Si les exceptions se multiplient, la maintenance du flux peut devenir difficile. Cela ne prouve pas automatiquement qu’un agent est nécessaire, mais invite à réexaminer la conception.

Dans un flux, les outils peuvent être limités aux appels prévus par le code. Les autorisations et les données accessibles dépendent de la mise en œuvre et de la configuration du système ; elles ne découlent pas du nom du modèle. La mémoire persistante n’est pas non plus une propriété nécessaire d’un flux. Il est possible de conserver l’état requis pour terminer une exécution, mais il convient de distinguer cet état temporaire d’une mémoire réutilisée d’une tâche à l’autre.

Modèle 2 : un agent unique équipé d’outils

Dans un modèle à agent unique, le modèle participe au choix des étapes suivantes en fonction de l’objectif, du contexte disponible et des outils qui lui sont proposés. Le programme continue de définir le cadre : l’objectif communiqué, les outils disponibles, les limites applicables et le moment où le système s’arrête ou demande de l’aide. L’autonomie ne signifie pas que les autorisations sont illimitées : le choix dynamique d’une action doit s’effectuer dans les conditions définies par le système.

Ce modèle peut être envisagé lorsque les cas varient de manière importante et qu’une séquence rigide ne convient pas, mais que les capacités nécessaires peuvent être couvertes par un ensemble limité d’outils. Prenons des demandes internes d’assistance : une personne signale un problème qui peut nécessiter de consulter de la documentation, de vérifier l’état d’un service et de rédiger une réponse. Selon le cas, l’agent pourrait décider laquelle de ces consultations est nécessaire. Si l’action a des conséquences importantes, le système peut se limiter à préparer une recommandation qu’une personne devra approuver.

Cette flexibilité entraîne des exigences d’évaluation différentes. Il ne suffit pas de vérifier un parcours unique : il faut observer les actions choisies par l’agent, les informations utilisées, le moment où il s’arrête et les cas où il demande une vérification. Une réponse finale correcte obtenue par hasard ne démontre pas que les étapes intermédiaires étaient appropriées. Il est utile d’enregistrer les décisions pertinentes de façon proportionnée et d’examiner aussi bien les cas résolus que ceux que le système a refusés ou transmis à une personne.

Les outils définissent une part importante des limites opérationnelles : ils indiquent les actions disponibles, mais leur portée réelle dépend de leur mise en œuvre, de l’authentification et des contrôles. Il ne faut pas supposer qu’une instruction en langage naturel remplace des contrôles techniques d’accès. La mémoire peut être inexistante, limitée à l’interaction en cours ou persistante, selon le produit et la conception. Pour une première évaluation, mieux vaut déclarer explicitement quel contexte est conservé et vérifier si cette conservation est nécessaire, plutôt que de supposer qu’une mémoire plus importante améliore le résultat.

Modèle 3 : un système multi-agents

Un système multi-agents réunit plusieurs composants aux fonctions distinctes qui interagissent pour accomplir une tâche. La coordination peut prendre plusieurs formes : un composant peut attribuer le travail, les composants peuvent échanger des résultats ou le système peut organiser une séquence de fonctions spécialisées. L’étiquette, à elle seule, ne précise pas qui détermine le flux, quelles informations sont partagées ni comment les désaccords sont résolus. Il faut spécifier ces propriétés pour pouvoir évaluer la conception.

Pour justifier la présence de plusieurs agents, la question n’est pas de savoir si le problème semble vaste, mais si la séparation des responsabilités apporte un avantage vérifiable par rapport à une seule unité de travail ou à un flux explicite. Cette option peut être étudiée lorsqu’il existe des tâches distinctes, des contextes qu’il est préférable de garder séparés ou des activités qui doivent produire des résultats indépendants avant une synthèse. Mais cette division ajoute de la coordination, des transferts de contexte et des points supplémentaires où des incohérences peuvent apparaître. En l’absence de mesures sur le cas concerné, il ne faut pas affirmer que cette séparation améliore la qualité ou réduit le temps nécessaire.

Reprenons l’exemple de la facture. Une conception hypothétique pourrait distinguer l’extraction du document, la vérification des politiques et la préparation d’un dossier à examiner par une personne. Avant de la construire, il faudrait se demander si ces responsabilités sont réellement indépendantes, si chacune peut être évaluée séparément et si le résultat combiné est meilleur ou plus facile à examiner qu’un flux fixe ou qu’un agent unique disposant des mêmes outils. Si la réponse est non, les composants supplémentaires pourraient représenter un coût sans bénéfice démontré.

Il est important de rendre les interactions visibles : il doit être possible de reconstituer les informations reçues par chaque composant, les résultats produits et la manière dont ceux-ci ont été utilisés ensuite. Cela aide à analyser les défaillances sans les éliminer pour autant. Les autorisations, les outils et la mémoire dépendent de la mise en œuvre ; l’architecture ne les détermine pas automatiquement. Une séparation fonctionnelle peut aider à délimiter les responsabilités, mais uniquement si les accès et les échanges de données sont conçus et vérifiés explicitement.

Comparaison appliquée et matrice de décision

Pour comparer équitablement les différents modèles, commencez par fixer la même tâche, le même ensemble de cas et le même critère de réussite. Pour l’exemple des factures, il faut utiliser des documents représentatifs, les mêmes règles comptables et une définition commune de ce qui constitue une extraction correcte, une transmission appropriée pour vérification et un enregistrement acceptable. La comparaison ne serait pas pertinente si un modèle disposait de davantage de contexte, d’outils ou d’intervention humaine qu’un autre sans que cela soit consigné.

Le tableau ci-dessous n’attribue pas de notes universelles. Il récapitule des questions auxquelles l’équipe peut répondre à partir de son processus, de ses tests et de ses mesures. Par exemple, une « forte variabilité » devrait signifier que des différences observables modifient les étapes nécessaires, et non simplement que l’équipe ne connaît pas encore le processus. De même, dire qu’un résultat est « facile à vérifier » suppose l’existence d’un test ou d’un critère d’acceptation, et pas seulement d’une impression subjective.

Outils, autorisations, mémoire et supervision

Ces éléments ne sont pas déterminés automatiquement par le choix d’un modèle plutôt qu’un autre. Le modèle change l’endroit où les décisions sont prises et le nombre de composants impliqués ; la portée réelle dépend des outils connectés, du contrôle des accès, des données fournies et de la logique de vérification. Il ne faut donc pas décrire une architecture comme « sûre » ou « contrôlée » uniquement parce qu’il s’agit d’un flux ou parce qu’elle est composée de plusieurs agents.

Pour les outils, documentez chaque action disponible, son effet et les personnes ou composants autorisés à l’appeler. Distinguez les opérations de lecture de celles qui modifient des données, envoient des messages ou produisent d’autres effets. Dans un flux, le programme peut appeler chaque outil à un point prévu. Avec un agent, le modèle peut choisir un outil parmi ceux qui sont autorisés. Dans un système multi-agents, il faut préciser quels composants ont accès à quels outils et comment vérifier qu’un résultat transmis ne déclenche pas une action non autorisée.

Pour la mémoire et le contexte, précisez ce qui est conservé pendant une exécution et ce qui, le cas échéant, est réutilisé dans une autre. Consignez la raison de cette conservation et vérifiez son effet à l’aide de cas de test. Une mémoire supplémentaire peut aider à préserver les informations nécessaires, mais elle peut également introduire un contexte obsolète ou non pertinent. Il faut traiter cette possibilité comme un risque de conception à tester, et non comme une conséquence inévitable.

La supervision humaine doit avoir une fonction précise. Elle peut confirmer des actions, résoudre des exceptions, vérifier des résultats ou arrêter le processus. Une vérification trop tardive risque de ne pas empêcher l’effet que l’on voulait contrôler ; vérifier chaque étape peut, à l’inverse, rendre l’automatisation inutile. Définissez les points de contrôle en fonction de l’impact d’une erreur et mesurez le nombre de cas examinés, le travail que ces vérifications demandent et les désaccords observés.

Évaluation initiale : mesurer avant d’accroître l’autonomie

Un pilote utile ne commence pas par une démonstration préparée pour que tout se passe bien. Il commence par un ensemble de cas représentatif de l’utilisation prévue : cas fréquents, limites connues, documents incomplets, entrées ambiguës et exceptions qui exigent un arrêt. Conservez une référence du processus actuel pour comparer les résultats et consignez les conditions de chaque test. Si les instructions, les outils ou les règles changent, notez ces changements afin de ne pas attribuer à l’architecture un effet qui pourrait provenir d’une autre modification.

Évaluez séparément le résultat et le parcours suivi. Parmi les questions portant sur le résultat : les données ont-elles été extraites correctement ? Le parcours autorisé a-t-il été choisi ? Le besoin d’une vérification a-t-il été détecté ? Une action a-t-elle été évitée lorsque les informations étaient insuffisantes ? Parmi les questions portant sur le processus : quelles décisions intermédiaires ont été prises ? Quels outils ont été utilisés ? Les informations pertinentes ont-elles été consultées ? Le système s’est-il arrêté au bon moment ? Pour les agents et les systèmes multi-agents, ces traces aident à déterminer si une réponse acceptable a été obtenue par un parcours approprié.

Définissez à l’avance les critères qui vous feront poursuivre, limiter ou interrompre le test. Si les erreurs les plus graves surviennent au moment du choix d’une action, il peut être nécessaire de restreindre les outils ou de rendre cette décision au code. Si les cas ne peuvent pas être évalués de façon cohérente, il faut d’abord améliorer la définition de la réussite. Si la vérification humaine corrige fréquemment le même type de résultat, le système peut avoir besoin d’une règle explicite, de meilleures entrées ou d’une étape de validation, et pas nécessairement de davantage d’agents.

Quand ne pas utiliser d’agent, ou quand réduire son autonomie

Ne pas utiliser d’agent peut être la bonne décision lorsqu’une routine connue peut être traitée par du code classique, lorsque les règles sont vérifiables et stables, ou lorsqu’il n’existe aucun moyen fiable de contrôler le résultat. Il peut également être préférable de garder une personne dans le processus lorsque le coût d’une erreur est élevé et que les actions sont difficiles à annuler. Dans ces cas, l’automatisation peut se limiter à préparer des données, résumer des informations ou proposer un parcours sans l’exécuter.

Revenez à un flux déterministe, ou limitez l’agent à une seule étape, si le choix des actions n’apporte aucun avantage mesurable, si l’agent utilise des outils inutiles, si les exceptions peuvent désormais être décrites par des règles claires ou s’il est difficile de reconstituer la manière dont une décision a été prise. En cas de désaccord entre les composants d’un système multi-agents, demandez-vous si leur séparation est réellement utile : pour le cas concerné, un parcours explicite assorti de validations peut être plus facile à tester, mais l’équipe doit le vérifier.

Si une composition d’agents est envisagée, commencez par des fonctions distinctes dotées d’entrées, de sorties et de critères d’acceptation définis. Ne découpez pas intuitivement une tâche en une multitude de rôles abstraits. Testez d’abord une version simple, observez où elle échoue et ne l’élargissez que lorsqu’un problème précis a été identifié et que la séparation est susceptible d’y répondre. Le conseil de commencer par le modèle le plus simple figure également dans l’une des sources secondaires fournies ; il est présenté ici comme une heuristique de conception à confronter au cas d’usage, et non comme une loi universelle.

Liste finale pour documenter votre choix

Une décision d’architecture est plus utile lorsqu’elle peut être réexaminée après l’observation du système en conditions réelles. Consignez le problème à résoudre, les options comparées et les éléments qui ont motivé la décision. Le choix n’a pas besoin d’être définitif : si la variabilité des cas, les conséquences d’une erreur ou les outils disponibles changent, le modèle approprié peut lui aussi changer.

Pour approfondir la comparaison entre un agent unique et plusieurs agents, consultez le guide de Microsoft Learn mentionné dans les sources. Pour comparer les agents et les flux de travail, la documentation d’UiPath peut être consultée, en gardant à l’esprit qu’il s’agit de la documentation d’un fournisseur. Les pages de Microsoft Learn et de Google Cloud consacrées aux modèles de conception apportent des conseils d’architecture ; leurs recommandations doivent être évaluées au regard des besoins et des contraintes de l’équipe. Ces références ne remplacent pas vos propres tests et ne démontrent pas, à elles seules, des résultats de performance pour une tâche donnée.

Poursuivre l’exploration

Corrections et transparence

Si vous repérez une information incorrecte ou obsolète, envoyez-nous la page et la source à vérifier.