L'IoT industriel en pratique : ce qui différencie les projets pilotes des projets à grande échelle

Il existe un schéma récurrent dans les projets IoT industriels que tout ingénieur en automation reconnaît après quelques années de carrière : le pilote fonctionne. Les dix capteurs transmettent, le tableau de bord affiche les données en temps réel, le directeur de l'usine s'enthousiasme et autorise l'agrandissement. Six mois plus tard, avec deux cents capteurs installés, le système commence à perdre des données, la latence augmente, les alertes n'arrivent plus au bon moment et l'équipe informatique se bat avec l'équipe d'automatisation pour savoir qui est responsable de quelle partie de l'infrastructure. L’expansion s’arrête. Le projet reste dans les limbes. L’investissement ne produit pas le rendement escompté. Ce qui différencie les entreprises capables de faire évoluer l'IoT industriel de celles bloquées dans des projets pilotes, ce n'est pas la technologie : c'est une décision architecturale prise avant d'installer le premier capteur.

Le problème de réseau que le pilote ne révèle pas

Les environnements industriels ont été conçus pour fonctionner avec des réseaux OT (Operational Technology) qui sont physiquement et logiquement séparés des réseaux informatiques d'entreprise. Cette séparation a une justification historique : les systèmes SCADA, les automates et les réseaux de terrain tels que Profibus et Modbus ont été conçus pour une fiabilité déterministe dans des environnements soumis à des interférences électromagnétiques, et non pour une connectivité IP avec le monde extérieur. Le résultat est que la plupart des installations industrielles disposent d’un réseau OT qui fonctionne sans problème depuis des années et d’un réseau informatique d’entreprise qui connecte les ordinateurs, les imprimantes et les systèmes de gestion. L’IoT industriel nécessite que les deux se parlent, et c’est dans ce processus que la plupart des projets commencent à rencontrer des problèmes.

La convergence OT/IT n’est pas un câble et un commutateur. Il s'agit d'un projet de sécurité, de gouvernance et d'architecture qui implique de décider quelles données peuvent traverser le périmètre entre les deux environnements, à quelle fréquence, avec quel protocole de traduction et avec quel système d'authentification. Dans un projet pilote avec dix capteurs, il est possible de créer une solution de contournement : une passerelle qui prend les données des capteurs et les publie sur le réseau informatique sans toucher au réseau OT. À grande échelle, cette solution de contournement crée des points de défaillance uniques, des problèmes de latence et des surfaces d'attaque que ni les équipes OT ni les équipes informatiques ne souhaitent gérer.

La bonne décision se prend avant le projet pilote : définir l'architecture réseau complète pour l'échelle cible, y compris le modèle de segmentation, les protocoles de communication intercouches et le modèle de gouvernance de qui exploite quoi. La plupart des entreprises prennent cette décision après le projet pilote, alors qu'il existe déjà des pressions sur les délais et une résistance interne des deux côtés de la fracture OT/IT.

Volume de données : quoi traiter, où et quand

Un capteur de vibrations de roulements à haute fréquence peut générer entre 5 et 50 mégaoctets de données par heure. Une caméra de vision par ordinateur pour l’inspection qualité peut générer des gigaoctets par heure. Dans un projet comprenant des centaines de points de surveillance, la transmission mathématique des données vers le cloud central devient rapidement irréalisable, à la fois en termes de coût de bande passante et de latence pour les applications nécessitant une réponse en temps réel.

