Ce que les usines demandent vraiment à l'IA
La plupart des sites industriels utilisent déjà une forme d'intelligence artificielle, par exemple des modèles prédictifs sur une machine. Ce qui change avec les modèles de langage, c'est leur capacité à lire des alarmes, des tendances, des manuels et des projets d'automatisme, puis à répondre en langage courant ou à rédiger des documents. En environnement OT, deux usages se distinguent nettement. Les assistants qui lisent et expliquent retrouvent la cause première d'un arrêt, décodent une alarme ou rédigent une passation : le risque est faible car une personne décide toujours. Les agents qui agissent écrivent du code automate ou modifient des configurations : ils ne doivent tourner que sur des systèmes de développement ou de test, avec la validation d'un ingénieur à chaque modification.
| Cas d'usage | Données nécessaires | Niveau de risque |
|---|---|---|
| Première cause d'un arrêt de ligne | Historique des alarmes et événements, logique d'interverrouillage | Faible, l'opérateur décide |
| Explication des alarmes et procédures | Textes d'alarmes, modes opératoires | Faible |
| Aide au dépannage | Tendances, historique des ordres de travail, manuels | Faible, le technicien décide |
| Documentation PLC et SCADA | Fichiers de projets, lecture seule | Faible |
| Migration d'un ancien SCADA ou automate | Anciens projets, listes de variables, standards | Moyen, sur système de développement puis testé |
| Code pour une nouvelle logique | Standard de l'entreprise, bibliothèque de blocs | Moyen, revue par un ingénieur et tests en simulation |
En juin 2026, Siemens a par exemple annoncé un agent d'ingénierie pour TIA Portal capable d'écrire du code automate et de construire des écrans IHM. Le signal envoyé aux DSI industriels est clair : la question n'est plus de savoir si l'IA peut intervenir sur les systèmes existants, mais comment l'y introduire sans créer de nouveau risque.
Où faire tourner les modèles : la décision qui engage toute l'architecture
Trois options coexistent, et beaucoup d'usines les combinent selon le cas d'usage. Les services professionnels d'Anthropic ou d'OpenAI constituent la première option : leurs conditions professionnelles indiquent que les données envoyées ne servent pas à l'entraînement des modèles par défaut, ce que détaillent leurs propres pages de confidentialité d'entreprise. La deuxième option consiste à exploiter les mêmes modèles via des régions cloud européennes, par exemple Amazon Bedrock ou Google Cloud, lorsque la localisation des données compte pour des raisons contractuelles ou de conformité interne. La troisième option, des modèles locaux installés sur site, s'adresse aux données qui ne peuvent pas quitter l'usine, au prix de capacités généralement moindres.
| Option | Ce qu'elle apporte | Point d'attention pour le DSI |
|---|---|---|
| Anthropic / OpenAI, services professionnels | Accès aux modèles les plus capables, non-entraînement par défaut sur les données envoyées | Vérifier contractuellement la portée exacte de cet engagement |
| Mêmes modèles via AWS Bedrock ou Google Cloud, région européenne | Localisation des données recherchée pour des exigences de conformité ou de clauses clients | La localisation ne dispense pas des obligations RGPD classiques |
| Modèles locaux sur site | Aucune donnée ne quitte l'usine | Capacités généralement inférieures aux modèles de pointe |
Une garantie de non-entraînement n'est pas une garantie de souveraineté
Ces deux notions répondent à des questions différentes. Le non-entraînement par défaut porte sur l'usage que le fournisseur fera des données envoyées. La localisation en région européenne, via Bedrock ou Google Cloud, répond à une autre question : où le traitement a-t-il lieu. Un DSI qui doit documenter un dossier de preuves pour un client ou un auditeur a besoin des deux réponses, pas d'une seule. C'est ce qui pousse certaines usines à combiner les trois options selon la sensibilité de chaque flux de données plutôt qu'à choisir une seule architecture pour tout le site.
Une autre approche, complémentaire, consiste à transformer les données avant qu'elles ne partent vers un modèle tiers, quel que soit son hébergement. C'est le principe retenu par Moon AI, la plateforme multi-modèles de Stellarr Studio SAS, dont la fonction Moon Blur remplace les données personnelles par des jetons avant l'envoi aux modèles tiers puis les rétablit au retour. Ce procédé étant réversible, il s'agit d'une pseudonymisation au sens de l'article 4-5 du RGPD, pas d'une anonymisation : les requêtes adressées aux modèles tiers partent bien chez leurs fournisseurs, après pseudonymisation, même si l'application et le stockage sont eux hébergés chez OVHcloud à Strasbourg et Roubaix. Pour un DSI industriel, ce type de couche s'ajoute à la question du lieu d'exécution du modèle, il ne la remplace pas.
Verrouiller l'accès aux données OT avant de parler de modèle
Un assistant ne vaut que par les données qu'il voit, et en OT cet accès ne doit créer aucun nouveau risque. Plusieurs règles s'imposent avant tout déploiement. Faire lire le modèle depuis des copies ou des interfaces en lecture seule : historian, base d'alarmes, projets exportés, exports de la GMAO. Garder les réseaux de contrôle segmentés et se connecter via la DMZ ou une passerelle en lecture seule, jamais avec un chemin direct d'internet vers un automate. Donner à l'assistant son propre compte, avec le minimum de droits nécessaires, et journaliser chaque requête. Enfin, ne jamais laisser un modèle de langage écrire dans les automates ou le SCADA en production : les modifications passent par l'ingénierie, les tests et la validation humaine.
Mener un pilote avant de généraliser
Les critères de réussite se fixent au départ : temps pour trouver la cause première d'un arrêt, durée d'une passation, nombre d'heures gagnées sur une migration. Opérateurs et ingénieurs utilisent ensuite l'assistant quelques semaines dans leur travail réel, et ce sont leurs retours qui décident du passage à la ligne suivante. Cette logique de preuve par la ligne évite d'engager une architecture cloud coûteuse avant d'avoir validé la valeur du cas d'usage.
Gouvernance OT et calendrier réglementaire pour 2026-2028
En décembre 2025, neuf agences de cybersécurité, dont la CISA américaine, le BSI allemand, le NCSC néerlandais et le NCSC britannique, ont publié des recommandations communes pour intégrer l'IA dans l'OT. Elles s'articulent autour de quatre principes : comprendre l'IA et ses risques propres en OT en formant les équipes et en suivant un cycle de développement sécurisé ; évaluer l'usage de l'IA en OT en vérifiant le cas d'affaires et les risques liés aux données OT, fournisseurs et intégration compris ; mettre en place une gouvernance et une assurance en intégrant l'IA aux cadres de sécurité existants et en suivant la réglementation ; intégrer sûreté et sécurité en gardant une supervision humaine, des systèmes transparents, et en incluant l'IA dans la réponse aux incidents.
Sur le plan réglementaire, l'omnibus numérique (règlement UE 2026/1744) est en vigueur depuis le 27 juillet 2026 et a reporté les échéances du haut risque : le 2 décembre 2027 pour les systèmes autonomes à haut risque de l'annexe III, le 2 août 2028 pour l'IA intégrée dans des produits relevant de la législation européenne sur les produits, annexe I. La plupart des assistants d'usine qui expliquent ou rédigent ne relèvent pas du haut risque, mais une IA qui sert de composant de sécurité peut l'être. Au-delà de la classification, les obligations classiques du RGPD demeurent : une analyse d'impact relative à la protection des données reste due dès lors que des données personnelles transitent par ces systèmes, indépendamment du lieu d'hébergement du modèle. Chaque cas d'usage mérite d'être examiné tôt, et un avis juridique reste recommandé pour la qualification définitive.
Pièges fréquents côté DSI
- Commencer par un chatbot généraliste qui ne voit pas les données de l'usine, avec des réponses qui restent génériques.
- Donner trop tôt des droits d'écriture sur les systèmes de contrôle.
- Construire le projet sans les opérateurs et techniciens, qui finissent par ne pas l'utiliser.
- Ne désigner aucun responsable après le pilote, ce qui empêche le déploiement sur une deuxième ligne.
Questions fréquentes
Les modèles Anthropic et OpenAI hébergés via Bedrock ou Google Cloud rendent-ils l'IA conforme au RGPD ?
Non. La localisation des données en région européenne répond à une question de souveraineté, pas de conformité automatique. Les obligations classiques, comme l'analyse d'impact relative à la protection des données, et pour les systèmes à haut risque l'analyse d'impact sur les droits fondamentaux, restent dues indépendamment du lieu d'exécution du modèle.
Faut-il construire une plateforme de données ou un Unified Namespace avant de démarrer ?
Non. Un bon premier cas d'usage lit les données qui existent déjà, historian, base d'alarmes ou exports de GMAO. Un Unified Namespace ou une plateforme de données devient utile quand le déploiement s'étend à de nombreuses lignes et sites.
L'IA va-t-elle remplacer les opérateurs ou les ingénieurs OT ?
Non. Elle supprime du travail de recherche et de rédaction et accélère l'obtention de réponses. Les personnes gardent les décisions, en particulier en OT où une mauvaise action peut avoir des conséquences physiques.
Combien de temps avant de voir des résultats concrets ?
Un assistant en lecture seule sur une ligne se teste rapidement, car il s'appuie sur des données qui existent déjà. Les cas d'ingénierie, comme les migrations de SCADA ou d'automates, demandent davantage de temps, car chaque résultat produit doit être testé avant mise en œuvre.