Aller au contenu
Novialoom
Lab · agent-lab

Les agents proposent, la plateforme décide.

Un agent d'IA propose des actions : appeler un outil, rédiger un mémo, décaisser un crédit. En entreprise, chaque action doit être autorisée, attribuable et prouvable, sans faire confiance au code de l'agent. Le banc agent-lab montre une architecture où l'agent propose et où la plateforme, hors de lui, autorise, exécute et prouve.

Outil interne Banc de démonstration local, sur des données fictives.

01 L'architecture de référence

Quatre plans, une frontière de confiance.

  • Contrôle

    Ce qu'un agent a le droit de faire : son contrat, validé puis signé et compilé en politique, et son identité.

    registre · moteur de politique · identité

  • Exécution

    Là où l'agent tourne : il propose, sa supervision est sa seule sortie, et chaque appel franchit une porte.

    porte d'entrée · agent · hébergement · supervision · model gateway · porte de sortie

  • État

    Les sessions, les approbations et les clés d'exécution, écrites par les seuls composants de confiance.

    sessions · approbations

  • Assurance

    L'audit, signé par chaque composant de confiance, et l'évaluation que lit la mise en production.

    audit · évaluation

Capture d'écran de l'accueil du banc : le parcours en six étapes, puis le schéma des quatre plans (contrôle, exécution, état, assurance) et leurs briques, chacune avec le composant du banc qui la tient.
L'accueil du banc : les quatre plans, leurs briques et le parcours en six étapes. Capture du banc, données fictives.
02 Le parcours

Six étapes, sur un dossier de crédit fictif.

De la création d'un agent à la preuve de ce qu'il a fait. Chaque étape a son écran ; chacun montre un contrôle, aucun n'en porte.

  1. Étape 1

    Créer l'agent

    On décrit un assistant outillé qui vérifie l'identité d'un client : son rôle, ses outils, son mandat. La plateforme en calcule le risque ; personne ne le déclare.

    Un essai à blanc le joue contre des serveurs fictifs, sans appeler aucun vrai service. Puis l'auteur propose l'agent au registre.

    Capture d'écran de l'atelier : un agent prérempli, son gabarit, son prompt et ses outils ; l'essai à blanc contre des serveurs fictifs ; le risque que la plateforme calcule, moyen, et le grade de l'agent.
    Atelier : le risque est calculé depuis les outils et les données, jamais déclaré. Capture du banc, données fictives.

  2. Étape 2

    Le faire valider

    Deux personnes autres que l'auteur valident la proposition : le propriétaire métier, puis la sécurité.

    L'auteur ne peut pas valider sa propre proposition. L'écran grise son bouton, et le registre refuse de toute façon : le contrôle est dans le service, pas dans l'écran.

    Capture d'écran du registre : la fiche du coordinateur crédit en service, ses outils, son risque et ses deux validations, à côté des propositions en cours de validation.
    Registre : chaque agent, sa version en service et les deux personnes qui l'ont validé. Capture du banc, données fictives.

  3. Étape 3

    Le mettre en production

    La plateforme signe le contrat, compile la politique, publie la version et lance l'agent, étape par étape. Chaque étape a son contrôle ; une étape en échec arrête la chaîne.

    Au lancement, le launch check n'admet qu'une version publiée dont les empreintes et les signatures concordent.

    Capture d'écran de la mise en production : le diagramme de séquence qui mène de la carte validée à l'agent qui répond, de la gate d'évaluation au launch check, et les états de l'agent : suspendre, retirer, rétablir.
    Mise en production : chaque flèche s'allume quand l'étape qui la porte a réussi. Capture du banc, données fictives.

  4. Étape 4

    Lui confier une mission

    La mission entre par la porte d'entrée, sous le jeton de l'utilisateur, et va au coordinateur crédit, qui instruit le dossier : vérifier l'identité du client, calculer son score, rédiger le mémo de crédit.

    L'agent propose chaque action ; sa supervision applique les garde-fous, le moteur de politique autorise ou refuse. Le diagramme de séquence se dessine en direct, et la rédaction du mémo attend une approbation.

    Capture d'écran de l'écran Mission : la demande au coordinateur crédit, puis le diagramme de séquence en direct entre l'utilisateur, la porte d'entrée, la supervision, l'agent, la model gateway, le moteur de politique, la porte de sortie et les outils ; la mission attend l'approbation du mémo.
    Mission : le diagramme se dessine en direct, en pause sur l'approbation du mémo. Capture du banc, données fictives.

  5. Étape 5

    Approuver l'action sensible

    Le human-in-the-loop est tenu par la plateforme, pas par l'agent. Une autre personne que le demandeur approuve la rédaction du mémo, pour cet appel exact : l'approbation est liée à son empreinte.

    Un appel modifié après la décision est refusé, et le demandeur ne peut pas s'approuver. L'appel exécuté est l'appel approuvé, une fois au plus : c'est l'unicité d'exécution.

    Capture d'écran des approbations : la rédaction du mémo de crédit, d'« en attente » à « exécutée », ses arguments montrés par type et longueur seulement, et l'appel exécuté, identique à l'appel approuvé.
    Approbations : l'appel exécuté est identique à l'appel approuvé, et exécuté une seule fois. Capture du banc, données fictives.

  6. Étape 6

    Rejouer et prouver

    On relit la mission dans l'audit signé : qui a décidé quoi, au nom de qui. Chaque événement est signé par le composant de confiance qui l'émet, avec sa propre clé ; aucun ne vient de l'agent.

    Chaque signature se revérifie, et un événement falsifié apparaît invalide.

    Capture d'écran de l'audit signé d'une mission : chaque événement, le composant de confiance qui l'a émis, sa décision et sa signature revérifiée.
    Audit : chaque événement est signé par le composant qui l'émet, et se revérifie. Capture du banc, données fictives.