La décision de savoir où traiter ce qui doit être fait avant de faire évoluer l'infrastructure. Le modèle général qui fonctionne à grande échelle répartit le traitement sur trois couches : sur l'appareil lui-même ou sur une passerelle locale, un filtrage et un prétraitement ont lieu, éliminant les données redondantes et détectant les événements nécessitant une action immédiate. Au niveau de la couche périphérique (serveurs dans l'usine ou dans un entrepôt technique), le traitement d'analyse le plus complexe a lieu et ne nécessite pas d'envoi vers le cloud, y compris les modèles de détection d'anomalies qui nécessitent une faible latence. Le cloud central héberge l'historique, la formation des modèles, la corrélation entre plusieurs usines et les tableaux de bord exécutifs.

Cette division semble évidente lorsqu'elle est décrite ainsi, mais la plupart des pilotes sont conçus pour tout envoyer vers le cloud car c'est le moyen le plus simple de démontrer le concept. Lorsque le projet évolue et que le coût de la transmission des données apparaît sur la facture cloud, ou lorsque la latence de réponse ne répond pas aux exigences opérationnelles, la refonte architecturale coûterait deux fois plus cher que si elle avait été réalisée dès le début.

Gestion des appareils : le problème qui grandit avec le carré

L'installation d'une centaine de capteurs est un projet d'ingénierie. Gérer une centaine de capteurs sur trois ans est une opération. La différence entre les deux réside dans un ensemble de défis qui n'apparaissent pas dans la démo : mettre à jour le firmware des appareils sur le terrain sans interrompre le fonctionnement, remplacer les appareils défectueux sans perdre le contexte de configuration, fournir de nouveaux appareils dans un délai acceptable et surveiller l'état du parc d'appareils pour détecter les pannes avant la perte de données.

Les projets qui touchent des milliers d'appareils sans plate-forme de gestion adéquate constatent que le coût opérationnel de la maintenance de la flotte dépasse les avantages des analyses que le projet était censé fournir. Dans une usine comptant un millier de capteurs, un taux de défauts de 5 % par an – ce qui est prudent pour du matériel en environnement industriel – signifie cinquante remplacements par an. Si le processus de remplacement implique la configuration manuelle de chaque appareil, cela représente un temps d'ingénieur qui n'était pas prévu dans le budget.

Les plates-formes de gestion des appareils IoT (AWS IoT Device Management, Azure IoT Hub ou des solutions telles que Balena pour les environnements Linux embarqués) existent précisément pour résoudre ce problème. Mais la décision de les adopter dès la phase pilote a un coût de mise en œuvre rarement inclus dans le budget de validation de concept. Le résultat est que le pilote utilise une configuration manuelle et des scripts maison, et lorsque le projet évolue, la migration vers une plate-forme appropriée doit se faire avec des appareils déjà sur le terrain, ce qui est beaucoup plus complexe que la mise en œuvre de la plate-forme à partir de zéro.

Sécurité dans les environnements OT : une problématique différente de celle de l'informatique d'entreprise

La sécurité des réseaux OT a toujours été résolue par l’isolement physique : ce qui n’est pas accessible de l’extérieur ne peut pas être attaqué de l’extérieur. L'IoT industriel connecte cet environnement au monde extérieur, et les appareils ajoutés à l'environnement OT ont rarement été conçus avec la même rigueur de sécurité que les équipements industriels déjà existants. Un capteur de température au firmware obsolète, accessible via IP, est un vecteur d’attaque qui n’existait pas il y a dix ans.

Les implications sont concrètes. L’attaque contre Colonial Pipeline en 2021 n’a pas directement compromis les systèmes OT, mais l’entreprise a arrêté les systèmes de manière préventive en raison d’un manque de visibilité et de confiance dans l’intégrité du réseau. Au Brésil, les centrales électriques, les systèmes d’approvisionnement en eau et la distribution d’énergie sont de plus en plus exposés à mesure qu’ils connectent davantage d’appareils à l’environnement industriel. Le coût d’un incident de sécurité OT n’est pas seulement un arrêt de production : c’est aussi la perte de confiance dans l’intégrité des données historiques, qui invalide toutes les analyses produites par le projet IIoT.

Le modèle de sécurité pour l'IoT industriel doit inclure une segmentation du réseau qui limite le rayon d'impact d'un appareil compromis, une authentification de l'appareil par certificat ou jeton qui empêche un appareil non autorisé d'entrer dans le réseau et une surveillance du trafic anormal qui détecte le comportement non standard de l'appareil. En principe, ce modèle n'est pas différent du modèle de sécurité informatique de l'entreprise : il est différent dans son exécution, car les protocoles OT, la latence acceptable pour l'analyse de sécurité et les outils disponibles sont spécifiques à l'environnement industriel.

Le modèle architectural qui évolue : ce que les entreprises qui réussissent font différemment

Les entreprises qui réussissent à faire évoluer l’IoT industriel partagent une caractéristique : elles prennent la décision architecturale complète avant d’installer le premier capteur, et elles considèrent le pilote comme une validation de l’architecture, et non comme une démonstration de capacité technologique. Le projet pilote ne doit pas prouver que les capteurs fonctionnent – cela est déjà connu. Le projet pilote consiste à valider que l'architecture réseau, le traitement, la gestion des appareils et la sécurité choisis répondront à l'échelle cible.

L’autre élément commun est la décision explicite quant à savoir qui exploite chaque niveau du système. Dans les environnements industriels, la frontière entre IT et OT est une frontière culturelle autant que technique. Les projets qui ne définissent pas explicitement quelle équipe gère quoi (et qui ne créent pas de modèle d'escalade des conflits entre les deux équipes) découvrent à grande échelle que le problème n'est pas la technologie, mais la gouvernance. Qui est responsable du capteur de vibrations ? Par qui la passerelle Edge est-elle gérée ? Lorsque les données n’arrivent pas dans le tableau de bord, quelle est la démarche de diagnostic et à quel moment le ticket passe-t-il d’une équipe à l’autre ?