Limites, hallucinations et risques

Pourquoi ce chapitre est le plus utile

Connaître les capacités d'un outil ne suffit pas à en faire bon usage : il faut connaître ses défaillances, et savoir lesquelles sont structurelles. Certaines limites exposées ici découlent du principe même de ces systèmes. Aucune version future ne les fera disparaître complètement.

Ce chapitre sert de filtre avant tout déploiement. Il ne s'agit pas de freiner l'adoption : il s'agit d'éviter de construire une dépendance sur des propriétés que le système n'a pas — exactitude garantie, motivation causale, conscience de ses propres limites.

L'hallucination

Un modèle de langagegrand modèle de langageIAModèle entraîné à prédire le token suivant d'une séquence de texte. Toutes ses capacités apparentes — résumer, traduire, coder — découlent de cette unique tâche.Voir dans le glossaire produit parfois un énoncé faux, formulé avec la même assurance qu'un énoncé exact. C'est ce qu'on appelle une hallucinationhallucinationIAProduction par un modèle d'un énoncé faux formulé avec la même assurance qu'un fait établi. Le phénomène est structurel : le modèle optimise la vraisemblance, pas la vérité.Voir dans le glossaire.

L'origine est structurelle. Le modèle génère la suite la plus probable, or une affirmation plausible n'est pas nécessairement vraie. Interrogé sur un sujet qu'il ne « connaît » pas, il ne dispose d'aucun mécanisme interne pour distinguer la restitution d'un fait de la production d'un énoncé simplement vraisemblable.

Les formes les plus fréquentes :

• Références inventées — articles, jurisprudences ou ouvrages au titre crédible mais inexistants
• Détails fabriqués — dates, chiffres, noms de personnes
• Faux consensus — présentation d'un point débattu comme unanimement établi
• Extrapolation — comblement d'une lacune documentaire par ce qui « devrait » logiquement s'y trouver

Le degré d'assurance d'une réponse n'a aucune corrélation avec son exactitude. Un modèle formule une invention exactement comme un fait établi, parce qu'il n'existe aucune différence de traitement entre les deux. Toute donnée factuelle destinée à une décision doit être vérifiée à la source.

Le RAGRAGIATechnique consistant à rechercher les documents pertinents et à les fournir au modèle dans son contexte. Elle permet des réponses à jour et citables, ce que l'affinage ne permet pas.Voir dans le glossaire réduit fortement le phénomène en fournissant les documents pertinents et en permettant la citation. Il ne l'élimine pas : le modèle peut encore mal interpréter un extrait fourni, fusionner deux passages incompatibles, ou inventer le lien entre une citation réelle et une conclusion qui n'y figure pas.

Un scénario métier typique

Un juriste demande un résumé de jurisprudence sur un point précis. Le modèle cite trois arrêts avec numéros, dates et motifs. Deux existent ; le troisième est une chimère convaincante. Sans vérification systématique, la chimère entre dans une note interne, puis dans une argumentation. Le risque n'est pas la « bêtise » du modèle : c'est la crédibilité de la forme, qui court-circuite le réflexe de contrôle.

L'opacité

Un réseau à plusieurs milliards de paramètres ne se lit pas. On peut constater qu'un dossier a été refusé, sans pouvoir énoncer la règle appliquée.

Cette opacité entre en conflit direct avec plusieurs exigences juridiques : l'obligation de motiver une décision, le droit à l'explication en cas de traitement automatisé, la charge de la preuve en cas de contestation.

Les techniques d'explicabilité (importance des variables, exemples contrefactuels, cartes d'attentionattentionIAMécanisme par lequel un modèle pondère l'importance de chaque token du contexte lorsqu'il en traite un autre, quelle que soit la distance qui les sépare.Voir dans le glossaire) indiquent quelles variables ont pesé sur une décision. C'est une indication, pas une démonstration. Sur un dossier contesté devant un tribunal, « la variable revenu a contribué à 34 % » ne constitue pas une motivation au sens juridique. Elle peut néanmoins aider un opérateur humain à formuler une motivation réelle — à condition que cet opérateur dispose du temps, de la compétence et de l'autorité pour contredire le système.

