Menu
Logiciel pour la sûreté : défis des systèmes critiques

Logiciel pour la sûreté : défis des systèmes critiques

Cet article est tiré des propos tenus lors d’une table ronde de la TECH WEEK 2025, animée par Sébastien SEGARD (Coordinateur Technique chez KAIZEN Solutions), Frédéric MICHAUD (Délégué métier « Contrôle-Commande et Système d’Informations » – EDF Hydro), Mikael WILLIAMS (Directeur programme EPR2 – Worldgrid) et Paul ROY (Directeur technique – Astriis).

Cette table ronde s’ouvre sur un constat simple : la sûreté et le logiciel sont devenus indissociables dès lors qu’on parle de systèmes critiques. A mesure que les systèmes industriels se numérisent, le logiciel devient un pilier de la sûreté. Pourtant, selon les secteurs, les contraintes associées à cette sûreté n’ont rien de comparable. Nucléaire, hydraulique et maintenance prédictive partagent un même vocabulaire, mais recouvrent des réalités techniques, normatives et culturelles très différentes.

 

Quand le critique n’est pas là où on l’attend

Première clarification essentielle : un système critique n’implique pas toujours un logiciel critique au sens normatif du terme.

Dans le domaine de la maintenance prédictive, le logiciel intervient sur des équipements dont la défaillance peut avoir des conséquences économiques, environnementales, voire humaines. Pour autant, l’indisponibilité temporaire de l’outil n’entraîne pas immédiatement de situation dangereuse. La criticité est donc portée par l’équipement surveillé, pas par le logiciel lui-même. Le logiciel collecte des données capteurs (surtout vibratoires), réalise de l’analyse spectrale, produit des indicateurs, puis utilise de l’IA pour détecter des défauts pouvant être anticipés jusqu’à 18 mois avant la panne sur certains équipements.


« Le critique, chez nous, c’est l’équipement. Le logiciel, lui, n’est pas classé critique au sens réglementaire, parce que son indisponibilité n’entraîne pas un danger immédiat. »
- Paul ROY - Astriis

À l’inverse, dans l’hydraulique ou le nucléaire, le logiciel est directement impliqué dans des fonctions qui protègent les personnes : pilotage des vannes, supervision des niveaux d’eau, conduite des installations, ou encore contrôle-commande en salle de commande. Ici, le logiciel devient un maillon explicite de la sûreté.

 

"DevOps en un clic": compatible avec la sûreté ?

Nucléaire : la sûreté comme discipline absolue

Dans le programme EPR2, le logiciel est au cœur d’une ambition inédite : une salle de commande informatisée classée « classe 2 », un niveau jamais atteint auparavant. Cette classification entraîne une exigence maximale de prédictibilité, de traçabilité et de démonstration.

Le cycle de développement est strictement normé : spécifications figées très en amont, séparation claire des rôles (développement, tests, validation), production d’une documentation abondante destinée aux autorités de sûreté. Dans ce contexte, les pratiques modernes de type « déploiement en un clic » ou intégration continue ne sont envisageables que pour des outils non-temps réel et non classés.

« En environnement classé, on ne rattrape pas ce qu’on a mal fait. Il faut faire bien du premier coup, parce que tout est audité et démontré. »
- Mikael WILLIAMS - Worldgrid

Le choix des technologies reflète cette logique : langages « memory safe », usage extrêmement limité des bibliothèques, maîtrise complète de la chaîne de compilation. L’objectif n’est pas la vitesse, mais la démonstration que le système se comportera toujours de manière déterministe, y compris dans les situations dégradées.

 

Hydraulique : une sûreté sous surveillance permanente

Dans l’hydraulique, la sûreté repose moins sur un cadre normatif dédié que sur un contrôle continu exercé par l’État. Les exploitants doivent déclarer tout événement impactant la sûreté, même mineur, afin d’alimenter le retour d’expérience collectif.

Le contrôle se fait via :

  • Surveillance locale par les DREAL
  • Supervision nationale par le pôle national de la sécurité des ouvrages hydrauliques
    avec deux angles :
  1. Déclarations et transparence : tout événement impactant la sûreté doit être déclaré, même petit, pour alimenter le REX et améliorer le standard.
  2. EDD (Études de Danger) : documents périodiques (tous les 10 ans) dressant l’état des lieux de la sûreté — une sorte de “permis de continuer à exploiter”.

