Que peut réellement faire Jev ? Comprendre ses usages à travers 10 projets communautaires

Naviguer sur des sites, nettoyer le contexte d’un Agent, assembler des interfaces, filtrer les publicités, piloter des jeux, classer des e-mails et passer les segments sponsorisés sur YouTube : mis côte à côte, ces projets Jev peuvent donner l’impression que le modèle sait presque tout faire.

En examinant chaque workflow de plus près, on découvre un rôle beaucoup plus étroit. Jev ne prend généralement en charge qu’une petite étape : produire une décision structurée à partir de l’état courant. L’analyse d’une page, la transcription de la parole, l’envoi d’un ordre ou le déplacement dans une vidéo restent exécutés par du code classique, des services spécialisés ou d’autres modèles.

C’est la distinction essentielle pour comprendre Jev. Sa valeur ne consiste pas à remplacer un modèle de chat pendant toute la tâche, mais à transformer des étapes où un modèle de langage devrait « réfléchir, rédiger, puis être analysé par le programme » en choix, scores ou probabilités directement exploitables par le logiciel.

En quoi Jev diffère-t-il d’un modèle de chat classique ?

TypeSafe présente Jev comme le premier modèle System One. Le développeur lui fournit deux éléments : un state décrivant la situation courante et un ensemble de typed questions typées. Au lieu de produire une longue réponse, Jev renvoie trois formes de décisions structurées :

Type	Question à laquelle il répond	Résultat typique
Choice	Quelle catégorie, action ou quel outil faut-il choisir ?	Une option et la probabilité de chaque option
Score	À quel niveau se situent la gravité, la pertinence ou la qualité ?	Un score et les probabilités de chaque niveau
Noul	Une affirmation est-elle vraie ?	Une probabilité comprise entre 0 et 1

Par exemple, un Agent de navigation peut regrouper le DOM de la page courante, l’objectif de l’utilisateur et les actions disponibles dans un state, puis demander à Jev : « Sur quel élément faut-il cliquer ensuite ? » Le programme exécute le clic après réception du résultat. S’il faut rédiger du texte dans un champ, cette partie reste confiée à un modèle génératif.

Le workflow exact n’est donc pas « Jev accomplit la tâche », mais plutôt :

État ou événement courant
      ↓
Jev : choisir, noter ou juger
      ↓
Code classique : exécuter, classer, filtrer, suspendre ou transmettre à une personne

Les dix projets suivants ne constituent pas un classement de maturité. Il est plus utile de les organiser selon le rôle de Jev dans le logiciel : couche d’action, couche d’information et couche de workflow.

1. Couche d’action : Jev choisit l’étape suivante, le programme l’exécute

1. Browser Use : transformer la navigation web en choix parmi des actions candidates

Dans l’implémentation jev-ultrafast de Browser Use, le programme commence par lire le DOM de la page et génère l’ensemble des actions disponibles à cet instant : cliquer sur un bouton, sélectionner une option ou passer à la page suivante, par exemple. Jev ne décrit pas librement la façon de parcourir le site ; il choisit l’étape suivante parmi ces actions candidates.

Cette conception convient à Jev parce que chaque cycle de décision remplit trois conditions : le programme a déjà structuré l’état, l’ensemble des actions est fini et le code sait comment exécuter l’action sélectionnée. Lorsque le workflow doit saisir un texte, comme une ville de départ ou d’arrivée, il appelle encore un petit modèle génératif ; Jev ne produit pas lui-même ce contenu.

L’auteur a indiqué qu’une recherche de vol prenait environ 7 secondes et coûtait près de $0.0039, la vidéo de démonstration étant diffusée à vitesse réelle. Ces chiffres décrivent ce workflow fixe, mais ne prouvent pas que n’importe quel site ou n’importe quelle tâche conservera la même vitesse et le même taux de réussite. Le MVP ne prend pas encore en charge des structures telles que shadow DOM, iframe, canvas ou l’envoi de fichiers.

