Empoisonnement des données et du modèle : la menace silencieuse sur vos IA

Une seule donnée corrompue, glissée dans le corpus d'entraînement, dans les exemples d'affinage ou dans la base documentaire que votre IA interroge, peut fausser durablement ses réponses sans qu'aucune alerte ne se déclenche. La parade ne consiste pas à inspecter le modèle une fois pollué, mais à verrouiller la provenance de chaque donnée avant qu'elle n'entre, en appliquant la même barrière de contrôle à ses trois portes d'entrée. Dans cet article, je vous explique comment le poison s'introduit dans une IA et pourquoi il reste invisible, puis la méthode en quatre étapes pour tracer vos données et refermer chacune de ces portes.

Le problème : un poison qui se fond dans la masse des données

Un modèle d'IA n'a pas d'opinion propre. Il restitue ce que ses données lui ont appris. Il suffit donc d'altérer ces données pour altérer durablement son comportement, et c'est précisément ce que vise l'empoisonnement : introduire, dans les jeux qui nourrissent votre IA, des exemples truqués qui vont biaiser ses réponses ou y implanter une porte dérobée. C'est le risque que l'OWASP classe au quatrième rang de son panorama des menaces propres aux modèles de langage.

Le danger tient à sa discrétion. Une poignée d'exemples corrompus se noient dans des millions de données saines et ne se repèrent pas à l'œil. Le modèle continue de fonctionner normalement au quotidien, puis dévie sur un sujet précis, favorise systématiquement une réponse, ou s'active sur un mot-clé déclencheur que seul l'attaquant connaît. Aucun antivirus ne lit dans les paramètres d'un réseau de neurones, et rien dans le code de votre application ne trahit la pollution.

Les trois portes par lesquelles le poison entre

Pour se défendre, il faut d'abord savoir où regarder. Contrairement à une idée répandue, l'empoisonnement ne se limite pas à l'entraînement initial du modèle. Il vise trois moments distincts du cycle de vie de votre IA, et le troisième concerne même les entreprises qui n'entraînent aucun modèle.

Cette dernière porte est la plus sous-estimée. Vous pouvez très bien ne jamais entraîner ni affiner de modèle et rester exposé, parce que brancher une IA sur votre base documentaire revient à lui faire ingérer, en temps réel, tout ce qui y est déposé. La bonne nouvelle est qu'une seule et même barrière de contrôle couvre les trois portes.

La méthode en 4 étapes pour verrouiller vos données

Se protéger de l'empoisonnement n'est pas une affaire de détection miraculeuse a posteriori, mais une discipline d'hygiène appliquée à chaque flux de données qui nourrit votre IA. Voici les quatre étapes, dans l'ordre où vous les mettez en place.

Étape 1 : maîtriser la provenance des données

Vous ne pouvez pas faire confiance à une donnée dont vous ignorez l'origine. La première étape consiste à n'autoriser dans vos jeux d'entraînement, d'affinage et d'indexation que des sources identifiées, rattachées à un responsable et couvertes par un droit d'usage clair. Concrètement, vous tenez une liste des sources admises, vous refusez tout apport dont l'origine est inconnue, et vous distinguez les données internes maîtrisées des données externes qui exigent une vigilance renforcée. Cette exigence de provenance est exactement celle que je détaille pour les modèles eux-mêmes dans mon article sur la traçabilité de la chaîne d'approvisionnement avec un AI-BOM, et elle s'applique tout autant aux données qu'aux poids du modèle.

Étape 2 : vérifier l'intégrité de ce qui entre

Maîtriser la source ne suffit pas si la donnée peut être modifiée entre le moment où vous la validez et celui où elle entre dans le modèle. La deuxième étape fige et prouve ce qui est effectivement ingéré. Vous versionnez vos jeux de données, vous conservez une empreinte de chaque lot admis, et vous vérifiez cette empreinte avant tout entraînement, tout affinage ou toute réindexation. Ainsi, une altération glissée en cours de route se voit, parce que l'empreinte ne correspond plus. Vous obtenez au passage une trace de ce qui a nourri chaque version du modèle, ce qui vous permettra, le jour d'un incident, de savoir exactement quel lot suspecter.