Les techniques d'explicabilité indiquent quelles variables ont pesé sur une décision. C'est une indication, pas une démonstration. Sur un dossier contesté devant un tribunal, « la variable revenu a contribué à 34 % » ne constitue pas une motivation au sens juridique.

La fragilité

Les modèles se montrent sensibles à des perturbations qui ne troubleraient aucun humain :

• Exemples adversesexemple adverseCybersécuritéEntrée modifiée de façon imperceptible pour un humain, mais suffisante pour faire basculer la décision d'un modèle. Cette fragilité découle de l'absence de sens commun.Voir dans le glossaire — une modification imperceptible d'une image suffit à changer sa classification.
• Sensibilité à la formulation — deux énoncés équivalents d'une même question peuvent produire des réponses différentes.
• Dégradation hors domaine — la performance chute dès que les donnéesdonnéesIAEnsemble d'informations structurées ou non utilisées pour entraîner, évaluer ou alimenter un modèle. La qualité, la quantité et la représentativité des données sont les facteurs décisifs pour les performances en apprentissage automatique.Voir dans le glossaire s'écartent de celles de l'entraînement, souvent sans signal d'alerte.

Le hors domaine est le plus fréquent en production. Un classifieur de tickets formé sur deux ans d'historique voit apparaître un nouveau produit, un nouveau canal, un nouveau ton client. Les scores restent élevés ; la pertinence chute. Sans surveillance de dérivedériveIADégradation progressive des performances d'un modèle après son déploiement, causée par l'évolution des comportements ou du contexte. Elle impose surveillance et réentraînement.Voir dans le glossaire, l'équipe découvre le problème via les plaintes, pas via les métriques.

Biais et amplification

Un modèle entraîné sur l'historique des décisions humaines n'apprend pas la justice : il apprend les régularités de cet historique. Si le passé discrimine, le modèle la reproduit — souvent avec une apparence d'objectivité mathématique qui rend le biaisbiaisIARégularité correctement apprise dans des données qui ne représentent pas la réalité visée, ou qui enregistrent des décisions passées avec leurs préjugés. Changer d'algorithme ne le corrige pas.Voir dans le glossaire plus difficile à contester.

Les variables protégées n'ont pas besoin d'être présentes. Des corrélats (code postal, établissement scolaire, vocabulaire du CV) suffisent. Les métriques globales masquent ensuite les écarts : un taux d'erreur « acceptable » à l'échelle du portefeuille peut cacher un taux inacceptable sur un sous-groupe.

