Mémo — Le parallèle LIDAR et l'architecture de Bricks OS¶

Date : 17 avril 2026 Auteur : Romain BAZIL (réflexion assistée) Statut : Document de réflexion stratégique — à confronter avec Nicolas / Cédric Lecteur cible : squad Analyse et décideurs métier

1. Déclencheur — le tweet sur Tesla et le LIDAR¶

Un tweet d'un ingénieur (Argil) défend la décision d'Elon Musk de virer le LIDAR des Tesla au profit d'une approche full vision end-to-end. Les arguments, traduits en principes d'ingénierie :

Bitter Lesson (Rich Sutton) : scaler le compute sur une méthode d'apprentissage générale bat systématiquement les architectures bricolées à la main.
End-to-end > pipelines modulaires : chaque capteur supplémentaire ajoute une modalité à fusionner, une source de désaccord à arbitrer, une dette technique permanente. "Sensor fusion artisanale".
Perception ≠ cognition : le LIDAR voit la géométrie, pas la sémantique. Les derniers 9 de fiabilité sont des problèmes de compréhension, pas de mesure. Ajouter un capteur ne résout rien.
Élégance = signal / complexité : le LIDAR explose le dénominateur. Défendre le LIDAR en 2026 = défendre les systèmes experts en 2012.
Analogie économique : LIDAR = planification centralisée soviétique (spécifier tout en amont). Vision end-to-end = ordre émergent hayékien (faire confiance à un système qui apprend).

Conclusion du tweet : never bet against end-to-end, never bet against la simplicité.

2. Pourquoi ce parallèle mérite d'être creusé pour Bricks OS¶

Le projet Bricks OS présente structurellement les mêmes caractéristiques qu'une archi LIDAR :

Un pipeline multi-agents (~12 agents V1 + V2) où chaque agent est une "modalité" à fusionner
Des règles métier hard-codées (marge < 10% = refus, LTV ≥ 80% = refus, etc.)
Des pipelines d'extraction séparés (OCR, RAG) qui pré-digèrent l'information avant LLM
Un monitoring à 3 étages (Sentinelle / Investigation / Fix) qui compense la fragilité de l'ensemble
Un signal utilisateur critique : certains décideurs préfèrent un outil one-shot lorsqu’il rend mieux visibles ses sources et son raisonnement

Le risque : reproduire, sans s'en rendre compte, l'architecture perdante (LIDAR) en pensant faire de la rigueur d'ingénieur.

Objectif du mémo : identifier les endroits où Bricks OS pourrait être en train de construire du LIDAR, arbitrer lucidement chaque cas, et fixer des marqueurs de dérive à surveiller.

3. Les 4 risques "LIDAR" identifiés dans Bricks OS¶

Risque #1 — Les agents comme capteurs à fusionner¶

Le risque¶

Chaque nouvel agent ajoute : - Une modalité à fusionner dans le mémo final - Une source de désaccord à arbitrer (agent A dit marge 12%, agent B déduit 14%) - Une dette de cohérence cross-agents (explicite dans le projet Q2 "Golden dataset & mesure qualité agents")

Au-delà d'un certain nombre d'agents, la complexité de fusion croît plus vite que la capacité du système. C'est la "sensor fusion artisanale = dette technique permanente" du tweet.

Position retenue (Romain)¶

Le découpage agent-par-agent est un choix conscient d'industrialisation, pas un réflexe :

Confiance yeux fermés requise : automatiser l'analyse nécessite que chaque étape soit fiable à 100%. Manus one-shot peut être "trop léger" sur une étape (passer à côté d'un détail juridique, mal interpréter un bilan). La spécialisation permet de garantir la qualité étape par étape.
Robustesse aux régressions modèle : les modèles évoluent semaine après semaine, parfois en régression. Un pipeline end-to-end dépendant d'un seul modèle subit ces régressions. Un découpage avec étapes procédurales/mathématiques (calcul frais de notaire, ratios financiers) isole ces régressions aux étapes LLM pures.
Contrainte de temps au marché : Tesla a pu attendre que le compute et les données rendent la vision viable. Bricks doit livrer de la valeur aujourd'hui. On ne peut pas parier sur un end-to-end parfait dans 3 ans.
Auditabilité réglementaire et métier : un comité d'investissement doit pouvoir justifier un refus. Le découpage produit un audit trail par section, exploitable par Cédric et par l'analyste.

