La prédiction n'a pas de marche arrière

20 juil.
10 min de lecture

Un LLM ne raisonne pas et ne vérifie pas. Ce ne sont pas deux limites séparées — c'est la même propriété architecturale, vue sous deux angles.

J'ai publié deux articles sur Medium qui semblaient traiter de deux problèmes différents.

Le premier, Le cadavre exquis — pourquoi un LLM ne raisonne pas (janvier 2026), soutenait que les modèles de langage ne raisonnent pas. Ils continuent. Le jeu du cadavre exquis — où chaque joueur ajoute un mot à une phrase que personne ne contrôle — est le modèle explicatif le plus clair de ce que fait réellement un transformer.

Le second, Un modèle de langage ne distingue pas le vrai du probable (juin 2026), soutenait que les modèles ne peuvent pas distinguer ce qu'ils savent de ce qu'ils inventent. Leurs erreurs ne portent aucun signal interne. Une réponse correcte et une réponse fabriquée arrivent sous la même forme, avec la même assurance.

Quand je les ai écrits, je traitais ces deux arguments comme séparés. L'un portait sur le processus — le modèle n'a pas de plan, pas d'objectif, pas de critère d'arrêt. L'autre portait sur le résultat — le modèle n'a pas accès à la vérité, pas de moyen de vérifier ce qu'il a produit.

Ce sont deux faces d'un même mécanisme, et le reconnaître change ce qu'il faut construire.

Face A — le processus : un LLM ne raisonne pas

Dans l'article du cadavre exquis, j'ai défendu l'idée que le jeu du cadavre exquis n'est pas une métaphore du fonctionnement d'un modèle de langage — c'est une description exacte.

Dans le jeu, chaque joueur ajoute un mot à une phrase. Aucun joueur n'a la phrase complète. Aucun joueur n'a de plan. Aucun joueur ne sait quand la phrase est terminée, ni si elle a réussi. Chaque joueur ne dispose que de la phrase partielle jusqu'à présent, et à partir de cet état, choisit un mot qui semble compatible.

Un modèle de langage fait exactement cela. À chaque étape, il reçoit un contexte — le prompt, l'historique de conversation, les tokens déjà générés — calcule une distribution de probabilités, et sélectionne le prochain token. Il ne sait pas où il va. Il ne sait pas ce qu'il fait. Il continue.

L'argument central était que le raisonnement, proprement défini, suppose au minimum trois choses :

Un objectif explicite et détectable — quelque chose que le processus cherche à atteindre.
Des invariants capables de contraindre la trajectoire — des références stables qui survivent d'une étape à l'autre.
La possibilité de suspendre, invalider ou revenir en arrière — un moyen de reconnaître l'échec et de se rétablir.

Un modèle de langage n'a rien de tout cela. Il n'a pas d'objectif. Il n'a pas d'invariants — chaque token est produit en recalculant l'attention sur l'ensemble du contexte, et rien ne persiste comme contrainte sur ce qui suit. Il ne peut pas revenir en arrière. Une justification brillante produite au token N ne devient pas une règle au token N+1. Elle devient du texte — réabsorbée dans le contexte, traitée comme n'importe quel autre fragment.

Le chain-of-thought rend la continuation plus ressemblante à un raisonnement, mais il ne crée pas le raisonnement. Il régularise la trajectoire linguistique. Le modèle produit des justifications plus lisibles, plus structurées, plus convaincantes — mais une justification n'est pas une garantie. Le chain-of-thought est lui-même du texte, soumis aux mêmes dynamiques que tout le reste du contexte. Il influence les tokens suivants exactement comme n'importe quel autre contexte, sans statut particulier.

La conclusion de cet article était précise : la limite est architecturale, pas un défaut d'entraînement. Le transformer calcule l'attention à chaque étape, produit un token, et passe au suivant. Il n'y a pas d'état logique persistant. Pas de conclusion reconnue. Pas d'objectif porté dans le temps. Le modèle peut produire des trajectoires qui ressemblent à un raisonnement, mais il opère dans un autre régime — celui de la continuation probabiliste, pas de l'intention tenue.

