Une nouvelle ligne de peinture démarre un lundi dans une usine automobile. Le vendredi, le tableau de bord OEE cesse de se rafraîchir pendant l’équipe de l’après-midi. La ligne produit. Les données qui le prouvent n’arrivent pas. En cause : trois automates d’ancienne génération que personne n’a correctement raccordés à la couche de données.

Petite histoire, gros problème. Tant que ces données manquent, la production ne voit pas comment tourne la ligne, la maintenance aborde l’équipe suivante à l’aveugle et le contrôle de gestion recalcule la productivité à la main. Chacun de ces points coûte de l’argent. Ensemble, ils expliquent pourquoi la connectivité industrielle a quitté la liste d’attente de la DSI pour rejoindre l’ordre du jour des directions d’usines de taille moyenne et grande.

La connectivité industrielle est la couche d’intégration qui permet aux machines, capteurs, automates et systèmes informatiques de l’atelier d’échanger des données opérationnelles de façon fiable et normalisée, quels que soient le constructeur et le protocole. Pour les industriels de l’automobile, de l’aéronautique, de la pharmacie ou des biens de consommation, c’est le socle des décisions en temps réel, de la maintenance prédictive, de la conformité et de la maîtrise des coûts. Ce guide explique ce qu’est la connectivité industrielle, où les projets échouent (équipements anciens, fossé IT/OT) et quels protocoles et technologies comptent vraiment. Il montre ensuite comment évaluer les fournisseurs, bâtir le business case et séquencer un déploiement qui porte les cas d’usage de l’industrie 4.0 et de l’IIoT, au lieu d’allonger la liste des pilotes à l’arrêt.

Ce que recouvre vraiment la connectivité industrielle

La connectivité industrielle, c’est l’intégration des équipements, des machines et des logiciels de l’atelier pour que les données circulent entre eux sous une forme normalisée et exploitable. Elle se trouve sous chaque initiative d’usine intelligente, quel que soit le nom que lui donne la plaquette.

Concrètement, elle relie quatre familles d’équipements. En bas, l’instrumentation de terrain : capteurs, variateurs, scanners. Au-dessus, les automates : PLC, DCS, CNC. Puis la supervision : SCADA, HMI, historians. Au sommet, l’informatique d’entreprise : MES, ERP, analytique, cloud. Le rôle de la couche de connectivité est de faire dialoguer ces quatre familles sans que l’équipe d’intégration réécrive deux fois le même traducteur.

Ce qui la distingue du réseau bureautique, c’est l’environnement. Le matériel encaisse la chaleur, les vibrations, la poussière et les perturbations électromagnétiques, et les données sont opérationnelles : valeurs de procédé en direct, alarmes, états machines, sur lesquels les décisions se prennent en secondes, pas après une revue trimestrielle.

Pourquoi le sujet est remonté jusqu’au comité de direction

Trois choses ont fait passer ce sujet du service automatisme à la salle du conseil.

Les programmes numériques échouent régulièrement sur la couche de connectivité. L’étude de McKinsey menée avec le Global Lighthouse Network du Forum économique mondial a montré qu’au moins 70 % des industriels restent bloqués dans le purgatoire des pilotes : des initiatives numériques qui font leurs preuves sur un pilote et ne passent jamais à l’échelle du réseau d’usines.

L’équipe opérations de McKinsey appelle la cause profonde le dernier kilomètre IT/OT et rappelle qu’une usine de taille moyenne fait tourner plus de 200 équipements de fournisseurs différents, chacun avec sa plateforme et son protocole. Un pilote de maintenance prédictive qui fonctionne avec 50 tags cale à 50 000 tags sur trois sites. Le modèle n’est pas le problème. La tuyauterie, si. Un comité qui a validé une première vague d’investissements numériques sans en voir le retour pose des questions plus dures avant la suivante.

Le coût d’une mauvaise connectivité se mesure. Le rapport Siemens True Cost of Downtime 2024 chiffre les pertes liées aux arrêts non planifiés dans les 500 plus grandes entreprises mondiales à environ 1 400 milliards de dollars par an, soit 11 % du chiffre d’affaires, contre 8 % en 2019. Dans l’automobile, une ligne à l’arrêt coûte jusqu’à 2,3 millions de dollars par heure. L’enquête Value of Reliability d’ABB montre que deux tiers des industriels subissent un arrêt non planifié au moins une fois par mois, pour un coût type d’environ 125 000 dollars par heure.

