La fluidité n’est pas la vérité Image : générée par IA

J’ai demandé à une IA de faire une recherche, et elle est revenue avec une réponse soignée, structurée, assurée — et fausse, d’une manière que je n’ai remarquée que par accident. Ma première réaction a été : est-ce que je m’en sers mal ? La littérature dit non. Ne pas remarquer est le résultat par défaut, même pour des personnes attentives, et la solution n’est pas la vigilance. C’est de convertir ce malaise en quelque chose qu’une machine peut vérifier.

L’heuristique de fluidité que les LLM ont brisée

Les humains fonctionnent avec un raccourci peu coûteux : si quelque chose est facile à traiter, c’est probablement vrai. Les psychologues appellent cela l’heuristique de fluidité, et pendant la majeure partie de l’histoire, c’était un pari raisonnable — un locuteur qui semble articulé, confiant et cohérent est généralement plus compétent, car produire ce type de discours sous les contraintes humaines est difficile à simuler longtemps. Les LLM sont les premiers locuteurs produits en masse qui brisent cette corrélation. La fluidité ne coûte désormais plus rien au modèle. La confiance est une distribution de tokens, pas un signal de compréhension vérifiée.

Cet écart apparaît directement dans la façon dont les gens évaluent les réponses de l’IA : pour une même réponse, les gens la jugent plus confiante lorsqu’on leur dit qu’elle vient d’une IA que lorsqu’on leur dit qu’elle vient d’un humain (phys.org, 2026-05). Ce n’est pas le modèle qui est devenu plus sûr de lui. C’est l’a priori du lecteur.

Les experts ne sont pas épargnés

Si c’était un problème d’inexpérience, la formation le résoudrait. Ce n’est pas le cas.

Des médecins déjà formés au diagnostic assisté par IA n’ont pas réussi à filtrer les recommandations de LLM incorrectes mais plausibles — le biais d’automatisation a survécu à la formation censée en immuniser (medRxiv, 2025-08). C’est le mécanisme en jeu, et c’est pire qu’il n’y paraît, car les erreurs qui passent au travers ne sont pas du genre facile à repérer. Les erreurs de niveau interprétatif sont plus difficiles à détecter que les erreurs factuelles — un nom erroné ou une date erronée saute aux yeux ; un cadrage erroné, non, parce qu’il semble plausible et correspond au récit que le lecteur attendait déjà (Not Wrong, But Untrue, arXiv:2509.25498). La connaissance du domaine permet de repérer les faits. Elle ne permet pas de repérer le cadrage de façon fiable.

Derrière ces deux constats se cache un écart de calibration : les LLM affichent un niveau de confiance qui dépasse systématiquement leur précision réelle. Mesuré sur onze modèles et six ensembles de questions, le niveau de confiance moyen déclaré était de 88 %, contre une précision réelle de 79 % (Confidence Calibration in Large Language Models, arXiv:2605.23909). Le modèle ne ment pas sur son degré de certitude. Il est mal calibré, et cette mauvaise calibration se lit comme de l’autorité.

Se sentir plus rapide tout en étant plus lent

La démonstration la plus claire que ce n’est pas un problème de connaissance vient de l’étude METR de 2025 sur des développeurs open source expérimentés — 16 développeurs, 246 tâches réelles, des dépôts comptant en moyenne plus d’un million de lignes de code. Ce ne sont pas des personnes qui font naïvement confiance à l’IA. Ils travaillent sur du code en production tous les jours.

  • Ils s’attendaient à ce que l’IA les rende 24 % plus rapides.
  • La mesure a montré qu’ils étaient en réalité 19 % plus lents.
  • Après avoir terminé les tâches — le coût réel en temps déjà derrière eux — ils continuaient de croire qu’ils avaient été 20 % plus rapides.

L’illusion a persisté même après que la tâche a été terminée et chronométrée. C’est ce point qui mérite qu’on s’y attarde : l’expérience ressentie n’est pas une preuve, et elle ne s’autocorrige pas. Un état où l’on livre, où ça « semble productif », peut se maintenir de façon stable même lorsqu’il n’est mesurablement pas productif, et aucune quantité de l’avoir vécu ne corrige cela à elle seule.

Pour être précis sur la portée de cette étude : seize développeurs, c’est un petit échantillon, et METR précise elle-même que le résultat est spécifique au contexte — des mainteneurs chevronnés, des bases de code matures d’un million de lignes qu’ils connaissaient en profondeur — et qu’il ne faut pas l’étendre à « l’IA ralentit tout le monde ». Ne transportez donc pas ces 19 % ailleurs comme une estimation ponctuelle. Ce sur quoi cet argument s’appuie, ce n’est pas l’ampleur mais le signe de l’écart : l’effet mesuré était négatif, l’effet perçu était positif, avant comme après le travail, et l’estimation moyenne a posteriori s’est retrouvée proche de l’attente initiale, loin de la mesure réelle. Si la perception de soi n’était que bruitée, les estimations a posteriori se disperseraient autour de la vérité mesurée. Ce n’est pas ce qui s’est passé. Elles sont restées là où était l’attente.

