Bonnes pratiques pour sécuriser les données utilisées dans l’entraînement et le fonctionnement des systèmes d’intelligence artificielle

J’ai souhaité vous proposer mes réflexions sur les bonnes pratiques de l’IA vue par un responsable de CERT. L’exercice n’était pas évident mais grâce à la CISA, Je peux vous partager ma réflexion sur l’IA.

Les ressources de données utilisées lors du développement, des tests et de l’exploitation d’un système d’intelligence artificielle (IA) constituent un élément critique de la chaîne d’approvisionnement de l’IA.

À ce titre, elles doivent être protégées et sécurisées de bout en bout. En effet, la sécurité des données est primordiale pour garantir la fiabilité des systèmes d’IA : si les données sont altérées ou compromises, les résultats produits par le modèle le seront aussi. Les grandes agences de cybersécurité internationales – notamment la NSA, la CISA et le FBI aux États-Unis, ainsi que leurs homologues en Australie, Nouvelle-Zélande et au Royaume-Uni – soulignent dans un guide conjoint de 2025 le rôle critique de la sécurité des données pour assurer l’exactitude, l’intégrité et la fiabilité des résultats produits par l’IA.

Cet article s’appuie sur ce guide de référence afin de présenter de manière approfondie les enjeux de la sécurité des données dans les systèmes d’IA, les bonnes pratiques à adopter et les risques majeurs à anticiper.

Dans le lexique de gestion des données de la Communauté du renseignement (IC) américaine, la sécurité des données est définie comme « la capacité à protéger les ressources de données contre la découverte, l’accès, l’utilisation, la modification et/ou la destruction non autorisés… la sécurité des données est une composante de la protection des données ».

Autrement dit, la sécurité des données vise à préserver la confidentialité, l’intégrité et la disponibilité des données tout au long de leur cycle de vie. Il s’agit d’un pilier fondamental pour le développement et le déploiement de systèmes d’IA fiables.

Je considère que la sécurité des données est un élément clé des stratégies de protection des systèmes d’IA, aux côtés des mesures de cybersécurité classiques. Des stratégies robustes de gestion des données doivent garantir que les données n’ont à aucun moment été altérées au cours du cycle de vie du système d’IA, qu’elles sont exemptes de contenu malveillant ou inapproprié, et qu’elles ne comportent pas d’informations dupliquées ou anormales par inadvertance. Il convient de noter que la sécurité des données d’IA repose sur la mise en place de protections cybersécurité de base pour l’ensemble des jeux de données utilisés lors de la conception, du déploiement, de l’exploitation et de la maintenance des systèmes d’IA ainsi que des modèles d’apprentissage automatique sous-jacents.

En tant qu’expert en cybersécurité, je souligne l’importance stratégique d’adopter une approche globale de sécurisation des données d’IA. Cela passe d’abord par une compréhension du cycle de vie d’un système d’IA et des points de vigilance associés à chaque phase du traitement des données.

Dans les sections qui suivent, je présenterai d’une part un cadre global du cycle de vie des systèmes d’IA en lien avec la gestion des données, et d’autre part une série de bonnes pratiques recommandées pour sécuriser les données utilisées par l’IA. J’approfondirai ensuite l’analyse de trois risques majeurs identifiés – la chaîne d’approvisionnement des données, les données malveillantes (dites empoisonnées) et la dérive des données – en décrivant pour chacun la nature de la menace et les stratégies de mitigation à mettre en œuvre. Enfin, une conclusion mettra en perspective les implications stratégiques de ces enjeux pour les organisations exploitant l’IA, avant de fournir les références complètes des sources utilisées.

Le cycle de vie des systèmes d’IA et la gestion des données

La sécurité des données est un facteur transversal critique qui s’applique à toutes les phases du cycle de vie d’un système d’IA. Pour comprendre comment la protection des données s’intègre dans un système d’IA, il est utile d’examiner les grandes étapes de son cycle de vie, telles que définies par le cadre de gestion des risques de l’IA du NIST (AI RMF). Le NIST distingue généralement six phases majeures : 1) Planification & Conception, 2) Collecte & Traitement des données, 3) Construction & Entraînement du modèle, 4) Vérification & Validation du modèle, 5) Déploiement & Utilisation, et 6) Exploitation & Surveillance du système d’IA. Chacune de ces étapes s’accompagne de préoccupations spécifiques en matière de gestion des données et de sécurité, ainsi que d’évaluations à mener en continu (tests, validations, audits, etc.).

