Sécurité des systèmes IA en entreprise : risques, contrôles et gouvernance

Treize pour cent des organisations ont déjà subi une violation de leurs modèles ou de leurs applications d’IA, et 97 % d’entre elles ne disposaient d’aucun contrôle d’accès dédié (IBM, Cost of a Data Breach 2025). L’adoption de l’intelligence artificielle progresse plus vite que sa sécurité. Entre shadow AI, injection de prompt et fuites de données, la surface d’attaque s’élargit à chaque déploiement. Pour un dirigeant, la question n’est plus de savoir si un incident surviendra, mais comment le rendre improbable et en limiter les effets. Ce dossier passe en revue les risques réels, les référentiels qui structurent la défense et les contrôles à mettre en place.

L’essentiel : Sécuriser un système d’IA combine trois chantiers : protéger les données et les accès, encadrer le comportement du modèle (injection de prompt, sorties non maîtrisées) et installer une gouvernance des risques. En 2025, 63 % des organisations touchées n’avaient aucune politique de gouvernance IA (IBM). Les référentiels OWASP, NIST et la norme ISO/IEC 42001 en fournissent la trame.

Temps de lecture : 13 min

Les points clés

• 13 % des organisations ont signalé une violation de leurs systèmes d’IA en 2025, dont 97 % sans contrôle d’accès dédié (IBM).
• Le shadow AI a pesé dans 20 % des violations et a ajouté 670 000 dollars à la facture moyenne (IBM).
• L’injection de prompt reste le risque numéro un du classement OWASP Top 10 for LLM Applications (OWASP, 2025).
• La norme ISO/IEC 42001 couvre 80 à 85 % des exigences de gouvernance attendues par l’AI Act.

Qu’est-ce que la sécurité des systèmes IA en entreprise ?

La sécurité des systèmes IA en entreprise désigne l’ensemble des mesures techniques, organisationnelles et de gouvernance qui protègent les modèles, les données et les applications d’intelligence artificielle contre les fuites, les manipulations et les usages non maîtrisés. Elle protège trois surfaces : les données, le modèle et les usages.

Une sécurité qui dépasse la cybersécurité classique

La cybersécurité traditionnelle protège les réseaux, les serveurs et les postes de travail. Elle reste indispensable, mais elle ne voit pas les risques propres à l’IA. Un pare-feu n’arrête pas une instruction malveillante glissée dans un document. Le profil génératif du cadre NIST recense douze risques spécifiques à l’IA générative, dont l’injection de prompt, l’empoisonnement des données et les atteintes à la sécurité de l’information (NIST, 2024). Sécuriser l’IA ajoute une couche pensée pour ces menaces, par-dessus les fondations existantes. Pour situer ces enjeux, mieux vaut d’abord comprendre l’IA et ses risques.

Les trois surfaces à protéger : données, modèle, usages

Un système d’IA expose trois surfaces. Les données d’abord : jeux d’entraînement, bases de connaissances, informations personnelles traitées par un assistant. Le modèle ensuite : ses poids, ses consignes système, ses réponses. Les usages enfin : qui accède à l’outil, avec quels droits, selon quelles règles. Une faille sur l’une de ces surfaces suffit. En 2025, la majorité des violations touchaient des données réparties sur plusieurs environnements, ce qui allonge la détection et le coût (IBM). Protéger l’IA suppose une vision d’ensemble, pas un correctif isolé.

Quels sont les principaux risques de sécurité de l’IA en 2026 ?

Les risques de sécurité de l’IA se concentrent sur quelques familles bien identifiées en 2026 : le shadow AI, l’injection de prompt, l’empoisonnement des données et des modèles, la chaîne d’approvisionnement et les dérives des agents autonomes. Chacune appelle une parade distincte, et aucune ne se règle par la seule bonne volonté des équipes.

Le shadow AI, première fuite invisible

Le shadow AI désigne l’usage d’outils d’IA non validés par la direction informatique. Un collaborateur colle un extrait de contrat dans un assistant grand public pour gagner du temps, et la donnée part sur une plateforme externe. En 2025, ce phénomène a pesé dans 20 % des violations et a ajouté 670 000 dollars à la facture moyenne (IBM). Les incidents liés au shadow AI exposent des données personnelles clients dans 65 % des cas, contre 53 % en moyenne (IBM). Le risque est autant culturel que technique.