Nuance importante à ne pas perdre¶

Il y a deux types de découpage qu'il faut bien distinguer :

Type	Exemple	Verdict
Découpage pour traçabilité	Mémo final à 8 sections avec sources, produit par un seul agent contextuel	Bon — lisibilité sans perte
Découpage pour exécution	8 agents LLM indépendants en silos + fusion a posteriori	Risqué — c'est là que la dette s'accumule
Découpage procédural légitime	Calcul frais de notaire via formule (agent BRI-313), ratios financiers	Très bon — remplace du LLM par du déterministe
Découpage LLM déguisé	Un "agent réputation" qui lit du web avec un prompt spécialisé	Faux découpage — ce n'est pas plus mathématique que Manus

Test à appliquer avant chaque nouvel agent : cette étape est-elle vraiment procédurale/déterministe, ou est-ce qu'on fait juste du LLM avec un prompt plus précis ? Si c'est le second cas, ce n'est pas un découpage, c'est une illusion de découpage.

Marqueurs de dérive¶

Le pipeline multi-agents ne bat plus Manus one-shot sur le golden dataset
Le nombre d'agents croît plus vite que la qualité mesurée du mémo final
Les incohérences cross-agents deviennent un projet à part entière (signe que la dette de fusion domine)

Test stratégique à instaurer¶

Tous les trimestres, à compétence de modèle égale, mesurer sur le golden dataset : - Pipeline multi-agents vs. Manus one-shot - Si le pipeline bat Manus → découpage justifié - Si Manus bat le pipeline → l'architecture est le problème

Questions en suspens¶

Quel est le volume d'étapes purement procédurales (mathématiques/déterministes) qu'on peut extraire du LLM ? C'est le vrai gisement de robustesse.
Jusqu'où pousser la décomposition avant que la fusion coûte plus que l'isolation ne rapporte ?
Quelle baseline Manus on utilise pour le benchmark trimestriel (Manus standard ? Manus avec outils ? Claude/Gemini one-shot ?)

Risque #2 — Les règles métier comme LIDAR (développé)¶

C'est le cœur de la réflexion. Trois niveaux de règles existent, ils ont l'air proches mais n'ont rien à voir. Il faut les distinguer consciemment pour ne pas construire un système expert sans s'en rendre compte.

Niveau A — Règles-contrat (à garder, voire à afficher publiquement)¶

Ce que c'est : règles simples, publiques, qui expriment une politique.

Exemples actuels : - Marge < 10% = refus - LTV ≥ 80% = refus - Dossier sans acte de propriété = rejet - Exception : LTV < 50% peut bypasser apport < 10%

Fonction réelle : - Communiquer aux porteurs ce qui est acceptable (peut être exposé sur le site) - Donner un cadre à l'analyste - Couvrir la responsabilité réglementaire et comité

