Quand le froid s'arrête, c'est toute la chaîne qui flanche — retour sur une crise qui aurait pu être évitée

# Quand le froid s'arrête, c'est toute la chaîne qui flanche — retour sur une crise qui aurait pu être évitée

*Retour terrain — Sécurité & Conformité*

C'était un mardi matin de février. Une ETI industrielle de 800 salariés, spécialisée dans la transformation agroalimentaire, découvre que ses systèmes de régulation thermique ne répondent plus. Pas une panne mécanique. Une cyberattaque. En quelques heures, les chambres froides perdent leur paramétrage, les capteurs remontent des données corrompues, et les automates de régulation — pilotés depuis une plateforme de supervision centralisée hébergée chez un acteur américain — sont rendus silencieux.

Le DSI que j'ai rencontré plusieurs semaines après les faits avait encore ce regard de quelqu'un qui rejoue mentalement chaque décision prise dans les 72 heures de crise. "On ne pensait pas que la surface d'attaque incluait nos frigos", m'a-t-il dit. Ce n'est pas de la naïveté. C'est le résultat d'une architecture pensée pour la performance, pas pour la résilience — et construite autour d'une dépendance que personne n'avait vraiment auditée.

L'architecture qui a tout aggravé

L'entreprise avait, comme beaucoup d'ETI industrielles européennes entre 2020 et 2023, accéléré sa transformation numérique. Elle avait choisi une solution de supervision OT/IT intégrée, commercialisée par un éditeur américain, pour unifier le pilotage de ses lignes de production et de ses équipements frigorifiques. Sur le papier, c'était du bon sens opérationnel : une interface unique, des dashboards temps réel, des alertes centralisées.

Mais cette centralisation avait un prix caché. Toutes les données de capteurs, tous les paramètres de régulation, tous les historiques de maintenance remontaient vers des serveurs hors sol européen. Le contrat prévoyait un hébergement "en Europe", mais les sous-traitants techniques de l'éditeur américain, eux, étaient soumis au Cloud Act. En cas d'injonction d'une autorité fédérale américaine, les données de production de cette ETI — y compris les schémas de vulnérabilité de son infrastructure industrielle — pouvaient légalement être transmises sans que l'entreprise en soit informée.

Je ne dis pas que c'est ce qui s'est passé ici. Je dis que personne dans cette entreprise n'avait posé la question. Et c'est précisément ça, le problème.

La crise, heure par heure

Lorsque l'attaque a été détectée, le premier réflexe a été d'appeler le support de l'éditeur américain. Fuseau horaire défavorable, procédures de ticketing inadaptées à l'urgence industrielle, escalade lente. Pendant ce temps, les équipes terrain tentaient de reprendre la main manuellement sur les automates — avec des notices papier parfois datant de plus de dix ans, parce que personne n'avait prévu que le numérique tomberait en même temps que les procédures de secours seraient inaccessibles (elles étaient, elles aussi, stockées dans la plateforme compromise).

La perte n'a pas été catastrophique en termes de volumes. Mais elle aurait pu l'être. Et surtout, l'entreprise a découvert en temps réel l'étendue réelle de sa dépendance : elle n'avait plus les moyens de piloter son cœur de métier sans passer par une infrastructure qu'elle ne contrôlait pas, hébergée par un tiers soumis à une juridiction étrangère, avec des SLA de reprise pensés pour des entreprises tertiaires, pas pour une chaîne du froid agroalimentaire.

Ce que NIS2 et DORA auraient exigé — et qu'on n'avait pas fait

En 2026, la directive NIS2 est transposée dans la quasi-totalité des États membres de l'Union européenne. Les ETI industrielles du secteur agroalimentaire entrent, selon leur taille et leur secteur, dans le périmètre des "entités importantes" ou "entités essentielles". Cela implique des obligations concrètes : cartographie des risques, plans de continuité d'activité testés, notification des incidents sous 24 heures, et — point souvent sous-estimé — maîtrise de la chaîne de sous-traitance numérique.