Une part significative de ces arrêts remonte à des données dont l’équipe avait besoin et qu’elle n’a pas eues à temps. Une usine qui a besoin de deux jours d’enquête pour répondre à « pourquoi le rendement a-t-il chuté sur la ligne 3 la semaine dernière ? » prend chaque décision opérationnelle plus lentement et plus cher que nécessaire. Celles qui répondent en quelques minutes réduisent le MTTR, améliorent le rendement au premier passage et libèrent du temps d’ingénierie pour un travail qui capitalise.

Les clients et les régulateurs posent la question. Les grands donneurs d’ordre de l’automobile et de la pharmacie exigent désormais de leurs fournisseurs des preuves de cybersécurité, de traçabilité et de maîtrise des échanges de données. Dans l’UE, la réglementation renforce la tendance : la directive NIS2, transposée en France par la loi résilience sous le contrôle de l’ANSSI. Nous traitons à part ce que NIS2 implique pour les réseaux OT. Où que vous opériez, une usine incapable de montrer des flux de données auditables de la machine au cloud perd des appels d’offres qu’elle gagnait autrefois sur le prix.

Comment fonctionne la connectivité industrielle ?

La connectivité industrielle fonctionne ainsi : un logiciel intermédiaire (middleware) traduit les protocoles propriétaires des équipements dans un format commun, puis transmet les données aux systèmes de niveau supérieur par des interfaces normalisées et indépendantes des constructeurs. Un point d’intégration unique, au lieu d’un pilote par système.

Au niveau du terrain, les équipements parlent le dialecte choisi par leur fabricant : Modbus TCP, EtherNet/IP, PROFINET, IO-Link et des dizaines d’autres. Une plateforme de connectivité exécute des pilotes qui traduisent chaque dialecte en un modèle de données interne unique, puis le publie vers le haut par deux standards neutres : OPC UA pour les échanges client-serveur industriels, et MQTT avec Sparkplug B pour le modèle publication-abonnement et le cloud. Par ces mêmes interfaces, robots, machines CNC et autres équipements automatisés publient leur état aux côtés du reste de la ligne, si bien que les systèmes en aval voient une image cohérente au lieu d’une douzaine de silos.

Résultat : SCADA, MES, historians et analytique cloud consomment les mêmes données d’atelier par un seul point d’intégration, au lieu d’entretenir chacun sa bibliothèque de pilotes. Ce découplage est tout l’argument économique. L’IT et l’OT cessent de se disputer l’accès aux données et commencent à les partager.

1
150+

150+ protocoles industriels parlés par vos machines

2
1

1 flux de données gouverné, servi en OPC UA et MQTT par le middleware de connectivité

3
0

0 intégration point à point à maintenir pour le SCADA, le MES, les historians et le cloud

Six protocoles pour 90 % de l’atelier

ProtocoleCoucheUsage type
Modbus TCP / RTUéquipementautomates anciens, variateurs, compteurs d’énergie
EtherNet/IPéquipement, automateécosystèmes Allen-Bradley / Rockwell
PROFINETéquipement, automateSiemens et écosystèmes européens
IO-Linkcapteurcapteurs et actionneurs intelligents
OPC UAcouche de donnéeséchange OT/IT indépendant des constructeurs
MQTT (Sparkplug B)couche IIoTedge vers cloud, Unified Namespace

Six protocoles couvrent à peu près 90 % d’un atelier type. Les quatre premiers gèrent les échanges courts entre automates et équipements. OPC UA et MQTT transportent des données contextualisées à travers la frontière OT/IT. Les architectures modernes utilisent les deux, avec une plateforme de connectivité au milieu pour la traduction.

Pour le transport, l’Ethernet industriel reste la norme parmi les solutions réseau conçues pour l’usine, avec des liaisons gigabit à faible latence pour les applications critiques. Le sans-fil (5G privée, Wi-Fi 6) prend le relais là où le câble n’est pas praticable, et l’edge computing ferme les boucles temps réel localement pendant que le cloud gère l’analytique de long terme. Quel que soit le mélange, les solutions IIoT doivent relier l’IT et l’OT tout en restant interopérables dans des conditions difficiles : le réseau doit continuer à transmettre malgré la chaleur, les perturbations, les coupures d’alimentation et tout ce qu’une usine peut lui infliger.

Pourquoi c’est difficile

Le plus dur n’est ni le câblage ni les protocoles. C’est la réalité opérationnelle.

Les équipements des années 1990

