7 cas d’usage de Jev qui épargnent un vrai travail aux logiciels

Une personne a demandé à notre site combien nous avions d’intégrations. Il lui a répondu en conseillant le nombre de champs à mettre dans un formulaire d’inscription.

La réponse est arrivée vite. Elle ne servait à rien.

Les deux questions contenaient « combien ». Notre code de recherche accordait à toute correspondance FAQ acceptée un score minimal de 0,86, si bien qu’un résultat peu pertinent paraissait convaincant. La rapidité masquait la mauvaise décision.

C’est le genre d’échec à garder en tête lorsque l’on consulte Ship with Jev. Le 26 septembre 2026, le répertoire recensait 551 créations de la communauté. Jeux, composants de recherche, agents de navigation, outils de recherche documentaire et expériences de routage s’y côtoient. Le répertoire attribue les chiffres de performance à leurs auteurs : c’est un outil de découverte, pas un banc d’essai indépendant.

La question intéressante est de savoir quels schémas enlèvent du travail à un vrai produit.

Pour les équipes qui créent des intégrations et des logiciels d’entreprise, voici les sept cas que j’évaluerais d’abord. Leur ordre reflète mon jugement sur leur utilité et leur facilité d’évaluation. Les parcours ci-dessous sont des propositions de conception, sauf lorsqu’une implémentation précise est citée.

Ce que Jev apporte à une application

TypeSafe décrit Jev comme un modèle de jugements typés. Donnez-lui un état pertinent et une question ; il renvoie un choix, une probabilité ou un score que le code peut exploiter. Sa carte des cas d’usage couvre le routage, la récupération, la vérification et l’extraction.

Cette distinction a un précurseur utile dans les vidéos que nous avons ingérées. Dans sa conférence à AI Engineer, Diogo Almeida, cofondateur de TypeSafe, plaide pour des logiciels dont les composants peuvent exprimer davantage d’intelligence. Il oppose cette ambition au simple ajout d’un assistant à un logiciel existant. Il s’agit de son argument sur l’orientation de l’IA, pas d’une mesure des performances actuelles de Jev.

Imaginez un aiguillage ferroviaire. Le résultat utile est la voie disponible que le train doit emprunter. Un paragraphe décrivant les voies ne déplace pas l’aiguillage.

L’objection est raisonnable : « Un LLM ordinaire peut déjà renvoyer du JSON. » Oui. L’intérêt d’un composant différent repose sur la qualité, le coût et la latence mesurés pour cette décision. Une réponse typée seule ne prouve aucun de ces points.

Le défi posé par CLM mérite d’être examiné d’abord

Le 23 septembre, Jacky Kwok, Hangoo Kang, Tarun Suresh, Jon Saad-Falcon, Marco Pavone, Christopher Ré et Azalia Mirhoseini ont publié Contrastive Language Models. Leur travail conteste l’idée que Jev soit la seule voie pratique vers des décisions sémantiques rapides.

Les auteurs rapportent des résultats zero-shot comparables à ceux de Jev sur des tâches d’utilisation d’ordinateur, de jeu et d’appel d’outils, avec une latence jusqu’à 9 fois moindre. Séparément, ils rapportent 81,6 % sur 38 tâches DeepSWE réservées et 87,6 % sur 30 tâches Terminal-Bench 2.1. Ces résultats de programmation utilisent des vérificateurs CLM affinés pour choisir parmi les solutions produites par d’autres modèles. Les auteurs indiquent également que Jev se situe sous leur référence fondée sur une sélection aléatoire dans ce dispositif. La latence a été mesurée sur une H100. Ce sont leurs résultats ; nous ne les avons pas reproduits de manière indépendante. Évaluation et méthodologie d’origine.

Cette comparaison change ce qu’il faut tester. Choisir une file de support, sélectionner un passage trouvé par recherche et évaluer une longue suite d’étapes de programmation sont des tâches différentes. Réussir l’une ne tranche pas les autres.

CLM encode séparément les états et les actions candidates, ce qui permet de mettre en cache les représentations d’actions réutilisables. Son dépôt décrit une interface compatible avec TypeSafe et une limite d’état de 2 048 tokens par défaut ; les états plus longs sont tronqués sauf configuration contraire. La compatibilité des interfaces ne garantit pas des décisions équivalentes.

La fiche du modèle publié précise qu’il utilise des représentations Qwen3-8B et avertit que les bons résultats des vérificateurs exigent des têtes affinées. Elle précise aussi que CLM note les candidats fournis sans générer de solution. Les poids ouverts offrent une possibilité d’évaluation ; le matériel, l’hébergement et la maintenance ont toujours un coût.