Or, cette ETI n'avait pas cartographié l'éditeur américain comme un prestataire critique. Elle l'avait traité comme un outil SaaS parmi d'autres. C'est une erreur de classification qui, en cas de contrôle post-incident, expose à des sanctions significatives — et surtout, qui révèle une incompréhension profonde de ce que signifie "criticité" dans une architecture OT/IT convergée.

DORA, lui, s'adresse principalement au secteur financier — mais les principes qu'il pose (tests de résilience, registre des dépendances tierces, exigences contractuelles envers les prestataires cloud) devraient servir de modèle à toute ETI industrielle qui prend au sérieux la continuité de son activité. Ce n'est pas de la compliance pour la compliance. C'est une grille de lecture qui force à regarder en face ce qu'on délègue — et à qui.

La question souveraine, concrètement

Je veux être direct ici, parce que le sujet le mérite.

Quand une ETI européenne confie le pilotage de son infrastructure industrielle critique à un acteur soumis au Cloud Act, elle ne fait pas seulement un choix technique. Elle fait un choix géopolitique. Elle accepte implicitement qu'une autorité non européenne puisse, dans certaines circonstances, accéder à des informations sur son outil de production. Ses recettes de fabrication. Ses volumes. Ses vulnérabilités.

En 2026, après des années de tensions commerciales transatlantiques, de décisions de la Cour de justice de l'Union européenne sur les transferts de données, et de montée en puissance des obligations réglementaires européennes, cette acceptation implicite n'est plus tenable. Ce n'est pas une posture idéologique. C'est une analyse de risque.

Des alternatives existent. Des éditeurs européens — je pense notamment à des acteurs spécialisés en supervision industrielle comme Ubisense ou des intégrateurs OT certifiés SecNumCloud — proposent des architectures qui gardent les données et les flux de commande en juridiction européenne. Ces solutions ne sont pas toujours aussi polies que les offres américaines. Parfois moins intégrées, parfois moins documentées en anglais. Mais elles répondent à une exigence fondamentale : l'entreprise reste maître de son infrastructure.

Trois conclusions transférables

Première conclusion : la centralisation opérationnelle est un risque de sécurité. Unifier le pilotage, c'est aussi unifier le point de défaillance. Une architecture résiliente prévoit des îlots de fonctionnement autonome, capables de tenir pendant une crise même déconnectés du cloud central. Pour une chaîne du froid, cela signifie des automates locaux capables de maintenir les paramètres de sécurité sans remontée vers un serveur distant.

Deuxième conclusion : les procédures de secours doivent survivre à la panne numérique. C'est une évidence que la crise remet brutalement en lumière. Les plans de continuité, les notices techniques, les contacts d'urgence ne peuvent pas vivre exclusivement dans les mêmes systèmes que ceux qui tomberont en premier lors d'une attaque.

Troisième conclusion : auditer ses prestataires sous l'angle de l'extraterritorialité, c'est désormais une obligation de direction. Pas seulement une case RGPD à cocher. Une vraie question posée en CODIR : quel prestataire critique est soumis à quelle juridiction ? Que se passe-t-il contractuellement si ce prestataire reçoit une injonction d'une autorité étrangère ? La réponse à ces questions doit figurer dans le registre des risques — et être connue du DSI, du RSSI, et de la direction générale.

L'ETI dont je parle s'en est sortie. Elle reconstruit aujourd'hui son architecture en segmentant les flux OT et IT, en rapatriant le pilotage critique sur des équipements locaux, et en requalifiant ses prestataires selon leur juridiction d'appartenance. Ce travail aurait dû être fait avant la crise. Il l'est maintenant.

Le coût de la résilience est toujours inférieur au coût de la panne. Mais il faut, pour s'en convaincre, avoir senti l'odeur d'une chambre froide qui remonte en température un mardi matin de février.