À l’intérieur d’un système multi-agents : notes d’architecture pour les concepteurs de cryptomonnaies

Imaginez une entreprise de cryptomonnaies qui vend ses services aux entreprises et qui souhaite un logiciel capable de surveiller les protocoles DeFi, d’évaluer la liquidité, de juger les risques liés aux contrats intelligents, de rééquilibrer les réserves financières, de signaler les transactions anormales et même d’exécuter des trades selon des politiques prédéfinies. Un agent d’IA chargé de tout cela finit par avoir trop de responsabilités. Il doit analyser les données du marché, interroger l’infrastructure de la chaîne, évaluer les risques, appeler des API, prendre des décisions financières et signer des transactions, tout cela au sein d’un seul cycle de raisonnement. Tester, mettre à l’échelle et sécuriser un tel système devient très rapidement complexe.

La réponse habituelle consiste à répartir le travail entre des agents spécialisés et à ajouter une couche d’orchestration par-dessus. Il ne s’agit pas simplement de plusieurs modèles de langage qui communiquent entre eux. Il s’agit d’une architecture logicielle dans laquelle le raisonnement des modèles, la logique d’application, les données, les outils, les permissions et l’exécution sont délibérément séparés. Ce qui suit explique comment ces éléments s’assemblent et ce que les concepteurs de systèmes de production dans ce domaine devraient prendre en compte.

Qu’est-ce qu’un système multi-agents ?

Plusieurs agents spécialisés qui coopèrent pour accomplir une tâche trop complexe pour qu’un seul d’entre eux puisse la gérer : telle est la définition. Une formule utile pour un agent unique :

Agent = modèle d’IA + instructions + contexte + outils + état + boucle d’exécution

On ajoute une deuxième couche pour le groupe :

Agents + orchestration + état partagé + communication + politiques

Une plateforme de gestion de trésorerie pourrait comporter les composants suivants :

1. Un agent de recherche qui collecte des données sur les protocoles et le marché.
2. Un agent de risque qui évalue les risques liés aux contrats, à la liquidité et aux protocoles.
3. Un agent de portefeuille qui compare les opportunités et calcule les allocations.
4. Un agent de conformité qui applique les règles commerciales de l’entreprise.
5. Un agent d’exécution qui prépare et soumet les transactions.
6. Un agent de surveillance qui vérifie sur la chaîne ce qui s’est réellement produit.

Prenons cette instruction : placer 50 000 USDC dans le produit à rendement le plus sûr disponible, à condition que le protocole respecte la politique de risque et que les coûts d’exécution restent inférieurs à 0,5 %. Cela nécessite plusieurs compétences distinctes, c’est pourquoi le système le transforme en une série d’étapes successives :

```text
User Request
     ↓
Orchestrator
     ↓
Research Agent
     ↓
Risk Agent
     ↓
Portfolio Agent
     ↓
Policy Check
     ↓
Execution Agent
     ↓
Blockchain
     ↓
Verification
```

Chaque agent s’occupe d’un petit problème et aucun n’a à gérer l’ensemble du flux de travail.

Les couches d’un système de production

Sept éléments réapparaissent sans cesse : un environnement d’exécution des agents, un orchestrateur, un état partagé, une couche d’outils, une couche de politiques et de sécurité, une infrastructure d’exécution, ainsi que des mécanismes d’observabilité. Chacun répond à une question technique distincte.

Environnement d’exécution des agents

Cet environnement fait fonctionner un agent. En production, un agent n’est pas simplement une requête entrante suivie d’une réponse sortante. Il fonctionne comme un cycle :

  ```text
Input
 ↓
Build Context
 ↓
Ask Model to Reason
 ↓
Choose Action
 ↓
Call Tool / Agent / Return Result
 ↓
Receive Result
 ↓
Update Context
 ↓
Reason Again
```

Imaginons qu’un agent de recherche soit chargé de comparer les protocoles de prêt DeFi. Il récupérerait une liste de ces protocoles, obtiendrait leur TVL actuel, chercherait les taux de prêt, comparerait la liquidité, sélectionnerait les candidats les plus solides et les transmettrait à l’agent chargé des risques. Le modèle fournit les raisonnements, tandis que l’application qui l’entoure contrôle ce qui est réellement exécuté. Cette séparation est importante, car un modèle ne devrait pas effectuer des tâches que du logiciel ordinaire peut accomplir mieux. Multiplier 50 000 dollars par 8,2 % ne nécessite pas d’LLM, car une simple fonction est plus rapide, moins chère et donne toujours le même résultat.

Orchestrateur

L’orchestrateur constitue le centre de contrôle. Il choisit quel agent doit s’exécuter, quelles instructions lui être données, quelle étape suivre, quelles tâches peuvent être exécutées en parallèle, quand le travail est terminé et quelle action entreprendre en cas d’échec d’un agent. Il existe deux styles de base.