Un industriel européen type fait tourner des équipements des années 1990. L’automate fonctionne, l’OEM a disparu, le protocole n’est pas documenté. Les plateformes de connectivité justifient leur prix en embarquant des pilotes pour ces orphelins : la ligne reste en service pendant que la couche de données se modernise autour d’elle.

Le fossé IT/OT

L’IT optimise pour la confidentialité et les cycles de correctifs. L’OT optimise pour la disponibilité et un gel des changements sur cinq ans. Chacun a raison sur son périmètre, et chacun a tort quand il applique son manuel de l’autre côté du pare-feu. Les projets qui réussissent traitent cela comme un problème de coordination, pas de technologie.

Les conditions de l’atelier

Une armoire de commande dans une aciérie tourne à 50 °C, avec des niveaux de perturbation qui détruisent en quelques semaines un commutateur grand public. Une part importante des projets IIoT n’échoue pas parce que l’architecture était mauvaise, mais parce que le réseau a été spécifié comme pour un bureau.

L’exposition aux attaques

Chaque équipement de terrain doté d’une adresse réseau élargit la surface d’attaque, et les clients l’auditent de plus en plus. L’époque où l’isolement physique tenait lieu de stratégie de sécurité s’est achevée à peu près au moment où il a cessé d’être réel.

Le coût d’une erreur est concret : arrêts, lots mis au rebut, expéditions manquées et appels d’offres perdus remontent, plus souvent qu’on ne l’admet, à une couche de connectivité qui n’a jamais été correctement conçue.

Ce qu’apporte une connectivité fiable à l’usine 4.0

Une fois que les données circulent de façon fiable, les cas d’usage qui justifient l’investissement dans la fabrication numérique deviennent possibles.

La maintenance prédictive transforme les mesures de vibration, de température et de courant en alertes précoces et remplace l’entretien à intervalle fixe par des interventions conditionnelles ; une meilleure collecte de données sur les équipements connectés améliore les décisions en maintenance comme en production. L’étude Siemens attribue à l’adoption de la maintenance prédictive la baisse des arrêts non planifiés d’une grande usine de 39 heures par mois en 2019 à 27 heures en 2024, principale raison pour laquelle le coût total des arrêts n’a pas explosé alors que chaque heure perdue coûtait plus cher.

Le suivi de production en temps réel avec l’OEE donne au directeur d’usine une image vivante de la performance plutôt qu’un rapport de la veille, révèle les goulets d’étranglement et accélère les changements de série. L’optimisation des procédés devient mesurable, parce que les données qui l’alimentent sont cohérentes d’une machine et d’un site à l’autre.

La même couche de données nourrit les usages plus récents. Les jumeaux numériques, répliques virtuelles d’actifs physiques, ont besoin d’une connectivité temps réel pour refléter et simuler la performance. Le suivi énergétique connecté réduit les factures et les émissions. Les systèmes de vision et de capteurs connectés détectent la dérive qualité avant qu’elle ne se transforme en rebut, et les systèmes de sécurité connectés peuvent ralentir ou arrêter l’automatisme quand une personne entre dans une zone définie.

C’est cela que l’on désigne par industrie 4.0 ou internet industriel des objets. L’étiquette change tous les quelques années. L’exigence, non : un moyen fiable, sécurisé et indépendant des constructeurs de faire circuler les données entre les machines, les systèmes et les personnes qui décident dans les procédés industriels.

Comment construire le business case

Un business case de connectivité repose sur trois chiffres que la direction financière peut vérifier, pas sur une vision technologique.

Votre coût d’arrêt par heure. Prenez une ligne représentative, multipliez le débit perdu par la marge sur coûts variables, ajoutez la main-d’œuvre inoccupée, le fret express et les pénalités contractuelles. La plupart des usines qui font l’exercice sérieusement découvrent que le chiffre réel vaut deux à trois fois celui du rapport de maintenance, parce que les coûts indirects (rebuts au redémarrage, perte de rendement pendant la montée en cadence, pièces au tarif urgent) n’apparaissent jamais dans le journal des arrêts. Si votre chiffre approche la médiane ABB de 125 000 dollars par heure, même une réduction modeste des incidents rembourse plusieurs fois la couche de connectivité.

Vos heures d’ingénierie passées à déplacer des données à la main. Comptez les heures que vos ingénieurs procédés, planificateurs de maintenance et analystes passent chaque mois à exporter, rapprocher et ressaisir des données entre systèmes. Dans nos déploiements, c’est régulièrement le plus gros poste caché : une usine de taille moyenne qui brûle 200 à 400 heures d’ingénierie par mois en tuyauterie manuelle de données est monnaie courante, et ce sont vos profils les plus chers et les plus difficiles à recruter qui font un travail qu’une licence de middleware accomplit pour une fraction du coût.