Face B — le résultat : un LLM ne distingue pas le vrai du probable

Dans le second article, j'ai abordé le même modèle sous un angle différent : non pas ce qu'il fait en générant, mais ce qu'il peut dire de ce qu'il a généré.

L'argument était direct. Un modèle de langage n'est pas entraîné à dire le vrai. Son objectif de base est de prédire le mot suivant — de rendre probable ce qui a réellement été écrit dans le corpus d'entraînement. Sa cible est la vraisemblance : ce qui ressemble à ce qu'un humain aurait écrit. Ce n'est pas une négligence d'ingénieur. Il n'existe aucune fonction mathématique qui encode la vérité à l'intérieur du modèle. On sait écrire une fonction qui mesure l'écart à un corpus, ou l'accord d'un évaluateur humain. On ne sait pas en écrire une qui mesure le vrai. Là où la vérité est vérifiable — en mathématiques, en programmation — elle est fournie par un contrôle extérieur qui détecte les fautes. Le modèle apprend alors à satisfaire ce contrôle, non à connaître le vrai. Ailleurs, la vérité n'est ni disponible à grande échelle ni même définissable.

Au moment de produire une réponse, rien ne corrige cela. Le modèle procède mot par mot : pour chaque candidat, il évalue la probabilité qu'il vienne ensuite, puis en choisit un. Cette chaîne ne comporte aucune étape de vérification. Le modèle ne confronte son output à aucune base de faits. Il prolonge la suite la plus probable. Quand il ignore un fait, il comble le vide par une continuation plausible.

L'alignement par retours humains (RLHF) ne corrige pas cela. Il optimise ce qu'un évaluateur juge satisfaisant en quelques secondes. Mais satisfaisant et vrai ne se recouvrent que partiellement. Une réponse claire, assurée et bien formulée est récompensée parce qu'elle paraît juste. Une réponse exacte mais hésitante peut être jugée inférieure à une réponse fausse mais nette. Une erreur qui paraît juste franchit donc l'alignement, puisque c'est l'apparence de justesse qui est récompensée.

Le résultat est une indiscernabilité structurelle. Une réponse correcte, une réponse approximative et une réponse fabriquée arrivent sous la même forme, avec la même fluidité, la même assurance — rien dans la forme de la réponse ne sépare ce que le modèle sait de ce qu'il invente.

C'est pourquoi le constat courant — « l'IA aide quand on maîtrise déjà le sujet » — n'est pas une rustine provisoire mais une condition permanente. Pour repérer une faute, il faut déjà connaître la réponse correcte. Le modèle produit ; l'utilisateur trie, dans la limite de ses propres connaissances. Au-delà, l'erreur passe inaperçue.

Et voici la conclusion contre-intuitive : un meilleur modèle ne réduit pas cette exigence. Il l'augmente. Un modèle plus précis produit des erreurs plus rares mais plus subtiles, à des endroits inattendus. La vérification se fait plus rare mais plus exigeante. Et pire : la précision du modèle érode la vigilance. Quand un modèle a raison 99 % du temps, on cesse de chercher le 1 %. Mais le 1 % n'est pas devenu visible — il est seulement devenu plus rare. La rareté des erreurs réduit la méfiance sans rendre les erreurs détectables. Un modèle plus précis est, paradoxalement, plus difficile à surveiller qu'un modèle moins précis.

Le pont

Ces deux arguments semblent traiter de problèmes différents. L'un porte sur comment le modèle génère. L'autre sur ce qu'il peut dire de ce qu'il a généré.

Ils sont la même limite.

Le cadavre exquis ne sait pas où il va. La machine à vraisemblance ne sait pas si ce qu'elle a écrit est vrai. Ce ne sont pas deux déficits indépendants. Ce sont deux conséquences d'un seul fait architectural :