Planification & Conception : Dès la conception initiale d’un système d’IA, j’insiste pour intégrer des mesures de sécurité des données dès l’origine. Il s’agit de concevoir l’architecture et les protocoles de sécurité en anticipant les menaces (par exemple via une analyse de risque et des modélisations de menace spécifiques aux données), de prévoir des contrôles robustes d’accès et de confidentialité, et d’appliquer les principes de « privacy by design » (protection de la vie privée dès la conception). L’objectif est d’ériger des garde-fous dès le départ pour éviter les failles ultérieures liées aux données. Par exemple, si un attaquant parvient à manipuler les données d’entrée d’un futur système d’IA, il pourra manipuler en cascade les décisions du modèle – il est donc crucial de prévoir dès la conception comment prévenir et détecter de telles manipulations. À ce stade, il faut également réfléchir à la provenance des données (fournisseurs, sources tierces) et évaluer la chaîne d’approvisionnement des données envisagée afin d’identifier d’emblée les risques potentiels (voir section sur la chaîne d’approvisionnement des données).
Collecte & Traitement des données : Cette phase consiste à rassembler les données brutes nécessaires à l’entraînement, puis à les préparer (nettoyage, étiquetage, agrégation, etc.). Je préconise de porter une attention particulière à l’intégrité et l’authenticité des données collectées. Il convient de s’assurer de la fiabilité des sources (idéalement des sources authoritatives dignes de confiance) et de mettre en place des mécanismes de vérification systématique de l’intégrité des données lors de leur stockage et transfert (par exemple via des hachages ou empreintes cryptographiques permettant de détecter la moindre altération). Des contrôles internes et externes de validation des données doivent être effectués pour détecter d’éventuelles anomalies ou incohérences. Durant la phase de pré-traitement, il est essentiel de sanitiser les données, c’est-à-dire de filtrer les données bruitées, aberrantes ou potentiellement malveillantes (voir également les bonnes pratiques de détection d’anomalies plus loin) avant de les utiliser pour l’entraînement du modèle. À ce stade, la minimisation des données (ne conserver que les données réellement nécessaires), l’anonymisation ou pseudonymisation des données sensibles, et le recours à des transferts sécurisés (chiffrement en transit) sont des techniques à envisager sérieusement. L’enjeu est de protéger les données brutes de toute fuite ou altération dès leur ingestion dans le pipeline d’IA.
Construction & Entraînement du modèle : Il s’agit de la phase où le modèle d’IA est construit (choix de l’architecture, implémentation) puis entraîné sur les données. Durant cette étape, je recommande de protéger strictement l’environnement d’entraînement afin d’éviter toute interférence ou intrusion pouvant altérer soit les données d’entraînement, soit le processus d’apprentissage lui-même. Par exemple, il peut être judicieux d’utiliser des enclaves sécurisées ou des environnements d’exécution de confiance pour isoler le calcul (mémoire sécurisée, exécution chiffrée). Il faut également veiller à la qualité et représentativité des données utilisées : des données inexactes ou biaisées entraîneront un modèle défaillant. Des techniques de préservation de la vie privée comme l’apprentissage fédéré ou la computation multipartite sécurisée peuvent être mises en œuvre lorsque plusieurs parties prenantes entraînent conjointement un modèle sur des jeux de données partagés, afin de protéger les données de chacune. Toute modification apportée aux données d’entraînement doit être authentifiée – idéalement via des signatures numériques – de sorte qu’on puisse garantir l’origine et l’intégrité de chaque version du jeu de données. En somme, pendant l’entraînement, l’accent doit être mis sur la protection des données contre toute altération (volontaire ou accidentelle) et sur le suivi de leur provenance dans le pipeline d’IA.
Vérification & Validation (du modèle) : Une fois le modèle entraîné, il est indispensable de le tester et valider rigoureusement avant son déploiement effectif. Je souligne que cette vérification/validation doit inclure des aspects de sécurité des données. Il s’agit notamment de vérifier l’intégrité des données qui ont servi à l’entraînement (détecter si possible des attaques d’empoisonnement passées inaperçues), de tester le modèle face à des données adversariales pour évaluer sa robustesse, et d’effectuer des audits de sécurité. Des techniques de test avancées, comme la validation formelle ou des analyses adversariales (simulant des tentatives de manipulation des entrées), peuvent être employées pour éprouver la résilience du modèle. Notons que cette phase de validation n’est pas ponctuelle : chaque fois que de nouvelles données ou retours utilisateurs alimentent le modèle, il convient de répéter des vérifications similaires, en appliquant les mêmes standards de sécurité aux nouvelles données qu’aux données d’entraînement initiales. En pratique, cela signifie que si le modèle est affiné avec de nouvelles données (re-training, fine-tuning, RLHF, etc.), ces données additionnelles doivent être soumises aux mêmes contrôles d’intégrité et de qualité que le corpus original.
Déploiement & Utilisation : Cette phase correspond à l’intégration du modèle dans un environnement de production où il fournit des prédictions ou décisions réelles. Je recommande une posture de “zero trust” durant le déploiement, ce qui implique de stricts contrôles d’accès aux données et au modèle, une infrastructure à privilèges minimaux, et une surveillance active des interactions. Concrètement, il faut s’assurer que seules les personnes ou systèmes autorisés peuvent accéder aux données d’entrée du modèle, aux données de sortie, ainsi qu’aux données internes du système d’IA (paramètres du modèle, etc.). Le chiffrement des données en transit et au repos est de rigueur à ce stade (par exemple en utilisant systématiquement TLS pour les communications API, avec des algorithmes de chiffrement robustes tels que AES-256). Le stockage des données doit se faire dans des infrastructures certifiées sécurisées (par ex. conformes aux normes de chiffrement FIPS 140-3) pour prévenir les risques d’exfiltration ou d’accès non-autorisé. Par ailleurs, j’encourage la mise en place d’une surveillance continue des comportements anormaux du système d’IA en production : par exemple détecter des pics d’erreurs ou des sorties anormalement biaisées pourrait révéler qu’une donnée inattendue ou malveillante influence le modèle. À ce stade, il faut également veiller à la conformité réglementaire (p. ex. respecter les règles GDPR si des données personnelles sont traitées) et préparer des plans de réponse à incident en cas de compromission.
Exploitation & Surveillance (Opérations) : Une fois le système d’IA déployé, la sécurisation des données reste un effort continu. J’estime qu’il est indispensable de procéder à des évaluations régulières des risques liés aux données tout au long de la phase opérationnelle. Cela inclut la surveillance des éventuelles fuites de données (breaches), la vérification du respect des politiques de conservation (p. ex. suppression sécurisée des données qui ne sont plus nécessaires), la mise à jour des mesures de sécurité face à l’évolution des menaces, et la réalisation d’audits de sécurité périodiques. En cas d’incident ou d’anomalie détectée, des plans de réponse doivent être en place pour contenir l’impact et corriger les failles. Un aspect crucial en phase opérationnelle est la gestion de la dérive des données : il convient de suivre de près l’évolution des données traitées par le système au fil du temps, et de vérifier que le modèle reste valable face à de nouvelles distributions de données (ce point sera détaillé dans la section sur la dérive des données). Négliger ces pratiques de surveillance peut conduire à de graves conséquences telles que la corruption insidieuse des données, des modèles compromis, des fuites d’information ou un non-respect des exigences de conformité – autant de scénarios qui soulignent l’importance d’une sécurité robuste des données à chaque phase du cycle de vie.

En résumé, adopter une vision holistique de la sécurité des données sur l’ensemble du cycle de vie d’un système d’IA permet de renforcer considérablement la fiabilité et la résilience de ce dernier. Dès la planification jusqu’aux opérations courantes, chaque étape offre des opportunités pour intégrer des contrôles de sécurité adaptés, réduisant ainsi la surface d’attaque et le risque d’erreurs dues à des données corrompues.

J’insiste sur le fait qu’une culture de sécurité des données tout au long du cycle de vie est non seulement techniquement judicieuse, mais stratégique pour toute organisation qui déploie des systèmes d’IA à des fins sensibles ou critiques.

Bonnes pratiques pour sécuriser les données des systèmes d’IA

Dans cette section, je présente une liste structurée de dix bonnes pratiques clés visant à améliorer la sécurité des données utilisées pour construire et faire fonctionner des systèmes d’IA, que ceux-ci soient hébergés sur site ou dans le nuage. Ces mesures concrètes, inspirées des recommandations des agences de cybersécurité, couvrent différents aspects tels que la provenance des données, leur intégrité, leur protection cryptographique, la préservation de la vie privée, et la gestion continue des risques. Chaque bonne pratique est accompagnée d’explications ou d’exemples pour en faciliter la mise en œuvre par les équipes responsables.

