Quand l'outil de productivité devient la faille de sécurité
En 2023, un ingénieur de Samsung Electronics a collé du code source propriétaire dans ChatGPT pour déboguer un programme interne. En quelques secondes, des secrets industriels critiques ont quitté définitivement le périmètre sécurisé de l'entreprise — sans intrusion, sans malware, sans alerte SOC. L'incident a été rendu public. Combien d'incidents similaires ne le sont jamais ?
Voici le paradoxe stratégique que peu de décideurs industriels ont pleinement mesuré : l'IA générative est en train d'être déployée massivement dans vos usines, vos bureaux d'études, vos équipes qualité et maintenance — souvent avant que votre politique de cybersécurité ait été mise à jour pour en tenir compte.
Selon le rapport IBM Cost of a Data Breach 2023, le coût moyen d'une violation de données atteint 4,45 millions de dollars. Mais dans un contexte industriel impliquant de la propriété intellectuelle, des formulations, des recettes ou des schémas de process, ce chiffre est une borne basse. La perte de compétitivité à long terme ne se chiffre pas en millions — elle se mesure en années d'avance technologique effacées.
Ce n'est pas l'IA elle-même qui est dangereuse. C'est l'usage non maîtrisé de l'IA dans des environnements industriels non préparés qui constitue aujourd'hui l'un des risques les plus sous-estimés du moment.
1. Le Shadow AI : l'angle mort que votre DSI ne voit pas encore
Le Shadow IT — ces outils non validés utilisés par les collaborateurs — existe depuis les débuts de l'informatique. La direction IT a appris à le gérer, au prix de dizaines d'années d'efforts.
Le Shadow AI, lui, est un phénomène d'une autre ampleur. Contrairement à une application bureautique non autorisée, un outil d'IA générative consomme activement les données que vous lui soumettez. Il les interprète, les stocke (selon les conditions d'utilisation du fournisseur), les utilise potentiellement pour entraîner des modèles futurs, et les expose à des infrastructures cloud hors de votre contrôle.
Dans les environnements industriels, les données soumises à ces outils ne sont pas anodines :
- Cahiers des charges techniques et plans de fabrication
- Données de process (paramètres, recettes, seuils critiques)
- Rapports d'incidents et analyses de non-conformités
- Données fournisseurs et sous-traitants (potentiellement couvertes par des clauses de confidentialité)
- Spécifications clients sous NDA
Une enquête Cyberhaven de 2023 révèle que 11 % des données collées dans ChatGPT par des employés d'entreprise sont classifiées "confidentielles" par leurs propres outils DLP. Et ce chiffre ne concerne que les flux détectés — par définition, le Shadow AI échappe largement à la détection.
La question n'est plus "est-ce que mes équipes utilisent des outils d'IA non validés ?" La réponse est oui, presque certainement. La vraie question est : "Savez-vous quelles données ont déjà quitté votre périmètre, et quel est le risque juridique et concurrentiel associé ?"
2. Les trois vecteurs d'attaque spécifiques à l'IA industrielle
2.1 L'exfiltration involontaire par prompt engineering
L'utilisateur lambda n'a aucune conscience du fait qu'il "entraîne" potentiellement un modèle avec ses requêtes. Un technicien de maintenance qui décrit un mode de défaillance récurrent sur une ligne critique, un ingénieur qualité qui soumet un plan de contrôle complet pour obtenir une analyse statistique rapide — ces actions semblent anodines. Elles ne le sont pas.
Le risque n'est pas hypothétique : plusieurs fournisseurs d'IA grand public stipulent dans leurs CGU la possibilité d'utiliser les conversations pour améliorer leurs modèles, sauf opt-out explicite et correctement configuré. Dans un contexte B2B, cet opt-out est rarement vérifié ou maintenu.
2.2 L'empoisonnement de modèles internes (Model Poisoning)
Pour les entreprises qui déploient des modèles d'IA en interne — pour la maintenance prédictive, le contrôle qualité automatisé, l'optimisation de process — un vecteur d'attaque sophistiqué consiste à corrompre les données d'entraînement. Un acteur malveillant ayant accès, même partiel, au flux de données alimentant un modèle peut introduire des biais délibérés qui dégradent silencieusement la performance du système.
Ce type d'attaque est particulièrement insidieux parce qu'il ne déclenche aucune alarme de sécurité classique. La dégradation est progressive, souvent confondue avec une dérive process naturelle. Quand elle est détectée, les décisions industrielles prises pendant la période de corruption sont déjà dans le passé — avec leurs conséquences sur la qualité, la conformité, voire la sécurité des produits.
2.3 L'injection de prompt comme vecteur d'attaque sur les systèmes connectés
Les architectures d'IA intégrées aux ERP, MES ou SCADA via des interfaces de langage naturel créent une surface d'attaque radicalement nouvelle. Une injection de prompt consiste à insérer des instructions malveillantes dans des données que le modèle va traiter, afin de lui faire exécuter des actions non prévues.
Dans un environnement industriel connecté, cela peut se traduire par des modifications de paramètres process, des ordres de fabrication frauduleux, ou des accès non autorisés à des bases de données critiques — le tout en contournant les contrôles d'accès traditionnels, parce que le système croit exécuter une instruction légitime.
L'OWASP a intégré l'injection de prompt dans son Top 10 des risques IA dès 2023. La plupart des architectures industrielles déployant des LLM en production n'ont pas encore intégré cette menace dans leur modèle de sécurité.
3. Limites des pratiques courantes : pourquoi votre cadre ISO 27001 ne suffit plus
La norme ISO 27001 reste une référence solide pour la gestion de la sécurité de l'information. Mais elle a été conçue dans un monde où les systèmes d'information avaient des périmètres relativement bien définis, et où les menaces étaient principalement externes.
L'IA générative fait exploser trois hypothèses fondatrices de ce cadre :
Hypothèse 1 — "Je contrôle ce qui sort de mon SI." Faux dès lors qu'un collaborateur copie-colle dans un outil cloud externe. Les outils DLP traditionnels détectent les transferts de fichiers, pas les échanges en langage naturel avec un LLM.
Hypothèse 2 — "Mes systèmes exécutent des instructions déterministes." Un LLM intégré dans un workflow industriel n'est pas déterministe. Sa réponse peut varier selon le contexte, l'historique de conversation, ou des manipulations externes. Les audits de sécurité classiques ne testent pas ce type de comportement.
Hypothèse 3 — "Mon périmètre de risque est stable." L'IA évolue à une vitesse sans précédent. De nouveaux outils, de nouvelles capacités, de nouvelles vulnérabilités apparaissent tous les trimestres. Un SMSI mis à jour annuellement est structurellement en retard.
Le cadre NIST AI RMF (AI Risk Management Framework), publié en janvier 2023, commence à combler ces lacunes. Mais son adoption dans l'industrie manufacturière est encore embryonnaire.
Ce que les experts savent… mais que peu d'entreprises appliquent réellement
Le vrai risque n'est pas l'IA de vos concurrents — c'est l'IA de vos fournisseurs
La plupart des directions industrielles focalisent leur attention sur leur propre usage de l'IA. C'est une erreur de priorisation.
Vos fournisseurs de rang 1 et 2 utilisent également des outils d'IA, avec des politiques de sécurité probablement moins matures que les vôtres. Si un fournisseur soumet à un LLM externe une spécification technique que vous lui avez transmise sous clause de confidentialité, vous avez une fuite de données — sans jamais avoir utilisé vous-même un outil d'IA.
Combien d'entreprises ont mis à jour leurs clauses contractuelles fournisseurs pour inclure des exigences sur l'usage de l'IA avec leurs données ? D'après mon expérience terrain, une minorité infime. C'est un angle mort juridique et concurrentiel majeur.
Les LLM ont une mémoire que vos politiques de rétention ne couvrent pas
Quand un collaborateur utilise un outil d'IA en mode "historique activé", ses conversations passées peuvent être réinjectées dans de futures interactions — parfois des mois plus tard. La politique de rétention des données de votre entreprise s'applique à vos serveurs. Elle ne s'applique pas aux serveurs de votre fournisseur d'IA.
L'IA augmente exponentiellement la valeur des données volées
Traditionnellement, une intrusion sur un SI industriel nécessitait un analyste humain pour interpréter les données volées — ce qui représentait un frein naturel à l'exploitation. Avec l'IA, un acteur malveillant disposant de 10 Go de données brutes non structurées peut en extraire la substance stratégique en quelques heures. Plans de fabrication, paramètres process, données de qualité : tout devient exploitable quasi instantanément.
Cela change fondamentalement le calcul de valeur d'une intrusion — et donc la motivation des attaquants.
l'inaction a un coût que vous ne verrez qu'après
La cybersécurité industrielle a mis 15 ans à se structurer autour des risques IT/OT. Elle n'a pas 15 ans pour intégrer les risques liés à l'IA.
Les entreprises qui agissent maintenant ne sont pas paranoïaques — elles sont compétitives. Elles préservent leur propriété intellectuelle, sécurisent leurs avantages process, et construisent une gouvernance IA qui deviendra rapidement un prérequis réglementaire (l'AI Act européen entre progressivement en vigueur jusqu'en 2026).
Les entreprises qui attendent s'exposent à trois risques cumulatifs : la fuite de données non détectée, le risque juridique lié à la non-conformité contractuelle, et la perte d'avance technologique au profit d'acteurs — concurrents ou États — qui exploitent des données industrielles collectées via des outils IA mal sécurisés.
Dans l'industrie, la sécurité n'a jamais été une option. La cybersécurité de l'IA ne doit pas l'être davantage.