Sécurité de l’IA : anticiper les attaques grâce à l’intelligence adverse

Les systèmes d’intelligence artificielle sont devenus des outils de travail, d’analyse et d’automatisation pour un nombre croissant d’organisations. Ils constituent aussi une nouvelle cible. Un attaquant ne cherche plus seulement à forcer l’entrée d’un réseau : il peut tenter de manipuler les données qui alimentent un modèle, de contourner ses garde-fous ou d’utiliser ses accès à des services internes. Face à cette évolution, la modélisation de l’intelligence adverse offre une idée simple : anticiper les raisonnements et les méthodes d’un adversaire pour corriger les fragilités avant qu’elles ne soient exploitées.

Au 30 janvier 2025, cette démarche ne désigne pas une technologie unique ni une promesse de protection totale. Elle rassemble des pratiques de cybersécurité bien établies, comme l’analyse de menaces, les tests de sécurité et la surveillance des anomalies, appliquées aux particularités de l’IA. Son intérêt est de passer d’une défense réactive à une défense qui se prépare aux scénarios les plus plausibles.

Qu’est-ce que la modélisation de l’intelligence adverse ?

L’expression recouvre deux réalités proches, mais qu’il faut distinguer. La première relève du renseignement et de la modélisation des menaces : une organisation étudie ce qu’un attaquant pourrait viser, les accès dont il pourrait disposer, les erreurs qu’il pourrait exploiter et les conséquences de son action. La seconde concerne les attaques dites adversariales contre les systèmes d’apprentissage automatique, c’est-à-dire des tentatives destinées à tromper, détourner ou dégrader un modèle.

Dans les deux cas, il ne s’agit pas d’attendre une attaque réelle. Les équipes de sécurité construisent des scénarios contrôlés : un compte utilisateur compromis, un document malveillant traité par un assistant, une donnée erronée intégrée à un jeu d’entraînement, ou encore un service externe devenu indisponible. Elles vérifient ensuite si les protections détectent le problème, empêchent une action risquée et permettent de rétablir le service.

Cette logique est proche de celle des exercices de sécurité traditionnels. La différence est qu’un système d’IA introduit des éléments supplémentaires : il dépend de données, produit des réponses probabilistes et peut être relié à des outils, des bases documentaires ou des logiciels métiers. Une erreur n’est donc pas toujours une intrusion visible. Elle peut prendre la forme d’une recommandation fausse, d’une fuite d’information dans une réponse ou d’une automatisation déclenchée à tort.

Quelles vulnérabilités les systèmes d’IA peuvent-ils exposer ?

Les attaques contre un système d’IA ne se limitent pas au modèle lui-même. Elles peuvent viser toute la chaîne technique et humaine : les données, les comptes, les applications qui intègrent le modèle et l’infrastructure sur laquelle elles reposent. Cette vision globale est indispensable, car une solution très performante peut demeurer vulnérable si ses droits d’accès sont trop larges ou si ses données sont mal protégées.

Pour le grand public comme pour les entreprises, le risque le plus visible reste souvent la compromission de données. Un assistant relié à des documents internes peut par exemple devenir une porte de sortie involontaire si les droits d’accès ne sont pas strictement séparés entre utilisateurs. À l’inverse, un système connecté à un outil métier peut être amené à réaliser une opération inappropriée s’il reçoit une instruction trompeuse et ne dispose pas de garde-fous suffisants.

Les rançongiciels, ou ransomware, illustrent également le fait que l’IA s’insère dans une menace plus large. Un attaquant peut viser les systèmes d’information classiques d’une organisation, puis perturber les services d’IA qui dépendent de ces systèmes. Protéger l’IA ne consiste donc pas à isoler un modèle dans l’abstrait : cela suppose aussi de sécuriser le réseau, les identités numériques, les sauvegardes et les procédures de réponse à incident.

Trois questions à poser avant de déployer une IA

Une analyse utile commence par des interrogations concrètes. Elles évitent de réduire la cybersécurité à un simple outil de détection.

1. Que cherche à protéger l’organisation ?

La réponse ne se limite pas au code du modèle. Il faut identifier les données personnelles, les informations commerciales, les secrets industriels, les services essentiels et les décisions qui pourraient être affectés. Plus l’IA intervient dans un processus sensible, plus il importe de déterminer ce qu’elle est autorisée à consulter, à recommander ou à exécuter.

2. Qui pourrait tenter de nuire, et par quel accès ?

Tous les adversaires n’ont ni les mêmes objectifs ni les mêmes moyens. Un cybercriminel peut rechercher un gain financier, notamment par l’extorsion. Un individu malveillant peut vouloir perturber un service. Un prestataire, un utilisateur ou un collaborateur peut aussi provoquer un incident par erreur. Modéliser ces profils aide à prioriser les protections réalistes, plutôt qu’à vouloir parer indistinctement toutes les hypothèses.

3. Comment saura-t-on qu’une défense fonctionne ?

Une règle de sécurité n’est utile que si elle est vérifiée. Des exercices encadrés peuvent mesurer la capacité à détecter une anomalie, à limiter les droits d’un compte compromis, à préserver les données et à restaurer un service. Après chaque test ou incident, les équipes doivent analyser ce qui a fonctionné, ce qui a échoué et les correctifs à apporter.

L’IA peut-elle réellement renforcer la cybersécurité ?

