Un système de supervision ne devient pas critique le jour où il tombe en panne. Il le devient bien avant, lorsque l’exploitation commence à se dégrader sans bruit : temps de réponse qui s’allongent, alarmes moins fiables, historisation incohérente, intégration de nouveaux équipements qui devient complexe, voire impossible.
Dans ces situations, le problème n’est plus seulement technique. C’est toute l’architecture SCADA qui commence à atteindre ses limites : dépendance à des composants non maintenus, protocoles vieillissants, contraintes d’évolution, exposition accrue aux risques de cybersécurité.
Migrer un système de supervision devient alors inévitable. Mais sur le terrain, une migration SCADA ne consiste jamais à remplacer un logiciel par un autre. C’est un projet structurant, qui impacte à la fois la continuité d’exploitation, les communications industrielles, l’intégrité des données et la capacité d’évolution de l’installation.
Dans cet article, nous vous proposons une approche concrète pour piloter cette transition : comment qualifier l’obsolescence réelle de votre système de supervision, structurer l’analyse de l’existant, définir une architecture cible cohérente et sécuriser chaque étape de la migration jusqu’à la mise en production.
Étape n°1 : vérifier si votre système de supervision est réellement obsolète
Avant de lancer une migration, il faut d’abord déterminer si le système de supervision actuel est encore techniquement viable. Un environnement ancien n’est pas automatiquement obsolète. En revanche, l’accumulation de signaux faibles indique souvent qu’une modernisation devient nécessaire.
Les questions à vous poser :
✔ Le SCADA est-il encore supporté par l’éditeur ? Si l’éditeur ne maintient plus la version en place, chaque incident devient plus complexe à traiter.
✔ Le système d’exploitation est-il toujours maintenu ? Un système de supervision qui repose sur une version Windows ou Linux non supportée reste parfois fonctionnel, mais il fragilise toute l’architecture.
✔ Les drivers de communication sont-ils toujours disponibles ? Certains drivers historiques ne sont compatibles qu’avec d’anciennes générations de serveurs, d’automates ou d’interfaces.
✔ Les protocoles modernes sont-ils compatibles ? Un système ancien peut encore fonctionner avec l’existant, tout en bloquant l’intégration d’OPC UA, IEC 61850, DNP3 ou d’architectures d’échange plus structurées.
✔ Les performances sont-elles encore adaptées au volume de données ? Temps d’affichage allongés, historisation qui ralentit, alarmes plus difficiles à traiter, serveurs saturés, synoptiques qui deviennent lourds : ces symptômes montrent souvent que l’architecture a atteint ses limites.
Cette première étape permet d’identifier si une migration est réellement nécessaire. Ce diagnostic demande déjà une analyse croisée entre SCADA, infrastructure, communications et exploitation.
Étape n°2 : cartographier l’architecture SCADA existante
Avant toute migration de système de supervision, il faut disposer d’une vision complète de l’existant. Sans cartographie précise, le risque de perte fonctionnelle, de rupture de communication ou d’oubli de dépendance critique reste élevé.
Les éléments à inventorier :
✔ Postes opérateurs et IHM : recenser les postes de conduite, de maintenance et d’exploitation, ainsi que les synoptiques, alarmes, vues process et fonctions locales associées.
✔ Serveurs de supervision : identifier les serveurs principaux et de secours, l’historisation, les services applicatifs, les passerelles de communication et les mécanismes de redondance.
✔ RTU et automates PLC : lister les équipements de contrôle-commande raccordés au système de supervision, leur rôle, leur criticité, leurs interfaces de communication et leur ancienneté. Cet inventaire permet de repérer les équipements qui pourront être conservés et ceux qui imposeront des adaptations.
✔ Capteurs et actionneurs supervisés : repérer les points exploités par le SCADA : mesures, états, consignes, commandes, retours d’information, alarmes process.
✔ Réseaux de communication : cartographier segments industriels, liaisons série, switches industriels, routeurs, passerelles, VLAN, accès distants. Cette cartographie conditionne ensuite les choix de segmentation, de redondance et de cybersécurité.
✔ Bases de données historiques : identifier où sont stockés les historiques process, journaux d’événements, alarmes et données énergétiques, ainsi que les usages associés.
“Ces éléments constituent les briques fondamentales d’une architecture SCADA. Sans cette étape, la migration d’un système de supervision se fait à l’aveugle. Et c’est souvent ici que l’on mesure le niveau réel de complexité du projet.” – Patrick Boissat, Dirigeant JSA
Étape n°3 : analyser les protocoles de communication utilisés
Dans une migration de système de supervision, les protocoles de communication sont un point de contrôle critique. Un SCADA peut sembler stable tout en reposant sur une chaîne d’échange hétérogène, partiellement documentée et difficile à reprendre dans une architecture moderne.
Les questions à vous poser :
✔ Quels protocoles sont réellement utilisés aujourd’hui ? Il faut recenser les protocoles entre SCADA, automates, RTU, passerelles, équipements terrain et systèmes tiers.
✔ Ces protocoles sont-ils encore adaptés aux standards actuels ? Un protocole encore en service n’est pas forcément pertinent pour une architecture moderne. Il faut évaluer sa maintenabilité, la disponibilité des drivers, son niveau de standardisation et sa compatibilité avec les exigences actuelles d’interopérabilité et de cybersécurité.
✔ Les équipements terrain peuvent-ils communiquer avec un nouveau SCADA ? Il faut vérifier si le futur système de supervision pourra reprendre correctement les mesures, états, alarmes, commandes, horodatages et événements sans perte fonctionnelle.
✔ Existe-t-il des passerelles ou dépendances cachées ? Convertisseurs série/Ethernet, OPC legacy, frontaux de communication, gateways protocolaires : ces composants intermédiaires sont souvent les points les plus fragiles de l’architecture.
Étape n°4 : définir l’architecture de supervision cible
La migration d’un système de supervision ne consiste pas à remplacer un système SCADA par un autre à périmètre constant. C’est le moment où il faut redéfinir une architecture cohérente avec les contraintes d’exploitation, les exigences de disponibilité et les besoins d’évolution du site.
Les points à valider :
✔ Faut-il une architecture centralisée ou distribuée ? Le choix dépend du nombre d’installations à superviser, de la criticité des processus et de l’organisation de l’exploitation. Une architecture centralisée simplifie souvent l’administration, tandis qu’une architecture distribuée peut mieux répondre à des contraintes de disponibilité ou de sites distants.
✔ Le niveau de redondance des serveurs SCADA est-il correctement défini ? Supervision, historisation, alarmes, communication, virtualisation : chaque couche doit être analysée avec ses mécanismes de basculement.
✔ La segmentation réseau OT/IT est-elle intégrée dès la conception ? Une architecture moderne doit clairement séparer les flux industriels et les flux informatiques, en maîtrisant les échanges entre les deux.
✔ La gestion des accès utilisateurs est-elle adaptée à l’exploitation ? Il faut définir les profils, les niveaux d’habilitation, les droits d’action, les accès distants et la traçabilité des opérations.
✔ Les exigences de cybersécurité sont-elles prises en compte nativement ? Durcissement des serveurs, gestion des comptes, contrôle des flux, journalisation, cloisonnement, politique de mise à jour : la cybersécurité ne doit pas être ajoutée en fin de projet, elle doit faire partie intégrante de l’architecture dès les choix de conception.
L’objectif est de concevoir un système de supervision capable d’évoluer sans reconstruire l’architecture à chaque nouveau besoin.
Étape n°5 : préparer la stratégie de migration
Une migration du système de supervision ne doit jamais être menée en rupture brutale. Même lorsque l’obsolescence du SCADA est avérée, le passage vers une nouvelle architecture doit être préparé de façon progressive, maîtrisée et réversible.
Les questions à vous poser :
✔ La migration peut-elle être découpée par sous-système ? Une migration progressive par atelier, zone fonctionnelle, utilité ou équipement critique permet de limiter les risques. Ce découpage évite d’exposer l’ensemble du site à un basculement unique.
✔ Une coexistence entre ancien et nouveau SCADA est-elle possible ? Dans certains projets, faire cohabiter temporairement les deux environnements permet de sécuriser la reprise fonctionnelle.
✔ Une duplication temporaire des serveurs doit-elle être prévue ? Selon l’architecture cible, il peut être pertinent de mettre en place des serveurs parallèles pour préparer les tests, valider les communications et fiabiliser le basculement. Cette duplication temporaire permet de réduire le risque, à condition d’être intégrée dès la stratégie de migration.
✔ Le basculement final est-il défini de manière contrôlée ? Le passage du système existant vers le nouveau système de supervision doit être scénarisé : séquence de bascule, prérequis techniques, critères de validation, gestion des écarts, retour en arrière éventuel.
Une stratégie de migration bien construite permet de moderniser le système de supervision sans exposer le site à une perte de conduite, à une rupture de communication ou à une indisponibilité.
Étape n°6 : sécuriser les données et l’historisation
Dans un projet de migration, la reprise des données est souvent traitée trop tard. Pourtant, sur un système de supervision, l’historisation, les journaux d’alarmes et les événements d’exploitation font partie des éléments les plus sensibles à transférer.
Les points à vérifier :
✔ La sauvegarde des bases de données est-elle complète ? Avant toute opération, il faut sécuriser l’ensemble des bases liées au SCADA. Une sauvegarde incomplète ou non vérifiée expose le projet à une perte de données dès les premières phases de migration.
✔ La migration des historiques est-elle réellement prévue ? Il faut déterminer ce qui doit être repris, sous quel format, avec quel niveau de profondeur et pour quels usages d’exploitation.
✔ L’intégrité des données sera-t-elle validée après reprise ? Il faut vérifier la cohérence des horodatages, la continuité des enregistrements, la lisibilité des historiques et la correspondance avec les événements réellement attendus dans le nouveau système de supervision.
✔ La continuité des alarmes et des événements est-elle garantie ? Les alarmes, acquittements, défauts process et journaux d’événements doivent rester exploitables pendant et après la migration.
L’objectif est de conserver la traçabilité des opérations industrielles. Copier des bases ne suffit pas : il faut garantir que l’information reste exploitable dans le nouveau système de supervision.
Étape n°7 : tester le nouveau système de supervision avant mise en production
Avant le déploiement final, un système de supervision modernisé doit être validé en conditions maîtrisées. Cette phase de recette conditionne directement la fiabilité du basculement.
Les éléments à valider :
✔ Les communications avec les équipements ont-elles été testées ? Il faut valider les échanges avec les automates, RTU, passerelles, compteurs, protections et équipements terrain raccordés.
✔ Le SCADA tient-il la charge attendue ? Le nouveau système doit être testé avec une volumétrie réaliste : nombre de variables, fréquence d’actualisation, alarmes simultanées, historisation, connexions opérateur, accès aux synoptiques.
✔ Les synoptiques et interfaces opérateur sont-ils conformes ? Il faut vérifier la cohérence d’affichage, la navigation, les états dynamiques, les commandes autorisées, les vues de diagnostic et la lisibilité globale pour l’exploitation.
✔ Des scénarios de défaut ont-ils été simulés ? Perte de communication, indisponibilité d’un équipement, défaut serveur, saturation d’alarmes, reprise après incident : ces cas doivent être testés avant mise en production. C’est ce qui permet de vérifier le comportement réel du système de supervision hors fonctionnement nominal.
Migrer un système de supervision ne consiste pas à remplacer un logiciel vieillissant par une interface plus récente. C’est un projet d’architecture à part entière, qui engage à la fois la supervision, les communications industrielles, l’historisation, la cybersécurité, la continuité d’exploitation et la capacité d’évolution de l’installation.
Une migration SCADA suppose bien plus qu’un simple changement d’outil : il faut qualifier l’obsolescence réelle du système en place, inventorier précisément l’architecture existante, analyser les protocoles, définir une cible cohérente, préparer le basculement, sécuriser les données et valider l’ensemble avant mise en production. Autrement dit, moderniser un système de supervision demande une méthode rigoureuse, une lecture fine du terrain et une vraie maîtrise des environnements industriels.
C’est précisément sur ce type de projet que l’expertise fait la différence. Chez JSA Groupe, nous accompagnons depuis plus de 20 ans les industriels dans la conception, l’évolution et la modernisation de leurs architectures de supervision, avec une approche sur mesure, orientée continuité d’exploitation, interopérabilité et fiabilité long terme.Vous envisagez de faire évoluer votre système de supervision ou vous souhaitez évaluer le niveau d’obsolescence de votre architecture actuelle ? Contactez JSA pour échanger sur votre installation, vos contraintes techniques et les conditions d’une migration maîtrisée.