La prédiction est un processus en avant seule. Elle n'a pas accès à sa propre trajectoire, et pas accès à la vérité de son propre output.

Considérez ce que signifierait « avoir une marche arrière » pour chaque face.

Pour la Face A — le raisonnement — le modèle aurait besoin d'un accès prospectif : la capacité de tenir un objectif au-delà du prochain token, de porter un invariant à travers les étapes, de reconnaître quand une trajectoire a échoué et de revenir en arrière. C'est ce que suppose le raisonnement. Le transformer n'en a rien. Il calcule l'attention, choisit un token, et l'état disparaît. Rien ne regarde en avant. Rien ne persiste.

Pour la Face B — la vérité — le modèle aurait besoin d'un accès rétrospectif : la capacité de revenir sur ce qu'il vient de produire, de l'évaluer contre quelque chose d'extérieur à lui, et de le marquer comme correct ou incorrect. C'est ce que suppose la vérification. Le transformer n'en a rien. Il produit un token et passe au suivant. Rien ne regarde en arrière. Rien ne vérifie.

Observons la symétrie :

	Ce qui manque	Direction d'accès	Conséquence
Face A (raisonnement)	Objectif, invariant, critère d'arrêt	En avant (prospectif)	Le modèle ne peut pas guider sa propre trajectoire
Face B (vérité)	Vérification, confrontation aux faits, marquage d'erreur	En arrière (rétrospectif)	Le modèle ne peut pas valider son propre output

L'indiscernabilité du cadavre exquis — un mot pertinent et un mot absurde écrits avec la même assurance — est le même phénomène que l'indiscernabilité de la vraisemblance — une réponse correcte et une réponse fabriquée livrées avec la même fluidité. Non pas parce que le signal est faible, mais parce que l'architecture qui le produirait n'existe pas.

Une prédiction n'a pas de marche arrière. Elle ne peut pas regarder ce qu'elle a fait et demander « est-ce juste ? ». Et elle ne peut pas regarder où elle va et demander « est-ce bien ce que je voulais faire ? ». L'absence de l'un et de l'autre est la même absence. Le transformer tourne dans une seule direction, et dans cette direction, il n'y a pas d'auto-référence.

Le paradoxe de l'amélioration

Une fois qu'on voit les deux faces comme une seule, l'argument optimiste standard — « les modèles vont s'améliorer » — tombe différemment.

De meilleurs modèles prédisent plus précisément. Une prédiction plus précise signifie :

Moins d'erreurs, mais des erreurs déplacées vers des cas plus rares et plus subtils (Face B)
Des trajectoires plus cohérentes, mais des trajectoires toujours portées par aucun invariant (Face A)
Plus de fluidité, ce qui rend l'indiscernabilité pire, pas meilleure

L'amélioration agit sur la qualité de la continuation. Elle n'agit pas sur la nature du mécanisme.

Les deux pièges se répondent avec précision. Le chain-of-thought fait croire que le modèle raisonne — mais la chaîne est du texte, pas une idée tenue. La précision fait croire que le modèle est fiable — mais elle réduit la méfiance sans rendre les erreurs visibles. Dans les deux cas, le modèle produit un output qui ressemble à ce que produiraient le raisonnement ou la vérification, mais le mécanisme qui le rendrait authentique — la marche arrière, l'auto-référence — est absent. L'amélioration rend la ressemblance meilleure. Elle n'installe pas le mécanisme.

Voici le point décisif : l'amélioration du modèle et l'amélioration de l'architecture ne sont pas la même chose. Un meilleur prédicteur reste un prédicteur. Il prédit plus, il prédit mieux, il prédit avec moins d'erreurs visibles. Mais il n'a toujours pas de marche arrière.

Ce que cela implique architecturalement

