Les LLM hallucinent à 30%. Qu'est-ce que ça veut dire ?
Lecture critique de HalluHard (Fan et al., 2026)
TL;DR : HalluHard est un benchmark qui mesure les hallucinations des LLM sur des questions difficiles, multi-tours, dans quatre domaines experts. Les meilleurs modèles (Claude Opus-4.5, GPT-5.2) conservent un taux d'erreur de 30% même avec recherche web. Le papier apporte une distinction précieuse entre erreur de référence (citer une source qui n'existe pas) et erreur de contenu (citer une source réelle mais lui attribuer des choses qu'elle ne dit pas). La recherche web résout la première ; elle ne résout pas la seconde. Mais 30% d'erreur, c'est aussi 70% de réussite sur des tâches expertes en quelques secondes, et le papier ne propose que la première lecture. Cette critique tente d'identifier ce qui manque (baseline humaine, décomposition de la chaîne d'erreurs, circularité du juge, prompting) et propose un troisième type d'erreur que les auteurs ne formalisent pas : la compression sémantique infidèle.
Article cible : Fan, D., Delsad, S., Flammarion, N., Andriushchenko, M. (2026). HalluHard: A Hard Multi-Turn Hallucination Benchmark. arXiv:2602.01031. )
Pourquoi ce papier m'intéresse
Les benchmarks d'hallucination existants sont en train de saturer. SimpleQA plafonne à 95% de réussite avec recherche web. LongFact descend à environ 1% d'hallucination pour la famille GPT-5. Quand un thermomètre ne bouge plus, il ne mesure plus rien d'utile.
HalluHard est un nouveau benchmark, et il reste difficile. 950 questions initiales, quatre domaines à fort enjeu (droit, recherche scientifique, directives médicales, code), un cadre multi-tours avec des questions de suivi qui creusent et qui piègent. Les modèles doivent sourcer leurs réponses, et un pipeline automatique va vérifier les sources en texte intégral, PDF compris. Le résultat : même les meilleures configurations conservent un taux d'hallucination d'environ 30% (Figure 1, p. 1). Les moins performantes montent à 80%.
C'est un chiffre qui m'a arrêté. 30%, ça veut dire qu'un modèle de pointe, équipé de recherche web, se trompe sur presque un tiers de ses affirmations sourcées dans des domaines experts. Mais ça veut dire aussi qu'il a raison sur 70% d'entre elles, en quelques secondes, sur des sujets de niche. Les deux lectures sont valides. Le papier n'en propose qu'une seule (la première), et c'est l'une de ses faiblesses. J'y reviens.
Ce que le papier apporte
Deux types d'erreurs, pas un seul
C'est ce qui m'a le plus intéressé dans le papier. Les auteurs séparent deux modes de défaillance (Figure 2, p. 2 ; Table 5, p. 8). L'erreur de référence : le modèle cite une source qui n'existe pas. L'erreur de contenu : la source existe, elle est correctement citée, mais le modèle lui attribue des informations qu'elle ne contient pas.
La Table 5 quantifie la distinction dans le domaine de la recherche. Pour Opus-4.5 sans recherche web, les erreurs de référence atteignent 38.6% et celles de contenu 83.9%. Avec recherche web, les erreurs de référence chutent à 7%, mais celles de contenu restent à 29.5%. La recherche web résout largement le problème de la localisation des sources. Elle ne résout pas le problème de leur lecture fidèle.
Ce deuxième mode est le plus dangereux en pratique. La présence d'une citation donne à l'utilisateur une fausse impression de fiabilité ; l'erreur est plus difficile à détecter que si la source n'avait pas été citée du tout. C'est le piège du modèle qui a l'air de savoir de quoi il parle, justement parce qu'il montre ses sources.
La zone dangereuse du savoir de niche
La section 6 (p. 8) teste un truc intéressant : est-ce que les modèles savent s'abstenir face à des sujets qu'ils ne connaissent pas ? Les auteurs distinguent les faits totalement inventés des faits de niche (peu documentés). Résultat : face à du totalement fictif, les modèles s'abstiennent assez bien. Mais face à un sujet partiellement familier, ils tentent de répondre. C'est dans cette zone intermédiaire que les hallucinations se concentrent.
C'est exactement le profil de risque réel pour un utilisateur. Le danger, ce n'est pas la question absurde à laquelle le modèle répondrait n'importe quoi. C'est la question plausible sur un sujet que le modèle connaît "un peu" ; assez pour se sentir autorisé à répondre, pas assez pour détecter ses propres incohérences. Il a des données. Il a plein de données. Elles sont juste incomplètes ou fausses, et il ne le sait pas.
Le raisonnement n'est pas une solution uniforme
L'article teste différents niveaux de raisonnement (Table 4, p. 7) et compare des modèles thinking et non-thinking. Les résultats sont nuancés, et c'est ce qui les rend intéressants.
Le cas de DeepSeek est frappant. DeepSeek-Reasoner (76.8%) ne fait pas mieux que DeepSeek-Chat (75.8%). C'est le seul modèle raisonneur qui ne montre aucune amélioration par rapport à sa version standard. Pour Opus-4.5, passer d'un effort de raisonnement low à high ne change presque rien (46.2% à 44.8%), alors même que le modèle produit davantage de références et de claims. Plus de raisonnement génère des réponses plus détaillées, ce qui crée mécaniquement plus d'opportunités d'erreur. Le raisonnement aide, mais il n'est pas un correctif universel ; et poussé trop loin, il peut même diluer la précision dans le volume. Je reste personnellement prudent par rapport à ce résultat et à son explication.
L'indice du coding
Dans trois domaines sur quatre, les hallucinations augmentent au fil des tours de conversation (Figure 6, p. 7). En coding, c'est l'inverse : elles diminuent. L'explication des auteurs est convaincante. Les conversations de code commencent large ("construis X") puis se resserrent ("corrige cette fonction", "gère ce cas limite"). Le contexte se focalise au lieu de s'élargir.
Ce résultat est un indice important. Il suggère que la dégradation multi-tours n'est pas un effet mécanique du nombre de tours, mais un effet de la dilution progressive du contexte. Quand le contexte se resserre, les performances s'améliorent. Quand il s'élargit (plus de sources, plus d'informations accumulées, plus de bruit), elles se dégradent. Ce n'est pas la conversation qui pose problème ; c'est l'accumulation non filtrée.
Chaque modèle cherche différemment
Un détail qui dépasse le cadre du benchmark : les auteurs notent (p. 8) que Claude cite significativement plus de sources encyclopédiques, là où GPT va davantage chercher des articles de recherche. Cette différence de stratégie de récupération influence directement les résultats.
C'est une observation qui mérite qu'on s'y arrête. Elle montre que le taux d'hallucination ne dépend pas seulement de la capacité du modèle à raisonner ; il dépend de la manière dont le système de recherche sélectionne et priorise les sources en amont. Autrement dit, une partie du problème se joue avant même que le modèle commence à réfléchir.
Un pipeline de jugement solide
Les auteurs ont recruté deux étudiants de troisième cycle pour annoter indépendamment plus de 120 claims sur 10 réponses (p. 5). Le processus a pris environ 10 heures par annotateur. L'accord inter-annotateurs atteint 93.5% sur les références et 92.5% sur le contenu (Table 2, p. 5). Le juge automatique atteint 97% d'accord avec les annotateurs sur les références avec les humains et 87.9% sur le contenu. L'Appendice D (p. 21-23) détaille les cas de désaccord avec des exemples concrets. Le juge n'est pas parfait, mais il est correctement caractérisé, et c'est suffisamment rare dans ce type de papier pour être souligné.
Ce qui pourrait manquer au papier
La baseline humaine
L'article valide son juge contre des annotateurs humains. Mais il ne compare pas la performance des modèles à celle d'humains sur les mêmes questions. Ce sont deux choses distinctes.
La première question est : est-ce que l'outil de mesure est fiable ? Les auteurs y répondent correctement. La seconde question est : que signifie un taux d'hallucination de 30% ? Ils n'y répondent pas.
Sans baseline humaine, le chiffre est impossible à interpréter. Combien de temps un juriste, un chercheur ou un médecin mettrait-il pour répondre aux mêmes questions avec des sources vérifiées ? Quel serait son taux d'erreur avec un temps limité ? Et un non-spécialiste ? Ferait-il les mêmes types d'erreurs que le modèle, ou des erreurs différentes ? Un humain qui s'appuie sur une documentation obsolète sans le savoir commet une erreur de mise à jour, pas une erreur de compétence. Un modèle qui fait la même chose sur le même corpus commet-il une "hallucination" ? L'indication indirecte fournie par les auteurs (10 heures pour annoter 120 claims) suggère que la tâche est ardue même pour des humains. Mais ce n'est pas une baseline de performance ; c'est un coût d'évaluation.
Et ça change tout pour la conclusion opérationnelle. Pour un décideur qui évalue l'utilité d'un LLM, la question pertinente n'est pas "le modèle fait-il des erreurs ?" (tout système en fait, y compris les humains) mais "le modèle fait-il moins d'erreurs qu'un humain pour un coût et un temps donnés ?" Le papier ne permet pas de répondre à cette question. C'est dommage, parce que les données sont là ; il manque juste le point de comparaison.
Le cadrage déficitaire
C'est un point que j'ai mentionné en ouverture, mais qui mérite qu'on s'y arrête, parce qu'il change la lecture de l'ensemble.
L'article présente ses résultats exclusivement sous l'angle du déficit : "les modèles hallucinent encore beaucoup, même les meilleurs." Regardons les mêmes données autrement. Dans 70% des cas, un modèle comme Opus-4.5 est capable de retrouver la bonne source, de la citer correctement, et d'en extraire une synthèse fidèle. Sur des questions de niche. En droit, en médecine, en recherche scientifique. Sur des sujets où les réponses ne se trouvent pas dans un paragraphe Wikipedia mais dans des PDF de guidelines, des articles de recherche à faible citation, des jurisprudences spécifiques. Et il le fait en quelques secondes.
Il faut mesurer ce que ça veut dire. Les annotateurs humains du papier ont mis 10 heures à deux pour vérifier 120 affirmations sur 10 réponses. Un juriste, un chercheur, un médecin qui devrait répondre aux mêmes questions avec le même niveau de sourcing mettrait probablement des heures, voire des jours. Et il ferait lui aussi des erreurs (on ne sait pas combien, justement parce que le papier ne le mesure pas).
Cette lecture alternative n'est jamais proposée. Elle change pourtant radicalement la conclusion opérationnelle. 30% d'erreur, c'est beaucoup si on compare à zéro. C'est peut-être remarquable si on compare à ce qu'un humain produirait dans le même temps, avec la même couverture. Le papier ne permet pas de trancher parce qu'il ne pose pas la question. Mais un praticien, lui, la pose tous les jours : est-ce que cet outil m'aide, oui ou non, par rapport à ce que je ferais sans lui ? Un papier qui ne présente qu'une seule lecture de ses données aide peut-être moins qu'il ne pourrait.
Ils mesurent le comportement par défaut, pas le meilleur comportement
Les questions de suivi sont générées automatiquement par un LLM "utilisateur" (section 4.2, p. 4). L'instruction de citation est uniforme et directe : exiger des citations inline pour chaque affirmation factuelle. Pas de stratégie de prompting alternative.
C'est un choix qui a des conséquences. On pourrait demander au modèle de vérifier la cohérence entre sa citation et son affirmation avant de produire sa réponse. On pourrait lui demander une auto-évaluation de confiance. On pourrait l'instruire explicitement de s'abstenir en cas de doute sur une source. Ces approches modifieraient potentiellement les résultats de façon significative. Le benchmark mesure le comportement par défaut des modèles, pas leur meilleur comportement atteignable. Dire "les modèles hallucinent à 30%" sans explorer l'espace des stratégies de prompting, c'est mesurer les performances d'un instrument sans chercher à l'utiliser correctement.
Le contraste est d'ailleurs frappant avec les prompts d'évaluation. L'Appendice C (p. 16-21) montre des prompts de jugement extrêmement détaillés, avec des règles de vérification strictes, des procédures pas à pas, des critères explicites. Les auteurs ont manifestement jugé que le soin apporté au prompting du juge affectait la qualité des résultats. La question se pose alors naturellement : pourquoi ne pas avoir appliqué le même soin au prompting de génération ? Si un prompt bien conçu améliore la fiabilité du juge, il est raisonnable de penser qu'un prompt bien conçu améliorerait aussi la fiabilité du modèle évalué. En l'état, le benchmark mesure ce que les modèles font quand on ne les aide pas à bien faire. C'est une information utile, mais ce n'est pas la seule qui compte.
La chaîne d'erreurs est une boîte noire
Quand un modèle avec recherche web produit une affirmation incorrectement sourcée, l'article enregistre une "hallucination". Mais cette étiquette unique recouvre au moins quatre points de défaillance distincts. Le modèle a-t-il récupéré le bon document ? A-t-il correctement lu ce document ? A-t-il correctement extrait l'information pertinente ? Des sources connexes mais non pertinentes ont-elles contaminé sa compréhension du sujet ?
Ces questions ne sont jamais posées séparément. Or la mauvaise interprétation d'une source correcte n'est pas le même phénomène que l'invention pure d'un fait. Un modèle qui reformule infidèlement un passage qu'il a correctement identifié commet une erreur de compression sémantique, pas une hallucination au sens strict. Un modèle dont le contexte est pollué par des documents tangentiels commet une erreur de filtrage, pas une erreur de raisonnement. Regrouper ces phénomènes sous une même métrique empêche d'identifier les leviers d'amélioration spécifiques à chacun.
Quand le corpus est faux, qui se trompe ?
Il y a un angle que l'article n'aborde pas du tout, et qui met en question la fiabilité même de la mesure : que se passe-t-il quand le web, sur lequel reposent à la fois le modèle et le juge, contient lui-même des erreurs factuelles ?
Ce n'est pas un cas d'école. Prenons un exemple concret. En 2023, Pantone a modifié ses formulations d'encres de base. C'est un changement technique significatif, mais très peu documenté sur le web. L'immense majorité des sources disponibles (tutoriels, forums, articles de blog, documentation technique) continue de référencer les anciennes recettes à 14 ou 18 encres de base. Un modèle qui synthétise le web va restituer l'ancienne version, parce que c'est ce que le web dit.
Ça crée trois scénarios que le benchmark ne distingue pas.
Premier scénario : le modèle restitue l'erreur du corpus et le juge la valide. Le modèle dit "les encres Pantone de base sont au nombre de 14". Le juge cherche sur le web, trouve massivement cette information, et valide le claim. Résultat compté : correct. Résultat réel : faux. Le benchmark sous-estime le taux d'erreur.
Deuxième scénario : le modèle a la bonne information (via une source récente à laquelle il a eu accès) et le juge la rejette. Le modèle dit "Pantone a revu ses formulations de base en 2023". Le juge cherche, trouve peu de sources qui confirment et beaucoup qui disent le contraire, et conclut que le claim n'est pas soutenu. Résultat compté : hallucination. Résultat réel : vrai. Le benchmark surestime le taux d'erreur.
Troisième scénario, le plus fréquent en pratique : l'ambiguïté totale. Le modèle produit un claim sur un sujet où le corpus est partagé entre l'ancienne et la nouvelle version. Le juge tombe sur l'une ou l'autre selon les résultats de recherche du moment. Le verdict dépend de l'état du web au moment de l'évaluation, pas de la vérité factuelle.
Le problème de fond, c'est la circularité. Le juge vérifie le modèle en utilisant les mêmes sources que le modèle. Si le corpus est biaisé dans une direction, le juge hérite du même biais. Les auteurs définissent d'ailleurs l'hallucination "purely in terms of groundedness" (p. 3) : est-ce que le claim est soutenu par les sources, pas est-ce que le claim est vrai. C'est un choix de design explicite, et il est défendable pour des raisons pratiques (la vérité factuelle absolue est souvent indécidable). Mais ça veut dire que le benchmark ne mesure pas la vérité ; il mesure la conformité avec le web. Ce n'est pas la même chose, et le papier ne discute jamais cette limite.
Et c'est là que la baseline humaine manque le plus. Parce que les humains font exactement les mêmes erreurs. Un juriste qui n'a pas vu passer un changement de formulation sur un formulaire fiscal, un graphiste qui travaille avec d'anciennes spécifications Pantone, un chercheur qui cite un résultat qui a été réfuté depuis : ce sont des erreurs de mise à jour, pas des hallucinations. Les humains les commettent parce que leur connaissance n'est pas à jour. Les modèles les commettent parce que le web n'est pas à jour. Le mécanisme est analogue, et le taux d'erreur pourrait être comparable. On ne le sait pas, parce que personne n'a mesuré les humains sur ces mêmes questions.
Le 70% de réussite que j'évoquais plus haut prend d'ailleurs une teinte différente à la lumière de ce constat. Si une partie des 30% d'erreur est imputable non pas au modèle mais au corpus sur lequel il s'appuie (et sur lequel le juge s'appuie aussi), alors la performance réelle du modèle est peut-être meilleure que ce que le benchmark indique. Ou, inversement, si le juge valide des claims faux parce que le web les confirme, la performance réelle est peut-être pire. On ne peut pas trancher dans un sens ou dans l'autre. Ce qui est certain, c'est que la métrique actuelle ne capture pas cette incertitude.
Et une dernière question que ça soulève : les 950 questions du benchmark sont-elles conçues pour inclure ce type de cas limite ? Les questions sont générées automatiquement (par un LLM pour les follow-ups, p. 4) et les seed questions couvrent des sujets "de niche" dans quatre domaines. Mais rien dans la méthodologie ne cible spécifiquement les cas où le consensus web est incorrect ou obsolète. C'est pourtant précisément dans ces cas que la mesure d'hallucination est la plus fragile, et que la distinction entre erreur du modèle et erreur du corpus serait la plus utile.
La pollution du contexte en multi-tours
L'article documente l'augmentation des hallucinations au fil des tours (Figure 6, p. 7) et l'attribue au self-conditioning : le modèle se conditionne sur ses propres erreurs antérieures. La Table 9 (p. 15) montre que 3 à 20% des références incorrectes du premier tour réapparaissent dans les tours suivants.
Mais cette explication ne couvre qu'une partie du phénomène. À chaque tour, le contexte s'enrichit aussi de résumés potentiellement imprécis, de sources nouvellement récupérées qui peuvent être tangentielles, et d'un volume croissant d'informations parmi lesquelles le modèle doit trier. Ce n'est pas seulement que le modèle propage ses erreurs ; c'est aussi que le contexte devient plus bruyant et plus difficile à exploiter. L'inversion de tendance en coding renforce cette hypothèse : quand le contexte se focalise plutôt que de s'élargir, les performances s'améliorent. Ce n'est pas le nombre de tours qui pose problème en soi ; c'est l'accumulation non filtrée d'informations.
Le double problème : système et modèle
Le cas du coding met en lumière une composante que l'architecture de recherche ne peut pas résoudre seule. En coding, les hallucinations ne relèvent pas d'erreurs de citation de sources ; elles relèvent d'invention pure. Les modèles fabriquent des packages, des fonctions, des arguments qui n'existent pas. Même avec recherche web activée, les taux restent significatifs : entre 15% et 75% selon les modèles et configurations (Table 3, p. 6).
C'est de l'hallucination paramétrique pure. Le modèle génère du plausible à partir de patterns appris, sans aucune source externe à blâmer. La recherche web aide (GPT-5.2-thinking passe de 32% à 16% avec WS), mais elle ne résout pas le problème fondamental. Le problème est donc double : une composante système (la qualité du grounding, la sélection des sources, le filtrage du contexte) et une composante modèle (la tendance intrinsèque à produire du vraisemblable plutôt qu'à s'abstenir). L'article mesure les deux ensemble sans les séparer, ce qui complique l'identification des solutions.
La compression sémantique : un troisième type d'erreur ?
Les erreurs résiduelles de content grounding (29.5% pour Opus avec recherche web) ne sont probablement pas toutes attribuables à de l'hallucination pure ou à du bruit de recherche. Je pense qu'une partie relève d'un phénomène distinct que le papier ne formalise pas : la compression sémantique infidèle.
Le scénario est le suivant. Le modèle accède à la bonne source. Il la lit correctement. Il en extrait l'information pertinente. Mais quand il la reformule pour l'intégrer à sa réponse, quelque chose se perd. Le sens global est préservé, mais des détails sont altérés, des nuances sont effacées, des spécificités sont généralisées. C'est le genre d'erreur qu'on fait nous aussi quand on résume un texte technique de mémoire : on attrape l'idée principale, on perd une condition, une exception, un qualificatif.
Ce type d'erreur est conceptuellement différent des deux que le papier identifie. Ce n'est pas une hallucination : le modèle n'invente rien. Ce n'est pas une erreur de recherche : la source est la bonne. C'est une limitation dans la capacité de paraphrase fidèle, et elle se situe en aval de la chaîne, au moment de la synthèse.
L'Appendice D du papier (p. 22) en fournit d'ailleurs des indices sans le formuler ainsi. Les cas de désaccord entre le juge automatique et les annotateurs humains portent souvent sur le degré de fidélité acceptable dans une reformulation. Le juge automatique, lui-même un LLM, a tendance à accepter des paraphrases que les annotateurs humains jugent trop libres. C'est logique : le juge a le même biais de compression que le modèle qu'il évalue.
Pourquoi je pense que c'est important ? Parce que les solutions ne sont pas les mêmes selon le type d'erreur. L'hallucination paramétrique demande un meilleur calibrage du modèle (savoir s'abstenir). L'erreur de recherche demande un meilleur grounding (trouver les bonnes sources). La compression sémantique demande autre chose : une capacité de synthèse plus fidèle, ou un mécanisme de vérification qui compare la reformulation à la source originale. Tant qu'on regroupe ces trois phénomènes sous la même étiquette "hallucination", on ne peut pas cibler les efforts d'amélioration.
Isoler et mesurer ce type d'erreur spécifique serait une contribution utile. Le papier a les données pour le faire (les claims sont associées à des sources, et les sources sont vérifiées en texte intégral) ; il ne pose simplement pas la question.
Vers où ça pointe
Des architectures multi-agents pour la recherche
Les données du papier suggèrent qu'une part significative des erreurs résiduelles provient de la qualité de la recherche et du filtrage des sources, pas de la capacité du modèle à raisonner sur une source propre.
Le grounding actuel fonctionne de manière "monotone" : le modèle lance une recherche, reçoit les résultats dans son contexte, et produit sa réponse en une passe. Ce schéma a deux faiblesses. Les résultats de recherche ne sont pas filtrés avant injection dans le contexte. Et le modèle doit simultanément trier les sources, les lire, les comprendre et synthétiser sa réponse.
Une architecture multi-agent permettrait de séparer ces responsabilités. Un premier agent effectue la recherche et évalue la pertinence de chaque source. Un second vérifie que les sources retenues répondent effectivement à la question posée (et déclare explicitement quand il n'a pas pu accéder à un document, plutôt que de combler les trous avec du probable). Un troisième produit la synthèse à partir d'un contexte nettoyé. Ce type d'architecture réduirait la pollution contextuelle, en particulier dans les interactions multi-tours où le problème s'accumule.
L'asymétrie Claude/GPT documentée dans le papier (p. 8) soutient cette direction. Le fait que la stratégie de sélection de sources influence directement les résultats montre que l'étape de recherche est un levier d'amélioration à part entière, pas juste un préalable transparent. Et visiblement avec la nouvelle version de Sonnet 4.6, Anthropic tend encore à faire des améliorations dans ce domaine.
Déclarer quand on n'a pas lu
C'est peut-être la recommandation la plus immédiatement actionnable, et elle découle directement des données du papier. Aujourd'hui, quand un modèle ne parvient pas à accéder à un document (PDF inaccessible, page derrière un paywall, lien mort), il ne le dit pas. Il tente de répondre quand même en comblant les trous avec des informations probables. Le résultat, c'est exactement le profil d'erreur que HalluHard mesure : une source citée, un contenu attribué, mais rien qui ne corresponde à ce que la source dit réellement.
J'en fais l'expérience régulièrement dans ma propre pratique. Sur un autre sujet que je traite en ce moment (des erreurs systématiques dans les déclarations de TVA), Gemini a cité des sources réglementaires qu'il n'avait manifestement pas pu lire, les a interprétées, et les a interprétées faussement. Le problème n'est pas qu'il se soit trompé ; c'est qu'il n'ait à aucun moment signalé qu'il n'avait pas eu accès au texte intégral. La confiance que j'accorde à une réponse sourcée repose sur l'hypothèse que le modèle a effectivement lu la source. Quand cette hypothèse est fausse et qu'on ne me le dit pas, la citation devient un piège.
La solution passe autant par le design du système que par le modèle lui-même. Dans une architecture multi-agent comme celle esquissée ci-dessus, un agent de recherche pourrait renvoyer explicitement : "je n'ai pas pu accéder à cette source ; voici un résumé partiel basé sur des éléments secondaires." Le modèle de synthèse pourrait alors calibrer sa réponse en conséquence, ou s'abstenir. Cette transparence sur la chaîne d'accès aux sources est un prérequis pour une utilisation fiable en contexte professionnel. Que la solution soit technique (des tools qui reportent leur statut d'accès) ou comportementale (du RLHF qui entraîne le modèle à déclarer ses limites d'accès), l'enjeu est le même : ne pas laisser la citation devenir un faux signal de fiabilité.
Le rapport coût/fiabilité
L'article ne propose aucune analyse coût-bénéfice. Opus-4.5 avec recherche web obtient le meilleur résultat (30.2%), mais c'est aussi la configuration la plus coûteuse. L'architecture multi-agent esquissée ci-dessus multiplierait encore les coûts d'inférence.
La question que ni l'article ni les benchmarks actuels ne posent est celle du rapport entre investissement en vérification et niveau de risque acceptable. Pour un avis juridique ou une directive médicale, un taux d'erreur de 30% est inacceptable, et des mécanismes de vérification coûteux se justifient. Pour une recherche exploratoire ou une synthèse préliminaire, ce même taux peut être tout à fait acceptable si l'utilisateur en est informé. Un benchmark utile devrait aussi informer ce type de décision en proposant des courbes coût-fiabilité, pas seulement des classements de taux d'erreur.
L'humain, la variable absente
L'article mesure les modèles en mode autonome. La réalité d'usage est tout autre. Dans la grande majorité des cas professionnels, un LLM travaille en collaboration avec un humain qui reformule, vérifie, corrige et itère.
Le taux d'hallucination effectif dans un workflow réel dépend autant de la compétence critique de l'humain que de la capacité du modèle. Un utilisateur qui vérifie systématiquement les sources citées détectera la plupart des erreurs de content grounding. Un utilisateur qui fait confiance aux citations sans les vérifier sera exposé à toutes. Aucun benchmark actuel ne mesure cette dimension. Une extension naturelle de HalluHard serait de tester des binômes humain-modèle sur les mêmes questions, en mesurant le taux d'erreur résiduel après relecture humaine.
La boucle de rétroaction
Il y a un aspect que le papier n'aborde pas et qui me semble pourtant être la conséquence la plus préoccupante de ce qu'il mesure.
Les LLM génèrent du contenu. Ce contenu finit sur le web : articles de blog "assistés par IA", réponses sur des forums, fiches techniques. Ce contenu est ensuite ingéré par les LLM suivants, soit dans leur entraînement, soit via leur recherche web en temps réel. Si les 30% d'erreur mesurés par HalluHard se traduisent par du contenu publié (et ils se traduisent par du contenu publié), alors le corpus web lui-même devient progressivement plus faux sur certains sujets.
Ce n'est pas du model collapse au sens classique (les poids du modèle qui se dégradent en boucle fermée). C'est quelque chose de différent : une contamination du corpus d'entraînement et de recherche par des erreurs qui ont l'air fiables parce qu'elles sont sourcées, bien écrites, et cohérentes entre elles. Les modèles deviennent plus confiants dans la fausseté, parce qu'ils trouvent de plus en plus de sources qui la confirment. C'est une boucle de rétroaction, et elle tourne dans le mauvais sens.
HalluHard mesure un instantané. Mais le problème est dynamique. Un benchmark qui reviendrait mesurer les mêmes questions à six mois d'intervalle, en documentant l'évolution du corpus web sur ces sujets, apporterait une donnée que personne n'a aujourd'hui.
Pour finir
HalluHard apporte un thermomètre qui ne sature pas, une distinction utile entre erreur de référence et erreur de contenu, et des données quantifiées sur les facteurs qui influencent les hallucinations. C'est une base solide. Ses principales limites, à mon sens : l'absence de baseline humaine, la non-exploration de stratégies de prompting alternatives, le cadrage exclusivement déficitaire, et le traitement de la chaîne d'erreurs comme une boîte noire. Un modèle qui réussit 70% de tâches expertes sourcées, en quelques secondes, sur des sujets de niche en droit, en médecine et en recherche, c'est un résultat qui mérite d'être posé à côté du 30% d'erreur. Le papier ne propose que le second chiffre. Ses lecteurs méritent les deux.
Je pense que les données, lues avec attention, pointent vers des axes d'amélioration concrets. La qualité du grounding dépend davantage de l'architecture du système de recherche que de la capacité brute du modèle. La pollution contextuelle en multi-tours est un problème de filtrage, pas seulement de propagation d'erreurs. La compression sémantique est un type d'erreur distinct qui mériterait sa propre mesure. La transparence sur l'accès réel aux sources (savoir quand le modèle n'a pas lu ce qu'il cite) est probablement le levier le plus immédiat. La circularité entre le modèle et son juge (tous deux dépendants du même corpus, avec les mêmes angles morts) pose une question de fond sur ce que "30% d'hallucination" mesure réellement. Et la collaboration humain-modèle, absente des mesures, est probablement le facteur le plus déterminant dans la fiabilité réelle d'un workflow assisté par LLM.
Au final, ces résultats plaident pour des architectures multi-agents avec séparation des responsabilités entre recherche, vérification et synthèse. Ils plaident aussi pour des benchmarks qui mesurent la performance des systèmes complets (humain + modèle + architecture) plutôt que des modèles isolés. Et ils plaident, peut-être surtout, pour qu'on commence à mesurer la boucle de rétroaction entre les erreurs des modèles et la qualité du web sur lequel les modèles suivants apprendront. C'est dans cette direction, à mon avis, que l'évaluation des hallucinations deviendra véritablement utile pour ceux qui les utilisent tous les jours.
Sources et liens
- Article : Fan, D., Delsad, S., Flammarion, N., Andriushchenko, M. (2026). HalluHard: A Hard Multi-Turn Hallucination Benchmark. arXiv:2602.01031
- Code et données : https://github.com/epfml/halluhard
- Leaderboard : https://halluhard.com
- Benchmarks cités dans l'article : SimpleQA (Wei et al., 2024) ; LongFact (Wei et al., 2024)
- Pipeline de jugement : basé sur SAFE (Search-Augmented Factuality Evaluator), étendu avec lecture de PDF en texte intégral
Contributeurs
Kira Kiranova - Relectrice et inspiratrice infatigable de mes nombreuses expéditions intellectuelles.
Note finale de l'auteur
Ce texte a été rédigé avec l'aide d'outils de synthèse IA, à travers des corrections et des allers-retours constants. La structure, les articulations et les impulsions sont les miennes ; c'est précisément cet effort qui me permet d'apprendre réellement ce que j'écris.
L'objectif de ce travail était avant tout pédagogique pour moi. BCS blog existe parce que je comprends mieux en écrivant. C'est le moteur essentiel de ces articles.
Olivier Heckendorn
Le blog BCS est également accessible via bcs-blog.fr.
Souscrivez à mon blog et recevez ma newsletter mensuelle une fois par mois, pas plus, pas moins - Résumé des articles récents et quelques infos.
Check out my last posts
Olivier Heckendorn - site olivierh.com - RSS feed Le blog est également accessible via bcs-blog.fr.