Utiliser des sources de données fiables et tracer la provenance – Je recommande de soigner le choix des sources de données et de n’utiliser pour l’entraînement et l’opération de l’IA que des données fiables, vérifiées et issues de sources dignes de confiance. Dans la mesure du possible, privilégiez les sources officielles ou certifiées pour réduire les risques d’injection de données falsifiées. En parallèle, mettez en place un suivi de provenance des données : l’objectif est de pouvoir retracer l’origine de chaque élément de donnée et de journaliser le parcours de ces données à travers le système d’IA. Concrètement, il peut s’agir de maintenir une base de métadonnées de provenance où chaque jeu de données entrant est enregistré avec son origine, son horodatage, son fournisseur, etc., de façon inaltérable et auditable. L’adoption de mécanismes de ledger immuables (append-only) signés cryptographiquement est une bonne pratique pour assurer une traçabilité robuste : cela permet non seulement d’identifier la source d’éventuelles données malveillantes injectées, mais aussi de garantir qu’aucun acteur ne puisse modifier les données à son insu sans que cela ne soit détecté.
Vérifier et maintenir l’intégrité des données en stockage et en transit – Préserver l’intégrité des données est indispensable pour garder des résultats d’IA exacts et fiables. Il convient d’utiliser des empreintes numériques (hash) ou des sommes de contrôle pour détecter toute altération des données stockées ou transmises sur le réseau. Par exemple, pour chaque fichier de données d’entraînement, on peut calculer un hash cryptographique (SHA-256, SHA-3…) lors de son ingestion puis régulièrement pendant son stockage : si un bit est modifié, le hash ne concordera plus, révélant une altération éventuelle. De même, lors des transferts de données (entre partenaires, du stockage vers l’environnement d’entraînement, etc.), des mécanismes de vérification d’intégrité doivent être intégrés (vérification de hash à la réception, signatures numériques, etc.). Je préconise d’automatiser ces contrôles d’intégrité dans les pipelines de données afin que toute corruption accidentelle ou malveillante soit détectée le plus tôt possible. Cette approche contribue à sauvegarder l’authenticité des informations utilisées par le modèle d’IA, en garantissant que rien n’a été modifié à leur insu pendant le stockage ou le transit.
Authentifier les modifications des données par des signatures numériques – L’usage de signatures numériques est une mesure forte pour garantir qu’un jeu de données n’a pas été altéré par un tiers non autorisé. Je recommande d’apposer une signature cryptographique sur chaque version originale des données d’entraînement, puis sur chaque modification ou mise à jour ultérieure de ces données. Ainsi, toute modification doit être signée par la personne (ou le processus automatisé) l’ayant effectuée, à l’aide d’une clé privée détenue uniquement par les acteurs autorisés. La vérification de la signature avec la clé publique correspondante permettra d’authentifier l’identité du modificateur et d’assurer que les données n’ont pas été altérées en transit. Il est conseillé de s’appuyer sur des algorithmes de signature résistants aux attaques quantiques dans la mesure du possible, anticipant l’évolution des capacités d’attaque. Par ailleurs, l’organisation devrait utiliser des autorités de certification de confiance pour délivrer et gérer ces certificats de signature, de manière à s’assurer de la validité de toute la chaîne d’approbation des données. En somme, les signatures numériques apportent une garantie d’intégrité forte, complémentaire des hachages, en offrant une authentification de l’auteur des changements en plus de la détection de la modification.
S’appuyer sur une infrastructure informatique de confiance – Pour toutes les opérations manipulant des données sensibles d’IA, j’encourage vivement l’adoption d’une infrastructure dite de confiance alignée avec les principes d’architecture Zero Trust. Il s’agit d’utiliser des environnements d’exécution sécurisés, isolés et vérifiables pour le traitement des données critiques. Par exemple, on peut recourir à des technologies de type TEE (Trusted Execution Environment – enclave sécurisée) qui chiffrent les données en mémoire et ne permettent qu’au code autorisé d’y accéder, réduisant fortement les risques de compromission durant le calcul. De même, segmenter les données et les traitements en fonction de leur sensibilité, et n’accorder que les privilèges minimum nécessaires aux processus (principe du moindre privilège), contribue à limiter l’impact d’une éventuelle brèche. Une infrastructure de confiance vise in fine à préserver la confidentialité et l’intégrité des données pendant les calculs, en isolant les opérations critiques dans des « bulles » sécurisées. Je considère ces environnements de confiance comme essentiels pour les applications d’IA manipulant des données sensibles ou critiques, car ils réduisent les risques liés à l’exécution sur des systèmes partagés ou non maîtrisés. En éliminant autant que possible les points de vulnérabilité, on crée une base solide pour un écosystème d’IA plus transparent et résistant aux manipulations.
Classifier les données et contrôler les accès – Il est important de catégoriser les données en fonction de leur sensibilité et des mesures de protection requises. Par exemple, les données pourraient être classées en catégories Confidentiel, Interne ou Public, avec pour chacune des règles de sécurité spécifiques. Cette classification permet d’appliquer des contrôles proportionnés : plus une donnée est sensible, plus les mesures de protection (chiffrement fort, restrictions d’accès, surveillance rapprochée) doivent être strictes. J’insiste notamment sur le contrôle d’accès : chaque catégorie de données devrait n’être accessible qu’aux personnes ou systèmes ayant un besoin légitime. Par ailleurs, une bonne pratique est d’aligner le niveau de classification de la sortie d’un système d’IA sur le niveau de sensibilité des données d’entrée qui ont servi à sa création. En d’autres termes, si un modèle d’IA est entraîné sur des données classifiées Confidentiel, alors les prédictions ou outputs de ce modèle doivent être traités avec le même niveau de confidentialité (et non considérés comme sans risque sous prétexte qu’ils seraient un artefact différent des données brutes). En somme, je préconise une approche rigoureuse de gouvernance des données, où chaque élément de donnée est inventorié, classé et assorti de contrôles d’accès adéquats tout au long de son cycle de vie.
Chiffrer les données – Le chiffrement est l’une des pierres angulaires de la protection des données. Je recommande d’adopter des protocoles de chiffrement robustes, en phase avec le niveau de sensibilité des données de l’organisation. Cela inclut le chiffrement des données au repos (stockées sur disque, en base de données, etc.), des données en transit (lorsqu’elles circulent sur un réseau ou entre composants), et même des données en cours de traitement lorsque c’est possible (p. ex. calcul sur données chiffrées, enclaves sécurisées mentionnées plus haut). À l’heure actuelle, un algorithme symétrique tel que AES-256 est considéré comme un standard industriel fiable, offrant une bonne résistance y compris face à de possibles menaces quantiques à court terme. Pour les communications réseau, on veillera à utiliser des protocoles éprouvés (ex : TLS 1.3 avec suites cryptographiques modernes) et à se tenir informé des recommandations post-quantiques dès qu’elles seront disponibles pour les échanges de clés et signatures. Des guides tels que la publication NIST SP 800-52r2 détaillent les bonnes configurations de TLS selon les contextes. En pratique, je conseille de chiffrer par défaut : toute donnée d’entraînement ou de test sensible stockée devrait l’être de manière chiffrée, et tout échange de données entre composants du pipeline d’IA devrait se faire sur des canaux sécurisés. Ceci réduit drastiquement les risques qu’un attaquant, même s’il accède à une infrastructure, puisse exploiter les données en clair.
Stocker les données de manière sécurisée – Au-delà du chiffrement, le stockage sécurisé implique de choisir des solutions de stockage dont la robustesse a été certifiée et qui offrent des mécanismes de sécurité intégrés. Je recommande d’utiliser des supports ou services de stockage conformes aux normes de sécurité élevées, par exemple certifiés FIPS 140-3 pour les modules cryptographiques. Ces normes garantissent que le chiffrement implémenté atteint un niveau de confiance validé par les autorités. Par ailleurs, il convient de sécuriser l’accès aux dépôts de données : cela recoupe en partie le contrôle d’accès (point 5), mais inclut aussi la supervision des accès (logs, alertes en cas d’accès anormal), la gestion rigoureuse des identités et des droits, etc. Il peut être utile de segmenter les données en dépôts distincts selon leur criticité, et de mettre en place des mesures physiques et logiques de protection (chiffrement matériel des disques, cloisonnement réseau, sauvegardes chiffrées régulières stockées hors-ligne pour parer aux ransomware, etc.). Mon conseil est également de tester régulièrement les mécanismes de récupération des données (plan de reprise après incident) afin de s’assurer qu’en cas d’attaque ou de sinistre, les données d’IA pourraient être restaurées sans compromis sur leur intégrité. En synthèse, un stockage sécurisé vise à rendre les données inaccessibles aux acteurs non autorisés et résilientes face aux tentatives d’intrusion ou de sabotage.
Mettre en œuvre des techniques de préservation de la vie privée – Plusieurs techniques dites de privacy-preserving peuvent être mobilisées pour renforcer la sécurité des données, en particulier lorsque ces données contiennent des informations sensibles sur des individus (données personnelles) ou des secrets d’affaires. Bien qu’elles comportent parfois des coûts computationnels non négligeables, je préconise d’évaluer leur applicabilité selon les cas d’usage. Parmi ces techniques figurent :
Supprimer ou purger les données de manière sécurisée – La protection des données ne s’arrête pas à leur utilisation : elle inclut aussi leur cycle de vie en fin d’exploitation. Je préconise aux organisations de mettre en place des politiques de suppression sécurisée des données lorsqu’elles ne sont plus nécessaires, notamment avant de réutiliser ou de mettre hors service des supports de stockage ayant contenu des données d’IA sensibles. Une suppression dite “sécurisée” signifie qu’il ne suffit pas d’effacer le fichier de manière classique (ce qui laisse souvent les données récupérables sur le disque), mais qu’il faut employer des méthodes garantissant l’impossibilité de reconstituer les données supprimées. Des techniques comme l’effacement cryptographique (cryptographic erase, où l’on détruit la clé de chiffrement ce qui rend les données chiffrées inexploitables), le blocage ou l’écrasement multiple des données sur le disque selon les directives de NIST SP 800-88, sont à privilégier. Il est recommandé de consigner ces opérations (journalisation des effacements sécurisés) et de vérifier périodiquement via des audits que les procédures de purge des données sont bien respectées. Cela permet d’éviter qu’d’anciennes données sensibles ne refassent surface par inadvertance ou à la suite d’une récupération malveillante de matériel mis au rebut.
Conduire des évaluations continues des risques sur les données – Enfin, j’insiste sur la nécessité d’évaluer en continu les risques pesant sur les données d’IA, à l’aide de cadres et de standards reconnus. Par exemple, les organisations gagneraient à intégrer la sécurité des données d’IA dans leur processus global de gestion des risques en s’appuyant sur des référentiels tels que le NIST Risk Management Framework (RMF) et le NIST AI RMF dédié aux systèmes d’IA. Des analyses de risques régulières doivent être menées pour identifier les nouvelles menaces (techniques d’attaque émergentes, vulnérabilités dans les jeux de données ou les pipelines, etc.), pour évaluer l’efficacité des contrôles en place et pour prioriser les actions d’amélioration. Ce processus doit être vivant : il s’agit d’adapter en permanence les mesures de sécurité des données en fonction de l’évolution des technologies et des attaques. J’encourage les équipes à établir un cycle d’amélioration continue où chaque incident de sécurité lié aux données (même mineur) est analysé a posteriori afin d’en tirer des leçons et d’ajuster les pratiques. De plus, rester informé des avancées (nouvelles solutions de sécurisation, outils d’automatisation, résultats de la recherche) fait partie intégrante du maintien d’une posture de sécurité robuste. En résumé, adopter une démarche proactive et itérative de gestion des risques sur les données d’IA permettra à l’organisation de prévenir les incidents plutôt que de simplement les subir, et de conserver une longueur d’avance face aux menaces.

