Cybersécurité de l’IA : prévenir empoisonnement, extraction et évasion

Un système d’intelligence artificielle ne se résume pas à l’interface que voit son utilisateur. Derrière une réponse textuelle, une image reconnue ou une alerte automatisée se trouvent des données, une capacité de calcul, un modèle, des logiciels et souvent des connexions avec d’autres outils. Chacun de ces éléments peut constituer une porte d’entrée pour un attaquant.

La cybersécurité de l’IA ne consiste donc pas seulement à empêcher l’accès non autorisé à un serveur. Il faut aussi s’assurer que le modèle a appris à partir de données fiables, qu’il ne dévoile pas des informations qu’il devrait conserver et qu’il ne peut pas être induit en erreur au moment où il est utilisé. Les risques d’empoisonnement, d’extraction et d’évasion recouvrent ces trois moments distincts.

Trois familles d’attaques à distinguer

Ces menaces n’ont ni le même objectif ni le même point d’entrée. Les comprendre permet d’éviter une erreur fréquente : appliquer la même protection à des problèmes qui se produisent à des étapes différentes de la vie d’un système.

Dans la pratique, ces risques peuvent se cumuler. Un acteur malveillant peut chercher à compromettre la qualité d’un jeu de données, puis à tirer parti des faiblesses d’un modèle en production. La réponse ne peut donc pas se limiter à un contrôle unique : elle doit couvrir l’ensemble de la chaîne.

L’empoisonnement des données agit avant la mise en service

L’attaque par empoisonnement consiste à altérer les données utilisées pour entraîner un modèle. L’objectif est de déformer son apprentissage afin qu’il fournisse ensuite des résultats incorrects. Le danger tient à son caractère discret : si les données compromises ne sont pas identifiées, le problème peut se retrouver intégré au comportement du système.

Ce risque concerne particulièrement les applications dont les réponses dépendent directement de la qualité et de la diversité des données d’entrée, notamment la reconnaissance d’images et le traitement du langage naturel. Dans ces domaines, le modèle apprend des régularités à partir de très grands ensembles d’exemples. Des données inexactes, manipulées ou introduites sans contrôle peuvent modifier ces régularités.

La première ligne de défense est donc la gouvernance des données. Une organisation doit savoir d’où proviennent ses jeux de données, qui peut les modifier, selon quelles règles ils ont été constitués et quelles vérifications ont été réalisées avant leur emploi. Cette traçabilité est aussi importante pour des données collectées en interne que pour des corpus fournis par un partenaire.

Valider les données en entrée ne signifie pas seulement rechercher des fichiers défectueux. Il s’agit d’examiner leur cohérence, leur pertinence par rapport à l’usage prévu et les modifications successives qu’elles ont subies. Des audits réguliers des jeux d’entraînement, associés à une surveillance des comportements inhabituels du modèle, aident à repérer une dégradation avant qu’elle ne se propage dans les usages.

L’extraction menace la confidentialité des modèles et des données

Une attaque par extraction vise à reconstruire ou récupérer des informations qu’un système d’IA ne devrait pas révéler. Cela peut concerner les paramètres d’un modèle ou des données utilisées au cours de son apprentissage. Pour une organisation, l’enjeu dépasse la seule propriété intellectuelle : une extraction peut également mettre en cause la confidentialité de données sensibles et la protection des données personnelles.

Un modèle est souvent considéré comme un actif technique difficile à copier. Cette perception ne doit pas faire oublier qu’une interface d’accès peut elle-même donner de nombreux signaux sur son fonctionnement. Lorsque les requêtes et les réponses sont exploitées de manière répétée, elles peuvent renseigner un attaquant sur les capacités du système et sur les informations qu’il est susceptible d’exposer.

La protection passe notamment par une gestion rigoureuse des accès et par une limitation de ce que chaque utilisateur ou application peut consulter. Les échanges avec le modèle doivent aussi être surveillés afin de détecter des usages anormaux, par exemple des séries de sollicitations inhabituelles. Il importe enfin de séparer autant que possible les informations sensibles des mécanismes qui n’ont pas besoin de les traiter.

La question à poser n’est pas uniquement « qui peut utiliser le modèle ? ». Elle est aussi : « quelles informations ce modèle, ses interfaces et les outils connectés peuvent-ils révéler ? ». Cette approche élargit la sécurité à tout le parcours des données.

L’évasion cherche à tromper le système au moment de la décision

Dans une attaque par évasion, l’attaquant ne modifie pas nécessairement le modèle ni ses données d’apprentissage. Il prépare plutôt une entrée conçue pour détourner le résultat attendu. Le principe est simple à énoncer, mais difficile à traiter : une légère manipulation d’un signal peut suffire à faire échouer une détection ou à orienter une réponse dans un sens imprévu.

Le risque est particulièrement sérieux quand l’IA intervient dans des contextes où une mauvaise classification ou une absence de détection peut avoir des conséquences importantes, comme la sécurité des infrastructures. Un système ne doit pas être évalué uniquement sur ses performances dans des conditions normales. Il doit aussi être testé face à des données ambiguës, inattendues ou volontairement manipulées.

Pour les modèles de langage, l’injection de prompts illustre cette difficulté. Des instructions malveillantes peuvent être glissées dans des sources externes consultées par le système, dans le but d’influencer sa réponse ou de contourner son comportement prévu. Ces attaques sont complexes parce qu’un modèle de langage traite des instructions et du contenu dans le même format : du texte.

