§01 La question
Le sens n'a pas besoin de mots pour exister
Vous avez peut-être entendu dire qu'interroger un modèle génératif en mandarin coûte parfois moins de tokens. La raison est instructive : un idéogramme n'est pas une lettre. C'est une unité graphique de sens, parfois élémentaire, parfois composée ; une même idée peut donc emprunter une structure plus compacte sans perdre sa capacité descriptive.
Le propos n'est pas de comparer les langues humaines. C'est que l'observation soulève une question plus générale : à quel niveau d'abstraction une pensée doit-elle être représentée ? Quand un modèle raisonne « étape par étape », il écrit ces étapes en phrases humaines, comme s'il énonçait ses pensées à voix haute. Cette narration est pour nous. Rien ne dit qu'une machine doive raisonner en anglais, ou en français, pour bien raisonner.
Une intuition, pas un résultat : le sens peut emprunter des unités plus denses que les mots, et ces unités n'ont pas à être conçues par quiconque. Savoir si un modèle peut réellement raisonner dans de telles unités, et comment on pourrait jamais le vérifier, est ce que cette série met à l'épreuve.
§02 La distinction
Raisonner et expliquer le raisonnement sont deux fonctions différentes
Deux extrêmes encadrent la façon dont un modèle peut raisonner aujourd'hui. Une chaîne de pensée en langage naturel est lisible, mais verbeuse : elle consomme du contexte, du temps d'inférence et du coût, et elle n'est pas toujours un compte rendu fidèle de ce que le modèle a réellement calculé. Les activations internes brutes du modèle sont efficaces, mais totalement opaques. Entre les deux existe peut-être un espace plus utile : un langage interne discret, compressé et appris, dont les unités représentent des concepts, des relations ou des états intermédiaires plutôt que des mots.
Une tentation mérite d'être écartée d'emblée : concevoir ce langage nous-mêmes. Rien ne garantit qu'un code conçu par un humain soit optimal pour un modèle, pas plus que ne l'est la grammaire humaine. L'objectif est de créer les conditions pour qu'un langage interne émerge à l'entraînement, puis d'inspecter ce qui a émergé.
Et c'est là que vit la vraie difficulté. Un code natif machine est, par construction, plus difficile à auditer qu'une phrase. Tout système de ce type vous doit donc une preuve : perturbez le code interne, et les réponses doivent se dégrader. Sinon, le modèle ne raisonne pas à travers le code ; il le contourne, et les symboles sont de la décoration. Cette exigence de vérification, plus que la performance brute, est ce autour de quoi cette ligne de recherche a fini par se construire.
§03 L'espace de conception
Sept façons de câbler un canal de raisonnement discret
Entre octobre 2025 et janvier 2026, nous avons exploré l'espace de conception ci-dessous. La colonne de statut en est la partie honnête : certaines familles ont été menées jusqu'à un verdict, d'autres explorées puis archivées, une n'a jamais quitté le papier. Seules les entrées portant un statut de run s'appuient sur des preuves ; les notes en tiennent les journaux.
§04 Où cela en est
Une preuve nette, trois échecs instructifs, une question ouverte
Le résumé honnête tient en trois phrases. À petite échelle, sous un test assez strict pour échouer, un modèle a démontrablement fait passer son calcul par un code discret appris : corrompez le code et les réponses s'effondrent. Chaque tentative de mise à l'échelle de ce mécanisme, ou de greffe sur un modèle pré-entraîné, a échoué, et les échecs nous ont plus appris que le succès. Pendant ce temps, des équipes plus grandes, chez Meta et IBM entre autres, ont porté le même mécanisme à une échelle et une utilité réelles ; leurs travaux sont la référence, et ce que nous gardons est le standard de vérification que le domaine ne rapporte généralement pas.
Les deux notes ci-dessous tiennent les journaux complets : l'architecture et le protocole de nécessité causale avec le run qui l'a passé, et les trois impasses avec les chiffres exacts qui les ont exposées.
Note 1 · méthode & résultat
Un canal de raisonnement doit se briser quand on le brouille
L'architecture à air-gap, le protocole à trois interventions, et le run de 26,5 M de paramètres qu'il a certifié.
Note 2 · les échecs
Trois façons dont un canal de raisonnement échoue en silence
Trois journaux de runs de fin 2025, dont l'échec qui a franchi tous les seuils du tableau de bord.
§05 La question ouverte
La question du titre reste ouverte
Cette ligne est née, disons-le franchement, d'une volonté de prendre de l'avance : être tôt sur un mécanisme original et construire quelque chose à nous autour. Sur cette ambition, elle a échoué. Le mécanisme s'est révélé être un territoire public, des laboratoires mieux dotés l'ont porté à l'échelle, et notre propre passage à l'échelle s'est effondré. L'arc est publié malgré tout, parce que ce qui a survécu est plus transférable que ce qui était visé : un moyen de savoir, pour tout système de ce type, si son code interne porte réellement le raisonnement.
La question du titre reste donc ouverte, pour tout le monde. Un tel canal peut exister et être rendu démontrablement porteur ; il échoue de manières que les tableaux de bord ne voient pas ; et un test sépare les deux. Si la direction en attente ressort un jour du tiroir, elle sera exécutée sous ce même test, et publiée dans un sens comme dans l'autre.
Chaque affirmation factuelle de cette page est documentée dans les deux notes et leurs journaux d'expérience ; cette vue d'ensemble n'en ajoute aucune.