L'OT oubliée : des centaines de supermarchés français perdent leur réfrigération
Dans la nuit de dimanche à lundi, des attaquants ont détourné à distance les systèmes de contrôle de réfrigération de supermarchés français et fait monter les températures en déclenchant la fonction de dégivrage automatique intégrée aux régulateurs. Le personnel a trouvé à son arrivée des stocks décongelés et avariés. La presse française fait état de 250 à 350 magasins touchés, parmi lesquels Intermarché, Super U et Coopérative U, Carrefour Market, Monoprix et Leclerc. Les pertes rapportées se chiffrent de dizaines à centaines de milliers d’euros par entreprise concernée. Le parquet de Paris a ouvert une enquête, reliant l’attaque aux pertes alimentaires et à des départs de feu signalés.
Les systèmes touchés fonctionnent avec des versions plus anciennes du logiciel de contrôle du fabricant danois Danfoss. La manière dont les attaquants se sont introduits n’a pas été confirmée.
Il s’agissait d’une attaque OT, pas d’une violation IT
Rien n’a été chiffré. Aucune donnée n’a été volée. Aucune demande de rançon n’est apparue. Les attaquants n’avaient besoin de rien de tout cela, car ils ne se trouvaient pas dans le périmètre IT. Ils se trouvaient dans la technologie opérationnelle (OT) : les systèmes de contrôle qui pilotent les processus physiques.
Un régulateur de réfrigération est un système de contrôle industriel au même titre qu’un régulateur de pompe ou qu’un automate (PLC) de ligne de production. Il lit des capteurs, maintient des consignes et pilote des équipements. Les attaquants ne l’ont pas piraté au sens propre — ils l’ont utilisé exactement comme prévu, en déclenchant un cycle de dégivrage que le régulateur propose comme fonction standard. Du point de vue du système, rien d’anormal ne s’est produit.
C’est la caractéristique déterminante des attaques OT, et la raison pour laquelle les contrôles de sécurité IT ne les détectent pas. Il n’y a pas de malware à détecter, pas de processus anormal à signaler, pas d’exfiltration à repérer. L’action malveillante est une commande légitime, exécutée par quelqu’un qui ne devrait pas pouvoir l’exécuter.
Les conséquences diffèrent aussi par nature. Une compromission IT coûte à une organisation ses données et sa productivité, et il existe généralement un chemin de retour via les sauvegardes. Une compromission OT coûte des produits physiques, des équipements physiques, et aurait dans ce cas provoqué des départs de feu. Il n’existe pas de clé de déchiffrement pour des stocks décongelés.
Pourquoi l’OT est accessible en premier lieu
Ce qui est confirmé dans ce cas, c’est l’exposition. Lundi, le chercheur en sécurité Baptiste Robert a recensé 2 752 systèmes Danfoss directement accessibles depuis l’internet ouvert, dont 1 590 en France. Shodan référençait plus de 4 500 appareils Danfoss accessibles.
C’est l’état normal de l’OT, pas une exception. La CISA a averti en mai 2025 d’une faille de contournement d’authentification dans la série Danfoss AK-SM 8xxA, puis en août 2025 d’une faille d’injection de commandes sur la même plateforme matérielle. L’équipe Team82 de Claroty, qui a découvert les deux failles, a démontré une exécution de code à distance sur des interfaces de gestion accessibles publiquement. Un firmware corrigé existe. Que ces failles précises aient été exploitées ici n’est pas confirmé, mais le schéma qu’elles décrivent l’est : des systèmes de contrôle directement accessibles, avec un firmware en retard de plusieurs années.
Trois raisons structurelles expliquent comment l’OT en arrive à cet état, et elles s’appliquent aussi bien à une chaîne de supermarchés qu’à un fabricant, un opérateur logistique ou un portefeuille immobilier.
L’OT est acquise et maintenue en dehors de l’IT. Un prestataire frigoriste, un intégrateur de gestion technique du bâtiment ou un fournisseur de machines installe l’équipement et le connecte pour la maintenance à distance. Cette connexion est raisonnable et nécessaire. Elle n’est cependant jamais examinée par quiconque a la sécurité, car elle ne figure sur aucun schéma réseau.
L’OT est absente de l’inventaire des actifs. Les analyses de vulnérabilités couvrent ce que l’organisation sait posséder, et les systèmes de contrôle figurent rarement sur cette liste. Une alerte peut être publiée, reconnue par le fournisseur et corrigée par firmware sans jamais atteindre la personne responsable de l’appareil.
La disponibilité de l’OT prime sur son patching. Ces systèmes fonctionnent en continu et ne sont mis à jour qu’en cas de défaillance, pas selon un cycle. Un régulateur qui fonctionne depuis six ans est considéré comme fiable, et la question du firmware ne se pose que lorsqu’il tombe en panne.
La détection a fait la différence
Certains magasins ont pu sauver leurs stocks. La raison mérite d’être notée précisément : les responsables ont reçu des alertes sur les variations de température, ou les systèmes ont été touchés peu avant l’ouverture et quelqu’un s’en est aperçu.
C’est de la surveillance OT, même si personne ne l’a appelée ainsi. La différence entre un incident maîtrisé et une perte totale a tenu au fait qu’un changement d’état du processus parvienne ou non à une personne capable d’agir.
La plupart des organisations ont inversé les priorités. Elles disposent d’une alerte 24h/24 et 7j/7 sur des serveurs qui peuvent tolérer une heure d’indisponibilité, et d’aucune alerte sur des processus physiques qui ne tolèrent pas vingt minutes.
Par où commencer
Commencez par la visibilité sur l’OT, car rien d’autre n’est possible sans elle. Constituez un inventaire de chaque système de contrôle de votre environnement : réfrigération, CVC, contrôle d’accès, gestion de l’énergie, équipements de production, ascenseurs, centrales d’alarme. Pour chacun, consignez qui l’a installé, qui le maintient, comment il est accessible et quel firmware il exécute. Dans la plupart des organisations, c’est un exercice ponctuel qui n’a jamais été mené, et il fait invariablement apparaître des systèmes dont personne ne savait qu’ils étaient connectés.
Déterminez ensuite ce qui est accessible depuis l’extérieur. Demandez à chaque prestataire de maintenance à quels systèmes il accède à distance et par quelle voie, puis vérifiez-le indépendamment par rapport à vos plages d’adresses externes plutôt que de prendre la réponse pour argent comptant. Des services comme Shodan vous montrent ce qu’un attaquant voit.
Segmentez ce que vous trouvez. L’OT ne devrait pas être directement accessible depuis l’internet, ni se trouver à plat à côté de l’IT bureautique. La maintenance à distance doit passer par un accès authentifié, limité dans le temps et journalisé, vers une zone segmentée qui ne peut pas atteindre le reste du parc — pas sur une interface publique avec un mot de passe fournisseur.
Attribuez contractuellement la responsabilité du firmware. Dans la plupart des contrats de maintenance, personne n’est explicitement responsable d’agir sur une alerte de sécurité — c’est ainsi qu’un régulateur continue de fonctionner dix-huit mois après la publication d’une faille de contournement d’authentification documentée. Désignez par écrit le responsable et un délai de réaction pour les alertes critiques.
Enfin, surveillez l’état du processus, pas seulement l’infrastructure. Les variations de température, de pression, de durée de fonctionnement et de consigne devraient générer des alertes qui atteignent, à toute heure, quelqu’un capable d’agir, via un canal indépendant du système concerné. Une alarme affichée sur un écran dans une arrière-boutique n’est lue que le lendemain matin — ce qui, dans cet incident, était déjà trop tard.
Message clé : Il s’agissait d’une attaque contre la technologie opérationnelle, menée entièrement via des fonctions légitimes du régulateur — ce pour quoi une sécurité IT classique ne l’aurait pas détectée. Des milliers de systèmes de contrôle comparables restent directement accessibles depuis l’internet. L’OT est une infrastructure critique pour l’activité qui échappe à la plupart des programmes de sécurité parce qu’un prestataire externe l’a installée et que personne ne l’a inventoriée. Constituez l’inventaire des actifs OT, déterminez ce qui est accessible depuis l’extérieur, segmentez la maintenance à distance derrière un accès authentifié, attribuez contractuellement la responsabilité du firmware, et alertez sur l’état du processus pour que quelqu’un s’en aperçoive pendant que les dégâts peuvent encore être contenus.