Orchestration pilotée par un modèle. Un modèle de supervision choisit le spécialiste dont il a besoin.

           ```text
        Supervisor Agent
              │
        ┌─────┼─────┐
        ▼     ▼     ▼
   Research  Risk  Analytics
```

Le superviseur pourrait penser qu’il a d’abord besoin de données de protocole, il appelle donc l’agent de recherche, et une fois le résultat reçu, il décide qu’une évaluation de sécurité est nécessaire et appelle l’agent de risque. Cela est flexible, mais le routage peut devenir imprévisible, les appels de modèles supplémentaires s’accumulent et les coûts augmentent en conséquence.

Orchestration pilotée par du code. L’application définit la séquence des opérations.

```text
Research
   ↓
Risk Analysis
   ↓
Policy Check
   ↓
Simulation
   ↓
Approval
   ↓
Execution
```

Cette version est plus simple à tester et à maîtriser.

Mélange des deux approches. Pour les produits financiers B2B, la configuration la plus efficace combine souvent ces deux méthodes : le modèle prend les décisions tandis que le code applique les règles. Le modèle peut conclure que le protocole A offre le meilleur rendement ajusté au risque, tandis que l’application insiste sur le fait que tout montant supérieur à 50 000 dollars nécessite une approbation supplémentaire. L’IA fait des recommandations et le logiciel les met en œuvre.

État partagé

Les agents doivent pouvoir voir les résultats des étapes précédentes. Fournir l’intégralité de la conversation à chacun d’eux est une perte de temps ; c’est pourquoi le système conserve plutôt un enregistrement structuré du flux de travail.

Pour une demande USDC, cet enregistrement contiendrait l’actif (USDC), le montant (50 000), la chaîne (Ethereum), une liste des protocoles candidats (Aave et Morpho), ainsi que trois champs d’état (risque, politique et exécution) initialement réglés sur « en attente », « en attente » et « non démarré ».

L’agent de recherche remplit des champs tels que les protocoles candidats, les résultats obtenus et les données de marché. L’agent de risque ajoute une note ainsi que ses constatations en matière de sécurité. L’agent d’exécution ne voit que ce dont il a besoin pour accomplir sa tâche. La structure est ordonnée :

               ```text
                Shared State
                    │
         ┌──────────┼──────────┐
         ▼          ▼          ▼
    Research      Risk     Execution
     Agent        Agent     Agent
        └──────────┼──────────┘
                   ▼
             Updated State
```

Un dossier partagé rend également beaucoup plus simple la suspension, la reprise, l’audit et le débogage d’un flux de travail.

Communication : transferts et agents en tant qu’outils

Les agents collaborent de deux manières utiles. Lors d’un transfert, le contrôle passe d’un agent à l’autre.

```text
Research Agent
↓
Risk Agent
↓
Portfolio Agent
```

Les transferts interviennent lorsque la responsabilité change : une fois la recherche de marché terminée, c’est l’agent chargé des risques qui est responsable de l’évaluation des candidats. Lorsqu’un agent est utilisé comme outil, un agent appelle un autre et conserve le contrôle.

     ```text
      Supervisor
      /    |   \
 Research Risk Analytics
```

Le superviseur peut demander à l’agent chargé des risques de tester un protocole selon les critères de l’entreprise, d’obtenir une réponse structurée et de poursuivre. Cela est utile lorsque un seul agent central doit fusionner plusieurs avis spécialisés.

Couche d’outils

Un agent ne peut pas accéder directement à une blockchain ou à une base de données. Les outils constituent le lien entre eux. Un agent spécialisé en cryptomonnaies peut disposer d’interfaces RPC pour les blockchains, d’API pour les données de marché, d’agrégateurs DEX, d’indexeurs, de bases de données de risques, d’infrastructures de portefeuille et de systèmes de trésorerie interne, accessibles via des opérations telles que get_balance(), read_contract(), estimate_gas(), simulate_transaction() et submit_transaction().

Accordez à chaque agent le minimum d’accès nécessaire à son fonctionnement. Un agent de recherche n’a besoin que de read_market_data() et read_protocol_data(). Un agent d’exécution peut disposer de simulate_transaction() et submit_transaction(). Rien ne justifie de confier les droits sur les portefeuilles ou les transactions à tous les agents, et des permissions restreintes limitent les dommages en cas de comportement anormal ou de compromission.

La frontière entre l’IA et la chaîne

Ce pourrait être le point de conception le plus important pour les produits cryptographiques. La sortie d’un modèle est probabiliste, tandis que l’exécution sur la blockchain est déterministe et ne peut souvent pas être annulée. Par conséquent, aucun agent ne devrait contrôler directement la transaction finale. Une approche plus sûre se déroule comme suit :

```text
Agent Decision
     ↓
Schema Validation
     ↓
Policy Check
     ↓
Risk Check
     ↓
Transaction Simulation
     ↓
Authorization
     ↓
  Signing
     ↓
Blockchain
```

