Programmable logic controllers and the information system: the reference guide

Dans la plupart des usines, deux mondes cohabitent sans vraiment se parler. D’un côté, les automates programmables, qui lisent des capteurs et commandent des actionneurs en quelques millisecondes, programmés par des automaticiens, souvent conçus pour durer vingt ans. De l’autre, le système d’information : gestion de production, qualité, maintenance, finance, avec ses cycles de mise à jour courts et ses équipes informatiques. Entre les deux, des ressaisies, des fichiers exportés, des tableurs, et beaucoup d’informations perdues.

Les relier est l’un des chantiers les plus rentables de l’industrie, et l’un des plus risqués. Ce dossier suit le chemin d’une donnée, depuis le capteur jusqu’à la décision, et s’arrête à chaque étape sur les choix qui comptent.

Ce qu’est un automate, et pourquoi il ne ressemble pas à un serveur

Un automate programmable industriel est un ordinateur spécialisé. Il exécute un programme en boucle : lire toutes ses entrées, calculer, écrire toutes ses sorties, recommencer, à un rythme qui se compte en millisecondes. Cette boucle, appelée cycle, doit être prévisible : si elle prend soudain trop de temps, une machine peut se dérégler ou devenir dangereuse.

Les programmes sont écrits dans des langages normalisés par la norme IEC 61131-3 : schéma à contacts hérité des armoires à relais, blocs fonctionnels, texte structuré proche des langages informatiques classiques, et grafcet pour décrire des séquences. Leur logique est souvent lisible par un électricien de maintenance, ce qui est voulu : c’est lui qui interviendra à 3 heures du matin.

Trois différences avec l’informatique de gestion expliquent la plupart des malentendus.

La priorité est la disponibilité et la sécurité des personnes, pas la confidentialité. Un automate que l’on redémarre pour appliquer un correctif, c’est une ligne arrêtée. Une mise à jour se planifie sur un arrêt technique, parfois une fois par an.

La durée de vie se compte en décennies. Des automates installés il y a vingt ou trente ans fonctionnent encore, avec des systèmes et des protocoles d’époque, sans mécanisme d’authentification.

Le programme est le savoir-faire. Les réglages, temporisations et séquences encodent des années d’ajustements. Les perdre, ou les modifier sans trace, est un risque industriel majeur.

Le chemin d’une donnée : les niveaux ISA-95

Pour que les automaticiens et les informaticiens parlent la même langue, le modèle ISA-95, repris par la norme internationale IEC 62264, découpe l’entreprise industrielle en niveaux. Il ne décrit pas une technologie, mais des responsabilités et des horizons de temps.

Au niveau 1, un capteur mesure une température. Au niveau 2, l’automate l’utilise pour réguler un four, et la supervision l’affiche à l’opérateur avec une alarme si elle dérive. Au niveau 3, le système de gestion des opérations de production (souvent appelé MES) l’associe à un lot, à un ordre de fabrication et à un contrôle qualité. Au niveau 4, le progiciel de gestion intégré en tire des coûts, des délais et des engagements clients.

La valeur naît des liens entre niveaux. Une température de four associée au lot qui y est passé permet de comprendre un défaut de qualité trois semaines plus tard. Un compteur de cycles associé au plan de maintenance permet d’intervenir avant la panne. Sans ces liens, chaque niveau optimise dans son coin.

Les protocoles : la tour de Babel industrielle

Les automates parlent de nombreux protocoles, souvent liés à un constructeur ou à une époque. Pour les relier au système d’information, il faut choisir comment les traduire.

OPC UA s’est imposé comme la référence pour l’interopérabilité entre les machines et les systèmes de niveau supérieur, notamment parce qu’il transporte non seulement des valeurs mais aussi leur description : unité, plage, type d’équipement. Des spécifications compagnons, élaborées par des associations professionnelles, définissent des modèles communs par type de machine. MQTT est très utilisé pour sa légèreté et sa capacité à diffuser des flux vers de nombreux consommateurs.

