Blog · IA & méthode
Halluciner n’est pas une option : les limites d’un assistant généraliste en enquête
Un LLM seul peut se montrer convaincant sans être fiable. Pourquoi un outil d’enquête a besoin d’un encadrement structurel, pas seulement d’un bon prompt.
Par Willem Riehl, cofondateur de DUPAIN. Mis à jour le 30 juillet 2026. Temps de lecture : environ 7 minutes.
Demander à un assistant généraliste de résumer un dossier de harcèlement produit, presque toujours, un texte bien écrit, structuré, d’apparence rigoureuse. C’est précisément ce qui rend le risque difficile à voir : la qualité de la forme n’a aucun rapport avec la fiabilité du fond. Un enquêteur qui a appris à se méfier d’un témoignage trop lisse devrait appliquer la même méfiance à une synthèse générée, pour une raison différente, mais tout aussi sérieuse.
1. Ce qu’est une hallucination, en langage d’enquêteur
Un modèle de langage ne récupère pas des faits dans une base de données : il prédit, mot après mot, la suite la plus probable d’un texte, à partir de régularités apprises sur d’immenses corpus. Lorsque l’information demandée est présente dans le contexte fourni, cette prédiction colle généralement au texte source. Lorsqu’elle ne l’est pas (un détail manquant, une date ambiguë, un lien entre deux pièces que le modèle n’a pas explicitement sous les yeux), le modèle produit néanmoins une suite plausible. Cette suite peut être entièrement inventée sans que rien, dans sa formulation, ne le signale. Ce n’est pas un bug ponctuel à corriger : c’est une conséquence structurelle de la manière dont ces systèmes génèrent du texte.
2. Pourquoi c’est spécifiquement dangereux dans un dossier d’enquête
Dans la plupart des usages, une hallucination produit une phrase maladroite ou un détail erroné sans grande conséquence. Dans un dossier d’enquête pour harcèlement, les mêmes mécanismes peuvent produire une citation attribuée à la mauvaise personne, un lien affirmé entre deux pièces qui n’ont en réalité aucun rapport, une date de chronologie « complétée » par extrapolation plutôt que tirée d’une pièce réelle, ou une corroboration entre deux témoignages qui n’existe pas dans les textes originaux. Le RGPD qualifie précisément ce risque : les données à caractère personnel traitées doivent être exactes, et le responsable de traitement doit prendre toute mesure raisonnable pour rectifier ou effacer sans délai les données inexactes1. Une hallucination qui s’installe dans un dossier n’est donc pas seulement une erreur de méthode : c’est, techniquement, une donnée personnelle inexacte produite par le traitement lui-même.
3. Ce qu’un bon prompt ne peut pas garantir
« Ne réponds qu’à partir des documents fournis », « cite tes sources », « ne suppose rien » : ces instructions améliorent le comportement moyen d’un modèle, elles ne le contraignent pas. Un modèle de langage généraliste n’a aucun mécanisme structurel qui l’empêche de produire une affirmation non fondée si la formulation la rend plausible : il n’a, par construction, aucune notion de ce qu’il « sait » réellement par opposition à ce qu’il « complète » de manière convaincante. Un encadrement qui repose entièrement sur la qualité de la consigne donnée au modèle repose, en réalité, sur la constance de son comportement face à des dossiers toujours différents. Ce n’est pas une garantie ; c’est un pari.
4. Ce qui marche : contraindre la structure, pas seulement la formulation
L’approche qui réduit réellement ce risque ne consiste pas à mieux demander au modèle d’être prudent, mais à concevoir le système de sorte qu’aucune affirmation ne puisse être présentée sans se résoudre à une pièce précise et vérifiable : page, passage, ou extrait d’entretien. Si le système ne peut pas rattacher un fait à sa source, il ne doit pas pouvoir le présenter comme un fait. Cette exigence rejoint, depuis l’angle réglementaire, celle que pose le règlement européen sur l’intelligence artificielle pour les systèmes à haut risque : un niveau approprié d’exactitude et de robustesse tout au long du cycle de vie du système2, et une conception permettant une supervision humaine réellement effective3. Ce ne sont pas deux exigences distinctes, juridique d’un côté, technique de l’autre, mais la même exigence formulée deux fois.
5. La supervision humaine arrive trop tard si elle n’a rien à vérifier
« Un humain reste dans la boucle » est souvent présenté comme la réponse au risque d’hallucination. C’est une réponse incomplète. Un enquêteur qui relit une synthèse fluide et bien construite, sans disposer d’un moyen immédiat de vérifier chaque affirmation contre la pièce dont elle est censée provenir, est structurellement exposé au biais d’ancrage : la première version lue tend à orienter la lecture des pièces qui suivent, même lorsqu’on sait, en théorie, qu’elle peut être fausse. La supervision humaine ne protège du risque que si la vérification est rendue triviale, un clic vers la source exacte, et non si elle suppose de reconstituer, a posteriori, un travail de recoupement que l’outil aurait dû faciliter plutôt que masquer.
6. Comment tester un outil avant de lui faire confiance
Quatre vérifications simples, à faire soi-même avant d’adopter un outil d’enquête assisté par IA :
- Demander une démonstration avec de vraies pièces contradictoires. Pas un exemple préparé par l’éditeur : un dossier réel, anonymisé, où deux témoignages se contredisent effectivement.
- Vérifier que chaque fait généré pointe vers une pièce précise. Pas vers « le dossier » en général, mais vers une page, un passage ou un extrait d’entretien identifiable.
- Tester volontairement un dossier incomplet. Un bon système signale l’absence d’information ; un système mal conçu « complète » le vide par une inférence non signalée comme telle.
- Vérifier qu’aucune fonctionnalité ne propose de conclusion prête à l’emploi. Une qualification des faits ou une recommandation de sanction générée automatiquement est un signal d’alerte, pas une fonctionnalité avancée.
7. Comment DUPAIN répond à ces exigences
C’est exactement ce test que DUPAIN a été construit pour passer. Chaque fait proposé se rattache à la pièce précise dont il provient, consultable en un clic, jamais à une affirmation flottante que l’enquêteur devrait vérifier par ses propres moyens. Lorsqu’une information manque au dossier, l’outil la signale comme manquante ; il ne la remplace jamais par une inférence présentée comme un fait établi. Et aucune fonctionnalité ne produit de qualification, de score de risque ou de conclusion : ce que l’outil génère reste, par construction, une proposition à vérifier, jamais un résultat à croire sur parole.
C’est cette discipline structurelle, pas une promesse de prudence mais une contrainte de conception, qui permet à un enquêteur de gagner du temps sur le travail mécanique sans jamais avoir à se demander si ce que l’outil lui montre est réellement dans le dossier.
Notes
- Règlement (UE) 2016/679 (RGPD), art. 5, § 1, point d), exactitude des données à caractère personnel, sur EUR-Lex. ↩
- Règlement (UE) 2024/1689 (règlement sur l’intelligence artificielle), art. 15, exactitude, robustesse et cybersécurité des systèmes à haut risque, sur EUR-Lex. ↩
- Règlement (UE) 2024/1689, art. 14, supervision humaine des systèmes à haut risque, sur EUR-Lex ; voir aussi ISO/IEC 42001:2023, Technologies de l’information, intelligence artificielle, système de management, Organisation internationale de normalisation. ↩