Historique des éditions

Il y a neuf jours, j’ai écrit sur un modèle appelé Jev.

Ce qui m’intéressait n’était pas le langage de lancement autour des « System One Models ». C’était l’idée plus petite en dessous : peut-être que l’unité utile d’intelligence dans un logiciel n’est parfois ni un agent, ni une conversation, ni un paragraphe.

Peut-être que c’est un jugement.

Une question bornée. Un espace de réponses défini. Une probabilité. Puis le code décide de la suite.

Depuis, quelque chose de prévisible s’est produit.

La lune de miel a duré à peu près zéro temps.

Les billets sont apparus. Certains réfléchis, certains irrités, certains presque offensés par l’attention reçue par Jev.

Ce n’est qu’un classificateur.

On avait ça il y a vingt ans.

Les modèles probabilistes ne sont pas nouveaux.

La calibration n’est pas nouvelle.

L’industrie a oublié l’apprentissage automatique et le redécouvre maintenant.

Une version allait plus loin : c’était la preuve que l’IA reculait. Peut-être même le début d’un nouvel hiver de l’IA.

Il y a un fait inconfortable dans la critique.

Une bonne part est vraie.

Et je pense que la conclusion est fausse.

Oui. Nous avions des classificateurs.

La classification n’a pas commencé en septembre 2026.

Ni la prédiction probabiliste.

Ni la calibration de la confiance.

En 2017, Chuan Guo et ses collègues ont publié une étude très citée sur la calibration des réseaux de neurones : elle examinait si les probabilités prédites correspondent à la justesse observée, et montrait que les réseaux modernes pouvaient être mal calibrés. Le temperature scaling, l’une des méthodes pratiques qu’ils ont évaluées, était elle-même le raffinement d’idées plus anciennes.¹

SetFit a ensuite montré que des modèles sentence-transformer relativement petits pouvaient s’adapter efficacement à la classification de texte en few-shot, sans grand modèle génératif ni prompts élaborés.²

GLiNER a montré autre chose qui compte pour cette discussion : un modèle bidirectionnel compact pouvait accepter des descriptions d’entités arbitraires et faire de l’extraction zero-shot flexible, sans la génération séquentielle de jetons d’un LLM conversationnel.³

Rien de cela n’est une histoire cachée.

Le champ n’a pas passé des décennies à attendre que quelqu’un invente if probability > 0.8.

Donc si l’affirmation était :

Jev a inventé la classification.

La critique serait dévastatrice.

Mais ce n’est pas l’affirmation intéressante.

La question intéressante est ce qui se passe lorsqu’une capacité familière franchit une nouvelle frontière de généralité, d’utilisabilité et d’économie.

C’est la couche qu’il vaut la peine d’examiner.

Le primitif n’est pas l’abstraction

Une base de données n’a pas inventé le stockage d’information.

Un GPU n’a pas inventé la multiplication.

Unix n’a pas inventé les fichiers, les processus ni les programmes.

Les conteneurs n’ont pas inventé l’isolation de processus.

Les abstractions utiles arrivent souvent longtemps après leurs primitifs sous-jacents.

Ce qui change, c’est la frontière.

Une capacité qui exigeait auparavant un travail de spécialiste devient accessible derrière une interface que d’autres ingénieurs peuvent utiliser sans reconstruire la machinerie en dessous.

Cette interface peut transformer une industrie même lorsque presque chaque ingrédient a des ancêtres.

C’est pourquoi « on avait déjà ça » est une phrase si dangereuse en technologie.

Parfois, c’est la correction nécessaire au marketing.

Parfois, c’est la preuve que nous regardons la mauvaise couche.

La question n’est pas seulement :

Quelqu’un a-t-il déjà classifié ?

Bien sûr.

Les questions plus intéressantes sont :

Un même modèle peut-il accepter un ensemble changeant de critères de décision en langage naturel, sans entraîner un nouveau classificateur pour chacun ?

Peut-il renvoyer des distributions de probabilités utiles, plutôt qu’une simple étiquette plausible ?

Plusieurs de ces jugements peuvent-ils être demandés à un coût assez bas pour que les architectes logiciels cessent de les rationner ?

La sortie peut-elle devenir un composant remplaçable dans du code ordinaire, plutôt que le début d’une nouvelle conversation ?

Ce sont des questions d’ingénierie.

