Jev et l'essor des modèles de décision : ce que System One AI signifie pour les outils de sécurité

Le 25 septembre 2026, TypeSafe AI a annoncé Jev, le premier modèle de ce qu'elle appelle la catégorie « System One » : pas un chatbot, ni simplement un modèle de langage plus vaste, mais ce que l'entreprise décrit comme un modèle de décision – quelque chose conçu pour répondre à une question limitée avec une réponse dactylographiée et calibrée plutôt qu'un paragraphe de prose. L'annonce est riche en chiffres précis, c'est pourquoi cet article l'examine exactement comme annoncé, indique clairement ce que nous avons pu et ne pouvons pas vérifier, et examine pourquoi l'idée sous-jacente, décider au lieu de générer, mérite d'être prise au sérieux pour les logiciels de sécurité en particulier.

Ce que TypeSafe a réellement annoncé

TypeSafe AI est fondée par Diogo Almeida, qui écrit dans l'annonce : « Chez OpenAI, j'ai aidé à créer les méthodes qui ont rendu les modèles de langage utiles pour suivre des instructions et parler avec les gens. » Jev, appelé le « premier modèle public » de l'entreprise, est présenté comme un travail totalement différent : produire ce que TypeSafe appelle des valeurs structurées de type sécurisé avec des probabilités calibrées et des scores de confiance, générées par ce qu'elle appelle un échantillonneur parallèle plutôt que par le décodage habituel jeton par jeton, et formées avec une méthode que l'entreprise appelle l'apprentissage par renforcement pour des décisions calibrées, ou RLCD.

• TypeSafe rapporte un temps de réponse de bout en bout de « 70 ms à 500 ms », contre ce qu'il a mesuré comme « 3 à 329 secondes » pour les modèles de langage frontière auxquels il a comparé Jev.
• TypeSafe prix les jetons d'entrée à « 0,042 $ / MTok », les jetons de sortie étant répertoriés comme gratuits.
• Lors de ses propres évaluations de flux de travail, TypeSafe rapporte que Jev fonctionne « 193,6 fois plus rapidement, 444,6 fois moins cher » que les politiques par rapport auxquelles il a été mesuré.
• TypeSafe décrit une erreur de type dans la sortie de Jev comme, selon ses termes, « mathématiquement impossible ».
• Jev est en accès anticipé ; TypeSafe affirme qu'il retire les développeurs "de la liste d'attente aussi rapidement que possible".

Génération contre décision

Une grande partie de ce que l’on appelle « l’IA en production » n’est pas du tout une tâche d’écriture. Autoriser ou bloquer une connexion. Escalader ou clôturer un ticket. Marquer ou effacer une transaction. Acheminez un message vers une file d’attente ou une autre. Le résultat souhaité n’est pas de la prose, c’est une étiquette tirée d’une liste courte et fixe, parfois accompagnée d’une partition. Poser ce genre de question à travers un modèle conçu pour produire des paragraphes fluides est une inadéquation : un blob JSON revient qui doit être analysé et espéré pour être valide, et toute confiance déclarée a tendance à signifier peu de choses en particulier, car rien ne l'oblige à suivre le taux d'erreur réel du modèle.

Deux affirmations méritent d'être séparées ici, car elles ne sont pas la même chose : tapées et calibrées. Une sortie tapée contraint la forme de la réponse : une question « à choix » renvoie l'une des options de la liste, un « score » renvoie un nombre à l'intérieur d'une plage déclarée, jamais une phrase parasite ou un champ inventé. L’étalonnage est une idée beaucoup plus ancienne et totalement distincte. Il s'agit d'une propriété statistique et non stylistique : cela signifie que lorsque le système indique une probabilité de 0,62, c'est souvent à peu près cela dans de nombreuses prédictions similaires, de sorte qu'un programme en aval peut en fait définir un seuil sur ce nombre au lieu de le traiter comme une décoration.

