Du chaos à la clarté : cinq leçons essentielles pour bâtir des systèmes multi-agents fiables en entreprise

Lorsqu’une entreprise technologique de taille moyenne a fait appel à nous, chez Zokforce, pour concevoir un système de gestion des talents RH reposant sur plusieurs agents d’IA, nous pensions comprendre les défis qui nous attendaient. Sur le plan des affaires, le projet était convaincant : automatiser les processus de recrutement, simplifier l’intégration des nouveaux employés et réduire les tâches RH manuelles. L’approche technique semblait simple : déployer des agents spécialisés pour chaque domaine, les coordonner au moyen d’un orchestrateur central et laisser l’IA faire le gros du travail.

Ont suivi six mois d’essais, d’erreurs et d’enseignements durement acquis, qui ont profondément changé notre approche du développement de systèmes multi-agents. Cet article raconte ce parcours : non pas une belle réussite aux indicateurs impeccables, mais la réalité chaotique de la construction de systèmes d’IA complexes, les erreurs que nous avons commises et les leçons tirées de ces difficultés.

Des débuts prometteurs

Sur le papier, l’architecture initiale semblait élégante. Nous avions conçu cinq agents spécialisés travaillant de concert :

Agent de recrutementAnnonces · Tri des CV

Agent orchestrateurTous les agents se coordonnent via lui

Agent de rémunérationPaie · Avantages

Agent d’intégrationTraitement des documents · Accès système

Agent de performanceObjectifs · Évaluations

Le plan :

• Agent de recrutement : gérer les offres d’emploi, trier les CV, planifier les entrevues
• Agent d’intégration : coordonner le traitement des documents, les accès aux systèmes et les calendriers de formation
• Agent de rémunération et avantages sociaux : calculer la paie, gérer les avantages sociaux, produire des rapports
• Agent de gestion de la performance : fixer les objectifs, gérer les processus d’évaluation, recueillir la rétroaction
• Agent orchestrateur : acheminer les tâches, surveiller les processus, résoudre les conflits

Chaque agent fonctionnerait de façon autonome dans son domaine, tandis que l’orchestrateur assurerait des passages de relais fluides. L’équipe RH du client pourrait se concentrer sur le travail stratégique pendant que les agents se chargeraient des opérations courantes.

Puis nous avons essayé de le déployer.

Leçon 1 : le piège de la spécification — quand des consignes « claires » ne le sont pas assez

Ce qui a mal tourné

En examinant les journaux d’exécution, nous avons découvert un problème fondamental : nos consignes étaient ambiguës. Nous avions demandé à l’agent de « trier les CV pour repérer les candidats qualifiés selon les exigences du poste ». Cela semble clair, non ? Pourtant, nous n’avions pas défini :

• ce que « qualifié » voulait dire en termes mesurables
• comment traiter les cas limites (p. ex. des candidats légèrement en deçà de l’expérience exigée, mais aux compétences exceptionnelles)
• quoi faire quand les exigences du poste se contredisaient (10 ans d’expérience exigés pour un salaire de débutant)
• quand faire remonter les décisions incertaines plutôt que de trancher de façon autonome

L’agent comblait ces lacunes avec ses propres interprétations, qui changeaient de façon imprévisible d’une exécution à l’autre.

Le problème de fond

Cela a mis au jour ce que la recherche appelle les erreurs de spécification, le mode de défaillance le plus courant des systèmes multi-agents. Le problème n’est pas que les LLM ne comprennent pas les consignes ; c’est qu’ils excellent à trouver des interprétations valides auxquelles nous n’avions jamais pensé.

Un échec particulièrement mémorable s’est produit quand on a demandé à l’agent d’intégration de « créer les comptes des nouveaux employés ». Pour un employé, il a créé des comptes dans tous les systèmes. Pour le suivant, il n’a ouvert que l’accès au courriel. Pour un troisième, il a créé des comptes en double dans la base de données RH. Même consigne, trois interprétations différentes, aucune cohérence.

Ce que nous avons appris

Evaluate each resume against the following criteria:

1. Required qualifications (must have ALL):
   - [List with exact matching rules]
   
2. Preferred qualifications (weight each):
   - [List with scoring rubric]
   
3. Disqualifying factors (immediate rejection):
   - [Explicit list]