Pourquoi l’économie de la vérification s’est effondrée

Avant les LLM, juger la qualité d’une production en regardant le résultat était un indicateur raisonnable de la compétence du producteur — les deux étaient corrélés, car un travail bâclé venait d’une production bâclée. Les LLM ont rompu ce lien. La qualité du résultat et la compétence du producteur ne sont plus couplées, ce qui signifie que l’évaluation fondée uniquement sur l’artefact a cessé de fonctionner comme diagnostic (Fluent, Confident, Wrong, ScienceDirect 2026). La vérification est devenue plus coûteuse que la production.

Pire, le coût d’une erreur n’est pas proportionnel au taux d’erreur. Quand les parties fausses se lisent exactement comme les parties justes — même registre, même assurance, même finition — on ne peut pas localiser les dégâts, si bien que quelques pour cent de contamination ne coûtent pas quelques pour cent. Cela empoisonne tout le lot : chaque affirmation du résultat porte désormais le soupçon de la pire d’entre elles. C’est pourquoi « le modèle a raison 95 % du temps » n’est pas le chiffre rassurant qu’il semble être. La confiance s’effondre de façon discontinue, bien avant la précision.

Les habitudes de vérification de presque personne ne se sont mises à jour en conséquence — c’est exactement l’écart sur lequel repose l’argument du Ratchet Pattern de ce site : la génération peut rester probabiliste, mais le contrôle qui s’exerce sur elle ne le peut pas.

Pas un mauvais usage — le comportement par défaut de la population

Alors : est-ce que je m’en sers mal ? La littérature dit le contraire. La définition classique du mauvais usage consiste à traiter la fluidité comme un signal de confiance et à désactiver la vérification — et ce n’est pas un cas marginal, c’est le comportement par défaut de la plupart des gens, y compris des personnes formées. Les médecins de l’étude sur le biais d’automatisation n’ont pas maintenu leur signal de désaccord. Les développeurs de l’étude METR non plus. Si rester méfiant face à une réponse fluide et apparemment infalsifiable vous semble relever de la paranoïa, il vaut la peine de noter que cela vous place déjà devant la majorité de la population mesurée — y compris ceux dont le travail consistait précisément à repérer cela.

Ce n’est pas une observation nouvelle pour ce site — c’est le même terrain sur lequel atterrissent à la fois la flagornerie comme caractéristique commerciale et pourquoi les agents fonctionnent et pourquoi ils se cassent : le mode de défaillance est structurel, pas un simple manque d’attention personnel, et aucune dose de « sois juste plus prudent » n’y résiste à l’échelle.

L’unique remède

Il n’y a exactement qu’un seul ajustement qui compte ici : ne pas s’arrêter au sentiment de malaise. Le convertir en un critère d’acceptation observable, et fixer ce critère avant que le travail ne commence, pas après. Le ressenti ne s’autocorrige pas — METR l’a démontré directement — mais la mesure, si.

« Convertir » est une procédure, pas une humeur. Pour toute affirmation porteuse — sur le point de façonner une décision — répondez à deux questions avant de la laisser faire :

  1. Que faudrait-il qu’il soit vrai pour que cela tienne ? Une réponse fluide énonce rarement ses prémisses ; elle les dissimule dans le cadrage, ce qui explique précisément pourquoi la connaissance du domaine glisse dessus sans prise. Cette question fait remonter la prémisse cachée au niveau d’une affirmation, où elle peut enfin être attaquée.
  2. Qu’observerais-je si c’était faux ? Cela force l’affirmation à prendre un engagement concret dans le monde. Une conclusion qui n’implique aucune différence observable par rapport à sa propre négation n’est pas de la connaissance — c’est de la cohérence, et la cohérence est ce qu’un modèle optimise quand rien n’est en jeu.

Pour du code généré par IA, les deux questions se compressent en un seul blanc à remplir avant même que le code existe : « Si c’est utile, alors immédiatement après sa mise en production, un utilisateur peut ___. » Le blanc doit nommer une action dans le monde de l’utilisateur, pas dans celui du code — une compilation propre et une exécution qui passe sont des vérifications de cohérence, pas des vérifications d’utilité. Et si vous ne pouvez pas remplir le blanc, c’est là le résultat le plus précieux de toute la procédure : cela signifie que vous ne savez pas encore ce que vous avez demandé, et que la réponse fluide était sur le point de vous le cacher.

Tout le reste dans la littérature sur l’atténuation — séparer le langage assuré du fait vérifié, décomposer le résultat en unités vérifiables indépendamment, introduire de la friction avant que la réponse fluide n’arrive — n’est que cette même conversion appliquée à des niveaux différents.

« N’est-ce pas simplement du scepticisme rebaptisé ? »

