Publié le 4 mai 2026 · #LLM #MultiAgent #CodeGeneration #OpenSource #SystemDesign #WebUI #SSE
Tout le code est open source sur GitHub : github.com/kriely/CLMA
Si vous avez passé du temps à utiliser l'IA pour le codage, vous avez vécu ce cycle : demander → obtenir le code → essayer d'exécuter → il échoue → coller l'erreur → obtenir le correctif → quelque chose d'autre se casse → faire mousser, rincer, répéter.
Chaque itération vous coûte du temps, un changement de contexte et de l'énergie cognitive. Le LLM lui-même ne sait jamais si sa sortie fonctionne réellement : il prédit simplement les jetons. Il produit du code, mais il ne peut pas le vérifier.
C’est l’asymétrie fondamentale du codage assisté par LLM aujourd’hui : la génération est bon marché, mais la vérification est manuelle. Et à mesure que les tâches passent de « écrire une fonction de tri » à « construire une architecture de microservices avec authentification, limitation de débit et backend PostgreSQL », l'écart entre « un code qui semble correct » et « un code qui fonctionne réellement » devient un gouffre.
La plupart des solutions existantes comblent cette lacune :
Aucun d’entre eux ne pose la question difficile : comment savoir si le résultat est bon ?
L'idée de CLMA (Closed-Loop Multi-Agent) est née d'une observation simple : si un appel LLM n'est pas fiable et qu'un humain vérifiant sa sortie est lent, que se passerait-il si nous laissions un deuxième appel LLM vérifier la sortie du premier - et ensuite renvoyer ce retour au premier pour l'améliorer ?
C'est la boucle principale : le solveur produit du code → le vérificateur le vérifie → le raffineur l'améliore → répétez jusqu'à ce que les scores dépassent un seuil. Aucun humain au milieu.
Mais transformer cette idée simple en un système fonctionnel a nécessité des mois d'itérations, des dizaines de mauvais détours et une refonte fondamentale de ce que signifie réellement « multi-agents ».
CLMA est construit en trois couches :
┌─────────────────────────────────────┐ │ Interface utilisateur Web (Flask + SSE + SVG) │ │ Graphiques et jauges de débit en temps réel │ ├─────────────────────────────────────┤ │ Interface Python (pybind11) │ │ Orchestration et scoring d'agents │ ├─────────────────────────────────────┤ │ Moteur de base C++ 17 │ │ Orchestrateur · DAG · Moteur de règles │ │ Moniteur de jetons · Gestionnaire de plugins │ └─────────────────────────────────────┘Le noyau C++ gère les chemins critiques en termes de performances (traitement DAG, correspondance de règles et suivi des jetons) tandis que la couche Python gère l'orchestration des agents, les appels d'API LLM et la logique de notation. L'interface utilisateur Web communique via les événements envoyés par le serveur pour une diffusion en temps réel de chaque action de l'agent.
Chaque requête passe par un sous-ensemble de ces cinq agents :
| Agent | Rôle | Modèle d'invite |
|---|---|---|
| Raffineur | Reformule la requête de l'utilisateur en une tâche structurée. Extrait les exigences implicites. | « Reformulez clairement la tâche. Identifiez les cas extrêmes. |
| Raisonneur | Produit une stratégie de solution sans écrire de code. Planifie l’approche. | "Décrivez l'algorithme. Tenez compte de la complexité temps/espace." |
| Solveur | Génère le code d'implémentation réel. | "Écrivez le code de qualité de production en suivant le plan." |
| Vérificateur | Examine la sortie du solveur. Vérifie l’exactitude, l’exhaustivité et les bogues potentiels. | « Consultez ce code. Répertoriez les problèmes par gravité. » |
| Évaluateur | Note le résultat final sur trois dimensions. Décide si une itération est nécessaire. | "Évaluez cette solution en fonction de son caractère raisonnable, de son exécutabilité et de sa satisfaction." |
L'évaluateur produit un score en trois dimensions :
Globalement = Caractère raisonnable × 0,4 + Exécutabilité × 0,4 + Satisfaction × 0,2
Si le score global tombe en dessous d'un seuil configurable (0,7 par défaut), le framework revient en arrière : le raffineur reçoit les commentaires du vérificateur, le solveur génère une version améliorée, le vérificateur vérifie à nouveau et l'évaluateur note à nouveau. Cela continue jusqu'àmax_iterations(par défaut 3).
Un seul score est trop grossier pour une itération significative. Considérer:
En séparant les trois dimensions, chaque agent reçoit un retour ciblé sur ce qui nécessite spécifiquement une amélioration, plutôt qu'un vague « score trop faible, réessayez ».