03 Une brique, un écran

Chaque brique de l'architecture a son écran.

Politique, entrée, agents, hébergement, supervision, model gateway, sortie, sessions, évaluation : chacun en lecture, rangé par plan. Trois d'entre eux.

  • Politique

    Les règles en clair, porte par porte, et ce que chaque agent a le droit de faire, lu dans les contrats compilés. L'autorité effective est une intersection : le contrat de l'agent, ses habilitations, les droits de l'utilisateur.

    On y teste une décision (un agent, une action, un montant) ; le moteur répond sans rien appliquer.

    Capture d'écran de l'écran Politique : une décision testée, refusée parce que la juridiction sort du mandat, puis les règles en clair, porte par porte, avec le refus que chacune produit.
    Politique : une décision testée, refusée hors mandat, et les règles porte par porte. Capture du banc, données fictives.

  • Identité et chaîne OBO

    Qui agit au nom de qui (on-behalf-of) : le jeton de l'utilisateur, échangé pour l'agent, puis pour l'agent qu'il appelle, selon la RFC 8693.

    La chaîne d'acteurs se lit à l'écran, les jetons décodés et rédigés. Une délégation n'ajoute aucun droit.

    Capture d'écran de l'écran Identité : les échanges de jetons, de l'utilisateur au coordinateur crédit, puis à l'agent de scoring ; un troisième saut, hors contrat, est refusé par le moteur de politique.
    Identité : qui agit au nom de qui, à chaque échange de jeton ; un saut hors contrat est refusé. Capture du banc, données fictives.

  • Évaluation pass^3 : trois succès sur trois

    Chaque agent rejoue trois fois, indépendamment, ses missions de démonstration, et ne passe que s'il réussit les trois fois. C'est pass^3 (« pass puissance 3 »), au sens du benchmark τ-bench de Sierra : l'inverse de pass@3, où un seul succès sur trois suffit.

    Un modèle de langage n'est pas déterministe : un agent qui réussit une fois sur trois n'est pas fiable en production. pass^3 mesure la régularité, pas la réussite ponctuelle. La mise en production lit ce résultat et refuse un agent qui ne passe pas.

    Capture d'écran de l'écran Évaluation : pour chaque agent, sa mission de démonstration, son résultat sur trois essais et la gate de mise en production, ouverte ou fermée.
    Évaluation : trois succès sur trois, ou la mise en production reste fermée. Capture du banc, données fictives.
04 L'agent hostile

Treize tentatives de contournement, toutes refusées hors de l'agent.

Un agent écrit pour tricher, avec LangChain comme le ferait une équipe métier, enchaîne ses tentatives dans une seule mission. Il essaie de :

  • joindre en direct un serveur d'outils, la porte de sortie, le modèle, un autre agent ou l'audit ;
  • signer un événement d'audit ou un contrat, sans clé ;
  • entrer sans passer par la porte d'entrée ;
  • demander un autre modèle que celui de son contrat ;
  • remplacer son prompt système, en direct ou par un middleware ;
  • appeler un outil hors de son contrat ;
  • passer un argument que les garde-fous bloquent ;
  • dépasser le mandat de l'utilisateur.

Chaque tentative est refusée par un composant hors de l'agent, et chaque refus est tracé dans l'audit signé. Sur l'écran Mission, une variante « mémo piégé » montre aussi le garde-fou de sortie : le serveur de mémo renvoie une injection de prompt, que la supervision bloque.

Capture d'écran de l'écran Supervision : pour l'agent hostile, les contrôles faits, ce qu'il a proposé, ce qui est sorti et chaque tentative retenue avec sa raison ; en dessous, le coordinateur crédit, dont rien n'est retenu.
Supervision : ce que l'agent hostile a tenté, et ce que sa supervision a retenu. Capture du banc, données fictives.

05 Sous le capot

Docker Compose
toute la plateforme sur un poste, sans dépendance cloud.
Envoy et OPA
la porte d'entrée, et le moteur de politique, qui charge en bundle signé une politique compilée depuis les contrats.
Keycloak et un service de jetons RFC 8693
les identités des utilisateurs et des agents, et l'échange de jetons qui porte la chaîne d'acteurs.
LangGraph, LangChain create_agent et un agent sans framework
trois runtimes sous le même contrat et la même supervision.
Une supervision hors du processus de l'agent, en MCP
sa seule sortie vers le modèle et vers les outils.
Une model gateway devant des modèles locaux
le modèle du contrat et le budget de tokens, tenus hors de l'agent.
Un audit signé (immudb, ed25519)
une clé par composant de confiance, des signatures revérifiables hors ligne.
PostgreSQL et OpenTelemetry
l'état d'exécution, et les traces de chaque mission.

06 Ce que ce banc n'est pas

Un produit en production : c'est un banc de démonstration local, sur des données fictives.
Une recommandation de stack : certaines briques sont des substituts de banc, comme Envoy à la place d'une API gateway d'entreprise. Chacune expose le même motif d'intégration que la brique qu'elle remplace.
Une mémoire d'agent : le banc n'a pas de mémoire longue.
Une évaluation complète : pass^3 sur les missions de démonstration, rien de plus.
Une isolation par session : chaque agent a son unité d'exécution, pas chaque session.
Lab Architecture d'agents

Concevoir l'autorité de vos agents.

La formation Architecture d'agents part des mêmes principes : un contrat d'agent signé, une politique « refus par défaut » testée sur cas, une méthode pour modéliser l'autorité effective.

Architecture d'agents

Tous les outils du Lab