Des agents no-code sans le trou de gouvernance

Les constructeurs d'agents no-code sont réellement bons. Permettre à un expert métier d'assembler un agent en un après-midi — choisir un modèle, brancher quelques outils, écrire un prompt, livrer — libère une vraie productivité, et cela ne disparaîtra pas. Le problème est ce que la plupart de ces constructeurs sacrifient discrètement pour y arriver. Quand n'importe qui peut livrer un agent en quelques minutes, on obtient beaucoup d'agents en quelques minutes, et la plateforme qui a rendu la chose facile l'a rarement rendue gouvernée.

Le trou que la plupart des constructeurs laissent béant

La vitesse de création n'est pas le risque. Le risque, c'est tout ce que le parcours de création saute. L'agent no-code type est livré sans les contrôles qui rendent son exécution sûre dans une entreprise régulée :

• Il s'exécute sous une clé partagée ou un compte de service au périmètre large, sans propriétaire, sans finalité métier, sans niveau de risque ni date d'expiration.
• Il n'a aucun plafond de dépenses, si bien qu'une boucle mal configurée devient un incident de coût avant que quiconque ne le remarque.
• Ses appels d'outils vont droit à l'outil, sans allowlist, sans DLP sur les entrées ou les sorties, et sans kill switch.
• Ses actions ne sont enregistrées d'aucune manière à altération détectable, de sorte qu'il n'y a rien à remettre à un auditeur.
• Il peut être publié sans aucun seuil de fiabilité, si bien qu'un agent de faible qualité atteint la production au feeling.

L'intérêt d'un constructeur gouverné n'est pas de ralentir la création. Il est de faire du chemin sûr le chemin par défaut — pour que la façon rapide de livrer soit aussi la façon gouvernée.

Comblez le trou au niveau du runtime, pas du canevas

La solution n'est pas de rendre la création plus difficile. Elle consiste à placer le même runtime gouverné sous tout ce qui est créé, pour que no-code ne signifie pas sans contrôles. Dans Cortex, un agent construit dans le studio est gouverné exactement comme un agent écrit à la main. Dès qu'il s'exécute, il franchit les mêmes huit verrous fail-closed — identité, budget, garde-fous, registre, control tower, exécution, contrôle de sortie, audit. Il n'existe pas de second chemin d'exécution, non gouverné, réservé aux agents faciles.

La publication est verrouillée elle aussi. Le registre consulte le score de fiabilité en direct de l'agent et refuse de publier celui qui, avec assez de signal, reste sous le seuil — pour qu'un agent de faible qualité n'atteigne pas la production au seul motif qu'il a été rapide à construire :

POST /v1/agents/<id>/publish
  -> 409 RELIABILITY_TOO_LOW
     score 41 < RELIABILITY_MIN_PUBLISH (50)

# les agents neufs ou peu documentés publient librement ;
# le seuil s'applique dès qu'il y a assez de signal d'exécution.

La gouvernance par défaut, pas comme un impôt

Bien menée, la gouvernance n'est pas une friction que l'on greffe après la partie amusante. Chaque agent reçoit une véritable identité gouvernée, avec un propriétaire et une expiration, dès l'instant où il existe. Chaque appel d'outil passe par l'allowlist et le DLP de la gateway. Chaque exécution est scellée dans le Trust Ledger. Le constructeur reste rapide ; la gouvernance est simplement toujours active en dessous.

C'est ainsi que l'on garde la vitesse sans la prolifération. Les équipes qui gagnent avec les agents no-code ne sont pas celles qui ont livré le plus d'agents le plus vite — ce sont celles qui peuvent encore vous dire, un an plus tard, ce qu'est chacun de ces agents, qui en est propriétaire et exactement ce qu'il a fait. Faites du chemin gouverné le chemin par défaut, et vous obtenez les deux.