Dans la nuit du 11 au 12 octobre 2026, des installations de froid de magasins Intermarché, Coopérative U, E.Leclerc et Monoprix ont été touchées par une cyberattaque : produits jetés, rayons fermés, enquête confiée à l’Ofac et ANSSI saisie, selon franceinfo, l’AFP et CNEWS. Le mode opératoire n’est pas établi. Trois semaines plus tard, un même commentaire revient dans chaque conversation : ces équipements n’étaient pas à jour.
Nous travaillons des deux côtés : avec des constructeurs d’équipements industriels qui préparent le Cyber Resilience Act, et avec des exploitants dans l’énergie, les transports et l’industrie. Ce que nous voyons n’est pas de la négligence. Quatre blocages s’enchaînent, et trois existent avant que l’équipement n’arrive sur le site.
Ce que disent les référentiels
Les recommandations sont légitimes, et elles connaissent la difficulté. Le guide « La cybersécurité des systèmes industriels, mesures détaillées » de l’ANSSI (ANSSI-PA-108, version 2.0 du 27 novembre 2025) écrit, au paragraphe 2.2.1, que « dans de nombreux cas, les correctifs ne peuvent être installés que pendant les phases de maintenance et, parfois, leur application peut entraîner la nécessité de requalifier le système industriel du point de vue de la sûreté de fonctionnement ».
Côté constructeurs, le règlement (UE) 2024/2847, le Cyber Resilience Act, fixe à l’article 13 une période d’assistance, autrement dit une durée de support, d’au moins cinq ans, pendant laquelle les vulnérabilités du produit et de ses composants doivent être gérées. Cette obligation vaut pour les produits mis sur le marché à partir du 11 décembre 2027.
Les textes décrivent la cible. Ils ne disent pas pourquoi le terrain n’y est pas.
Problème 1 : le produit n’a pas été conçu pour être mis à jour
Un équipement OT n’est jamais un seul logiciel. C’est un système embarqué, une pile de communication, des bibliothèques tierces et le code métier du constructeur, assemblés à une date donnée. Rien n’a prévu qu’une de ces briques bouge seule.
Chez un équipementier de taille intermédiaire, corriger une bibliothèque de chiffrement imposait de changer la version du système embarqué, qui imposait de recompiler le code métier, qui n’était plus compatible avec l’outil de supervision du client. Une mise à jour en entraîne trois, et la troisième casse quelque chose.
Problème 2 : la crainte du non-redémarrage
Les produits OT sont extrêmement fiables. Nous voyons des automates qui tournent depuis plus de dix ans avec quelques redémarrages, une fiabilité que l’informatique de gestion n’atteint pas. Le revers : personne ne sait comment l’équipement se comportera au prochain démarrage, parce que personne ne l’a vu démarrer depuis des années.
La peur du terrain n’est pas le correctif, c’est le non-redémarrage. Sur un site isolé, les équipes avec lesquelles nous travaillions ont connu deux jours de pirogue pour aller dépanner physiquement un équipement qui ne répondait plus. Quand c’est le prix d’un échec, on ne touche à rien.
Selon l’enquête 2024 de TXOne Networks auprès de 150 dirigeants, 47 % citent la crainte d’une interruption de production comme frein aux correctifs, et 48 % le manque de personnel ou de compétences.
Problème 3 : l’achat en une fois
Les travaux de conformité CRA nous ont appris une chose que ni le vendeur ni l’acheteur n’avaient formulée : aucune modalité de mise à jour n’avait été prévue. Le constructeur ne la proposait pas toujours, et l’acheteur n’avait jamais acheté des années de maintenance logicielle au-delà de la garantie.
Le maintien en condition opérationnelle et de sécurité, le MCO/MCS que l’informatique connaît bien, n’existait pas dans ces contrats. L’équipement s’achetait comme une pompe : un prix, une garantie, puis la maintenance mécanique.
Problème 4 : personne ne tient le logiciel côté exploitant
Dernier blocage, une fois les trois premiers levés : qui applique la mise à jour dans l’usine ? La maintenance mécanique et matérielle est organisée, avec un responsable, un planning et un contrat. Le logiciel, lui, n’a pas de responsable.
Quand nous creusons pour en désigner un, nous ne trouvons aucune compétence de maintenance logicielle sur ces équipements. L’automaticien sait programmer la machine, pas qualifier un correctif du système embarqué. Ce n’est pas un défaut de personnes, c’est un poste qui n’a jamais été créé.
Ce que nous en retenons
Les mises à jour OT sont complexes, et le sujet se traite, à condition de nommer les vrais problèmes. Chacun a son propriétaire.
Constructeur : avant la fin de la conception, décrire le chemin de mise à jour de chaque brique logicielle, le tester sur un exemplaire et prévoir le retour arrière.
Acheteur : dès la prochaine consultation, inscrire dans le contrat la période d’assistance (cinq ans au minimum selon le CRA), le prix de la maintenance logicielle et la fenêtre de qualification d’un correctif.
Exploitant : d’ici la fin du trimestre, nommer un responsable du logiciel par famille d’équipements, et obtenir un banc d’essai ou une fenêtre de maintenance par an pour redémarrer en conditions maîtrisées.
Décision clé : une mise à jour OT ne se décide pas le jour où le correctif sort, elle se prépare le jour où l’équipement s’achète.
Chez vous, qui est responsable du logiciel de vos équipements industriels ? Si l’article vous a plu, faites-le circuler dans votre réseau : un simple partage nous aide beaucoup.