(Tableau récapitulatif) : La table suivante synthétise les domaines d’attention principaux en matière de sécurité des données pour chaque phase du cycle de vie de l’IA, ainsi que les risques majeurs correspondants et les mesures phares à envisager :

Ce tableau illustre que la sécurité des données doit être prise en compte à chaque étape du projet IA, avec des mesures spécifiques adaptées au contexte de la phase. En particulier, trois thématiques de risque transversales se dégagent – la provenance des données (supply chain), les données malveillantes (empoisonnement) et la dérive au cours du temps – sur lesquelles nous allons maintenant revenir en détail.

Chaîne d’approvisionnement des données : risques et parades

Relevant pour les phases : Plan & Conception; Collecte & Traitement; Construction; Validation; Déploiement; Exploitation.

Le risque lié à la chaîne d’approvisionnement des données recouvre l’ensemble des menaces pesant sur les données en amont de leur utilisation par le système d’IA. Autrement dit, même avant d’entraîner un modèle, les données peuvent être compromises lors de leur collecte, de leur agrégation ou de leur mise à disposition. Dans de nombreux cas, les organisations utilisent des jeux de données externes ou tiers (open source, données du web, données fournies par des partenaires). Si ces sources ne sont pas maîtrisées, un attaquant astucieux peut profiter de failles dans la chaîne d’approvisionnement pour injecter du contenu malicieux ou dénaturé. J’observe que la sécurité globale d’un système d’IA dépend fortement de la confiance qu’on peut accorder à ses données d’entrée : garbage in, garbage out comme on dit, des données corrompues produiront un modèle corrompu.

Un premier scénario de menace concerne les jeux de données web “curatés” (c’est-à-dire compilés par des tiers à partir du web). Des exemples notables incluent des corpus massifs comme LAION-2B ou COYO-700M utilisés pour entraîner des modèles de vision ou de langage. Ces ensembles sont vulnérables à une technique appelée empoisonnement à double-vue (split-view poisoning). L’idée est la suivante : le jeu de données curaté ne contient souvent que des liens ou références vers des données (par exemple des URLs pointant vers des images ou des textes sur Internet). Si l’un des domaines hébergeant ces données référencées arrive à expiration et qu’un acteur malveillant le rachète, il obtient alors le contrôle du contenu à cette adresse. Le corpus, lui, pointe toujours vers cette URL soi-disant légitime, mais désormais l’attaquant peut y placer n’importe quelle donnée de son choix (fausse, toxique, malveillante). Ainsi, sans coup férir, le jeu de données curaté est empoisonné a posteriori. Des recherches ont montré qu’il est parfois peu coûteux d’acheter suffisamment de domaines expirés pour altérer significativement un ensemble : par exemple, dans le cas de COYO-700M, on estime qu’une attaque efficace pourrait coûter seulement 60 dollars US à un attaquant opportuniste, ce qui la met à la portée de menaces même peu financées. Ce type d’attaque illustre la vulnérabilité de toute chaîne d’approvisionnement de données ouverte où le maintien de l’intégrité du contenu dans le temps n’est pas garanti par le curateur.