La principale leçon n’est pas que « Jev sait naviguer sur le Web », mais qu’il est possible de réduire d’abord l’espace d’actions avec du code, puis de laisser le modèle effectuer un choix contraint.

2. Navigateur vocal : Jev se place entre la reconnaissance vocale et l’exécution dans le navigateur

La chaîne d’un navigateur commandé par la voix illustre encore mieux la répartition des rôles. Le microphone capte la parole, un service vocal la convertit en texte, le système lit la page courante et prépare les actions exécutables, Jev en choisit une, puis le navigateur l’exécute.

L’auteur a rapporté qu’une décision de Jev prenait environ 300 millisecondes et coûtait près de $0.0002. Ce chiffre ne couvre que l’étape de décision. Il n’inclut ni la capture audio, ni la transcription, ni la localisation de l’élément sur la page, ni le transfert réseau, ni l’exécution par le navigateur. « Jev décide vite » ne signifie donc pas que l’interaction vocale complète ne dure que 300 millisecondes.

Ce modèle convient davantage à des commandes telles que « ouvre cet onglet », « clique sur envoyer » ou « fais défiler vers le bas », que l’on peut associer à un ensemble fini d’actions. Si l’utilisateur demande de rédiger, résumer ou expliquer un contenu, le workflow a toujours besoin d’un modèle généraliste.

3. Doom et Mario : lire un état structuré, pas les pixels du jeu

Les démonstrations de jeux attirent généralement le plus l’attention. Dans le projet public Doom, la position, les ennemis, les armes et d’autres données sont convertis en état textuel structuré. Jev choisit ensuite un déplacement, une attaque ou une autre action, et le programme renvoie ce choix au jeu.

L’auteur a signalé une cadence d’environ 10 appels par seconde pour un coût d’environ $7 par heure. Il ne faut toutefois pas présenter la démonstration comme si « Jev comprenait directement l’image et jouait de façon autonome ». Les documents de lancement de TypeSafe précisent que la démonstration Doom utilise un état textuel structuré, et non des pixels bruts. Les projets communautaires autour de Mario ressemblent eux aussi davantage à des expériences où l’état alimente une boucle de décision et où le modèle choisit une action.

Ces projets montrent que des décisions rapides peuvent entrer dans une boucle en temps réel. Ils ne montrent pas que Jev possède une compréhension visuelle générale ou une capacité de planification à long terme dans un jeu.

4. Trading en temps réel : choisir vite ne prouve pas qu’une stratégie est rentable

Les démonstrations de trading suivent une structure similaire. Les prix, les actifs et l’état du marché sont structurés puis envoyés à Jev ; le modèle choisit buy ou sell ; le programme transmet ensuite l’ordre. Un autre projet communautaire affirme pouvoir suivre une cadence de blocs d’environ 300 millisecondes.

Les documents disponibles ne publient ni rendement, ni drawdown, ni slippage, ni impact des frais, ni résultats complets de gestion du risque. L’exemple montre donc seulement que Jev peut être intégré à un prototype de décision de trading à faible latence. Il ne prouve pas que la stratégie est rentable, et la vitesse d’exécution ne doit pas être confondue avec une performance d’investissement.

Dans un système réel, les limites de position, les stop-loss, les autorisations, la validation des ordres et la gestion des exceptions doivent rester contrôlés par du code déterministe. Les ordres à haut risque ne devraient pas être exécutés automatiquement sur la base d’un seul choix du modèle.

2. Couche d’information : Jev classe, note et détecte des limites

5. Classement des e-mails et tickets : ne pas demander uniquement « quelle catégorie ? »

Le classement des e-mails est l’un des usages les plus intuitifs de Jev. Le système place le corps du message dans state, demande à Jev de choisir entre ventes, facturation, assistance technique ou une autre catégorie, puis laisse le programme agréger, acheminer ou placer le message dans une file de vérification humaine.

L’auteur d’un projet représentatif a indiqué avoir traité 500 e-mails en quelques secondes pour environ $0.035. La publication d’origine ne communique pas la composition du corpus, la définition des catégories, la précision ni la matrice de confusion. Ce résultat ne peut donc pas être présenté comme un benchmark général de classification des e-mails.