« Tout événement, même petit, doit être déclaré. C’est ce qui permet d’améliorer le standard et de renforcer la sûreté globale. »
- Frédéric MICHAUD - EDF Hydro

Les Études de Danger, renouvelées périodiquement, jouent un rôle clé : elles conditionnent le droit de continuer à exploiter un ouvrage. Le logiciel est omniprésent dans la conduite quotidienne des barrages, mais la priorité reste la lisibilité et la maintenabilité des systèmes, en particulier pour les équipes de terrain.

Cette exigence de simplicité crée parfois une tension avec la cybersécurité : ajouter des couches de protection peut complexifier l’exploitation, là où la sûreté cherche avant tout à réduire les risques d’erreur humaine ou de comportement inattendu.


Maintenance prédictive : agilité sous conditions

Dans le monde de la maintenance conditionnelle, l’agilité est plus grande. Les mises en production rapides sont possibles, précisément parce que le logiciel n’est pas directement classé critique. Mais cette liberté n’exonère pas d’un haut niveau d’exigence.

La crédibilité repose sur plusieurs piliers :

  • Une roadmap de sécurité numérique construite avec un expert cyber
  • Durcissement des équipements, authentification, protections
  • Hébergement sur cloud souverain OVH
  • Isolation des données par client : bases distinctes + conteneurs distincts, pour éviter toute “bavure” entre clients.

Les modèles sont validés non seulement par des tests automatisés, mais aussi par des experts métiers confrontant les résultats aux signaux réels du terrain, bien plus complexes et bruités que les données de laboratoire.

 

« Dans certains contextes industriels, savoir qu’une installation fonctionne est déjà une information sensible. »
- Paul ROY - Astriis


Cybersécurité et IA : des enjeux transverses, des réponses différenciées

La cybersécurité est un sujet commun à tous, mais abordé différemment selon les contextes. Dans le nucléaire, elle est fortement encadrée par des acteurs étatiques et influe directement sur l’organisation et la circulation de l’information. Dans l’hydraulique, elle doit composer avec les impératifs de simplicité opérationnelle. Dans la maintenance prédictive, elle conditionne la confiance des clients, même sans obligation réglementaire immédiate.

 L’intelligence artificielle suit une trajectoire comparable. Les approches « classiques » d’IA sont déjà largement utilisées, notamment pour la détection d’anomalies. En revanche, l’IA générative ouvre un nouveau défi : comment qualifier et démontrer la fiabilité de code ou de tests produits, au moins en partie, par une machine ? Une question encore largement ouverte, quel que soit le secteur.

 Mais Frédéric (EDF) voit des usages très prometteurs côté ingénierie :

  •  Data mining sur la masse d’incidents (pour accélérer le REX)
  •  Aide à la requalification (plateforme et site)
  •  Génération de scénarios de test “intelligents”
  •  Aide au déployeur pour préparer son intervention.

 

Une constante au-delà des différences

Cette table ronde montre une chose : “systèmes critiques” n’est pas un bloc homogène.

  • Dans le nucléaire, la sûreté impose une discipline d’ingénierie maximale : normes, preuves, validation, compartimentation, gestion des versions figées, arbitrages cyber/performance… avec surveillance des autorités
  • Dans l’hydraulique, la sûreté est structurée par la surveillance étatique, le REX, les EDD, la standardisation, et une montée en puissance du contrôle-commande, avec un enjeu humain immense : garder des solutions maintenables et compréhensibles sur le terrain.
  •  Dans la maintenance prédictive, l’agilité est plus grande, mais la crédibilité passe par des pratiques solides : cyber “trust”, isolation des données, et surtout qualification via tests, experts, et cas réels, pour compenser la rareté des défaillances “catastrophiques”.

 La constante, elle, est simple : la sûreté, ce n’est pas seulement “ne pas se tromper”. C’est être capable de le démontrer, dans la durée, au bon niveau d’exigence.

Pour revivre l’intégralité des échanges et comprendre comment nucléaire, hydraulique et maintenance prédictive abordent la sûreté logicielle, découvrez le replay complet de la table ronde de la Tech Week 2025 :

Retour aux articles

C'est à lire...