Pour Tajo, les leçons sont concrètes : comparer les modèles de décision sur les mêmes cas, consigner séparément la latence à froid et à chaud et tester des candidats erronés mais plausibles. Fixez la version du modèle et de tout encodeur ou tête de projection. Rejetez une configuration de fournisseur non prise en charge au lieu de choisir silencieusement un autre fournisseur. Revérifiez l’étalonnage quand le modèle ou les candidats changent.

Les sept parcours suivants restent de bons candidats à l’évaluation. Leur intérêt ne dépend pas d’une victoire de Jev dans toutes les comparaisons.

1. Une recherche qui vérifie si le résultat répond à la question

C’est mon premier choix : l’échec est visible et le résultat facile à étiqueter. Le passage renvoyé répondait-il à la question posée par le visiteur ?

Récupérez quelques candidats avec une recherche par mots-clés, des représentations vectorielles ou les deux. Demandez ensuite à Jev si chaque passage contient l’information demandée. Le guide de reclassement de TypeSafe montre cette structure en deux temps. Il en montre aussi la limite : un outil de reclassement ne peut choisir un document absent des résultats initiaux.

1. Récupération

   mots-clés, représentations vectorielles

   Quelques candidats

   Ne peut pas ajouter ce qu’elle a manqué
2. Jev

   jugement typé

   Ce passage contient-il

   l’information ?
3. Réponse

   ou pas de réponse

   Juste ou sans réponse

   Latence totale mesurée

Pour notre exemple du nombre d’intégrations, le chemin le plus court est encore plus simple. Comptez les entrées du catalogue faisant autorité. Précisez ce que mesure ce nombre. Un connecteur documenté et une connexion configurée par un client ne sont pas la même chose.

Réservez le jugement sémantique aux questions qui demandent une interprétation, comme « Est-ce que cela peut transférer seulement les clients modifiés depuis hier ? ». Récupérez la documentation de synchronisation pertinente, puis vérifiez qu’elle couvre les mises à jour incrémentales.

L’implémentation jevsearch de Kyle McLaren rend la séquence concrète : les résultats par mots-clés arrivent d’abord, puis Jev les classe. Son évaluation publiée utilise son propre corpus documentaire et des requêtes étiquetées. C’est un élément probant pour ce test, pas une promesse pour un autre site ou une autre langue.

Mesurez les bonnes réponses, les réponses non étayées, les questions restées sans réponse et la latence totale. Incluez les fautes de frappe et les requêtes traduites. Un résultat non pertinent le reste même s’il arrive plus vite.

2. Diriger les demandes vers la bonne page, file ou le bon agent

Un utilisateur écrit : « Les contacts n’arrivent plus depuis que j’ai changé de compte. » Votre application doit distinguer un problème de connexion d’une question de facturation, d’une correspondance de champs ou d’une demande de nouvelle synchronisation.

Fournissez l’écran actuel, les échanges récents et les destinations accessibles à cet utilisateur. Demandez la meilleure destination, avec une option explicite « aucune correspondance ». L’application garde la maîtrise des identifiants de destination.

Plusieurs jugements peuvent servir ensemble : intention, destination, urgence et présence d’une demande sur laquelle agir. Le schéma fan-out de TypeSafe permet à plusieurs questions indépendantes de partager une même requête. Le code utilise ensuite les réponses utiles.

Une suggestion de navigation sans conséquence et l’autorisation d’effectuer une tâche restent deux décisions distinctes. Trouver la bonne page de facturation n’autorise pas un remboursement. Trouver le bon agent ne lui donne pas d’identifiants.

L’avantage pratique est la réduction des transferts et des demandes de précisions. Mesurez la fréquence à laquelle l’utilisateur atteint la bonne destination dès le premier essai. Gardez un jeu de tests avec des réponses de suivi comme « oui », « nouvelle tâche » et « est-ce terminé ? ». Elles ne prennent sens qu’en contexte.

3. Associer des données désordonnées dans une intégration fiable

Voici un parcours d’intégration proposé. Un export source contient customer_email, billing_email et account_owner_email. La destination attend l’adresse e-mail du contact.

La ressemblance des chaînes laisse une vraie ambiguïté. Les descriptions des champs, les exemples de valeurs et l’objectif métier aident à la lever. Jev peut choisir parmi les véritables champs source, tandis que le code contrôle les types, les valeurs obligatoires et les contraintes de la destination.