Le vrai problème : le sens des données

Un projet qui choisit un protocole ouvert croit souvent avoir réglé l’interopérabilité. Il découvre vite que la variable « T_Four_2 » d’une ligne et la variable « TEMP_ZONE_B » d’une autre décrivent la même chose, que l’une est en degrés et l’autre en dixièmes de degré, et que personne ne sait plus à quel four correspond « DB12.DBW40 ».

La solution est un modèle de données partagé : une description des équipements (site, atelier, ligne, machine, sous-ensemble), de leurs mesures et de leurs états, avec des noms, des unités et des définitions stables. Ce modèle peut s’appuyer sur la hiérarchie d’équipements d’ISA-95 et sur les spécifications compagnons d’OPC UA. Il vit indépendamment des automates : quand une machine est remplacée, son nouveau programme est rattaché au même modèle et les applications en aval continuent de fonctionner.

Un protocole ouvert transporte des nombres. Seul un modèle de données partagé leur donne un sens qui survit au remplacement d’une machine.

Ce travail est ingrat et souvent sous-estimé. Il demande de recenser les variables utiles (pas toutes : une grande partie ne sert qu’au fonctionnement interne de l’automate), de les nommer, de les documenter et de désigner un responsable du modèle. C’est pourtant lui qui conditionne la réussite de tout ce qui suit : tableaux de bord, analyse de la qualité, maintenance prédictive, jumeau numérique.

La cybersécurité : zones et conduits

Relier les automates au système d’information, c’est ouvrir un chemin entre un monde exposé (messagerie, Internet, postes bureautiques) et un monde fragile. Les incidents publics des quinze dernières années, de Stuxnet en 2010 aux rançongiciels qui ont arrêté des usines en touchant seulement leur informatique de gestion, montrent que ce chemin est emprunté.

La série de normes IEC 62443 fournit le cadre de référence. Son principe central consiste à découper l’installation en zones regroupant des équipements de même niveau de sécurité, reliées par des conduits dont les flux sont explicitement autorisés et contrôlés. En pratique :

• Pas de flux direct entre le réseau bureautique et les automates ; une zone intermédiaire (souvent appelée zone démilitarisée industrielle) héberge les serveurs d’échange
• Les flux sortants des automates vers le système d’information sont privilégiés ; les flux entrants sont limités, justifiés et surveillés
• Les accès de télémaintenance passent par un point unique, authentifié, journalisé et ouvert seulement le temps de l’intervention
• Un inventaire des équipements industriels, de leurs versions et de leurs vulnérabilités connues est tenu à jour
• Les postes d’ingénierie qui programment les automates sont protégés comme des équipements critiques
• Les sauvegardes des programmes automates sont faites, vérifiées et conservées hors ligne

Le contexte réglementaire renforce ces exigences. La directive NIS 2 inclut de nombreux secteurs industriels dans son champ. Le Cyber Resilience Act, entré en vigueur le 10 décembre 2024, imposera aux fabricants de produits comportant des éléments numériques, dont les équipements industriels, des exigences de sécurité dès la conception et un traitement des vulnérabilités, avec une application complète le 11 décembre 2027. Le règlement (UE) 2023/1230 sur les machines, applicable à partir du 20 janvier 2027, intègre la protection contre la corruption, y compris les attaques informatiques, dans les exigences de sécurité des machines. Les recommandations de l’ANSSI sur la cybersécurité des systèmes industriels donnent une méthode de classification et des mesures concrètes.

La gouvernance des programmes automates

C’est le point aveugle de beaucoup d’usines. Un programme modifié directement sur l’automate, sans copie ni trace, lors d’un dépannage nocturne. Une sauvegarde qui date de la mise en service. Un intégrateur qui a quitté le métier en emportant la seule version commentée.

Les bonnes pratiques du développement logiciel s’appliquent, avec quelques adaptations.