Votre initiative à l’arrêt. Si un programme de maintenance prédictive, d’analyse qualité ou d’énergie est déjà approuvé et bloqué à la couche de données, l’investissement en connectivité hérite du business case de ce programme. Vous ne financez pas une valeur nouvelle ; vous débloquez une valeur que le comité a déjà signée.

Additionnez ces trois chiffres et le dossier s’écrit généralement tout seul. Ce qui tue les propositions de connectivité, ce n’est pas une économie faible ; c’est de présenter le projet comme une dépense d’infrastructure au lieu d’en faire la clé de retours auxquels l’organisation s’est déjà engagée.

La séquence de déploiement qui fonctionne

1
Audit

2 à 3 semaines

2
Architecture

2 à 4 semaines

3
Adéquation plateforme

1 à 2 semaines

4
Pilote

4 à 8 semaines

5
Déploiement

6 à 12 semaines par site

6
Gouvernance

permanente

La plupart des échecs de connectivité sont des échecs de séquence. Le schéma qui marche est le même dans l’automobile, les biens de grande consommation et la pharmacie, et il tient en six étapes.

1. Audit (2 à 3 semaines). Cartographiez ce que vous avez réellement : chaque actif producteur de données, son protocole, son propriétaire et l’endroit où ses données vont (ou ne vont pas). C’est l’étape que la plupart des organisations sautent, et c’est pour cela que leurs schémas d’architecture décrivent une usine qui n’existe pas. Le livrable : un inventaire des actifs et des flux de données, plus la liste des équipements non gérés dont personne ne connaissait la présence sur le réseau. Sans arrêt de production.

2. Architecture (2 à 4 semaines). Décidez du schéma cible avant de choisir un logiciel. Pour la plupart des industriels multisites, ce schéma est l’Unified Namespace : une couche de données unique et centralisée qui sert de source de vérité à tous les systèmes, où chaque producteur et chaque consommateur de données se connecte une fois au lieu d’entretenir des intégrations point à point. Fixez ici vos conventions de nommage et vos modèles de données, car les rattraper après la mise en service de 10 000 tags est un travail pénible. Gardez l’architecture cible modulaire, pour éviter la dépendance à un fournisseur et laisser de la place aux extensions.

3. Adéquation de la plateforme (1 à 2 semaines). C’est seulement maintenant qu’il faut établir la liste restreinte des logiciels, sur la base de l’audit et de l’architecture plutôt que d’une démonstration de fournisseur. La section ci-dessous explique en quoi les principales plateformes diffèrent.

4. Pilote (4 à 8 semaines). Une ligne ou une cellule, mais conçue comme une tranche de l’architecture cible, pas comme un jetable. Le pilote doit valider les conventions de nommage, le modèle de sécurité et le passage de relais à l’équipe qui l’exploitera, parce que ce sont ces trois choses qui cassent à l’échelle. Un pilote qui prouve seulement que « les données peuvent circuler » ne prouve rien que vous ne sachiez déjà.

5. Déploiement (6 à 12 semaines par site). Déployez site par site avec les modèles validés par le pilote. C’est là que la discipline initiale paie : conventions et modèles fixés, chaque site supplémentaire relève de la configuration, pas de la conception, et la configuration à distance devient un moyen pratique de déployer et d’administrer les équipements sur plusieurs sites.

6. Gouvernance (permanente). Attribuez la responsabilité de l’espace de noms, du cycle de vie des certificats et de la gestion des changements. La connectivité n’est pas un projet qui se termine ; c’est une couche qui survit à toutes les applications construites dessus.

Respectez la séquence et l’efficacité opérationnelle progresse pendant que vos équipes se concentrent sur la valeur, pas sur les reprises. Inversez-la (en général en commençant par l’étape 3, parce que la démo d’un fournisseur a convaincu) et vous rejoignez les 70 % du purgatoire des pilotes.

Huit questions à poser au fournisseur