Le nom propre de TypeSafe emprunte son vocabulaire à la psychologie plutôt qu'aux statistiques. Daniel Kahneman, qui a reçu le prix Nobel d'économie en 2002 "pour avoir intégré les connaissances de la recherche psychologique dans la science économique, en particulier concernant le jugement humain et la prise de décision dans l'incertitude", a popularisé les termes dans Penser, vite et lentement : "Le système 1" est "rapide, automatique, fréquent, émotionnel, stéréotypé, inconscient", tandis que le "Système 2" est "lent, exigeant, peu fréquent, logique, calculateur, conscient". La métaphore est évocatrice, mais elle décrit la cognition humaine et non une garantie concernant un logiciel. Un modèle peut être rapide comme le système 1 l'est, sans que sa confiance déclarée ne signifie quoi que ce soit : l'étalonnage doit être gagné et mesuré, et non impliqué par un nom.

Ce que « ne peut pas halluciner » peut et ne peut pas signifier

L'affirmation de TypeSafe selon laquelle une erreur de type est « mathématiquement impossible » décrit le décodage contraint, une technique qui existe déjà ailleurs. Le propre guide des sorties structurées d'OpenAI offre une garantie similaire : la fonctionnalité, dit-il, "garantit que le modèle générera toujours des réponses qui adhèrent à votre schéma JSON fourni, vous n'avez donc pas à vous soucier du fait que le modèle omet une clé requise ou hallucine une valeur d'énumération invalide." Cette garantie est réelle et utile. Il est également plus restreint qu’il n’y paraît : il contraint la forme de la réponse, et non son caractère exact. Une question « à choix » avec trois options renverra toujours l'une des trois - y compris, si le modèle a mal évalué l'entrée, une mauvaise réponse sûre, valablement saisie.

L'étalonnage est la pièce qui doit être vérifiée et non affirmée. L'outil standard est un diagramme de fiabilité : les prédictions de tranche en fonction de leur niveau de confiance déclaré, et pour chaque tranche, tracez la fréquence à laquelle ces prédictions se sont réellement avérées exactes ; l'écart entre la diagonale et la ligne observée est généralement résumé comme une erreur d'étalonnage attendue. Ce n'est pas une question nouvelle pour l'apprentissage automatique : Article de Guo et al. de 2017 « Sur l'étalonnage des réseaux de neurones modernes » a découvert que "les réseaux de neurones modernes... sont mal calibrés" par défaut et qu'une solution simple à un seul paramètre appelée mise à l'échelle de la température était "étonnamment efficace" pour le réparer. La leçon se généralise au-delà de cet article : l’étalonnage n’est pas une propriété qu’un modèle peut annoncer sur lui-même. C'est quelque chose que vous vérifiez sur vos propres données étiquetées, car elles ont tendance à se dégrader exactement là où vous en avez le plus besoin – sur des entrées qui ne ressemblent en rien à celles sur lesquelles le modèle a été réglé.

Un harnais d'évaluation minimal (modèle)

Avant d'acheminer une décision réelle via un modèle de décision, Jev ou autre, trois questions comptent plus que n'importe quel chiffre du fournisseur : la réponse tapée est-elle analysée à chaque fois par rapport à votre schéma, une confiance déclarée suit-elle son taux de réussite réel sur un échantillon étiqueté de vos propres données, et cet étalonnage survit-il sur des entrées qui diffèrent de tout ce que le modèle a déjà vu. Le croquis ci-dessous est un modèle construit autour de la forme de requête présentée dans la documentation de démarrage rapide de TypeSafe. Il ne prétend pas ce que montrerait son exécution contre Jev - nous ne l'avons pas exécuté, et il s'agit d'un pseudo-code illustratif, pas d'un rapport.

# Illustrative pseudo-code. Mirrors the request shape shown in TypeSafe's own
# quickstart docs (POST /v1/systemone with state, model, and typed questions).
# Not run against Jev or any live API; no results are claimed here.
import requests

