REGARD · Architecture

Le projet de bout en bout

Du besoin métier jusqu'à la réponse vérifiée : le déroulé complet, et comment l'agent est construit techniquement. Une seule page pour tout comprendre.

1 · Métier

Le besoin

2 · Données

Du brut au gold

3 · Agent

Question, réponse

4 · Contrôle

Vérifié et mesuré

1. Le besoin métier (finance)

Une banque a des expositions de risque : des montants qu'elle risque de perdre si une contrepartie (une autre banque, une institution) fait défaut. Son cauchemar, c'est le risque de concentration : trop d'exposition sur un même acteur, et sa chute entraîne la banque. C'est le mécanisme de 2008.

Les régulateurs imposent donc des limites de concentration (ici 60 000 000 € par contrepartie) et, via la norme BCBS239, exigent des données de risque fiables, traçables et à jour. Le problème réel : ces données sont en désordre, dispersées, saisies par des humains. Un responsable conformité doit pourtant répondre vite à « quelle est notre exposition sur X ? », « dépasse-t-on une limite ? ».

L'objectif de REGARD : permettre à une personne non-technique d'obtenir une réponse fiable et sourcée sur ces expositions, en posant une question en français, sans écrire de requête, sans ouvrir un tableur, et sans jamais recevoir un chiffre inventé.

2. Le déroulé, étape par étape

Une question traverse neuf étapes, de la donnée brute jusqu'à la réponse tracée. Les étapes en bleu sont déterministes (code vérifiable) ; le modèle d'IA n'intervient qu'en appui.

  1. 1

    Génération des données

    · pipeline/raw/generate.ts

    Un script seedé fabrique 207 lignes d'expositions synthétiques, avec un désordre volontaire (formats incohérents, devises mélangées, doublons, valeurs manquantes) qui imite le réel.

  2. 2

    Nettoyage et scoring

    · pipeline/transform.ts

    Chaque ligne est réparée (montants, devises, dates normalisés), dédupliquée, et reçoit un score de qualité de 0 à 1. Les lignes irréparables sont rejetées, avec leur motif.

  3. 3

    Table gold

    · public/data/exposures_gold.csv

    La version propre, fiable et notée. C'est la seule source que l'agent et les tableaux de bord ont le droit de consulter.

  4. 4

    La question

    · app/api/ask

    L'utilisateur pose une question en français. Elle entre dans l'agent côté serveur (les clés d'API ne touchent jamais le navigateur).

  5. 5

    Planification

    · nodes/plan.ts

    L'agent détecte l'intention (total, liste, fraîcheur, etc.) et la contrepartie, par règles déterministes. Le LLM n'est sollicité que si la question reste ambiguë.

  6. 6

    Récupération

    · nodes/retrieve.ts

    Les lignes pertinentes sont extraites de la table gold, avec un score de confiance et un indicateur de fraîcheur.

  7. 7

    Croisement et brouillon

    · nodes/crosscheck.ts

    Le code calcule les faits : totaux par devise, puis conversion en équivalent euros à taux fixes documentés, classements et dépassements de limite. Le LLM reformule ces faits vérifiés, il ne calcule rien.

  8. 8

    Autocontrôle

    · nodes/verify.ts

    Contrôles déterministes d'abord (fraîcheur, confiance, citations qui existent), puis un LLM-juge qui vérifie que chaque chiffre est ancré dans les sources. Si non : nouvel essai ou refus.

  9. 9

    Réponse ou refus, tracé

    · nodes/finalize.ts

    Soit une réponse gouvernée avec ses sources et ses badges qualité, soit un refus motivé. Chaque étape et chaque décision sont journalisées.

3. Comment l'agent est construit

Un graphe d'états (LangGraph)

L'agent n'est pas une suite d'instructions linéaire, mais un StateGraph : des nœuds reliés par des arêtes, dont certaines conditionnelles. Après l'autocontrôle, le graphe peut boucler en arrière (nouvel essai) ou filer vers la réponse. Un simple if/else deviendrait vite illisible ; le graphe rend le flux explicite et modifiable.

Un état typé et partagé

Chaque nœud lit et enrichit un état commun (la question, le plan, les enregistrements, le brouillon, les citations, le verdict, les tokens consommés). Les compteurs, coût et appels LLM, s'accumulent sur toute la requête, y compris les essais répétés.

Déterministe d'abord, LLM ensuite

Le principe central : le calcul, les contrôles et les décisions reviennent au code vérifiable ; le LLM ne sert qu'à comprendre une question floue et à rédiger. Résultat : sans clé d'API, ou si le modèle est indisponible, l'agent répond quand même, moins fluide mais tout aussi fiable.

L'autocontrôle en défense en profondeur

Trois lignes de défense : les garde-fous déterministes (une donnée périmée ou une citation introuvable font refuser), puis le LLM-juge contre les dérives chiffrées, puis l'escalade humaine. Aucune n'est présentée comme une garantie : c'est un empilement de filets.

Mesuré, pas supposé

Un harnais d'évaluation en Python rejoue un jeu de 28 questions de référence contre l'agent et calcule les métriques réelles : justesse des décisions, couverture des citations, latence, coût par requête, hallucinations détectées. C'est ce qui distingue un système fiable d'une démo qui marche une fois.

28/28

Cas réussis

~370 ms

Latence médiane

~0,26 $

Coût / 1000 req.

7

Capacités métier

Chiffres mesurés par le harnais d'éval sur le golden dataset, reproductibles.

La stack, et pourquoi

Next.js 15 + TypeScriptUn seul déploiement pour le site et l'agent ; typage strict de bout en bout.
LangGraph.jsOrchestration du graphe d'états, avec boucle d'autocontrôle.
DuckDB-WASM / Node fsRequêtes sur la table gold : dans le navigateur pour les dashboards, côté serveur pour l'agent.
Groq (Llama 3.3 70B) + GeminiReformulation et jugement, avec repli automatique. Rapide et à coût quasi nul.
Python + pytestHarnais d'évaluation en boîte noire, rejouable en intégration continue.
Interroger l'agent Comprendre les données