TLDR
- Jev est un modèle de décision System One de TypeSafe. Il renvoie des réponses typées avec des probabilités calibrées au lieu d'un texte.
- Dans nos tests, Jev répond en 100 à 200 millisecondes environ, contre 2 à 10 secondes pour les grands modèles de langage comparés.
- Thunders rend déjà les exécutions répétées déterministes en mettant les selectors en cache. Jev ne couvre que les étapes hors de portée du cache : premières exécutions, pages modifiées, étapes invalidées.
- Les limites de Jev aujourd'hui : texte uniquement, un budget d'état de 32k, pas de région européenne publiée, aucun benchmark indépendant, et il ne sait ni compter, ni calculer, ni comparer des dates.
- Les clients européens conservent le chemin d'inférence de Thunders résident dans l'UE. Les fournisseurs sans région européenne sont soumis à une activation client par client.
Jev est un modèle de décision System One publié par TypeSafe en septembre 2026, et il n'écrit pas de texte. Il lit un état, répond à des questions typées sur cet état, et renvoie un choix ou une probabilité.
Chez Thunders, nous l'avons testé, et adopté là où il apporte quelque chose.
Dans nos tests, Jev répond en 100 à 200 millisecondes environ, contre 2 à 10 secondes pour les grands modèles de langage de la même comparaison.
Pour l'automatisation des tests par l'IA, où chaque étape de test attend un modèle, cela change la forme du problème, pas seulement son réglage.
Cet article couvre ce qu'est un modèle System One, le niveau de déterminisme de vos exécutions selon le chemin emprunté, ce qu'un modèle plus rapide corrige ou non si vous construisez votre propre solution, et où se situent les limites de Jev aujourd'hui pour les tests web, mobile, API, desktop et SAP.
Qu'est-ce qu'un modèle System One, et en quoi diffère-t-il d'un LLM ?
Un modèle System One est un modèle de décision qui renvoie une réponse typée et une probabilité calibrée au lieu d'un texte. Vous lui donnez un état et une question au format de réponse fixe. Il renvoie la réponse et sa confiance. Il n'écrit jamais de phrase, donc rien n'a besoin d'être parsé, retenté ou réparé.
Un grand modèle de langage fait le travail inverse. Il génère des tokens un par un, si bien que la longueur de la réponse fixe la durée de l'attente. C'est le bon outil quand il faut un plan, du code, ou un test rédigé en langage naturel. C'est coûteux quand tout ce qu'il fallait était un oui ou un non.
TypeSafe a entraîné Jev avec RLCD, l'apprentissage par renforcement pour décisions calibrées, plutôt qu'avec RLHF. Posez deux fois la même question et TypeSafe rapporte des probabilités quasi identiques, là où les modèles comparés se contredisaient eux-mêmes, même à température 0. TypeSafe indique aussi que Jev est certifié SOC 2 Type II et ne s'entraîne pas sur les données clients.
Les limites décident de son utilité. Jev est textuel uniquement, n'accepte aucune image, et dispose d'un contexte de 64k tokens dont 32k pour l'état. Un écran que seul un modèle de vision peut lire n'est pas un cas System One.
Pourquoi l'automatisation des tests « fait maison » passe-t-elle autant de temps à attendre des modèles ?
Parce qu'une exécution de test est faite de nombreuses petites décisions, et que chacune coûte un aller-retour complet vers un modèle. Quelle action pour cette étape. Quel élément est visé. L'assertion est-elle passée. Aucune de ces questions n'a besoin de prose. Toutes payaient pourtant le prix de la prose.
Nos propres mesures disent combien.
En approche naïve, une simple classification d'étape prend un peu plus de 3 secondes en moyenne. La sélection d'élément tourne autour de 4 secondes et dépasse 10 secondes au 95e percentile. L'évaluation d'assertion dépasse 3 secondes en moyenne. Une résolution complète de selector à travers les étapes langage et vision coûte environ 8 secondes par tentative.
Multipliez n'importe lequel de ces chiffres par les étapes d'une vraie suite, et vous avez la raison pour laquelle l'automatisation des tests par l'IA paraît lente à des équipes à qui l'on avait promis l'inverse.
Comment Thunders rend-il déjà les exécutions répétées déterministes et rapides ?
Simple : en n'appelant aucun modèle sur la plupart des étapes.
Ce n'est pas nouveau, et ce n'est pas un modèle System One qui l'a rendu possible. Un test Thunders résout un élément avec l'IA à la première exécution, puis met en cache un selector déterministe. Les exécutions suivantes le rejouent directement. Aucun appel de modèle, aucun coût en tokens, aucune variance.
Sur une suite stable, les exécutions répétées sont déterministes et un à deux ordres de grandeur moins chères que d'envoyer chaque étape à un grand modèle de langage.
Jev n'est donc pas un sauvetage. C'est un nouvel outil qui s'insère dans une architecture déjà construite, et il répond à ce que le cache ne peut légitimement pas couvrir : la première exécution, une page modifiée (5 % des exécutions en moyenne), une étape que le cache a invalidée à raison.
C'est pour cela que Jev nous plaît. C'est l'étape suivante dans la recherche d'efficacité.
Quel est le vrai niveau de déterminisme de vos exécutions ?
Tout dépend du chemin qui répond à l'étape, et l'écart entre les trois est plus large que l'écart de vitesse.
| Chemin | Variance entre exécutions identiques | Ce que cela signifie pour votre suite |
|---|---|---|
| Rejeu depuis le cache Thunders | Déterministe par construction. Le selector en cache rejoue et aucun modèle n'est consulté | La même étape se résout de la même façon à chaque fois : une exécution rouge est une vraie régression, pas un modèle qui change d'avis |
| Décision System One (Jev) | Faible variance. TypeSafe rapporte des probabilités quasi identiques sur des questions répétées, et chaque réponse porte une confiance calibrée | Une décision limite apparaît comme un score bas sur lequel poser un seuil, au lieu d'une mauvaise réponse sûre d'elle |
| Appel LLM à chaque étape | Forte variance. TypeSafe rapporte que les modèles comparés se contredisaient eux-mêmes, même à température 0 | La même suite peut passer et échouer sur le même build, et votre équipe passe la semaine à séparer les vraies pannes du bruit de modèle |
Cet ordre compte plus que l'ordre des latences, et la plupart des comparaisons l'ignorent. Une suite de régression existe pour dire si le build du jour a cassé quelque chose que celui d'hier faisait bien. Une suite qui répond différemment sur des entrées identiques ne peut pas faire ce travail, quelle que soit sa vitesse.
Entre une suite plus rapide et une suite reproductible, nous choisissons la reproductible. C'est pourquoi le cache reste le premier étage et qu'un modèle System One s'insère derrière lui. L'appel de modèle le plus stable reste celui qu'on ne fait jamais.
Faible variance ne veut pas dire variance nulle. Jev resserre l'écart sur les décisions qui ont réellement besoin d'un modèle. Il ne les transforme pas en rejeu depuis le cache.
Quelles sont les limites de Jev aujourd'hui ?
Texte uniquement, un budget d'état de 32k, pas de région européenne, des rate limits que TypeSafe dit pouvoir modifier sans préavis, et aucun benchmark indépendant à notre connaissance. Ce qui vous pénalise dépend de ce que vous testez.
États-Unis uniquement. TypeSafe ne publie aucune région européenne pour Jev. Pour les clients européens, cela tranche la question à elle seule : c'est pourquoi Jev est placé derrière l'activation client par client décrite plus bas.
Un budget d'état de 32k, face à un DOM souvent plus grand. TypeSafe documente 64k tokens par requête, dont 32k pour l'état plus la question la plus longue. Le document de 54 Ko de sa démonstration de batching tient sans difficulté. Un DOM brut issu d'une grille de données dense, d'un long formulaire ou d'un écran SAP, souvent pas. Dans nos mesures, 25 % des applications d'entreprise franchissent largement cette limite de 32k avec leur DOM.
Aucune entrée visuelle. TypeSafe indique que Jev n'accepte que du texte, sans image, audio ni vidéo. Les applications canvas, les sessions desktop streamées et tout écran dont le sens vit dans les pixels restent du ressort d'un modèle de vision. Une décision System One ne peut pas remplacer cet étage, seulement ceux qui le précèdent.
Pas de benchmark indépendant, et une capacité encore en réglage. Tous les chiffres de vitesse et de calibration publiés à ce jour viennent de TypeSafe ou de ses utilisateurs, nous compris. Nous n'avons vu aucun benchmark tiers. La documentation de TypeSafe indique que ses rate limits s'ajustent dynamiquement face à une très forte demande, et qu'ils peuvent changer sans préavis. Une flotte de régression fonctionne par rafales : pour une plateforme de test, c'est une question de capacité, pas une note de bas de page.
Il ne sait ni compter, ni calculer, ni comparer des dates. TypeSafe liste les trois comme des modes de défaillance connus : Jev n'est pas une calculatrice, il ne compte pas de manière fiable, et il lit les dates comme du texte plutôt que comme des quantités ordonnées. Les assertions de test font exactement cela, en permanence. Des lignes dans une grille, un total sur une facture, une échéance dans le futur. Ces comparaisons relèvent du code, le modèle n'étant sollicité que pour la part de jugement.
Trois autres points qui comptent pour une suite plutôt que pour une démo. TypeSafe précise que la calibration se mesure sur des groupes de prédictions et ne garantit pas qu'une réponse individuelle soit correcte : un score de confiance dit comment router, pas si cette réponse est juste. Le modèle ne fournit aucune explication de son raisonnement, donc une mauvaise résolution vous laisse un chiffre et aucun pourquoi. Et l'alias jev-latest bouge à chaque nouvelle version, donc les réponses peuvent changer sans que rien ne change de votre côté. Épinglez la version si vous avez calibré vos seuils dessus. Pour une suite de régression, un modèle non épinglé est une variable silencieuse, précisément ce qu'une suite de régression existe pour éliminer.
Jev règle-t-il toutes les objections à construire sa propre automatisation des tests ?
Non. Un modèle de décision plus rapide supprime une ligne du coût de construction, et laisse les lignes les plus lourdes intactes.
Self-healing auditable. N'importe quel modèle peut recalculer un selector cassé. Votre release manager pose une autre question : qu'est-ce qui a changé, pourquoi, et qui l'a validé. Thunders enregistre le selector avant et après, l'étage qui l'a résolu, la capture d'écran et le récapitulatif de l'étape : une réparation est vérifiable et réversible. Un modèle plus rapide répare plus vite. Il ne produit pas la preuve, et du self-healing sans preuve, c'est une suite qui se réécrit en silence entre deux releases.
Infrastructure. Les exécutions demandent des navigateurs, des appareils réels et des émulateurs, des sessions desktop, de la capacité parallèle, des retries, du stockage d'artefacts, et une file d'attente qui survit à toute l'équipe qui pousse en même temps. Rien de tout cela ne devient moins cher parce qu'une décision prend 150 millisecondes au lieu de 3 secondes.
Collaboration. Une suite est un actif partagé, pas un script. Scénarios de test, test sets et plans de test, permissions, revue des étapes générées, historique d'exécution consultable, liens vers Jira, Linear ou Xray, déclencheurs CI, tableaux de bord lisibles par un product manager. C'est du travail de produit, et c'est pourquoi un harnais maison n'est jamais tout à fait terminé.
Évaluation et routage. Chaque décision appelle un modèle différent, et la bonne réponse change tous les quelques mois. Plus bas à ce sujet.
Sécurité et résidence. Où s'exécute l'inférence, et quels fournisseurs sont autorisés pour chaque client, sont des contraintes d'architecture, pas des réglages ajoutés après coup.
Jev entame sérieusement une de ces cinq lignes. Il ne touche pas aux quatre autres.
Qu'intègre Thunders, et quelle est la frontière RGPD pour les clients européens ?
Nous intégrons les décisions System One dans le produit, et nous soumettons le fournisseur à une activation client par client tant que la résidence des données n'existe pas. Les deux sont vrais en même temps, et il faut les lire ensemble.
Thunders exécute sa propre inférence IA dans l'UE. Tout fournisseur sans région européenne est soumis à une activation client par client, et les clients européens conservent le chemin résident dans l'UE. C'est un choix délibéré sur l'emplacement de vos données de test, et il tient quelle que soit la vitesse d'un modèle situé hors de cette frontière.
Thunders est certifié ISO 27001, SOC 2 et conforme au RGPD, et la résidence fait partie de cet ensemble plutôt que d'être un réglage. Quand une région européenne existe chez un fournisseur, la porte s'ouvre. En attendant, elle reste fermée, et le travail sur la vitesse continue avec les modèles que nous pouvons déjà exécuter à l'intérieur de la frontière.
Acheter ou construire : pourquoi le choix du modèle doit-il revenir à l'éditeur ?
Parce que ce travail est continu, et que ce n'est pas celui pour lequel votre équipe est payée. Une intégration contre un modèle, c'est une semaine. Maintenir une plateforme de test correcte à travers les modèles, c'est permanent.
Vous routez chaque décision vers un modèle différent, parce que le meilleur modèle pour la sélection d'élément n'est pas le meilleur pour l'évaluation d'assertion. Vous maintenez un golden set par décision. Vous relancez les évaluations à chaque changement de prompt ou de modèle, parce qu'un prompt qui améliore une décision en dégrade régulièrement une autre. Puis un meilleur fournisseur apparaît et vous refaites tout.
Thunders a migré de modèle plusieurs fois dans son pipeline sur la foi de ces évaluations, chaque migration justifiée par les chiffres du golden set plutôt que par une annonce de lancement. Une équipe qui construit sa propre automatisation des tests paie cette taxe pour toujours, en plus du produit qu'elle vend réellement.
Un client qui achète Thunders achète donc la capacité à changer de modèle, pas un modèle. Le modèle sous-jacent changera. Le harnais d'évaluation qui décide du moment est la partie durable.
Les éditeurs s'adaptent, et c'est cela le produit
Le meilleur modèle pour une décision donnée change tous les quelques mois. Toute architecture qui suppose le contraire est déjà datée.
Une plateforme dont la valeur est une abstraction de fournisseurs et un harnais d'évaluation devient plus rapide et moins chère sans que vous fassiez quoi que ce soit. Vous ne réécrivez pas un test, vous ne réenregistrez pas un parcours. Le routage change sous votre suite existante, et vos tests web, mobile, API, desktop et SAP s'exécutent plus vite sur les étapes que vous avez déjà écrites.
C'est le résultat sur lequel juger les éditeurs. Pas le modèle qu'ils utilisent aujourd'hui. Si un meilleur modèle au trimestre prochain vous parvient comme un gain de vitesse ou comme un projet de migration.
La place de Thunders
Thunders est une plateforme d'automatisation des tests par l'IA, sans code, qui couvre les applications web, mobiles, API et desktop, y compris SAP. Vous décrivez un parcours en langage naturel, et Thunders génère le test, l'exécute, et le maintient à mesure que votre interface change.
L'architecture décrite dans cet article est ce qui rend cela possible à grande échelle :
- La première exécution utilise l'IA, les suivantes rejouent un selector déterministe en cache : une suite stable est déterministe et un à deux ordres de grandeur moins chère qu'un appel LLM par étape.
- Le runner essaie le déterministe, puis un modèle de langage, puis un modèle de vision : vous payez l'étage dont chaque étape a besoin.
- Chaque réparation est enregistrée et vérifiable : une suite en self-healing conserve une piste d'audit.
- Le choix du modèle nous revient, pas à vous : une nouvelle classe de modèle comme Jev est une intégration pour nous, pas un projet pour vous.
Thunders couvre aujourd'hui les interfaces web de SAP et s'étend au client SAP GUI natif.
Créez un compte Thunders gratuit pour voir comment votre suite se comporte avec cette architecture, ou réservez une démo pour passer en revue les surfaces couvertes, le chemin d'inférence résident dans l'UE, et le routage de modèles sur vos tests.
Sources
- TypeSafe, System One : ce qu'est un modèle System One, et les formats de réponse typée qu'il renvoie.
- TypeSafe, Models : limites de contexte, rate limits et tarification de Jev.
- TypeSafe, Jev 1.13 jaggedness : les modes de défaillance que TypeSafe documente elle-même.