Imaginez que l’agent décide d’échanger 50 000 USDC contre de l’ETH. La couche d’exécution doit vérifier de manière indépendante si le USDC est un actif approuvé et l’ETH une destination autorisée, si le montant reste dans les limites fixées pour l’utilisateur, si le glissement de prix est acceptable, si le destinataire est correct, si la transaction se simule sans problème et si l’utilisateur doit donner son accord. L’agent propose une action, et une couche déterministe décide si elle peut être mise en œuvre. Les systèmes financiers reposent sur cette séparation.

Règles de sécurité et gestion des pannes

Encadrez chaque décision de l’IA par des limites déterministes. Une configuration pourrait indiquer : montant maximal de transaction de 50 000, glissement de prix maximal de 0,5 %, liquidité minimale de 5 M, chaînes autorisées : Ethereum, Arbitrum et Base. Un modèle ne peut pas contourner ces valeurs en reformulant ses réponses.

N’oubliez pas non plus qu’une structure valide ne prouve pas que le contenu est correct. Un résultat comme {"risk_score": 0.04} peut être parfaitement formulé tout en reposant sur une logique complètement erronée. Un système de production doit vérifier le format, les règles métier, la fraîcheur des données, la fiabilité des sources ainsi que les résultats des appels aux outils finaux :

```text
Agent Output
     ↓
Schema Validation
     ↓
Business Validation
    ↓
Data Validation
    ↓
Tool Execution
    ↓
Result Verification
```

Idempotence. Prenons le cas d’une soumission qui expire. L’agent peut décider que la transaction a échoué et essayer à nouveau, mais la première tentative a peut-être déjà abouti, ce qui entraînerait une duplication d’une action financière. Le service d’exécution doit attribuer à chaque demande un identifiant unique, par exemple exec_829192, et le lier à la transaction qui en résulte. Si la même demande arrive à nouveau, le service renvoie le résultat existant sans soumettre rien de nouveau. Dans les workflows financiers, cette propriété n’est pas optionnelle.

Observabilité

Les journaux simples ne suffisent pas pour les systèmes d’agents, car les ingénieurs ont besoin de connaître l’ensemble du parcours de décision. Pour chaque étape, il faut enregistrer quel agent l’a exécutée, quel modèle elle a utilisé, quels outils elle a appelés avec quels paramètres, ce qui est revenu, quelles politiques ont été activées, combien de temps chaque étape a duré et quelle transaction a finalement été envoyée. Lorsqu’une transaction échoue, il doit être possible de savoir qui a pris la décision, sur quels données, quelle politique l’a approuvée, comment la transaction a été constituée et ce qui s’est réellement passé sur la chaîne. Sans ce niveau de visibilité, faire fonctionner ces systèmes en production devient une affaire de suppositions.

Au-delà de l’élément central, un déploiement en production doit intégrer un contrôle d’identité et d’accès, une gestion des clés, un stockage pour l’état, des mécanismes de limitation, un suivi, des exécutions d’évaluation ainsi qu’un historique d’audit. Une démonstration ne montre jamais ces éléments, pourtant ce sont eux qui déterminent si le système fonctionne à l’échelle d’une entreprise.

Systèmes distribués intégrant des LLM

La manière la plus claire de comprendre ce défi est de cesser de considérer un système multi-agents comme un ensemble de chatbots. Il s’agit d’un système distribué où certaines décisions sont prises de manière probabiliste par un modèle, ce qui signifie que toutes les préoccupations classiques restent pertinentes : gestion de l’état, authentification, autorisation, concurrence, tentatives répétées, idempotence, récupération en cas de panne, validation des données et observabilité.

Le modèle constitue la couche de raisonnement tandis que l’architecture représente la couche de contrôle. Lorsque des actifs réels et des transactions irréversibles sont en jeu, cette différence revêt une grande importance. Un système bien conçu ne cherche pas à atteindre une autonomie illimitée ; il vise plutôt une autonomie contrôlée : des agents libres de raisonner, de coopérer et de s’adapter, tandis que du logiciel déterministe gère les permissions, les limites financières, la validation et l’exécution.

Le point clé

La valeur ne réside pas dans la possession de plusieurs modèles, mais plutôt dans la division des workflows complexes en unités plus petites et spécialisées qui peuvent être contrôlées. Pour le crypto B2B, ce principe peut être formulé simplement :

• Le raisonnement relève des agents.
• La récupération des données et les opérations relèvent des outils.
• La coordination relève de l’orchestrateur.
• Les règles métier sont appliquées par des politiques.
• Les transactions passent par la couche d’exécution, qui les contrôle.
• Le règlement final a lieu directement sur la blockchain.

Lorsque ces responsabilités sont séparées, le système est plus facile à mettre à l’échelle, à tester, à sécuriser et à auditer. L’objectif n’est pas de faire paraître l’IA intelligente, mais de rendre les workflows complexes pilotés par l’IA suffisamment fiables pour être utilisés en production.