Aller au contenu

ADR-004 — Friction délibérée avant analyse
Statut Accepted
Date 07/05/2026 (S19 mid-week)
Décideurs Romain BAZIL, Nicolas Léonard
Origine Synchro S19 mid-week §1

Contexte

Cas concret observé sur Manus : sur un projet où la surface habitable n'était pas extraite des documents, Manus a inventé une surface à partir du prix déclaré par le porteur ("sur un coin de serviette") en se disant qu'il faisait probablement entre 160 et 180 m². Tout ce qui en a découlé (estimation valeur vénale, marge, LTV) était faux. L'analyste s'en est rendu compte par hasard.

Le problème n'est pas un bug ponctuel : c'est structurel. Les agents full-agentiques type Manus sont entraînés à toujours produire un output, même quand ils manquent de matière. Ils sont calibrés pour ne pas faillir, ce qui les pousse à halluciner.

Décision

Le pipeline interne refuse de tourner un agent si ses champs critiques ne sont pas renseignés.

Plutôt que de laisser un agent produire un output halluciné, on lui interdit de tourner.

Mécanisme

  1. Chaque agent déclare son set de champs critiques (les inputs sans lesquels il ne peut pas faire un travail honnête)
  2. Avant de lancer l'agent, le pipeline vérifie la complétude de la fiche consolidée sur ces champs
  3. Si manquant → l'agent ne tourne pas, un signal est remonté à l'AM (bandeau "champs critiques manquants")
  4. L'AM peut quand même forcer le lancement (pop-up de confirmation), mais la responsabilité est tracée

Wording côté UI

  • Bandeau : "X champs critiques manquants" (vs "0/23 validés")
  • Verbe : "fiabiliser" (vs "valider" / "vérifier")
  • Bouton "Envoyer en analyse" reste accessible (pas de big bang sur le workflow AM) avec pop-up rappel

Rationale

  • La complétude est responsabilité humaine, pas IA : si la matière n'est pas là, c'est l'AM qui doit aller la chercher (relancer le porteur, fouiller, demander un document) — pas l'agent qui doit inventer
  • Économie de coûts : faire tourner estimate_value sans surface = ~5-6'30 et plusieurs euros pour un output inutilisable
  • Économie de temps analyste : un output halluciné fait perdre plus de temps qu'un agent qui ne tourne pas (l'analyste re-creuse pour comprendre, perd confiance dans tous les outputs)
  • Anti-pattern Manus structurant : « Ces agents sont entraînés pour donner une réponse, mais pas pour rentrer dans tes critères de manière systématique. »
  • Capture d'un signal de qualité AM : les AM qui poussent systématiquement avec des champs critiques manquants deviennent identifiables (signal de coaching)

Conséquences

Ce qui change

  1. Chaque agent doit déclarer son set de champs critiques (à formaliser dans wiki/stack/ à venir, ou dans le code de l'agent directement)
  2. Le pipeline vérifie la fiche consolidée avant chaque lancement d'agent
  3. Le bandeau UI guide l'AM vers les champs à fiabiliser en priorité
  4. Friction acceptée dans le workflow AM (pas de big bang, mais signal clair)

Ce qu'il faut faire

  • Lister par agent (estimate_value, réputation, projections financières, etc.) le set minimum de champs critiques
  • Implémenter le check pré-lancement
  • Renommer le bandeau ("X champs critiques manquants" + verbe "fiabiliser")
  • Tracer les forçages (qui force quand sur quel projet)

Ce qu'il faut éviter

  • Bloquer dur l'envoi en analyse : pas de big bang sur le workflow AM, on garde la possibilité de forcer
  • Faire la liste de "champs nécessaires" trop conservative : on bloquerait trop de dossiers et les AM contourneraient

Alternatives écartées

  • Laisser tourner l'agent et signaler le doute en sortie : on a essayé, ça produit du bruit que personne ne lit
  • Faire faire l'extraction manquante par un autre agent : on rajouterait un Nième prompt LLM pour fixer un trou (anti-pattern LIDAR #1)
  • Compteur "X/23 validés" : trompeur (Romain l'a interprété comme un compteur de complétude data, pas de validation AM) → wording réécrit en "champs critiques manquants"

Verbatims

« Ces agents sont entraînés pour donner une réponse, mais pas pour rentrer dans tes critères de manière systématique. C'est exactement pour ça qu'on ne peut pas miser sur un Manus at scale chez Bricks. » — Romain

« Mon take qui commence à se forger maintenant de façon assez forte, c'est qu'il y a de la friction qui doit avoir lieu avant d'appuyer sur le bouton et de lancer l'analyse. » — Nicolas

« Le call to action ici, c'est plutôt "commencer à fiabiliser des données" — pas "valider". Ça les met dans un mindset : ton rôle, c'est de fournir de la data fiable pour nos agents qui seront utilisés par les analystes, qui seront utilisés pour décider si oui ou non on finance. » — Romain (sur le wording)

Cas concret de référence

Projet où estimate_value (V4 ou Manus, à confirmer) a halluciné une surface habitable à partir du prix déclaré. Surface réelle disponible dans un override AM corrigé par Franck — jamais lu par l'agent (cause : pas de fiche consolidée à l'époque). À la suite : fiche consolidée + ADR-003 (hiérarchie de précédence) + cet ADR-004.

Voir aussi

Sources