L’expression « DataOps industriel » est passée d’un sujet confidentiel à un terme largement accepté ces dernières années. Le travail qui consiste à assurer le transfert fiable des données d’usine, des automatismes vers l’IT, à la modélisation pertinente de ces données, à la sécurisation du périmètre et à la gestion des accès, n’est pas une idée nouvelle. La nouveauté réside dans le fait que l’industrie prend conscience de son importance et s’accorde désormais sur un nom.

Le « DataOps industriel » relève de l’ingénierie des données, mais il s’agit également d’une architecture de sécurité, d’un enjeu de protection des investissements et du fondement de toute stratégie d’IA sérieuse dans tous les secteurs industriels, mais aussi dans les infrastructures énergétiques, les infrastructures de transport et les bâtiments connectés.

Le DataOps industriel constitue une couche dédiée entre l’OT et l’IT.

L’expression « DataOps industriel » désigne la migration des données de production des systèmes OT vers les systèmes IT et le cloud de manière fiable et validée, qui s’appuie sur un modèle d’information pertinent, accessible via des interfaces standards, sécurisées entre l’OT et l’IT ; l’ensemble étant administré et géré par une équipe qui organise et sécurise les flux et les autorisations d’accès aux données entre les systèmes.

La plupart des usines réalisent déjà des échanges entre l’OT et l’IT. Le problème est qu’elles le font de manière « cloisonnée », projet après projet : chaque système IT dispose de son canal d’échange avec l’OT et fait sa propre mise en forme de données. Ainsi, pour un même ensemble de données OT, le MES redéfinit le mapping des tags, le projet d’analyse de données construit son propre pipeline, chaque applicatif cloud remet en question les unités et la nomenclature des données. Le « DataOps industriel » est le résultat obtenu en centralisant ce travail sur cet ensemble de données OT dans une couche dédiée, et en le mettant à disposition des systèmes IT.

Des études sectorielles montrent que les data scientists consacrent 60 à 80 % de leur temps à la préparation des données. Dans le cas des données industrielles, cette part est probablement encore plus élevée, car chaque machine, chaque ligne de production stocke les tags différemment, et ceux-ci sont souvent illisibles pour un humain.

Sans couche DataOps, chaque nouveau projet doit partir de zéro et le budget est mis à rude épreuve avant même que le problème métier ne soit véritablement abordé. Avec le DataOps industriel, la modélisation et l’harmonisation sont effectuées une seule fois, au plus près de la source, par des experts du domaine et du processus. Tous les systèmes en aval bénéficient alors de données homogènes et contextualisées : extensions MES, outils d’analyse, agents d’IA, systèmes cloud.

La plupart des articles sur le DataOps industriel abordent la sécurité en une phrase, puis passent à autre chose. C’est étonnant, car avec la directive NIS2 et les normes IEC 62443, la sécurité n’est plus un sujet secondaire et l’architecture qui résout les problèmes de données résout également une grande partie des problèmes de sécurité.

Ce que NIS2 attend d’une usine se résume ainsi : un contrôle d’accès documenté, une segmentation du réseau entre les environnements OT et IT, des communications chiffrées, des ruptures de technologies entre l’OT et l’IT, une journalisation centralisée et un signalement rapide des incidents.

Une couche DataOps industriel correctement conçue prend en charge la plupart de ces exigences. Elle isole le réseau d’automatisation afin qu’aucun utilisateur ou application IT ne puisse communiquer directement avec un automate programmable. Elle applique un contrôle d’accès unique pour chaque requête de données de l’usine. Elle met fin aux protocoles d’automatisation non sécurisés existants au sein de la zone OT et expose l’accès externe via des protocoles sécurisés modernes. Elle journalise les flux de données qui franchissent la frontière.

La frontière qui filtre et harmonise les données est également le lieu idéal pour appliquer les règles de sécurité, et une grande partie des exigences de base de NIS2 découle naturellement d’une gestion rigoureuse des données.

Si votre architecture « DataOps » ne respecte pas cette frontière, vous rencontrez deux problèmes simultanément : un problème de données et un problème pour les audits internes de conformité à la NIS2.

Une bonne décision architecturale dans la mise en œuvre d’un DataOps industriel permet de résoudre ces deux problèmes.

Le DataOps industriel comme frontière de sécurité entre l’OT et l’IT.

La modélisation des données représente la part la plus importante du coût d’un projet de DataOps industriel. C’est aussi là que le verrouillage éventuel par le fournisseur s’installe insidieusement.

