# Pourquoi nous avons créé Strom, un modèle de décision européen alternatif

> Les petits modèles de décision perdent en accuracy. Les grands demandent des GPU de datacenter et un post-training lourd. Aucun modèle ouvert n’a égalé Jev dans l’ensemble, et Jev ne voit pas les images. Nos données devaient rester dans l’UE. Alors nous avons entraîné le nôtre, et c’est désormais une API.

Marco Herzog · 3 oct. 2026 · 11 min de lecture · Entreprise
Canonical: https://platform.uprelic.com/fr/blog/strom-modele-de-decision-alternative-europeenne-a-jev
Deutsch: https://platform.uprelic.com/de/blog/strom-eu-alternative-entscheidungsmodell-zu-jev.md
English: https://platform.uprelic.com/blog/strom-eu-alternative-decision-model-to-jev.md

---

La plupart d’entre vous ont sans doute déjà testé des modèles de décision open source, voire construit le leur. Depuis le lancement de Jev le 15 septembre, l’idée d’un modèle qui ne fait que décider (oui ou non, un score, une option parmi plusieurs) s’est répandue plus vite que tout ce que nous avions vu. Selon un décompte, Hugging Face comptait plus de 1 300 dépôts de modèles de décision dix-huit jours plus tard.

Nous aussi, nous construisions sur ces modèles. Et nous retombions toujours sur les mêmes problèmes.

## Ce que nous avons rencontré

### Les petits modèles perdent en accuracy

Les modèles de décision sont faciles à cloner, et les petits sont tentants, car ils tournent sur un ordinateur portable. Mais l’accuracy chute vite en dessous de quelques milliards de paramètres. La famille kev a publié la courbe la plus claire à ce jour, sur sa propre suite de tests.