Le guide connexe sur l’extraction de valeurs préanalysées emploie une conception particulièrement utile : le code trouve des valeurs candidates, le modèle en choisit une, puis le code copie la valeur originale. On évite ainsi de générer une autre adresse ou un autre montant.

1. Code

   trouver les candidats

   customer_email

   billing_email

   account_owner_email
2. Jev

   en choisir un

   Descriptions des champs

   Exemples de valeurs, objectif
3. Code

   copier la valeur originale

   Types, valeurs obligatoires

   Contraintes de la destination

Pour une intégration CRM et e-mail marketing, conservez ensemble le champ source et la décision de correspondance. Montrez un aperçu des enregistrements concernés. Laissez les correspondances incertaines en suspens jusqu’à leur vérification.

Il y a ici un avantage économique : une correspondance de schéma approuvée peut être réutilisée. Nul besoin d’appeler un modèle pour chaque ligne si le sens du champ n’a pas changé.

Mesurez les enregistrements rejetés et les mauvaises correspondances sur un échantillon vérifié. Une requête API réussie prouve que la charge utile a été acceptée ; elle ne prouve pas que la bonne adresse e-mail a été attribuée au bon contact.

4. Choisir le plus petit modèle capable d’accomplir la tâche

Le routage des modèles est intéressant quand une application envoie tout à son modèle le plus cher. Modifier un libellé, juger un résultat de recherche et enquêter sur une architecture difficile n’ont pas les mêmes exigences.

Définissez d’abord les modèles configurés et autorisés à recevoir les données de la tâche. Notez leurs outils pris en charge et leurs performances observées. Un jugement étroit peut alors recommander une option appropriée dans cet ensemble. TypeSafe présente ce schéma dans ses exemples de routage des modèles.

Le Jev Router d’OpenRouter propose ce schéma sous l’identifiant typesafe/jev-router dans son API de chat. Sa fiche décrit le choix du modèle et de l’effort de raisonnement au fil de la conversation. Avant de l’adopter, évaluez les modèles en aval autorisés, les coûts réels, le traitement des données et le comportement lors des appels d’outils. Nous avons vérifié la fiche, pas évalué ce routeur par des tests comparatifs.

Notre règle proposée commence par du code ordinaire pour les règles et faits exacts. Employez un modèle de décision pour les questions sémantiques délimitées, un modèle génératif adapté pour écrire ou programmer, et une escalade lorsque les éléments disponibles la justifient.

De quoi la tâche a-t-elle besoin ?

1. Règles et faits exacts

   Code ordinaire

2. Une question sémantique délimitée

   Modèle de décision

3. Rédaction ou implémentation

   Un modèle génératif adapté

4. Les éléments disponibles justifient davantage

   Escalade

Le routeur lui-même coûte du temps et de l’argent. Pour les tâches évidentes et répétables, une règle fixe peut être meilleure. Pour les tâches ambiguës, comparez le routage à un modèle fixe sur le travail achevé.

Suivez le coût par résultat accepté, les nouvelles tentatives, le taux d’escalade et les échecs découverts plus tard. Un premier appel bon marché peut devenir un parcours coûteux si quelqu’un doit réparer son résultat.

5. Vérifier les affirmations avant qu’elles n’atteignent les clients

Une citation peut exister sans étayer la phrase à côté. Une source peut décrire une fonction prévue, alors que la réponse affirme qu’elle est disponible aujourd’hui.

Le guide de vérification des citations de TypeSafe sépare deux contrôles. Une comparaison de chaînes ordinaire repère une citation manquante. Un jugement sémantique évalue si le passage source environnant soutient l’affirmation.

Appliquez la même conception à une réponse de support, à un guide d’intégration généré ou au compte rendu d’achèvement proposé par un agent. Gardez l’affirmation, le passage source et le verdict à disposition pour examen.

L’achèvement exige toujours des preuves directes. Des tests établissent le comportement testé. Un journal de déploiement établit un déploiement. Un jugement sémantique peut signaler un écart entre un rapport et ses preuves ; il ne peut créer les preuves manquantes.

Ce cas est intéressant parce qu’il peut se placer avant une étape de publication existante. Mesurez les affirmations non fondées qui passent, celles qui sont fondées mais bloquées à tort, et le travail de vérification créé. Commencez par des erreurs explicites que votre système commet déjà.

6. Tirer des extraits utiles des transcriptions et des avis clients

Une archive de transcriptions devient utile lorsqu’on y trouve le passage qui compte. « Contient le mot intégration » est un filtre médiocre pour « explique pourquoi un client a abandonné la configuration ».