Avant de signer quoi que ce soit, posez-les à votre liste restreinte. Les réponses séparent les plateformes de production des plateformes de laboratoire.

  1. Parmi les protocoles de notre audit, lesquels prenez-vous en charge nativement, et lesquels exigent un développement spécifique ? Demandez la liste des pilotes par écrit, pas un pourcentage.
  2. Que se passe-t-il à 50 000 tags sur trois sites ? Demandez un client de référence à cette échelle, pas une diapositive de benchmark.
  3. Comment la sécurité est-elle gérée par défaut : certificats, chiffrement, authentification des utilisateurs ? « Configurable » n’est pas synonyme d’« activé par défaut ».
  4. Que devient le modèle de licence à l’échelle ? Par tag, par pilote, par serveur ou par abonnement, les coûts sur cinq ans divergent fortement ; modélisez votre parc cible, pas le pilote.
  5. Comment traitez-vous nos équipements anciens et orphelins ? Citez les automates des années 1990 relevés dans votre audit et observez la réaction.
  6. Comment se passent les mises à jour et les correctifs côté OT ? Une plateforme qu’on ne peut pas corriger sans arrêter la production ne passera pas un audit de sécurité.
  7. Qui met en œuvre, et qui assure le support à deux heures du matin ? Une plateforme ne vaut que par l’intégrateur et la chaîne de support qui la portent.
  8. Quelle est la porte de sortie ? Si la question « comment récupérons-nous nos modèles de données ? » reste sans réponse, vous achetez une dépendance, pas de la connectivité.

Kepware ou Ignition : choisir la plateforme

La catégorie logicielle derrière tout cela est le middleware de connectivité industrielle. Le marché compte Kepware (Velotic), Ignition (Inductive Automation), HighByte, Cogent DataHub et AVEVA PI System. Pour les industriels de taille moyenne à grande qui bâtissent une architecture indépendante des constructeurs, deux plateformes couvrent la plupart des décisions en pratique, et ce sont les deux que TT PSC met en œuvre directement.

Kepware est un middleware de connectivité au sens strict. Il traduit plus de 150 protocoles industriels en un flux de données unique et l’expose via OPC UA, MQTT, REST et des connecteurs cloud directs. Il l’emporte quand la priorité est une large couverture des équipements anciens, un serveur OPC UA de qualité production et une topologie qui passe d’un pilote mono-serveur à une architecture UNS multisite sans réécriture.

Ignition a un périmètre plus large : connectivité plus SCADA, HMI, gestion des alarmes et reporting dans une seule plateforme, avec une licence sans limite de tags. Il l’emporte quand l’exigence est une plateforme unique pour la connectivité et la visualisation, en particulier sur les sites neufs ou quand un SCADA vieillissant doit être remplacé.

La réponse honnête à « lequel ? » dépend du parc existant. Une usine standardisée sur Allen-Bradley, avec une séparation nette entre connectivité et SCADA, relève généralement de Kepware. Un industriel régional des biens de consommation qui consolide ses fournisseurs sur cinq sites relève généralement d’Ignition. Beaucoup de parcs réels utilisent les deux.

TT PSC est intégrateur et revendeur agréé Kepware au sein du programme partenaires Velotic, et intégrateur Inductive Automation de niveau Gold. Nous déployons les deux plateformes dans l’automobile, les biens de consommation, la pharmacie et l’industrie manufacturière discrète au Royaume-Uni, dans la zone DACH, en Scandinavie, au Benelux, en France et en Pologne. La recommandation qu’un client reçoit de nous repose sur l’adéquation à son parc, pas sur la marge de licence.

Par où commencer

La connectivité industrielle est l’endroit où la plupart des programmes de transformation numérique réussissent ou s’enlisent, et la différence tient rarement à la plateforme. Elle tient à la séquence : audit, architecture, adéquation de la plateforme, pilote, déploiement, gouvernance. TT PSC accompagne les industriels sur toute cette séquence comme partenaire conseil, pas seulement comme revendeur.

Si votre initiative numérique ou IA est bloquée à la couche de données, la conversation commence par votre architecture actuelle : ce que vous avez, ce que vous cherchez à connecter et où se trouve réellement le goulet d’étranglement. Si vous cadrez un déploiement Kepware, nos services de licence et de mise en œuvre couvrent tout le chemin, du dimensionnement à la production. Et si vous opérez dans l’UE avec la sécurité OT à votre agenda de conformité, un test de préparation NIS2 gratuit prend dix minutes et vous dit où vous en êtes.

La connectivité industrielle est l’intégration des machines, capteurs, automates et systèmes logiciels de l’atelier pour que les données opérationnelles circulent entre eux de façon fiable et normalisée. Elle recouvre les protocoles, les réseaux et le middleware qui acheminent les données des équipements vers les systèmes et les personnes qui agissent dessus.