Aller au contenu

ADR-037 — La convergence devient un agent outillé avec accès documentaire
Statut Proposed
Date 14/08/2026
Décideurs Dimitri Hertz (propose), Romain BAZIL + Jérôme Barthès (valident)
Origine Atelier convergence 14/08 (décision D2)

Contexte

Aujourd'hui le moteur de convergence arbitre sur les seuls résultats des méthodes (une valeur + un court extrait). Comportement non souhaitable identifié : si deux méthodes sur trois se trompent de la même façon, la convergence retient leur valeur et l'affiche comme vraie (problématiques convergence §1). Le juge n'a pas de quoi prendre du recul : il ne voit qu'un passage minuscule, pas le contexte du dossier.

Cette ADR étend le principe de cascade (ADR-001) : la convergence ne se contente plus des outputs, elle accède aux documents.

Décision

Le moteur de convergence devient un agent IA outillé, avec accès au contexte documentaire du dossier.

  1. Accès documentaire : chaque document est stocké en base avec sa pagination et un résumé structuré (au-delà du seul RAG). La convergence récupère le résumé et les pages citées des documents en jeu, et tranche sur le contexte global du dossier, pas sur un extrait isolé.
  2. Outils d'exploration : l'agent peut requêter la base de données et le RAG pour se forger un avis neutre, indépendant de ce que les workflows lui ont remonté.
  3. IA distincte du juge : idéalement, le juge tourne sur un modèle d'IA différent de celui des méthodes, sinon les raisonnements s'uniformisent et l'arbitrage perd sa valeur.
  4. Hébergement : la convergence reste dans le repo Python, sur une route indépendante (déjà le cas aujourd'hui). Un service / serveur séparé est écarté pour raison de coût (multiplication des serveurs Railway).

Rationale

  • Sortir de la convergence « à plat » : aujourd'hui un workflow envoie une valeur + un bout de texte, sans raisonnement ni contexte. Donner à l'agent les documents + des outils lui permet de vérifier si un raisonnement « tient » plutôt que de compter les votes.
  • Neutralité du juge : un juge qui n'a que les argumentaires des workflows est trop contextualisé par eux ; il lui faut des données neutres pour trancher (Dimitri).
  • Ne pas recréer un workflow : le périmètre d'exploration de la convergence macro reste borné (critiquer / trancher), il ne refait pas le travail d'extraction de chaque workflow — sinon « spirales infernales » (Romain).
  • Coût maîtrisé : la charge (stockage + IA sur documents entiers) est assumée au regard de l'enjeu, à optimiser plus tard.

Conséquences

  1. Travail de context engineering préalable (système de documents structurés par projet, « une sorte de wiki à l'échelle du projet ») — prérequis, pas encore fait.
  2. Mise à jour des schémas de base (Python + TS) pour porter résumé structuré + document paginé.
  3. Possibilité de passer sur des modèles plus performants côté juge (plus de contexte disponible).
  4. Piste ouverte : un accès standardisé par projet (MCP) pour brancher une méthode alternative sans l'intégrer au repo.

Alternatives écartées

  • Service / repo séparé pour la convergence macro : écarté pour coût serveur (Romain, Dimitri).
  • Juge sur la même IA que les méthodes : uniformisation des raisonnements, intérêt faible.
  • Convergence limitée aux outputs : le comportement non souhaitable actuel (majorité qui se trompe).

Verbatim

« pour moi, la convergence doit être un workflow… il ait accès aux documents… l'accès à des tools, capable de requêter la base de données, capable de requêter le RAG, et il doit sortir une décision » — Dimitri (atelier 14/08)

« c'est une route indépendante… comme c'est le cas aujourd'hui… [service séparé] à un moment ton CFO va venir te voir » — Romain (atelier 14/08)

Voir aussi

Sources