L’injection de prompt, le risque numéro un

L’injection de prompt détourne un modèle en lui soumettant des instructions cachées. Elle est directe quand l’utilisateur tape la consigne, indirecte quand le modèle lit un contenu piégé dans un site, un document ou un courriel. Les systèmes à base de RAG et les agents amplifient le danger, car le modèle traite le contenu externe comme une consigne de confiance. C’est le risque numéro un du classement OWASP Top 10 for LLM Applications, en tête pour la deuxième édition consécutive (OWASP, 2025). Ni le RAG ni le réglage fin ne suffisent à l’éliminer.

L’empoisonnement des données et du modèle

L’empoisonnement vise les données et le modèle lui-même. Un attaquant introduit des exemples corrompus dans les données d’entraînement ou d’ajustement, et le modèle apprend un comportement biaisé ou une porte dérobée. Ce risque figure parmi les entrées majeures du classement OWASP et parmi les douze risques du profil génératif NIST (NIST, 2024). La parade passe par la maîtrise de la provenance des données, leur validation et la traçabilité de chaque source utilisée pour entraîner ou nourrir le système.

La chaîne d’approvisionnement de l’IA

La chaîne d’approvisionnement de l’IA regroupe les modèles tiers, les bibliothèques, les API et les modules intégrés à une application. Une dépendance compromise ouvre une brèche directe. Les incidents passant par cette chaîne ont conduit à une compromission de données dans 60 % des cas et à une interruption d’activité dans 31 % (IBM). Le classement OWASP a ajouté en 2025 une entrée dédiée aux faiblesses des bases vectorielles et des embeddings, au cœur des systèmes RAG (OWASP, 2025).

L’agentivité excessive des agents IA

Les agents IA dépassent la simple réponse : ils envoient des courriels, interrogent des bases et déclenchent des actions. Le classement OWASP parle d’agentivité excessive et en distingue trois causes : trop de fonctions accordées, trop de droits, trop d’autonomie. Un agent autorisé à agir sans validation humaine élargit la portée d’une attaque. La règle de bon sens reste simple : l’IA propose, l’humain décide pour toute action sensible.

Quels référentiels structurent la sécurité de l’IA ?

Plusieurs référentiels structurent la sécurité et la gouvernance de l’IA. Le classement OWASP cartographie les failles techniques, le cadre NIST AI RMF organise la gestion des risques, la norme ISO/IEC 42001 certifie un système de management, et l’AI Act fixe des obligations légales. Les combiner donne une défense cohérente plutôt qu’une somme de correctifs.

OWASP Top 10 for LLM Applications

Le classement OWASP Top 10 for LLM Applications recense les risques les plus critiques des applications fondées sur des modèles de langage. Sa version 2025 réordonne les risques et ajoute deux entrées. Les principaux :

• Injection de prompt (LLM01), risque numéro un.
• Divulgation d’informations sensibles (LLM02).
• Sécurité de la chaîne d’approvisionnement (LLM03).
• Empoisonnement des données et du modèle (LLM04).
• Traitement non sécurisé des sorties (LLM05).
• Agentivité excessive des agents IA.
• Faiblesses des bases vectorielles et des embeddings.

OWASP recommande une défense en profondeur : moindre privilège, filtrage des entrées et des sorties, validation humaine des actions à fort impact et tests adverses réguliers (OWASP, 2025).

Le cadre NIST AI RMF

Le cadre NIST AI RMF, publié en janvier 2023, repose sur quatre fonctions : gouverner, cartographier, mesurer et gérer (NIST, 2023). Il est volontaire, mais il s’est imposé comme un standard de fait, y compris hors des États-Unis. En juillet 2024, le profil génératif NIST-AI-600-1 l’a complété avec douze risques propres à l’IA générative, dont l’injection de prompt et l’empoisonnement des données (NIST, 2024). Il se superpose au cadre existant sans imposer de refonte.

La norme ISO/IEC 42001

La norme ISO/IEC 42001:2023 est la première norme internationale de système de management de l’IA, et la seule certifiable à ce jour. Elle applique la logique Plan-Do-Check-Act et s’articule avec la norme de sécurité de l’information ISO/IEC 27001. La certification, délivrée par un organisme tiers accrédité, reste volontaire. La norme ISO/IEC 42006, publiée en 2025, encadre justement les organismes habilités à certifier ces systèmes de management.

