2.1 Hallucinations et biais des LLM : causes, cas réels, garde-fous

Comprendre les limites des modèles d'IA générative suppose de comprendre, au moins schématiquement, comment ils fonctionnent. Sans entrer dans les détails techniques, voici les éléments essentiels.

Un grand modèle de langage (Large Language Model, LLM) est un réseau de neurones comptant de plusieurs milliards à plusieurs centaines de milliards de paramètres, entraîné en deux phases :

1. Pré-entraînement sur un corpus massif de textes (web, livres, code). Le modèle apprend à prédire le fragment de texte (token) le plus probable à partir du contexte précédent. Aucune notion de vérité ni de mémoire des faits : des régularités statistiques.
2. Alignement (RLHF / RLAIF) : ajustement par feedback humain pour que le modèle soit utile, inoffensif, honnête. Cette phase corrige les comportements indésirables mais n'élimine pas les limites fondamentales du pré-entraînement.

Ce que le LLM fait bien :

• Manipuler le langage avec fluidité (résumé, reformulation, traduction)
• Synthétiser des connaissances générales largement représentées dans le corpus
• Suivre des instructions complexes et raisonner sur courtes chaînes
• Générer du code, du texte créatif, des structures

Ce que le LLM fait mal :

• Calcul mathématique précis (sauf délégation à un outil externe)
• Récupération de faits précis non largement représentés (citations, statistiques rares)
• Raisonnement long avec nombreuses étapes
• Conscience de ses propres limites (le modèle ne sait pas qu'il ne sait pas)
• Mise à jour temporelle (le corpus a une date de coupure)

Cette asymétrie — fluidité de surface mais limites profondes — est la racine des risques opérationnels que nous allons détailler. Le LLM paraît compétent partout, ce qui pousse l'humain à lui faire confiance même là où il ne le devrait pas.

Une hallucination est une affirmation produite par un LLM qui n'est pas vraie mais qui est présentée avec la même confiance que les affirmations correctes. C'est l'un des risques les plus connus, et pourtant le plus sous-estimé en pratique.

Types d'hallucinations fréquentes :

• Citations inventées : références bibliographiques, articles, jurisprudences, statistiques qui n'existent pas. Le modèle « complète » la forme attendue d'une citation sans en vérifier l'existence.
• Faits historiques erronés : dates fausses, attributions incorrectes, événements imaginaires
• Chiffres approximatifs : statistiques avec valeurs plausibles mais fausses
• Personnes inventées : noms, biographies, titres qui sonnent vrais mais qui ne correspondent à personne
• Code qui semble fonctionner mais qui appelle une fonction inexistante d'une bibliothèque (parfois appelé « package hallucination »)
• Procédures juridiques fausses : étapes administratives inventées, délais erronés

Pourquoi ces hallucinations ? Le LLM ne « consulte » pas une base de connaissances : il génère token par token la suite la plus probable. Quand une question demande un fait précis qu'il ne « connaît » pas, il génère quelque chose qui ressemble à la réponse attendue plutôt que d'avouer son ignorance. C'est un comportement encouragé par son alignement (être utile et serviable).

Les évolutions techniques récentes ont réduit les hallucinations mais ne les ont pas éliminées :

• RAG (Retrieval-Augmented Generation) : le LLM cherche dans une base documentaire avant de répondre, ce qui réduit nettement les hallucinations pour les sujets couverts par la base. Mais ne marche que dans le périmètre de la base.
• Recherche web intégrée : le modèle consulte des sources actualisées avant de répondre. Cela réduit les hallucinations sur les faits récents mais introduit un autre risque : des sources web elles-mêmes non fiables, reprises sans discernement.
• Modèles dits « de raisonnement », qui explicitent des étapes intermédiaires avant de répondre : meilleurs sur les problèmes longs, mais capables d'inventer une étape intermédiaire avec la même assurance.

La règle d'or : tout fait précis produit par un LLM doit être vérifié indépendamment avant utilisation à enjeu. Citations, dates, statistiques, références juridiques, données techniques. Le LLM est utile pour structurer, reformuler, suggérer — pas pour certifier des faits.

Un biais est une distorsion systématique dans les réponses du modèle, qui défavorise ou favorise un groupe, une opinion, une caractéristique. Les biais sont inévitables car ils existent dans les corpus d'entraînement, qui reflètent les biais sociaux historiques.

Types de biais couramment observés :

Biais de genre. Stéréotypes associant certaines professions à un genre (« infirmière » = femme, « ingénieur » = homme), traits de caractère, comportements. Un grand groupe de commerce en ligne a abandonné en 2018 un outil expérimental de présélection de candidatures qui pénalisait les CV de femmes : entraîné sur dix ans de recrutements majoritairement masculins, il avait appris à déprécier les indices associés aux candidates (affaire rapportée par l'agence Reuters en octobre 2018).

Biais ethniques et culturels. Représentations biaisées de groupes ethniques. Études récurrentes montrant que les générateurs d'images représentent par défaut « médecin » comme un homme blanc, « femme de ménage » comme une femme racialisée. Les systèmes de reconnaissance faciale ont historiquement des taux d'erreur supérieurs sur les visages noirs.

Biais socio-économiques. Représentations stéréotypées des classes sociales, lieux d'habitation, niveaux d'éducation. Risque particulier en scoring (crédit, assurance).

Biais culturels. Les modèles entraînés sur des corpus majoritairement anglophones véhiculent des références et des normes culturellement situées : un texte généré pour un public français peut importer des conventions juridiques, sociales ou rédactionnelles nord-américaines sans que l'utilisateur s'en aperçoive.

Biais d'âge. Stéréotypes sur les seniors, les jeunes, les comportements liés à l'âge.

Conséquences juridiques potentielles :

• Discrimination directe (article L1132-1 du Code du travail) si le système pénalise l'un des critères protégés (sexe, origine, âge, état de santé, activité syndicale…). Sur le plan pénal, la discrimination à l'embauche est punie de trois ans d'emprisonnement et de 45 000 € d'amende (articles 225-1 et 225-2 du Code pénal).
• Discrimination indirecte si le système, en apparence neutre, désavantage systématiquement un groupe protégé sans justification objective
• Manquement à l'article 22 du RGPD et, à compter du 2 décembre 2027, aux obligations des systèmes à haut risque pour les outils RH

L'AI Act impose aux fournisseurs de systèmes à haut risque des obligations de gouvernance des données d'entraînement (article 10) : examen des biais possibles, représentativité, mesures de détection et de correction. Le règlement omnibus 2026/1744 a élargi la possibilité de traiter des données sensibles à seule fin de détecter et corriger ces biais. Ces obligations s'appliquent à compter du 2 décembre 2027.

Pour les déployeurs : tester systématiquement les sorties des outils IA contre des biais, particulièrement dans les domaines à risque (recrutement, RH, scoring, marketing ciblé). Une analyse d'impact doit explicitement mesurer les biais et prévoir des mesures correctives.

Des bibliothèques open source d'audit d'équité, publiées par plusieurs grands éditeurs et par la recherche académique, mesurent les disparités de résultats entre groupes (taux de sélection, taux d'erreur) et permettent d'objectiver un biais avant le déploiement. Elles ne remplacent pas l'analyse juridique, mais elles la documentent.

Chaque LLM a une date de coupure (« knowledge cutoff ») au-delà de laquelle il n'a aucune information directe. Les événements récents, les évolutions réglementaires, les sorties de produit, les actualités lui sont inconnus — sauf s'il dispose d'un outil de recherche web actif.

Cette date figure dans la documentation de chaque modèle et se situe en général entre six mois et deux ans avant la date d'utilisation. Elle varie d'une version à l'autre du même produit : la vérifier sur la page officielle de l'éditeur, pas de mémoire.

Conséquences pratiques :

• Un LLM interrogé en 2026 sur le « tarif horaire SMIC actuel » donnera la valeur à sa date de coupure, pas la valeur actuelle
• Sur la réglementation récente, les modèles donnent des informations partielles ou périmées : un assistant entraîné avant l'été 2026 ignore le report des obligations haut risque de l'AI Act par le règlement omnibus 2026/1744 et affirmera avec assurance la date du 2 août 2026
• Les versions de logiciels, les API, les bibliothèques évoluent — le code généré peut référencer des fonctions obsolètes ou nouvelles non encore documentées
• Les noms de personnes occupant des fonctions (président, ministre, dirigeant d'entreprise) sont valides à la date de coupure et peuvent être obsolètes

Solutions :

Recherche web intégrée. La plupart des assistants proposent un mode qui consulte des sources en ligne avant de répondre. Le risque d'obsolescence est nettement réduit pour les faits datés, mais les sources consultées peuvent elles-mêmes être erronées : lire les sources citées, pas seulement la synthèse.

RAG sur sources internes. Pour les sujets internes (procédures, base documentaire entreprise), le RAG sur sources internes à jour est la meilleure approche.

Vérification systématique. Pour tout fait à enjeu, vérifier sur la source officielle (Légifrance, EUR-Lex, service-public.fr, site de l'autorité compétente) plutôt que de se fier au modèle seul.

La combinaison recommandée : utiliser un LLM avec recherche web active + double-vérification sur source primaire pour les faits critiques. Ne jamais se fier à un LLM seul pour une donnée à enjeu juridique, financier ou contractuel.

Plutôt que de bannir l'IA générative à cause de ces risques, l'objectif est de mettre en place des garde-fous qui rendent l'usage sûr.

1. Vérifier les sources. Demander systématiquement au LLM de citer ses sources. Vérifier que ces sources existent et confirment effectivement l'affirmation. En mode recherche web, les assistants affichent les adresses des pages consultées : les ouvrir avant de valider.

2. Croiser les modèles. Pour les sujets à enjeu, poser la même question à deux ou trois assistants différents. Des réponses convergentes augmentent la confiance sans la garantir ; des réponses divergentes signalent qu'au moins l'un d'eux se trompe.

3. Décomposer les tâches. Pour un sujet complexe, plutôt qu'une question globale, décomposer en sous-questions vérifiables. « Rédige-moi une note sur X » devient « Quels sont les 5 points juridiques à couvrir sur X ? Pour chaque point, cite l'article et donne-moi l'URL ». Plus facile à vérifier.

4. Faire valider par un expert humain. Pour tout livrable critique (note juridique, communiqué presse, document financier, code en production), validation systématique par un humain expert du domaine. L'IA est un assistant, pas un certificateur.

5. Tracer les usages. Conserver l'historique des prompts et réponses pour les usages à enjeu. Permet le retour en arrière en cas d'incident, et la documentation pour audit.

6. Acculturer les utilisateurs. Les hallucinations sont contre-intuitives : un LLM peut paraître très compétent dans une réponse et complètement inventer la suivante. Sans formation, les utilisateurs survestiment systématiquement la fiabilité du LLM. C'est l'objet même de l'IA literacy de l'article 4.

Le seuil de tolérance aux erreurs doit être calibré selon l'usage : 0 erreur tolérée pour une note juridique ou un livrable client final, quelques erreurs tolérées pour un brouillon ou une recherche exploratoire. Le LLM est mieux utilisé en première intention (brouillon, idéation, exploration) qu'en certification finale.

Quelques cas qui ont marqué et qui illustrent les risques :

Moffatt c. Air Canada (Civil Resolution Tribunal de Colombie-Britannique, 14 février 2024). Le chatbot du site de la compagnie avait indiqué à un client qu'il pouvait demander un tarif « deuil » après son voyage, alors que la politique réelle l'excluait. La compagnie a soutenu que le chatbot était une « entité juridique distincte responsable de ses propres actes ». Le tribunal a rejeté l'argument et condamné la compagnie à indemniser le client : l'entreprise répond des informations données par son chatbot, comme de celles de n'importe quelle page de son site.

Un agent conversationnel expérimental sur un réseau social (2016). Lancé par un grand éditeur, il a été retiré en moins de vingt-quatre heures après avoir produit des messages racistes et négationnistes, orienté par des utilisateurs malveillants. Leçon : le comportement d'un modèle peut être détourné par le contexte qu'on lui fournit, et les protections de l'alignement se contournent (voir le chapitre 3.3 sur le jailbreaking).

Fuite de code source par des prompts (2023). Des ingénieurs d'un grand groupe électronique coréen ont collé du code source confidentiel et l'enregistrement d'une réunion interne dans un assistant grand public pour les analyser, selon la presse économique coréenne. Le groupe a interdit ces outils sur ses postes de travail et développé un assistant interne. Le chapitre 2.2 en tire les leçons.

Rejet automatique de candidatures selon l'âge (États-Unis, 2023). Le logiciel de recrutement d'une société de tutorat en ligne écartait automatiquement les candidates de plus de 55 ans et les candidats de plus de 60 ans. L'agence fédérale chargée de l'égalité dans l'emploi (EEOC) a conclu avec l'entreprise un accord transactionnel de 365 000 dollars. Il ne s'agissait pas d'un modèle génératif, mais la leçon vaut pour tout système automatisé : la règle discriminante peut être codée ou apprise, le résultat est le même.

Chatbot administratif d'une grande ville américaine (2024). Un assistant destiné à renseigner les entrepreneurs sur la réglementation locale a donné, selon une enquête de presse de mars 2024, des réponses contraires au droit (sur le salaire minimum, les pourboires, les discriminations au logement). La ville l'a maintenu en ligne en renforçant les avertissements. Leçon : un chatbot public engage l'autorité qui le déploie, et un avertissement ne corrige pas une réponse fausse.

Leçon transversale : l'entreprise reste responsable des sorties produites par ses outils IA. Le fait que ce soit l'IA qui ait commis l'erreur ne dégage en rien la responsabilité. D'où l'importance de la supervision humaine, des garde-fous, de la formation, des AIPD/FRIA.