Un deuxième scénario de menace concerne les jeux de données web collectés automatiquement (ex : dumps de Wikipedia, corpus provenant de crawlers). Ici, une technique d’empoisonnement courante est appelée empoisonnement en anticipant la collecte (frontrunning poisoning). Par exemple, la base Wikipedia est exportée deux fois par mois sous forme de dumps publics. Un attaquant peut planifier des modifications malveillantes sur certaines pages juste avant la date du snapshot mensuel. Si ces changements passent sous le radar des modérateurs pendant quelques jours, ils seront inclus dans le dump officiel et diffusés à des milliers d’utilisateurs et de modèles d’IA. L’attaquant peut ensuite soit retirer son contenu (pour ne pas se faire repérer), soit le laisser en espérant qu’il reste undétecté un certain temps, mais le mal est fait : le dataset collecté est pollué. Ce procédé permet d’introduire des exemples biaisés ou toxiques dans des corpus censés faire autorité, sans avoir à compromettre l’infrastructure de la source – il exploite simplement le délai inhérent à la modération ou la mise à jour. Par ailleurs, même en l’absence d’attaque ouverte, des changements sur le web (des évolutions de langage, des vandalisations temporaires, etc.) peuvent se retrouver agrégés dans les données collectées et influencer négativement un modèle si on n’y prend garde.

Un troisième aspect du risque supply chain tient aux données de mauvaise qualité ou mal documentées. Par exemple, l’absence de métadonnées descriptives suffisantes (également appelées déclarations de données) peut causer des problèmes d’interprétation. Si l’on ne sait pas précisément comment, quand, par qui un jeu de données a été constitué, ou si certaines caractéristiques (unités, signification des champs, contexte de collecte) ne sont pas documentées, on court le risque de mauvaises utilisations et d’introduire des biais ou erreurs dans le système. Des métadonnées incomplètes ou erronées peuvent mener à une compréhension incorrecte des données, et donc à un modèle entraîné sur des bases faussées. Pire, un acteur malveillant pourrait exploiter cette faiblesse documentaire en modifiant ou supprimant des métadonnées (par ex. en effaçant l’information qu’une colonne représente des “températures en °C” – le modèle pourrait alors interpréter des valeurs de façon incohérente). Ce type de faille n’est pas du « bruit » visible dans les données elles-mêmes mais constitue tout de même un risque pour l’intégrité et la sécurité du système d’IA. Je préconise donc une gouvernance stricte des métadonnées : chaque jeu de données devrait comporter une “fiche d’identité” complète, vérifiée, et stockée de manière sécurisée. Des processus de validation de la complétude et de la cohérence des métadonnées sont à établir avant d’utiliser un dataset pour l’entraînement. Le cas échéant, il convient d’enrichir les données avec des sources de référence fiables pour combler les lacunes de documentation.

Stratégies d’atténuation – Pour se prémunir contre les risques de la chaîne d’approvisionnement des données, plusieurs mesures s’imposent. Du côté des curateurs de données, il est recommandé d’attacher une empreinte cryptographique (hash) à chaque élément brut du jeu de données mis à disposition. Ainsi, les utilisateurs en aval pourront vérifier que le contenu téléchargé correspond exactement à celui d’origine. Les curateurs devraient également effectuer des vérifications régulières de leur collection (par exemple re-télécharger périodiquement un échantillon du corpus pour s’assurer qu’il n’a pas changé). Si un changement non expliqué est détecté, ils doivent le signaler ou retirer l’élément suspect. Idéalement, un processus de certification du dataset par son curateur initial peut être mis en place, attestant qu’à la date de publication les données ont été passées au crible pour écarter tout contenu malveillant connu. Du côté des consommateurs de données (ceux qui téléchargent et utilisent un dataset), il est indispensable d’intégrer une étape de vérification de hash lors de l’importation : tout fichier dont l’empreinte ne correspond pas à celle annoncée doit être rejeté d’office. Les consommateurs gagneraient aussi à diversifier leurs sources ou à croiser les données : si le même élément d’information provient de plusieurs dépôts indépendants, la probabilité qu’il ait été compromis dans tous est plus faible (cependant cela ne protège pas contre une compromission à la source unique). Enfin, l’utilisation d’outils d’analyse automatisée peut aider à détecter des anomalies dans des corpus massifs – par exemple des scans antiviraux sur les données, ou des algorithmes signalant des distributions qui changent subitement d’une version à l’autre du dataset.

En résumé, la chaîne d’approvisionnement des données est le premier maillon à sécuriser pour garantir la confiance dans un système d’IA. Des données altérées à la source se propageront à toutes les étapes suivantes. Je recommande donc une vigilance accrue sur la provenance, avec des contrôles techniques (hachages, signatures) et organisationnels (accords avec les fournisseurs de données, audits) afin de réduire la surface d’attaque. Malgré toutes les précautions, il faut reconnaître qu’à l’ère des données massives du web, éliminer totalement le risque est un défi ouvert : la recherche continue d’améliorer les méthodes de filtrage et d’attestation des énormes jeux de données utilisés par les models foundation. En attendant des solutions parfaites, adopter une approche de best effort avec transparence (par exemple, exiger de ses fournisseurs de modèles pré-entraînés des comptes-rendus de leurs méthodes de filtrage de données) est une mesure pragmatique pour les consommateurs en aval.

Données malveillantes (« empoisonnées ») : risques et parades

Relevant pour les phases : Collecte & Traitement; Construction & Entraînement; Validation; Déploiement; Exploitation.

Les données malveillantes – souvent qualifiées de données empoisonnées – représentent une menace directe pour l’exactitude et l’intégrité des systèmes d’IA. Il s’agit de données volontairement conçues ou modifiées par un adversaire dans le but de tromper, biaiser ou perturber le modèle d’IA. Si ces données contaminées sont ingérées par le système (notamment pendant la phase d’entraînement ou lors de mises à jour ultérieures), elles peuvent entraîner des résultats erronés, des comportements indésirables du modèle, voire ouvrir des failles de sécurité exploitables. Je note que les risques liés aux données malveillantes recouvrent principalement les attaques d’empoisonnement du jeu d’entraînement et les attaques adversariales, même s’il existe également des risques connexes dus à des erreurs involontaires ou des biais dans les données qui, sans être intentionnels, peuvent aussi compromettre la fiabilité du modèle.