For candidates scoring 80-100: Auto-advance
For candidates scoring 60-79: Flag for human review
For candidates scoring below 60: Auto-reject with reason code

If any criterion is ambiguous or missing, mark as 
"INSUFFICIENT_INFO" and request clarification.

Même cela ne suffisait pas. Nous avons dû ajouter une validation des contraintes : avant tout traitement, l’agent doit d’abord confirmer qu’il dispose de toute l’information requise, et il doit produire sa notation dans un format structuré que nous pouvons vérifier par programme.

Leçon 2 : le cauchemar de la coordination — quand les agents n’arrivent pas à communiquer

Ce qui a mal tourné

Pendant des jours, nous avons multiplié les allers-retours pour corriger le protocole de communication. Nous avons ajouté des champs au message. Puis l’agent de rémunération s’est plaint d’avoir besoin d’autres champs. Nous les avons ajoutés. Puis l’agent de gestion de la performance a eu besoin d’une autre structure de données encore.

En deux semaines, nous avions cinq formats de message différents, aucune interopérabilité, et des agents qui cessaient tout simplement de répondre quand ils recevaient une entrée inattendue.

Le problème de fond

2 agents = 1 lien

4 agents = 6 liens

5 agents = 10 liens

La complexité de coordination croît au carréChaque échange est une occasion de malentendu, de perte de données ou d’erreur de format.

C’est le problème de l’échec de coordination, qui afflige les déploiements multi-agents. Pris isolément, chaque agent fonctionnait correctement, mais leur comportement collectif était chaotique. Le problème croît de façon exponentielle : 2 agents = 1 point de coordination potentiel, 4 agents = 6 points de coordination potentiels, 5 agents (notre système) = 10 points de coordination potentiels.

Ce que nous avons appris

{
  "message_id": "uuid",
  "conversation_id": "uuid",
  "sender_agent": "recruitment",
  "receiver_agent": "onboarding",
  "message_type": "TASK_DELEGATION",
  "timestamp": "ISO8601",
  "payload": {
    "action": "initiate_onboarding",
    "entity_id": "emp_12345",
    "entity_type": "employee",
    "required_data": {
      "employee_info": {...},
      "employment_details": {...}
    }
  },
  "callback_required": true,
  "callback_timeout_seconds": 300
}

Surtout, nous avons mis en place des contrats d’interface stricts. Chaque agent publie un schéma qui définit précisément les données qu’il exige et celles qu’il produit. L’orchestrateur valide chaque message par rapport à ces contrats avant de le livrer.

Si un agent tente d’envoyer des données incomplètes, le message est rejeté à la frontière, et non après que l’agent destinataire a déjà tenté de le traiter et échoué mystérieusement.

Leçon 3 : la fragmentation de la mémoire — quand le contexte disparaît

Ce qui a mal tourné

En creusant, nous avons découvert que l’agent ne pouvait pas réellement se souvenir de la commande de l’ordinateur : il avait récupéré cette information pour répondre à la première question, généré une réponse, puis l’avait aussitôt oubliée. Devant la question suivante, il n’avait aucun contexte de l’échange précédent.

Ce n’était pas un incident isolé. Les agents « oubliaient » régulièrement des décisions qu’ils avaient prises, contredisaient des informations qu’ils venaient de fournir ou demandaient des données qu’ils avaient déjà reçues.

Le problème de fond

C’est le problème de la fragmentation du contexte : chaque agent tient sa propre mémoire de travail éphémère, et cette mémoire disparaît dès que la conversation passe à autre chose. Dans des processus d’entreprise qui s’étendent sur des heures ou des jours, cela crée des problèmes de fiabilité fondamentaux.

Pire encore, quand plusieurs agents doivent travailler ensemble, chacun a une vision partielle et différente de la situation. L’agent de recrutement savait que le candidat avait négocié un salaire plus élevé. L’agent d’intégration, non. L’agent de rémunération a traité le montant de l’offre standard. Trois agents, trois réalités différentes, un nouvel employé très en colère.

Ce que nous avons appris

Niveau 1Mémoire de sessionÉphémère

30 minutes

Portée

Conversation en cours seulement

Stockage

Cache Redis (TTL de 30 minutes)

But

Permettre des conversations naturelles à plusieurs tours

Niveau 2Mémoire de tâchePersistante

Un processus métier

Portée

