Quand on parle d'IA, on pense presque toujours aux grands modèles de langage : on leur écrit du texte, ils répondent en texte. Mais pour certaines tâches, ce format est inadapté. Un robot sur une chaîne, un système qui doit décider plusieurs fois par seconde, un programme qui attend une valeur précise et pas une phrase…
Dans cette vidéo, on teste Jev, le nouveau modèle de TypeSafe, présenté comme un modèle « System One ». TypeSafe a donné un accès en avant-première pour le tester. Le défi : lui faire jouer seul à un casse-brique, un cas qui ne pardonne pas.
Le principe de Jev est différent de celui d'un LLM :
- on lui envoie un état : l'état de l'application, en JSON ;
- on lui pose des questions typées, par exemple un Choice (choisir parmi des options), un Score ou d'autres types ;
- il renvoie une valeur typée, accompagnée de sa probabilité.
Aucun texte généré, rien à analyser : le code utilise directement la réponse. Pour un développeur, c'est la différence entre demander « où dois-je mettre la raquette ? » et interpréter une phrase, et obtenir directement une valeur, par exemple « zone 7, probabilité 0,83 ».
Le nom « System One » fait écho à la distinction classique en psychologie entre la pensée rapide et intuitive (système 1) et la pensée lente et réfléchie (système 2). Un LLM qui raisonne longuement ressemble au second ; Jev vise le premier.
Avant de brancher l'IA, il faut un jeu. Il est codé avec Claude Code, avec la stack suivante : Next.js 16, React 19, TypeScript, Tailwind 4.
Deux étapes marquantes :
- un bug de latence, finalement lié à l'accélération graphique de Chrome ;
- l'ajout d'un panneau de données en temps réel, pour voir ce qui se passe à chaque instant.
Le branchement se fait avec le SDK de TypeSafe (@typesafe-ai/sdk) :
- une route côté serveur, pour que la clé d'API ne quitte jamais le serveur, un bon réflexe de sécurité ;
- une question de type Choice : l'écran est découpé en 16 zones de 50 pixels, et Jev choisit la zone où placer la raquette ;
- une requête toutes les 150 ms au maximum.
Premier essai en direct : l'IA pilote la raquette. La latence, mesurée dans l'onglet Network du navigateur, est de 200 à 300 ms par décision, aller-retour compris. Soit plusieurs décisions par seconde.
Ensuite, on pousse le système : la balle accélère, puis arrivent les briques surprises et les multiballes, jusqu'à ce que Jev décroche. C'est le genre de test qui montre les limites réelles d'un système, bien mieux qu'une démo lisse.
Les chiffres mesurés dans la vidéo :
| Mesure | Valeur |
|---|
| Tarif annoncé | 0,042 $ par million de tokens en entrée, sortie gratuite |
| 700 requêtes | 867 000 tokens, soit 3 centimes |
| Une partie complète | 1,3 million de tokens, soit 5 centimes |
À ce prix-là, on peut envisager des usages où un modèle prend des milliers de décisions sans que la facture explose.
Le débrief de la vidéo évoque plusieurs pistes au-delà du jeu :
- la robotique industrielle, où il faut décider vite et souvent ;
- les garde-fous (guardrails), pour classer rapidement une requête ou une action ;
- les décisions à la chaîne, où chaque réponse doit être une valeur exploitable par le code.
La vidéo montre aussi un journal de décisions, utile pour comprendre ce que le modèle a choisi et avec quelle confiance, et aborde le modèle économique de TypeSafe.
L'exercice oblige à repenser la façon de poser un problème à une IA. Au lieu d'écrire un prompt, on décrit l'état du monde et on pose une question fermée.
Pour le casse-brique, l'état pourrait ressembler à ceci (exemple illustratif, pas le format exact du SDK) :
{
"balle": { "x": 412, "y": 530, "vx": -3.2, "vy": 5.1 },
"raquette": { "zone": 9 },
"briques_restantes": 37
}
Et la question : « dans laquelle des 16 zones placer la raquette ? ». La réponse est une zone, avec une probabilité, que le code applique directement.
Quelques principes qui ressortent de ce test, applicables à d'autres projets :
- découper l'espace de décision en options discrètes (ici 16 zones de 50 pixels) rend la question simple et la réponse directement exploitable ;
- limiter la fréquence des requêtes (ici une toutes les 150 ms) évite de saturer le service et reste suffisant pour un jeu ;
- garder la clé côté serveur, toujours ;
- journaliser les décisions et leur probabilité, pour comprendre les erreurs.
Ce test rappelle que « l'IA » ne se résume pas aux LLM. Pour une tâche donnée, la bonne question est : de quel type de réponse ai-je besoin, et en combien de temps ?
- pour raisonner, écrire, coder, un LLM comme Claude reste l'outil adapté ;
- pour décider vite une valeur typée à partir d'un état, un modèle spécialisé peut être bien plus rapide et moins cher.
Et les deux se combinent très bien : dans cette vidéo, c'est Claude Code qui a construit le jeu, et Jev qui joue.
La prochaine expérience envisagée : les échecs ou le go.
- Jev, de TypeSafe : un modèle « System One », qui répond par des valeurs typées et non du texte.
- Un casse-brique en Next.js 16 codé avec Claude Code, et une raquette pilotée par Jev.
- 200 à 300 ms par décision, 5 centimes la partie complète.
- Des usages possibles en robotique, garde-fous et décisions à la chaîne.