La prudence consiste à ne pas accorder automatiquement à l’IA une autonomie trop large lorsqu’elle lit des contenus externes ou agit sur d’autres systèmes. Les actions sensibles doivent être encadrées, vérifiées et proportionnées au niveau de risque identifié.

La chaîne d’approvisionnement de l’IA doit être cartographiée

La chaîne d’approvisionnement de l’IA repose sur trois piliers principaux : la capacité de calcul, les modèles d’IA et les données. Ils peuvent sembler distincts, mais ils sont interdépendants. Une faiblesse chez un fournisseur, dans une ressource informatique, dans un modèle réutilisé ou dans un ensemble de données peut exposer l’ensemble du système.

Cartographier cette chaîne revient à établir une vue concrète des dépendances : quels modèles sont employés, quelles données les alimentent, quels outils les relient, quels prestataires interviennent et quels systèmes internes reçoivent les résultats. Sans cette visibilité, il est difficile d’identifier les chemins qu’un attaquant pourrait emprunter.

Cette cartographie doit aussi tenir compte des interconnexions. Une IA connectée à d’autres réseaux, applications ou sources de données dispose de nouvelles capacités, mais elle ouvre aussi de nouveaux vecteurs d’attaque. Une source externe, un connecteur ou une interface mal sécurisée peut devenir le point faible d’un dispositif pourtant robuste pris isolément.

L’évaluation des fournisseurs est donc une composante de la défense. Des audits, des évaluations de sécurité et des exigences définies dans les contrats peuvent aider à vérifier que les partenaires appliquent un niveau de protection cohérent avec la sensibilité du projet. L’enjeu est de ne pas confondre confiance commerciale et maîtrise effective du risque.

Les failles humaines et organisationnelles restent déterminantes

Les protections techniques sont indispensables, mais elles ne compensent pas une organisation qui ne sait pas quels systèmes d’IA elle utilise ni dans quelles conditions. Le manque de formation peut favoriser une confiance excessive dans l’automatisation. Des opérateurs trop confiants risquent de moins remettre en cause un comportement anormal ou un résultat surprenant.

Le phénomène d’IA « shadow » aggrave cette situation. Il désigne l’usage, au sein d’une organisation, de systèmes d’IA qui ne sont pas régulés ou ne sont pas connus des équipes chargées de la sécurité. Une équipe peut alors transmettre des informations à un outil sans que ses règles d’accès, ses connexions ou son traitement des données aient été évalués.

La sensibilisation doit viser les utilisateurs, les équipes techniques et les décideurs. Les premiers doivent pouvoir reconnaître les comportements suspects et savoir quand ne pas déléguer une action à un outil. Les équipes techniques doivent intégrer les risques dès la conception et le déploiement. Quant aux décideurs, ils doivent fixer un cadre d’usage, définir le niveau d’autonomie acceptable et allouer les moyens nécessaires au suivi.

Construire une défense adaptée au niveau de risque

Il n’existe pas de mesure unique capable d’éliminer les risques liés à l’IA. Une démarche solide combine plusieurs protections, ajustées à la finalité du système et à la gravité d’une erreur éventuelle. Une IA qui assiste une tâche peu sensible ne requiert pas le même encadrement qu’un outil connecté à des systèmes critiques ou traitant des informations confidentielles.

Une organisation peut structurer sa démarche autour de plusieurs priorités :

• Adapter l’autonomie de l’IA à l’analyse de risques : plus une action est sensible, plus l’intervention humaine et les contrôles doivent être importants.
• Contrôler les données avant l’entraînement et au fil de leurs mises à jour, en assurant leur traçabilité et en organisant des audits réguliers.
• Cartographier les dépendances entre calcul, modèles, données, fournisseurs, interfaces et systèmes connectés.
• Surveiller en continu les performances du modèle, les accès, les requêtes inhabituelles et les résultats anormaux.
• Former les équipes aux attaques propres à l’IA, aux règles de manipulation des données et aux procédures de signalement.

Cette approche doit être révisée au fil des évolutions technologiques. Les modèles changent, les usages s’étendent et de nouvelles interconnexions sont ajoutées. Une politique de sécurité efficace n’est donc pas un document figé : elle repose sur une vigilance continue, des contrôles réguliers et une capacité à corriger rapidement un dispositif lorsque le contexte évolue.

Ce qu’il faut surveiller

En février 2025, l’adoption de l’IA conduit de nombreuses organisations à connecter des modèles à davantage de données, de documents et d’outils métier. Cette extension augmente l’utilité des systèmes, mais elle élargit aussi leur surface d’attaque. La question centrale n’est plus seulement de savoir si un modèle produit une réponse convaincante : il faut également déterminer quelles données il reçoit, quelles décisions il peut influencer et quelles actions il est autorisé à déclencher.

Les attaques par empoisonnement, extraction et évasion rappellent que la sécurité de l’IA commence avant le premier prompt et continue après chaque mise à jour. La capacité à inventorier les dépendances, détecter les anomalies, contrôler l’autonomie et responsabiliser les équipes sera déterminante pour utiliser ces systèmes sans transformer l’innovation en angle mort de cybersécurité.