Analyse terrain proposée par Nicolas Raflegeau, Expert SCADA et MES chez 2Gi Technologie
Lorsqu'un projet SCADA est mis en service, beaucoup considèrent que le projet est terminé. Les données remontent, les écrans fonctionnent et les objectifs initiaux semblent atteints.
Cette vision est compréhensible. Pourtant, dans la réalité industrielle, un projet SCADA n'est jamais véritablement figé. Car les besoins évoluent en permanence, même lorsque les installations semblent stables.
Pourquoi un projet SCADA paraît terminé après sa mise en service
La plupart des projets industriels sont construits autour d'un objectif précis : remplacer une supervision existante, centraliser les données d'un site ou moderniser un outil devenu obsolète. Une fois cet objectif atteint, il est naturel de considérer le projet comme terminé.
Cette vision est renforcée par la manière dont les projets sont généralement pilotés. Un budget est défini, un calendrier est fixé et une date de mise en service marque officiellement la fin du projet. Une fois la solution déployée et les équipes formées, l'entreprise passe naturellement à d'autres priorités.
Cette perception est également liée à la nature même des installations industrielles. Contrairement à d'autres environnements numériques, les équipements de production évoluent souvent lentement. Une ligne de production, une station de traitement ou un poste de pompage peuvent rester en service pendant de nombreuses années.
Parce que l'outil de production paraît stable, on imagine souvent que le SCADA qui le supervise le sera également.
Pourquoi faire évoluer un SCADA est indispensable
Or, cette vision confond les équipements et les usages. Même lorsque les installations changent peu, les besoins des exploitants, des responsables de production ou des directions industrielles continuent d'évoluer. Même lorsque les installations changent peu, les besoins des exploitants, des responsables de production ou des directions industrielles continuent d'évoluer.
Quelques mois seulement après une mise en service, de nouvelles demandes apparaissent souvent : intégrer un équipement supplémentaire, créer de nouveaux indicateurs, faire évoluer les tableaux de bord ou connecter d'autres applications de l'entreprise.
Ces évolutions sont parfaitement normales. Elles traduisent généralement une meilleure appropriation de l'outil par les équipes. À mesure que les utilisateurs découvrent les possibilités offertes par le SCADA, ils identifient de nouveaux besoins, de nouvelles opportunités d'amélioration et de nouvelles façons d'exploiter les données.
Les besoins de l'entreprise évoluent eux aussi. Les exigences réglementaires changent, les enjeux de cybersécurité se renforcent, de nouveaux objectifs de performance sont définis et les données deviennent de plus en plus stratégiques pour le pilotage des activités.
Un SCADA n'est donc pas seulement un outil de supervision. C'est un système qui accompagne l'évolution de l'exploitation dans le temps. C'est pourquoi l'évolutivité d'un SCADA doit être pensée dès sa conception.
Les conséquences d'un SCADA dont l'évolution n'a pas été anticipée
Lorsque l'évolutivité n'est pas prise en compte dès la conception, les difficultés n'apparaissent généralement pas immédiatement. Elles se révèlent progressivement, au rythme des évolutions du site.
Chaque nouvelle demande devient plus complexe à mettre en œuvre. Ajouter un équipement, créer un nouvel indicateur ou modifier un écran nécessite davantage de temps et de développement qu'initialement prévu.
Les coûts d'évolution augmentent alors progressivement. Ce qui devrait être une amélioration courante finit par mobiliser des ressources importantes, voire conduire à repousser certaines évolutions pourtant nécessaires.
La maintenance du système devient également plus difficile. Les développements spécifiques se multiplient, les écarts entre les installations augmentent et la compréhension globale de l'application se dégrade au fil du temps.
Ces difficultés apparaissent régulièrement lorsque l'évolution du système n'a pas été anticipée dès sa conception. L'équipe de 2Gi Technologie a notamment rencontré cette situation lors de la reprise d'un projet de supervision dans le secteur de l'eau couvrant une cinquantaine de sites.
Lors de la conception initiale, chaque site avait été développé individuellement. À première vue, cette approche fonctionnait parfaitement : chaque installation disposait de ses propres écrans et répondait au besoin du moment.
Le problème est apparu lorsque le système a commencé à évoluer.
La moindre modification devait être reproduite sur l'ensemble des sites. Ajouter une fonctionnalité, corriger une erreur ou faire évoluer un écran impliquait de répéter la même opération cinquante fois.
Au fil du temps, les écarts entre les sites se sont multipliés. Certaines modifications étaient réalisées sur certains sites mais pas sur d'autres. Les erreurs devenaient plus fréquentes et les temps de maintenance augmentaient.
Le système répondait toujours au besoin initial, mais il n'avait pas été conçu pour évoluer efficacement.
Pour remédier à cette situation, les équipes de 2Gi ont repensé l'architecture autour d'une logique de standardisation et de réutilisation des développements.
Une modification pouvait alors être réalisée une seule fois puis déployée sur l'ensemble des sites concernés.
Le problème n'était donc pas le logiciel utilisé. Le problème était l'absence d'une conception pensée pour accompagner les évolutions futures.
Penser l'évolution du SCADA dès sa conception
Les projets les plus performants ne sont pas ceux qui anticipent parfaitement tous les besoins futurs. Ils sont ceux qui sont capables de s'adapter lorsque ces besoins apparaissent.
Dès les premières phases du projet, l'évolutivité est intégrée dans les choix de conception. L'architecture est pensée pour accueillir de nouveaux équipements, de nouveaux sites ou de nouveaux usages sans remettre en cause l'ensemble du système.
Les développements sont standardisés autant que possible. Les données sont structurées de manière cohérente. Les composants réutilisables sont privilégiés afin d'éviter de recréer les mêmes fonctionnalités à chaque évolution.
Cette approche permet de réduire les coûts de maintenance, de simplifier les évolutions futures et de garantir une meilleure pérennité de la solution.
Un bon intégrateur ne cherche donc pas uniquement à répondre au besoin exprimé aujourd'hui. Il réfléchit également à la manière dont le système pourra évoluer demain.
Car un projet SCADA n'est jamais figé. Il accompagne la vie de l'exploitation, ses transformations et ses nouveaux enjeux.
Une supervision se juge à sa capacité à évoluer avec les besoins de l'exploitation, sans devenir plus complexe, plus coûteuse ou plus difficile à maintenir, parce qu’un un projet SCADA n'est jamais vraiment terminé.
La mise en service d’un SCADA n’est pas la fin d’un projet, c’est précisément là que tout commence. Le client s’approprie l’outil, découvre ses possibilités et fait émerger de nouveaux besoins.
Le SCADA devient alors une base sur laquelle viennent se construire de nouveaux usages.
