Intelligence artificielle

Particuliers et entreprises

Empoisonnement des données ou du modèle

Data poisoning / Model poisoning

Des données ou composants altérés influencent le comportement d’un modèle.

Révision éditoriale : 23 septembre 2026Comprendre : 2 min · Cas technique et détails : 4 min

Comprendre et agir

À la fin de cette lecture, vous pourrez expliquer le piège et choisir une première réaction adaptée à votre rôle. Aucun prérequis informatique n’est nécessaire.

Une situation concrète

Une base documentaire utilisée par un assistant reçoit des fiches volontairement fausses. Plus tard, les réponses citent ces fiches comme si elles étaient fiables. Dans un autre scénario, les données d’entraînement d’un modèle sont altérées pour modifier durablement son comportement.

Comment cela fonctionne

L’empoisonnement d’IA consiste à altérer volontairement les données dont un système apprend ou qu’il consulte pour répondre. Si un assistant s’appuie sur une fausse fiche, il peut en reprendre les affirmations avec assurance. Si les données ont servi à entraîner le modèle, leur retrait ne suffit pas forcément à effacer ce qu’il a appris. Une réponse fausse peut aussi venir d’une erreur ordinaire : il faut examiner les sources et les changements avant de conclure à une attaque.

Comment le piège fonctionne

Une source est manipulée
Documents, exemples ou modèle.
L’IA s’appuie dessus
Apprentissage ou recherche documentaire.
Ses résultats sont orientés
De façon générale ou dans certains cas.

Les signes qui doivent attirer l’attention

Des sources nouvelles ou modifiées influencent anormalement les réponses.
Les performances changent pour une catégorie précise de cas.
La provenance d’un jeu de données ou d’un modèle devient impossible à établir.

Ces signes invitent à vérifier la situation. Pris isolément, ils ne prouvent pas tous qu’une attaque a réussi.

Ce que vous pouvez faire

Vos premiers réflexes

Vérifiez les sources citées par un assistant avant une décision importante. Signalez une réponse fausse avec le document ou la référence qui semble l’avoir influencée.

Si vous êtes responsable du service ou de l’organisation

Conservez la provenance et les versions des données. Évaluez les résultats par catégorie sur un jeu indépendant avant d’intégrer une nouvelle source ou un nouveau modèle.

Le détail qui change toutUne idée reçue à corriger

Retirer un document de la base ne supprime pas nécessairement son influence si le modèle a déjà été entraîné dessus.

À vous de décider

L’assistant cite un document pour appuyer une réponse. La présence de cette référence garantit-elle que l’information est fiable ?

Choisissez votre réponse et expliquez pourquoi avant de lire la correction.

Voir la réponse expliquée

Non. Le document peut être faux, altéré ou mal interprété. Consultez son contenu et son origine, puis comparez avec une source indépendante avant une décision importante. Signalez l’erreur avec la référence : une réponse fausse ne prouve pas à elle seule un empoisonnement volontaire.

Analyser un cas technique

Pour les personnes qui développent, administrent ou analysent les systèmes concernés. Commencez par « Comprendre et agir » si ces notions sont nouvelles pour vous.

Étude de cas fictive

De nouvelles données dégradent un groupe de cas sans faire baisser le score global

Entre les exécutions R17 et R18, le modèle et le code d’évaluation restent identiques, mais les données changent. Une nouvelle source ajoute 120 éléments sans revue. Le score global reste proche de 0,96, tandis que celui du groupe ciblé chute de 0,98 à 0,20. La moyenne masque donc une dégradation importante.

Cette comparaison oriente vers les données, mais il faut vérifier les autres différences de configuration et la reproductibilité de l’évaluation. Une erreur d’étiquetage ou un changement de distribution peut produire un effet similaire à un empoisonnement volontaire. Retrouver la provenance des éléments, leur validation, leurs transformations et leur présence dans les versions utilisées.

L’impact dépend de l’endroit où les données interviennent : apprentissage, ajustement, index documentaire ou jeu d’évaluation. Corrompre le jeu de test peut aussi donner une impression trompeuse de progrès. Conserver des versions traçables et des évaluations indépendantes par catégorie. Retirer une source de l’index ne modifie pas automatiquement un modèle déjà entraîné avec elle ; la remise en état doit correspondre au composant réellement touché.

Le déroulement en schéma

Qui échange avec quiLisez les échanges de haut en bas. Le point marque le départ et la flèche l’arrivée. Les vérifications après correction ne sont pas la suite de l’attaque.

Faites défiler le diagramme pour suivre les échanges ; les noms des acteurs restent en haut. Sur petit écran, faites aussi défiler de gauche à droite.

Étape

Source de donnéesLot S9

PipelineValidation et transformations

Modèle / indexVersion candidate

ÉvaluationCohortes indépendantes

Action
Lot ajouté
Source de données vers Pipeline
Trace 120 éléments
Action sur place
Validation manquante
Pipeline
Trace reviewer absent
Action
Jeu de données D9 utilisé
Pipeline vers Modèle / index
Trace lignée conservée
Action
Résultats candidat R18
Modèle / index vers Évaluation
Trace même jeu E3
Action sur place
Analyse par cohorte
Évaluation
Trace moyenne stable
Refus / blocage
Mise en service suspendue
Évaluation vers Pipeline
Trace régression ciblée
Action
Reconstruction et retour à une version fiable
Pipeline vers Modèle / index
Trace index et caches inclus

Comment repérer cette attaque

Indices à rechercher

Repérer les écarts de résultat concentrés sur certains groupes ou tâches, les ajouts de données sans validation et les changements de provenance inexpliqués.