Une conception pratique ne devrait pas non plus se limiter à une seule question large. Un ticket peut contenir simultanément un problème technique, une demande de remboursement et une forte frustration. La tâche peut être décomposée en décisions indépendantes :

• Choice : À quelle équipe faut-il principalement l’attribuer ?
• Score : À quel niveau d’urgence appartient-il ?
• Noul : Implique-t-il un remboursement, un chargeback, un risque juridique ou une escalade humaine ?

Le code environnant peut ensuite combiner les résultats pour construire le parcours de traitement. Même si la catégorie principale est correcte, le système ne traitera pas automatiquement le ticket en ignorant une demande de remboursement ou un signal d’escalade.

6. Blocage sémantique des publicités : passer de règles correspondantes à un jugement sur le contenu

Les bloqueurs de publicité traditionnels reposent souvent sur des domaines, des sélecteurs et des listes de filtres maintenues. Dans la démonstration communautaire, l’extension inspecte un à un les éléments DOM et leurs class, demande à Jev si chacun ressemble davantage à une publicité ou à un contenu normal, puis supprime les éléments classés comme publicitaires.

L’idée montre comment un jugement sémantique peut compléter un système de règles. Même si un élément ne correspond à aucun filtre connu, le modèle peut reconnaître une intention publicitaire à partir du texte et de la structure de la page.

Cependant, les documents publics ne fournissent ni code associé à une version fixe, ni taux de suppressions erronées et d’omissions, ni couverture de sites, ni tests de longue durée. Il est donc plus exact de parler de « prototype de blocage sémantique des publicités » que d’un système de production impossible à contourner ou exempt d’erreurs. La suppression incorrecte d’éléments frontières — navigation, recommandations d’achat ou promotions internes — peut directement casser la page.

7. Tableurs pilotés par l’intention : transformer le nom d’une colonne en tâche de notation sémantique

Le projet de tableur prédictif traite le nom de la colonne lui-même comme une question. Lorsqu’un utilisateur ajoute une colonne Urgency, le système lit le texte de chaque ligne, demande à Jev d’en évaluer l’urgence, puis inscrit le résultat dans la feuille.

Jev ne génère pas ici une formule Excel. Une colonne de données est transformée en une série de tâches de classification ou de notation. Le même schéma peut s’appliquer à la priorité d’un prospect, au sentiment client, au risque d’un contenu ou aux thèmes de feedback difficiles à exprimer par des formules fixes.

La vidéo de l’auteur mentionne un traitement d’environ 100 millisecondes, mais ne précise ni le nombre de lignes, ni la frontière de mesure, ni le comportement du cache, ni la stabilité des scores. Elle ne montre donc pas que n’importe quel nom de colonne peut devenir automatiquement une « formule intelligente » fiable. Avant un déploiement, il faut encore fixer le sens de la question, tester les cas limites et déterminer quels résultats nécessitent une vérification humaine.

8. Saut des segments sponsorisés sur YouTube : le modèle trouve les limites, le code contrôle le déplacement

YouTube Sponsor Detection découpe la transcription d’une vidéo en lignes numérotées. Jev détermine quelles lignes correspondent à du contenu sponsorisé et où le segment commence et se termine. Le programme associe ensuite ces numéros de ligne à des horodatages et contrôle le déplacement du lecteur.

Si la vidéo ne possède pas de sous-titres exploitables, un mode audio utilise d’abord un service tel que Deepgram pour produire une transcription. Jev n’écoute donc pas directement l’audio et ne contrôle pas lui-même le lecteur. Son rôle consiste à porter un jugement sémantique sur la transcription et à en détecter les limites.

L’auteur décrit le projet comme un prototype BYOK open source coûtant environ $0.005 par vidéo. Ce chiffre varie selon la longueur de la transcription, le mode audio et le service de transcription, et les documents publics ne fournissent pas de test de précision indépendant. Le saut automatique comporte aussi deux risques concrets : l’absence de sous-titres ou la classification erronée d’un passage ordinaire comme segment sponsorisé.