def ask(state: str, question_id: str, question: dict) -> dict:
    resp = requests.post(
        "https://api.typesafe.ai/v1/systemone",
        headers={"Authorization": f"Bearer {API_KEY}"},
        json={"state": state, "model": "jev-latest", "questions": {question_id: question}},
    )
    return resp.json()["answers"][question_id]

# 1. Shape check: does every response parse against the declared type, on your
#    own edge cases, not just a vendor demo set?
# 2. Calibration check: bucket the stated confidence and compare it to the
#    true label rate, on data the model has never seen.
buckets = {i: {"n": 0, "correct": 0} for i in range(10)}
for state, true_label in labeled_sample:          # your own traffic, labeled by hand
    answer = ask(state, "decision", {"type": "noul", "instructions": "Should this be allowed?"})
    bucket = min(int(answer["noul"] * 10), 9)
    buckets[bucket]["n"] += 1
    buckets[bucket]["correct"] += int(round(answer["noul"]) == true_label)

for b, s in buckets.items():
    if s["n"]:
        stated = (b + 0.5) / 10
        observed = s["correct"] / s["n"]
        print(f"stated~{stated:.2f}  observed={observed:.2f}  n={s['n']}")  # the gap here is your calibration error

• Si la réponse saisie analyse toujours les entrées produites par votre propre système, pas seulement l'ensemble de démonstration d'un fournisseur.
• Si un 0,9 indiqué est correct environ neuf fois sur dix sur votre propre trafic étiqueté, et non sur l'ensemble d'évaluation de quelqu'un d'autre.
• Si cet étalonnage tient sur des entrées contrairement à tout ce qu'il a vu auparavant : une nouvelle application, un nouveau protocole, un expéditeur qui a lu la même annonce que vous venez de lire.
• Ce que fait l'appelant en cas d'expiration ou de panne, car un système de décision a besoin d'une valeur par défaut sûre lorsque le modèle de décision est inaccessible.

Pourquoi c'est important pour les outils de sécurité

Un pare-feu, un filtre anti-spam, un contrôle anti-fraude, une file d'attente de triage : chacun d'eux est un système de décision, répondant encore et encore au même type de question : étant donné cette entrée, autorisez-la ou bloquez-la, avec quel degré de confiance et où se situe le seuil. La propre page d'évaluation de TypeSafe tire ses exemples exactement de ce territoire : décider s'il faut fermer une alerte de sécurité, la transmettre à une personne ou la contenir immédiatement est une décision de triage, pas une tâche d'écriture, et c'est le genre d'appel qu'un outil de sécurité fait constamment, à un volume qu'aucun analyste ne pourrait examiner manuellement.

Honnêtement, le compromis en matière de confidentialité

Jev, comme le décrit TypeSafe, est une API hébergée : une requête transporte un "état", c'est-à-dire quelles que soient les données sur lesquelles porte la question, vers les serveurs de TypeSafe sur Internet. Pour les exemples d'incidents de sécurité et de tri que TypeSafe lui-même met en évidence, cet état est exactement le type d'informations que de nombreuses personnes préféreraient ne pas transmettre par défaut à un tiers : quelle application parle à quelle adresse, à quelle fréquence, à partir de quel appareil. Les envoyer vers n’importe quel modèle de cloud, aussi rapide ou bon marché soit-il, signifie que les données quittent la machine d’où elles proviennent.

FireAI, le pare-feu macOS de HisnLabs, a fait le choix inverse pour la catégorie exacte de décision sur laquelle porte cet article. FireAI fonctionne sur macOS 14 ou version ultérieure sur silicium Apple, pour un montant unique de 49 €, et n'est explicitement ni un antivirus ni un VPN. Lorsqu'une application que vous n'avez pas vue auparavant tente d'atteindre le réseau, FireAI peut exécuter un petit modèle sur l'appareil lui-même (un téléchargement facultatif de 1,5 Go) pour examiner cette connexion et vous demander une raison en langage clair en pièce jointe ; le trafic examiné n’est jamais envoyé nulle part. Chacune de ces décisions assistées par l'IA devient une règle visible, liée à la signature de code de l'application, que vous pouvez voir et annuler, aux côtés de flux de menaces appliqués localement plutôt que interrogés sur un serveur distant.

