Protéger un système ou protéger un modèle : deux objets différents
La cybersécurité vise l'infrastructure : serveurs, réseaux, comptes, logiciels, terminaux. Elle répond à des questions éprouvées — qui accède à quoi, comment détecter une intrusion, comment résister à une attaque par déni de service, comment reprendre l'activité après un incident. La sécurité de l'IA déplace le regard ailleurs : vers le modèle lui-même et vers ses données d'entraînement. Sont-ils fiables, manipulables, détournés de leur usage prévu ? Un pare-feu correctement configuré ne dit rien de la qualité d'une prédiction, ni de la façon dont un agent interprétera une instruction ambiguë glissée dans un document qu'il consulte. Ce sont deux objets techniques, et à bien des égards deux métiers.
La distinction n'a rien d'académique. Un éditeur peut afficher une infrastructure irréprochable et livrer un modèle qui invente des références juridiques ou médicales avec une assurance trompeuse. À l'inverse, un modèle éprouvé peut tourner sur un serveur mal durci, accessible sans authentification forte ni journalisation. La sécurité de l'IA recouvre donc des risques qui lui sont propres : empoisonnement des données destinées à l'entraînement, extraction d'informations sensibles mémorisées par le modèle, injection de consignes malveillantes dans un agent relié à des outils. La cybersécurité traite l'accès aux ressources ; la sécurité de l'IA traite la confiance dans le comportement du système.
La surface d'attaque propre à l'IA : données, modèles et agents
Un système d'IA s'attaque à plusieurs niveaux que la cybersécurité classique n'anticipe guère. Les données d'entraînement peuvent être corrompues en amont pour orienter durablement les réponses futures, une pratique que l'on nomme empoisonnement. Le modèle lui-même peut être volé ou copié par extraction, en interrogeant massivement son interface pour reconstituer son comportement sans jamais accéder au code source. Ces menaces ne relèvent pas d'un mot de passe faible : elles tiennent à la manière dont le modèle ingère, mémorise et restitue l'information qu'on lui confie, et donc à sa conception autant qu'à son exploitation quotidienne.
S'ajoute le cas des agents autonomes, qui exécutent des actions et non plus seulement du texte. Un agent capable de lire des courriels, d'écrire dans une base de données ou de lancer des scripts ouvre une surface d'attaque inédite, à la jonction du logiciel et du modèle. La prompt injection en est l'exemple le plus net : une instruction malveillante cachée dans un document consulté peut détourner l'agent de sa mission et lui faire exécuter autre chose que ce qui était prévu. Sécuriser l'IA suppose alors de restreindre les droits de l'agent, de journaliser chacune de ses actions et de prévoir des points de contrôle humains avant tout effet irréversible.
Là où les deux disciplines se rejoignent
Malgré leurs objets différents, la cybersécurité et la sécurité de l'IA partagent des principes communs : moindre privilège, cloisonnement des environnements, journalisation, gestion rigoureuse des identités, réaction structurée aux incidents. Un agent IA ne vit pas dans un vide : il s'insère dans un système d'information existant et doit hériter de ses protections. Ignorer cet héritage revient à construire une porte blindée sur une clôture trouée. La robustesse du modèle ne compense jamais un contrôle d'accès défaillant ni une politique de sauvegarde absente. C'est souvent là, sur des fondations négligées, que les projets d'IA les plus ambitieux trébuchent en production.
Les référentiels confirment ce rapprochement. La norme ISO 42001 structure la gouvernance d'un système de management de l'IA, tandis que le règlement européen sur l'IA impose des obligations proportionnées au niveau de risque des systèmes concernés. Le RGPD encadre les données personnelles quelle que soit la technologie employée, y compris lorsqu'elles alimentent un modèle ou apparaissent dans une réponse. Autrement dit, la sécurité de l'IA doit s'intégrer aux politiques de sécurité et de conformité existantes, plutôt que d'être traitée comme un chantier parallèle, isolé et souvent redondant avec ce qui est déjà en place.
Ce que cela change pour les équipes et les compétences
Cette frontière déplace les profils recherchés. Le spécialiste de la sécurité des agents IA doit comprendre à la fois les principes du durcissement système et les fragilités propres aux modèles : dérive, hallucination, contournement de consignes, fuite d'informations par reformulation. Ce sont deux cultures techniques différentes, qui dialoguent mal si personne ne fait le lien entre elles. Une entreprise gagne à nommer explicitement qui couvre quel risque, plutôt qu'à supposer que l'équipe sécurité traitera tout par défaut. Quand cette clarification manque, chaque camp croit que l'autre s'en occupe, et le risque reste sans réponse claire.
En pratique, la question utile n'est pas « sécurité IA ou cybersécurité ? » mais « quel risque cherche-t-on à réduire ? ». Un accès non autorisé appelle les réflexes classiques du durcissement et de la surveillance. Une réponse infondée produite par un modèle appelle l'évaluation, la traçabilité et la supervision humaine. Distinguer les deux permet de prioriser les efforts, d'attribuer les budgets au bon endroit et d'éviter le faux sentiment de sécurité qui accompagne les approches trop générales. C'est cette lucidité, plus que l'outil choisi, qui protège réellement une organisation dans la durée, face à des menaces qui évoluent vite.
Aller plus loin
Ces frontières s'apprennent mieux en manipulant des cas concrets qu'en lisant des définitions générales. Pour approfondir la sécurisation des agents et des modèles, parcourez notre catalogue des 31 formations et identifiez le parcours adapté à votre niveau.
Vous voulez maîtriser ce sujet en pratique ?
Cabinet MARA forme en ligne, sur des cas réels, avec des modules courts et un suivi de progression.
Voir la formation liée Les 31 formations