Étape 3 : valider et nettoyer les données

Une source autorisée peut malgré tout véhiculer une donnée corrompue, par erreur ou par compromission en amont. La troisième étape ajoute un filtre de qualité avant l'ingestion. Vous détectez les doublons suspects, les contenus aberrants, les valeurs incohérentes et les documents dont la structure ou le comportement tranche avec le reste du lot. Pour une base RAG, cela signifie contrôler ce qui est déposé avant de l'indexer, plutôt que d'indexer d'abord et de découvrir le problème dans les réponses de l'IA. Ce nettoyage ne cherche pas la perfection, il élimine les anomalies les plus grossières, celles qui portent l'essentiel du risque.

Étape 4 : surveiller la dérive et éprouver le modèle

Aucune barrière d'entrée n'est parfaite, et un flux propre aujourd'hui peut se corrompre demain. La quatrième étape installe une surveillance dans la durée. Vous suivez le comportement du modèle pour repérer une dérive soudaine sur un sujet, vous rejouez périodiquement des tests de référence dont vous connaissez les bonnes réponses, et vous cherchez activement les comportements cachés par des tests offensifs. C'est précisément le rôle du red teaming d'un LLM, qui traque les déclencheurs et les portes dérobées que le contrôle des données seul ne révèle pas.

Le résultat : une donnée traçable et un modèle défendable

Au bout de cette méthode, vous ne pariez plus sur la propreté supposée de vos données. Pour chaque version de votre IA, vous savez d'où vient ce qui l'a nourrie, vous pouvez prouver que rien n'a été altéré en chemin, et vous détectez une dérive avant qu'elle ne s'installe. Cette traçabilité sert deux fois : elle réduit votre surface d'attaque en amont, et elle constitue une preuve exploitable quand un régulateur ou un client vous demande de justifier la fiabilité de votre modèle. La maîtrise des données rejoint alors la démarche plus large d'un audit de sécurité d'une application IA, dont elle est l'un des volets.

L'empoisonnement n'est qu'un des dangers propres aux modèles de langage. Pour le situer dans le tableau d'ensemble et le prioriser face aux autres, je passe en revue les dix risques majeurs dans mon guide sur l'OWASP LLM Top 10 expliqué pour décider.

Questions fréquentes

Sommes-nous concernés si nous n'entraînons aucun modèle nous-mêmes ?

Oui. Dès que vous branchez une IA sur vos documents, par exemple un assistant qui répond à partir de votre base interne, vous ouvrez la porte de l'indexation. Un document piégé déposé dans cette base peut orienter les réponses sans que vous ayez jamais touché à l'entraînement. C'est même le cas le plus répandu en entreprise.

Comment repérer un empoisonnement une fois qu'il est en place ?

Vous ne le lisez pas dans le modèle, vous l'observez dans son comportement. Une dérive sur un sujet précis, une réponse anormalement orientée ou une réaction à un mot-clé inhabituel sont des signaux. C'est pourquoi la surveillance et les tests offensifs sont indispensables : ils font apparaître ce que l'inspection statique ne montre jamais.

Un contrôle d'accès strict suffit-il à empêcher l'empoisonnement ?

Il aide mais ne suffit pas. Le contrôle d'accès protège des apports non autorisés, mais le poison peut venir d'une source pourtant légitime, corrompue en amont ou par erreur. La provenance et l'intégrité restent nécessaires même à l'intérieur de votre périmètre de confiance.

Par où commencer si nos données ne sont aujourd'hui pas tracées ?

Par l'inventaire des flux qui nourrissent vos IA : d'où viennent les données d'entraînement, d'affinage et d'indexation. Traitez en priorité la base RAG branchée en production, car c'est la porte la plus active, puis appliquez les quatre étapes à chaque flux, du plus sensible au moins critique.

Cartographier vos flux de données, qualifier leur provenance et éprouver la robustesse de vos modèles, c'est l'un des volets de mon audit Sécurité & Conformité IA. En quelques jours, vous savez par où le poison pourrait entrer et par quoi commencer pour refermer chaque porte.

Cet article a une visée pédagogique et ne constitue pas un conseil juridique. Chaque situation mérite une analyse au cas par cas.