Panne ou cyberattaque ? Détecter les anomalies d'un réacteur avec une IA qu'on comprend

Imaginez la salle de commande d'une centrale. Un indicateur dérive : le niveau d'eau d'un générateur de vapeur n'est plus tout à fait celui qu'on attend. L'opérateur a quelques secondes pour trancher une question qui n'a rien d'anodin — est-ce qu'un capteur est en train de lâcher, ou est-ce qu'un attaquant est en train de mentir aux instruments ?

Les deux symptômes se ressemblent. Les deux réponses sont opposées. Si c'est une panne, on répare le composant et la vie continue. Si c'est une cyberattaque, il faut peut-être arrêter le réacteur — une manœuvre lourde, coûteuse, mais parfois vitale. Se tromper dans un sens, c'est perdre des millions pour rien. Se tromper dans l'autre, c'est rater un accident.

Je suis tombé récemment sur un papier de recherche qui attaque exactement ce problème. Et il a mis des mots sur une intuition que je traînais depuis mes cours d'I&C : dans un environnement pareil, une IA qui détecte ne suffit pas. Il faut une IA qui explique.

C'est de ça que je veux parler.

I. Une centrale, c'est devenu du code#

On imagine encore le nucléaire comme un univers de tuyaux, de vapeur et de gros boutons mécaniques. La réalité est plus banale : une centrale moderne, c'est avant tout un système d'instrumentation et de contrôle — l'I&C — c'est-à-dire un immense réseau de capteurs, de contrôleurs et de calculateurs numériques qui mesurent, décident et commandent en continu.

Cette numérisation a un revers : ce qui est connecté est attaquable. Et une anomalie dans l'I&C peut avoir deux origines radicalement différentes.

Une panne aléatoire. Un composant lâche. Typiquement, le système ne répond plus, ou un retour d'information s'interrompt. C'est un problème de fiabilité.

Une cyberattaque délibérée. Là, c'est plus sournois : le système peut continuer à se comporter normalement en apparence, pendant qu'on falsifie discrètement les mesures ou les commandes. C'est un problème de sécurité.

Le piège, c'est que les deux peuvent produire le même symptôme en surface. Or la réponse n'est pas la même du tout : on ne répare pas une intention malveillante, et on n'arrête pas un réacteur parce qu'un capteur a grillé. Identifier vite et juste la nature de l'anomalie, ce n'est pas du confort — c'est ce qui sépare la bonne décision de la catastrophe.

II. L'IA sait détecter — mais pas se justifier#

C'est exactement le genre de tâche où l'IA excelle. Apprendre à quoi ressemble un fonctionnement normal à partir de montagnes de données, puis repérer la déviation qui cloche : c'est du pain bénit pour des modèles de détection d'anomalies. Sur le papier, l'opérateur tient là un allié rêvé pour sortir du dilemme.

Sauf qu'il y a un mais, et c'est le cœur du problème. La plupart de ces modèles — les gros réseaux de neurones en particulier — sont des boîtes noires. Ils sortent un verdict : « anomalie » ou « rien à signaler ». Mais ils sont incapables de dire pourquoi. Et une réponse sans justification, dans une salle de commande, ça ne vaut pas grand-chose.

Parce que la vraie question de l'opérateur n'est pas seulement « y a-t-il une anomalie ? ». C'est « est-ce que je peux te croire avant d'arrêter un réacteur ? ». Un humain qui doit engager une décision à plusieurs millions d'euros — ou la sûreté d'une installation — a besoin de vérifier le raisonnement, pas de recevoir un oracle. L'explicabilité n'est pas un luxe cosmétique ici. C'est la condition pour qu'on accepte de faire confiance.

Et là, je retombe sur une obsession qui traverse tout ce que j'écris sur l'IA : une réponse qu'on ne comprend pas, ce n'est pas vraiment une réponse. C'est un pari déguisé en certitude.

III. L'astuce : découper le problème par couches#

L'idée du papier est élégante, et très « ingénieur » dans l'esprit : plutôt qu'une seule IA géante qui avale tout et recrache un verdict opaque, on découpe le problème en suivant la structure réelle de l'I&C.

Un système d'I&C est organisé en couches. Tout en bas, les capteurs et actionneurs, qui touchent au processus physique. Au-dessus, les contrôleurs — les automates, les PLC. Encore au-dessus, les postes de supervision et de gestion. Et — détail crucial — un attaquant n'a ni les mêmes compétences ni les mêmes points d'entrée selon la couche qu'il vise.

Le framework installe donc trois détecteurs spécialisés, un par couche, chacun nourri de son propre type de données :

• un module IT, qui surveille le trafic réseau — la couche haute, là où arrivent la plupart des attaques ;
• un module ICS, qui surveille les données des contrôleurs : temps de cycle, état de l'automate ;
• un module Process, qui surveille les variables physiques du réacteur : niveau, débit, pression.

Et c'est là que la mécanique devient maligne. Chaque module répond simplement par 0 ou 1 — normal ou anormal. Mais c'est la combinaison des trois réponses qui devient l'explication.

Autrement dit, le système ne dit pas juste « attaque » ou « panne ». Il dit où ça se passe et jusqu'où ça remonte. L'explication n'est pas rajoutée après coup pour rassurer l'opérateur — elle est construite dans l'architecture elle-même.

Dernier point que j'ai trouvé satisfaisant en tant que futur ingénieur : à chaque couche, son algorithme. Les données réseau et automate, qui sont tabulaires, sont traitées par des méthodes adaptées — forêts d'arbres, gradient boosting. Les variables du procédé, qui sont des séries temporelles, sont confiées à un réseau spécialisé dans le temps (un LSTM), entraîné à prédire le comportement normal et à lever l'alarme dès que le réel s'en écarte. On ne prend pas le marteau le plus gros ; on prend l'outil juste pour la donnée. Résultat sur leur banc d'essai : autour de 99 % d'identification correcte.

Conclusion : l'explicabilité comme contrainte de conception#

Ce papier m'a marqué moins pour ses chiffres que pour ce qu'il dit en creux. On a tendance à juger une IA sur sa performance — son taux de détection, sa précision. Mais dans un système critique, ce critère est incomplet. Une IA qui a raison sans pouvoir le justifier reste inutilisable, parce que personne de sensé n'arrêtera un réacteur sur la foi d'un oracle muet.

L'explicabilité ne devrait pas être une couche qu'on ajoute à la fin pour faire joli. Elle devrait être une contrainte de conception, au même titre que la précision ou la latence — pensée dès l'architecture, comme ici. C'est exactement le même réflexe que pour l'énergie, ou pour notre propre dépendance à ces outils : ce qu'on traite comme un détail finit toujours par nous rattraper.

Et soyons honnêtes : ce n'est pas magique. Dans leurs propres tests, une poignée d'attaques très discrètes sont passées sous le radar, mal classées parce qu'elles touchaient le procédé trop légèrement et trop brièvement pour franchir le seuil d'alarme. C'est précisément pour ça qu'on garde un humain dans la boucle — et qu'on veut qu'il comprenne ce que la machine lui montre, pour rattraper ce qu'elle laisse passer.

Penser l'IA comme un ingénieur, ce n'est pas lui demander d'avoir raison. C'est lui demander de pouvoir le prouver.

Une réponse sans explication ne supprime pas le doute. Elle le déplace.