Jev : 5 prompts pour cette IA… 400 fois moins chère que les autres
Pourquoi personne n’y a pensé avant ? C’est la question que laisse Jev, nouveau modèle d’IA dévoilé mis-septembre par l’entreprise américaine TypeSafe AI. Basé sur un entraînement d’un genre entièrement nouveau, Jev promet d’automatiser réellement le software pour un prix modique. TypeSafe AI parle d’un coût global jusqu’à 444 fois inférieur et 193 fois plus rapide qu’un LLM généraliste. Le modèle serait également beaucoup plus déterministe (et donc fiable) avec un déploiement ridiculement simple à mettre en place. Explications et cas d’usage.
Il était une fois TypeSafe AI
TypeSafe AI est lancé en 2024 par Diogo Almeida (CEO), ancien d’OpenAI, Sasha Sheng (COO), ex Meta FAIR, et Erik Gafni (CTO) spécialiste du machine learning. L’idée de base est en toute modestie de développer une intelligence artificielle générative capable de réellement révolutionner le monde de l’entreprise. Diogo Almeida a travaillé sur la première version de ChatGPT et spécifiquement sur le RLHF, cette technique qui permet d’enseigner aux LLM les préférences humaines. Et c’est justement ce principe même que le CEO remet aujourd’hui en question.
Pour Diogo Almeida, les LLM généralistes ne sont pas conçus pour l’automatisation et l’autonomie mais pour répondre correctement aux humains. Partant de là, il se lance dans le développement d’une nouvelle technique d’entraînement pour conditionner le modèle à prendre une décision structurée avec une probabilité de confiance exploitable par un logiciel. Cette nouvelle architecture verra le jour sous le nom de RLCD pour Reinforcement Learning for Calibrated Decisions. C’est cette nouvelle architecture qui sous-tend Jev, le modèle publié le 15 septembre dernier.
Comment fonctionne Jev ?
Derrière Jev se cache un modèle entraîné en RLCD. TypeSafe AI reste pour l’heure peu bavard (pour ne pas dire muet) sur l’architecture technique exacte du modèle. On sait toutefois que contrairement à un LLM, qui construit sa réponse étape par étape, Jev peut calculer plusieurs réponses en une seule fois. Par exemple, s’il doit déterminer à la fois si une facture est frauduleuse, si le fournisseur est fiable et quel est son niveau de risque, ces trois décisions peuvent être prises simultanément plutôt que l’une après l’autre. C’est ce qui explique en grande partie sa rapidité d’exécution. Principale différence avec un LLM, Jev ne peut pas être prompté en langage naturel. Le modèle requiert un prompt structuré avec des arguments clairs. Jev doit être vu comme un moteur d’intelligence déterministe.
Il est par définition impossible de lui demander de générer du texte. Le prompt structuré prend en entrée le modèle appelé et deux arguments de fond : le state, à savoir le contexte que vous souhaitez ajouter à votre demande (un document, une facture, un email…), et les questions. Les questions doivent impérativement être fermées. Il est possible de demander au modèle de choisir parmi plusieurs options ou de répondre par oui ou par non. C’est aussi simple que cela.
En sortie, le modèle répond par trois types d’arguments possibles :
- Noul retourne une probabilité entre 0 et 1
- Choice choisit une option parmi une liste fermée, avec des probabilités
- Score retourne un score pondéré sur un niveau défini (dans le prompt initial)
Le plus parlant reste un exemple, très simple. Disons que nous souhaitons router les mails arrivant dans un service informatique d’une entreprise. Nous mettons donc en place un prompt d’entrée du type :
{
"model": "jev-latest",
"state": "Je n'arrive plus à me connecter à mon ordinateur depuis ce matin. Mon mot de passe semble refusé et j'ai une présentation dans 20 minutes.",
"questions": {
"service": {
"type": "choice",
"instructions": "Quel service doit traiter cette demande ?",
"criteria": {
"IT": "Problèmes informatiques, accès, logiciels, matériel ou mots de passe",
"RH": "Congés, contrats, paie ou questions liées aux salariés",
"Comptabilite": "Factures, dépenses ou paiements",
"Communication": "Presse, communication interne ou externe"
}
}
}
}
Jev répondrait alors, très probablement :
{
"model": "jev-1.13.0",
"answers": {
"service": {
"type": "choice",
"choice": "IT",
"confidence": 0.99,
"probabilities": {
"IT": 0.99,
"RH": 0.004,
"Comptabilite": 0.002,
"Communication": 0.004
}
}
},
"usage": { "input_tokens": 296, "output_tokens": 20 }
}
La vraie différence avec un classifier en machine learning repose sur la généralisation des cas. Le modèle n’a pas besoin d’être entraîné sur une tâche donnée pour répondre. Il est généraliste. Et contrairement aux LLM, il ne peut pas halluciner une réponse hors du format demandé. L’aspect déterministe et probabiliste est certainement le second maillon manquant actuellement à l’IA générative pour infuser réellement dans le software. Le premier étant le coût (lire ci-après).
L’important est de bien comprendre que Jev ne s’utilise pas dans une interface classique : il est conçu nativement pour s’intégrer dans un workflow, avec à la clef des conditions (if, else…).
Selon ses propres benchmarks (les benchmarks classiques étant encore peu adaptés à ce nouveau type de modèle), Jev produit des résultats proches des modèles frontières. Le test consistait à comparer les modèles sur plusieurs workflows concrets, notamment dans le service client, le traitement de factures, la cybersécurité ou encore l’analyse de traces d’agents. En moyenne, Jev est parvenu à 67,8% de précision contre 67,9% pour GPT-5.6 Terra, 74,1% pour GPT-5.6 Sol et 73,1% pour Claude Opus 5. Mais quand Claude Opus 5 met environ 37,8 secondes pour répondre, Jev en met 0,4.
Un pricing défiant toute concurrence
Le prix est l'autre point fort de Jev. Comme le modèle n’a pas besoin de calculer chaque token de manière autorégressive, il demande logiquement beaucoup moins de puissance de calcul. En résultent des prix inédits pour un modèle génératif. Jev ne facture que les tokens en entrée et jamais à la sortie. Le tarif est de 42 dollars par milliard de tokens.
Concrètement, pour une requête d’automatisation contenant 2 000 tokens, Jev revient à moins de 0,0001 dollar. A volume égal, GPT-5.6 Terra coûterait, selon nos estimations, autour de 55 fois plus cher et GPT-5.6 Sol une centaine de fois plus, même en limitant fortement leur génération de texte. Même avec une requête très lourde de 100 000 tokens, Jev ne coûterait que 0,0042 dollar, soit moins d’un demi-centime.
5 cas d’usage
On le comprend, Jev est donc l’IA idéale pour prendre une décision structurée à partir d’un contexte donné. Il est peu cher, rapide et surtout déterministe donc relativement fiable. Le but est de lui confier des missions qui attendent une réponse sûre, avec un vrai niveau d’intelligence.
Trier automatiquement des mails en lot
On peut par exemple faire trier sa boîte de réception non seulement en fonction de l’urgence d’un mail mais également du contexte. Une fois les scores retournés par Jev, un script déterministe applique alors des filtres directement sur la boîte. Pour un coût largement inférieur aux LLM.
Exemple de prompt :
{
"model": "jev-latest",
"state": {
"from": "{{FROM}}",
"to": ["{{TO}}"],
"subject": "{{SUBJECT}}",
"date": "{{DATE_ISO}}",
"thread_length": "{{THREAD_LENGTH}}",
"is_reply_to_me": "{{BOOL}}",
"body": "{{BODY_TRONQUE_2000_CARACTERES}}"
},
"questions": {
"priority": {
"type": "score",
"instructions": "{{USER_CONTEXT}} Quelle est la priorité de traitement de ce mail pour cette personne ?",
"criteria": [
"Aucune : envoi automatique, promotionnel ou de masse, sans lien avec son activité",
"Basse : information utile à connaître, mais aucune action ni échéance",
"Moyenne : demande une action ou une réponse, sans date butoir proche",
"Haute : échéance sous 48h, ou quelqu'un attend cette réponse pour avancer",
"Critique : échéance du jour, incident en cours, ou expéditeur dont dépend un engagement pris"
]
},
"category": {
"type": "choice",
"instructions": "{{USER_CONTEXT}} Dans quelle catégorie ranger ce mail ?",
"criteria": {
"core_work": "Relève directement de l'activité principale de cette personne, telle que décrite dans son contexte.",
"interne": "Collègues, hiérarchie, équipe : coordination, planning, suivi de production.",
"externe": "Interlocuteur extérieur légitime : client, partenaire, fournisseur, contact établi.",
"sollicitation": "Démarchage non sollicité : prospection commerciale, pitch, recrutement, invitation générique.",
"admin": "Facturation, contrats, RH, outils, logistique, sécurité du compte.",
"automatique": "Notification système, newsletter, abonnement, alerte générée par un service.",
"other": "Rien de ce qui précède."
}
},
"needs_reply": {
"type": "noul",
"instructions": "Ce mail attend-il une réponse écrite du destinataire ? Une simple information ou un envoi de masse n'en attend pas."
},
"has_deadline": {
"type": "noul",
"instructions": "Le mail mentionne-t-il une échéance datée qui engage le destinataire ?"
},
"is_relevant": {
"type": "noul",
"instructions": "{{USER_CONTEXT}} Le sujet de ce mail relève-t-il de ce qui intéresse cette personne ?"
},
"is_suspicious": {
"type": "noul",
"instructions": "Ce mail présente-t-il des signes d'hameçonnage ou d'usurpation : urgence artificielle, demande de identifiants ou de paiement, expéditeur incohérent avec le contenu ?"
}
}
}
Il suffit de remplacer USER_CONTEXT par deux ou trois phrases décrivant votre rôle et les mails génériques qui vous intéressent, avec quelques exemples et le tour est joué.
Orchestrer un prompt vers le bon modèle d’IA
Rares sont les agents de code à choisir un modèle dédié en fonction du prompt initial. Dans Claude Code ou Codex, le modèle par défaut est appelé de manière déterministe sans réflexion, qu’importe la tâche demandée. Jev, via un hook, peut décider quel modèle choisir en fonction du prompt initial en une fraction de seconde. On économise ainsi de nombreux tokens, à coup sûr. Le hook remplit lui-même le contexte à chaque requête : le prompt de l’utilisateur, la nature du dépôt, les fichiers ouverts et la profondeur de la session en cours.
Exemple de prompt :
{
"model": "jev-latest",
"state": {
"prompt": "{{PROMPT_UTILISATEUR}}",
"repo": { "langages": ["{{LANGAGES}}"], "fichiers": "{{NOMBRE_DE_FICHIERS}}" },
"fichiers_ouverts": ["{{FICHIERS_OUVERTS}}"],
"historique_session": "{{NOMBRE_DE_TOURS}}"
},
"questions": {
"model": {
"type": "choice",
"instructions": "Quel modèle doit traiter cette requête, au coût le plus bas qui suffit ?",
"criteria": {
"haiku-4-5": "Tâche mécanique et locale : renommage, formatage, regex, commit message, lecture d'un fichier court.",
"sonnet-5": "Tâche de code standard et bien cadrée : un bug identifié, un test à écrire, un refactor sur quelques fichiers.",
"opus-5": "Tâche complexe ou mal cadrée : cause racine inconnue, refonte d'architecture, dette technique transverse, raisonnement long.",
"fable-5-1": "Tâche demandant la capacité maximale : algorithmique difficile, optimisation de perf non triviale, debug d'une interaction système obscure."
}
},
"reasoning": {
"type": "score",
"instructions": "Quelle profondeur de raisonnement la tâche exige-t-elle avant d'écrire du code ?",
"criteria": [
"Aucune : l'action à faire est explicite dans la requête",
"Faible : une ou deux inférences évidentes",
"Moyenne : il faut relier plusieurs fichiers ou hypothèses",
"Élevée : cause racine inconnue, plusieurs pistes à éliminer"
]
}
}
}
Trier des CV pour un poste dédié
Les entreprises utilisant des LLM pour trier des CV en fonction de leur affinité avec une fiche de poste ont tout intérêt à migrer vers Jev. C’est l’IA idéale pour pré-classifier des CV (l’AI Act impose un contrôle humain sur le tri des candidatures).
Exemple de prompt :
POST https://api.typesafe.ai/v1/systemone
{
"model": "jev-latest",
"state": {
"offre": "{{FICHE_DE_POSTE}}",
"cv": "{{CV_TEXTE_BRUT_ANONYMISE}}"
},
"questions": {
"adequation": {
"type": "score",
"instructions": "Dans quelle mesure ce CV correspond-il à l'offre ? Juger sur les compétences, l'expérience et le périmètre effectivement documentés dans le CV, au regard de ce que l'offre demande.",
"criteria": [
"Hors sujet : le CV relève d'un autre métier, aucun recouvrement avec l'offre",
"Faible : quelques compétences transférables, mais l'essentiel des attendus n'est pas couvert",
"Partielle : une partie significative des attendus est couverte, avec des manques nets",
"Bonne : la plupart des attendus sont couverts, à un niveau d'expérience cohérent",
"Forte : tous les attendus sont couverts, avec une expérience directe et consolidée sur le même périmètre"
]
},
"stade": {
"type": "choice",
"instructions": "Comment orienter ce dossier au vu de l'offre ?",
"criteria": {
"entretien": "Correspond à l'offre, à faire avancer.",
"a_revoir": "Profil partiel, atypique ou en reconversion : mérite une lecture humaine attentive.",
"hors_perimetre": "Ne concerne manifestement pas le métier décrit.",
"other": "Rien de ce qui précède."
}
},
"experience_suffisante": {
"type": "noul",
"instructions": "Le niveau d'expérience documenté atteint-il celui demandé par l'offre ?"
}
}
}
Audit de conformité à l’AI Act
Autre exemple : faire pré-classer par Jev les systèmes d’IA de votre entreprise. Faites générer par vos équipes, ou par vos agents, une description textuelle précise de chaque système : finalité, données traitées, personnes concernées, nature des sorties. Envoyez ensuite à Jev, dans un même état, les extraits de l’AI Act qui traitent de la classification (article 5, article 6, annexe III) et la description du système. Jev renvoie alors la catégorie concernée avec la probabilité de chacune.
{
"model": "jev-latest",
"state": {
"reference_juridique": {
"source": "Règlement (UE) 2024/1689, extraits de classification",
"article_5_pratiques_interdites": "{{TEXTE_ARTICLE_5}}",
"article_6_regles_classification": "{{TEXTE_ARTICLE_6}}",
"annexe_iii_domaines_haut_risque": "{{TEXTE_ANNEXE_III}}",
"definitions_fournisseur_deployeur": "{{TEXTE_ART_3_POINTS_3_ET_4}}"
},
"systeme_evalue": "{{DESCRIPTION_DU_SYSTEME}}"
},
"questions": {
"categorie": {
"type": "choice",
"instructions": "En appliquant uniquement le texte fourni dans reference_juridique, comment le systeme_evalue se classe-t-il ?",
"criteria": {
"interdit": "Correspond à une des pratiques listées à l'article 5 du texte fourni.",
"haut_risque_annexe_iii": "Relève d'un des domaines listés à l'annexe III du texte fourni, sans bénéficier d'une exception de l'article 6(3).",
"haut_risque_annexe_i": "Constitue un composant de sécurité d'un produit couvert par l'annexe I, au sens de l'article 6(1) du texte fourni.",
"exception_art_6_3": "Relève formellement d'un domaine de l'annexe III, mais entre dans une des exceptions prévues à l'article 6(3) du texte fourni.",
"hors_classification": "Ne correspond à aucune catégorie du texte fourni.",
"other": "Le texte fourni ne permet pas de trancher."
}
},
"point_annexe_iii": {
"type": "choice",
"instructions": "Si le système relève de l'annexe III du texte fourni, quel point de cette annexe s'applique ? Répondre 'non_applicable' si le système n'en relève pas.",
"criteria": {
"1_biometrie": "Biométrie.",
"2_infrastructures": "Infrastructures critiques.",
"3_education": "Éducation et formation professionnelle.",
"4_emploi": "Emploi, gestion de la main-d'œuvre, accès à l'emploi indépendant.",
"5_services_essentiels": "Accès aux services privés essentiels et aux services et prestations publics.",
"6_repression": "Répression.",
"7_migration": "Migration, asile, contrôle aux frontières.",
"8_justice": "Administration de la justice et processus démocratiques.",
"non_applicable": "Le système ne relève pas de l'annexe III.",
"other": "Relève de l'annexe III mais le point applicable est indéterminable."
}
},
"role": {
"type": "choice",
"instructions": "Au sens des définitions fournies, quel rôle l'entreprise tient-elle sur ce système ?",
"criteria": {
"fournisseur": "Elle développe le système ou le met sur le marché sous son nom.",
"deployeur": "Elle utilise sous sa propre autorité un système développé par un tiers.",
"les_deux": "Elle modifie substantiellement ou rebadge un système tiers.",
"other": "Indéterminable depuis la description."
}
},
"description_suffisante": {
"type": "noul",
"instructions": "La description du système contient-elle assez d'éléments — finalité, données traitées, personnes concernées, nature des sorties — pour appliquer le texte sans supposition ?"
},
"cas_limite": {
"type": "noul",
"instructions": "Le classement repose-t-il sur une interprétation discutable du texte fourni, plutôt que sur une correspondance directe ?"
}
}
}
Un système de triage des alertes cyber
C’est un cas d’usage typiquement métier qui gagnerait à utiliser Jev. Les alertes cyber sont de plus en plus nombreuses et les analystes sont souvent dépassés par leur nombre. Un système de triage intelligent basé sur Jev pourrait classifier les alertes à remonter en fonction de la gravité et de l’urgence de chaque alerte. Certains SIEM le proposent déjà nativement mais le coût est, là encore, prohibitif.
POST https://api.typesafe.ai/v1/systemone
{
"model": "jev-latest",
"state": {
"regle": "{{NOM_DE_LA_REGLE_DECLENCHEE}}",
"severite_source": "{{SEVERITE_BRUTE_DU_SIEM}}",
"horodatage": "{{DATE_ISO}}",
"actif": {
"identifiant": "{{HOSTNAME_OU_IP}}",
"criticite": "{{CRITICITE_METIER_DE_LACTIF}}",
"expose_internet": "{{BOOL}}"
},
"utilisateur": {
"compte": "{{COMPTE_CONCERNE}}",
"privilegie": "{{BOOL}}",
"anciennete_mois": "{{NOMBRE}}"
},
"contexte": {
"alertes_similaires_24h": "{{NOMBRE}}",
"faux_positifs_30j_sur_cette_regle": "{{NOMBRE}}",
"changement_en_cours": "{{MAINTENANCE_MIGRATION_DEPLOIEMENT_OU_VIDE}}"
},
"details_bruts": "{{LOG_TRONQUE_2000_CARACTERES}}"
},
"questions": {
"escalade": {
"type": "score",
"instructions": "Quel niveau d'escalade cette alerte justifie-t-elle, au vu de l'actif touché, du compte concerné et du contexte opérationnel ?",
"criteria": [
"Clôture automatique : signal attendu, explicable par le contexte",
"File basse : à revoir en lot, sans urgence",
"File normale : à instruire par un analyste dans la journée",
"Prioritaire : à instruire sous l'heure",
"Astreinte : réveiller quelqu'un maintenant"
]
},
"phase": {
"type": "choice",
"instructions": "À quelle phase d'une intrusion ce signal correspond-il le mieux ?",
"criteria": {
"reconnaissance": "Balayage, énumération, collecte d'informations.",
"acces_initial": "Tentative ou réussite d'entrée : authentification, exploitation, phishing.",
"persistance_elevation": "Maintien d'accès ou élévation de privilèges.",
"mouvement_lateral": "Déplacement vers d'autres actifs du réseau.",
"exfiltration_impact": "Sortie de données, chiffrement, destruction.",
"non_malveillant": "Activité légitime ou erreur de configuration.",
"other": "Indéterminable depuis ces éléments."
}
},
"faux_positif": {
"type": "noul",
"instructions": "Cette alerte est-elle explicable par une activité légitime connue : maintenance, déploiement, changement d'infrastructure en cours, comportement habituel de ce compte ?"
},
"actif_sensible": {
"type": "noul",
"instructions": "L'actif ou le compte concerné donne-t-il accès à des données sensibles ou à des privilèges étendus ?"
},
"correlation": {
"type": "noul",
"instructions": "Cette alerte s'inscrit-elle dans une séquence cohérente avec les alertes similaires récentes, plutôt que d'être un événement isolé ?"
}
}
}
Jev étant encore nouveau, il reste difficile de concevoir exactement quels cas d’usage peuvent bénéficier de ses services. Par ailleurs, les agents de code (Claude Code, Codex, etc.) n’ont pour l’heure aucune connaissance de ce petit dernier. Le plus simple est donc de leur donner un skill qui leur explique à quoi sert Jev et quand l’utiliser dans un projet. Nous en avons développé un petit, simple et peu intrusif qui répond parfaitement à cette mission. Pour l’installer, envoyer simplement ce prompt à votre agent de code :
Installe ce skill depuis https://github.com/BenjaminPolge/jev-architect. Inspecte le repository, détermine l'emplacement approprié pour les skills/instructions dans mon environnement Claude Code/Codex, installe les fichiers nécessaires et vérifie que le skill pourra être invoqué automatiquement lorsqu'un choix d'architecture IA doit être fait. Ne modifie pas mes autres configurations sans nécessité.
Jev, une petite révolution dans les usages
Jev répond à deux irritants majeurs qui freinent l’adoption de l’IA générative dans les processus : le coût et la fiabilité. Tous les workflows agentiques ne passeront pas demain par Jev, mais le modèle lève un vrai lièvre pour bon nombre d’équipes. Du ROI, l’IA générative en produit déjà. Ce que change Jev, c’est qu’on n’a plus à choisir ses batailles : à ce prix, on peut enfin automatiser tout ce qu’on gardait de côté. Petite révolution.
Jev réussira-t-il toutefois à survivre dans les mois à venir ? Rien n’est joué. Ses barrières à l’entrée restent solides : une architecture modulaire capable de traiter simultanément plusieurs questions, un prix qu’aucun LLM n’approche et la prime au premier arrivé. Mais les travaux de Google notamment sur les modèles de diffusion textuels pourraient bien donner du fil à retordre à Jev. Si le produit fonctionne (les premiers indicateurs vont déjà en ce sens), les éditeurs concurrents n’hésiteront pas à sortir dans les prochains mois des modèles proches de son architecture. TypeSafe AI sera-t-il alors capable d’innover encore une fois ? Stay tune.