Pari fiabilité — la cascade convergence¶
Statut : doctrine acquise (S19, 07/05/2026) Voir aussi : ADR-001 Cascade fiabilité, ADR-002 Consolidateur par agent, ADR-004 Friction délibérée
La phrase¶
« Tant qu'il faut vérifier une seule info, le doute reste — et le doute tue l'automatisation. »
Le constat¶
Aujourd'hui l'outil d'analyse Bricks est utilisé mais pas encore digne de confiance. Concrètement :
- les analystes re-analysent systématiquement les outputs au lieu de les consommer ;
- les AM revérifient à la main les données avant de qualifier un dossier ;
- une partie de l'équipe ouvre Manus ou une autre IA en parallèle pour se rassurer — ce qui veut dire qu'on rate une grosse partie du feedback (il sort de l'outil).
Tant que ce cycle persiste, l'outil ne remplace personne. Il ajoute juste une étape.
Le pari¶
La fiabilité par convergence multi-workflow. Pour chaque donnée critique (montant extrait d'un compromis, valeur vénale, surface, identité d'une partie prenante), on fait converger plusieurs approches structurellement différentes et on n'appelle l'humain qu'en dernier recours.
La cascade en 4 étapes¶
1. N approches en parallèle ────► même objectif, méthodes différentes
2. Convergence ────► ON FAIT CONFIANCE (sans humain)
3. Désaccord → LLM-as-a-judge ────► arbitrage tracé (peut exclure une source qui hallucine)
4. Doute persistant → HITL ciblé ────► uniquement sur le champ litigieux, pas sur tout le dossier
Détail par étape¶
1. N approches en parallèle. Pas N clones d’un même prompt. Pas N appels au même LLM avec une variation de température. Vraiment N approches structurellement indépendantes : boucle LLM, extraction structurée, OCR/parsing, scraping web, déclaratif PDP et validation AM. Chacune peut se tromper pour des raisons différentes des autres.
2. Convergence. Si toutes les approches s'accordent sur la même valeur, on prend la valeur. Sans intervention humaine. Le clic AM « valider » n'a aucune valeur ajoutée si les approches indépendantes et le déclaratif PDP convergent tous vers « 140 m² ».
3. Désaccord → LLM-as-a-judge. Quand les approches divergent, un LLM avec le contexte projet arbitre. Critères explicites et traçables. Cas concret : Manus invente une donnée puis confirme l'avoir inventée si on le challenge → le judge l'exclut, garde la convergence des autres.
4. HITL ciblé. Uniquement quand le judge n'arrive pas à trancher. Et uniquement sur le seul champ litigieux, pas sur tous les champs du dossier. Qui intervient :
| Niveau de doute | Acteur | Cas type |
|---|---|---|
| Conflit non résoluble par LLM, contexte projet | AM | 3 sources contradictoires sur surface, à examiner |
| Conflit demandant expertise métier | Analyste | Division parcellaire qui rend la surface déclarée incohérente |
| Décision finale (pas dans la cascade) | Cédric | Comité d'investissement |
Application à 2 niveaux¶
Niveau 1 — par donnée (V1 actuelle)¶
C'est la fiche consolidée actuelle. 4 sources (override AM, déclaratif Bubble, messagerie CRM, data extraction) → précédence → conflit ou convergence → output unique.
Niveau 2 — par agent (vision cible)¶
Chaque agent (estimate_value, réputation, etc.) embarque sa propre cascade en interne :
- sub-nodes lecture sources → reconciliation source par source → output consolidé
- comparateur global LLM-as-a-judge entre workflows alternatifs (V3, V4, Manus, freelance approach…)
À terme, il y aura plusieurs façons de calculer la valeur vénale, et le judge tranchera entre elles avec critères explicites + capitalisation passive de la convergence pour le dataset d'éval.
Pourquoi pas une seule approche "parfaite"¶
Parce qu'elle n'existe pas. Et qu'on a déjà essayé.
Trois approches indépendantes qui convergent valent mieux qu'une seule approche "parfaite" qui n'existe pas.
C'est exactement la même règle qui distingue un capteur LIDAR (haute résolution mais point unique de défaillance) d'un système de fusion caméras + radar + lidar (chacun moins parfait individuellement, mais structurellement complémentaire).
Conséquences opérationnelles¶
-
Squad dédiée à l’extraction documentaire — chaque contribution doit apporter une approche structurellement différente. Le critère de sélection : « est-ce que cette approche peut se tromper pour une raison différente des autres ? » Si non, on n'a pas besoin du freelance.
-
Friction délibérée avant analyse — voir ADR-004. Notre pipeline interne refuse de tourner un agent si ses champs critiques manquent (anti-pattern Manus qui hallucine).
-
Capture passive de la convergence — chaque fois que N sources convergent, c'est une ground truth gratuite pour le golden dataset. À condition que le data model l'enregistre (
chosen_sources= array, pas singleton — voir ADR-005). -
Pas de validation manuelle systématique — wording du bandeau AM : "X champs critiques manquants" + verbe "fiabiliser" (pas "valider"). Auto-validation quand sources convergent. L'AM intervient uniquement quand le système ne peut pas trancher.
Ce qui n'est PAS dans le pari¶
- Ce n'est pas du "consensus à N LLMs" — N LLMs lisant les mêmes docs via la même pipeline = consensus corrélé, pas convergence indépendante.
- Ce n'est pas une fuite de la responsabilité humaine — l'humain reste dans la boucle, mais sur les arbitrages où il a vraiment de la valeur ajoutée.
- Ce n'est pas un dogme universel — pour les règles déterministes (calcul d'un ratio, frais de notaire), un seul code suffit. La cascade s'applique aux jugements, pas aux calculs.
Trace historique¶
- Origine : posture Romain de longue date, formalisée explicitement en synchro S19 mid-week (07/05/2026) → CR détaillé §2.
- Alignement Nicolas explicite : « Faire ce taf de réconciliation où on attire l'attention de l'AM uniquement quand on a déjà fait bosser en amont un LLM-as-a-judge. »
- Référence conceptuelle :
assets/Memo - Parallele LIDAR et architecture Bricks OS.md(risque #3 "consensus corrélé").
Sources¶
- Source migrée :
bricks-os/wiki/doctrine/pari-fiabilite.md - Catalogue des sources legacy