- Le nombre d’agents doit découler de la décomposition du travail.
- Chaque délégation ajoute un contrat, un coût et un point de défaillance à gérer.
- Une validation humaine doit être placée avant les actions qui l’exigent.
Un retour d’ingénierie à contextualiser
Dans son article du 24 mars 2026 sur les applications exécutant des tâches longues, Anthropic décrit un dispositif qui sépare notamment planification, génération et évaluation. Ce retour montre une manière d’organiser le travail d’agents dans un contexte précis. Il ne démontre pas que plusieurs agents sont toujours plus efficaces qu’un seul.
Notre point de départ est le processus métier. Nous examinons ce qui doit être déterministe, ce qui nécessite une interprétation et ce qui doit être approuvé. L’architecture vient ensuite. Cette séquence permet d’éviter une coordination complexe lorsque quelques étapes explicites suffisent.
Distinguer trois types de solutions
Un workflow suit des étapes définies à l’avance : recevoir un document, extraire certains champs, vérifier une règle puis enregistrer une proposition. Il convient lorsque les chemins sont connus et que les exceptions peuvent être décrites. Une étape peut utiliser un modèle sans que tout le processus devienne un système autonome.
Un agent dispose d’une marge de décision pour choisir une prochaine action parmi des outils autorisés. Un système multi-agents distribue ce travail entre plusieurs rôles. Cette spécialisation peut être utile lorsque les contextes, les outils ou les responsabilités diffèrent. Elle impose cependant de définir ce qui est transmis et comment les désaccords sont résolus.
Définir les contrats entre les agents
Chaque rôle doit avoir une entrée, une sortie attendue, des outils et une condition d’arrêt. Un agent de recherche peut retourner des passages et leurs sources. Un agent de synthèse reçoit ces éléments et produit une note structurée. Un contrôle vérifie ensuite la présence des éléments requis, sans présumer que la note est correcte simplement parce qu’un autre agent l’a produite.
Utilisez des formats stables pour les échanges. Précisez la manière de signaler une information manquante, un échec de recherche ou une contradiction. Les journaux doivent permettre de comprendre le déroulement d’un cas sans exposer inutilement les données. Une boucle sans limite ou une reprise automatique indéfinie doit être remplacée par une règle explicite.
Placer les validations au bon endroit
La préparation d’une action et son exécution sont deux étapes différentes. Un agent peut proposer une réponse commerciale sans être autorisé à l’envoyer. Il peut suggérer une mise à jour CRM sans disposer du droit de modifier tous les enregistrements. Les permissions doivent correspondre à la mission et au niveau de risque du processus.
La personne qui valide doit voir les informations nécessaires pour décider : contenu proposé, sources pertinentes, destinataire et conséquence de l’action. Une validation qui intervient après l’envoi ne contrôle pas cet envoi. Dans un pilote, commencez par observer les propositions avant d’étendre progressivement les possibilités d’exécution.
Tester sur les erreurs et les exceptions
Le scénario nominal n’est qu’une partie de l’évaluation. Ajoutez une source indisponible, une donnée contradictoire, une réponse d’API inattendue et une demande hors périmètre. Observez si le système s’arrête, demande une précision ou transmet une proposition incomplète comme si elle était certaine.
Comparez aussi les architectures sur le même jeu de cas. Mesurez la qualité du résultat, la durée totale, les appels aux modèles et la charge de revue. Le multi-agents doit justifier son coût de coordination. Si la séparation ne produit pas un avantage observable ou un meilleur contrôle, simplifier le système peut être la bonne décision.
Un exemple : préparer un rendez-vous client
Prenons un scénario illustratif. La demande est de préparer un dossier à partir d’informations commerciales autorisées. Un premier rôle récupère les éléments du CRM et des documents. Un deuxième organise les faits, les questions ouvertes et un ordre du jour. Une étape de contrôle repère les sources absentes. Le responsable commercial valide le dossier.
Ce processus n’a pas besoin, par défaut, d’agents capables d’envoyer des emails, de changer des prix ou d’explorer tous les systèmes internes. Le périmètre s’étend seulement si un besoin identifié le justifie. Pour cadrer votre propre projet, apportez un exemple de demande, un résultat attendu et les outils que le système devrait pouvoir consulter.
| Option | À privilégier lorsque… | Vigilance |
|---|---|---|
| Workflow | Les étapes et exceptions sont connues | Ne pas rigidifier un besoin réellement variable |
| Agent unique | Une responsabilité cohérente nécessite des choix | Définir outils, limites et arrêt |
| Multi-agents | Les rôles et contextes gagnent à être séparés | Coordination, répétitions et cohérence des sorties |
Sources & méthode
Cette perspective associe les publications citées à une analyse éditoriale. Les exemples illustratifs ne constituent pas des résultats clients. Les fonctionnalités et conditions des fournisseurs peuvent évoluer.