Déterminer à quoi ressemblent les données d’une pompe, d’un lot, d’une cuve ou d’un échantillon qualité demande un effort considérable, et la majeure partie du travail d’intégration d’une plateforme de DataOps est consacrée à cette tâche. Si la plateforme utilise un format de modèle propriétaire, chaque heure passée à modéliser les actifs devient un investissement dans l’écosystème du fournisseur de la plateforme. Bien que les données vous appartiennent encore sur le papier, leur signification réside dans l’outil d’un tiers.

Nous avons tous constaté ce problème récemment avec plusieurs produits du secteur des logiciels industriels : des changements de modèles de tarification ou un arrêt discret du développement ont piégé les clients, les contraignant à utiliser une plateforme qu’ils ne choisiraient plus. Remplacer une plateforme de DataOps industriel basée sur un modèle propriétaire revient à refaire la partie la plus coûteuse du projet ; en pratique, elle n’est donc pas remplacée.

La solution ? Des modèles d’information ouverts. Deux familles pertinentes, reposant sur le même format de balisage et se chevauchant quelque peu, sont les spécifications OPC UA Companion et les profils CESMII pour la fabrication intelligente. Lorsque la modélisation est basée sur des standards ouverts, elle reste compatible avec les changements de fournisseurs. Les nouveaux appareils et systèmes informatiques déjà conformes à ces standards nécessitent un effort d’intégration considérablement réduit.

Le choix entre une sémantique ouverte et une sémantique propriétaire est la seule décision architecturale véritablement cruciale pour l’ensemble du projet. La plupart des autres choix peuvent être modifiés ultérieurement.

« Les données vous appartiennent, mais pas le modèle » vs « Le travail de modélisation vous suit » – le choix architectural unique qui détermine si votre investissement DataOps est récupérable ou non.

Nombreux sont à supposer que l’IA est si performante qu’elle peut analyser des données brutes d’usine et en déduire des informations par elle-même. C’est la porte ouverte à l’échec.

Les modèles de langage, les pipelines d’apprentissage automatique et les agents autonomes ont tous besoin de contexte. Un modèle qui ignore si une température est exprimée en degrés Celsius ou Fahrenheit, ou si FT-101 est un débitmètre sur la ligne 3 ou la ligne 7, produira des résultats absurdes sans que cela ne soit signalé. Un agent incapable de distinguer une opération de maintenance d’une modification de consigne prendra des décisions indésirables.

Des données contextualisées et correctement sémantiques, c’est précisément ce que produit le DataOps industriel. La Fondation OPC, CESMII et d’autres organisations travaillent déjà sur des protocoles permettant aux agents d’IA d’exploiter les données industrielles de manière structurée. Ces protocoles ne sont utiles que si les données de sortie sont cohérentes.

En fin de compte, la taille du modèle importe moins que la qualité des données qui l’alimentent. Les usines qui tireront le meilleur parti de l’IA au cours des prochaines années seront celles dont les données sont déjà structurées et prêtes à être utilisées par les agents, ou presque.

Les grands modèles d’IA ne corrigent pas les données erronées. Seule une sémantique cohérente à la source le permet.

Si les constats ne sont pas nouveaux, la nouveauté réside dans le fait que l’industrie s’est enfin accordée sur le nom, l’architecture et le vocabulaire. Cette harmonisation fait de ce moment le moment idéal pour considérer sérieusement le déploiement d’une plateforme de DataOps industriel.

Prosys Forge est une plateforme de DataOps industriel qui répond aux enjeux et besoins décrits dans cet article :

La modélisation des informations dans Forge utilise les spécifications OPC UA Companion et les profils de fabrication intelligente CESMII. La frontière OT intègre un contrôle d’accès basé sur les rôles et une journalisation d’audit, de sorte que la même configuration couvre une grande partie des exigences de la directive NIS2 et des normes IEC 62443. De plus, les données fournies en aval par Forge sont correctement contextualisées, ce qui permet aux agents d’IA de travailler avec des informations de qualité plutôt que de produire des réponses incohérentes à partir de données brutes.

Prosys OPC travaille dans ce domaine depuis vingt ans. Forge est le produit de l’expérience des besoins réels des usines en matière de couche DataOps.

Cet article est une adaptation d’un article de Pyry Grönholm, CEO de Prosys OPC, avec son aimable autorisation.

The Necessity of Industrial DataOps, Explained | LinkedIn