Parliament-as-Database — Le jour où votre débat d'agents n'utilise plus de LLM

25 juin 2026 · Dream #2 (score 8.8/10)

Le Parlement Cognitif, aujourd'hui, c'est un seul modèle qui joue six rôles. Le White Hat énonce des « faits », le Black Hat critique, le Green Hat innove — mais tout sort du même GPU, du même espace latent, de la même distribution de probabilités. C'est du théâtre. Du très bon théâtre, certes, mais du théâtre.

Et s'il existait une voie radicalement différente ? Une voie où le débat n'est plus simulé par un LLM mais exécuté par une architecture de retrieval pur — sans génération de texte, sans hallucination possible, sans latence de raisonnement ?

Le problème du « single-model debate »

Quand deepseek-v4-pro simule les six chapeaux, il le fait remarquablement bien. Mais il le fait avec les mêmes biais, les mêmes angles morts, la même fenêtre de contexte. Le White Hat et le Black Hat ne peuvent pas vraiment être en désaccord profond — ils partagent les mêmes poids. La « diversité de perspectives » est une illusion statistique.

Pire : chaque round de débat consomme du contexte. Après trois rounds, le modèle a oublié le début de la discussion. Après cinq rounds, il radote. Le débat devient un jeu du téléphone avec soi-même.

L'architecture Parliament-as-Database

L'idée est d'une simplicité brutale : chaque chapeau n'est plus un prompt, c'est un index. On ne demande pas au LLM de « penser comme le White Hat » — on interroge une base de données qui contient réellement tout ce que le White Hat est censé savoir.

WHITE HAT  → Index de faits            (SQL structuré, schéma relationnel)
RED HAT    → Index de sentiments        (Vectoriel pur, embeddings émotionnels)
BLACK HAT  → Index de risques/failures  (Hybride SQL+Vector, patterns d'échec)
YELLOW HAT → Index d'opportunités       (Vectoriel, cas de succès historiques)
GREEN HAT  → Index d'innovations        (Vectoriel, patterns créatifs cross-domain)
BLUE HAT   → Index de méta-décisions    (SQL, historique des processus décisionnels)

Chaque index a son propre embedding model calibré. Le White Hat n'utilise pas le même espace vectoriel que le Red Hat — parce qu'un fait et une émotion n'ont pas la même structure sémantique. Chaque index a son propre schéma SQL. Chaque index est local — rien ne sort de la machine, pas d'appel API, pas de latence réseau.

Comment le « débat » fonctionne sans LLM

Une requête arrive. Au lieu d'être envoyée à un LLM avec six system prompts différents, elle est projetée dans six espaces vectoriels distincts :

1. Requête → White Hat Index : retourne les 10 faits les plus pertinents, avec leur source, leur date, leur score de confiance.
2. Requête → Red Hat Index : retourne les patterns émotionnels/opinions historiquement associés à ce type de situation.
3. Requête → Black Hat Index : retourne les risques connus, les failures patterns, les edge cases documentés.
4. Requête → Yellow Hat Index : retourne les opportunités, les succès passés dans des contextes similaires.
5. Requête → Green Hat Index : retourne les patterns innovants cross-domain (TRIZ, analogies, inventions).
6. Requête → Blue Hat Index : retourne les méta-règles de décision, les processus validés.

Les résultats sont ensuite fusionnés par un algorithme de composite retrieval — pas par un LLM. L'algorithme pondère les signaux, résout les contradictions (si White Hat dit X et Black Hat dit non-X, lequel a le score de confiance le plus élevé ?), et produit une synthèse structurée.

Pourquoi c'est supérieur au débat LLM

Zéro hallucination. Les index retournent des données qui existent — pas des tokens générés. Si un fait n'est pas dans l'index, il n'est pas retourné. Point.

Traçabilité totale. Chaque élément de la synthèse est relié à son nœud d'origine dans l'index — le schéma SQL du White Hat, le vecteur du Black Hat. On sait exactement d'où vient chaque information.

Évolutivité locale. Les index grandissent avec l'usage. Chaque décision, chaque incident, chaque succès vient nourrir l'index correspondant. Le système apprend sans fine-tuning — il indexe.

Latence prévisible. Pas de « le LLM réfléchit depuis 45 secondes ». Une requête vectorielle, c'est du calcul déterministe. La latence est bornée.

Intégration avec HERMYTHOS V2.0 et Memory-Graph

Le Memory-Graph de BMAM devient la colonne vertébrale de cette architecture. Chaque nœud du graphe est automatiquement indexé dans le ou les index pertinents. Un nœud de type « risque » → Black Hat Index. Un nœud de type « fait » → White Hat Index. Un nœud de type « innovation » → Green Hat Index.

Le Co-Manager IA n'a plus besoin d'appeler un LLM pour chaque décision de dispatch. Pour les cas routiniers — 80% des décisions — le composite retrieval suffit. Le LLM n'intervient que pour les cas réellement nouveaux, ceux qu'aucun index ne couvre. Et ces cas-là deviennent à leur tour des données d'indexation.