Une approche consiste à récupérer les passages probables, puis à juger quelques propriétés précises : ce passage décrit-il un obstacle à la configuration, contient-il un exemple concret ou se comprend-il sans contexte manquant ?

Conservez l’URL source et l’horodatage avec chaque passage choisi. L’horodatage vient de la transcription. Le modèle juge la pertinence.

Pour une équipe de montage vidéo, ces signaux peuvent produire une courte liste d’extraits à examiner. Pour une équipe produit, ils peuvent classer les objections récurrentes. Pour une équipe marketing, ils peuvent séparer les témoignages des clients des affirmations de campagne sans fondement.

Le schéma de notation composée de TypeSafe garde les dimensions séparées pour que le code puisse changer leurs poids. Un extrait adapté à un tutoriel peut différer de celui d’une courte démonstration du produit. Réutilisez les jugements tant que les preuves et les critères restent inchangés.

JevQL offre une implémentation communautaire proche : des prédicats sémantiques sur des lignes PostgreSQL, évalués hors de la base. Sa documentation rappelle l’effet des filtres ordinaires sur la facture. Réduisez les lignes admissibles avant de demander des jugements sémantiques.

Mesurez le taux d’acceptation par les personnes chargées de la revue et le temps gagné pour trouver des éléments exploitables. Un score d’accroche n’est pas une prévision du nombre de vues.

7. Des interfaces qui choisissent la prochaine action utile

Un écran de paramètres pourrait recevoir « Arrête cette synchronisation jusqu’à demain ». Un agent de navigation pourrait devoir choisir parmi les commandes visibles sur la page courante.

Dans notre proposition d’interface, l’application fournit les actions permises et l’état actuel. Jev choisit parmi elles. L’interface présente la commande pertinente ou une proposition vérifiable.

Ship with Jev présente la démonstration de recherche de vols dans le navigateur de Gregor Zunic. Le temps d’exécution et le coût annoncés concernent cette démonstration. L’idée transposable est de choisir parmi les actions disponibles à chaque étape ; un autre parcours de navigation exige sa propre vérification.

La fraîcheur de l’état est essentielle. Si le compte ou la page sélectionnés changent pendant le jugement, écartez le résultat périmé. Associez les actions au compte et à l’état examinés.

Cela peut aussi rendre utile un catalogue d’interfaces typées. Un modèle choisit une vue connue et ses données délimitées ; le code de rendu habituel produit l’interface. Mesurez les tâches menées à bien et les actions erronées, en vérifiant particulièrement que les commandes restent compréhensibles.

Par où commencer

Choisissez la décision répétée qui crée déjà un gaspillage visible. Construisez le jeu d’évaluation à partir de ses échecs réels.

Problème actuel	Premier essai	Éléments à recueillir
La recherche répond à la mauvaise question	Juger une courte liste de résultats	Bonnes réponses, abstentions, latence
Les demandes passent d’une équipe à l’autre	Choisir parmi les files autorisées	Exactitude du premier routage, transferts
Les imports exigent une association manuelle	Choisir de vrais champs source	Erreurs d’association, temps de vérification
Chaque tâche utilise le plus gros modèle	Router les tâches admissibles	Coût par résultat accepté
Les réponses générées en disent trop	Vérifier les affirmations face aux sources	Affirmations non fondées qui passent
Personne n’utilise les transcriptions	Renvoyer des passages horodatés	Acceptation par les relecteurs, temps pour trouver une preuve
Les utilisateurs ne trouvent pas les commandes	Suggérer une action disponible	Taux d’achèvement, mauvais choix

Ne copiez pas le seuil de confiance d’une démonstration. La documentation de TypeSafe sur la confiance explique que la confiance de Choice et Score résume une distribution. Elle ne prouve ni que les entrées étaient complètes ni que l’action choisie est autorisée.

Incluez des cas où aucun candidat ne convient. Incluez un service indisponible. Incluez chaque langue que vous comptez prendre en charge. Conservez la version du modèle et les définitions des questions avec les résultats afin de comparer équitablement un changement futur.

Pour un produit d’intégration, je commencerais par la pertinence de la recherche et l’association des champs. Toutes deux raccourcissent le chemin vers une synchronisation qui fonctionne. Toutes deux permettent d’inspecter l’erreur avant qu’elle ne devienne un problème client.

Choisissez une mauvaise réponse que votre logiciel donne aujourd’hui. Faites-lui prendre de manière fiable la bonne étape suivante.