![Diagramme en barres de l’accuracy de test selon la taille du modèle dans la famille kev, avec 69,7 % à 0,8B, 83,8 % à 4B, 85,2 % à 9B et 88,9 % à 27B paramètres](https://platform.uprelic.com/blog/media/strom-eu-alternative-decision-model-to-jev/size-curve.fr.svg "L’accuracy progresse le plus vite jusqu’à 4B. De 4B à 27B, elle gagne encore 5,1 points, soit environ un tiers d’erreurs en moins. Données issues du split de test new-source de la famille kev.")

Le plus petit modèle se trompe presque une fois sur trois, et ses probabilités sont bien moins fiables, avec un score de Brier de 0,416 contre 0,156 à 27B (plus bas, c’est mieux). Les deux comptent quand on veut automatiser une décision. Une mauvaise réponse assortie d’une probabilité assurée est pire que pas de réponse du tout.

Les plus grands modèles continuent de payer là où cela compte pour l’automatisation. De 4B à 27B, le taux d’erreur passe de 16 % à 11 %, le score de Brier de 0,242 à 0,156, et seul le modèle 27B garde son accuracy sur des inputs jusqu’à 64K tokens, contre 8K pour les plus petits. Une partie de l’écart tient à la méthode, puisque le modèle 27B a été entraîné en full fine-tuning et les plus petits avec des adaptateurs LoRA.

### Les grands modèles demandent des GPU de datacenter et un post-training lourd

La classe 27B et au-delà est précise, mais elle tourne sur des GPU de datacenter. Les poids de base ne suffisent pas. Un petit modèle, Laya, obtient 36 % sur un benchmark de décision avant le fine-tuning et 77 % après. Pour les modèles de décision, le fine-tuning, c’est le modèle. Toute équipe qui veut cette accuracy doit payer l’entraînement, puis les GPU.

La taille détermine aussi jusqu’où le post-training peut mener un modèle. Dans une étude de 2026 sur le supervised fine-tuning de modèles allant jusqu’à 235B paramètres, les plus grands modèles étaient nettement meilleurs après le même entraînement, avec des rendements décroissants, et davantage en full fine-tuning qu’avec des adaptateurs LoRA. Davantage d’exemples d’entraînement a aidé chaque taille dans à peu près la même proportion ([O’Neill et al., 2026](https://arxiv.org/abs/2609.01244) ; voir aussi [Zhang et al., 2024](https://arxiv.org/abs/2402.17193)). Les grands modèles ont en outre besoin de moins de données pour atteindre leur meilleur niveau. Sur des données d’entraînement synthétiques, un modèle 8B a atteint son optimum à 1 000 milliards de tokens, un modèle 3B seulement à 4 000 milliards ([Qin et al., 2025](https://arxiv.org/abs/2503.19551)). Pour un modèle de décision dont les données d’entraînement ne cessent de croître, c’est tout l’enjeu, car une base plus grande garde son avance à chaque nouvelle série de données.

La plupart des projets open source n’utilisent pas de données d’entraînement étendues, ne les nettoient généralement pas assez et ne les enrichissent pas avec des données synthétiques. Pour être juste, c’est trop coûteux pour l’open source. Pour obtenir un modèle performant, toute la data pipeline doit être un investissement, avec un entraînement continu. Pour nous, cela signifie servir un modèle tout en en entraînant plusieurs autres, et préparer déjà les données de la deuxième génération.

### Jev ne voit pas les images

Tout d’abord, un grand bravo à TypeSafe AI, les créateurs de Jev. Ils ont ouvert une toute nouvelle classe de modèles, et suscité l’enthousiasme pour de nouveaux use cases. Ils méritent vraiment le respect pour l’idée et pour les nombreuses approches nouvelles qui en découleront.

Une grande pièce manquante, et décisive pour nous, est que Jev ne traite pas les images. Pour beaucoup de nos cas, c’est indispensable. Parfois, une image sert de fallback quand le texte ne suffit pas, comme la photo jointe à une déclaration de sinistre ou le screenshot d’un ticket de support. Parfois, il n’y a pas de texte du tout, comme pour une photo produit qui doit respecter des règles de publication ou une question de design. Vous voyez l’idée.

Les images sont tout aussi importantes pour notre prochaine extension, un browser agent. Un agent web décide aussi en fonction de ce qu’il voit, comme le bouton sur lequel cliquer, si un formulaire a été correctement rempli, si une page affiche une erreur et demande un fallback visuel, et que faire quand il n’y a pas de DOM du tout, comme sur un canvas. Parfois, il regarde simplement pour vérifier. Le texte de la page omet souvent l’essentiel, si bien que le screenshot fait partie de l’état. Un modèle de décision qui ne sait pas lire une image ne peut pas piloter l’agent de façon fiable.

![Strom et Jev côte à côte sur Google Flights, pilotant le même browser agent vers le même aller-retour de Zurich à New York](https://platform.uprelic.com/blog/media/strom-eu-alternative-decision-model-to-jev/strom-vs-jev.mp4 "Le même code d’agent et le même objectif, lancés ensemble ; seul le modèle qui décide change. Les deux reçoivent la même instruction pour les date pickers, à savoir cliquer sur le champ, puis sur la date, puis confirmer. Après la date de départ, Google laisse le calendrier ouvert avec le champ du retour déjà actif. Jev suit l’instruction à la lettre et clique encore et encore sur le champ, tandis que Strom choisit directement le 27 octobre, à partir du même texte de page et sans screenshot. Strom trouve les vols en 7,7 secondes. Sur l’ensemble de nos runs enregistrés de cette tâche, Strom en a réussi 20 sur 20 et Jev environ 1 sur 12. Cela montre une situation que les instructions de l’agent ne couvrent pas, pas un classement général.")

Dans les prochains articles, nous reprendrons ces use cases un par un, des photos de sinistres pour les assurances et des screenshots dans les tickets de support aux photos produit face aux règles de publication et au browser agent.

### Et nos données devaient rester dans l’UE

Beaucoup des décisions que nous automatisons portent sur des données personnelles, comme des e-mails clients, des factures et des photos. Au titre du RGPD, chaque prestataire qui traite ces données pour vous a besoin d’un contrat de sous-traitance (DPA), et tout transfert hors de l’UE exige ses propres garanties. Le chemin le plus court vers la conformité était donc notre propre modèle sur des GPU à Paris, exploités pour nous par Scaleway, un fournisseur cloud français, sans fournisseur d’IA tiers entre les deux. Quand le délégué à la protection des données d’un client demande où vont ses données, nous voulions une réponse simple. Elles sont traitées en France.

## Alors nous avons entraîné le nôtre

Strom est un grand modèle vision-langage, entraîné par fine-tuning sur des décisions métier dans 14 domaines à ce jour, de l’assurance et la finance à l’ingénierie mécanique et au travail de bureau, avec des tâches allant des factures et contrats aux logs de machines et aux agents web. Il accepte du texte libre, du JSON ou des images, et répond à des questions nommées avec l’une des options que vous définissez, plus une probabilité pour chaque option. Il parle le même format de requête que Jev, avec des questions de type `choice`, `score` et `noul`. Pour sa taille et sa précision, il lui faut des GPU de datacenter.

## Pourquoi c’est désormais une API

Nous avons surtout construit Strom pour nous-mêmes, pour [uprelic.com](https://uprelic.com), notre service principal, un chat de co-work. Dans de prochains articles, nous montrerons comment cette classe de modèles peut aussi améliorer les applications de chat, car certaines approches, comme le model routing, séduisent en théorie mais ne sont pas encore réalisables. En même temps, il était évident que d’autres équipes avaient les mêmes besoins, comme des décisions à automatiser, des données qui doivent rester dans l’UE, des inputs qui sont souvent des images et une workflow pipeline très bon marché, mais sans la capacité de construire et d’améliorer en continu un modèle elles-mêmes.

Alors nous l’ouvrons. Strom coûte **0,042 $ par million de tokens d’input, et l’output est gratuit**, le même prix par token que Jev.

## Les performances de Strom

Une précaution avant les chiffres. La propre suite de tests d’un modèle en dit peu sur la façon dont il se compare aux autres. kev-27B obtient 88,9 % sur la suite de kev, devant les 85,7 % de Jev sur cette même suite, et pourtant aucun modèle ouvert n’a égalé Jev dans l’ensemble. Les équipes construisent leurs tests autour de ce sur quoi leur modèle a été entraîné, souvent sans le vouloir. Cela vaut aussi pour nous. Nous nous en tenons donc aux benchmarks publics, signalons où nos runs ne sont pas entièrement propres et continuons d’améliorer notre façon de mesurer, avec davantage de benchmarks held-out et indépendants au fil du temps.

Nous avons mesuré Strom 1.0.7 en production le 1er octobre 2026, sur des benchmarks publics pour lesquels les résultats d’autres modèles sont publiés. Voici ce que nous avons trouvé, y compris là où Strom est derrière.

### À égalité avec Jev sur JevBench

Sur les 231 tâches publiques de JevBench, Strom en réussit 201. Jev 1.13 en réussit 200, selon les résultats publiés.

| Système | Réussies (sur 231) | Brier | ECE |
|---|---:|---:|---:|
| GPT-6 Astra (reasoning, low) | 231 (100 %) | 0,009 | 0,015 |
| GPT-5.6 Luna (sans reasoning) | 206 (89,2 %) | 0,207 | 0,093 |
| **Strom 1.0.7** | **201 (87,0 %)** | **0,167** | **0,033** |
| Jev 1.13.0 | 200 (86,6 %) | 0,181 | 0,032 |
| Open-Jev 27B v1.1 | 197 (85,3 %) | 0,242 | – |
| Open-Jev 9B | 179 (77,5 %) | 0,322 | 0,086 |
| Open-Jev 2B | 150 (64,9 %) | 0,475 | 0,127 |

Le modèle de reasoning réussit tout, avec une médiane de 2,2 secondes par réponse. Strom a répondu en 136 ms en médiane, mesuré depuis un client en Allemagne, réseau compris. Les latences des résultats publiés proviennent d’autres clients, donc seules les colonnes d’accuracy et de calibration se comparent directement.

Les probabilités de Strom sont bien calibrées. Une Expected Calibration Error (ECE) de 0,033 signifie que sa confiance affichée s’écarte en moyenne d’environ trois points de la fréquence à laquelle il a réellement raison. C’est ce qui rend les seuils utilisables. Si 0,9 veut dire juste neuf fois sur dix, votre code peut agir en conséquence.

Strom réussit toutes les tâches d’extraction, d’intent, de routing, de policy, de tool selection et d’ordinal scoring. Son point le plus faible concerne les questions de dates et de chiffres (5 sur 15). Il peine aussi sur les longues policies (12 sur 19) et les questions multi-hop qui enchaînent plusieurs faits (13 sur 18). Nous y travaillons dans notre prochain cycle d’entraînement.

### Là où Jev est devant

Sur les suites de contrôle publiées par Open-Jev, Jev est devant.

| Suite | Strom 1.0.7 | Jev 1.13.0 |
|---|---:|---:|
| FizzBuzz (300) | 264 | 299 |
| Mailroom (921) | 898 | 908 |
| JF100 (300) | 209 | 232 |

Les erreurs suivent un schéma. Sur FizzBuzz, Strom ne rate jamais « divisible par 5 », mais répond oui à « divisible par 3 » pour des nombres comme 13 et 29. Chaque erreur sur Mailroom est un faux positif, un oui à tort. Sur JF100, les relations, les dates et l’arithmétique concentrent la plupart des erreurs, tandis que les règles de policy et le discourse sont parfaits. Là aussi, nous corrigeons cela dans les données d’entraînement, une famille de tâches après l’autre.

### Un premier signal sur les images

Image JevBench publie des questions et des réponses, mais pas d’images, nous avons donc reconstruit nous-mêmes une partie des images. Sur ses 128 éléments de preview publics, Strom en réussit 94 (73,4 %). Le meilleur système de la propre preview du benchmark obtenait 59,4 %. Voyez cela comme un sanity check, pas comme un score, car 68 des images sont les nôtres, et certaines de nos versions sont probablement plus faciles que les originales. Une vraie comparaison nécessite un run sur le jeu scellé du benchmark.

### Vitesse

Le temps passé dans le modèle dépend surtout de ce que vous envoyez. Le graphique montre des médianes de 10 requêtes par point, avec un contenu nouveau à chaque fois, mesurées en production.

![Graphique en lignes du temps médian dans le modèle selon le nombre de tokens d’input, où le texte passe de 91 ms à 550 tokens à 228 ms à 8 000 et 673 ms à 24 000, et une image de 58 ms à 168 ms entre 256 et 1024 pixels de large](https://platform.uprelic.com/blog/media/strom-eu-alternative-decision-model-to-jev/speed.fr.svg "Une question oui ou non sur 550 tokens de texte prend 91 ms, sur 8 000 tokens 228 ms ; une image prend 58 ms à 256 pixels de large et 168 ms à 1024. Production, 1er octobre 2026.")

Ajoutez votre aller-retour réseau, d’environ 100 ms depuis l’Allemagne. Le [guide de latence](https://platform.uprelic.com/docs/latency) contient toutes les mesures, y compris la façon dont davantage de questions et d’options s’additionnent. Nous prévoyons d’opérer depuis d’autres sites pour réduire la latence.

## Notre pari

Dix-huit jours plus tard, les modèles de décision sont une catégorie. Le format a été reconstruit par un laboratoire ouvert, un runtime, un CDN et des centaines d’auteurs indépendants. Les poids seuls ne seront un moat pour personne. Ce qui reste, c’est ce qu’un fine-tuning d’un week-end ne fournit pas, à savoir des probabilités calibrées sur lesquelles poser des seuils et une data pipeline continue, sur une infrastructure qui traite vos données dans l’UE.

C’est à cela que sert Strom. La [documentation](https://platform.uprelic.com/docs) explique comment envoyer votre première requête.

---

### Données et méthode

Nous avons mesuré Strom 1.0.7 en production le 1er octobre 2026. Pour JevBench, nous avons utilisé les 231 tâches publiques avec le format de requête et le scoring du harness Open-Jev, et repris les résultats des autres systèmes sur la page de benchmarks d’Open-Jev. Nous avons reconstruit les suites de contrôle (FizzBuzz, Mailroom, JF100) comme Open-Jev les a construites et vérifié les 1 521 gold labels par rapport aux lignes publiées par Open-Jev. Deux éléments de nos données d’entraînement se sont révélés proches de tâches de JevBench, une longue policy et une question de date, donc ces deux slices ne sont pas entièrement propres pour Strom. Les chiffres de kev proviennent de l’évaluation publiée de la famille kev (split de test new-source), ceux de Laya de la model card publiée par Convai Innovations, et le décompte de l’écosystème des dépôts Hugging Face portant des tags de modèles de décision et créés après le 15 septembre 2026.