Caractéristiques : - Stables dans le temps (mois, trimestres, années) - Peu nombreuses (10 max) - Compréhensibles en 30 secondes par un non-expert - Binaires ou simples (pas d'imbrication de sous-conditions)

Verdict : ces règles sont l'équivalent du code de la route. Personne ne conduit en appliquant le code, mais il cadre les sorties acceptables.

Niveau B — Règles-jugement (le piège central)¶

Ce que c'est : règles qui prétendent encoder le raisonnement expert du comité.

Exemples imaginés (à éviter) : - "Si zone tendue + apport > 15% + promoteur avec 3+ projets alors bonus X, sauf en région PACA où appliquer Y..." - "Si bilan N-1 déficitaire mais tendance à la hausse sur 3 ans + secteur résilient, appliquer coefficient Z..."

Pourquoi c'est un piège : - Elles s'empilent sans fin : chaque feedback analyste donne envie d'ajouter une règle - Elles donnent l'illusion d'un système qui comprend - Elles deviennent incohérentes entre elles à mesure qu'elles croissent - Elles figent un raisonnement qui devrait être adaptatif au marché

Diagnostic : c'est exactement le système expert de 2012 qui a été balayé par le deep learning. Ce niveau de règles est la contrepartie directe du LIDAR dans notre domaine.

Niveau C — Jugement appris (l'objectif cible)¶

Ce que c'est : un système qui apprend la distribution historique des décisions sur les dossiers validés ou refusés, au lieu de se limiter aux règles déclarées.

Insight critique : les décisions complexes combinent règles explicites, précédents et jugement contextuel. Les règles seules ne reproduisent donc pas toute la décision.

Conséquence : si on code ses règles déclarées, on reproduit sa communication, pas sa décision. C'est la différence entre un pilote qui récite le code de la route et un pilote qui conduit.

Ce que ça suppose : - Un golden dataset conséquent (le projet Q2 "Golden dataset & mesure qualité agents" va dans ce sens) - Une boucle validate/modify/reject industrialisée (décision S17) - Un modèle qui apprend la distribution, pas un moteur de règles

Le bon pattern¶

Niveau	Stratégie
A — Règles-contrat	Minimum syndical, explicite, stable. Garde-fou public.
B — Règles-jugement	Résister activement à la tentation. Réponse par défaut : non.
C — Jugement appris	Tout l'investissement passe ici. Dataset, feedback loop, modèle.

Règle pratique : lorsqu’un expert propose d’ajouter une règle pour couvrir une exception, la réponse par défaut est non. On ajoute 20 exemples annotés au golden dataset à la place. Si après ajout des exemples le système continue de se tromper, alors (et seulement alors) on discute d'une règle A.

Marqueurs de dérive vers le niveau B (à surveiller activement)¶

Symptôme	Diagnostic
Le nombre de règles augmente trimestre après trimestre	Glissement A → B
Des règles avec des sous-conditions (if/else/sauf si)	Déjà en B
Les exceptions aux règles se multiplient	Le niveau B ne capture pas assez le contexte
Les analystes débattent des exceptions aux règles plutôt que des dossiers	Les règles prennent la place du jugement
Besoin d'un moteur de règles avec ordre de priorité	Système expert reconstitué
Le produit devient illisible pour un nouvel analyste	Complexité interne vs. valeur externe

Marqueurs de bon pattern¶

Les règles A restent stables trimestre après trimestre
Le système sort une confiance calibrée par dossier (pas 100% systématique)
Les validate/modify/reject nourrissent un dataset, pas un catalogue de règles
La performance sur le golden dataset progresse sans ajouter de règles (elle progresse parce que le dataset grossit)

Test concret à appliquer à chaque demande de règle¶

"Est-ce que je pourrais résoudre ce problème en ajoutant 20 exemples annotés au golden dataset à la place ?"

Si oui → on fait ça. Pas de règle.
Si non → c'est probablement une vraie règle de niveau A. Ajouter, documenter, stabiliser.

Questions en suspens¶

Quelle volumétrie minimum de golden dataset pour que le niveau C soit viable ? (100 dossiers ? 500 ? 1000 ?)
Qui valide le golden dataset — un référent métier unique ou un consensus d’analystes ?
Comment exposer au porteur les règles A sans révéler le niveau C (propriété intellectuelle du jugement appris) ?
Comment gérer la transition entre un système qui tourne sur règles aujourd'hui et un système qui tournera sur jugement appris demain ? Modes parallèles ? A/B ?

Risque #3 — Le consensus inter-agents comme illusion de fiabilité¶

Le risque¶

Intuition actuelle : "si tous les agents sont d'accord, confiance haute, pas besoin de contrôler ; si désaccord, human in the loop."

Cette logique est séduisante mais piégeuse : elle suppose que les agents sont des sources indépendantes. Si ce n'est pas le cas, le consensus ne fiabilise rien.

Les trois cas de figure¶

Cas 1 — Sources structurellement indépendantes (le cas qui marche) - DVF (base notaires) + PriceHubble (modèle hédonique) + Firecrawl (annonces marchandes) - Modes d'erreur différents par construction - Accord → confiance réellement augmentée - C'est ce modèle qu'il faut généraliser

Cas 2 — Sources corrélées (le piège) - 3 agents LLM qui lisent le même PDF via la même pipeline OCR - Mêmes biais, mêmes hallucinations - Accord → confiance simulée, pas réelle - Les LLM hallucinent souvent avec assurance et de façon corrélée

Cas 3 — Le pire : l'erreur silencieuse consensuelle - Tous les agents sortent la même valeur fausse avec confiance haute - Le garde-fou "désaccord → human" ne se déclenche jamais - L'analyste ne voit jamais le dossier - La décision passe

Position retenue (Romain)¶

L'approche visée est bien l'opposé de Manus : là où Manus se "débrouille" (une seule source de réponse, opaque), le workflow guidé prend des éléments très spécifiques et les croise. Et on peut imaginer d'autres approches encore à chaque fois (triangulations différentes).

Cette logique est bonne — à condition d'être appliquée avec les bonnes sources.

Principe directeur¶

Le gain réel de fiabilité vient de croiser des sources structurellement différentes :

Type de source	Exemple	Indépendance
Structured data	DVF, SIRENE, cadastre, Banque de France	Élevée
LLM sur doc	Lecture d'un bilan PDF	Faible (corrélée avec d'autres LLM)
Web scraping	Firecrawl sur annonces	Moyenne
Humain	Analyste métier	Très élevée

Règle : ne pas multiplier les LLMs sur les mêmes documents. Préférer la diversité de nature à la diversité de prompt.

Pratiques recommandées¶

Calibration des confiances : chaque agent doit produire une confiance honnête. Un agent qui dit toujours "95% sûr" ne contribue à aucune fusion utile. Calibration = la confiance doit matcher le taux de succès réel sur golden dataset.
Agent adversarial / challenger : un agent dont le job est de jouer l'opposé (essayer de refuser le dossier alors que les autres valident), plutôt qu'un N+1ème agent qui fait la même chose.
Détection d'erreurs silencieuses : mesurer le taux d'erreur conditionnel au consensus. Si sur le golden dataset, quand N agents sont d'accord on a encore X% d'erreurs, le consensus ne sauve pas. Ce taux doit décroître quand le consensus augmente.
Croisement structurel : viser 1 source structured data + 1 LLM + 1 humain sur les décisions critiques. Pas 3 LLMs.

Questions en suspens¶

Comment calibrer les confiances des agents actuels ? (Aujourd'hui aucun n'expose une confiance honnête.)
Quel agent adversarial déployer en premier, et sur quel périmètre ?
Sur le golden dataset, quel est aujourd'hui le taux d'erreur conditionnel au consensus ? (Baseline à mesurer pour juger des progrès.)

Risque #4 — Le monitoring à 3 étages comme béquille¶

Le risque¶

Une première boucle Sentinelle → Investigation → Fix et un dashboard de santé des agents ont été livrés en S17.

Mais : c'est aussi l'aveu que les agents cassent assez souvent pour mériter 3 bots dédiés. Le LIDAR c'est exactement ça : un système qui a besoin d'outillage de plus en plus sophistiqué pour compenser sa fragilité de base.

Position retenue¶

On ne fait pas "sans monitoring" — mais on cible différent selon la couche :

Couche	Nature	Direction stratégique
Sentinelle	Monitoring d'infra (agent planté, API down)	Garder — toujours utile, faible coût
Investigation	Monitoring de dérive qualité	Devrait diminuer à mesure que le golden dataset détecte automatiquement les régressions
Fix	Boucle de correction manuelle	À automatiser — c'est le projet "Workflow produit augmenté" S16 (agent PM Slack + healing loop)

Principe directeur¶

Un système end-to-end simple a besoin de moins de monitoring, pas de plus.

Si le monitoring grossit avec le système, signal d'alarme : on compense la fragilité structurelle par de l'outillage, au lieu de résoudre le problème racine.

Test stratégique¶

Dans 6 mois, à volume de dossiers constant : - Plus d'alertes Sentinelle/Investigation ? → on empile - Moins d'alertes ? → on simplifie réellement

Questions en suspens¶

Quelle baseline d'alertes aujourd'hui ? (Pour juger dans 6 mois.)
Quelle part du monitoring "Investigation" pourrait être remplacée par des tests golden dataset automatiques ?
Le healing loop (feedback UI → issue Linear auto) a-t-il des kill criteria clairs ? (Décision S16 : proto 2 semaines.)

4. Les limites du parallèle — ce qu'il ne faut PAS importer naïvement¶

L'analogie Tesla / LIDAR est puissante mais elle a des limites structurelles pour le contexte Bricks :

4.1 — Pas l'échelle de data de Tesla¶

L'argument "scaler une modalité" suppose qu'on puisse scaler. Tesla : des millions de miles par jour. Bricks : 457 projets en mars 2026.

Conséquence : pré-encoder un peu de structure reste rationnel tant que la boucle de feedback n'est pas industrielle. On ne peut pas attendre d'avoir des millions de dossiers pour commencer à produire des mémos fiables.

4.2 — Contrainte d'auditabilité que Tesla n'a pas¶

Un comité d’investissement doit pouvoir justifier un refus. « Le modèle a dit non » n’est acceptable ni pour le porteur ni pour le régulateur.

Conséquence : les règles explicites ont une valeur de communication et d'auditabilité, pas seulement de décision. C'est la justification du niveau A des règles.

4.3 — Instabilité des modèles LLM semaine à semaine¶

Tesla contrôle son modèle (entraîné en interne, versionné, stable). On dépend de modèles tiers (OpenAI, Anthropic, Google) qui peuvent régresser sans prévenir.

Conséquence : ne pas mettre tous les œufs dans un pipeline end-to-end dépendant d'un seul modèle. Isoler des étapes déterministes (calculs, extractions structurées) réduit la surface de régression.

4.4 — Les "derniers 9" ne sont pas techniques, ils sont humains¶

Tesla : les derniers 9 sont un problème de cognition du système. Bricks : les derniers cas signalent un problème d’explicabilité et de contrôle perçu par les décideurs métier.

Conséquence : le mémo comité de 10 pages avec sources, l'interaction validate/modify/reject avec justification, c'est exactement ça. Ce n'est pas du LIDAR, c'est de l'interface humaine nécessaire.

4.5 — Pression du time-to-market¶

Tesla a eu 10 ans pour attendre que la vision soit prête. Bricks doit livrer de la valeur cette année.

Conséquence : ne pas attendre un end-to-end parfait hypothétique. Construire aujourd'hui avec les agents spécialisés, mais avec les bons marqueurs de dérive pour ne pas se retrouver coincé dans une archi obsolète dans 18 mois.

5. Principes directeurs retenus¶

Synthèse des arbitrages, à appliquer à chaque décision archi / produit Q2 :

Le découpage est OK, mais c'est un choix conscient, pas un réflexe. Mesurer trimestriellement pipeline vs. Manus one-shot. Si on perd, simplifier.
Privilégier le découpage procédural/déterministe (calculs, extractions structurées) au découpage LLM-spécialisé (prompts plus précis). Le premier est un vrai gain de robustesse ; le second est une illusion.
Résister activement aux règles de niveau B. Réponse par défaut à toute demande de règle : "et si on ajoutait 20 exemples au golden dataset à la place ?". Règles A minimum syndical, stables, publiques. Investissement massif sur niveau C (jugement appris).
Croiser des sources structurellement indépendantes, pas des LLMs en parallèle. Calibrer les confiances. Déployer un agent adversarial plutôt qu'un énième agent consensuel. Mesurer le taux d'erreur conditionnel au consensus.
Le monitoring est un thermomètre, pas une solution. Sa croissance est un signal d'alarme. Investir pour le réduire, pas pour le supporter.
Boucle d'apprentissage > spécification amont (le méta-principe). Golden dataset, feedback validate/modify/reject, healing loop. Pas nouvelles règles, pas nouveaux agents, pas nouveaux capteurs par défaut.

6. Questions clés à se poser avant chaque décision Q2¶

#	Question	Si réponse problématique
1	Cette spécialisation d'agent bat-elle Manus one-shot sur le golden dataset ?	Simplifier
2	Cette étape est-elle vraiment procédurale/déterministe, ou du LLM déguisé ?	Ne pas découper
3	Cette nouvelle règle est-elle de niveau A (contrat public) ou B (jugement) ?	Ajouter au dataset à la place
4	Cette nouvelle source est-elle indépendante des sources existantes ?	Ne pas l'ajouter
5	Cette amélioration agit sur la boucle d'apprentissage ou sur la spécification amont ?	Préférer la boucle
6	Ce monitoring est-il une béquille temporaire ou une dette permanente ?	Viser à le réduire
7	Cette décision résout le fond (cognition, jugement) ou la surface (mesure, règle) ?	Attaquer le fond

7. Questions en suspens à trancher¶

Sur le découpage multi-agents¶

Quel volume d'étapes purement procédurales (mathématiques/déterministes) peut-on extraire du LLM ? C'est le vrai gisement de robustesse.
Jusqu'où pousser la décomposition avant que la fusion coûte plus que l'isolation ne rapporte ?
Quelle baseline Manus pour le benchmark trimestriel ? (Standard, avec outils, autre modèle one-shot ?)

Sur les règles métier¶

Quelle volumétrie minimum de golden dataset pour que le niveau C (jugement appris) soit viable ? (100 / 500 / 1000 dossiers ?)
Qui valide le golden dataset — référent métier unique ou consensus d’analystes ?
Comment exposer au porteur les règles A sans révéler le niveau C (propriété intellectuelle du jugement) ?
Quelle transition entre système sur règles aujourd'hui et système sur jugement appris demain ? Modes parallèles ? A/B sur dossiers réels ?

Sur le consensus inter-agents¶

Comment calibrer les confiances des agents existants ? Aucun n'expose aujourd'hui de confiance honnête.
Quel agent adversarial déployer en premier, sur quel périmètre ?
Quel est aujourd'hui le taux d'erreur conditionnel au consensus sur le golden dataset ? (Baseline à mesurer.)

Sur le monitoring¶

Quelle baseline d'alertes aujourd'hui ? (Pour juger dans 6 mois si on simplifie ou empile.)
Quelle part du monitoring "Investigation" peut être remplacée par des tests golden dataset automatiques ?
Le healing loop a-t-il des kill criteria clairs ? (Proto 2 semaines décidé S16.)

Meta¶

Ce mémo doit-il être partagé avec les décideurs métier pour alignement sur la philosophie ?
Cadence de revue de ces principes : trimestrielle ? À chaque fin de projet Linear ?

8. Actions concrètes à court terme¶

Dérivées des principes et des questions en suspens.

#	Action	Horizon	Owner
1	Instaurer le benchmark trimestriel pipeline vs. Manus one-shot sur golden dataset	Q2	Romain / Nicolas
2	Mesurer la baseline du taux d'erreur conditionnel au consensus	Q2 (avec golden dataset)	Romain
3	Calibrer les confiances exposées par chaque agent (commencer par 2-3 agents critiques)	Q2	Romain + freelances
4	Formaliser la politique "ajoute un exemple, pas une règle" dans la doc Hub Analystes	Q2	Romain
5	Lister toutes les règles actuelles et les classer A / B pour nettoyer les B en attente	Q2	Romain + Nicolas
6	Identifier les étapes procédurales/déterministes candidates au découpage dur (frais de notaire déjà en cours — BRI-313)	Q2	Nicolas
7	Définir kill criteria et metrics du healing loop (proto 2 semaines)	S17-S18	Romain
8	Partager une version adaptée avec les décideurs métier	S17-S18	Produit

9. Conclusion — le fil rouge¶

Le tweet a raison sur un point universel : les derniers points de fiabilité sont un problème de cognition, pas de mesure. Ajouter un capteur, un agent, une règle ne résout rien si le problème est la compréhension.

Il a raison sous condition sur un autre : scaler une méthode générale bat les architectures bricolées — à condition d'avoir l'échelle et le temps.

Bricks OS n'a ni l'échelle de Tesla, ni son temps, ni son indépendance modèle. Donc un découpage conscient reste rationnel. Mais le découpage n'est pas une fin en soi : c'est une béquille temporaire qu'il faut régulièrement confronter à la baseline end-to-end.

Le vrai danger n'est pas de découper. Le vrai danger est de glisser : - Du niveau A au niveau B des règles sans le remarquer - Du découpage procédural au découpage LLM déguisé - De la fusion de sources indépendantes au consensus corrélé - Du monitoring temporaire au monitoring qui grossit avec le système

Le vrai objectif reste : reproduire un jugement métier explicable, pas seulement des règles déclarées. Automatiser la décision, pas la mesure. Construire la boucle d'apprentissage, pas la spécification amont.

Never bet against end-to-end — mais en 2026, à notre échelle, parier sur l'end-to-end c'est parier sur la boucle d'apprentissage, pas forcément sur un modèle monolithique. Les deux paris sont compatibles si on est lucide sur ce qu'on construit.

Document à réviser après validation par les décideurs métier.