Jev : le modèle conçu pour être appelé par du code, pas par des humains
Diogo Almeida, ex-OpenAI, explique pourquoi il a créé une nouvelle classe de modèles « system one » — et pourquoi il refuse les benchmarks publics, les refus et le pré-entraînement.
En bref
Dans un entretien de plus de deux heures au studio Latent Space, le fondateur de TypeSafe détaille la thèse derrière Jev : un modèle dont le consommateur est le code, optimisé pour l'« intelligence par dollar », sans chaîne de raisonnement ni refus. Il y démonte au passage le RLHF, les benchmarks publics et le débat sur le « pacing » du frontier, et raconte pourquoi il a quitté OpenAI après avoir poussé InstructGPT.
🍺 Version comptoir
Depuis trois ans, tout le monde t'explique que l'IA sera ton collègue de bureau. Lui pense que c'est une erreur de casting : l'IA, ce n'est pas un stagiaire, c'est une base de données un peu douée qu'on appelle un million de fois par jour depuis une boucle. D'où un modèle qui ne discute pas, ne refuse rien, ne réfléchit pas à voix haute, et renvoie juste trois choses : un booléen flou, un score, un choix. Si ça marche, la révolution IA n'arrivera pas sous la forme d'un chatbot génial mais sous celle d'un logiciel banal qui, soudain, prend enfin les bonnes décisions tout seul.
À retenir
- 1
Jev appartient à une classe de modèles que TypeSafe appelle « system one », « machine native » ou « large programmable » : le consommateur de la sortie est du code, pas un humain.
- 2
Trois primitives seulement — nule (issu de Bernoulli), score et choice — qui correspondent à un if, à un tri ou seuil, et à un switch sur enum.
- 3
Le modèle est optimisé pour l'« intelligence par dollar » (d'où le nom, en référence au paradoxe de Jevons), pas pour la vitesse ni pour les classements.
- 4
Almeida se dit « extrêmement anti-benchmarks publics » : trop facilement gamables, ils devraient céder la place aux évaluations internes des développeurs sur leurs propres workflows.
- 5
Aucun refus dans l'API : « refusal is obviously a type error » — un refus aléatoire dans une dépendance qui tourne en arrière-plan casse le logiciel.
- 6
Les données sont entièrement synthétiques et l'entreprise refuse de s'entraîner sur celles des utilisateurs, pour ne pas surajuster au présent.
- 7
Chiffres cités : plus de 1 000 milliards de tokens par jour passés, y compris la nuit, 100 000 personnes sur le Discord, et quasi aucun revenu avant le lancement.
Chapitres
Cold open : l'énigme de l'automatisation
Comment une IA capable de problèmes de mathématiques de haut niveau n'automatise-t-elle toujours pas les tâches les plus basiques ? Le moteur d'automatisation existe, les prises manquent.
Semaine de lancement : « never been worse »
État d'esprit du fondateur après un lancement qui a saturé la timeline, et choix de prioriser les town halls Discord sur les rendez-vous investisseurs.
Qu'est-ce que Jev ?
Définition de la nouvelle classe de modèles : system one, machine native, large programmable, avec le code comme consommateur et l'intelligence par dollar comme métrique.
RLHF, mode collapse et la diapo de LeCun
Le mode dropping du RLHF explique pourquoi l'accumulation d'erreurs prédite par LeCun ne se vérifie pas — au prix d'une calibration détruite.
Pourquoi Jev ne refuse jamais
Le refus comme erreur de typage dans une API ; distinction entre alignement de capacité et alignement de sécurité ; l'intelligence comme base de données plutôt que collègue.
Anti-benchmarks publics
Pourquoi les benchmarks publics sont ingérables et gamables, et ce qui devrait les remplacer : vibes, confiance, puis évaluation dans le workflow réel.
La « bitterest lesson » : les données d'abord
La donnée compte plus que le compute, RLCD comme nouvelle north star, et l'obsession du recrutement de « data people ».
Déterminisme contre robustesse
Pas de seed pour l'instant : la bonne propriété serait la robustesse, testée en injectant des UUID dans les prompts.
Versions de modèles et LTS
Engagement de ne pas modifier un modèle déployé, absence de promesse de support long terme, et hypothèse d'un LTS sur Jev 1.13.0.
Design de l'API : nule, score, choice
Origine des noms, refus des types existants, et correspondance avec if, seuil et switch sur enum.
Comment structurer ses requêtes
Décomposer jusqu'à l'unité sémantique minimale, passer du JSON structuré plutôt que des templates, poser beaucoup de questions en parallèle.
System 1 contre system 2
Pourquoi les LLM pré-entraînés sont fondamentalement des penseurs system one, et ce que le RLVR a apporté — avec sa fragilité fractale.
Avant le lancement : plus de la moitié ne comprenait pas
Retour sur une phase de validation décevante, l'absence de revenus et la remise en question de la notion de product-market fit.
Familles d'usages et coding agents
Dark data, temps réel, vérification, smart software — et la critique de la « tyrannie du KV cache » dans les agents de code.
Le débat sur le ralentissement du frontier
La déclaration commune des labs présuppose selon lui qu'il faut toujours plus de RLVR ; une hypothèse qu'il juge non universelle.
D'InstructGPT au départ d'OpenAI
Le combat pour déployer InstructGPT, le document envoyé à Sam Altman, et la création de TypeSafe avec Eric puis Sasha.
Les chantiers qu'il offre aux autres
Jeux vidéo intelligents et refonte des coding agents libérés du KV cache : deux directions qu'il aimerait voir explorer par d'autres.
Une nouvelle classe de modèles : le code comme client
Le point de départ est une opposition de tâches. Le pré-entraînement optimise l'autocomplétion d'Internet, le RLHF optimise la réponse à un humain, le RLVR optimise des sorties vérifiables. TypeSafe revendique une quatrième cible, baptisée RLCD : produire des sorties directement consommées par du code. D'où le nom de l'entreprise, TypeSafe.
Concrètement, Jev n'écrit pas de texte libre. Il expose trois primitives : nule (dérivé de la probabilité de Bernoulli, un booléen continu), score, et choice. Almeida les décrit comme des types volontairement nouveaux, qui ne se confondent pas avec un bool, un int ou un function call.
La correspondance avec le code est explicite : un nule alimente un if, un score un tri ou un seuil, un choice un switch sur une enum. « Il y aura d'autres types, et ils correspondront à des primitives de programmation », annonce-t-il.
Le nom Jev vient du paradoxe de Jevons. La marque interne est claire : Jev désigne la famille de modèles qui reste sur la frontière de l'intelligence par dollar. Pas la plus intelligente dans l'absolu — la plus intelligente à prix donné.
Le procès du RLHF : mode collapse et calibration
C'est le morceau le plus technique de l'entretien, et il vient de quelqu'un qui a travaillé sur InstructGPT. Selon Almeida, personne n'a regardé les effets secondaires du RLHF, en particulier le mode dropping : le modèle abandonne les modes minoritaires de la distribution pour ne produire que ce qui est le plus sûr.
Il s'en sert pour expliquer un paradoxe connu. La fameuse diapositive de Yann LeCun sur l'accumulation d'erreurs avec la longueur de séquence est, dit-il, « mathématiquement évidente mais manifestement fausse » empiriquement. Raison invoquée : pour ne pas dérailler sur de longues chaînes, les modèles RLHF deviennent ultra-conservateurs et perdent leur calibration.
Cette calibration cassée est, pour lui, « un poison » dans les distributions de probabilité sur les chaînes de caractères — et la raison pour laquelle on fait de mauvaises décisions en surchargeant des modèles à texte.
Il tient LeCun pour l'un des commentateurs les plus justes du domaine, tout en refusant de trancher sur JEPA : « de la très belle recherche précoce », mais pas encore pragmatique à ses yeux.
Ni refus, ni benchmarks : la doctrine plateforme
Sur la sécurité, la position est tranchée. Almeida ne s'oppose pas à la sécurité comme principe, mais considère que le safety alignment est désaligné avec les utilisateurs d'une API. Un refus est « un type error » : acceptable dans un produit grand public, insensé dans une dépendance qui tourne en tâche de fond.
Son analogie revient plusieurs fois : « l'intelligence ressemblera plus à une base de données qu'à un collègue ». Et ce n'est pas au moteur de base de données de juger l'usage aval. Sur l'usage militaire, il concède une préférence personnelle, mais refuse de l'inscrire dans la couche technologique, au motif que chaque surajustement « fracture l'intelligence ».
Même logique pour les benchmarks publics. Il rappelle que chaque labo avait autrefois une équipe dédiée à collecter des données ressemblant à MMLU. Sa conclusion : « à long terme, il faut des vibes et de la confiance », puis une évaluation dans le workflow réel. En interne, les évals existent — la discipline consiste à ne pas les gamer.
Le coût de cette position a été réel : lors de la levée précédente, personne ne les croyait faute de chiffres à montrer. Il dit s'y être tenu par principe. Il se déclare aussi « anti-démos », y compris pour les démos flatteuses de sa communauté.
Fiabilité, versions, GPU : les promesses faites aux développeurs
Pas de seed, pas de déterminisme pour l'instant. Il juge le déterminisme intéressant pour les tests unitaires, mais estime que la vraie propriété désirable est la robustesse : entrées sémantiquement identiques, sorties similaires. Leur test maison consiste à injecter des UUID dans les prompts et à vérifier la stabilité des réponses.
Sur les versions, l'engagement est net : « nous ne modifierons pas nos modèles après déploiement ». En revanche, aucune promesse de support long terme — ils comptent itérer beaucoup plus vite que les fournisseurs habituels, avec l'hypothèse d'un LTS temporaire sur la version très utilisée, Jev 1.13.0.
Le contexte est celui d'une pénurie durable de GPU. C'est aussi l'argument économique de leur positionnement : moins d'intelligence par dollar signifie plus de GPU pour le même résultat. L'objectif affiché n'est pas d'onboarder des grands comptes mais de mettre l'outil dans un maximum de mains.
Le fine-tuning n'est pas exclu, mais pas prévu : il redoute l'effet fusil à pompe et préfère parier sur la calibration et des cascades de modèles de tailles différentes.
Comment s'en servir, selon son auteur
Son conseil principal tient en un mot : décomposer. Poser beaucoup de petites questions indépendantes plutôt qu'une grosse, jusqu'à l'unité sémantique la plus fine. L'exemple qu'il donne : ne pas demander « dois-je refuser ici ? », mais interroger séparément chaque situation de refus possible.
L'avantage est d'ordre génie logiciel. Chaque question devient mesurable, chaque bug se corrige en ajoutant une question ou en ajustant un seuil, et le cas devient un test permanent, à l'abri du context rot. Il résume : « c'est du machine learning sans le machine learning ».
Deuxième conseil : arrêter de tout mettre en chaîne de caractères. State, instructions et critères acceptent du JSON structuré. Les system messages sont décrits comme « d'immondes variables globales » où l'on empile tout en espérant que chaque instruction passe.
Côté usages, il classe quatre grandes familles : les dark data que les entreprises n'osaient pas passer au LLM pour raisons de coût, les coding agents, le temps réel et les assistants, et la vérification systématique des appels LLM. Le computer use, lui, est arrivé par surprise.
OpenAI, l'hiver de l'IA et le débat sur le « pacing »
La partie biographique éclaire le reste. Almeida raconte s'être battu pour déployer InstructGPT, avec au passage un algorithme non publié écrit par lui, puis avoir constaté que le résultat servait surtout au copywriting. D'où sa question : que manque-t-il entre « très intelligent » et « crée de la valeur » ?
Sa réponse : dans une révolution économique par l'IA, l'immense majorité des appels viendront du code, pas des humains — et toute l'optimisation allait vers les humains. Il dit avoir écrit un document, en avoir parlé à Sam Altman qui lui a conseillé d'y aller, supposé qu'Anthropic le faisait déjà, puis fini par monter TypeSafe avec Eric puis Sasha.
Son moteur affiché est la peur d'un hiver de l'IA dont il se sentirait personnellement responsable, à la fois pour la direction RLHF et pour n'avoir pas tout misé sur celle-ci. Sa cible n'est pas un score mais un chiffre macro : 3 % de croissance de la productivité totale des facteurs en cinq ans.
Sur la déclaration commune des labs en faveur d'un ralentissement, il parle de tour de passe-passe : elle présuppose que tout le monde doit faire toujours plus de RLVR en laissant les modèles agir librement. Pour sa forme de modèle, « zéro est la quantité optimale ». Le host ajoute une autre lecture, plus prosaïque : du positionnement politique en vue de 2028.
“Refusal is just like obviously a type error.”
“I think intelligence will be more like a database than a coworker.”
“If you gave me a billion dollars I wouldn't pre-train.”
Pourquoi ça compte
Depuis trois ans, le consensus produit de l'IA tient en un mot : l'agent, ou le collègue numérique. Almeida propose l'exact inverse — une intelligence banalisée, invisible, appelée par des programmes, facturée comme une requête de base de données et jugée sur sa fiabilité plutôt que sur son intelligence brute. C'est une thèse cohérente, argumentée techniquement, et elle a le mérite d'expliquer un fait gênant : le logiciel de 2026 ressemble encore à celui de 2019, un chatbox latéral en plus. Reste une tension à ne pas gommer. Refuser les benchmarks publics, les démos et le déterminisme au nom de la pureté d'ingénierie revient aussi à rendre les revendications de l'entreprise invérifiables de l'extérieur, au moment précis où « intelligence par dollar » devient un argument commercial. La promesse de ne jamais modifier un modèle déployé, elle, est engageante : c'est là qu'il faudra le tenir.
À lire aussi
99 % ou 0 % : quatre experts parient sur la fin du monde
Steven Bartlett fait écrire à quatre spécialistes leur probabilité d'extinction sur une enveloppe. Les réponses vont de 99 % à zéro, et le débat qui suit est le plus utile qu'on ait entendu sur le sujet.
Source · The Diary Of A CEO · AI Emergency: The AI Labs Are Lying To Everyone, He Says 99% Chance Of Extinction | Roman Yampolskiy
#régulationAujourd'huiLa Californie encadre les data centers : sept lois d'un coup
Reporting obligatoire sur l'eau et l'électricité, fin des passe-droits environnementaux : Sacramento veut que l'industrie de l'IA paie ses propres factures de réseau.
Source · Governor of California (gov.ca.gov) · Governor Newsom signs most comprehensive data center laws in the nation, providing communities more control on water, electricity, and land use
#rechercheAujourd'huiOpenAI annonce Navier–Stokes résolu et crée un comité de mathématiciens
Dans un même billet : un modèle interne qui dit avoir bouclé plus de 100 problèmes ouverts, et un groupe d'experts indépendant pour gérer l'onde de choc.
Source · OpenAI · Advisory Group on Mathematics and Artificial Intelligence