Et on n’y répond pas en pointant un manuel de régression logistique.

Ce que Jev a réellement changé

TypeSafe a présenté Jev le 15 septembre 2026 comme un modèle en accès anticipé pour des décisions probabilistes typées. Son interface prend un état non structuré et des questions définies par le développeur, puis renvoie des sorties bornées : probabilités oui/non, choix et scores.⁴

L’entreprise appelle sa méthode d’entraînement Reinforcement Learning for Calibrated Decisions, ou RLCD, et dit avoir construit une nouvelle architecture et un échantillonneur parallèle autour de cette tâche.⁴

Ces affirmations méritent un examen.

L’architecture n’a pas été divulguée publiquement avec assez de détail pour qu’un extérieur puisse déterminer ce qui est vraiment nouveau. RLCD n’est pas documenté au point où des chercheurs indépendants pourraient reproduire la procédure d’entraînement et établir sa nouveauté.

Sebastian Raschka a fait ici la distinction utile. Son évaluation : Jev pourrait bien reposer sur des ingrédients familiers — potentiellement une architecture de type encodeur, un entraînement orienté calibration, de solides données et une API bien conçue — tout en restant intéressant par la façon dont le système résultant semble généraliser sur des tâches de classification.⁵

C’est la position que je trouve la plus convaincante à ce stade.

Je ne sais pas si Jev contient une percée de recherche.

Je pense qu’il a mis au jour une frontière de système utile.

Ce sont des affirmations différentes.

Et les confondre produit les deux mauvaises analyses : l’emballement d’un côté, le rejet de l’autre.

L’informatique est déjà passée par là

Les systèmes à usage général sont merveilleux parce qu’ils permettent de faire des choses que personne n’avait prévues au moment de leur construction.

Puis une charge de travail devient importante.

Nous la comprenons mieux.

Nous découvrons où le système général gaspille du temps, de l’énergie ou de l’argent.

Et la spécialisation revient.

L’histoire de l’informatique est pleine de ce mouvement.

Le Tensor Processing Unit de Google n’est pas apparu parce qu’on avait oublié la multiplication. Il est apparu parce que les charges d’apprentissage automatique étaient devenues assez importantes pour qu’une architecture spécifique au domaine les exécute plus efficacement qu’un processeur généraliste.⁶

John Hennessy et David Patterson ont fait du matériel spécifique au domaine un élément central de leur Turing Lecture de 2018 sur un nouvel âge d’or de l’architecture informatique. Leur argument n’était pas que le calcul généraliste avait été une erreur. C’était que la fin des gains de performance faciles rendait à nouveau attrayants la co-conception matériel/logiciel et les architectures spécifiques au domaine.⁷

Ce n’est pas une régression.

C’est la maturité d’une charge de travail.

Le même motif existe plus haut dans la pile.

Le système Unix d’origine valait en partie parce que des programmes, fichiers, pipes et processus indépendants pouvaient se composer à travers des interfaces simples.⁸

Un programme n’avait pas à devenir le système d’exploitation.

Un composant pouvait rester un composant.

Cela paraît presque embarrassant d’évidence.

Pourtant, le logiciel d’IA a passé plusieurs années à aller dans la direction opposée.

Nous avons trouvé un modèle capable d’écrire du texte, de résumer des documents, d’extraire des données, de classer des messages, d’appeler des outils, de raisonner sur des politiques et de générer du code.

Alors, naturellement, nous lui avons demandé de tout faire.

Souvent dans un seul prompt.

Parfois dans un énorme prompt.

L’émerveillement devant le modèle généraliste a encouragé une architecture généraliste autour de lui.

C’était compréhensible.

C’était aussi peu probable d’être la forme finale.

Le modèle est devenu le système

La première vague d’applications d’IA générative ressemblait souvent à ceci :

entrée → LLM → sortie

Puis le prompt s’est allongé.

Puis on a ajouté la recherche documentaire.

Puis les appels d’outils.

Puis les validateurs.

Puis les sorties structurées.

Puis les nouvelles tentatives.

Puis le routage.

Puis un second modèle pour juger le premier.

Puis un modèle plus fort pour les cas difficiles.

Puis du code pour décider quel modèle devait tourner.

À un moment, le « modèle » n’était plus l’application.

C’était de nouveau un composant à l’intérieur d’une application.