1. Un référentiel unique des programmes. Chaque programme, avec ses versions successives, stocké dans un outil de gestion de versions, et non sur des clés USB ou des postes individuels.
2. La comparaison régulière avec l’automate. Vérifier que le programme qui tourne correspond à la dernière version enregistrée ; tout écart signale une modification non tracée.
3. Une procédure de modification. Qui peut modifier, après quelle revue, avec quel test, et comment revenir en arrière. Les modifications d’urgence sont permises, mais régularisées dans les vingt-quatre heures.
4. Des tests hors production. Pour les modifications significatives, un test sur simulateur ou sur un jumeau virtuel de la machine évite de découvrir les erreurs sur la ligne ; nous avons décrit la démarche dans notre guide pour tester un programme automate sur jumeau virtuel.
5. Une documentation vivante. Commentaires dans le code, description des séquences, liste des variables exposées au système d’information et lien avec le modèle de données.

Que faire des machines anciennes ?

Le parc installé est hétérogène : quelques machines récentes nativement communicantes, beaucoup d’équipements d’âges variés, et quelques ancêtres qui fonctionnent parfaitement mais ne parlent à personne. Le remplacement massif est rarement justifiable. Trois approches se combinent : lire les données de l’automate existant par une passerelle qui traduit son protocole ; ajouter des capteurs indépendants (courant, vibration, température) quand l’automate ne donne pas accès aux informations utiles ; remplacer quand l’équipement n’est plus maintenu ni réparable. Notre guide sur le retrofit des machines anciennes détaille les critères de choix.

Historiser : la mémoire de l’usine

Une valeur affichée en temps réel sert à piloter. Une valeur conservée dans le temps sert à comprendre. Entre les deux se trouve l’historisation : enregistrer les mesures et les états, avec leur horodatage, pendant des mois ou des années. Beaucoup d’usines disposent déjà d’un historique dans leur supervision, mais limité à quelques semaines, à une ligne, ou enfermé dans un format propriétaire.

Trois décisions conditionnent la qualité de cette mémoire. La fréquence : enregistrer chaque valeur à chaque cycle produit des volumes énormes et inutiles ; enregistrer seulement quand la valeur change au-delà d’un seuil, ou à intervalle régulier pour les grandeurs lentes, suffit souvent. L’horodatage : les horloges des automates, de la supervision et des serveurs doivent être synchronisées, faute de quoi il devient impossible de reconstituer l’enchaînement d’un incident. Le contexte : une mesure n’a de sens que rattachée à un équipement du modèle de données, à un lot, à un ordre de fabrication, à un mode de marche (production, nettoyage, arrêt).

La question du lieu de stockage se pose ensuite : sur le site, dans un centre de données de l’entreprise ou dans un service en nuage. La réponse dépend des volumes, de la sensibilité des données de procédé et de l’usage. Une règle simple aide à trancher : ce dont la production a besoin pour fonctionner reste sur le site ; ce qui sert à l’analyse, à la comparaison entre sites et à l’entraînement de modèles peut être centralisé, à condition que la remontée soit sortante et maîtrisée.

Qui fait quoi : automatisme et informatique

La plupart des difficultés de ces projets sont humaines avant d’être techniques. L’automaticien voit dans l’informaticien quelqu’un qui veut redémarrer une machine pour installer un correctif ; l’informaticien voit dans l’automaticien quelqu’un qui laisse tourner un système d’exploitation hors support depuis dix ans. Les deux ont raison, dans leur monde.

Un partage clair des responsabilités évite de rejouer ce conflit à chaque décision. L’équipe d’automatisme, ou la maintenance, reste responsable de ce qui touche au procédé : programmes, réglages, sécurité des machines, choix des données exposées. L’équipe informatique est responsable de l’infrastructure d’échange, de la sécurité des zones et des conduits, des outils de sauvegarde et de gestion de versions, et des applications de niveau 3 et 4. Les décisions qui touchent la frontière (ouvrir un nouveau flux, connecter un équipement, donner un accès à distance) se prennent ensemble, selon une procédure écrite.

