Dans l’ensemble des déploiements d’IA que j’ai examinés dans divers secteurs, un schéma récurrent se dégage : les organisations cherchent le risque au mauvais endroit. Leur attention se porte généralement sur le modèle lui-même, y compris ses données d’entraînement, ses contrôles de sécurité et son comportement. Mais en pratique, c’est rarement là que les défaillances surviennent.
Un grand nombre des vulnérabilités à plus fort impact apparaissent dans le système environnant — dans la manière dont les prompts sont construits, dont les données externes sont sourcées et jugées fiables, dans ce à quoi le modèle est autorisé à accéder et sous quelles identités il opère. C’est là que les systèmes d’IA sont le plus souvent exposés : dans les points de jonction entre les composants, là où la gouvernance est généralement la plus faible.
Le problème plus profond réside dans l’écart entre attentes et réalité. Les organisations anticipent un type de défaillance, mais les systèmes en production échouent de façons complètement différentes. Le risque émerge dans ce décalage — dans des hypothèses qui ne résistent ni à l’échelle, ni à l’autonomie, ni à l’intégration.
Les mêmes idées reçues sur la sécurisation de l’IA reviennent sans cesse. Il vaut la peine d’examiner les cinq plus importantes.
- À LIRE AUSSI → La confiance à la vitesse de l’IA : construire une stratégie de cybersécurité pour l’IA
Idée reçue n°1 : si le modèle est sécurisé, le système est sécurisé
C’est l’erreur la plus fréquente que je constate, et elle est facile à commettre. Le modèle paraît nouveau, donc les équipes se concentrent sur les garde-fous et les tests, puis supposent que le travail est terminé.
Mais ce n’est pas ainsi que ces systèmes échouent. Le modèle n’est qu’un composant d’une infrastructure beaucoup plus vaste, et la plupart des défaillances se produisent là où il se connecte aux données, aux outils et à d’autres systèmes. Se concentrer uniquement sur le modèle revient à installer une porte haute sécurité dans un bâtiment sans murs.
Comment y remédier : pour sécuriser un système d’IA, considérez l’ensemble de l’environnement comme surface d’attaque. Cartographiez l’intégralité des flux de données — des entrées à la récupération et à la mémoire, et des outils aux sorties — et gouvernez les prompts, agents, bases vectorielles, identités et connecteurs comme des actifs à part entière, avec des points de contrôle clairs, des responsabilités définies et des politiques, comme pour tout autre système critique.
Idée reçue n°2 : l’injection de prompt n’est qu’un autre problème d’entrée
Les équipes de sécurité issues du web ont souvent recours à des outils familiers lorsqu’elles rencontrent un nouveau problème. Lorsqu’il s’agit de sécuriser l’IA, cet instinct peut les conduire dans la mauvaise direction.
L’injection de prompt ressemble à l’injection SQL — où les systèmes traitent une entrée malveillante comme une commande — mais se comporte très différemment.
Les logiciels traditionnels peuvent imposer une séparation claire entre instructions et données. Les grands modèles de langage ne peuvent pas le faire de manière fiable. Ils traitent instructions et données comme un même flux de texte et portent des jugements probabilistes pour distinguer l’un de l’autre.
Le National Cyber Security Centre (NCSC) du Royaume-Uni est clair sur ce point : l’injection de prompt est structurellement différente de l’injection SQL et doit être abordée différemment.
Comment y remédier : les filtres et détecteurs aident, mais ne résolvent pas le problème à eux seuls. Les mesures les plus efficaces sont d’ordre architectural. Limitez l’accès aux outils, appliquez le principe du moindre privilège, isolez les contenus non fiables et validez de manière déterministe les appels d’outils et leurs paramètres. Exigez une approbation explicite pour les actions sensibles, exécutez en environnement isolé (sandbox) et surveillez de manière rigoureuse. Ces mesures réduisent à la fois la probabilité et l’impact d’une compromission, mais n’éliminent pas le risque. Si le risque résiduel reste inacceptable, le cas d’usage n’est pas adapté à un grand modèle de langage.
Idée reçue n°3 : les sorties de l’IA ne sont que du texte — elles ne créent pas de risque réel
Les premiers déploiements d’IA valorisaient l’autonomie. Cette approche a été transposée dans des environnements de production où elle n’est pas appropriée.
Les sorties de l’IA peuvent sembler être du texte inoffensif, mais elles le restent rarement. Dès qu’elles sont transmises à un autre système, elles peuvent entraîner des actions réelles — envoi d’e-mails, interrogation de bases de données, exécution de code ou suppression d’un enregistrement. Dans ce contexte, une injection de prompt réussie hérite de toutes les capacités du système.
C’est là que le risque devient réel : les capacités du système deviennent celles de l’attaquant.
L’Open Web Application Security Project identifie l’agence excessive comme l’un des risques les plus graves dans l’IA agentique, tandis que le NCSC souligne que c’est précisément à ce moment que l’injection de prompt cesse d’être une nuisance et devient une violation.
Comment y remédier : c’est simple : limitez ce que le système peut faire, appliquez le principe du moindre privilège et considérez les sorties du modèle comme non fiables tant qu’elles n’ont pas été validées de manière déterministe à la frontière d’exécution. Cela ne rendra pas un agent compromis inoffensif, mais réduira considérablement le périmètre d’impact.
Idée reçue n°4 : l’utilisation de données externes rend l’IA plus fiable et plus sûre
La génération augmentée par récupération (RAG), où les modèles s’appuient sur des données externes, améliore la précision mais ne rend pas les systèmes plus sûrs. Des recherches publiées par USENIX montrent que corrompre un petit nombre d’entrées dans une base de connaissances suffit à manipuler de manière fiable les sorties RAG à grande échelle.
Chaque source de données connectée devient un point d’entrée potentiel. Si ces données ne sont pas fiables, sont obsolètes ou manipulées, elles peuvent influencer la sortie du modèle de manière difficile à détecter.
Comment y remédier : il s’agit à la fois d’un problème de modèle et d’un problème de données et de chaîne d’approvisionnement. Traitez les sources externes comme des dépendances nécessitant une gouvernance. Appliquez des contrôles sur la provenance, la validation, les accès en écriture, l’analyse lors de l’ingestion, le versioning, la séparation des sources et la gestion des changements.
Idée reçue n°5 : une IA managée signifie que le fournisseur gère la sécurité
On confond souvent services managés et sécurité externalisée. En réalité, la responsabilité est partagée, mais les responsabilités du client en matière de sécurité restent importantes.
Le fournisseur sécurise le service lui-même. Vous êtes responsable de tout ce qui l’entoure : les données qui y entrent, les accès, ce que le modèle est autorisé à faire et la manière dont les sorties sont utilisées.
Comment y remédier : soyez explicite sur ce qui relève de votre responsabilité, cartographiez clairement la responsabilité partagée et ne supposez pas que c’est sécurisé parce que c’est managé. Examinez les contrôles du fournisseur, puis comblez vous-même les lacunes en matière d’identités, de gestion des données, de configuration, de surveillance et de sécurité des intégrations.
Ce que chaque déploiement devrait inclure
La plupart des organisations que j’évalue peuvent lister les solutions d’IA qu’elles ont déployées. Beaucoup moins sont capables de dire qui en est responsable, quelles données elles utilisent, ce qu’elles peuvent faire ou ce qui se passe en cas de défaillance. Cela met en évidence un problème de gouvernance.
Les fondations ne sont pas particulièrement complexes ; elles sont simplement appliquées de manière inégale.
Au minimum, vous devriez disposer de :
- Une posture de sécurité de l’IA claire, approuvée au niveau exécutif, et d’un appétit pour le risque défini, aligné sur des cas d’usage spécifiques et des types de données
- Un inventaire complet de vos actifs d’IA (modèles, prompts, agents, ensembles de données, bases vectorielles, connecteurs, comptes de service et plugins), avec des responsables identifiés
- Des modèles de menace définissant les frontières de confiance et appliquant des politiques à des points de contrôle prévisibles
- Des contrôles d’intégrité robustes sur l’ensemble de votre chaîne d’approvisionnement et de votre pipeline de données, y compris la provenance, la signature, l’analyse, la traçabilité, le versioning et, le cas échéant, des registres gérés
- Un accès aux outils basé sur le principe du moindre privilège pour les agents, avec une supervision humaine pour les actions à fort impact
- Des couches de validation des sorties avant toute exécution, écriture ou exposition aux utilisateurs
- Une évaluation et une surveillance continues intégrées à la gestion des changements
- Des procédures d’incident testées en conditions réelles, incluant des scénarios de confinement, de désactivation sécurisée et de retour arrière
Mettre ces éléments en place revient à appliquer la même discipline d’ingénierie que celle attendue pour tout système critique.
Conclusion sur la sécurité de l’IA
La sécurité de l’IA va au-delà de la simple sécurisation des systèmes ou des modèles. Le reconnaître tôt vous placera en avance sur ceux qui ne l’apprennent qu’après une défaillance.
Ce n’est pas un exercice ponctuel. Les systèmes d’IA évoluent en permanence, et la sécurité doit suivre. Cela implique des tests continus, y compris du red teaming — tenter délibérément de compromettre le système pour en comprendre les faiblesses.
Et si vous n’êtes pas en mesure d’évaluer clairement votre exposition à travers les modèles, les intégrations, les pipelines de données et les agents, cette incertitude fait elle-même partie du risque.