Logiciels ou applications SCADA en fin de vie : risques et solutions

Les logiciels de supervision industrielle, dit logiciels SCADA, constituent une brique essentielle des systèmes d'information industriels dans des secteurs aussi variés que l'industrie, l'énergie, la GTB, l'eau ou l'environnement. Pourtant, un grand nombre d'installations reposent sur des solutions obsolètes ou en voie d'obsolescence : applications figées dans le temps, éditeur qui disparait ou logiciels abandonnés par leur éditeur, systèmes non maintenus à jour par l'exploitant. Le cas du logiciel SOFREL PCWin2, dont la fin de vie a été officiellement annoncée par son éditeur, illustre parfaitement les enjeux auxquels sont confrontés de nombreux exploitants. Face au danger que représentent les défaillances opérationnelles et le manque de possibilité d’évolution, quels sont les signaux à surveiller, les risques encourus et les stratégies à adopter ? 

Les signaux d'alerte à surveiller

1. Un logiciel qui n'évolue plus (ou pas) par manque de nouvelles versions régulières proposées par l’éditeur.
2. La disparition de l'éditeur ou l'annonce officielle d'un arrêt de commercialisation et de support. C’est le cas des logiciels SOFREL PCWin2 et Schneider Electric Citect.
3. Un logiciel installé sur un vieux système d’exploitation (OS) éventuellement incompatible avec les OS les plus récents.
4. L'absence de politique de gestion des correctifs de sécurité par l’éditeur (patch management), pourtant incontournable dans le contexte réglementaire NIS2. 
5. La dépendance à des compétences rares ou introuvables : intégrateurs qui ne maîtrisent plus la solution, perte de savoir-faire en interne. 
6. Un manque d'interopérabilité avec de nouveaux équipements communicants et les composants du SI industriel.
7. Une application pas mise à jour, des synoptiques et logiques métiers obsolètes ou qui ne reflètent plus la réalité du terrain.
8. Une application qui a fait l’objet de nombreuses évolutions, correctifs non structurés ou réfléchis qui fragilisent au final l'ensemble de l’application. 
9. Une documentation incomplète ou dépassée qui transforme chaque intervention en prise de risque.

Tous ces signaux sont révélateurs de risques qui peuvent mettre en danger l'exploitation : 

• Des failles de sécurité non corrigées constituent des portes d'entrée pour des cyber-attaques
• Une perte de compétences internes et/ou externes fragilise la maîtrise de la solution au quotidien
• Une absence de support constitue un risque pour la continuité de service et l’exploitation de manière globale
• Une application décorrélée de la réalité terrain est source de pertes d’exploitation

Quand engager une migration et quelles solutions envisager ?

La règle d'or : anticiper. Dès lors qu’un ou plusieurs signaux sont identifiés, il convient de ne pas tarder à lancer un projet de rénovation, sans attendre qu'une défaillance impose une migration dans l'urgence, toujours plus coûteuse et risquée.
Quelle stratégie adopter pour cette migration ? Trois approches sont envisageables selon le contexte. 

1. La migration à l'identique consiste à basculer vers une version plus récente du logiciel en place, lorsque c'est possible. Elle offre une continuité fonctionnelle (si la compatibilité ascendante du logiciel est bien assurée par l'éditeur), une conduite du changement (souvent) allégée et des coûts maîtrisés. Attention, cette approche peut parfois perpétuer la dépendance à l'éditeur et limiter les gains de modernisation.
2. La migration avec transformation consiste à repenser partiellement l'architecture existante en conservant le logiciel existant : refonte des synoptiques, modernisation des protocoles de communication, intégration avec les systèmes IT (bases de données, web, cloud). C'est souvent un bon compromis — à condition toutefois que le coût de mise à jour reste raisonnable et que les compétences internes soient préservées.
3. Enfin, le remplacement complet. Cette refonte totale, sur de nouveaux standards et avec une architecture moderne, représente un investissement significatif en termes de coût, de complexité éventuelle et de conduite du changement. Néanmoins, cette alternative ouvre la voie à une véritable pérennité de son application et à un alignement durable avec les exigences techniques actuelles et futures.

Quel que soit le scénario retenu, la réussite d'un projet de rénovation SCADA repose sur une phase d'avant-projet structurée : audit de l'existant, définition des besoins fonctionnels, choix de la solution cible, plan de migration et gestion du changement.

>> Des étapes clés détaillées dans cet article

La solution de supervision Topkapi s'inscrit comme une réponse concrète dans le cadre d’un remplacement de logiciel, avec une architecture ouverte, une interopérabilité étendue et une dynamique d’évolution continue garantissant pérennité et évolutivité sur les années à venir. Un choix à envisager pour tout projet de rénovation ou de remplacement d’un logiciel SCADA en fin de vie.