Dans les organisations de taille moyenne, une même personne porte parfois les deux casquettes. Il est alors d’autant plus important que les règles soient écrites : elles protègent la personne autant que l’usine. Dans tous les cas, un référent identifié pour la cybersécurité industrielle, formé aux spécificités du domaine, est indispensable.

Ce que l’on peut en attendre

Les gains d’une intégration réussie sont concrets mais rarement spectaculaires au début. La visibilité d’abord : savoir en temps réel ce que produit chaque ligne, pourquoi elle s’arrête, combien de temps. La qualité ensuite : relier les paramètres de fabrication aux défauts constatés pour en trouver les causes. La maintenance enfin : passer de l’intervention après panne à l’intervention planifiée selon l’usage réel, puis, quand l’historique est suffisant, à l’anticipation des défaillances.

Les projets de maintenance prédictive ou d’intelligence artificielle qui démarrent sans cette base échouent presque toujours sur le même écueil : des données incomplètes, mal nommées, sans contexte. L’intégration des automates n’est pas un projet d’IA ; c’en est le préalable.

Une démarche en cinq étapes

Cartographier. Inventorier les automates, leurs versions, leurs protocoles, leurs réseaux et les flux existants, y compris les accès de télémaintenance oubliés.

Choisir un cas d’usage. Une question précise, posée par la production ou la qualité, sur une ligne. Par exemple : pourquoi cette ligne perd-elle du temps lors des changements de format ?

Construire le socle. Zone intermédiaire sécurisée, collecte, modèle de données pour le périmètre, historisation.

Livrer et mesurer. Un tableau ou une alerte utilisés par les équipes de terrain, et la mesure de l’effet sur la question posée.

Étendre. Ligne par ligne, en enrichissant le modèle de données et en réutilisant le socle, plutôt qu’en multipliant les projets isolés.

Ce chantier demande des compétences rarement réunies dans une même équipe : automatisme, réseaux industriels, sécurité, données. Notre expertise industrie et automates intervient sur ces jonctions. Pour la place que peuvent ensuite prendre les traitements au plus près des machines, voir notre note sur le calcul en périphérie, et pour les leçons tirées des attaques publiques, notre synthèse des incidents de cybersécurité industrielle.

1. IEC 61131-3, Automates programmables, partie 3 : langages de programmation.
2. IEC 62264 (ISA-95), Intégration des systèmes de commande d’entreprise.
3. IEC 62541, OPC Unified Architecture.
4. IEC 62443, Sécurité des systèmes d’automatisation et de commande industriels.
5. Règlement (UE) 2024/2847 (Cyber Resilience Act) et règlement (UE) 2023/1230 sur les machines.
6. ANSSI, publications sur la cybersécurité des systèmes industriels.

Questions fréquentes

Peut-on relier directement un automate au cloud ?

Techniquement, oui ; c'est rarement une bonne idée. Une connexion directe expose l'automate à Internet et mêle deux mondes aux exigences opposées. L'architecture recommandée passe par une zone intermédiaire qui collecte, filtre et relaie les données, sans ouvrir de flux entrant vers les équipements de contrôle.

Faut-il remplacer les automates anciens pour les connecter ?

Pas nécessairement. Beaucoup d'automates anciens peuvent être lus par une passerelle qui traduit leur protocole, ou par des capteurs ajoutés. Le remplacement se justifie quand l'automate n'est plus maintenu, plus réparable ou ne permet aucun accès aux données utiles.

Qui doit être responsable des programmes automates ?

Le service qui les exploite, en général la maintenance ou l'automatisme, avec des règles proches de celles du développement logiciel : référentiel des versions, sauvegardes, revue des modifications, traçabilité. Le service informatique apporte les outils et la sécurité ; il ne doit pas décider seul de ce qui touche au procédé.