Nous ne prétendons pas que le modèle intégré de FireAI correspond à Jev, ou à tout autre modèle de système unique, en termes d'exactitude brute, de vitesse ou de prix - nous n'avons pas effectué cette comparaison et n'avons aucune évaluation à publier ici. Ce que cette annonce soutient, c'est une orientation de conception : qu'une décision de sécurité est bien servie par un petit modèle rapide et limité fonctionnant à proximité des données, plutôt que par un routage via un chatbot à usage général ailleurs. TypeSafe fait valoir ce point du côté de l'API ; FireAI s'appuie déjà sur cela du côté de l'appareil, et pour une raison différente : pour un pare-feu en particulier, les données en question ne devraient pas du tout avoir à quitter la machine pour être jugées.

Questions ouvertes

• Évaluations indépendantes : aucun tiers n'a encore publié une reproduction des multiples de vitesse ou de coût dans l'annonce de TypeSafe, sur des données que TypeSafe n'a pas choisies.
• Calibrage sous changement de distribution – le scénario exact sur lequel porte l’article de Guo et al., et celui qui compte le plus contre un adversaire qui s’adapte une fois qu’une méthode de défense est publique.
• Si le prix tient au volume de production réel et si la latence déclarée tient sous une charge soutenue plutôt que sous une seule demande démontrée.
• Comment le modèle se comporte face à des entrées contradictoires ou véritablement ambiguës, où une réponse tapée avec confiance peut être moins honnête qu'une réponse indiquant « peu claire ».
• Lorsque l'accès anticipé s'ouvre au-delà de la liste d'attente, à qui et dans quelles conditions pour les données envoyées en tant qu'« état ».

Pour l'instant, Jev est un ensemble de revendications d'une équipe avec de véritables références et aucune vérification extérieure pour le moment. La catégorie qu’il tente de nommer, les modèles de décision plutôt que les modèles de génération, souligne une réelle lacune dans la manière dont les logiciels de sécurité ont été conçus jusqu’à présent pour utiliser l’IA. Que Jev résiste ou non aux tests indépendants, cela rappelle utilement que la question intéressante pour un pare-feu, un filtre anti-fraude ou une file d'attente de triage n'a jamais été "peut-il écrire une phrase convaincante" mais "peut-il prendre une décision qu'il peut soutenir, assez rapidement pour avoir de l'importance". C'est la question que nous posons à propos du modèle intégré à l'appareil dans FeuAI chaque fois que nous le modifions – et c'est pourquoi, pour nous, la réponse reste sur l'appareil plutôt que de devenir une requête adressée à l'API de quelqu'un d'autre.

Le rôle de FireAI et de HisnLabs

We have not tested Jev and make no claim it works as described or that FireAI matches it in any way — but the idea that a security decision deserves a small, bounded, fast model instead of a paragraph from a chatbot is one we built FireAI around a year before TypeSafe wrote a blog post about it.

FireAI est le produit de HisnLabs : un pare-feu IA embarqué pour Mac. Il montre en langage clair chaque connexion faite par vos applications et vous laisse décider ce qui sort de votre Mac — son IA fonctionne en local, votre trafic ne nous est jamais envoyé, ni à personne d’autre. L’équipe de recherche en sécurité de HisnLabs est celle qui garde ces décisions fiables : elle recense les domaines de simple télémétrie face à ceux d’un vrai service, suit le pays et le réseau derrière une connexion, et entraîne le modèle embarqué (la fonction Autopilot) sur du trafic réel, sans que rien ne quitte votre Mac.

Vous pouvez lire les choix techniques qui s’y trouvent, ou essayer FireAI pendant 17 jours, sur FireAI, par HisnLabs.