Depuis sa sortie mi-septembre, Jev est partout. TypeSafe AI le présente comme un modèle « System One » : il ne génère pas de texte, il décide. On lui envoie une description de la situation et des questions typées (oui/non, choix parmi des options, note) ; il renvoie des probabilités calibrées, en une seule passe, en quelques dizaines de millisecondes. Les chiffres annoncés font rêver : jusqu'à 200 fois plus rapide qu'un LLM de pointe, pour une fraction du prix.

Or mon EMS (le système qui pilote la maison : batterie, panneaux, chauffe-eau, borne de recharge) passe son temps à répondre à une question binaire : cet appareil doit-il tourner maintenant ? Chaque minute, pour chaque appareil. L'occasion était trop belle : j'ai branché Jev sur mon banc de test et je l'ai mis face au programmateur que je développe et régle depuis des mois.

Une contrainte en plus : à terme, tout doit tourner en local, sur un Raspberry Pi 4 ou 5 avec 2 Go de RAM. Pas question d'appeler une API dans le cloud pour allumer un chauffe-eau.

Trouver un Jev qui tient sur un Raspberry Pi

Jev lui-même est fermé : poids non publiés, accès uniquement par l'API hébergée de TypeSafe. Mais en quelques jours, la communauté a publié des clones à poids ouverts qui parlent le même protocole (POST /v1/systemone).

jevos-v4 coche les cases : un seul binaire, CPU uniquement, pas de Python, environ 1 Go de mémoire, et une version GGUF pour llama.cpp qui devrait passer sur ARM. Sur son propre banc, l'auteur annonce 28 à 130 ms par décision sur un portable, et une juste une pertinence en retrait de Jev (par exemple 0,76 contre 0,91 sur des règles de location) mais devant Qwen3.5-4B, un LLM quatre fois plus gros.

Le banc de test

Mon banc de test, présenté dans l'article précédent, rejoue l'historique réel de l'installation, minute par minute : production solaire mesurée, consommation de la maison, tarif heures pleines / heures creuses et physique de la batterie. Il fait tourner la vraie machinerie du moteur de l'EMS (gestion de la batterie, charge en heures creuses), et seule la décision des appareils change d'un bras (levier de test du banc) à l'autre.

Le scénario :