La menace la plus emblématique est celle des attaques par empoisonnement de l’entraînement (data poisoning). Dans ce scénario, un acteur malveillant parvient à insérer dans le corpus d’entraînement de l’IA des exemples spécifiquement choisis pour fausser l’apprentissage. L’objectif de l’attaquant peut être par exemple de faire en sorte que le modèle apprenne une règle incorrecte (biais induit), qu’il se comporte de manière erratique sur certains inputs, ou même qu’il apprenne une porte dérobée (backdoor) exploitable plus tard. Les attaquants qui pratiquent l’empoisonnement corrompent ainsi le processus d’apprentissage afin de compromettre l’intégrité du modèle produit. Contrairement aux bugs ou bruit aléatoire, ici la corruption est intentionnelle et souvent subtile : les données empoisonnées sont insérées en petites quantités pour ne pas éveiller les soupçons, et peuvent sembler légitimes au premier abord. Par exemple, pour un classifieur d’e-mails spam, un empoisonnement pourrait consister à injecter massivement de faux négatifs (des spams non détectés marqués comme légitimes) afin que le modèle apprenne à considérer ces spams comme acceptables. De telles attaques ont été démontrées à coût relativement faible sur divers systèmes.

Une autre forme d’attaque consiste à introduire des exemples adversariaux (adversarial examples) dans les données. Un exemple adversarial est une entrée modifiée imperceptiblement pour les humains mais qui provoque une erreur du modèle. Typiquement, ce concept s’applique aux attaques après entraînement (on ajuste légèrement une image pour qu’un modèle vision la classe incorrectement). Cependant, on peut aussi imaginer des exemples adversariaux intégrés pendant l’entraînement : l’attaquant fournit des données d’entraînement possédant des perturbations subtiles qui feront que le modèle aura des points faibles précis. Ces exemples “piégés” peuvent éroder les performances du modèle de manière ciblée (par exemple le pousser à toujours confondre deux catégories dans certaines conditions). Là encore, l’attaquant vise à ce que le modèle apprenne de mauvaises associations en incorporant des données manipulées dans son expérience.

Un risque lié, même s’il ne s’agit pas à proprement parler d’empoisonnement du modèle, est la question de la fuite d’informations sensibles via les données. Un adversaire peut exploiter des techniques telles que l’inversion de modèle pour tenter de retrouver, à partir des sorties du modèle, des informations sur les données d’entraînement initiales. Par exemple, en analysant attentivement les prédictions d’un modèle, un attaquant peut parfois inférer la présence de certains enregistrements précis dans les données d’origine (c’est le problème d’inférence d’appartenance mentionné plus haut). Dans le contexte de la sécurité, ceci peut permettre à un acteur malveillant de confirmer que tel ou tel élément (peut-être confidentiel) a servi à entraîner le modèle, constituant une brèche potentielle. Les attaques de modèle de ce type ne modifient pas le modèle, mais en extraient indûment de l’information, ce qui peut être tout aussi problématique (ex : extraction de secrets commerciaux ou de données personnelles qui figuraient dans le jeu d’entraînement).

Face à ces menaces de données malveillantes, plusieurs parades et bonnes pratiques peuvent être déployées :

Détection d’anomalies dans les données d’entraînement : Intégrer des algorithmes de détection d’anomalies ou d’outliers lors du pré-traitement des données permet d’identifier et filtrer proactivement des points de données suspects avant l’apprentissage. Par exemple, des techniques d’estimation robuste ou de clustering peuvent signaler les exemples qui s’écartent statistiquement de la distribution normale. Bien qu’un attaquant puisse tenter de camoufler ses données empoisonnées pour les rendre “normales”, combiner plusieurs critères de détection (données trop bruyantes, données en double anormales, incohérences métadonnées, etc.) augmente les chances de les repérer. Je recommande d’automatiser autant que possible ces filtres d’assainissement, et de les appliquer non seulement une fois au départ, mais à chaque itération d’entraînement sur de nouvelles données.
Nettoyage et validation systématique des données : Lié au point précédent, il est crucial de sanitiser le dataset en appliquant des procédures de nettoyage rigoureuses. Cela peut inclure la suppression des duplicatas exacts ou quasi-duplicates (pour éviter qu’un attaquant noie le poison dans des répétitions), l’élimination des données manifestement erronées ou hors contexte, la normalisation des valeurs sur des plages attendues, etc. Un dataset de haute qualité, épuré de ses valeurs aberrantes, réduit la surface d’attaque disponible pour un empoisonnement. Je préconise de répéter ce nettoyage à chaque mise à jour du dataset (par exemple avant chaque nouvel entraînement ou affinement du modèle) afin d’éviter l’accumulation progressive d’éléments malveillants au fil du temps. Il est également pertinent de valider les données via un processus humain dans le cas de données critiques : par exemple, pour un ensemble relativement restreint, faire relire ou vérifier manuellement un échantillon des données par des experts peut détecter des anomalies subtiles qu’un algorithme ne verrait pas.
Sécurisation de la chaîne d’entraînement : Il convient de sécuriser les pipelines d’approvisionnement des données et d’entraînement pour empêcher un acteur malveillant d’y injecter des données ou d’altérer le modèle de l’extérieur. Concrètement, cela signifie restreindre l’accès aux dépôts de données brutes, journaliser toute modification apportée au corpus, protéger les scripts et environnements d’entraînement contre les modifications non autorisées (contrôle de version avec intégrité, signature du code d’entraînement, etc.). Je recommande de cloisonner le processus d’entraînement dans un environnement fortement contrôlé : par exemple, si on entraîne un modèle sur des données cloud, s’assurer que l’instance n’ait pas accès à Internet ou à d’autres services non nécessaires durant l’entraînement évitera qu’un attaquant ne puisse injecter de nouvelles données via une intrusion réseau. En somme, traiter l’entraînement d’un modèle sensible comme une opération critique à isoler (à l’image d’un build logiciel sécurisé) est une bonne pratique.
Ensembles de modèles et vérification croisée : Une approche pour atténuer l’effet des données empoisonnées est d’employer des méthodes d’ensemble ou d’apprentissage collaboratif faisant intervenir plusieurs modèles. L’idée est que si chaque modèle est entraîné sur un sous-ensemble différent des données ou avec des méthodes différentes, une donnée malveillante n’affectera potentiellement qu’une partie des modèles, et la prédiction finale combinée (par majorité ou autre agrégation) sera moins susceptible d’être incorrecte. Par exemple, face à un input, si un modèle isolé a été trompé par une donnée empoisonnée, mais que quatre autres modèles ne le sont pas, la moyenne ou le vote à la majorité des cinq modèles pourra corriger l’anomalie. Je conseille d’envisager ce type d’architecture redondante pour les applications critiques, d’autant que cela augmente également la résilience aux pannes et peut réduire les biais propres à un seul modèle. De même, en phase de validation, comparer les résultats de modèles entraînés avec des jeux de données légèrement différents peut aider à détecter qu’un jeu a pu être corrompu (si un modèle diverge fortement des autres, peut-être a-t-il ingéré un poison).
Anonymisation et limitation des informations sensibles : Pour réduire les impacts d’une éventuelle attaque d’inversion de modèle ou de fuite de données, il est avisé de retirer ou masquer autant que possible les données sensibles du corpus d’entraînement. J’entends par là que si certaines colonnes ou attributs ne sont pas indispensables à la tâche d’IA, il vaut mieux les exclure en amont (principe de minimisation). De plus, l’anonymisation des données personnelles avant entraînement (rendre impossible l’identification d’individus spécifiques) est non seulement une exigence légale dans certains cas, mais aussi une parade aux attaques qui viseraient à extraire ce type d’information du modèle. En procédant ainsi, même si un attaquant réussissait à soutirer des bribes de données du modèle, celles-ci ne compromettraient pas la vie privée ou la sécurité de personnes ou d’entités réelles.