L’AI Act et le RGPD

À partir du 2 août 2026, l’AI Act impose surtout des obligations de transparence (article 50). Les obligations applicables aux systèmes à haut risque de l’annexe III, d’abord prévues à cette date, sont reportées au 2 décembre 2027 dans le cadre du Digital Omnibus, dont l’accord provisoire date du 7 mai 2026. Les sanctions peuvent atteindre 35 millions d’euros ou 7 % du chiffre d’affaires mondial. La norme ISO/IEC 42001 couvre 80 à 85 % des exigences de gouvernance attendues. Le RGPD interdit par ailleurs toute décision entièrement automatisée (article 22).

Et côté méthode : garder la main sur votre IA : gouvernance et ROI.

Pourquoi la gouvernance compte-t-elle autant que la technique ?

La technique ne suffit pas. En 2025, 63 % des organisations touchées par une violation liée à l’IA n’avaient aucune politique de gouvernance (IBM). Le constat des analystes est net : le vrai risque n’est pas l’IA, c’est l’IA sans gouvernance. Sécuriser durablement suppose des règles, des rôles et une supervision humaine.

Le vrai risque, c’est l’IA sans gouvernance

L’adoption de l’IA va plus vite que son encadrement. Parmi les organisations dotées d’une politique, seules 34 % auditent régulièrement les usages non autorisés (IBM). Le rapport IAPP 2025 confirme l’écart : 77 % des organisations construisent un programme de gouvernance, mais 36 % seulement ont adopté un cadre formel (IAPP, 2025). Côté pertes, une enquête EY menée auprès de 975 dirigeants montre que 99 % ont subi des pertes financières liées aux risques de l’IA, près des deux tiers au-delà d’un million de dollars (EY, 2025).

L’humain dans la boucle de décision

La gouvernance fixe qui décide quand un modèle se comporte de façon inattendue. Elle attribue la responsabilité, définit les seuils de tolérance et impose une validation humaine pour les actions sensibles. Cette logique rejoint la parade OWASP contre l’agentivité excessive : une approbation humaine avant tout effet important. Elle suppose aussi de former les équipes, de tester les plans de réponse aux incidents et de simuler des crises. L’IA propose, l’humain garde la décision finale.

Quels contrôles déployer pour sécuriser un système IA ?

Sécuriser un système d’IA en production repose sur quelques contrôles éprouvés : cartographier les usages et verrouiller les accès, filtrer les entrées et les sorties, superviser les actions sensibles, puis tester en conditions adverses. Hébergé en local, le modèle limite encore la surface d’exposition.

Cartographier et verrouiller les accès

Le premier contrôle consiste à savoir ce qui tourne. Inventoriez tous les usages d’IA, y compris ceux que personne n’a déclarés. Appliquez ensuite le moindre privilège : chaque agent n’accède qu’aux données et aux fonctions strictement nécessaires. Traitez les agents IA comme des identités, au même titre que les utilisateurs humains, avec des droits cadrés sur leur tâche. Le rappel est sévère : 97 % des organisations victimes d’un incident IA n’avaient aucun contrôle d’accès dédié (IBM).

Filtrer les entrées et les sorties

Un modèle reçoit des entrées et produit des sorties, deux points à filtrer. En entrée, contrôlez et nettoyez le contenu soumis, surtout s’il vient de sources externes. En sortie, traitez la réponse du modèle comme une donnée non fiable : validez-la avant qu’une application l’exécute. Le classement OWASP cite le traitement non sécurisé des sorties parmi les risques majeurs, souvent enchaîné à une injection de prompt (OWASP, 2025). Ce double filtre coupe une grande partie des attaques.

Superviser, tester et héberger en local

La supervision ferme la boucle. Journalisez les requêtes, surveillez les comportements anormaux et exigez une validation humaine pour toute action à fort impact. Avant la mise en production, faites tester le système par une équipe qui cherche à le détourner : le profil génératif NIST recommande ces tests adverses (NIST, 2024). Pour les données les plus sensibles, un modèle hébergé en local évite tout transit par une plateforme externe. Les organisations qui exploitent l’IA et l’automatisation dans leur sécurité économisent 1,9 million de dollars et 80 jours sur le cycle d’un incident (IBM).

Par où commencer pour sécuriser vos systèmes IA ?