• un chauffe-eau de 1 200 W, avec un quota de 3 kWh à livrer chaque jour (on peut le chauffer au réseau en heures creuses si le soleil n'a pas suffi) ;
• une voiture électrique de 2 800 W, sans quota : elle ne doit se charger qu'avec de l'énergie « gratuite » (surplus solaire, batterie), jamais au réseau ;
• une batterie de 7,2 kWh, 13 jours de juin, un pas de décision de 15 minutes.

Le critère : la facture à service égal. Un programmateur qui ne livre rien ne paie rien ; on ajoute donc à la facture l'énergie non livrée, valorisée au prix des heures creuses.

Comment interroge-t-on Jev ?

J'ai suivi le conseil de l'auteur de jevos : « mettez la règle dans la question, faites les calculs dans le code ». À chaque pas, le code calcule les faits (heure, tarif, production, consommation, surplus, charge de la batterie, prévision, énergie restant à livrer, surplus laissé par les appareils prioritaires) et les écrit en texte. Une question oui/non par appareil, une seule requête pour tous. Extrait réel (libellés des appareils simplifiés) :

Time 12:00. Sun is up.
Electricity tariff now: PEAK (expensive grid).
Solar production now 3600 W, house consumption without the controlled devices 100 W, solar surplus 3500 W.
Solar forecast: 3600 W next hour, 17.5 kWh for the rest of today, tomorrow 15 kWh.
Home battery 7.2 kWh, charge 99 %, it never goes below 20 %.
Controlled devices, by priority (1 = first served):
1. Water heater (water-heater), 1200 W, currently OFF (full, absorbs nothing), daily quota 3 kWh, 0 kWh still due
   before next sunrise; surplus left for it after higher-priority running devices: 3500 W.
2. EV (ev-charger), 2800 W, currently OFF (full, absorbs nothing), no quota (runs only on free energy); surplus left
   for it after higher-priority running devices: 3500 W.

Les seules règles appliquées en dur sont celles que la production impose déjà en dehors du programmateur : ne pas rallumer un appareil plein ou débranché, respecter les durées minimales de marche et d'arrêt. Tout le reste, c'est Jev.

Deux variantes :

• Jev libre : les faits et l'objectif (« livrer ce dont chaque appareil a besoin en payant le moins possible »), sans règle ;
• Jev règles : les mêmes faits, plus mon contrat en toutes lettres (« jamais de réseau en heures pleines », « en heures creuses, le chauffe-eau prend le réseau s'il lui reste de l'énergie due », « un appareil sans quota n'utilise jamais le réseau »…).

Résultat : un échec net

• Jev libre n'allume presque rien. Même quand le surplus couvre largement le chauffe-eau, il répond « non » dans 96 % des cas.
• Jev règles livre tout, mais en violant la règle la plus explicite qu'on lui ait donnée : la voiture est chargée en heures pleines, sans surplus, dans 85 % des cas. À l'inverse, le chauffe-eau n'est allumé que dans 6 % des cas où le surplus le couvrait.

Résultat : 4,7 fois la facture du programmateur maison à service égal, dans le meilleur des cas.

Côté vitesse aussi, la promesse se nuance : avec une description d'environ 500 tokens, il faut 330 à 690 ms par décision sur un Mac récent. Sur un Raspberry Pi, il faut compter plusieurs secondes. Ça tiendrait dans un cycle d'une minute, mais avec ces décisions-là, ça n'a pas d'intérêt.

Est-ce la taille du modèle ?

0,9 milliard de paramètres, c'est très petit pour un modèle. Pour trancher, j'ai repris 40 situations réelles du rejeu dont je connais la bonne réponse (20 où il fallait allumer, 20 où il fallait éteindre) et j'ai posé la même décision au modèle sous trois formes.

Le même modèle passe de 23 à 34 bonnes réponses quand on ne lui présente qu'un appareil à la fois. Ce n'est pas d'abord la taille, c'est la forme de la question. Une description longue, plusieurs appareils dans le même texte, la bonne ligne de chiffres à retrouver, une règle à plusieurs conditions : c'est trop pour lui. En forme B, il se comporte proprement :

Il bascule bien autour de la puissance de l'appareil, avec un peu de flou juste au seuil. En heures creuses, il répond 0,99 pour un chauffe-eau à qui il reste de l'énergie à livrer, et 0,06 pour un chauffe-eau plein.

La taille joue, mais pas assez : la section suivante repasse l'essai avec un modèle quatre fois plus gros.

Et avec un modèle plus gros ?

Pour ne pas rester sur un doute, j'ai refait les mêmes essais avec OpenJev-4B, un clone à poids ouverts quatre fois plus gros que jevos. Il ne tiendrait pas sur un Raspberry Pi de 2 Go (8,4 Go), mais il donnera la tendance d'un modèle nettement plus capable.

1. Les 40 situations réelles, trois formes de question

La compréhension d'une requête longue était donc bien en partie une affaire de taille : la forme A passe de 58 % à 93 %.

2. Le banc complet (13 jours de juin)

Le gros modèle comprend mieux : il respecte la règle « jamais de réseau en heures pleines » que jevos violait. Mais il devient frileux et n'allume la voiture qu'à un tiers de son besoin. Résultat : 7,47 €, toujours environ cinq fois la facture du programmateur.

3. Vingt décisions écrites à la main (dont des arrêts d'appareils allumés). Avec un appareil par question, OpenJev ne se trompe sur aucune des 15 décisions notées ; avec l'état complet, il en rate 3 sur 15 : deux juste sous le seuil de 0,5 (0,47 et 0,48), et la règle « le chauffe-eau prend le réseau en heures creuses » (0,32). C'est exactement ce qui sous-alimente la voiture au banc.

4. Combien de raisonnement peut-on lui laisser ? 150 situations de coucher tirées au hasard (407 décisions, dont 70 % à moins de 2,5 kWh du seuil), avec pour vérité la fonction exacte du programmateur qui décide d'abandonner ou non le rattrapage nocturne d'un appareil. On fait lire au modèle une version de plus en plus « brute » du même problème :

Le modèle compare parfaitement, mais ne calcule pas : dès qu'il faut une soustraction, il perd près de vingt points, et au-delà il répond au hasard. Ses erreurs vont presque toutes dans le même sens (abandonner un quota que le soleil ne couvrira pas), le plus coûteux. Il ne génère pas de texte, donc il ne peut pas poser un calcul étape par étape : tout se joue en une seule passe. Et la comparaison à 99 % tombe à 68 % si on retire la phrase de contexte qui ouvre la requête : la formulation pèse presque autant que la taille.

La sentence ne bouge pas. Un modèle plus imposant lit mieux, et c'est tout : le bilan est le même qu'avec jevos, juste un peu meilleur. Ce que fait le programmateur, c'est du calcul sur l'avenir, et le seul morceau que le modèle exécute sans faute (la comparaison) est celui que le code fait déjà gratuitement. Pour cette utilisation, je rejette Jev, petit ou gros.

Même bien interrogé, il ne peut pas gagner

C'est la leçon la plus intéressante. La forme B fonctionne… parce que le code a déjà fait le travail. C'est lui qui calcule le surplus laissé par les appareils prioritaires, lui qui écrit la règle. Jev se contente d'appliquer « surplus suffisant, ou heures creuses pour le chauffe-eau ». C'est un routeur de surplus : il n'utilise ni la batterie, ni la prévision solaire, ni le report d'une charge à plus tard.

Ce plafond, je l'avais mesuré sans le vouloir. Pour tester la plomberie du banc, j'avais écrit un faux serveur qui applique exactement cette règle simple, sans jamais se tromper. Sur les mêmes 13 jours (avec une prévision parfaite) :

Autrement dit, un Jev parfait, interrogé de la meilleure façon, ferait au mieux 2,5 fois la facture du programmateur. Ce qui fait la valeur du programmateur (savoir qu'il vaut mieux attendre le soleil de 14 h plutôt que charger au réseau à 6 h, quand puiser dans la batterie, comment répartir le surplus entre plusieurs appareils), c'est de l'arithmétique sur l'avenir. Et c'est exactement ce que Jev demande qu'on fasse dans le code.

Ce qu'on en retient

1. Jev n'est pas un moteur d'optimisation. C'est un classifieur rapide et bien calibré pour des jugements élémentaires. Lui confier une allocation d'énergie, c'est lui demander de faire des additions, ce qu'il déconseille lui-même.
2. La forme de la question compte plus que la taille du modèle, et la taille ne suffit pas. Une question par entité, des faits courts, une règle simple : la justesse de jevos grimpe de 58 % à 85 %. Un modèle quatre fois plus gros comprend mieux les requêtes longues (93 %), mais ne sait pas calculer : il compare à 99 %, perd près de vingt points sur une soustraction et répond au hasard au-delà.
3. Un « oui/non » n'est pas forcément un problème binaire. La décision semble binaire, mais elle dépend de la prévision, de la batterie, des autres appareils et de l'échéance du quota. Le binaire, c'est la sortie, pas le raisonnement.
4. Là où il pourrait servir : le texte libre. Une consigne de l'utilisateur (« je pars en week-end », « charge la voiture pour demain 7 h »), un bulletin météo, un agenda. Transformer ça en faits structurés que le programmateur consomme : c'est le genre de jugement que le code fait mal, et que Jev fait bien.

Mon programmateur maison garde donc la main. Le banc reste branché : si une version plus forte de Jev sort, il suffira de changer une URL pour la remettre à l'épreuve, même si un modèle quatre fois plus gros n'a pas fait bouger la conclusion.

Limites de l'étude

1. 13 jours de juin sur une seule installation, deux appareils pilotés, décision toutes les 15 minutes (le programmateur de production décide chaque minute).
2. Deux clones testés (jevos-v4, 0,9 milliard de paramètres, et OpenJev-4B) ; le Jev hébergé de TypeSafe et OpenJev-8B n'ont pas été essayés. Les essais sur OpenJev ne portent que sur un tirage et une seule formulation des requêtes : d'autres tournures pourraient changer quelques points, pas l'ordre de grandeur.
3. Le test des trois formes porte sur 40 situations ; parmi les 20 où il fallait allumer, aucune ne relevait de la règle « heures creuses + chauffe-eau ».
4. Le plafond de la règle simple (3,45 €) a été mesuré avec une prévision parfaite, les bras Jev avec la prévision réelle de production : les deux scores du programmateur (1,35 € et 1,46 €) servent de repère respectif.

Sources

• TypeSafe AI — Introducing System One Models & Jev
• Tom's Hardware — TypeSafe AI's Jev offers an alternative to LLMs
• TechTarget — Jev decision model touted as quicker, cheaper LLM alternative
• feder-cr/jev — jevos-v4 · modèle sur Hugging Face
• wfzyx/von · alanhuangyoo/OpenJev