Note d’ingénierie
Leon : encadrer un modèle de langage dans un système où l’erreur coûte de l’argent
Un banc d’essai interne, pas une référence de production. On le publie parce que c’est là qu’on montre le niveau de rigueur qu’on applique quand une erreur n’est pas rattrapable.
Rôle Looptra
Conception, développement, exploitation
Statut
Interne, non commercialisé
Terrain
Système event-driven, sur nos propres fonds
Socle
Traitements asynchrones, moteur de risque déterministe
Section 01
La question posée
Peut-on faire intervenir un modèle de langage dans une chaîne de décision automatique sans jamais lui confier la décision ? La question nous intéresse parce qu’elle revient chez nos clients sous d’autres formes : un modèle qui valide une pièce, qui trie une demande, qui déclenche un paiement.
Pour l’éprouver, il fallait un terrain où l’erreur se paie immédiatement et où personne ne peut se raconter d’histoire. C’est ce qu’est Leon : un système event-driven qui réagit à des évènements de marché, sur nos propres fonds, avec des garde-fous conçus avant la première ligne de logique.
Section 02
La contrainte dure
Une action irréversible au bout de la chaîne
Il n’y a pas d’écran de confirmation, pas de « annuler ». Toute la conception part de là : ce n’est pas la qualité moyenne des décisions qui compte, c’est l’impossibilité d’un mauvais cas.
Un modèle non déterministe, et manipulable par le texte
Une même entrée peut donner deux sorties, et n’importe qui peut écrire publiquement une phrase conçue pour influencer un modèle. Un système qui lit du texte public et agit derrière est, par construction, attaquable.
Des flux qui arrivent quand ils veulent
Signaux publics, données de marché, évènements : rien n’est synchrone, tout peut arriver deux fois, en retard, ou pas du tout. Un traitement rejoué doit produire le même résultat, pas un second effet.
Section 03
Les décisions d’architecture
L’architecture de sécurité, pas la stratégie.
Le modèle ne voit jamais le texte brut
Pourquoi : les signaux publics sont d’abord transformés en features structurées : qui parle, quel type de compte, quelle nouveauté, quel écart par rapport à l’habituel. Le modèle raisonne sur ces champs, jamais sur la phrase d’origine. Une phrase écrite pour manipuler un modèle n’a plus de prise, et deux exécutions sur les mêmes faits sont comparables.
Ce que ça coûte : un étage d’extraction à écrire, à tester et à maintenir, et de la nuance perdue au passage. On l’accepte.
Un moteur déterministe a le dernier mot
Pourquoi : le modèle produit au mieux une conviction ; il ne signe rien. Aucune action ne sort sans avoir passé un moteur de risque écrit en code : bornes, cohérence, limites d’exposition. Si une règle dit non, l’avis du modèle ne compte pas.
Ce que ça coûte : le système refuse des cas que le modèle jugeait bons. C’est l’objectif.
Idempotence et arrêt automatique
Pourquoi : chaque évènement est traité une fois et une seule, même s’il arrive deux fois ; un redémarrage ne rejoue pas d’action. Et si la chaîne cesse de donner signe de vie, un dead man’s switch coupe tout plutôt que de laisser un système aveugle continuer.
Ce que ça coûte : de l’état à gérer partout, et des arrêts déclenchés pour des incidents bénins.
Trois environnements, dont un qui n’engage rien
Pourquoi : dev, staging en simulation, production. Rien ne passe en production sans avoir tourné à blanc sur des flux réels. Les mêmes garde-fous s’appliquent aux trois, sinon on ne teste pas le vrai système.
Ce que ça coûte : trois environnements à maintenir pour un système qui n’a pas de client.
Section 04
Ce qui tourne, et ce qu’on ne dira pas
Le système tourne en interne, sur nos fonds, avec les garde-fous décrits plus haut. On ne publiera ni performance, ni signal, ni méthode de sélection : ça n’ajouterait rien au propos et ça transformerait un banc d’essai en promesse. Ce que Leon démontre est ailleurs, dans la manière d’enfermer une brique probabiliste au milieu de code déterministe et vérifiable.
Section 05
Ce que l’exercice a établi
Une brique probabiliste peut tenir dans une chaîne irréversible, à condition qu’elle ne décide jamais. Ce qui l’encadre compte plus que le modèle choisi.
C’est ce que Leon a servi à établir, et c’est ce qu’on applique quand un client nous demande de mettre de l’IA sur un processus qui engage vraiment quelque chose.
Leon n’est pas un produit et n’est pas commercialisé. Aucune performance n’est publiée, aucun signal n’est diffusé, rien ici ne constitue un conseil en investissement ni une incitation à investir.