Ce que l'on compare réellement
Un système multi-agents désigne un ensemble de programmes autonomes, dotés chacun d'un rôle, d'outils et parfois de mémoire, qui collaborent pour atteindre un objectif commun. Un planificateur découpe la demande, un exécutant appelle des services, un vérificateur contrôle le résultat. À l'opposé, l'architecture monolithique concentre la logique dans un seul agent ou un seul appel : la demande entre, la réponse sort, sans intermédiaire. La comparaison ne porte donc pas sur la technologie mais sur l'organisation du travail. Répartir les rôles introduit de la coordination ; tout centraliser introduit de la rigidité. Deux manières distinctes de payer la complexité, selon l'endroit où on préfère la concentrer.
Cette distinction se confond souvent avec un débat de mode. On présente le multi-agents comme l'étape supérieure, laissant croire qu'un montage unique serait dépassé. C'est une erreur de cadrage. Un agent seul, bien outillé, avec une consigne solide et des garde-fous clairs, résout une majorité de cas réels. Le multi-agents apporte de la valeur quand la tâche se décompose naturellement en sous-problèmes indépendants, ou quand plusieurs expertises doivent dialoguer. Là où cette décomposition n'existe pas, ajouter des agents revient à multiplier les points de rupture sans rien gagner en qualité. La bonne question n'est pas combien d'agents, mais quel découpage le problème impose.
La complexité a un coût, souvent sous-estimé
Chaque agent ajouté crée une dépendance supplémentaire : il faut définir son rôle, ses accès, ses critères de succès, et prévoir ce qui se passe quand il échoue. Un enchaînement de cinq agents multiplie les endroits où une réponse approximative peut se propager. Le coût d'exécution grimpe aussi, puisqu'une demande traverse plusieurs modèles avant d'aboutir. À cela s'ajoute la difficulté à observer le comportement d'ensemble : quand le résultat est mauvais, identifier quel maillon a dévié demande une traçabilité que peu de montages prévoient. La coordination n'est jamais gratuite, même lorsqu'elle est bien conçue, et elle se paie en surveillance comme en argent.
À l'inverse, le monolithe paie d'autres facteurs. Concentrer toute la logique dans une unique consigne la rend vite ingérable : la moindre règle ajoutée entre en conflit avec les précédentes, et le comportement devient difficile à prévoir. Un agent qui doit à la fois rédiger, calculer, consulter une base et respecter vingt règles finit par mal faire certaines choses, faute d'attention disponible. Le monolithe monte aussi mal en charge quand des besoins hétérogènes se greffent. Sa rigidité se paie au moment où l'on veut faire évoluer une partie sans casser l'ensemble. Aucune des deux approches n'évite la complexité : elles la déplacent simplement ailleurs.
Quand un agent unique suffit encore
Beaucoup de projets lancés en multi-agents auraient gagné à rester simples. Un assistant de rédaction, un outil de synthèse, un module de réponses aux questions courantes se conçoivent très bien autour d'un agent unique correctement outillé. La règle de départ gagne à être conservatrice : commencer par le montage le plus simple qui produit un résultat acceptable, puis n'introduire un second agent que lorsqu'un besoin précis le justifie. On sépare alors pour une raison nommable, confier la vérification à un agent distinct par exemple, et non parce que l'architecture modulaire inspire davantage. La simplicité initiale laisse de la marge pour corriger, mesurer et comprendre ce qui se passe réellement en production.
Un agent seul impose cependant de la discipline. Il faut lui donner des outils bien délimités, un cadre strict sur ce qu'il a le droit de faire, et des points de contrôle avant toute action irréversible. Sans cela, la concentration de pouvoirs crée un risque : une seule manipulation réussie peut déclencher l'ensemble des capacités disponibles. Beaucoup de montages multi-agents sont d'ailleurs nés de cette inquiétude, en séparant la lecture de l'écriture ou la décision de l'exécution. Mais on peut atteindre le même cloisonnement en restreignant les droits d'un agent unique, sans en multiplier le nombre. La sécurité vient des permissions accordées, pas du nombre de programmes.
Décider selon le problème, pas selon la mode
Trancher entre les deux architectures suppose de regarder le travail réel. La tâche se découpe-t-elle en étapes franchement distinctes, menées par des compétences différentes ? Faut-il plusieurs sources de vérité ou plusieurs niveaux de contrôle ? Les sous-tâches peuvent-elles échouer indépendamment sans compromettre le tout ? Si la réponse est non, un monolithe bien conçu reste le choix raisonnable. Si le problème ressemble au contraire à un atelier où chaque poste a son métier, alors la séparation apporte de la clarté. Décider à partir du problème et non de la tendance évite les deux excès : la sur-ingénierie qui fragilise et la simplicité qui ne tient pas la charge.
Quel que soit le choix, deux exigences demeurent. D'abord la traçabilité : on doit pouvoir reconstituer ce qui s'est passé, étape par étape, pour diagnostiquer une erreur. Ensuite la supervision : plus un système enchaîne d'actions autonomes, plus il faut prévoir où l'humain reprend la main, notamment pour les décisions sensibles. Le règlement européen sur l'intelligence artificielle impose selon les usages des obligations de transparence et de contrôle humain, mises en œuvre par étapes entre 2025 et 2026. Ces contraintes pèsent sur les deux architectures. Elles rappellent que la question n'est pas de savoir laquelle est moderne, mais laquelle on saura faire fonctionner et surveiller dans la durée.
Aller plus loin
Choisir entre un agent unique et un système multi-agents engage autant l'architecture technique que la maîtrise des risques. Notre catalogue des 31 formations propose des parcours sur la conception de systèmes multi-agents et l'orchestration d'agents d'IA.
Vous voulez maîtriser ce sujet en pratique ?
Cabinet MARA forme en ligne, sur des cas réels, avec des modules courts et un suivi de progression.
Voir la formation liée Les 31 formations