On n’a pas besoin d’un gros LLM pour chaque décision. Avec Jev, TypeSafe AI remet cette question au centre de la conception des logiciels d’entreprise : quelle intelligence faut-il vraiment mobiliser pour choisir la prochaine action ?
Lancé le 15 septembre 2026 en accès anticipé, Jev inaugure chez TypeSafe la catégorie des « System One Models ». L’entreprise le présente comme un modèle conçu pour produire des décisions structurées accompagnées de probabilités, plutôt que du texte libre. L’annonce officielle de Jev détaille cette approche.
Pour les entreprises qui adoptent des logiciels AI-native avec CraftOS, le sujet dépasse la nouveauté d’un modèle. Il touche à la vitesse des opérations, à la maîtrise de la consommation IA et à la manière de faire travailler plusieurs modèles ensemble.
Jev, un modèle de décision : qu’est-ce que cela change ?
Classifier quelque chose n’a rien de nouveau. Depuis longtemps, le machine learning permet de répondre à des questions précises : spam ou pas spam ? Support, commercial ou facturation ? Risque faible, moyen ou élevé ?
Prenons une demande reçue par une entreprise : « Je voudrais commander 50 unités, mais j’ai besoin de connaître le délai de livraison. » Le logiciel doit reconnaître une intention d’achat, identifier l’information manquante et choisir vers qui orienter la demande. Il n’a pas nécessairement besoin d’un long raisonnement rédigé pour chacune de ces étapes.
Dans l’approche de Jev, le développeur définit les réponses possibles et leur structure. Le modèle reçoit le contexte et renvoie des valeurs directement exploitables par le logiciel, avec un niveau de probabilité. Une décision devient ainsi une étape du parcours métier.
Jev et les LLM : des rôles complémentaires
Un modèle généraliste comme ceux utilisés dans ChatGPT, Claude ou Gemini peut rédiger, coder, analyser, raisonner et aussi classifier. Les LLM savent également produire des sorties structurées. La différence ne se résume donc pas à « l’un écrit, l’autre décide ».
L’intérêt d’une architecture spécialisée est de consacrer ses ressources à un périmètre précis. Pour rédiger une proposition commerciale personnalisée, un modèle génératif reste pertinent. Pour orienter une demande parmi quelques catégories connues, une solution plus spécialisée peut suffire. Et si une règle déterministe résout correctement le problème, aucun modèle n’est nécessaire.
C’est une question centrale en ingénierie IA et intégration de modèles : choisir la bonne combinaison selon la tâche, le délai acceptable, le coût d’une erreur et le volume à traiter.
Latence et prix de Jev : ce qu’annonce TypeSafe
Dans son annonce de lancement, TypeSafe communique les chiffres suivants pour Jev :
- 70 à 500 ms de temps de réponse de bout en bout ;
- 40 à 200 fois plus rapide que les LLM comparés sur les tâches de décision testées ;
- 0,042 dollar par million de tokens d’entrée, sans facturation des tokens de sortie.
Ce sont les chiffres de l’éditeur au lancement, pas une garantie sur chaque application. Les conditions de test, la localisation du service et les modèles comparés influencent les résultats. TypeSafe en précise les limites dans sa présentation des performances et de la méthodologie.
Une entreprise doit surtout mesurer son propre parcours : réception de la demande, accès aux données, décision, action et éventuelle validation humaine. Une réponse rapide du modèle ne suffit pas si le reste du processus prend plusieurs minutes.
Même logique pour le prix : un million de tokens ne correspond pas à un million de décisions. Le coût réel dépend de la quantité de contexte envoyée, du nombre d’appels, des reprises et des autres services mobilisés.
Pourquoi les logiciels AI-native multiplient les micro-décisions
Dans un système AI-native, une seule demande peut déclencher plusieurs choix en arrière-plan. Quelle information récupérer ? Quel traitement lancer ? Quelle action proposer ensuite ? Peut-on continuer automatiquement ou faut-il demander une validation ?
À l’échelle d’une entreprise, ces choix peuvent se compter par milliers ou millions. Utiliser systématiquement le modèle le plus puissant peut alors ajouter du délai et de la consommation sans améliorer chaque résultat.
Cette réflexion concerne directement l’orchestration d’agents IA : un agent IA peut avoir besoin d’un raisonnement élaboré pour préparer une réponse, tout en s’appuyant sur des étapes plus simples pour trier, orienter ou vérifier. Voici trois applications métier de cette logique.
CRM : qualifier et orienter les demandes commerciales
Un prospect écrit sur WhatsApp, par email ou via un réseau social. Avant de répondre, le système doit distinguer une demande de prix, une intention d’achat et un besoin de support. Il doit aussi repérer les informations manquantes et savoir quand transmettre la conversation à l’équipe commerciale.
C’est le type de parcours auquel répond un CRM natif IA comme CraftOS CRM : réunir le contexte client et permettre à un agent IA WhatsApp de qualifier, répondre et faire avancer la vente. Chaque étape n’appelle pas le même niveau de raisonnement.
Facturation : distinguer une relance d’un litige
« Je règle vendredi » et « Le montant ne correspond pas au devis » ne doivent pas déclencher la même action. Avant toute relance, il faut comprendre la réponse et vérifier le dossier. Une contestation doit pouvoir être transmise à une personne.
Dans un parcours de devis, facturation et suivi des paiements avec CraftOS Facturation, la valeur vient de cette continuité : une information comprise, un dossier à jour et une prochaine action adaptée.
Cloud : choisir le modèle selon le travail à effectuer
Préparer une présentation, analyser un dossier d’appel d’offres et classer des demandes entrantes sont trois tâches différentes. Une architecture multi-modèles permet d’évaluer quel modèle convient à chacune, selon la qualité attendue, les données traitées et la consommation IA.
Découvrez cette approche à travers CraftOS Cloud et ses applications IA intégrées. Ces exemples illustrent des usages possibles de modèles spécialisés ; ils ne constituent pas une annonce d’intégration de Jev dans CraftOS.
Avant d’automatiser une décision, tester ce qui compte
Un format de réponse valide n’est pas une preuve que la décision est juste. Un niveau de probabilité doit lui aussi être évalué sur des situations représentatives de votre activité.
Pour passer de la démonstration à la production, nous recommandons de commencer par un périmètre limité :
- Choisir une décision répétitive. Par exemple, orienter les demandes entrantes vers le bon service.
- Constituer un jeu de cas réels. Inclure les messages incomplets, les ambiguïtés et les langues utilisées par vos clients.
- Comparer les options. Règles métier, classifieur, LLM ou modèle spécialisé : mesurer la qualité, le délai et le coût du parcours complet.
- Prévoir le relais humain. Définir les situations dans lesquelles le système doit s’arrêter ou demander une validation.
- Suivre les erreurs en production. Documenter les décisions, recueillir les corrections et réévaluer les seuils.
Ces choix relèvent autant de la technique que de la gouvernance de l’IA en entreprise. L’accès aux informations et leur traitement doivent également respecter votre cadre de sécurité des données et de conformité IA.
Le bon niveau d’intelligence, au bon endroit
Jev ne remplace pas les modèles généralistes et n’a pas inventé la classification. Il remet en lumière une question utile : faut-il mobiliser un gros modèle pour chaque étape d’un processus ?
Avec les systèmes AI-native, l’enjeu est de construire un ensemble cohérent : des règles lorsque le problème est déterministe, des modèles spécialisés lorsque la tâche est précise, et des modèles généralistes lorsque le travail demande un raisonnement plus large.
Utiliser juste le niveau d’intelligence nécessaire, au bon endroit, au bon moment et au bon coût. C’est ainsi que l’IA peut prendre sa place dans les opérations quotidiennes de l’entreprise.
Échangeons sur les processus que vous souhaitez automatiser avec l’IA →
← Tous les articles