Des chercheurs de Berkeley ont décrit cette transition en 2024 comme le passage des modèles aux systèmes d’IA composés : des systèmes où les modèles interagissent avec la recherche, les outils, la logique programmatique et d’autres modèles, plutôt que de tenter de résoudre toute la tâche en un seul appel monolithique.⁹

Cette transition s’est poursuivie pour une raison simple.

Différentes parties du travail ont des formes computationnelles différentes.

L’arithmétique n’est pas la classification.

La classification n’est pas la recherche.

La recherche n’est pas la planification.

La planification n’est pas l’autorisation.

L’autorisation n’est pas la génération de texte.

Nous pouvons certes demander à un modèle de langage suffisamment capable d’approximer tout cela.

Cela ne veut pas dire que nous le devrions.

Un modèle universel est utile parce qu’il élargit l’espace de ce que le logiciel peut tenter.

Un composant spécialisé devient utile lorsque nous comprenons assez bien une part récurrente de cet espace pour lui donner une interface plus nette.

Les deux idées ne sont pas ennemies.

Le modèle général découvre le territoire.

Le système finit par construire des routes.

Ce que dit réellement la Bitter Lesson

C’est là que la discussion devient plus intéressante.

The Bitter Lesson de Rich Sutton est l’un des essais courts les plus importants de l’IA moderne. Il est aussi facile à transformer en slogan.

Le slogan ressemble à peu près à ceci :

Le général bat toujours le spécialisé. L’échelle gagne. Arrêtez d’ingénierer.

Ce n’est pas l’argument de Sutton.

Son observation était que les chercheurs en IA ont essayé à plusieurs reprises d’encoder leur propre compréhension d’un domaine dans des systèmes, tandis que des méthodes plus générales capables d’exploiter une computation croissante — en particulier la recherche et l’apprentissage — finissaient par dépasser ces approches conçues à la main.¹⁰

Les échecs sont un exemple.

Le go en est un autre.

La reconnaissance de la parole et la vision par ordinateur suivent des motifs semblables dans le récit de Sutton.

La part amère n’était pas que chaque système doive contenir un modèle énorme.

C’était que les êtres humains sont mauvais à spécifier manuellement tout le savoir requis pour l’intelligence, tandis que l’apprentissage et la recherche peuvent continuer à s’améliorer à mesure que la computation croît.

Cette leçon est tout à fait compatible avec des modèles spécialisés appris.

Un modèle de décision entraîné à partir de données n’est pas la même chose qu’un système expert contenant des milliers de règles écrites par un comité.

Un TPU est du matériel spécialisé, et pourtant il existe précisément pour rendre l’apprentissage à grande échelle plus efficace en calcul.

Un système de recherche est spécialisé, et pourtant il peut fournir à un modèle général un savoir qu’il devrait sinon approximer à partir de paramètres.

Un classificateur peut être spécialisé dans son espace de sortie tout en ayant acquis ses capacités par un apprentissage général.

La distinction importante n’est souvent pas :

général versus spécialisé

mais plutôt :

appris versus encodé à la main,
réutilisable versus fragile,
scalable versus piégé par sa propre conception.

TypeSafe est entré directement dans cette discussion avec un essai intitulé The Bitterest Lesson. Son argument : la computation compte énormément, mais l’objectif à optimiser compte d’abord — un système peut scaler superbement tout en devenant meilleur à la mauvaise tâche.¹¹

C’est l’argument d’un fournisseur et il faut le lire comme tel.

Mais la question sous-jacente est légitime.

Si le travail consiste à choisir parmi cinq actions permises, la génération du prochain jeton est-elle l’objectif computationnel que nous voulons finalement optimiser ?

Peut-être.

Peut-être pas.

C’est une question empirique, pas un article de foi.

Puis tout le monde en a construit un

Il y a une autre raison pour laquelle je pense que l’épisode Jev mérite d’être suivi.

La réponse a été inhabituellement rapide.

Bespoke Labs a publié Nimble, un modèle ouvert inspiré de Jev qui prend du texte et un schéma et renvoie des décisions typées avec probabilités. Le projet affirme que sa première version a été construite en un jour.¹²

Together AI a publié Tev1-4B-experimental sur la base de Qwen3.5 4B. Sa recette d’entraînement publiée utilise environ 38 000 exemples de classification et rapporte un coût de fine-tuning d’environ 17 dollars US.¹³

