Tous les articles
IA & dev

Jev ou GLiDE : quel modèle de décision choisir (et lequel est open source) ?

Par Elouan Laurent

Jev et GLiDE : deux modèles qui décident au lieu d'écrire

Jev et GLiDE sont des modèles de décision. Ils ne génèrent pas de texte. Vous leur donnez un état (un ticket, un log, un JSON) et une liste d'options que vous avez définies. Ils renvoient l'option retenue, une probabilité pour chaque option et un score de confiance.

Jev a ouvert la catégorie. TypeSafe AI l'a lancé le 15 septembre 2026. La société a été fondée par Diogo Almeida, ancien chercheur d'OpenAI, avec Erik Gafni et Sasha Sheng.

GLiDE (Generalized Lightweight Decision Engine) a suivi le 30 septembre 2026, chez Fastino Labs, l'éditeur des modèles d'extraction GLiNER. Il reprend l'interface de Jev et y ajoute une étape de raisonnement.

Deux confusions circulent déjà :

  • GLiDE n'est pas un modèle de Jev. Ce sont deux produits concurrents, de deux sociétés différentes.
  • Aucun des deux n'est open source. Ils s'utilisent par API, et leurs poids ne sont pas publiés. Il existe des modèles de décision ouverts : ils ont leur section plus bas.

Modèle de décision : à quoi ça sert face à un LLM ?

Un LLM répond par du texte libre. Pour en tirer une décision, votre code doit l'analyser, le valider et gérer les réponses hors format. Un modèle de décision supprime cette étape : la réponse a toujours la forme attendue.

TypeSafe appelle Jev un modèle « System One ». Le nom vient de Système 1 / Système 2 de Daniel Kahneman : le Système 1, c'est la pensée rapide et intuitive. Le Système 2, le raisonnement lent, est celui que poursuivent les grands LLM.

Les deux modèles proposent les trois mêmes types de questions :

  • Noul : une question oui/non, qui renvoie la probabilité que la réponse soit « oui » ;
  • Choice : une option parmi une liste que vous fournissez ;
  • Score : un niveau sur une échelle ordonnée, par exemple une gravité de 1 à 5.

Les cas d'usage visés se recoupent : router un ticket ou un agent IA vers le bon outil, modérer un contenu, bloquer une action risquée, vérifier la sortie d'un autre modèle. Les deux éditeurs renvoient à un LLM classique tout ce qui demande de rédiger, résumer ou générer du code.

Pour un CTO, l'intérêt tient dans la probabilité. On automatise les cas sûrs et on envoie les cas ambigus à un humain, avec un seuil qu'on règle soi-même.

Jev : rapide, peu cher, et honnête sur ses limites

TypeSafe met en avant la vitesse et le prix. L'éditeur annonce une latence de 70 à 500 millisecondes de bout en bout. Sur ses propres flux de test, il mesure Jev jusqu'à 193,6 fois plus rapide et 444,6 fois moins cher qu'un grand LLM comparable. Ce sont des chiffres de l'éditeur, sur ses propres scénarios.

Ce que j'apprécie le plus chez TypeSafe, c'est une page de sa documentation consacrée aux défauts connus de Jev 1.13. L'éditeur y liste ce que son modèle fait mal :

  • le calcul et le comptage : « Jev n'est pas une calculatrice », la logique numérique doit rester dans le code ;
  • la comparaison de dates : Jev lit les dates comme du texte, pas comme des valeurs ordonnées ;
  • les raisonnements en plusieurs étapes et les doubles négations ;
  • les états volumineux remplis de détails sans rapport avec la question ;
  • les contenus malveillants écrits pour orienter la réponse.

Sa consigne est claire : le modèle juge, le code calcule. On lui fait extraire le mois et l'année d'un contrat, et c'est Java qui compare les dates.

Deux autres points comptent pour une entreprise. Jev ne se fine-tune pas : les mêmes poids servent tous les clients, et on l'adapte par la requête. Et l'anglais est sa langue principale ; les autres langues sont prises en charge, « mais pas aussi bien », d'après TypeSafe.

GLiDE : la réponse de Fastino, qui ajoute du raisonnement

GLiDE vise exactement les faiblesses que TypeSafe documente. Il fait d'abord une évaluation rapide. Si la réponse est incertaine, il prend un temps de raisonnement supplémentaire, puis l'intègre dans les probabilités finales.

Fastino le présente comme le premier modèle de décision « qui réfléchit ». D'après l'annonce de GLiDE, cette étape sert les décisions qui dépendent de calculs, de code, de dates ou de plusieurs faits liés.

