Un projet SCADA n’est pas difficile techniquement ; il demande de la discipline. Les erreurs que nous avons vues au fil des années, sur des sites différents, sont étonnamment les mêmes. Ce qui suit vient des règles que nous nous sommes fixées en construisant le SCADA d’une station de traitement des eaux.
Comment un écran SCADA se simplifie
01 / 04
400 signaux
Chaque signal de l’installation est sur l’écran principal. L’opérateur n’en voit aucun.
02 / 04
Écran principal
L’état du process et ce qui demande une intervention à l’instant ; le détail est à un clic. Les pompes tournent en alternance.
03 / 04
Priorités d’alarme
Défaut pompe en rouge et sonore, alerte de niveau en jaune, information simplement enregistrée. Chaque alarme a une fonction.
04 / 04
Redondance
Un jour, le serveur tombe. Le serveur de secours prend le relais ; historiques, recettes et journal d’alarmes restent en place.
1. Tout mettre à l’écran
Nous avons vu des projets où, sur une installation de 400 signaux, les 400 signaux se retrouvaient sur l’écran principal. L’opérateur n’en voit aucun. L’écran principal doit montrer l’état du process et ce qui demande une intervention à l’instant ; le détail est à un clic. Dans le projet de traitement des eaux, l’écran principal affiche l’état des pompes et des bassins ; courbes de débit et courants moteur sont sur une page à part. Ce qui a raccourci le temps d’intervention de l’opérateur, ce n’est pas plus d’information, c’est moins d’information.

2. Laisser la liste des alarmes pour le dernier jour
Si les alarmes ne sont pas hiérarchisées, elles sonnent toutes en même temps et l’opérateur les fait toutes taire. Une semaine plus tard, l’écran d’alarmes n’est plus qu’une liste que personne ne regarde. Nous concevons les alarmes avec des priorités, des temporisations et des regroupements : défaut pompe en rouge et sonore ; alerte de niveau en jaune ; les alarmes informatives sont simplement enregistrées. Une alarme qui ne répond pas à la question « Quand elle sonne, que fait exactement l’opérateur ? » n’entre pas dans la liste.
3. Attendre le rapport de l’opérateur
Si les rapports réglementaires et internes sont saisis à la main dans Excel, vous produisez à la fois des erreurs et des heures de travail. Le reporting, c’est le travail du SCADA : rapports journaliers, par poste et mensuels doivent être planifiés et, si nécessaire, partir par e-mail. Dans la station de traitement des eaux, l’automatisation complète du reporting réglementaire est devenue la partie du projet que les opérateurs apprécient le plus, davantage encore que les écrans.
4. Se contenter de faire tourner les pompes
Les pompes représentent une grande partie de la facture d’énergie d’une installation. Si le SCADA se limite à marche/arrêt, vous passez à côté d’une opportunité. Une logique qui fait tourner les groupes de pompes en alternance et de façon efficace, selon le niveau, la demande et le tarif, représente quelques jours de travail côté logiciel ; sur la facture, la différence est durable. Pour nous, ce n’est pas une « fonction en plus » du SCADA, c’en est le cœur.
5. Remettre le réseau et la sauvegarde à « plus tard »
Si le serveur SCADA est une machine unique, cette machine tombera un jour. Et avec elle les historiques, les recettes, le journal d’alarmes. La redondance serveur, la sauvegarde de la base de données et la séparation du réseau OT et du réseau IT doivent figurer dans le périmètre du projet dès le premier jour. Même chose pour le plan d’adressage IP : sur site, chaque heure passée à se demander « Quelle était déjà l’adresse IP de cet équipement ? » est l’heure la plus chère du projet.
Un bon SCADA, c’est un SCADA qui fonctionne aussi quand l’opérateur ne regarde pas l’écran.