Laya implémente une interface de décision non autorégressive compatible avec Jev et publie des bancs d’essai comparatifs utiles précisément parce qu’ils ne sont pas flatteurs partout. Ses propres résultats montrent des zones où son modèle affiné surpasse Jev et des zones — y compris les grands ensembles de choix et certaines métriques de distribution de probabilités — où Jev reste plus fort.¹⁴

Kev emmène l’idée encore ailleurs : de petits modèles de décision ouverts de style Jev, y compris un prototype à l’échelle d’un ordinateur portable et de plus grandes variantes basées sur Qwen. Ses fiches de modèle avertissent explicitement qu’une valeur de confiance n’est pas une probabilité vérifiée de justesse, et que la calibration doit être mesurée sur la population de déploiement réelle.¹⁵

Aucun de ces projets ne prouve que TypeSafe a créé une catégorie permanente.

Ils prouvent quelque chose de plus étroit.

D’autres constructeurs ont vu l’interface et ont immédiatement pensé :

Je veux ça.

Cela compte.

Une catégorie technologique n’est pas créée quand une entreprise la nomme.

Elle commence à devenir réelle quand des concurrents, des développeurs open source et des utilisateurs reconnaissent assez bien la forme de la chose pour la reproduire, la varier et en débattre.

Peut-être que « System One Model » restera le nom.

Peut-être que personne ne l’utilisera dans un an.

Le nom est secondaire.

Le motif émergent est plus intéressant :

état en entrée → questions bornées → distributions de probabilités en sortie → le code décide de la suite

Cette interface a maintenant plusieurs implémentations.

Pour quelque chose d’apparemment si dépassé, cela génère une quantité surprenante de travail nouveau.

La redécouverte peut quand même être surestimée

Rien de tout cela ne signifie que Jev gagne.

En fait, la réponse la plus forte à l’enthousiasme actuel n’est pas « les classificateurs sont vieux ».

C’est :

Quel classificateur dois-je utiliser pour ce travail particulier ?

Si j’ai une tâche stable, un jeu d’étiquettes propre et des milliers d’exemples de haute qualité, un classificateur conventionnel spécifique à la tâche peut être exactement la bonne réponse.

Il peut être plus rapide.

Il peut être moins cher.

Il peut être plus facile à évaluer.

Il peut tourner entièrement sur une infrastructure que je contrôle.

SetFit et des années de recherche en classification de texte n’ont pas cessé d’être utiles parce que Jev a été lancé.²

De même, un LLM général peut rester le meilleur composant lorsque l’espace de réponses ne peut pas être défini à l’avance, lorsque la tâche exige une synthèse, lorsque le raisonnement sur des situations inconnues compte plus que la latence, ou lorsque le système a réellement besoin de produire du langage.

Et puis il y a les probabilités.

Un point décimal crée une impression de précision que le système ne mérite peut-être pas.

Le travail de Guo sur la calibration reste pertinent parce qu’un modèle qui dit 0.92 ne suffit pas. La question opérationnelle est de savoir si les prédictions à ce niveau sont réellement correctes à peu près à cette fréquence sur la population où le système est utilisé.¹

Le décalage de distribution compte.

La conception des étiquettes compte.

Les alternatives manquantes comptent.

Les mauvaises preuves comptent.

Le système peut être parfaitement sûr quant aux types et choisir quand même la mauvaise réponse permise.

La spécialisation n’enlève pas la responsabilité de tester.

Elle rend le test plus facile à définir.

C’est un avantage seulement si nous le faisons vraiment.

Ce n’est pas à cela que ressemble un hiver de l’IA

L’expression « hiver de l’IA » porte un poids historique.

L’histoire AI100 de Stanford décrit l’hiver du milieu des années 1980 comme une période où la déception pratique a rattrapé les attentes, où l’intérêt a baissé et où le financement s’est tari.¹⁶

C’est un phénomène très différent de celui de développeurs qui découvrent que certaines charges de production n’exigent pas un modèle génératif géant.

Si des entreprises commencent à remplacer des appels généralistes coûteux par de plus petits composants appris là où la tâche le permet, ce n’est pas la preuve que l’IA a échoué.

C’est la preuve que le coût compte.

La latence compte.

La fiabilité compte.

L’architecture compte.

Autrement dit, la technologie est soumise aux mêmes pressions que toute autre technologie qui a fini par quitter le stade de la démonstration.