En synthèse, les données malveillantes constituent une menace insidieuse car elles attaquent le système de l’intérieur, en exploitant sa dépendance fondamentale aux données. Je recommande une vigilance extrême sur la qualité des données d’entraînement, en combinant des contrôles automatisés et des audits manuels, afin de neutraliser autant que possible les tentatives d’empoisonnement. Il est également crucial de mettre en place une culture de tests de robustesse du modèle (attaques simulées, jeux de données adversariaux de test) pour évaluer la résistance du système et identifier d’éventuelles faiblesses avant qu’un adversaire réel ne les exploite. Enfin, la protection contre les données malveillantes doit être envisagée de façon complémentaire avec les mesures de sécurité plus larges : il ne sert à rien d’avoir un modèle bien entraîné sur des données saines si un attaquant peut ultérieurement lui fournir des entrées malveillantes faute de contrôle en production. Ainsi, une approche holistique intégrant sécurité des données et sécurité du système d’IA dans son ensemble est indispensable pour contrer ces risques.

Dérive des données : risques et parades

Relevant pour les phases : Déploiement & Utilisation; Exploitation & Surveillance.

La dérive des données – aussi appelée shift de distribution – correspond aux changements progressifs ou soudains dans les caractéristiques statistiques des données alimentant un système d’IA en production, par rapport aux données sur lesquelles le modèle a été initialement entraîné. En d’autres termes, au fil du temps, les données réelles peuvent devenir sensiblement différentes de l’ensemble de formation d’origine du modèle. Cette évolution naturelle peut s’expliquer par des changements dans le monde réel (nouvelles tendances, évolution du comportement des utilisateurs, modifications de procédures, etc.) et elle entraîne souvent une dégradation des performances du modèle si celui-ci n’est pas adapté en conséquence. La dérive des données est considérée comme un phénomène inévitable dans la durée de vie d’un système d’IA : aucun modèle n’est éternellement valable sans maintenance, car la réalité qu’il modélise finit par s’écarter de ce qu’il a appris.

Au début, la dérive des données peut provoquer de petites dégradations imperceptibles des performances du modèle. Si on ne fait rien, ces écarts s’accumulent et peuvent se traduire par des baisses significatives de précision ou d’utilité de l’IA. Par exemple, un modèle de détection de spam entraîné il y a deux ans pourrait voir sa précision chuter graduellement à mesure que de nouvelles techniques de spam apparaissent et que le langage employé évolue. Au bout d’un certain temps, le modèle devient obsolète et potentiellement inutilisable en l’état. Cette perte de performance due à la dérive n’est pas seulement un problème d’efficacité : elle peut aussi avoir des implications en matière de sécurité. En effet, un modèle “dégradé” peut commettre des erreurs risquées (p. ex. un faux négatif en cybersécurité, où le modèle laisse passer une attaque car le schéma de celle-ci n’était pas dans ses données d’entraînement dépassées).

Il est crucial de distinguer une dérive de données normale d’une attaque malveillante visant à altérer le modèle. La différence réside souvent dans la nature et la rapidité des changements observés. Si les changements dans les données ou le comportement du modèle sont lents et graduels, on a plus de chances d’avoir affaire à une dérive naturelle (évolution progressive du domaine d’application). En revanche, des changements brusques et drastiques peuvent indiquer une manipulation volontaire – par exemple, si du jour au lendemain les performances chutent lourdement sur un type de données, cela peut révéler qu’un acteur a tenté d’induire rapidement un dysfonctionnement (ce pourrait être le signe d’une attaque par empoisonnement ciblé). Les compromissions cyber cherchent en général un effet rapide et notable, tandis que la dérive est un glissement diffus. En pratique, les opérateurs de systèmes d’IA doivent surveiller attentivement les métriques de performance et investiguer tout changement de régime : une dégradation progressive appelera une réponse de maintenance (ré-entraînement, ajustement), tandis qu’une dégradation soudaine doit enclencher en plus une enquête de sécurité pour s’assurer qu’il n’y a pas eu d’attaque ou d’incident.

Pour gérer la dérive des données, je préconise une panoplie de techniques de détection et de mitigation à intégrer dans les processus MLOps :

Surveillance des données et des sorties du modèle : Il est indispensable de mettre en place une veille continue des entrées et des prédictions du modèle en production. Cela signifie mesurer régulièrement si les nouvelles données s’éloignent des distributions de référence. Par exemple, on peut calculer des statistiques (moyennes, écarts-types, distributions de catégories) sur les données entrantes et les comparer à celles du jeu d’entraînement original afin de détecter des écarts significatifs. De même, suivre des indicateurs de performance du modèle (taux d’erreur, confiance des prédictions, etc.) permet de repérer une dégradation progressive. Je conseille d’établir des seuils d’alerte : si le taux d’erreur dépasse un certain niveau ou si tel indicateur dérive de X%, une alerte est déclenchée pour examiner la cause. Cette surveillance doit être outillée et automatisée autant que possible, car la dérive peut survenir insidieusement au fil de milliers de prédictions. Des techniques statistiques (tests de Kolmogorov-Smirnov pour comparer des distributions, etc.) ou d’apprentissage automatique (détecteurs de drift) peuvent épauler cette tâche.
Gestion proactive des données et enrichissement : Pour retarder ou compenser la dérive, il convient d’augmenter la couverture des données utilisées pour entraîner le modèle. Cela implique, lors des phases initiales, d’essayer d’inclure un éventail le plus large possible de situations réelles dans le dataset d’entraînement. Cependant, il est impossible de tout prévoir à l’avance : ainsi, il faut régulièrement intégrer de nouvelles données représentatives des évolutions constatées. En pratique, cela se traduit par des ré-entraînements périodiques du modèle en y incorporant les données plus récentes (par exemple, chaque trimestre ou dès qu’un volume suffisant de nouvelles données pertinentes est accumulé). Une stratégie de gestion des données bien rodée facilitera cet enrichissement continu : on doit pouvoir ajouter de nouveaux échantillons, les étiqueter correctement, et les intégrer au pipeline sans tout recommencer de zéro. J’insiste également sur l’utilité des tests de qualité des données en continu : des outils peuvent évaluer si les nouvelles données sont complètes, valides et cohérentes, afin d’éviter d’incorporer des données bruitées ou erronées lors des mises à jour. En somme, un bon data management aide à identifier les éléments spécifiques causant la dérive et à y remédier rapidement (par exemple, constater qu’un nouveau type de cas apparaît fréquemment et décider d’entraîner le modèle pour le gérer).
Techniques de mitigation spécifiques : Selon la nature du système d’IA, on peut appliquer des méthodes particulières pour contrer la dérive. Par exemple, pour un modèle de détection d’anomalies en cybersécurité, on pourrait ajuster régulièrement les seuils ou les features en fonction des nouvelles menaces détectées. Pour un modèle de recommandation, on peut utiliser des algorithmes en ligne qui s’adaptent constamment aux dernières interactions des utilisateurs (apprentissage en continu). L’important est d’inclure dès la conception des mécanismes d’adaptation : ainsi, le système est pensé pour évoluer. L’utilisation de modèles d’ensemble peut également aider face à la dérive : combiner plusieurs modèles entraînés à différentes époques (ex : un modèle initial et un modèle affiné sur les données des 3 derniers mois) peut améliorer la robustesse globale, chaque modèle couvrant une partie de la distribution. Enfin, mettre en place une boucle de rétroaction avec les utilisateurs ou avec des experts peut permettre de signaler rapidement si les résultats deviennent moins pertinents, ce qui sert de déclencheur à une action corrective.