Durée d’un processus métier

Stockage

PostgreSQL avec la clé workflow_id

But

Assurer la continuité lors des relais entre agents

Niveau 3Base de connaissances partagéePermanente

En tout temps

Portée

Tous les agents, en tout temps

Stockage

Base de données vectorielle + données structurées

But

Fournir une source de vérité cohérente

L’injection de contexte avant chaque action d’agent assure la cohérence.

Niveau 1 : mémoire de session (éphémère) – Conversation en cours seulement, cache Redis avec TTL de 30 minutes, permet des conversations naturelles à plusieurs tours

Niveau 2 : mémoire de tâche (persistante) – Durée d’un processus métier, PostgreSQL avec workflow_id comme clé, assure la continuité lors des passages de relais entre agents

Niveau 3 : base de connaissances partagée (permanente) – Tous les agents, en tout temps, base de données vectorielle + données structurées, fournit une source de vérité cohérente

Point crucial, nous avons ajouté l’injection de l’historique de conversation : avant qu’un agent traite une demande, l’orchestrateur lui fournit tout le contexte pertinent des interactions précédentes, et pas seulement la requête immédiate.

Leçon 4 : le déficit de vérification — quand personne ne vérifie le travail

Ce qui a mal tourné

Ce fut la panique. Notre enquête a mis au jour l’enchaînement suivant :

1. L’agent de gestion de la performance a recommandé des augmentations au mérite (correctement : 3-5 %)
2. L’agent de rémunération a traité les augmentations (à tort : il a interprété 3-5 % comme 300-500 %)
3. Les systèmes de paie ont exécuté (docilement : ils ont versé ce que l’agent avait indiqué)

Personne n’a détecté l’erreur. Chaque agent supposait que le précédent avait fait son travail correctement. Le système n’avait aucune couche de vérification, aucun contrôle de vraisemblance, aucune capacité à se demander « ce résultat a-t-il du sens ? ».

Ce n’était pas, et de loin, le seul échec de vérification. Nous avons aussi constaté ceci :

• L’agent d’intégration a créé des comptes utilisateurs aux permissions manifestement erronées
• L’agent de recrutement a envoyé des invitations à des entrevues à des candidats déjà refusés
• L’agent de gestion de la performance a calculé les notes de performance avec la mauvaise formule

Le problème de fond

Combler les lacunes de vérification est souvent la dernière chose dont les équipes s’occupent. On suppose que si chaque agent est « assez intelligent », le système fonctionnera. C’est une erreur dangereuse.

Le problème, c’est que les LLM sont des machines à certitude : ils produisent des résultats avec une grande assurance, même quand ces résultats sont absurdes. Dans un système multi-agents, l’erreur pleine d’assurance d’un agent devient l’entrée tout aussi assurée de l’agent suivant, ce qui crée des défaillances en cascade que personne ne remet en question.

Ce que nous avons appris

Part des erreurs interceptées à chaque niveau

Niveau 1Validation structurelle~40 %Validation de schéma · Typage · Détection des champs manquants. Peu coûteux et automatisé, intercepte les erreurs de format et de structure.

Niveau 2Validation des règles métier~35 %Contrôle des contraintes · Plages de valeurs · Vérification logique. Exemple : variations salariales de plus de 20 %, dates impossibles.

Niveau 3Cohérence entre agents~15 %L’orchestrateur maintient les invariants · Réconciliation des états. Garantit la cohérence des décisions liées entre agents.

Niveau 4Revue humaine~10 %Décisions à faible confiance · Cas limites · Échecs silencieux. Les agents évaluent leur confiance ; un score bas déclenche une revue.

Vérification obligatoire et bloquanteAucune suite tant qu’elle n’est pas validée.

Niveau 1 : validation structurelle – Chaque résultat d’agent est vérifié par rapport à un schéma. Les erreurs de type, les champs manquants et les données mal formées sont détectés immédiatement (intercepte ~40 % des erreurs)

Niveau 2 : validation des règles métier – Contrôles automatisés des violations de la logique métier. Exemples : variations salariales de plus de 20 %, création de comptes en double, dates impossibles (intercepte ~35 % des erreurs)

Niveau 3 : contrôles de cohérence entre agents – L’orchestrateur maintient des invariants entre les agents. Si l’agent de recrutement marque une personne comme « embauchée », l’agent d’intégration doit avoir une tâche correspondante (intercepte ~15 % des erreurs)