Ce projet illustre une répartition typique : le modèle identifie la limite sémantique, tandis que le code déterministe convertit le temps et contrôle la lecture.

3. Couche de workflow : Jev devient un composant intermédiaire de décision

9. Compaction du contexte d’un Agent : décider quoi conserver au lieu de réécrire un résumé

À mesure qu’un Agent appelle des outils, les journaux du terminal, les résultats de recherche et le contenu des fichiers peuvent remplir rapidement la fenêtre de contexte. Une approche fréquente consiste à demander à un modèle génératif de réécrire l’historique sous forme de résumé. fast-jev-compaction adopte une autre méthode : il associe d’abord les appels d’outils à leurs résultats, demande à Jev quels contenus doivent être conservés en entier, tronqués ou supprimés, puis laisse le code effectuer l’élagage concret.

Cette méthode réduit la réécriture libre et facilite le suivi des éléments supprimés. Mais « élaguer rapidement » ne signifie pas « améliorer toutes les tâches suivantes ». Une évaluation du port vers Hermes a rapporté un temps de compaction d’environ 1.4 seconde, une conservation d’environ 115K token et un score de rappel de 75.5%, tout en incluant une baseline de récupération par recherche. Le résultat dépend du jeu de test, du budget de Token, de la méthode de portage et de la possibilité de retrouver les informations supprimées. Il ne permet pas d’affirmer que tous les Agent économiseront des coûts à long terme.

Il faut évaluer l’ensemble de la chaîne de tâche. Après une suppression, l’Agent relance-t-il les mêmes recherches ? Oublie-t-il les contraintes de l’utilisateur ? Répète-t-il une erreur précédente parce que les informations correspondantes ont disparu ? Si la récupération ultérieure coûte plus cher, une compaction plus rapide ne réduit pas nécessairement le coût total.

La compaction du contexte nécessite donc un mécanisme de récupération et une liste d’autorisation pour les informations critiques. Les exigences de l’utilisateur, les tâches inachevées, les contraintes d’autorisation et les traces d’actions irréversibles ne devraient pas être supprimées définitivement sur la seule base d’un résultat à faible probabilité.

10. json-render : choisir les composants et leurs relations plutôt que générer librement toute l’interface

Dans les notes d’implémentation de Jev pour json-render, la génération d’interface est divisée en deux étapes. La première détermine quels composants sont nécessaires et en quelle quantité. La seconde organise les relations parent-enfant et l’ordre. Le code génère et valide ensuite le JSON avant de le transmettre au renderer qui assemble l’interface.

Cette approche diffère nettement de celle qui consiste à demander à un modèle généraliste d’écrire une page HTML ou JSON complète en une seule réponse. Les composants, bindings et actions proviennent tous d’ensembles contraints. Jev choisit principalement la structure, tandis que le code garantit que la sortie respecte le protocole de rendu.

Cela peut réduire les sorties libres impossibles à analyser, mais « structure valide » ne signifie pas encore « interface correcte ». Les composants peuvent être mal choisis, la hiérarchie peut ne pas correspondre à l’intention de l’utilisateur, le texte peut toujours nécessiter un modèle génératif et le design final peut manquer d’attrait ou d’ergonomie. Les notes d’implémentation limitent aussi le nombre d’éléments ajoutés par lot, le nombre d’évaluations et la profondeur maximale. Cette méthode convient donc mieux à l’assemblage d’interfaces à partir d’une bibliothèque finie qu’à la conception sans contrainte de n’importe quelle page produit.

Que peut-on retenir de ces dix projets ?

Même si ces projets couvrent les navigateurs, la vidéo, l’e-mail, les tableurs, les jeux et l’UI, leur structure de fond est très proche :

