Comment cette note a été vérifiée. Avant publication elle a été attaquée, réfutation d’abord, par huit instances de relecture extérieures issues de quatre familles de modèles (Moonshot Kimi, xAI Grok, DeepSeek, Alibaba Qwen), chacune recalculant chaque comptage à partir des fichiers de l’éditeur. Ce qu’elles ont cassé et comment cela a été corrigé figure au §5. Le compagnon technique, avec la méthode, les comptages complets et les limites, est Field Note 1. Les relevés d’instances et l’archive de données hachée sont conservés dans notre dépôt de rapports et disponibles sur demande.
En une minute. Une entreprise nommée TypeSafe AI a publié Jev, un modèle d’IA qui n’écrit jamais une phrase. Posez-lui une question à ensemble de réponses fixe et il renvoie une réponse, plus une probabilité pour chaque option. Pour un modèle de cette classe de capacité c’est nouveau, et cela aiguise une question que les classifieurs ne nous ont jamais imposée : comment vérifier un témoin qui ne peut pas s’expliquer ? La réponse de TypeSafe consiste à noter Jev contre l’opinion moyenne de deux autres modèles d’IA. Nous avons ouvert les vingt cas que TypeSafe publie pour illustrer son banc d’essai et constaté que, dans huit des dix-neuf où les deux correcteurs ont répondu, ces deux modèles divergeaient entre eux sur la bonne réponse. Cette note explique pourquoi cela compte bien au-delà d’une seule entreprise.
1. Un modèle qui ne parle pas
Pendant trois ans, quand un modèle d’IA de pointe nous donnait une réponse, il nous donnait des mots. Nous pouvions les lire, les contester, et prendre le modèle en flagrant délit de contradiction. Les classifieurs plus petits ont toujours renvoyé des étiquettes nues ; ce qui est nouveau, c’est un modèle de capacité de pointe qui ne renvoie rien d’autre. TypeSafe AI, une entreprise de San Francisco sans lien avec le langage de programmation TypeScript, a livré un modèle qui ne fait rien de tout cela. Il s’appelle Jev, et TypeSafe le présente comme le premier d’une nouvelle catégorie, les « System One models », d’après la pensée rapide et intuitive décrite par Daniel Kahneman dans Système 1 / Système 2 : Les deux vitesses de la pensée.
Voici comment Jev fonctionne. Vous lui donnez de la matière, disons le ticket d’assistance d’un client. Vous lui donnez un ensemble de questions typées : ce client demande-t-il un remboursement ? (oui ou non, avec une probabilité). Quelle équipe doit s’en charger ? (une à choisir dans une liste). Quel est le niveau d’exaspération du client, de 0 à 4 ? (une note). Jev renvoie les réponses, chacune avec une distribution de probabilité, en une fraction de seconde. Pas de prose, pas d’explication, pas de code. Votre logiciel agit directement sur les réponses.
Pour automatiser des décisions de routine c’est séduisant, et nous ne sommes pas ici pour dire le contraire. Supprimer le texte libre élimine toute une classe de défaillances, et une probabilité sur laquelle on peut fixer un seuil sert davantage un programme qu’un paragraphe. Ce qui nous intéresse, c’est un effet de bord. Un modèle qui ne fait que choisir dans votre liste ne peut jamais vous dire qu’il manque quelque chose à la liste. Un relecteur humain, ou un modèle qui écrit, peut dire « vous avez posé la mauvaise question ». Jev ne le peut pas. Il peut suggérer qu’aucune option ne convient bien, parce que ses probabilités seront étalées au lieu d’être concentrées, et la documentation de TypeSafe le dit elle-même. Mais il ne peut jamais nommer l’option que vous avez oubliée. Ce que vous avez laissé hors de l’ensemble de questions y reste, pour chaque témoin qui y répond.
Nous abordons cela sous un angle inhabituel. Notre document de travail traite les sorties d’IA comme les savants traitent les vieux manuscrits : comme le témoignage de témoins qui peuvent partager des sources, se copier les uns les autres et commettre les mêmes erreurs pour les mêmes raisons. Dans ce cadre, Jev est un témoin qui a cessé d’écrire.
2. Qui note le correcteur ?
Chaque modèle d’IA reçoit une note de banc d’essai. La question à poser devant toute note est : comparée à quoi ? Pour un problème de mathématiques la réponse est facile : le nombre correct. Pour « cette alerte de sécurité doit-elle être escaladée ? » il n’y a pas de corrigé. Quelqu’un doit décider quelle était la bonne réponse.
TypeSafe publie son banc d’essai sur evals.typesafe.ai. Sa section méthodologie explique comment il
a tranché :
“Instead of debating the correctness of the harness and labels, we assume that the code is correct, and measure against the current smartest large models. For this eval, the reference labels are generated via an average of the responses of GPT-6 Astra and Claude Fable 5.1, both at high thinking, answering every question in the harness. All other models are evaluated using the provider’s default reasoning settings.”
Notre traduction : plutôt que de débattre de la justesse du harnais et des étiquettes, nous supposons que le code est correct et mesurons contre les grands modèles actuellement les plus performants ; pour cette évaluation, les étiquettes de référence sont produites par une moyenne des réponses de GPT-6 Astra et de Claude Fable 5.1, tous deux en mode de réflexion élevée.
En clair : la « bonne réponse » à chaque question est ce que deux modèles d’IA de premier plan, le GPT-6 Astra d’OpenAI et le Claude Fable 5.1 d’Anthropic, ont dit en moyenne. L’exactitude de Jev est la fréquence à laquelle il s’accorde avec cette moyenne. Celle de tous les autres aussi.
TypeSafe reconnaît franchement le problème évident. Le billet de lancement dit que cela “biases answers towards OpenAI and Anthropic’s models. We likely underestimate the relative performance of our model and DeepSeek’s models” (cela biaise les réponses en faveur des modèles d’OpenAI et d’Anthropic, et sous-estime probablement la performance relative de leur propre modèle et de ceux de DeepSeek). C’est une réserve honnête. Mais il y a un problème plus profond, qu’il ne nomme pas.
Quand deux modèles d’IA se trompent tous les deux, ils tendent à se tromper de la même façon. Une étude de 2025 portant sur plus de 350 modèles a trouvé que lorsque deux modèles manquent tous deux une question, ils donnent la même mauvaise réponse bien plus souvent que le hasard ne le prédirait. L’effet se renforce à mesure que les modèles gagnent en capacité, et il tient à travers des entreprises et des architectures différentes (Kim, Garg, Peng et Garg, ICML 2025). Moyenner deux juges amortit les erreurs qu’ils commettent séparément ; au niveau d’une décision finale, cela se range simplement du côté de l’un des deux, comme nous le montrons plus bas. Cela ne fait rien contre les erreurs qu’ils commettent ensemble, et au sommet du domaine, ces erreurs partagées sont les grosses.
Une moyenne de deux modèles de pointe n’est donc pas un arbitre neutre. C’est leur opinion commune, promue au rang de vérité de terrain. Un modèle qui copie leur erreur commune est noté correct. Un modèle qui a raison quand ils ont tous deux tort est noté en échec. Nous avons appelé cela le piège du consensus quand nous avons écrit sur les bancs d’essai en août. Le banc d’essai de TypeSafe est l’exemple divulgué le plus net que nous ayons vu. Une note d’honnêteté de notre part : l’étude a mesuré cela sur deux classements publics et une tâche de recrutement. Que la même chose se produise à l’intérieur d’un banc d’essai de flux de travail sans vérité indépendante est notre inférence, non le résultat de l’étude.
3. Nous avons ouvert les cas. Voici ce que nous avons trouvé.
Le tableau de bord note neuf modèles sur quatre flux de travail : alertes de sécurité, supervision d’agents d’assistance, traitement de factures et service client, 711 cas en tout. Jev se situe au milieu du peloton : 67,8 % d’accord avec la référence en moyenne, contre 74,1 % pour le meilleur modèle. Il se place sous les modèles de tête d’OpenAI et d’Anthropic, un dixième de point derrière GPT-5.6 Terra, au niveau de Claude Sonnet 5, et au-dessus des deux modèles DeepSeek. Si vous êtes venu demander si Jev « hallucine », le billet de lancement de TypeSafe est franc là-dessus aussi : le 0 % qu’il trace est, selon ses propres mots, “not empirical. Schema matching is guaranteed, thus we can confidently add 0% into the plots” (non empirique ; la correspondance de schéma est garantie). Jev ne peut pas renvoyer une réponse malformée. C’est autre chose que d’en renvoyer une correcte.
La partie qui nous occupe est plus petite et plus révélatrice. TypeSafe publie aussi vingt cas travaillés, cinq par flux, choisis pour illustrer cinq situations : chacun des trois modèles comparés divergeant tour à tour des deux autres, les trois manquant la référence, et les trois s’accordant. Pour dix-neuf de ces cas, il publie ce que chacun des deux modèles correcteurs a dit, question par question, et pas seulement leur moyenne ; dans l’un des dix-neuf, la plupart des réponses de suivi du second correcteur manquent dans le fichier, et dans deux des quatre flux la moyenne elle-même n’est pas publiée du tout. C’est plus de transparence que n’en offrent la plupart des bancs d’essai, et cela nous a permis de compter.
Les deux correcteurs ont divergé entre eux sur la décision finale dans 8 des 19 cas. Nous avons comparé la liste complète des actions auxquelles chaque correcteur est parvenu ; dans quelques cas la liste de l’un était celle de l’autre plus des étapes supplémentaires, et nous comptons cela aussi comme une divergence. Question par question, ils ont donné des réponses différentes 31 fois sur les 356 questions auxquelles les deux correcteurs ont répondu, toutes présentes dans les fichiers archivés ; dans six autres cas, l’un d’eux n’a donné aucune réponse. Ces vingt cas ont été sélectionnés à la main par TypeSafe pour montrer des divergences parmi les modèles notés ; ce n’est donc pas une mesure de la fréquence à laquelle les correcteurs divergent sur les 711. C’est ce que TypeSafe a choisi de publier, lu depuis l’autre côté.
Chacun des cas que TypeSafe étiquette « les trois manquent la référence » est un cas où les deux
correcteurs divergeaient aussi entre eux. Prenez l’exemple de sécurité. Un correcteur a dit
ISOLATE HOST. L’autre a dit REVOKE SESSIONS. La moyenne a donné ISOLATE HOST. Les trois modèles
notés ont dit QUARANTINE FILE. Trois modèles ont donc été marqués faux contre une réponse que l’un
des deux modèles rédigeant le corrigé n’avait pas donnée non plus. Pour être exact sur ce que cela
montre : les trois modèles auraient été marqués faux sous l’un comme sous l’autre correcteur, il
s’agit donc d’un corrigé contesté et non d’une bonne réponse punie. Personne ne peut dire lequel des
deux correcteurs avait raison : ces flux n’ont pas de corrigé indépendant, ce qui est précisément le
propos. Deux des quatre cas étiquetés « les trois s’accordent » tranchent dans l’autre sens. Dans
l’un, les deux correcteurs se sont partagés entre ISOLATE HOST et ESCALATE TIER2, la moyenne a
retenu ESCALATE TIER2, et les trois modèles notés ont dit la même chose, de sorte que s’accorder
avec un correcteur contre l’autre a compté comme correct. Partout où TypeSafe publie la moyenne,
elle égale la réponse de l’un ou de l’autre correcteur, jamais une troisième. Ce n’est pas une
coïncidence : les probabilités moyennées passent par les mêmes règles de décision que les réponses de
n’importe quel modèle, la moyenne doit donc aboutir à une action, et dans chaque cas publié elle
aboutit du côté de l’un des correcteurs.
L’un des correcteurs était en partie un remplaçant. Dans le flux de sécurité, le fichier décrivant
le second correcteur indique, mot pour mot : “Claude Fable 5.1 high, one question per request; Claude
Opus 5 high on the 88 documents Fable refused or failed”. Ainsi, pour les documents que Fable ne
voulait ou ne pouvait pas traiter, un autre modèle d’Anthropic, Claude Opus 5, a pris le relais. Le
fichier compte 240 cas dans ce flux mais ne dit pas comment les documents correspondent aux cas, et
nous ne transformerons donc pas les 88 en pourcentage. Il en découle une seule chose : un correcteur
pour un flux est un mélange dont la recette n’est pas divulguée au-delà d’un décompte de documents.
Le fichier consigne le remplaçant ; le classement ne le mentionne pas. Et comme le fichier ne dit pas
sur quels documents Fable a échoué, nous ne pouvons pas savoir si le REVOKE SESSIONS ci-dessus
venait de Fable ou d’Opus 5.
Les réponses de Jev sont publiées elles aussi, et elles ne penchent d’aucun côté. Sur les 31 questions où les deux correcteurs divergeaient, Jev s’est rangé 14 fois du côté d’Astra, 14 fois du côté du second correcteur, et 3 fois d’aucun des deux. Pour une note de 0 à 4, la convention propre à TypeSafe est la moyenne pondérée par les probabilités plutôt que le seul niveau le plus probable ; noté ainsi, une réponse bascule et cela devient 13 contre 15. Dans un cas comme dans l’autre, sur cet échantillon minuscule et trié, rien n’indique que Jev penche vers l’un des deux modèles dont la moyenne le note. Mais attention à ce que cela montre. Un partage égal, c’est à quoi ressemble l’absence de favori. C’est aussi, comme l’a relevé l’un de nos relecteurs extérieurs, à quoi ressemblerait un modèle entraîné à suivre la moyenne des deux. Ce comptage ne peut pas départager ces deux histoires. Gardez cela en tête pour la section suivante.
Rien de tout cela ne rend Jev meilleur ou pire que ne le dit le tableau de bord. Cela montre que la définition du « correct » dans ce banc d’essai est contestée à l’intérieur de ses propres données, d’une manière que TypeSafe a rendue visible et que son chiffre de une ne montre pas.
4. Où Jev a-t-il appris à juger ?
Notre programme de recherche pose une question à chaque modèle : d’où viennent ses habitudes ? A-t-il été entraîné sur la sortie d’un autre modèle ? Partage-t-il une base avec un concurrent ? Pour les modèles qui écrivent, un indice étonnamment fort se trouve dans l’écriture elle-même : les distributions de choix de mots sont assez distinctives pour départager cinq grands systèmes d’IA avec 97 % d’exactitude (Sun et al., ICML 2025). C’est l’équivalent machine de reconnaître un copiste à sa main.
Jev n’écrit rien, cet indice disparaît donc. Restent deux méthodes plus difficiles : des marqueurs délibérément implantés, et comparer un modèle à une version antérieure de lui-même pour voir de quel maître il a appris. Aucune des deux n’est accessible à un tiers. L’introduction de TypeSafe dit que ses modèles partent de modèles de langue préentraînés ordinaires et ajoutent une nouvelle étape d’entraînement, “Reinforcement learning for calibrated decisions”. TypeSafe aborde bien l’origine de ses données d’entraînement, dans une réponse de FAQ du billet de lancement qu’aucun rendu textuel de la page ne montre et que l’un de nos relecteurs a trouvée dans la charge utile de script de la page : “We make all the data ourselves” (nous fabriquons nous-mêmes toutes les données). Cela exclut un entraînement sur des données clients. Cela ne nomme pas de modèle de base, ne nomme pas de maître, et ne dit pas si des données fabriquées soi-même peuvent porter les réponses d’autres modèles. La même FAQ dit que Jev n’est “neither small nor an LLM” (ni petit ni un LLM), ce qui s’accorde mal avec la description, dans l’introduction, d’une troisième voie pour adapter des modèles de langue préentraînés ; TypeSafe ne réconcilie pas les deux, et nous ne le pouvons pas. Selon nos propres règles, l’ascendance de Jev est donc un programme de recherche et non un résultat, et plus mince que pour les modèles qui écrivent.
Reste une hypothèse que nous voulons énoncer avec soin. Si Jev avait été entraîné à s’aligner sur le même genre de moyenne de deux modèles que celle qu’emploie son banc d’essai, alors un panel de relecture qui ajouterait Jev comme « quatrième opinion indépendante » ajouterait en réalité un descendant de deux opinions qu’il possédait déjà, et tout procédé qui le compterait comme indépendant serait trompé sans le savoir. Deux éléments y touchent, aucun de façon décisive. Jev est au milieu du peloton sur le tableau de bord, là où l’on pourrait attendre d’un modèle entraîné à copier les correcteurs qu’il s’accorde davantage avec eux ; mais capacité et accord y sont enchevêtrés, c’est donc une preuve faible. Et sur les 31 questions contestées, Jev s’est partagé quatorze contre quatorze entre les deux correcteurs (treize contre quinze sous la notation propre à TypeSafe pour un type de réponse). C’est compatible avec l’absence de favori, et tout aussi compatible avec le suivi de la moyenne du couple, cela ne règle donc rien. Nous tenons l’hypothèse pour possible et disons ce qui la trancherait : que TypeSafe divulgue d’où viennent ses réponses d’entraînement, ou une comparaison qui oppose la proximité de Jev à la moyenne des deux correcteurs à celle d’autres modèles capables qui n’ont pas été entraînés sur eux, mesurée sur les 711 cas plutôt que sur les 20 que nous pouvons voir. La proximité seule ne trancherait pas : tout modèle capable tend à se placer entre deux correcteurs capables.
5. Notre propre part là-dedans
Cette note a été rédigée avec Claude Fable 5.1, l’un des deux modèles dont TypeSafe traite la moyenne comme la vérité. Une analyse antérieure que nous avons consultée venait d’un modèle d’OpenAI, l’autre moitié de cette moyenne. Les deux auteurs sont, autrement dit, parties à ce qu’ils évaluaient. Aussi, avant que cette note soit écrite, avons-nous fait attaquer l’évaluation sous-jacente par un relecteur d’une troisième entreprise, le Kimi de Moonshot. Il a corrigé trois de nos citations et cassé dix-neuf de nos conclusions, dont l’affirmation d’un premier jet selon laquelle Jev « s’accorde le moins » avec le consensus. Ce n’est pas le cas ; il est au milieu du peloton. Une deuxième instance Kimi a ensuite recalculé chaque comptage ci-dessus à partir des fichiers bruts et les a confirmés, et a cassé à son tour le premier jet de cette note : il avait converti les « 88 documents » de TypeSafe en une part de 240 cas, deux unités que les fichiers n’assimilent pas, et avait écrit qu’un correcteur « se notait lui-même », ce que les données ne soutiennent pas. Les deux ont disparu. Une troisième instance, le Grok de xAI, a recalculé les comptages une troisième fois et montré que notre exemple de sécurité prouvait moins que nous ne l’avions laissé entendre, que placer le fait du remplaçant à côté du classement d’Opus 5 invitait à une conclusion que nous avions écartée, et que l’un de nos comptages dépend d’un choix de notation. Une quatrième, de DeepSeek, les a recalculés encore et nous a pris à traiter un partage égal comme une preuve contre une hypothèse dont elle ne peut pas le distinguer. Une cinquième, une autre instance Kimi, a trouvé une réponse de FAQ sur les données d’entraînement que quatre lecteurs de page, le nôtre compris, avaient signalée comme absente. Une sixième, le Qwen d’Alibaba, exécutée par l’auteur et non par nous, a confirmé chaque comptage et a été la quatrième à dire que le paragraphe sur le remplaçant insinuait encore ; il se lit désormais comme une simple divulgation. Tout est corrigé ci-dessus. Une note sur des juges corrélés écrite par un juge corrélé vaut exactement ce que vaut sa vérification extérieure.
Le 17 septembre, deux relecteurs supplémentaires, une instance Codex d’OpenAI et une instance Kimi de Moonshot, ont examiné notre projet de tester Jev directement et montré que le test proposé au §4 ne pouvait pas trancher la question à lui seul. La phrase du §4 dit désormais ce qu’il lui faudrait.
Ce que nous ne disons pas
Nous ne disons pas que les décisions typées sont une mauvaise idée ; pour l’aiguillage et le tri c’est probablement une bonne. Nous ne disons pas que le banc d’essai de TypeSafe est malhonnête ; il divulgue plus que la plupart, et tout ce qui précède est compté à partir de ce qu’il divulgue. Nous ne disons pas que Jev a été entraîné sur les réponses de ses correcteurs ; le seul test que nous pouvions mener ne peut pas le dire. Nous disons trois choses. Un banc d’essai dont la vérité est une moyenne de deux témoins hérite de tout ce que ces témoins se trompent ensemble. Les cas publiés par TypeSafe montrent les deux témoins en désaccord sur la réponse dans huit cas sur dix-neuf. Et une classe de modèles qui ne peut pas écrire nous a retiré la preuve dont nous nous servirions sinon pour demander d’où vient son jugement.
Pourquoi cela nous importe
CounterProof relit le code écrit par IA comme le ferait un adversaire. Notre règle de travail est qu’un constat se tranche en exécutant le code, jamais en prenant un vote parmi les modèles. La nouvelle classe de modèles de décision sera notée, et entraînée, contre le consensus des modèles, parce que le consensus est bon marché et que de vraies étiquettes d’issue coûtent cher. Toute notre méthode est l’alternative coûteuse : des cas figés, des reproductions que vous pouvez exécuter, et des étiquettes qui viennent de ce que le code a réellement fait plutôt que de ce que deux modèles se sont accordés à prédire. Si les modèles à décisions typées deviennent la couche par laquelle les agents d’IA agissent, alors la question de savoir quel jugement cette couche porte devient la question de provenance de la décennie. La seule réponse honnête viendra d’une vérification contre les issues. C’est là le travail.
Le dossier technique. Méthode, schéma, le tableau complet des comptages, ce que le spécimen autorise et n’autorise pas, et les limites : Field Note 1, Consensus as oracle: TypeSafe’s Jev benchmark as a type specimen, sur notre site de recherche.
Divulgation, dont nous ne tirons rien. Claude Opus 5, le remplaçant pour une partie du corrigé du flux de sécurité, est aussi l’un des neuf modèles notés. Le fichier ne dit pas quels documents ont été substitués, et une réponse de remplacement doit encore l’emporter dans la moyenne face à Astra avant de devenir le corrigé. Nous n’en tirons aucune conclusion sur la note d’un quelconque modèle, et quatre relecteurs extérieurs nous ont dit que placer ce fait à l’intérieur de l’argumentation ci-dessus y invitait malgré tout ; il se tient donc ici.
Sources. Billet de lancement de TypeSafe, documentation (introduction,
introduction/machine-learning-primer, confidence, System One concepts, HTTP API, primitives/choice)
et evals.typesafe.ai, lus le 16 septembre 2026 ; les cinq pages et quatre fichiers de cas
(*-cases.js) servis par ce site, archivés avec leurs empreintes SHA-256 dans notre dépôt de
rapports. Kim, Garg, Peng et Garg, Correlated Errors in Large Language Models, ICML 2025,
arXiv:2506.07962. Sun, Yin, Xu, Kolter et Liu, Idiosyncrasies in Large Language Models, ICML 2025,
arXiv:2502.12150. Rawat et al., Reference-Based Distillation Detection in LLMs, arXiv:2607.09692.
Soons, Agentic Stemmatics, v1.29, doi:10.5281/zenodo.22790100. Les comptages du §3 portent
uniquement sur les vingt cas publiés ; les décisions finales ont été comparées comme des ensembles
non ordonnés d’actions ; un cas ne porte la réponse que d’un seul correcteur et est exclu des huit
sur dix-neuf.