Par où commencer ? La sécurité de l’IA se construit par étapes, pas d’un bloc. Un plan simple en quatre temps permet d’avancer vite sans tout bloquer, tout en transformant la conformité en atout de confiance plutôt qu’en contrainte subie.

Un plan en quatre temps

Avancez en quatre temps. D’abord l’inventaire : recensez tous les usages d’IA, déclarés ou non. Ensuite les priorités : verrouillez les accès et installez le double filtre entrées-sorties. Puis la gouvernance : rédigez une politique, attribuez les rôles et alignez-vous sur le cadre NIST ou la norme ISO/IEC 42001. Enfin les tests continus : red teaming, journalisation et supervision. Cette progression rejoint la logique d’un déploiement maîtrisé, du premier essai jusqu’à la mise en production contrôlée.

Faire de la conformité un atout

La conformité n’est pas qu’une contrainte. Anticiper les obligations de transparence du 2 août 2026 et s’appuyer sur la norme ISO/IEC 42001, qui couvre 80 à 85 % des exigences de gouvernance, rassure clients et partenaires. Une sécurité documentée devient un argument de confiance, surtout face à des donneurs d’ordre exigeants. Commencez dès cette semaine par dresser l’inventaire de tous vos usages d’IA, puis verrouillez les accès avant d’élargir le périmètre.

Questions fréquentes sur la sécurité des systèmes IA

Qu’est-ce que la sécurité des systèmes IA en entreprise ?

La sécurité des systèmes IA en entreprise désigne l’ensemble des mesures techniques, organisationnelles et de gouvernance qui protègent les modèles, les données et les applications d’intelligence artificielle contre les fuites, les manipulations et les usages non maîtrisés. Elle prolonge la cybersécurité classique en couvrant des risques propres à l’IA, comme l’injection de prompt ou l’empoisonnement des données, et s’appuie sur des référentiels comme OWASP, NIST AI RMF et la norme ISO/IEC 42001.

Qu’est-ce que le shadow AI et pourquoi est-il dangereux ?

Le shadow AI désigne l’usage d’outils d’IA non approuvés par la direction des systèmes d’information, comme un assistant grand public alimenté avec des documents internes. Il est dangereux car il échappe à tout contrôle. En 2025, il a pesé dans 20 % des violations et a alourdi la facture moyenne de 670 000 dollars, avec une exposition de données personnelles clients dans 65 % des cas, contre 53 % en moyenne (IBM).

Qu’est-ce que l’injection de prompt ?

L’injection de prompt consiste à glisser des instructions malveillantes dans le texte qu’un modèle de langage analyse, pour lui faire ignorer ses consignes initiales. Elle peut être directe, via la conversation, ou indirecte, cachée dans un document, un site ou un courriel que le modèle consulte. C’est le risque numéro un du classement OWASP Top 10 for LLM Applications, en tête pour la deuxième édition consécutive (OWASP, 2025).

Faut-il être certifié ISO 42001 pour sécuriser son IA ?

Non, la certification ISO/IEC 42001 n’est pas obligatoire pour sécuriser son IA. C’est une démarche volontaire, validée par un organisme tiers accrédité. La norme reste utile : elle structure un système de management de l’IA selon la logique Plan-Do-Check-Act et couvre 80 à 85 % des exigences de gouvernance attendues par l’AI Act. Beaucoup d’organisations s’en inspirent sans viser la certification dans un premier temps.

Que change l’AI Act pour la sécurité de l’IA en 2026 ?

À partir du 2 août 2026, l’AI Act impose surtout des obligations de transparence (article 50). Les obligations applicables aux systèmes à haut risque de l’annexe III, d’abord prévues à cette date, sont reportées au 2 décembre 2027 dans le cadre du Digital Omnibus. Les sanctions peuvent atteindre 35 millions d’euros ou 7 % du chiffre d’affaires mondial. Le RGPD interdit par ailleurs toute décision entièrement automatisée (article 22).

Un LLM hébergé en local est-il plus sûr ?

Un modèle hébergé en local peut réduire fortement le risque de fuite, car les données sensibles ne quittent pas le périmètre de l’entreprise et ne transitent pas par une plateforme externe. Ce n’est pas une protection totale : il faut toujours verrouiller les accès, filtrer les entrées et les sorties et superviser les actions de l’agent. Le local répond surtout aux enjeux de souveraineté et de confidentialité des données.

Diagnostic IA gratuitNous contacterParler à Eric