Éléments à croiser

Comparer deux runs dont le code, les paramètres et l’évaluation sont maîtrisés, puis isoler la modification de données suspecte. Examiner la cohorte ciblée en plus de la métrique globale.

Limites de l’interprétation

Une baisse de qualité peut venir d’une dérive des données, d’une erreur d’étiquetage ou d’un changement d’évaluation. Elle ne prouve pas une intention d’empoisonnement ; l’absence de traçabilité limite l’attribution.

Comment réagir

Suspendre la mise en service de la version concernée et isoler les données douteuses. Restaurer le corpus ou l’index, ou réentraîner le modèle selon le composant touché. Comparer les résultats dans les mêmes conditions, revoir la validation des sources et examiner les décisions déjà prises à partir des sorties affectées.

Vérifier la correction

Ces contrôles s’adressent à l’équipe responsable du système. Les simulations se préparent dans un environnement de test autorisé ; la lecture du cas ne nécessite aucune manipulation.

Les évaluations par groupe sont examinées en plus de la moyenne globale.
Chaque donnée ajoutée peut être reliée à une source, une version et une décision de validation.
Le retrait ou le réentraînement est vérifié sur le composant touché et sur un jeu de contrôle indépendant.

À vous de raisonner

Le score global reste stable après l’ajout d’une source, mais celui d’un groupe chute. Quelles vérifications permettent de qualifier cette dégradation ?

Formulez votre décision et l’élément qui la justifie avant d’ouvrir la correction.

Comparer avec le raisonnement expliqué

Comparez les versions des données et les autres paramètres, reproduisez l’évaluation par groupe et retrouvez la provenance des ajouts. Une erreur ou un changement de distribution reste possible : la baisse ne prouve pas une intention malveillante. Vérifiez la correction sur le composant touché et un jeu indépendant.

Consulter les détails techniques

Pour aller plus loin après l’étude du cas : les extraits servent à s’exercer à la lecture des traces ; le guide de collecte aide les personnes qui disposent des outils et des accès nécessaires.

Lire les extraits commentés — reconstitution fictive

Ces extraits utilisent des valeurs fictives. Certains reprennent des champs documentés ; d’autres regroupent plusieurs sources dans un format pédagogique. Ce ne sont pas des exports bruts à retrouver tels quels dans vos outils. Commencez par les champs expliqués, puis retrouvez-les dans les extraits.

reviewer: Validation de provenance que le pipeline du cas doit enregistrer explicitement ; elle n’est pas créée automatiquement par MLflow.
cohort: Sous-ensemble évalué séparément : une moyenne globale stable peut masquer sa dégradation.

Lignée des données et résultats

Journal

Exemple synthétique de registre d’expérimentation ; les digests sont des repères, pas de vrais hashes.

run=R17 model_base=M4 dataset=D8 code=COMMIT7 eval_set=E3
run=R18 model_base=M4 dataset=D9 code=COMMIT7 eval_set=E3
dataset D9 added_source=S9 reviewer=missing records_added=120
metric R17 target_cohort=0.98 global=0.96
metric R18 target_cohort=0.20 global=0.96

Préparer une collecte dans votre environnement

Choisissez les sources qui correspondent à vos outils et à votre périmètre d’intervention. Cette liste n’est pas un équipement requis pour comprendre la fiche. Vérifiez que les journaux nécessaires étaient activés pendant la période étudiée. Conservez l’export original, son fuseau horaire et sa provenance dans un espace à accès restreint ; travaillez sur une copie expurgée des secrets.

MLflow Tracking — expériences et runs
Où les trouver
Interface MLflow → expérience → runs comparés : paramètres, métriques, jeux de données et artefacts effectivement enregistrés par le pipeline.
Quoi relever
Comparer run_id, versions du code et des données, paramètres, métriques par cohorte et artefacts. Retrouver la provenance des nouvelles données et les validations enregistrées par le pipeline.
Accès et prérequis
Accès au serveur de suivi. Les versions de données, cohortes et validations doivent être enregistrées explicitement ; MLflow ne les invente pas à partir du modèle final.
Documentation : MLflow Tracking — expériences et runs
GitHub Actions — journaux d’exécution
Où les trouver
Dépôt → Actions → exécution concernée → job et étapes ; télécharger les logs encore disponibles et conserver séparément les attestations et artefacts de cette exécution.
Quoi relever
Si l’entraînement ou la préparation passent par GitHub Actions, conserver l’exécution, le commit et les artefacts qui ont introduit le jeu de données. Chercher qui a approuvé le changement et avec quels tests.
Accès et prérequis
Accès au dépôt et historique non expiré. Le succès d’un job ne garantit ni l’identité de l’artefact déployé ni la légitimité de la modification qui l’a produit.
Documentation : GitHub Actions — journaux d’exécution

Si vous pensez être concerné

Isolez les versions suspectes et gardez les éléments nécessaires à l’analyse.
Identifiez les données et étapes ayant introduit le changement.
Revenez à une version fiable puis vérifiez les résultats après reconstruction.

Pour qualifier votre situation et être orienté : obtenir une assistance sur 17Cyber. Dans une organisation, prévenez aussi le responsable ou prestataire chargé de la sécurité.

Sources et repères pour approfondir

OWASP GenAI — Data and Model Poisoning — genai.owasp.org
MITRE ATLAS — atlas.mitre.org
OWASP GenAI — Data and Model Poisoning — genai.owasp.org
NIST — Adversarial Machine Learning — csrc.nist.gov