Pour le prouver, Fastino a lancé l'évaluateur du Decision Index, la suite de tests de Jev. Sa version 0.2.1 couvre près de quarante bancs de test, en cinq domaines : outils et automatisation, recherche et classification, compréhension du langage, connaissances et raisonnement, arts et goût humain.

Mesure GLiDE Jev
Score global (Decision Index 0.2.1) 64,81 57,91
Outils et automatisation 83,5 75,1
Connaissances et raisonnement 62,9 51,4
CLadder (raisonnement causal) 88,7 % 72,6 %
CRUXEval (exécution de code) 92,6 % 73,0 %

D'après Fastino, GLiDE devance Jev dans les cinq domaines et sur 31 bancs sur 38.

Trois réserves avant d'en tirer une conclusion :

  1. Ce sont des chiffres de l'éditeur. Fastino compare son propre passage de l'évaluateur au score publié de Jev. GLiDE ne figure pas sur le classement public du Decision Index, dont les soumissions pour la version 0.2.1 sont suspendues. BenchLM, un agrégateur de benchmarks, le laisse aussi hors de son classement : toutes ses lignes viennent du rapport de Fastino.
  2. Les écarts les plus nets portent sur le raisonnement. C'est le terrain que TypeSafe reconnaît comme faible pour Jev. Sur du tri simple, là où Jev est à l'aise, l'avance peut fondre.
  3. Le raisonnement a un prix. Fastino ne publie aucune latence pour GLiDE, et un modèle qui prend le temps de réfléchir sur les cas difficiles ne répond pas en temps constant. Je n'ai mesuré aucun des deux modèles moi-même.

Jev ou GLiDE : prix et limites au 2 octobre 2026

Relevé dans la documentation de TypeSafe et la page tarifs de Fastino le 2 octobre 2026 :

Jev 1.13 (TypeSafe) GLiDE (Fastino)
Entrée, par million de tokens 0,042 $ 0,30 $
Sortie gratuite gratuite
Contexte 64 000 tokens par requête, 32 000 pour l'état plus la plus longue question 40 000 tokens par question (état plus question)
Options par question 255 au maximum 255 au maximum
Latence publiée 70 à 500 ms non publiée
Fine-tuning non non
Poids publiés non non
SDK officiels Python, JavaScript aucun, appel HTTP direct

À volume égal, GLiDE coûte environ sept fois plus cher en entrée. Et l'écart réel peut être plus grand : Fastino précise que les tokens d'entrée facturés additionnent toutes les passes internes de chaque question. Le compteur peut donc dépasser la taille de votre requête.

Côté exploitation, TypeSafe prévient que ses limites de débit (100 000 tokens et 40 requêtes par seconde) peuvent changer sans préavis tant que la demande dépasse ses capacités. Il ne s'entraîne pas sur les requêtes de ses clients et propose la rétention zéro (zero data retention) aux comptes entreprise.

Sécurité : un format typé n'est pas une protection

Le 24 septembre 2026, Check Point a publié un test d'injection de prompt contre Jev. Le scénario : une application d'analyse d'investissement, où un rapport piégé doit faire passer une société frauduleuse de « risque élevé » à « risque faible ».

Toutes les configurations testées ont fini par céder, pour environ 0,50 $ par attaque réussie. Ajouter des consignes anti-injection n'a presque rien changé. La conclusion de Check Point : « ne confondez pas un format de sortie avec une frontière de sécurité ».

GLiDE n'a pas été testé, mais rien dans son architecture ne le met à l'abri : il lit l'état comme du texte, comme Jev. TypeSafe le reconnaît d'ailleurs dans sa liste de défauts. La protection se construit autour du modèle : filtrer ce qui entre dans l'état, et garder une validation humaine sur les décisions à fort enjeu.

Appeler Jev ou GLiDE depuis Spring Boot

Les deux modèles exposent la même route, POST /v1/systemone, avec la même structure : un state, des questions nommées, des answers aux mêmes clés. Aucun n'utilise l'interface /v1/chat/completions des LLM : un client compatible OpenAI ne servira à rien ici.

Le même code Java sert donc les deux. Seuls l'URL, la clé et le nom du modèle changent, et Fastino accepte l'en-tête Authorization: Bearer de TypeSafe :

// Jev :   https://api.typesafe.ai, modèle "jev-latest"
// GLiDE : https://api.fastino.ai,  modèle "fastino/GLiDE"
RestClient decisions = RestClient.builder()
    .baseUrl(baseUrl)
    .defaultHeader("Authorization", "Bearer " + apiKey)
    .build();