1. L’état peut être structuré. Le DOM d’une page, une transcription, un e-mail, l’état d’un jeu ou un journal d’outil peuvent être représentés sous forme de texte, de JSON ou de tableau.
2. La réponse peut être contrainte. Une action suivante, une catégorie, un niveau de risque ou une décision de conservation peuvent s’exprimer par un ensemble fini d’options, une grille de notation ou un jugement probabiliste.
3. Le code sait quoi faire du résultat. Cliquer, supprimer, se déplacer dans une vidéo, classer, écrire dans une feuille ou transmettre à une personne disposent d’une logique d’exécution explicite.
4. Les erreurs disposent d’un chemin de repli. Si le modèle est incertain, si l’API échoue ou si le risque est trop élevé, le système peut s’arrêter, réessayer, appeler un modèle généraliste ou solliciter une personne.

C’est également la répartition la plus pertinente entre Jev et une LLM généraliste. Jev traite les décisions sémantiques fréquentes, en une étape et aux limites claires. Le modèle généraliste continue à générer du texte, proposer de nouveaux plans, effectuer des raisonnements complexes et expliquer les résultats.

Une sortie typée garantit seulement que la valeur renvoyée respecte l’interface ; elle ne garantit pas que le jugement métier soit juste. Des évaluations tierces montrent aussi que la précision et la calibration probabiliste de Jev varient selon les jeux de données. Lorsqu’une entreprise dispose déjà de quelques centaines d’exemples correctement annotés, un petit classifieur ou un encodeur peut être plus précis, plus rapide et mieux adapté à une exécution hors ligne. Jev convient donc davantage comme composant décisionnel général au démarrage à froid et pour les tâches de longue traîne que comme solution définitive à tout problème de classification.

Cinq éléments à ne pas négliger avant la mise en production

Premièrement, relisez la formulation des questions comme du code. La sortie de Jev dépend fortement de la question et de ses critères. Une formulation vague, contradictoire ou regroupant plusieurs jugements peut produire un résultat correctement typé mais incorrect pour le métier.

Deuxièmement, calibrez les seuils sur vos propres données. Les probabilités et seuils d’une démonstration ne peuvent pas être recopiés tels quels en production. Chaque langue, type de contenu et niveau de risque doit être testé séparément.

Troisièmement, prévoyez un repli en cas de latence ou d’échec. Une requête réseau peut expirer ou échouer. Le système doit définir à l’avance si un échec signifie autoriser, bloquer, réessayer ou transmettre à une personne, au lieu de traiter une erreur d’API comme un « non ».

Quatrièmement, ne fondez pas une action à haut risque sur un seul jugement du modèle. Les opérations irréversibles — trading, suppression de données, gel de compte ou publication de contenu sensible à la conformité — doivent conserver des règles déterministes, une seconde confirmation et des traces d’audit.

Cinquièmement, continuez à collecter les erreurs. Conservez la version de l’entrée, la version de la question, les probabilités des options, l’action finale et la correction humaine. C’est la seule façon de savoir si un échec vient de la construction de l’état, de la formulation, du seuil ou du modèle.

Conclusion

Jev est surtout utile non pas comme remplaçant d’un modèle de chat, mais à l’intérieur d’un logiciel, aux points de décision autrefois difficiles à exprimer par une logique if/else et trop coûteux à confier systématiquement à un grand modèle génératif.

Browser Use lui fait choisir la prochaine action web. Un système d’e-mail peut l’utiliser pour le routage et les signaux d’escalade. Le prototype YouTube lui demande de délimiter un segment sponsorisé. json-render s’en sert pour choisir les relations entre composants, tandis que la compaction de contexte lui demande quelles informations historiques méritent encore une place dans la fenêtre. Aucune de ces applications ne fonctionne parce que Jev accomplit seul toute la tâche. Elles fonctionnent parce que les développeurs conçoivent ensemble l’état, les options candidates, la logique d’exécution, les seuils et les chemins de repli.

Jev apporte le plus de valeur lorsque la limite de décision est claire, que la sortie peut être contrainte et que le code peut exploiter le résultat de manière fiable. Quand une tâche exige une longue génération de texte, un raisonnement en plusieurs étapes, une planification ouverte ou une conclusion explicable, une LLM généraliste reste indispensable.