L’objection évidente : « vérifier avant de faire confiance », c’est ce que le scepticisme a toujours signifié, alors qu’y a-t-il vraiment de nouveau ici ? La réponse est le moment où le jugement intervient, et ce moment constitue tout le mécanisme.

Le scepticisme est une posture que l’on applique en regardant le résultat — et chacune des études ci-dessus mesure précisément l’échec de cette posture. Les médecins n’étaient pas crédules ; ils avaient été formés au diagnostic assisté par IA — l’intervention censée installer précisément cette posture — et ils regardaient les recommandations en face. Les recommandations les ont désarmés quand même, parce qu’un artefact fluide module le jugement qu’on lui applique — c’est exactement ce qu’est l’heuristique de fluidité. Un critère fixé avant que le résultat n’existe n’a aucun artefact fluide par lequel se laisser désarmer. Il n’y a rien sur quoi la confiance puisse agir, parce que le test a été fixé à un moment que le résultat ne peut pas atteindre.

La science a institutionnalisé le même mouvement, pour la même raison. Le préenregistrement n’existe pas parce que les évaluateurs manqueraient de scepticisme ; il existe parce qu’un chercheur qui regarde des données déjà collectées peut rationaliser n’importe quel résultat avec fluidité, donc le domaine a déplacé l’hypothèse avant les données. Si cette distinction était vide de sens — si le scepticisme après fonctionnait aussi bien que le critère avant — alors les évaluateurs formés filtreraient les mauvaises recommandations à un taux élevé. C’est précisément l’expérience qu’a menée l’étude sur le biais d’automatisation, et le résultat a été négatif.

« La vérification coûte plus cher que la production — qui peut se le permettre ? »

L’objection plus incisive : si vérifier un résultat coûte plus cher que le générer, alors « vérifier avant de faire confiance » revient à conseiller d’être plus lent que tout le monde, et la plupart des décisions réelles n’ont pas les moyens de se le payer. Cette objection interprète mal la prescription, et ce à deux titres.

D’abord, le critère n’est pas la vérification. Écrire ce que l’on observerait si l’affirmation était fausse coûte une phrase, et l’on ne paie le coût de la vérification que pour les affirmations porteuses. Un observable prédéfini est également bien moins coûteux à vérifier qu’un artefact fluide ne l’est à auditer de façon ouverte — l’essentiel du coût de la vérification a posteriori ne réside pas dans la vérification elle-même, mais dans le fait de ne pas savoir par où commencer, et c’est le critère qui fait s’effondrer cet espace de recherche.

Ensuite, sauter la vérification ne supprime pas le coût — cela le déplace en aval et le sort des comptes. Les développeurs de l’étude METR n’ont pas évité de payer ; le coût est apparu dans le temps mesuré, tandis que leur comptabilité ressentie enregistrait un profit. C’est là que l’objection se trompe de comparaison. Il ne s’agit pas de « vérification contre gratuité ». Il s’agit de vérification maintenant, chiffrée et visible, contre absorption de l’erreur plus tard, non chiffrée et comptabilisée comme un gain.

Écrire le relecteur comme du code

La procédure en deux questions décrite plus haut a encore un point faible : elle dépend de quelqu’un qui se souvient de l’appliquer. C’est le même échec reformulé un niveau au-dessus. Une discipline qui ne vit que dans la tête d’une personne se dégrade exactement comme le malaise lui-même — aiguë à la première lecture attentive, disparue à la dixième lecture fluide. La forme durable de « convertir cela en un critère d’acceptation observable » n’est pas une habitude. C’est une étape de build : confier le critère à une machine et faire en sorte que le pipeline refuse de passer sans lui.

Ce n’est pas hypothétique — c’est précisément ce qui a conditionné le passage de l’article que vous lisez. Reins est un framework open source construit exactement pour cela : chaque critère d’acceptation devient une quest, une règle qui évalue un Fact{Where, Expected, Actual} et rapporte un succès ou un échec sans jamais se demander si la prose environnante paraît convaincante. Avant même qu’une seule phrase de ce texte n’existe, un humain a consigné les affirmations précises qu’il était autorisé à faire ; une machine a passé le brouillon au crible de cette liste ; et le relecteur chargé de vérifier la couverture des affirmations travaillait depuis un contexte distinct de celui qui avait écrit le brouillon, parce que se relire soi-même n’est pas une relecture — abloq, le système de quests sur lequel tourne ce site, encode cela comme une règle, pas comme une demande.

C’est là le contenu réel de « ne vous fiez pas seulement au ressenti ». Pas davantage de vigilance — un point du pipeline où la vigilance cesse d’être une dépendance. Les deux questions de la section précédente — ce qui doit être vrai, ce qui la falsifierait — cessent d’être quelque chose qu’il faut se souvenir de poser dès lors qu’elles deviennent une règle de gate plutôt qu’une note mentale. Une quest ne se fatigue pas à la dixième lecture.

Articles liés

Sources

Journal des modifications

  • 2026-07-09 : Version initiale