Malgré les outils existants, la gestion de la dérive des données reste un domaine actif de recherche et d’innovation. Il n’existe pas de solution universelle, car les causes de dérive peuvent être multiples : cela va d’un changement subtil dans un format de log informatique jusqu’à un événement majeur modifiant complètement la nature du problème (par ex., un changement réglementaire, ou l’apparition d’un nouveau type de malware inédit qui prend de court un modèle de détection). Je conseille donc aux organisations d’adopter une approche multi-facettes, alliant surveillance, maintenance et agilité.

Il faut intégrer dès le départ l’éventualité de devoir mettre à jour le modèle régulièrement, prévoir des ressources pour cela, et éventuellement recourir à des solutions de “retraining continu” pour les applications critiques (par ex. en médecine, où la dérive peut avoir des conséquences graves, une surveillance extrêmement rapprochée s’impose). L’implémentation d’un cadre de gestion des données évolutif dès la conception – incluant le monitoring, la mise à jour régulière, le nettoyage et la combinaison de modèles – est essentielle pour maintenir l’intégrité et la sécurité globales des systèmes d’IA sur le long terme.

Ma conclusion et les implications stratégiques associées

La sécurité des données dans les systèmes d’IA n’est pas un luxe optionnel réservé aux seuls contextes classifiés : c’est un impératif stratégique pour toute organisation qui mise sur l’IA dans ses opérations critiques. Au fil de cet article, j’ai démontré que la sécurité des données doit être envisagée de manière holistique, englobant tout le cycle de vie de l’IA, depuis la conception jusqu’à l’exploitation continue. Les bonnes pratiques présentées – de la traçabilité des données sources au chiffrement, en passant par la classification, l’infrastructure de confiance, la suppression sécurisée, etc. – constituent un socle sur lequel bâtir des systèmes d’IA robustes et dignes de confiance. De même, l’analyse des risques majeurs liés aux données (chaîne d’approvisionnement, empoisonnement, dérive) met en lumière des vecteurs d’attaque souvent méconnus du grand public, mais que les experts doivent anticiper et contrer activement.

Je conclus que les organisations ont tout intérêt à investir dans la sécurisation de leurs données d’IA pour plusieurs raisons stratégiques. D’une part, la fiabilité et la qualité des décisions prises par l’IA – qu’il s’agisse de détection d’intrusion, de diagnostic médical ou de conduite autonome – dépendent directement de la qualité des données ingérées. Toute compromission à ce niveau peut se traduire par des erreurs coûteuses, des atteintes à la sécurité physique ou juridique, et une perte de confiance des utilisateurs. D’autre part, les obligations réglementaires autour des données se renforcent (lois sur la protection des données personnelles, exigences sectorielles sur la gouvernance des modèles d’IA, etc.) : une mauvaise gestion des données peut mettre l’organisation en défaut de conformité, avec des conséquences légales et d’image. À l’inverse, maîtriser sa gouvernance des données d’IA confère un avantage concurrentiel : cela permet d’adopter plus rapidement de nouveaux cas d’usage en sachant gérer les risques, de collaborer de manière sécurisée avec des partenaires (échange de données sûres), et de présenter aux parties prenantes (clients, autorités) des garanties solides sur la fiabilité de ses systèmes d’intelligence artificielle.

Sur le plan opérationnel, intégrer la sécurité des données dans le cycle de vie de l’IA signifie qu’il faut fédérer des compétences pluridisciplinaires : experts IA, experts cybersécurité, data engineers, juristes (pour les aspects conformité), doivent collaborer étroitement. J’estime qu’il est du ressort des décideurs de créer cette synergie en interne, par exemple en formant des comités de gouvernance de l’IA où la question des données est centrale, ou en nommant des responsables dédiés (tels que des AI data stewards ou équivalent du Data Protection Officer spécialisé IA). Ce n’est qu’en adoptant une démarche coordonnée que les principes évoqués dans ce document pourront effectivement se traduire en pratiques quotidiennes.

Enfin, il convient de rester agile et proactif face à l’évolution des menaces. Les attaquants innovent, tout comme les jeux de données et les usages de l’IA évoluent. Les agences de sécurité informatique et les chercheurs continueront de publier des recommandations actualisées, et il appartient aux organisations de les suivre et de les implémenter. Les principes exposés dans cet article fournissent une base robuste pour sécuriser les données d’IA et assurer la fiabilité des résultats produits, mais ils doivent s’inscrire dans un cycle d’amélioration continue.

En adoptant dès aujourd’hui ces bonnes pratiques et en restant vigilants, les concepteurs et exploitants de systèmes d’IA pourront inspirer confiance à leurs utilisateurs, protéger leurs actifs informationnels, et exploiter pleinement le potentiel de l’intelligence artificielle sans compromettre la sécurité ni les valeurs de l’organisation.

Enjoy !

Sources

https://media.defense.gov/2025/May/22/2003720601/-1/-1/0/CSI_AI_DATA_SECURITY.PDF – AI Data Security: Best Practices for Securing Data Used to Train & Operate AI Systems, fiche d’information cybersécurité conjointe NSA/CISA/FBI/ASD/NCSC-NZ/NCSC-UK, Mai 2025.
https://www.cisa.gov/news-events/cybersecurity-advisories/aa25-142a – Annonce CISA (Cybersecurity Advisory AA25-142A) présentant la publication du guide “AI Data Security: Best Practices…”, 22 mai 2025.
https://doi.org/10.6028/NIST.AI.100-1 – NIST AI Risk Management Framework (AI RMF 1.0), National Institute of Standards and Technology, Janvier 2023.
https://doi.org/10.6028/NIST.SP.800-88r1 – NIST Special Publication 800-88 Rev.1: Guidelines for Media Sanitization, National Institute of Standards and Technology, 2014.
https://csrc.nist.gov/publications/detail/sp/800-53/rev-5/final – NIST SP 800-53 Rev.5: Security and Privacy Controls for Information Systems and Organizations, National Institute of Standards and Technology, 2020.

Conformité et Normes