Oui, l’IA peut assister les défenseurs, notamment lorsqu’il faut examiner un volume considérable de journaux techniques, d’alertes et d’événements réseau. Des systèmes de détection peuvent repérer des comportements inhabituels : connexion à un horaire inattendu, transfert de données anormal, multiplication de requêtes ou changement brutal dans l’utilisation d’un compte. L’apprentissage automatique peut aider à faire ressortir les signaux qui méritent une investigation humaine.

Elle peut également rendre les simulations plus adaptatives. Au lieu de vérifier toujours le même scénario, des outils peuvent varier les cas testés et aider à cartographier les chemins par lesquels un incident pourrait se propager. Cette approche est particulièrement intéressante pour des environnements complexes, composés de nombreux services et fournisseurs.

Il serait toutefois imprudent de présenter l’IA comme une réponse autonome aux cyberattaques. Un modèle peut se tromper, produire des faux positifs ou manquer un signal important. Il peut aussi être lui-même ciblé. Une alerte automatisée n’a de valeur que si des personnes compétentes peuvent l’interpréter, décider d’une réponse proportionnée et en assumer la responsabilité.

Des défenses techniques, mais aussi organisationnelles

La meilleure modélisation adverse ne compense pas l’absence de bases de sécurité. Avant d’ajouter des outils sophistiqués, une organisation doit savoir où sont ses données, quels systèmes sont exposés et qui possède des droits d’administration. Les mises à jour régulières, l’authentification forte, la segmentation des environnements et des sauvegardes testées restent des protections essentielles.

Pour une application d’IA, cette discipline se traduit notamment par les pratiques suivantes :

• limiter les données envoyées au système au strict nécessaire ;
• attribuer à chaque utilisateur et à chaque connecteur des autorisations minimales ;
• isoler les environnements de développement, de test et de production ;
• journaliser les actions importantes afin de pouvoir comprendre un incident ;
• prévoir une validation humaine pour les décisions sensibles ou irréversibles ;
• réexaminer régulièrement les fournisseurs et composants dont dépend le service.

La formation joue aussi un rôle déterminant. Un salarié qui transmet des informations confidentielles à un outil non approuvé, ou qui accorde trop rapidement des droits à une application, peut involontairement créer une vulnérabilité. À l’inverse, des règles compréhensibles et des outils validés réduisent la tentation de contourner les procédures.

NIS2 : pourquoi la réglementation place la gestion des risques au premier plan

Dans l’Union européenne, la directive NIS2 renforce les exigences de cybersécurité applicables aux entités concernées dans des secteurs jugés essentiels ou importants. Elle met l’accent sur la gestion des risques, la sécurité de la chaîne d’approvisionnement, la continuité d’activité, la gestion des incidents et la responsabilité de la direction.

La directive prévoit également une procédure de notification graduée des incidents significatifs : une alerte précoce intervient en principe dans les 24 heures, une notification d’incident dans les 72 heures, puis un rapport final dans le mois qui suit. Les modalités concrètes dépendent toutefois de la transposition nationale et de la situation de chaque organisation.

L’intelligence artificielle n’efface pas ces obligations, elle peut les rendre plus exigeantes. Lorsqu’une entreprise utilise un modèle pour traiter des données ou soutenir une activité critique, elle doit intégrer cet outil à son dispositif de gestion des risques. Cela implique de documenter les usages, de connaître les dépendances techniques et de pouvoir démontrer que des mesures de protection ont été envisagées.

Coopérer sans perdre le contrôle de l’outil

Les cybermenaces dépassent les frontières et les secteurs. Les méthodes observées dans une entreprise peuvent réapparaître chez un fournisseur, dans un service public ou sur une plateforme utilisée par des millions de personnes. Le partage d’informations entre professionnels, les référentiels communs et la coopération entre chercheurs, éditeurs et autorités contribuent à réduire ce délai d’apprentissage collectif.

Cette coopération doit néanmoins respecter une limite fondamentale : rendre publiques des vulnérabilités sans précaution peut exposer les utilisateurs avant qu’un correctif soit disponible. La divulgation responsable vise justement à permettre aux organisations concernées d’analyser et de corriger une faille, tout en informant les utilisateurs de façon proportionnée.

Les enjeux éthiques sont tout aussi concrets. Un système conçu pour simuler un adversaire doit rester sous contrôle, être utilisé dans un périmètre autorisé et ne pas devenir lui-même un instrument d’intrusion. L’objectif n’est pas de donner davantage de puissance à l’attaque, mais d’améliorer la résilience collective.

Ce qu’il faut surveiller

La prochaine génération d’outils de cybersécurité intégrera vraisemblablement davantage d’agents capables d’analyser des alertes, de proposer des scénarios de défense et d’apprendre de simulations. Leur intérêt dépendra moins de leur apparente autonomie que de la qualité des données, des droits qui leur sont accordés et du contrôle exercé par les équipes humaines.

Pour les organisations, la priorité est claire : considérer la sécurité comme une condition du déploiement de l’IA, non comme un ajout tardif. Identifier les actifs sensibles, tester les scénarios d’attaque autorisés, corriger les failles et préparer la réponse à incident permettent de transformer l’intelligence adverse en outil de prévention. Dans un environnement où les attaquants comme les défenseurs adoptent l’IA, cette préparation constitue un avantage décisif.