Si les deux limites sont la même propriété architecturale, alors la solution n'est pas « meilleures données » ou « plus de paramètres » ou « meilleur prompt ». Ces leviers agissent sur la qualité du forward pass. Ce qui manque est structurel :

L'architecture n'a pas de boucle d'auto-référence.

Un transformer tourne : prédire → produire → prédire → produire. À aucun moment il n'évalue son propre output contre quelque chose d'externe. À aucun moment il ne tient un objectif qui contraint la prochaine prédiction. La boucle est :

prédire → produire → jeter l'état → prédire à nouveau

Il n'y a pas de

prédire → évaluer → corriger

Pas de

tenir l'objectif → prédire → vérifier contre l'objectif → ajuster

Ce qui manque n'est pas un forward pass plus grand. Ce qui manque est l'autre moitié de la boucle :

Un objectif qui persiste à travers les tokens. Pas un prompt — un prompt est du texte, absorbé dans le contexte comme tout le reste. Un invariant architectural : quelque chose qui se trouve en dehors du flux de génération, qui n'est pas écrasé par le prochain token, et qui contraint la trajectoire.
Un chemin de vérification. La capacité de prendre ce qu'on vient de produire, de le comparer à un ground truth qui vit en dehors de la distribution du modèle, et de le marquer. Pas la confiance — la confiance est juste une propriété de la distribution. Un contrôle : « cet output correspond à un fait » ou « cet output ne correspond pas ».
Un signal d'auto-surveillance distinct de la fluidité. L'incertitude du modèle est actuellement indiscernable de sa fluidité. Une réponse fausse bien écrite et une réponse juste bien écrite se ressentent pareil — pour le modèle et pour le lecteur. L'architecture a besoin d'un canal qui sépare « j'ai produit ceci avec fluidité » de « je peux vérifier que c'est correct ».

Aucune de ces exigences n'est exotique. Les thermostats ont des objectifs. Les bases de données ont des chemins de vérification. Les compilateurs ont des signaux d'auto-surveillance. Le fait qu'on ne pense pas à ces choses comme à de « l'IA » est lui-même un symptôme du problème — le domaine a confondu l'intelligence avec le forward pass d'un prédicteur, et oublié que l'intelligence dans tout autre système inclut la marche arrière.

L'hypothèse que « scale + data → raisonnement » n'est pas seulement optimiste. Elle est architecturalement incohérente. Scaler un processus en avant seule en fait un meilleur processus en avant seule — cela ne lui donne pas de marche arrière.

Ce n'est pas un argument contre les modèles de langage. Ils sont utiles, puissants, et deviendront meilleurs dans ce qu'ils font. C'est un argument contre la confusion entre ce qu'ils font et ce qu'ils semblent faire. Un prédicteur qui prédit bien est un bon prédicteur — ce n'est pas un raisonneur, pas un vérificateur, parce que le raisonnement et la vérification supposent ce que la prédiction structurellement manque : une marche arrière.

Changer de cadre

Les deux articles que j'ai écrits à des mois d'intervalle identifiaient chacun un mur. L'un disait : le modèle ne raisonne pas, il continue. L'autre disait : le modèle ne vérifie pas, il génère avec vraisemblance. Ce que je vois maintenant, c'est que les deux murs sont le même mur, et qu'il a un nom.

La prédiction n'a pas de marche arrière.

Cette phrase change la question. La question cesse d'être « comment rendre le modèle plus raisonnant ? » — parce que le modèle ne raisonne pas, et améliorer ses prédictions ne le fera pas raisonner. La question devient : que construire autour du prédicteur pour lui donner ce que le prédicteur ne peut pas se donner à lui-même ?

Pas un meilleur prompt. Pas un modèle plus grand. Une architecture qui porte des objectifs, vérifie son output, et sépare la confiance de la vérité.

C'est un autre type de travail. Ce n'est pas le travail de l'entraînement. C'est le travail de la conception.