Map<String, Object> request = Map.of(
    "model", model,
    "state", "Refund request: the receipt is attached, the purchase was 10 days ago, "
        + "and refunds are allowed within 30 days.",
    "questions", Map.of(
        "refund_allowed", Map.of(
            "type", "noul",
            "instructions", "Does this request qualify for a refund?",
            "criteria", Map.of("true", "Qualifies", "false", "Does not qualify"))));

JsonNode answer = decisions.post()
    .uri("/v1/systemone")
    .contentType(MediaType.APPLICATION_JSON)
    .body(request)
    .retrieve()
    .body(JsonNode.class)
    .path("answers").path("refund_allowed");

double pYes = answer.path("noul").asDouble();          // probabilité du « oui »
double confidence = answer.path("confidence").asDouble();

Avec Spring Boot 4, JsonNode vient de Jackson 3 (tools.jackson.databind).

Deux points à retenir dans la réponse :

  • noul est une probabilité, pas un booléen. Les deux éditeurs insistent : 0,5 n'est pas forcément le bon seuil métier. Réglez-le sur des données réelles.
  • confidence mesure la certitude du modèle, dans un sens ou dans l'autre. C'est ce champ qui décide du passage à un humain.

Quelques différences à gérer si vous passez de l'un à l'autre :

  • les codes à réessayer : 429 et 529 chez TypeSafe, 425, 429 et 503 chez Fastino ;
  • le délai de lecture : Fastino recommande au moins 300 secondes, car un cas difficile peut déclencher une longue réflexion ;
  • la validation : GLiDE exige un texte non vide dans chaque champ instructions et rejette en erreur 422 les champs qu'il ne connaît pas.

Un client écrit pour Jev doit donc être relu, pas seulement reconfiguré. Fastino publie d'ailleurs un guide de migration depuis TypeSafe : la cible commerciale est claire.

Les exemples des deux documentations sont en anglais, et les deux éditeurs présentent l'anglais comme leur langue de référence. Je n'ai testé aucun des deux sur des tickets en français : vérifiez-le sur votre propre corpus.

Et en open source ? GLiNER2.5-Decide

Si vous cherchiez un modèle de décision à héberger vous-même, ni Jev ni GLiDE ne conviennent. L'option la plus aboutie aujourd'hui s'appelle GLiNER2.5-Decide. Fastino l'a publiée le 24 septembre 2026, sous licence Apache 2.0 : usage commercial, modification et déploiement hors ligne autorisés.

C'est un modèle d'un autre gabarit : 340 millions de paramètres. Sa fiche Hugging Face le dit clairement : il ne raisonne pas, n'explique pas et ne répond pas aux questions ouvertes. Il classe : intention d'un client, routage d'un e-mail, sentiment, urgence, modération.

Ses chiffres, publiés par Fastino :

  • 60,2 % de précision moyenne sur fast-decisions, une suite de 17 domaines créée par Fastino. JevK5, une reproduction ouverte de Jev (et non le modèle de TypeSafe), y obtient 57,6 % ;
  • 167 ms de latence médiane sur CPU (un Xeon de 48 cœurs virtuels), 38 ms sur un GPU NVIDIA V100.

Il s'installe en une commande (pip install gliner2). Une variante multilingue de 287 millions de paramètres, GLiNER2.5-multi-Decide, est aussi sous Apache 2.0 : c'est elle qu'il faut évaluer pour du français.

Mon avis : trois profils, trois réponses

Les modèles de décision ne remplacent pas les LLM. Ils remplacent un usage précis des LLM : celui où l'on demande à un modèle génératif de choisir dans une liste, puis où l'on espère qu'il réponde dans le bon format.

Le choix entre les trois se fait sur la nature de vos décisions :

  • Du tri en volume, où la vitesse et le prix comptent (tickets, modération, routage) : Jev, avec les calculs et les dates gardés dans votre code, comme TypeSafe le recommande.
  • Des décisions qui demandent du raisonnement (règles croisées, contrats, contrôle d'actions d'agent) : GLiDE, en acceptant un prix sept fois plus élevé et une latence non garantie.
  • Des données qui ne doivent pas quitter votre réseau : GLiNER2.5-Decide, sur vos serveurs, pour du tri uniquement.

Avant de trancher, je ferais trois choses :

  1. Construire un jeu de test de quelques centaines de décisions réelles, avec la bonne réponse connue.
  2. Mesurer les trois candidats sur ce jeu. Les benchmarks des éditeurs ne remplacent pas vos données.
  3. Chiffrer le coût par décision et non par million de tokens, puisque les passes de réflexion de GLiDE gonflent le compteur d'entrée.

Vous voulez brancher un modèle de décision ou un agent IA sur une application Java / Spring Boot existante ? Je développe sur cette stack depuis 2015. Réserver un appel découverte de 30 minutes.

À lire ensuite