Implémenter l'IA dans l'OT : guide pratique pour l'industrie (2026)

Mis à jour: 24 octobre 2026 · SIM Solutions

En bref

Choisissez deux ou trois tâches où opérateurs, techniciens ou ingénieurs perdent du temps chaque jour. Donnez à l'IA un accès en lecture seule aux données nécessaires, comme l'historique des alarmes, les tendances, les manuels et les projets PLC ou SCADA. Prouvez la valeur sur une ligne avec des critères fixés à l'avance, faites valider chaque modification par une personne, et ne déployez qu'ensuite.

Ce que signifie « l'IA en OT » en pratique

La plupart des usines utilisent déjà une forme d'IA, comme des modèles prédictifs sur une machine. Ce qui a changé, ce sont les modèles de langage : des assistants qui lisent alarmes, tendances, manuels et logiciels d'automatisme, répondent en langage courant et rédigent documents et code. En OT, ils servent de deux façons :

Des assistants qui lisent et expliquent. Ils trouvent la première cause d'un arrêt, expliquent une alarme, cherchent dans les manuels et l'historique, et rédigent passations et ordres de travail. Risque faible, valeur rapide à prouver.
Des agents qui agissent. Ils écrivent du code automate, construisent des écrans SCADA ou modifient des configurations. Puissants, mais uniquement sur des systèmes de développement ou de test, avec la validation d'un ingénieur pour chaque modification.

Les fournisseurs avancent vite aussi. En juin 2026, Siemens a par exemple annoncé un agent d'ingénierie pour TIA Portal qui écrit du code automate et construit des écrans IHM. Pour la plupart des usines, la question n'est donc plus de savoir si l'IA peut le faire, mais comment l'introduire en toute sécurité sur tous les systèmes existants.

Étape 1 : choisir des cas d'usage rentables

Les bons premiers cas d'usage ont quatre points communs : ils sont fréquents, ils coûtent du temps ou de la production, les données existent déjà, et une mauvaise réponse ne peut nuire à personne car une personne décide toujours.

Cas d'usage	Données nécessaires	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
Passation d'équipe et rapports	Journal de production, alarmes, changements de consignes	Faible
Documentation PLC et SCADA	Fichiers de projets PLC et SCADA	Faible : lecture seule
Migration d'un ancien SCADA ou automate	Anciens projets, listes de variables, standards	Moyen : sur un 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

Étape 2 : maîtriser l'accès aux données

L'assistant ne vaut que par les données qu'il voit, et en OT cet accès ne doit pas créer de nouveau risque.

Lire 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. 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.
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.

Étape 3 : choisir où tournent les modèles

Trois options sont courantes, et beaucoup d'usines les combinent :

Services IA professionnels d'Anthropic ou d'OpenAI. Leurs conditions professionnelles indiquent que vos données ne servent pas à l'entraînement par défaut.
Les mêmes modèles dans des régions cloud européennes, par exemple via Amazon Bedrock ou Google Cloud, quand la localisation des données compte.
Des modèles locaux sur site pour les données qui ne peuvent pas quitter l'usine, généralement avec moins de capacités.

Étape 4 : un pilote sur une ligne

Fixez les critères de réussite au départ, par exemple le temps pour trouver la première cause d'un arrêt, la durée d'une passation ou le nombre d'heures d'une migration. Laissez ensuite opérateurs et ingénieurs utiliser l'assistant quelques semaines dans leur travail réel. Leurs retours décident de ce qui passe à la ligne suivante.

Étape 5 : gouvernance et sécurité

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 reposent sur quatre principes :

Comprendre l'IA. Connaître ses risques propres en OT, former les équipes et suivre un cycle de développement sécurisé.
Évaluer l'usage de l'IA en OT. Vérifier le cas d'affaires, gérer les risques pour les données OT et tenir compte des fournisseurs et de l'intégration.
Mettre en place gouvernance et assurance. Intégrer l'IA aux cadres de sécurité existants, tester et évaluer les modèles en continu et suivre la réglementation.
Intégrer sûreté et sécurité. Garder une supervision humaine, garder les systèmes transparents et inclure l'IA dans la réponse aux incidents.

L'AI Act : ce qui s'applique et quand

L'omnibus IA est en vigueur depuis le 27 juillet 2026 et a reporté les échéances pour le haut risque : le 2 décembre 2027 pour les systèmes autonomes à haut risque de l'annexe III, et le 2 août 2028 pour l'IA intégrée dans des produits relevant de la législation européenne sur les produits. La plupart des assistants d'usine qui expliquent ou rédigent ne sont pas à haut risque, mais une IA qui sert de composant de sécurité peut l'être. Examinez chaque cas d'usage tôt ; pour un avis juridique, consultez un juriste.

Erreurs fréquentes

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érales.
Donner trop tôt des droits d'écriture sur les systèmes de contrôle.
Le construire sans les opérateurs et techniciens, qui ne l'utilisent ensuite pas.
Pas de responsable après le pilote, qui n'atteint donc jamais la deuxième ligne.

Comment nous aidons

Nous sommes des ingénieurs en automatisation qui construisent de l'IA. Nous analysons les cas d'usage, connectons l'IA en toute sécurité à vos données PLC, SCADA, historian et maintenance, menons le pilote et déployons, en IT comme en OT. Voir Implémentation de l'IA et les démos.

Questions fréquentes

En combien de temps voit-on des résultats ?

Un assistant en lecture seule sur une ligne se teste rapidement, car il utilise des données qui existent déjà. Les cas d'ingénierie comme les migrations demandent plus de temps, car chaque résultat est testé.

Faut-il d'abord une plateforme de données ou un Unified Namespace ?

Non. Un bon premier cas d'usage lit les données qui existent déjà. Un Unified Namespace ou une plateforme de données aide quand vous passez à de nombreuses lignes et sites.

L'IA va-t-elle remplacer les opérateurs ou les ingénieurs ?

Non. Elle supprime du travail de recherche et de rédaction et donne des réponses plus rapides. Les personnes gardent les décisions, surtout en OT.

À quels systèmes peut-elle se connecter ?

À la plupart des systèmes SCADA, historian et GMAO, via des exports, des bases de données ou des API. Nous avons nos propres connecteurs pour Siemens TIA Portal, WinCC V7 et Ignition.

Implémenter l'IA dans l'OT et la production : guide pratique