La première phase demande :

Que peut faire cette machine ?

La suivante demande :

Quelle machine doit faire quelle part ?

La seconde question sonne moins magique.

C’est aussi la question que les ingénieurs doivent finir par trancher.

Une industrie composée de LLM, de modèles de décision, de modèles d’embeddings, de récupérateurs, de systèmes de vision, de code déterministe, de bases de données, de politiques et de voies d’escalade humaines peut ressembler moins à de la science-fiction qu’un modèle omnipotent derrière une API.

Elle peut aussi mieux fonctionner.

L’ennui est un jalon

Il y a une habitude étrange dans les discussions technologiques.

Nous traitons la généralisation comme un progrès et la spécialisation comme un repli.

Mais qu’une invention devienne ennuyeuse est souvent l’un des signes les plus clairs de succès.

L’électricité a disparu dans les murs.

Le réseau a disparu dans les systèmes d’exploitation.

Les bases de données sont devenues de l’infrastructure.

Les machines virtuelles sont devenues ordinaires.

Le cloud computing est finalement devenu la facture de quelqu’un d’autre.

Une technologie mature est entourée de composants dont la nouveauté ne compte plus pour la personne qui les utilise.

L’IA ne sera probablement pas différente.

Il y aura encore des modèles de frontière.

Ils deviendront plus capables.

Ils ouvriront de nouveaux territoires.

Mais les systèmes construits autour d’eux peuvent devenir de plus en plus hétérogènes.

Certaines décisions iront à un modèle de raisonnement de frontière.

Certaines à un classificateur de quatre milliards de paramètres.

Certaines à un modèle qui tourne en local.

Certaines à une requête SQL.

Certaines à un moteur de règles.

Certaines à une personne, parce que la conséquence est trop importante ou la preuve trop incomplète.

Une bonne architecture ne se souciera pas de quel composant a actuellement la capture d’écran de banc d’essai la plus impressionnante.

Elle se souciera de savoir si le composant fait assez bien, assez bon marché et assez prévisiblement le travail qui lui est assigné pour qu’on puisse s’y fier.

Ce n’est pas un repli devant l’intelligence.

C’est l’intelligence qui devient infrastructure.

La redécouverte n’est pas une régression

Donc oui.

Jev est un classificateur.

Ou, du moins, classificateur est une description parfaitement raisonnable de ce qu’il fait.

La classification est ancienne.

La calibration est ancienne.

Les modèles spécialisés sont anciens.

Aucune de ces observations ne tranche si Jev est utile.

Elles font mieux : elles retirent la mythologie.

Alors nous pouvons poser les questions qui comptent.

L’interface généralise-t-elle ?

Les probabilités sont-elles utiles ?

Comment se comporte-t-il hors des exemples du fournisseur ?

Où un classificateur ordinaire le bat-il ?

Où un modèle génératif le bat-il ?

Le composant peut-il être remplacé sans reconstruire l’application ?

Que fait le système entier quand le modèle a tort ?

Ce sont des questions bien plus saines que de demander si nous avons franchi une ligne historique invisible entre « ancienne IA » et « nouvelle IA ».

La technologie avance rarement en jetant définitivement tout ce qui est venu avant.

Elle avance par recombinaison.

Une capacité devient générale.

Nous l’utilisons partout.

Nous apprenons où elle convient.

Nous spécialisons les parties coûteuses.

Nous standardisons les interfaces utiles.

Puis une autre percée généraliste arrive et le cycle recommence.

Si Jev disparaît l’an prochain, ce motif restera digne d’être compris.

Parce que le basculement le plus conséquent n’a peut-être rien à voir avec Jev.

Il se peut que l’ère des modèles génératifs ait appris aux développeurs à traiter l’intelligence comme quelque chose que le logiciel peut appeler.

Et maintenant nous commençons à poser la question suivante, évidente :

Quelle sorte d’intelligence chaque appel doit-il réellement exiger ?

Ce n’est pas un hiver de l’IA.

C’est de l’architecture.

Et la redécouverte n’est pas une régression.

Sources

Sources consultées le 25 septembre 2026. La documentation des fournisseurs sert à établir les affirmations produit, les interfaces et les mesures publiées, non comme vérification indépendante des performances. Les bancs d’essai des projets open source sont rapportés comme résultats publiés par le projet, sauf indication contraire.

Notes