Corriger après coup (rééquilibrage, contraintes d'équité) aide, mais ne remplace pas l'audit amont des données et la définition explicite de ce qu'on refuse d'optimiser.

Les risques propres à l'exploitation

Fuite de donnéesfuite de donnéesIAErreur consistant à laisser entrer dans l'entraînement une information qui n'existera pas au moment réel de la prédiction. Le modèle affiche des scores excellents puis s'effondre en production.Voir dans le glossaire — soumettre un document confidentiel à un service en ligne, c'est le transmettre à un tiers. Les conditions d'utilisation déterminent si les contenus soumis peuvent servir à l'entraînement. Les politiques « opt-out » changent ; le secret professionnel, lui, ne s'adapte pas rétroactivement.

Injection de requêteinjection de requêteCybersécuritéAttaque consistant à dissimuler des instructions dans un contenu que le modèle va lire, afin de détourner son comportement. Le risque devient critique dès qu'un agent peut agir.Voir dans le glossaire (prompt injectionInjection de promptCybersécuritéAttaque visant à détourner un LLM en insérant des instructions malveillantes dans le contexte (entrée utilisateur, document RAG, etc.).Voir dans le glossaire) — un texte malveillant dissimulé dans un document traité par le modèle peut détourner son comportement. Le risque est majeur dès qu'un système lit des contenus non maîtrisés — courriels, pages web, pièces jointes.

Empoisonnement des donnéesempoisonnementCybersécuritéIntroduction délibérée d'exemples corrompus dans un jeu d'entraînement, afin d'altérer durablement le comportement du modèle.Voir dans le glossaire — introduire des exemples corrompus dans un jeu d'entraînement pour altérer durablement le modèle. Sur un pipeline qui réentraîne périodiquement à partir de retours utilisateurs, l'attaque peut être lente et difficile à attribuer.

Dépendance — externaliser une compétence critique vers un fournisseur unique, sans réversibilité prévue. Changement de tarif, de politique de rétention, ou d'API : le métier se retrouve sans plan B.

IAintelligence artificielleIAEnsemble des techniques permettant à un programme d'accomplir une tâche qui demanderait de l'intelligence humaine. Le terme couvre aussi bien les systèmes à règles écrites que ceux qui apprennent de données.Voir dans le glossaire de l'ombre (shadow AI) — les équipes utilisent des outilstool callingIACapacité d'un agent ou d'un LLM à invoquer des outils externes (API, calcul, recherche) pendant le raisonnement.Voir dans le glossaire grand public hors du périmètre IT. Le risque n'est plus théorique : des extraits de code, des clauses, des données clients sortent de l'organisation sans journalisation. Interdire sans alternative pousse le phénomène sous le tapis ; encadrer avec des outils validés le ramène sous contrôle.

Traitez toute sortie de modèle comme une entrée non fiable. Si elle alimente une requête de base de données, une commande système ou un affichage web, appliquez les mêmes contrôles que pour une saisie utilisateur : validation, échappement, principe du moindre privilège. Un modèle peut être manipulé par le contenu qu'il lit.

Les coûts qu'on oublie de chiffrer

À ces postes s'ajoute le coût de l'échec silencieux : un modèle qui se dégrade pendant six mois sans alerte produit des décisions médiocres à grande échelle. Le tableau de bord qui n'affiche que le taux de disponibilité de l'API ne mesure pas la pertinence métier.

Le cadre de décision

Avant d'engager un projet, quatre questions suffisent à écarter la plupart des impasses :

1. Que coûte une erreur ? Si elle est grave et irréversible, une validation humaine s'impose.
2. La décision doit-elle être motivée ? Si oui, privilégier un modèle interprétable ou une règle explicite.
3. Disposons-nous des données ? En volume, en qualité, et avec une base légale de traitement.
4. Comment mesurera-t-on l'échec ? Sans critère défini à l'avance, aucun projet ne peut être arrêté à temps.

L'IA convient aux tâches où une erreur occasionnelle est tolérable et détectable. Elle convient mal aux décisions irréversibles sans supervision. Ce n'est pas une limite de maturité technologique : c'est une propriété des systèmes statistiques.

Reconnaître une hallucination avant qu'elle ne cause un dommage

Aucune méthode ne garantit la détection, mais cinq signaux méritent une vérification systématique :

Une référence précise et vérifiable. Un numéro d'article, une date, un nom propre, un montant. Plus la donnée est précise, plus elle est utile — et plus une invention passe inaperçue.

Une réponse à une question sans réponse connue. Interrogé sur un fait qui n'existe pas, un modèle produit rarement « je ne sais pas » : il comble.

Une régularité trop nette. Des chiffres alignés, une progression parfaite, une répartition symétrique : le monde réel est rarement aussi ordonné.

Une information postérieure à l'entraînement. Le modèle ignore ce qui s'est passé après sa date de coupure, mais rien ne l'empêche de produire un énoncé plausible sur cette période.

Un consensus affirmé sur un sujet débattu. La présentation d'une controverse comme une évidence signale souvent une simplification produite par le modèle.

Demandez la source en même temps que la réponse, pas après coup. Une demande de vérification postérieure conduit fréquemment le modèle à produire une justification de sa réponse initiale plutôt qu'un réexamen. Sans mécanisme de récupération documentaire, la source citée reste elle-même sujette à invention.

Choisir le degré d'automatisation

Entre l'humain seul et la machine seule s'échelonnent quatre régimes, à choisir selon le coût de l'erreur :

Le régime par exception est le meilleur compromis dans la plupart des situations professionnelles, à une condition : que le système sache reconnaître ses propres cas incertains et les remonter. Un système qui traite tout avec la même assurance ne permet aucun de ces régimes, sinon la validation intégrale — laquelle annule une partie du gain.

Mesurer l'incertitude n'est pas trivial. Un score de confiance du modèle n'est pas une probabilité calibrée. En pratique, on combine des signaux : divergence entre modèles, absence de sources RAG pertinentes, règles métier qui refusent certains profils, revue par échantillonnage. L'objectif n'est pas la perfection : c'est d'éviter que les cas les plus risqués passent en silence.

Mesurer pour pouvoir arrêter

Un projet sans métrique d'échec est un projet qu'on ne peut pas tuer. Définissez avant le lancement : le taux d'erreur maximal acceptable, le délai de détection souhaité, et le seuil qui déclenche la suspension ou le retour au processus manuel. Sans ces trois éléments, la discussion post-incident tourne en débat d'impressions.

Surveillez aussi la dérive des données d'entrée (distribution des variables) et la dérive de performance (qualité des sorties sur un échantillon labellisé régulièrement). L'une peut précéder l'autre : les données changent avant que les utilisateurs ne se plaignent.

Ce que ces systèmes ne feront pas mieux avec le temps

Certaines limites tiennent au principe même de l'approche statistique et ne relèvent pas de la maturité technologique :

• La garantie d'exactitude. Un système probabiliste produit une réponse probable, jamais certaine.
• La justification causale. Il peut expliquer ce qui a pesé, non pourquoi cela devait peser.
• La connaissance de ses propres limites. Il ne sait pas ce qu'il ignore, faute de représentation de son propre savoir.
• La responsabilité. Elle reste juridiquement humaine, quel que soit le degré d'automatisation.

Ces quatre points doivent figurer dans toute analyse de risque. Les ignorer conduit à concevoir des dispositifs dont la sécurité repose sur des propriétés que le système n'a pas.

Le chapitre suivant situe ces exigences dans le cadre européen : RGPDRGPDConformitéRèglement européen sur la protection des données personnelles. Il s'applique dès qu'un système d'IA traite de telles données, et se cumule avec l'AI Act.Voir dans le glossaire et AI ActAI ActConformitéRèglement européen sur l'intelligence artificielle, adopté en 2024. Il classe les systèmes en quatre niveaux de risque selon leur usage — jamais selon leur technologie.Voir dans le glossaire ne « corrigent » pas l'hallucination, mais ils définissent qui doit prouver quoi lorsque le système échoue.

Taxonomie courte des défaillances

Erreurs factuelles fluides, biais reproduits, fragilité hors distribution, fuites de données via prompts, sur-confiance utilisateur, automatisation de décisions injustes : les risques ne se réduisent pas aux « hallucinations ». Classez-les par impact et détectabilité pour prioriser les contrôles.

Une erreur rare mais indétectable peut coûter plus cher qu’une erreur fréquente évidente. C’est le critère que les slides du chapitre soulignent : coût × non-détection.

Gouvernance minimale

Politique d’usage, inventaire des systèmes, évaluation avant déploiement, supervision humaine sur les cas critiques, journalisation, revue périodique. Ces éléments sont banals en apparence ; leur absence explique la plupart des incidents publics.

La gouvernance n’empêche pas l’innovation : elle empêche de confondre vitesse et imprudence.

Communication des limites

Affichez clairement ce que le système ne fait pas. Interdisez les formulations anthropomorphiques dans l’UI (« je pense que »). Proposez une voie d’escalade humaine. Ces détails UX réduisent la sur-confiance mieux qu’un paragraphe légal enfoui.

Scénarios d’exercice

Organisez des tabletop : hallucination juridique, biais de recrutement, fuite PII dans un promptpromptIAConsigne ou contexte fourni à un modèle de langage pour orienter sa réponse. La qualité du prompt conditionne souvent la qualité du résultat.Voir dans le glossaire cloud, agentagentIASystème qui enchaîne des appels d'outils de façon autonome pour atteindre un objectif : il planifie, agit, observe, recommence. Sa fiabilité décroît exponentiellement avec le nombre d'étapes.Voir dans le glossaire qui exécute une action destructive. Chronométrez la détection et la réponse. Mettez à jour procédures et droits ensuite.

Pour chaque système IA, écrivez une fiche d’une page : usage, données, limites, contact d’escalade.