Niveau 4 : revue humaine selon la confiance – Les agents déclarent eux-mêmes leur score de confiance. Les décisions à faible confiance sont automatiquement soumises à une revue humaine (intercepte les cas limites et prévient les échecs silencieux, ~10 % des erreurs)

Point crucial, nous avons rendu la vérification obligatoire et bloquante : les agents ne peuvent pas passer à l’étape suivante tant que la vérification n’a pas réussi.

Leçon 5 : l’explosion de la complexité — quand plus d’agents aggravent les choses

Ce qui a mal tourné

Chaque nouvel agent augmentait de façon exponentielle la complexité du système :

• Plus d’agents = plus de points de coordination
• Plus de coordination = plus de modes de défaillance
• Plus de modes de défaillance = plus de temps de débogage
• Plus de débogage = un développement plus lent

Au septième agent, nous consacrions 80 % de notre temps à déboguer des problèmes de coordination et seulement 20 % aux fonctionnalités elles-mêmes. Pire, le système était devenu si complexe que même nous ne pouvions plus prévoir de façon fiable son comportement.

La goutte d’eau qui a fait déborder le vase a été une boucle infinie entre l’agent de conformité et l’agent de rémunération : l’agent de conformité signalait un calcul de paie comme potentiellement non conforme, l’agent de rémunération refaisait le calcul, l’agent de conformité signalait le nouveau calcul, et ainsi de suite, sans fin. Le système est resté bloqué pendant 47 minutes, jusqu’à l’expiration du délai.

Le problème de fond

C’est le problème de l’explosion combinatoire. Les coûts de coordination croissent de façon quadratique avec le nombre d’agents :

• Un système à quatre agents compte 6 chemins de coordination
• Un système à sept agents compte 21 chemins de coordination
• Un système à dix agents compte 45 chemins de coordination

La recherche confirme cette dure réalité : ajouter des agents réduit souvent la performance. Le surcoût de coordination l’emporte sur les avantages de la spécialisation.

Ce que nous avons appris

Décision 1 : fusionner des agents

• Intégration du contrôle de conformité à l’agent de rémunération (même domaine)
• Fusion de l’apprentissage et du développement avec la gestion de la performance (processus commun)
• Retour de sept à cinq agents

Décision 2 : limiter la communication directe entre agents

• Architecture en étoile (hub-and-spoke) plutôt qu’en maillage
• Toute la communication passe par l’orchestrateur
• Suppression des dépendances d’agent à agent

Décision 3 : règle de l’agent unique d’abord

• Avant d’ajouter un agent, nous nous demandons : « Un agent existant pourrait-il s’en charger avec de meilleurs prompts ? »
• Nous n’ajoutons un agent que lorsque les solutions à agent unique échouent clairement

Le résultat ? La fiabilité du système s’est améliorée de façon spectaculaire. Les temps de réponse ont diminué. Le débogage est devenu gérable. L’équipe pouvait enfin raisonner sur le comportement du système.

Vue d’ensemble : ce que nous aurions aimé savoir

Avec le recul, ces leçons ont un fil conducteur : les systèmes multi-agents échouent non pas à cause des limites de l’IA, mais à cause de décisions d’architecture et de conception.

Les défaillances que nous avons rencontrées concordent remarquablement avec la recherche du secteur :

• 32 % d’erreurs de spécification
• 28 % d’échecs de coordination
• 24 % de lacunes de vérification
• Sans compter une complexité en cascade à mesure que les systèmes grandissent

Ce que nous ferions autrement :

Où nous en sommes aujourd’hui

Six mois plus tard, le système RH tourne en production. Il n’est pas parfait et exige une surveillance et des ajustements continus. Mais il fonctionne de façon assez fiable pour que l’équipe RH lui confie de vrais processus.

Surtout, nous avons intégré ces leçons pour nos futurs projets multi-agents. Nous les abordons désormais avec la prudence qui s’impose : nous commençons simplement et n’ajoutons de la complexité que lorsque des avantages clairs la justifient.

Le succès exige non seulement des modèles d’IA puissants, mais aussi une conception réfléchie des systèmes, des tests rigoureux et l’humilité de simplifier quand la complexité devient ingérable.