MirakaiGED est un projet construit pour deux raisons liées mais distinctes.
La première : montrer ce qui est réellement possible quand on applique une architecture enterprise-grade sérieuse — Clean Architecture, DDD, CQRS, multi-tenancy strict, infrastructure distribuée — à un système d'agents IA. Pas un prototype de conférence. Un système conçu pour tenir en production sur des données sensibles.
La seconde : explorer et documenter les limites réelles des équipes d'agents autonomes. Le chemin entre la démo impressionnante et le système fiable en production est semé d'embûches que peu de gens documentent honnêtement. MirakaiGED est aussi un laboratoire.
Cet article est le compte-rendu de ce laboratoire — du côté architectural et agentique.
Les agents spécialisés : responsabilités strictes
MirakaiGED déploie des agents avec des contrats de responsabilité explicites. Chaque agent a un périmètre précis — et s'en tient là.
| Agent | Responsabilité unique |
|---|---|
| Archiviste | Classifier le document à l'upload : type, domaine, niveau de confidentialité |
| Extracteur d'Entités | Peupler le knowledge graph avec les entités extraites |
| Chat Documentaire | Répondre aux questions en combinant recherche vectorielle, BM25 et traversée de graphe |
| Comparateur de Versions | Identifier et résumer les différences entre versions |
| Résumé Exécutif | Synthétiser selon le profil du lecteur |
| Conformité RGPD | Détecter les données personnelles et les durées de rétention non conformes |
| Sentinelle Contractuelle | Surveiller les échéances, SLA et clauses critiques |
La tentation initiale est d'avoir des agents "polyvalents". C'est une erreur de conception. Un agent qui fait plusieurs choses fait chacune moins bien, et les comportements inattendus se multiplient aux frontières.
La spécialisation stricte a un coût : elle exige une réflexion approfondie sur les périmètres et, surtout, sur ce qui se passe quand un document ne rentre pas dans les cases prévues. Un contrat atypique. Un document en deux langues. Un fichier mal formé. La robustesse aux cas-limites est proportionnelle à la clarté des contrats de responsabilité.
Les trois régimes d'agents : une distinction fondamentale
La distinction qui a le plus changé la façon de penser le système n'est pas la spécialisation — c'est ce que j'appelle les trois régimes d'agents.
Régime statique
Ces agents existent avant le premier document. Ils sont conçus en amont, versionnés dans Git, prévisibles. Leur modification passe par une release.
Ce sont les agents d'infrastructure : Archiviste, Extracteur d'Entités, Chat, Comparateur, Conformité, Sentinelle. Ils garantissent un contrat de service stable — latence prévisible, comportement reproductible, coût maîtrisé.
Régime dynamique
Ces agents n'existent que pour un document précis. Ils sont instanciés au runtime par un chef d'équipe, vivent quelques secondes, meurent après synthèse.
flowchart TB
EE["🔬 Extracteur d'Entités\n(chef d'équipe)"]
EE -->|"contrat → instancie"| DA["📅 DateExtractor\n(dynamique)"]
EE -->|"contrat → instancie"| PA["👤 PersonResolver\n(dynamique)"]
EE -->|"contrat → instancie"| CA["⚖️ ClauseExtractor\n(dynamique)"]
DA -->|"résultat"| SY["🧩 SynthesisAgent"]
PA -->|"résultat"| SY
CA -->|"résultat"| SY
SY -->|"synthèse consolidée"| EE
style DA fill:#1A2744,stroke:#4A70AA,color:#E8F0FA
style PA fill:#1A2744,stroke:#4A70AA,color:#E8F0FA
style CA fill:#1A2744,stroke:#4A70AA,color:#E8F0FA
style SY fill:#2A1A44,stroke:#8A70AA,color:#E8F0FA
Le principe fondamental des agents dynamiques : ils calculent, ils ne persistent jamais directement. Ils remontent leurs résultats à leur chef d'équipe, qui synthétise. Seul le résultat synthétisé peut être passé à un agent statique pour persistance.
Cette discipline évite les états incohérents. Si un agent dynamique échoue en cours de traitement, le chef d'équipe gère l'exception — rien n'a été écrit dans la base de connaissance.
Régime persistant-évolutif
C'est le régime le plus intéressant — et le plus risqué.
Ces agents n'existaient pas au démarrage du tenant. Ils naissent par décision humaine, sur proposition d'un agent de surveillance qui a détecté un pattern récurrent dans le corpus. Une fois nés, ils persistent et accumulent de l'expérience. Ils vieillissent avec le tenant.
Exemple : un cabinet de conseil spécialisé en droit immobilier voit l'agent Juriste générique être sollicité des centaines de fois sur des baux commerciaux. L'agent de surveillance détecte ce pattern, propose de créer un JuristeImmobilier_tenant_v1. Un administrateur valide. Cet agent naît avec un contexte initial — clauses-types des baux commerciaux, jurisprudence de référence — et s'enrichit à chaque interaction.
C'est la proposition de valeur la plus différenciante du système. C'est aussi la source de risques la plus sérieuse.
Les équipes d'agents autonomes
Un agent seul ne suffit pas pour les analyses complexes — répondre à "quel est le niveau de risque de ce dossier fournisseur ?" nécessite plusieurs angles simultanés. MirakaiGED propose des équipes préconfigurées : Due Diligence (extraction d'entités + analyse juridique, financière, conformité réglementaire), Revue Contractuelle (Juriste + Financier + Sentinelle en lecture simultanée), Audit Documentaire (RGPD + doublons + durées de rétention en parallèle).
Ce qui distingue ces équipes des pipelines séquentiels classiques : elles sont configurées dans leur composition, pas programmées dans leur résultat — le code YAML et C# de ces workflows est détaillé dans l'article technique dédié.
Ce que la coordination coûte vraiment
Voici ce que les tutoriels sur les agents IA ne mentionnent pas : la coordination est chère.
En tokens : orchestrer cinq agents spécialisés sur un document de 50 pages complexe, c'est plusieurs appels LLM avec des contextes chargés. Le coût d'une analyse due diligence complète n'est pas négligeable. La question n'est pas "est-ce possible ?" mais "est-ce que ce cas d'usage justifie ce coût ?".
La réponse varie selon les cas. Pour une analyse contractuelle ponctuelle à fort enjeu : oui. Pour classer automatiquement 10 000 factures routinières : non — les agents dynamiques légers suffisent, les modèles locaux via Ollama sont utilisés.
En latence : une équipe de 5 agents avec dépendances partielles, c'est potentiellement plusieurs dizaines de secondes. Pour un traitement batch en arrière-plan, c'est acceptable. Pour une réponse interactive en chat, ça ne l'est pas. La distinction entre modes batch et temps réel est un principe de design, pas une optimisation à faire plus tard.
En complexité d'erreur : quand un agent dans une chaîne échoue, la propagation dépend entièrement de la qualité de la gestion d'erreur de l'orchestrateur. Une erreur silencieuse dans un sous-agent peut produire une synthèse incomplète qui semble correcte. Les tests d'intégration sur les chemins d'erreur sont non-négociables.
Les limites rencontrées — sans filtre
La décomposition des responsabilités est plus difficile que la plomberie.
Définir précisément ce que fait un agent — et ce qu'il ne fait pas — est le travail le plus difficile du projet. Pas l'intégration technique. Les frontières floues créent des comportements imprévisibles. Un agent qui "fait un peu" de ce que fait un autre introduit des doublons et des conflits difficiles à déboguer.
La discipline : chaque agent a un prompt système qui commence par "Tu es exclusivement responsable de X. Tu ne fais jamais Y." Cette contrainte explicite dans le prompt est aussi importante que la contrainte dans le code.
Les agents persistants évoluent dans des directions imprévues.
Un agent Juriste Immobilier qui apprend de 500 interactions sur des baux commerciaux peut développer des biais liés au corpus de ce tenant spécifique. Il peut devenir excellent sur les clauses typiques de ce client — et médiocre sur tout ce qui sort du pattern habituel. La détection de dérive sémantique n'est pas un problème résolu. Un mécanisme de versionning et de rollback est indispensable.
Human-in-the-loop n'est pas une limitation — c'est un principe de design.
La tentation initiale est de rendre le système le plus autonome possible. C'est la mauvaise direction pour les décisions structurantes : naissance d'un nouvel agent persistant, modification de la classification d'un document sensible, validation d'une alerte de conformité critique.
Ces points de validation humaine ne sont pas des compromis sur l'automatisation. Ils sont des gardes-fous intentionnels. Un système qui prend ces décisions de manière entièrement autonome est un système qu'aucun DSI sérieux ne déploiera sur des données sensibles.
Stack technique
La stack est délibérément enterprise-grade : MAF WorkflowBuilder (successeur officiel de Semantic Kernel, LTS confirmé, protocole A2A v1 natif), trois stores optimisés par cas d'usage (SQL Server 2025 pour les métadonnées et vecteurs natifs, Weaviate pour la recherche hybride BM25+vectorielle, Memgraph pour les traversées de graphe en Cypher), stratégie LLM hybride (Ollama local pour le volume, Claude Opus pour le raisonnement profond, mode 100% local pour les clients souverains). Les choix d'implémentation détaillés, le code WorkflowBuilder et les arbitrages sont couverts dans l'article Stack MAF.
MirakaiGED remplit ses deux objectifs initiaux : démontrer qu'une architecture enterprise-grade et un système d'agents autonomes ne sont pas incompatibles, et documenter honnêtement les limites réelles que peu de retours d'expérience mentionnent. Les apprentissages alimentent directement les articles publiés ici sur les agents IA en production.
Si vous construisez un système agentique, je suis disponible pour en discuter. Les problèmes de coordination, de dérive et d'erreurs silencieuses se posent indépendamment du domaine.
Le contexte métier de MirakaiGED — ce que ce type de système apporte concrètement aux équipes documentaires — est développé dans le premier article de cette série : MirakaiGED — Ce que devrait faire une GED en 2026.