En trois lignes. L’attaque des frigos de supermarché est un précédent fondateur, comme Stuxnet l’a été en 2010 : elle est publique, attribuée à un État, et elle a déjà été rejouée. La température n’est pas le sujet, l’impact opérationnel l’est : que fait-on quand tous les magasins tombent la même nuit ? La première vague s’explique, la seconde ne s’excuse pas : les équipements anciens branchés sur Internet doivent être traités maintenant.

Dans la nuit du 11 au 12 octobre 2026, les meubles froids d’environ 700 points de vente français se sont mis à chauffer. Le 9 novembre, le ministre des Affaires étrangères Jean-Noël Barrot a attribué l’opération aux Gardiens de la révolution iraniens (franceinfo, France 24). Nous retenons autre chose que la géopolitique : le métier vient de recevoir son deuxième précédent.

Stuxnet avait prouvé la compétence, pas la banalité

En 2010, Stuxnet a montré que des gens savaient saboter un automate industriel et qu’ils le faisaient. La leçon est restée rangée au rayon du critique : centrifugeuses, énergie, eau. En France, nous disons « d’importance vitale », et la loi de programmation militaire de 2013 a suivi cette logique.

Le frigo d’un supermarché n’a jamais eu droit à ce vocabulaire. C’était un sujet de frigoriste, pas un sujet de sécurité. Il aura donc fallu des yaourts tièdes pour obtenir ce que quinze ans de conférences n’avaient pas obtenu : l’attention d’un comité de direction.

Dix ans de frigos branchés n’importe comment

Soyons honnêtes, l’histoire du frigo connecté est vieille comme le monde. Depuis le début, nous voyons des réseaux électriques, des centrales de froid, des téléviseurs et des moniteurs de surveillance de patients posés directement sur Internet. La télémaintenance le demandait, et le mot de passe d’usine dépannait tout le monde.

Rien de tout cela n’est caché. Shodan est un moteur de recherche qui indexe, non pas des pages web, mais les équipements joignables depuis Internet, avec leur marque et leur version. FOFA est son équivalent chinois. Le 12 octobre, BleepingComputer relevait plus de 4 500 équipements du fabricant concerné visibles sur Shodan, et le chercheur Baptiste Robert (Predicta Lab) en comptait 2 752, dont 1 590 en France. Selon Next, FOFA fait partie des outils habituels de l’unité mise en cause.

Deux bulletins de la CISA, l’agence américaine de cybersécurité, signalaient dès mai et août 2025 des failles sur cette famille de contrôleurs. Aucune source ne dit qu’elles ont servi ici, et BleepingComputer précise que le mode d’entrée n’est pas établi. Nous ne le supposerons pas.

Le thermomètre va très bien, merci

Mesurer une température, tout le monde sait faire. Les sondes ont parfaitement fonctionné : elles ont enregistré la montée, minute par minute.

Le vrai sujet est l’impact opérationnel. Franceinfo rapporte des pertes alimentaires importantes et une vingtaine de départs de feu. Derrière ces mots, il y a des questions très concrètes. Qui décide de détruire le stock ? Qui appelle le frigoriste quand 700 magasins appellent le même, la même nuit ? Combien de techniciens a-t-il ? Qui rouvre le rayon, sur quelle preuve ?

Ces questions n’ont rien de numérique. Elles ont été posées en direct, par des directeurs de magasin, un dimanche soir. Nous pensons à ces équipes : elles ont géré une crise que personne ne leur avait fait répéter.

Ces impacts physiques, nous les montrons aussi dans notre simulateur, maillon par maillon. Vous pouvez aller voir directement.

Jouez gratuitement avec notre simulateur

La première vague s’explique, la seconde ne s’excuse pas

On peut critiquer les victimes d’octobre, et les excuser en même temps. Il n’existait pas de précédent récent de sabotage du froid commercial en France. Le risque figurait dans des rapports, pas dans des souvenirs.

Dans la nuit du 1er au 2 novembre, trois semaines plus tard, une douzaine de pays européens ont connu la même scène, avec au moins une centaine de magasins visés (Points de Vente). Les autorités n’ont pas relié officiellement les deux vagues. Le fabricant, lui, indique que la majorité des magasins avaient pris des mesures après octobre, et qu’un petit nombre ne l’avait pas fait.

Mon avis : trois semaines, avec la une de tous les journaux et les consignes du fabricant, c’est long. La seconde vague est inexcusable.

Décision clé : un précédent public et rejoué transforme un risque théorique en négligence. Les équipements anciens exposés sur Internet ne sont plus une dette technique, ils sont une obligation.

Ce que le précédent impose

Trois gestes, pour tout site qui a du froid, de la gestion technique de bâtiment ou des automates.

• Responsable informatique, cette semaine : chercher les adresses IP publiques de l’entreprise dans Shodan et lister chaque équipement technique qui répond. Tout ce qui répond doit passer derrière un accès distant protégé sous 30 jours.

• Responsable maintenance, avec le frigoriste, sous 15 jours : remplacer chaque mot de passe d’usine, et dresser la liste des contrôleurs qui ne reçoivent plus de mises à jour, avec une date de remplacement inscrite au budget 2027.

• Direction d’exploitation, avant la fin de l’année : jouer pendant une heure le scénario « tous les sites en panne de froid la même nuit ». Le critère de réussite : savoir qui décide de la destruction du stock et qui est appelé en premier.

Jouez gratuitement avec notre simulateur

Chez vous, qui décroche si tous les sites perdent le froid la même nuit ? Si l’article vous a plu, faites-le circuler dans votre réseau : un simple partage nous aide beaucoup.

Références

• franceinfo, « La France accuse l’Iran de la cyberattaque contre des frigos de supermarchés », 9 novembre 2026 : franceinfo.fr

• France 24, « Cyberattaques contre des frigos de supermarchés : la France accuse l’Iran », 9 novembre 2026 : france24.com

• Next, « Cyberattaque contre les frigos de 700 supermarchés : pourquoi la France accuse l’Iran », novembre 2026 : next.ink

• BleepingComputer, « Cyberattack shuts down refrigerators at French supermarkets », 12 octobre 2026 : bleepingcomputer.com

• Points de Vente, « Cyberattaques de frigos : la vague s’étend en Europe », 4 novembre 2026 : pointsdevente.fr

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.

Accéder au simulateur

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.

J'en ai fait un post à chaud sur LinkedIn. Voici la version longue, avec ce que nous avons appris depuis.

Le contexte

Deux failles critiques du moteur PHP, baptisées PHP2Shell (CVE-2026-109618 et CVE-2026-109619), ont été publiées puis exploitées dans la foulée. Elles permettent d'exécuter du code à distance, sans authentification, en configuration par défaut. L'avis 2026-018 du CERT-EU détaille les contournements possibles pour chacune.

Sur le papier, la réponse tient en une ligne : passer en PHP 8.2.35. Sur le terrain, c'est une autre histoire, parce que PHP est partout.

Ce que nous avons vu

Le site corrigé, sauf une adresse. Un site WordPress a été mis à jour dans la journée par son prestataire. Notre contrôle non intrusif du soir trouvait cinq adresses sur six corrigées, et le flux /feed/ encore vulnérable à chaque mesure. Le lendemain, tout était bon, sans que nous sachions si la cause était un cache ou un processus pas encore redémarré.

Le produit qui embarque du PHP. Chez un fabricant d'équipements, l'interface d'administration tourne sur PHP, en deux générations. La plus récente se corrige ; la plus ancienne, en PHP 5.6, n'aura jamais de correctif. La nomenclature logicielle (SBOM) n'inventoriait même pas les paquets PHP.

L'usine qui n'expédie plus. Conséquence directe : les produits finis restent en stock plutôt que de partir avec une interface vulnérable. C'est moins cher que de tout corriger une fois les équipements installés, mais les palettes s'accumulent.

Le sous-domaine oublié. Dans un établissement de santé, la cartographie ne mentionnait aucune application en PHP. Le site institutionnel tourne pourtant sur un CMS en PHP, chez un hébergeur externe. Les journaux publics de certificats nous ont montré un second sous-domaine, créé un mois plus tôt sur le même serveur.

Ce qui nous a surpris

Les réponses sans preuve. Une agence web nous a écrit que les hébergeurs avaient appliqué le correctif, sans version ni capture. Un infogérant a été plus précis : serveurs mis à jour, serveurs à décommissionner, recherche de compromission en cours. C'est la seconde réponse qui permet de piloter.

L'éditeur qui demande un accès en pleine crise. Un éditeur SaaS, lui-même en incident, a demandé à un client un accès de connexion à son environnement pour vérifier l'exposition. Nous avons déconseillé de l'accorder. L'éditeur a fini par désactiver ses propres briques PHP, sans aucun accès.

Les questions d'après. Un fabricant s'est demandé dès le lendemain s'il devait signaler la vulnérabilité aux autorités, au titre de l'article 14 du Cyber Resilience Act. Et même à jour, PHP 8.2 ne reçoit plus que des correctifs de sécurité jusqu'au 31 décembre 2026, selon le calendrier publié sur php.net : la migration en PHP 8.4 est déjà la prochaine étape.

Ce que nous en retenons

La vraie question n'était pas « est-ce qu'on est patché ? », mais « où est-ce qu'on a du PHP ? ». Et la plupart du temps, personne n'avait la liste.

• Inventorier par technologie : d'ici la fin du mois, le RSSI demande à chaque responsable d'application sur quoi elle tourne, hébergeur et équipements des fournisseurs compris.

• Exiger une preuve : avant de clore, une version relevée ou un contrôle externe, adresse par adresse.

• Tracer chaque échange : qui a été alerté, quand, et ce qu'il a répondu. Cinq jours après, c'est ce qui dit où on en est.

Décision clé : cette crise n'est pas une crise de correctifs, c'est une crise d'inventaire.

Notre simulateur

Un livre blanc sur une faille ne dit pas quoi faire le jour où elle frappe. Notre simulateur vous montre comment neutraliser une attaque et comment la prévenir. Vous êtes dans la salle, vous repérez la menace et vous la neutralisez, puis vous voyez le geste qui l'aurait évitée. L'accès est gratuit, sur demande.

Accéder au simulateur

Chez vous, quelle a été la galère PHP depuis le 21 octobre ? Si l'article vous a plu, faites-le circuler dans votre réseau : un simple partage nous aide beaucoup.

TL;DR

• Depuis quelques mois, nos incidents de phishing aboutissent à la prise de comptes, y compris de comptes administrateurs Entra ID.

• Les attaquants créent des boîtes partagées et effacent les emails envoyés en interne pour rester crédibles.

• Ils avaient de quoi tout casser et ne l’ont pas fait : nous pensons à des escrocs guidés par l’IA.

• Chaque alerte de faible intensité déclenche désormais deux vérifications, sans exception.

Contexte

Depuis quelques mois, l’équipe enchaîne des incidents qui ne ressemblent pas aux précédents. Le point de départ est classique : un email de phishing réussi, un mot de passe et un code MFA saisis sur une fausse page. La suite l’est beaucoup moins. Dans plusieurs cas, le compte pris en main était un compte administrateur de l’instance Microsoft Entra ID (l’ex Azure AD) du client.

Ce n’est pas une surprise statistique. Selon le Data Breach Investigations Report 2025 de Verizon, l’usage d’identifiants volés reste le premier vecteur d’accès initial, dans 22 % des violations analysées. Ce qui nous a surpris, c’est la suite.

Figure 1 : Les identifiants volés restent la première porte d’entrée (source : Verizon, Data Breach Investigations Report 2025).

Ce que nous avons vu

Une fois dans la place, les attaquants ont travaillé la crédibilité plutôt que la destruction. Sur le terrain, ça donne :

• des boîtes aux lettres partagées créées discrètement, pour piloter les envois sans passer par la boîte de la victime ;

• les emails envoyés en interne depuis le compte compromis supprimés au fil de l’eau, pour que personne ne remarque la vague partie au nom d’un collègue ;

• un nouveau phishing lancé en interne, depuis une adresse légitime, avec un ton juste et sans faute.

Figure 2 : Une fois administrateurs, les attaquants ont soigné leur crédibilité, pas la casse.

Le phishing interne est redoutable : quand le message vient de la comptabilité ou de la direction, le réflexe de méfiance tombe.

Ce qui nous a surpris

Avec un compte administrateur Entra ID, on peut presque tout faire : créer des comptes, attribuer des rôles, désactiver des protections, effacer. Les attaquants avaient ce pouvoir de nuisance. Ils ne s’en sont pas servis.

Figure 3 : Ils pouvaient presque tout casser, ils se sont contentés de phisher.

Nous avons longtemps cherché la pièce manquante. Notre conclusion, assumée même si elle reste une hypothèse : nous n’avions pas affaire à un groupe de rançongiciel, mais à des escrocs qui se sont servis de l’IA pour aller plus loin que leur niveau habituel. Ils savaient monter une campagne de phishing. Pour le reste, ils suivaient un mode d’emploi.

Pour en avoir le cœur net, nous avons rejoué leurs demandes avec Kimi, l’assistant de l’éditeur chinois Moonshot AI. Il nous a expliqué la marche à suivre, sans aucun filtre. Nous ne la reproduirons pas ici. Retenez simplement que la compétence n’est plus la barrière : il suffit de savoir poser la question.

Ce que nous avons appris

Face à une alerte de faible intensité (une connexion inhabituelle, une règle de boîte mail, un pays inattendu), le réflexe était d’évaluer, puis souvent de classer. Ce n’est plus le cas. Chaque alerte de ce type déclenche désormais deux vérifications, systématiquement :

1. Vérifier qu’aucun appareil tiers n’a été enregistré. Un téléphone ou un poste ajouté au compte donne à l’attaquant un accès durable, qui survit au changement de mot de passe. Nous regardons les appareils inscrits et les méthodes d’authentification ajoutées récemment.

2. Retracer l’activité de l’attaquant dans Entra ID. Journaux d’audit et de connexion : rôles attribués, comptes créés, boîtes partagées, applications autorisées. C’est là que nous avons trouvé ce que la victime ne voyait pas.

Figure 4 : Deux vérifications avant de classer la moindre alerte.

C’est plus long, et la plupart du temps on ne trouve rien. Mais une alerte faible sur un compte administrateur ne se classe plus sans avoir regardé.

Ce qu’il faut retenir

L’IA ne fabrique pas d’attaquants de haut vol. Elle donne à des escrocs moyens des gestes d’administrateur qu’ils n’auraient jamais su faire seuls. Microsoft l’a mesuré dans son Digital Defense Report 2025 : les emails de phishing automatisés par l’IA obtiennent 54 % de clics, contre 12 % pour les tentatives classiques.

Figure 5 : Le phishing écrit par l’IA fait cliquer 4,5 fois plus (source : Microsoft, Digital Defense Report 2025).

Le risque change de forme : moins de casse spectaculaire, plus d’usurpation crédible et durable. Selon moi, la priorité n’est pas d’acheter un outil de plus. C’est de traiter chaque compte administrateur comme une cible, et chaque petite alerte sur ce compte comme une piste.

Notre simulateur

Nous mettons à jour le simulateur cybersécurité CyberLead au fil de ces incidents : chaque scénario vécu devient une activité à repérer puis à neutraliser.

Figure 6 : Chaque incident vécu devient un scénario du simulateur.

L’accès est gratuit, mais il est réservé aux personnes qui ont le besoin d’en connaître. La demande se fait sur cyberlead.fr/simulateur.

Insight CyberLead : Un compte administrateur Entra ID compromis qui ne fait « rien » n’est pas une bonne nouvelle. C’est souvent le signe d’un attaquant qui prépare une usurpation durable : boîtes partagées, appareils enregistrés, emails effacés. Le silence est un indice, pas un soulagement.

Chez vous, qui vérifie les appareils enregistrés après une alerte de connexion ? Si l’article vous a plu, faites-le circuler dans votre réseau : un simple partage nous aide beaucoup.

Dans la nuit du 11 au 12 octobre, des installations de froid de magasins Coopérative U, Intermarché, E.Leclerc et Monoprix ont été touchées par une cyberattaque. Nous ne connaissons pas son déroulé. Ce que nous connaissons, ce sont les chemins que nous constatons chez nos clients sur des installations comparables. Et ils passent par la maintenance.

Ce qui s’est passé

Selon la presse (franceinfo, AFP, CNEWS), plusieurs enseignes de la grande distribution ont vu leurs installations de froid touchées dans la nuit du 11 au 12 octobre : entre 150 et 200 magasins Intermarché et moins d’une centaine de magasins Coopérative U selon les enseignes. Produits frais et surgelés jetés, rayons fermés. Le parquet de Paris a ouvert une enquête confiée à l’Ofac et l’ANSSI a été saisie. Le mode opératoire n’est pas établi officiellement, et nous ne le commenterons pas. Toute notre sympathie va aux équipes cyber, IT et magasins qui passent ces journées en crise.

Ce que nous constatons sur le terrain

Nous n’avons pas de retour des structures touchées. Mais sur des installations de froid comparables, le schéma est toujours le même : le chemin d’un attaquant est celui du frigoriste. Ce que le frigoriste fait tous les jours pour dépanner, un attaquant peut le refaire avec les mêmes accès. Seule l’intention change. Chaque accès ouvert pour la maintenance est donc une porte d’entrée.

Nous en voyons trois :

• la télémaintenance du constructeur ou de l’intégrateur GTC, plus rare ;

• les accès distants des frigoristes : routeur 4G, VPN partagé, outil de prise en main installé « pour l’astreinte » ;

• la passerelle d’envoi d’alertes SMS / e-mail. C’est celle que personne ne regarde, et celle que nous trouvons le plus souvent piratée.

Les risques

Le premier est sanitaire : une rupture de la chaîne du froid oblige à détruire les produits. Le second est financier : stock perdu et rayons fermés, jusqu’à plusieurs centaines de milliers d’euros par magasin selon les premières estimations de presse. Une régulation détournée peut aussi endommager les installations. Enfin, l’effet d’échelle : un accès ou un équipement commun à de nombreux sites les expose tous à la fois.

Quatre mesures à mettre en place cette semaine

1. Télémaintenance. Inventoriez chaque accès : routeur 4G, VPN constructeur, prise en main à distance. Fermé par défaut, ouvert à la demande, journalisé.

2. Accès des frigoristes. Un accès distant ouvert par le magasin le temps de l’intervention, avec un point d’entrée unique, journalisé. Sur site, toute clé USB passe en station blanche avant de toucher la GTC.

3. Passerelle d’alerte SMS / e-mail. Jamais exposée sur Internet, mot de passe d’usine changé, micrologiciel à jour, flux sortant uniquement.

4. GTC et régulateurs. Superviseurs en fin de vie remplacés ou isolés, consignes bornées en local, alerte sur tout changement de consigne.

Aller plus loin

Pour la contextualiser à votre site, nous regardons ensemble vos chambres froides, vos accès distants et votre GTC, et nous voyons ce qui s’applique chez vous.

Contacter nos experts

N’hésitez pas à partager cette fiche à ceux qui ont des frigos avec des connexions externes : directeurs de magasin, services techniques, frigoristes.

Nous sortons d’un audit cybersécurité chez un client industriel. Je ne le nommerai pas, mais ce que l’équipe y a trouvé mérite d’être partagé avec toute la communauté, parce que nous ne l’avions pas vu venir.

Le contexte

Nous étions venus pour un audit classique de site de production : réseau OT, postes de supervision, accès des prestataires, sauvegardes. Le contrôle qualité n’était même pas dans notre périmètre de départ. Pour nous, comme pour beaucoup, c’était un sujet métier : il vérifie que chaque pièce correspond à ce que le client a commandé, avant qu’elle ne quitte l’usine.

Ce que nous avons découvert

En suivant le parcours d’une pièce sur la ligne, nous nous sommes arrêtés au poste de contrôle. Tout y est paramétré : plans de contrôle dans le logiciel qualité, tolérances, fréquences d’échantillonnage, programmes des machines de mesure. L’opérateur lance, la machine compare, le lot passe ou ne passe pas.

Sur la plupart des sites que nous accompagnons, ces contrôles bougent peu. Une cote précisée, une tolérance resserrée après une réclamation, une amélioration de méthode : des évolutions rares et visibles.

Ici, c’était l’inverse. Les lots changent, et chaque semaine de nouveaux plans de contrôle sont redescendus sur la ligne, parfois complètement différents de ceux de la semaine précédente. Quand nous avons cherché comment on vérifiait qu’un plan reçu était bien celui qui avait été validé, nous n’avons trouvé aucun mécanisme en place. Personne ne se posait la question, parce que le changement était la norme.

Pourquoi nous l’avons classé critique

C’est à ce moment que l’audit a changé de priorité. Si tout change en permanence, une tolérance élargie ou un contrôle désactivé ne se distingue plus d’une mise à jour ordinaire. Erreur de saisie, compte partagé ou attaquant installé sur le réseau : le résultat est le même, et il ne se voit pas.

C’est ce qui nous a le plus marqués. Pas d’arrêt de production, pas d’écran rouge. La ligne tourne, les contrôles sont verts, les rapports sont signés. L’entreprise se croit conforme alors que le contrôle lui-même a pu être modifié. Le problème n’apparaît que des semaines plus tard, chez le client final.

Ce que nous avons recommandé

• Identifier d’où viennent les plans de contrôle et qui a le droit de les modifier.

• Tracer chaque version et la comparer à la référence validée avant qu’elle n’arrive sur la ligne.

• Exiger une double validation pour tout élargissement de tolérance ou désactivation de contrôle.

• Faire entrer le paramétrage qualité dans le périmètre cyber, au même titre que les automates.

Ce que nous en retenons

Depuis cette mission, nous regardons le contrôle qualité dynamique sur chaque site industriel. Que vous soyez en interne ou expert cybersécurité en mission, allez voir comment ces plans arrivent sur la ligne : la question est simple, la réponse peut être inquiétante.

Lancement de l’Attack Simulator Cyberlead

3 salles par univers. De plus en plus critiques. Chaque faille renvoie à un cas réel.
Jouez l'auditeur dans des lieux reconstitués, en 3 à 10 minutes par salle. La salle critique se visite en réalité virtuelle, accompagné.

Je n’aurais pas parié que la finance nous ferait changer notre façon de travailler dans l’industrie ou la santé. C’est pourtant ce qui s’est passé avec DORA.

Le contexte

DORA (Digital Operational Resilience Act, règlement (UE) 2022/2554) s’applique depuis le 17 janvier 2025 aux acteurs financiers et à leurs prestataires TIC. Il ne demande pas seulement d’être protégé : il demande de prouver que l’on continue de fonctionner pendant l’incident, et que l’on sait repartir. Son article 11 exige une politique de continuité des activités TIC avec des plans testés.

Nous avons été appelés sur ce sujet par des fonds d’investissement et des structures de taille moyenne. Des équipes réduites, un SI largement porté par des prestataires, et une échéance réglementaire bien réelle.

Le problème

Impossible de traiter DORA sans le PCRA, le plan de continuité et de reprise d’activité. Or nous venions pour la cybersécurité. Nous avons pris le sujet avec ses limites : des tests de bascule difficiles à organiser grandeur nature, des prestataires qui ne s’engagent pas toujours sur des délais de reprise, des arbitrages où il fallait accepter un plan imparfait plutôt que pas de plan du tout. Ce n’était pas parfait, c’était assumé.

Ce que nous avons compris en route

En construisant ces PCRA, nous avons réalisé que nous avions déjà une bonne partie de la matière. L’analyse de risques cybersécurité nous avait donné les événements redoutés : indisponibilité d’une application clé, perte de données, défaillance d’un prestataire. La cartographie nous avait donné le master process de l’organisation, c’est-à-dire les activités qui la font vivre. C’est précisément ce dont un bilan d’impact sur l’activité a besoin.

Décision clé : ne plus séparer cybersécurité et continuité. Le PCRA fait désormais partie de nos missions, quel que soit le secteur.

Mon avis

Je pense qu’il coûte beaucoup moins cher de demander à l’expert cybersécurité de poursuivre sur le PCI/PRI (plans de continuité et de reprise informatique), puis sur le PCA/PRA métier. Il connaît déjà les dépendances, les tiers, les points de rupture. Repartir de zéro avec un autre intervenant, c’est payer deux fois la même cartographie.

La condition, et je la pose clairement : que cette personne ait l’expérience du terrain et de votre secteur. Un PCA d’usine ne s’écrit pas comme celui d’un fonds, et un PCA d’hôpital encore moins.

Audit NIS2 offert.

DORA a imposé la continuité d’activité à la finance. NIS2 fait de même pour l’industrie, la santé, l’énergie et les services essentiels.

Un plan de reprise jamais testé reste une hypothèse. L'audit vous dit ce que vous pouvez réellement démontrer.

Contexte

Le Cyber Resilience Act impose des obligations de sécurité et de notification à tout fabricant d’objets connectés vendus en Europe. Une première échéance intervient dès le 11 septembre 2026 : elle concerne uniquement l’obligation de signaler les vulnérabilités activement exploitées et les incidents graves, en 24 heures pour l’alerte initiale et 72 heures pour la notification complète, auprès de l’ENISA et des CSIRT nationaux via la plateforme unique de signalement. Les exigences de fond - sécurité par conception, gestion des vulnérabilités, durée de support, marquage CE - ne deviennent obligatoires que le 11 décembre 2027. L’intention affichée est claire : rendre les objets connectés vendus en Europe réellement plus sûrs.

Problème

Le coût de mise en conformité : documentation technique, gestion des vulnérabilités, durée de support engagée. Cela absorbe une part de budget que peu de petits fabricants peuvent financer sans renoncer à autre chose.

Les grands acteurs disposent déjà des équipes juridiques et produit pour cocher les cases du règlement ; les plus petits, eux, risquent de disparaître ou de se faire racheter dans les prochaines années.

Une réglementation peut très bien réussir sa mission économique, consolider un marché, le professionnaliser, sans réussir sa mission de sécurité, à savoir rendre l’objet réellement plus sûr : ce sont deux résultats distincts, rarement débattus comme tels avant que le texte ne soit voté.

Décision clé

Suivre séparément deux indicateurs : la conformité réglementaire du produit, et sa sécurité réelle telle qu’un audit indépendant la mesurerait.

En pratique

• Identifier précisément les produits concernés par le règlement et leurs éléments numériques, plutôt que de traiter le CRA comme un sujet uniquement logiciel.

• Mettre en place, avant le 11 septembre 2026, un processus interne capable de tenir les délais de signalement : qui détecte, qui qualifie, qui notifie, dans quel ordre.

• Désigner un point de contact identifié pour la relation avec l’ENISA et les CSIRT nationaux, plutôt que de découvrir la procédure au moment du premier signalement réel.

• Ne pas attendre l’échéance de 2027 pour engager les exigences de fond - sécurité par conception, gestion des vulnérabilités, durée de support - qui demandent plus de temps à mettre en place qu’un simple ajustement documentaire.

• Évaluer la dépendance à des sous-traitants ou fournisseurs de composants trop petits pour absorber seuls le coût de mise en conformité, avant que le sujet ne devienne un risque de rupture d’approvisionnement.

• Documenter chaque décision de conformité dans un dossier structuré, consultable en cas de contrôle, plutôt que de la disperser entre plusieurs équipes et plusieurs outils.

Recommandations

1. Ne jamais confondre conformité réglementaire et sécurité réelle du produit : ce sont deux mesures différentes, qui méritent un suivi séparé.

2. Toujours préparer le processus de signalement avant la première vulnérabilité activement exploitée, jamais après.

3. Traiter la dépendance aux petits fournisseurs comme un risque de conformité à part entière, pas seulement comme un risque produit.

Conclusion

Le CRA changera probablement la structure du marché des objets connectés vendus en Europe, en professionnalisant les acteurs qui y restent. Qu’il rende ces objets réellement plus sûrs sur les étagères est une question distincte, qui ne se répondra pas avant plusieurs années de recul - et qui mérite d’être posée maintenant, avant que la première question ne masque la seconde.

Dossier de sécurité Produit offert

Vous n'avez pas encore documenté votre conformité CRA ? Construisez la gratuitement depuis votre dossier de sécurité structuré : cartographie des produits et éléments numériques concernés.

Contexte

Après le Kit RSSI, nous ouvrons en bêta le Dossier de Sécurité Cyberlead.

Cet outil n’est pas un prototype : nous l’utilisons depuis plusieurs années pour piloter nos missions. Déjà déployé sur 382 dossiers auprès d’organisations de secteurs et de maturités variés, il a évolué grâce aux retours de nombreux utilisateurs, dont plusieurs grands groupes français.

Son objectif est simple : permettre à chaque organisation de centraliser gratuitement le pilotage de sa cybersécurité dans un dossier vivant, mis à jour en continu.

Le Dossier de Sécurité permet notamment de :

• Cartographier le système d’information et les risques ;

• Piloter les chantiers cyber via une roadmap opérationnelle ;

• Suivre les vulnérabilités, incidents, PCA/PRA et exigences applicables ;

• Disposer à tout moment d’une vision claire de l’état de la cybersécurité.

Parce que la cybersécurité ne devrait pas être reconstruite à l’approche d’un audit, mais pilotée au quotidien.

En pratique

Le Dossier de Sécurité repose sur quatre principes fondamentaux.

1. Un état réel plutôt qu’une photographie figée

La cartographie du système d’information et l’analyse des risques sont mises à jour en continu. Elles reflètent l’évolution réelle de l’organisation, et non une situation reconstituée ponctuellement pour répondre à une échéance.

2. Une feuille de route réellement pilotable

Les chantiers de cybersécurité sont priorisés, planifiés et suivis dans le temps. L’objectif est de transformer les intentions en actions concrètes inscrites dans un calendrier réaliste.

3. Un dossier adapté à chaque contexte

Parce qu’une usine, un établissement de santé, une entreprise de services ou un produit numérique ne partagent pas les mêmes enjeux, le Dossier de Sécurité se décline en quatre versions :

• Entreprise

• Usine

• Santé

• Produit

Plutôt qu’un modèle unique appliqué à tous les contextes, chaque déclinaison est conçue pour répondre aux spécificités de son environnement.

4. Une vision complète de la cybersécurité

Le Dossier de Sécurité couvre, entité par entité :

• Les informations générales et le statut du dossier

• Les prestations et accompagnements en cours

• Les entités et Business Units du périmètre

• Le système d’information et sa cartographie technique

• Les projets numériques en cours

• Les exigences de cybersécurité applicables

• Les risques identifiés et leur priorisation

• Les dispositifs PCA / PRA

• Le suivi des vulnérabilités

• Les incidents et leur main courante

• La feuille de route et le suivi des actions

Conclusion

Un dossier de sécurité qui ne vit qu’au moment d’un audit protège rarement l’organisation entre deux échéances.

Nous avons conçu cet outil pour répondre à cette problématique dans nos propres missions. Aujourd’hui, avec 382 dossiers déjà déployés en bêta et les retours d’expérience de plusieurs grands groupes français, nous avons fait le choix de le mettre à disposition du plus grand nombre.

L’objectif est simple : aider les organisations à passer d’une cybersécurité documentaire et ponctuelle à une cybersécurité pilotée, vivante et durable.

Un équipementier de taille intermédiaire, une gamme de passerelles industrielles vendue dans toute l’Europe. Le dossier CRA est prêt : analyse d’écart, nomenclature logicielle, politique de divulgation coordonnée. Tout est écrit, relu, validé.

Rien n’a jamais été branché. Le produit arrive sur le banc un lundi matin. À midi, nous avons trois écarts entre ce que le dossier annonce et ce que la carte contient.

Le problème

Le premier écart est structurel. Le dossier décrit le produit conçu, le banc montre celui qui a été fabriqué. Port de debug ouvert, bibliothèque plus ancienne que la nomenclature : les deux peuvent diverger, parfois suffisamment pour remettre en cause les hypothèses du dossier.

Le deuxième tient à la méthode. La R&D teste la fonction : elle vérifie que le produit marche. Un banc teste l’abus : ce qui arrive quand on s’en sert autrement. Ce n’est pas le même travail.

Le troisième est commercial. Une déclaration affirme la conformité. Un rapport de test documente les vérifications qui permettent de la défendre. Le jour où un donneur d’ordre demande la preuve, l’écart se paie en semaines de retard sur une commande.

La décision clé

Passer le produit sur un banc avant de signer la déclaration de conformité, et non après la première question d’un client.

En pratique

1. Tester le produit avec son écosystème

Un équipement seul ne se teste pas utilement. Il faut le banc complet : l’application de configuration, le portail cloud s’il existe, le canal de mise à jour, les identifiants d’usine. C’est là que se trouvent la plupart des écarts, parce que ces composants sont développés par des équipes différentes, parfois par un prestataire, et rarement audités ensemble.

2. Reproduire l’usage réel, pas les conditions de laboratoire

Un produit installé chez un client est mal configuré, jamais mis à jour, branché sur un réseau à plat et administré par un technicien pressé. Le banc doit refléter cet état, pas la configuration nominale du manuel. Les vulnérabilités qui comptent sont celles qui restent exploitables dans la configuration que vos clients utilisent vraiment.

3. Attaquer toutes les interfaces, y compris celles qu’on a oubliées

Le réseau et le web sont les plus regardés parce qu’ils sont les plus accessibles. Les interfaces série, USB, JTAG et radio le sont beaucoup moins, et ce sont elles qui donnent l’accès au firmware. Un attaquant qui achète votre produit d’occasion ne se limite pas au port Ethernet.

4. Vérifier la chaîne de mise à jour de bout en bout

C’est l’un des points structurants du CRA, et c’est le point le plus souvent négligé. Signature vérifiée sur l’équipement, canal protégé, protection contre le retour vers une version connue comme vulnérable lorsque le niveau de risque le justifie, comportement en cas d’échec. Un produit qu’on ne peut pas corriger sur le terrain n’est pas supportable dix ans.

5. Produire un rapport qui serve à deux publics

La R&D a besoin de reproductibilité : configuration exacte, étapes, correctif proposé. La direction et les clients ont besoin d’une preuve datée, traçable et exploitable en audit ou en appel d’offres. Un seul document ne sert bien qu’un des deux. Le rapport se rédige en deux parties dès le départ — c’est ce qui évite de le réécrire au moment de l’appel d’offres.

Recommandations

Passer sur le banc avant le gel du design. Un écart trouvé en conception coûte une décision. Le même écart trouvé après la mise en série coûte un rappel, ou un contournement documenté qu’on traînera dix ans.

Ne pas confondre banc produit et test d’intrusion applicatif. Les compétences, l’outillage et les livrables diffèrent. Un pentest sur votre portail client ne dit rien de la sécurité de l’équipement lui-même.

Faire du rapport un argument de vente. Vos clients industriels vont l’exiger. Ceux qui peuvent le produire en trois jours gagnent les appels d’offres que les autres passent trois mois à instruire.

Conclusion

Un dossier de conformité se construit à partir de faits mesurés ou à partir de déclarations. Les deux se ressemblent sur le papier, jusqu’au premier audit. La différence tient à une semaine de banc, en amont, à un moment où corriger coûte encore peu.

Vous voulez voir ce que donne votre produit sur un banc ?

Nous testons gratuitement un produit de votre gamme sur notre banc d’essai cybersécurité et vous remettons le rapport complet. Sans engagement.

Réserver mon test gratuit

Contexte

• Le 11 septembre 2026 ne demande pas un programme CRA complet, seulement une capacité de détection et de notification opérationnelle.

• J0-30 : cartographier les produits concernés et désigner un responsable du sujet.

• J30-60 : outiller le process de notification 24h/72h/14j et se préparer à la plateforme ENISA.

• J60-90 : tester le process à blanc avant l’échéance, plutôt que de découvrir ses failles en conditions réelles.

Il reste quelques semaines avant le 11 septembre 2026. Pas de quoi bâtir un programme de conformité CRA complet mais largement de quoi sécuriser ce qui compte vraiment à cette date : la capacité à détecter et signaler une vulnérabilité active dans les délais imposés par l’article 14.

J0 à J30 : cartographier

Le premier sprint ne touche à aucun outil, seulement à une liste. Il s’agit de recenser tous les produits de l’entreprise qui entrent dans la définition de “produit comportant des éléments numériques” : matériel ou logiciel se connectant, directement ou indirectement, à un appareil ou un réseau y compris ceux déjà commercialisés. En parallèle, un responsable unique du sujet doit être désigné : sans porteur identifié, l’inventaire s’arrête souvent à la première difficulté.

J30 à J60 : outiller

Une fois le périmètre connu, le sprint suivant construit le squelette opérationnel du signalement : qui reçoit l’alerte de vulnérabilité, qui rédige la notification initiale sous 24h, qui complète le rapport à 72h, qui suit la mise à jour finale à 14 jours. C’est aussi la fenêtre pour se familiariser avec la plateforme unique de signalement de l’ENISA (Single Reporting Platform), dont la période de test précède l’entrée en application du 11 septembre.

J60 à J90 : exercer

Le dernier sprint est celui qu’on saute le plus souvent, faute de temps et c’est pourtant le plus utile. Un test à blanc, sur un scénario fictif de vulnérabilité exploitée, révèle en une matinée ce qu’aucune documentation ne montre : qui est réellement joignable un week-end, où se situe le goulot d’étranglement dans la chaîne de validation, si le délai de 24h est tenable en pratique. Mieux vaut découvrir ces failles sur un exercice que le jour où la notification est vraiment due.

Ce qu’il faut retenir

Ce plan ne couvre pas l’ensemble du Cyber Resilience Act. Le marquage CE et les exigences essentielles ont leur propre calendrier, jusqu’à fin 2027. Il couvre ce qui a une échéance ferme dans les prochaines semaines : une capacité de détection et de notification qui fonctionne, éprouvée avant d’en avoir besoin.

Insight CyberLead

La tentation, face à un texte aussi dense que le CRA, est de vouloir tout traiter d’un coup : cartographie complète, SBOM exhaustif, documentation technique. Sur 90 jours, ce n’est pas réaliste, et ce n’est pas ce que demande l’échéance du 11 septembre. Ce qu’elle demande, c’est une chose précise : être capable de détecter une vulnérabilité activement exploitée sur l’un de vos produits et de la signaler dans les délais. Le reste du programme CRA : marquage CE, exigences essentielles, évaluation de conformité a jusqu’à décembre 2027. Prioriser l’un ne dispense pas de préparer l’autre, mais confondre les deux calendriers fait perdre un temps qu’on n’a plus.

Où en est votre organisation sur ces 90 jours : cartographie faite, process outillé, ou pas encore commencé ? CyberLead peut vous aider à structurer et réaliser ce sprint.

Contacter un expert Cyberlead

Vous voyez un post LinkedIn sur le sujet , n’hésitez pas et partagez cet article en commentaire !

Partager

Contexte

• L’enquête ENISA PME 2026 (194 organisations, 31 pays) confirme un fort écart entre connaissance du CRA et capacité réelle à s’y conformer.

• 54% des répondants comprennent peu ou pas le processus d’évaluation de conformité.

• 42% sont déjà en difficulté sur la documentation technique exigée.

• La plateforme unique de signalement de l’ENISA, encore en cours de construction, ajoute une inconnue technique au calendrier légal.

Le CRA est connu. C’est presque devenu un lieu commun dans les comités de direction industriels. Ce qui l’est beaucoup moins, c’est la capacité réelle des organisations à transformer cette connaissance en conformité opérationnelle avant le 11 septembre 2026 et c’est précisément ce qu’a mesuré l’ENISA au printemps.

Une enquête, deux chiffres qui comptent

Entre février et mars 2026, l’ENISA a interrogé 194 organisations dans 31 pays, dont 25 États membres de l’UE, pour son enquête dédiée aux PME face au Cyber Resilience Act. Résultat : 54% des répondants déclarent comprendre peu ou pas le processus d’évaluation de conformité, et 42% se disent déjà en difficulté sur la documentation technique attendue. Le constat de l’agence est sans détour : la plupart des PME savent que le règlement arrive, peu sont prêtes à y répondre.

Le problème du parc déjà installé

Ce qui complique la donne pour le 11 septembre, c’est que l’obligation de signalement de l’article 14 ne concerne pas seulement les futurs produits : elle s’applique aussi à ceux déjà commercialisés. Concrètement, cela inclut des composants logiciels en fin de support, parfois maintenus par des tiers qui ont eux-mêmes arrêté leur suivi de sécurité. Surveiller une dépendance qu’on ne maintient plus soi-même, pour pouvoir signaler une vulnérabilité qui y serait activement exploitée, est un exercice que peu d’organisations ont déjà organisé.

La plateforme elle-même n’est pas encore stabilisée

Autre élément à intégrer dans le calendrier : la plateforme unique de signalement de l’ENISA (Single Reporting Platform), prévue par l’article 16, est toujours en construction. L’agence a lancé un appel d’offres et retenu un prestataire pour son développement, avec une période de test annoncée avant le 11 septembre. Autrement dit, même une organisation totalement prête côté process devra composer avec un outil réglementaire encore en rodage côté régulateur.

Ce qu’il faut retenir

L’écart révélé par l’enquête ENISA n’est pas anecdotique, il est structurel : la majorité des PME concernées n’ont pas encore la maturité méthodologique pour documenter leur conformité, et le calendrier légal ne s’ajustera pas à ce retard. Les organisations les plus exposées sont souvent les plus petites, celles qui n’ont ni équipe conformité dédiée ni service juridique en interne pour décrypter le texte.

Insight CyberLead

Sur les cadrages CRA que nous avons menés ce printemps, le blocage le plus fréquent précède même les chiffres de l’enquête ENISA : la plupart des équipes produit n’ont jamais dressé la liste précise de leurs propres produits entrant dans la définition de “produit comportant des éléments numériques”. Tant que cet inventaire n’existe pas, la question de la documentation ou de l’évaluation de conformité ne se pose pas encore. On est en amont du problème que révèle l’enquête. Le vrai chantier de rentrée n’est donc pas juridique, il est factuel : savoir précisément quoi est dans le périmètre avant de discuter de comment s’y conformer.

Ressources CyberLead

Le Dossier de Sécurité CyberLead regroupe vos risques, exigences, cartographies, incidents et plans d’action dans une vision claire, à jour et partageable. Accédez-y gratuitement, commencez en autonomie, puis faites-le évoluer avec un expert Cyberlead.

Accédez à votre dossier de sécurité

Vous voyez un post LinkedIn sur le sujet, n’hésitez pas à partager cet article en commentaire !

Partager

Un métier qui va devoir apprendre à aller plus vite

D’expérience, l’été est le moment où les RSSI et responsables cybersécurité lèvent un peu la tête du guidon. C’est aussi le bon moment pour regarder où va le métier, avant la rentrée. Et ce qu’on observe depuis quelques mois sur nos missions, chez des clients de tailles très différentes, c’est une accélération nette : l’IA générative change la vitesse à laquelle les attaquants opèrent, et donc la vitesse à laquelle la fonction cybersécurité doit répondre. Tout le monde, du RSSI industriel au DSI généraliste, se prépare consciemment ou non à devoir gérer plus vite, avec les mêmes équipes.

Ce n’est pas un scénario de science-fiction : c’est déjà visible dans la manière dont les consultations et les appels d’offres sont rédigés, et dans les outils que les praticiens se bricolent eux-mêmes faute d’attendre le bon budget. Voici 5 devoirs de vacances pour préparer la rentrée sur ces sujets.

1. Mieux gérer la cartographie

Partout où nous intervenons, le même mouvement se répète : les RSSI reprennent la cartographie en direct, au lieu de la sous-traiter entièrement ou de la laisser vieillir dans un tableur oublié. Sans inventaire à jour des systèmes, des applications et des flux, aucune priorisation de la remédiation n’est crédible, et l’IA ne peut rien automatiser sur une base de données fausse.

Ce retour en direct se retranscrit très concrètement dans les consultations que nous recevons : de plus en plus d’appels d’offres demandent explicitement un outil ou une méthode de cartographie vivante, pas un audit ponctuel figé à la date de restitution. Le devoir de vacances est simple : reprendre la main sur cette base avant que quelqu’un d’autre, ou un attaquant, ne la reconstitue à votre place.

2. Préparer l’industrialisation de la qualification des vulnérabilités

Pour ceux qui seraient passés à côté : la CISA, l’agence américaine de cybersécurité, a publié le 10 juin 2026 la Binding Operational Directive 26-04, consacrée à la priorisation des mises à jour de sécurité selon le risque. Elle impose aux agences fédérales américaines de remédier leurs vulnérabilités dans des délais allant de 3 à 60 jours, calculés non plus sur le seul score CVSS mais sur quatre facteurs croisés : l’exposition réelle de l’actif, sa présence dans le catalogue KEV (Known Exploited Vulnerabilities), la disponibilité d’un exploit automatisable, et l’impact technique potentiel.

L’enjeu de fond dépasse le périmètre fédéral américain : c’est la généralisation d’une logique où le KEV, la liste des vulnérabilités dont l’exploitation active est confirmée, devient la boussole de priorisation, devant le score de sévérité brut. La directive impose aussi un inventaire continu des actifs exposés en externe, remis à jour trimestriellement. Pour nos clients, la qualification manuelle des vulnérabilités, CVE par CVE, ne tiendra bientôt plus le rythme. Le devoir de vacances est de commencer à outiller cette qualification, flux KEV, scoring d’exposition, automatisation du triage, avant que le volume ne devienne ingérable.

3. Monter en compétence sur le PCRA

Autre mouvement observé partout : les RSSI reprennent progressivement la main sur le Plan de Continuité et de Reprise d’Activité. Longtemps porté par les équipes IT ou par des cabinets généralistes de gestion de crise, le PCRA redevient un sujet cybersécurité à part entière, parce que le scénario de sinistre le plus probable aujourd’hui reste l’attaque par rançongiciel. Le devoir de vacances : ne plus se contenter de relire le PCRA une fois par an, mais en comprendre chaque brique assez finement pour le challenger et le tester soi-même.

4. Développer, ou vibecoder, ses outils internes

De plus en plus d’experts cybersécurité développent leurs propres outils pour des usages internes, chez les petites structures comme chez les grands groupes. Avec les assistants de code IA, un script de triage, un tableau de bord ou un connecteur maison qui prenait deux semaines se code en une journée. On pense sincèrement que ça va devenir un indispensable du métier, au moins sur toute la partie non critique : rien ne remplace un outil pensé pour son propre contexte, sans attendre un éditeur ou un budget d’intégration.

5. Digitaliser le pilotage de la cybersécurité

Avec l’accélération que permet l’IA sur l’attaque comme sur la défense, il faudra encore davantage prouver aux directions ce qui est réellement fait, et pas seulement ce qui est prévu. Un plan d’action mis à jour une fois par trimestre ne suffira plus à rassurer un comité de direction qui lit les mêmes actualités que vous. Le pilotage doit devenir vivant, traçable, et consultable à tout moment.

Vous pouvez prendre exemple sur le dossier de sécurité que nous mettons à disposition pour nos clients finaux, qui centralise en continu l’état réel de la sécurité et des actions en cours.

Ce qu’il faut retenir

Ces 5 devoirs n’ont rien d’exotique pris séparément. Ce qui change, c’est le rythme : la cartographie, la qualification des vulnérabilités, le PCRA, l’outillage interne et le pilotage devront tous absorber une vitesse d’exécution que l’IA impose des deux côtés de la barrière. Le RSSI qui prend l’été pour remettre ces cinq briques d’aplomb partira avec une longueur d’avance à la rentrée.

Ressources CyberLead

Le Dossier de Sécurité CyberLead regroupe vos risques, exigences, cartographies, incidents et plans d'action dans une vision claire, à jour et partageable. Accédez-y gratuitement, commencez en autonomie, puis faites-le évoluer avec un expert.

Accédez à votre dossier de sécurité

Vous voyez un post LinkedIn sur le sujet, n’hésitez pas à partager cet article en commentaire !

Partager

L’année 2025 et le début de l’année 2026 ont amené, pour nombre d’entre nous, une refonte de la manière de travailler sur la cybersécurité. L’usage de l’IA, déjà présent dans les SOC, a été étendu à la gouvernance grâce aux outils d’IA générative de type ChatGPT, Gemini et d’autres.

En parallèle, de nombreux prestataires de cybersécurité se sont mis à coder des outils pour leurs besoins vis-à-vis de leurs clients, et utilisent désormais des plateformes pour améliorer la cybersécurité livrée à leurs clients.

Dans ce contexte, CyberLead a suivi le mouvement et a fait évoluer sa plateforme interne de suivi des prestations vers une plateforme plus globale en y ajoutant en particulier :

• les dossiers de sécurité produit (DSP)

• les dossiers de sécurité usine (DSU)

• les dossiers de sécurité entreprise (DSE)

• les dossiers de sécurité Hôpitaux (DSH)

Nous avons aussi décidé d’arrêter la production de notre Kit RSSI, dont la majorité des documents de conformité est désormais construite via ces plateformes.

Nous vous proposons ainsi de pouvoir découvrir notre plateforme CyberLead et notre vision du dossier de sécurité, à destination des acteurs basés en France et, plus largement, en Europe.

Le Dossier de Sécurité CyberLead regroupe vos risques, exigences, cartographies, incidents et plans d’action dans une vision claire, à jour et partageable. Accédez-y gratuitement, commencez en autonomie, puis faites-le évoluer avec un expert.

Accédez à votre dossier de sécurité

Ce qu'on pensait être un problème militaire est devenu un risque industriel

Pendant longtemps, le GPS spoofing était perçu comme une menace géopolitique et militaire : des États qui manipulent les signaux GPS pour désorienner des drones adverses ou masquer des mouvements de navires militaires. Cette perception a radicalement changé. En 2025, le transport est devenu le troisième secteur le plus ciblé en Europe selon l'ENISA, avec une hausse de 103% des incidents cyber maritimes. Les incidents de GPS spoofing ne se comptent plus en dizaines mais en milliers par mois dans certaines zones géographiques.

Pour la logistique industrielle, les cas concrets se multiplient. Des tankers pétroliers ont vu leurs systèmes de navigation afficher des positions erronées, les plaçant fictivement dans les eaux territoriales d'un pays tiers pour créer un prétexte d'interception. Des opérateurs de flotte terrestre en Europe de l'Est ont constaté que leurs véhicules affichaient des trajectoires impossibles dans leurs outils de suivi. Et des incidents ont montré que des cargaisons ont été acheminées vers de mauvaises destinations suite à des erreurs de navigation induites par des signaux GPS falsifiés.

Comment fonctionne le GPS spoofing et pourquoi c'est si simple

Le GPS est un système de positionnement qui repose sur la réception de signaux radio émis par des satellites. Le problème fondamental : ces signaux ne sont pas authentifiés. N'importe qui disposant d'un émetteur radio de quelques centaines d'euros peut émettre de faux signaux GPS qui vont se substituer aux signaux satellites dans le récepteur cible. Le récepteur qu'il soit dans un smartphone, un camion, un drone ou un système de navigation industrielle ne peut pas distinguer le vrai signal du faux.

C'est cette simplicité technique qui rend le GPS spoofing si préoccupant dans un contexte de logistique industrielle. Il ne requiert pas des compétences avancées, pas de failles logicielles à exploiter, pas d'accès physique aux équipements cibles. Un attaquant positionné à quelques kilomètres d'un hub logistique peut manipuler les positions GPS de dizaines de véhicules simultanément.

4 impacts concrets sur la logistique industrielle

1. Vol de cargaisons de valeur

L'impact le plus direct et le plus documenté : détourner des véhicules transportant des cargaisons à haute valeur produits pharmaceutiques, composants électroniques, matières premières stratégiques vers des points de livraison contrôlés par des acteurs malveillants. Le véhicule croit suivre sa route normale, l'opérateur de flotte voit une position GPS normale, et la cargaison disparaît. Ce type d'attaque a été documenté dans plusieurs pays d'Europe centrale et orientale ces deux dernières années.

2. Invalidation des outils de gestion de flotte

Les plateformes de gestion de flotte s'appuient massivement sur les données GPS pour optimiser les routes, surveiller les temps de conduite, calculer les délais de livraison et facturer les clients. Des données GPS corrompues polluent tous ces processus en cascade : des alertes de dépassement de zone se déclenchent pour des véhicules qui n'ont pas bougé, des estimations de livraison deviennent fausses, des calculs de temps de conduite sont erronés. Au-delà de la perturbation opérationnelle, des données GPS corrompues peuvent invalider des preuves de livraison en cas de litige commercial.

3. Perturbation de la synchronisation temporelle industrielle

C'est l'impact le moins visible mais potentiellement le plus critique dans certains environnements industriels. Le GPS est très fréquemment utilisé comme référence de temps dans les systèmes industriels pour synchroniser les automates, les systèmes SCADA, les journaux d'événements, les protocoles de communication. Un signal GPS falsifié qui modifie l'heure de référence peut désynchroniser des systèmes industriels interdépendants, générant des erreurs de séquençage dans les process automatisés et rendant les journaux d'audit inexploitables pour l'analyse post-incident.

4. Risques sur les véhicules et équipements autonomes

Les chariots élévateurs autonomes, les AGV (Automated Guided Vehicles) en entrepôt et les drones logistiques s'appuient sur le GPS comme l'une de leurs sources de positionnement. Une manipulation GPS dans ces environnements peut conduire à des comportements imprévisibles dans le meilleur cas une perte de positionnement avec arrêt de sécurité, dans le pire cas une collision ou une chute. Avec la montée en puissance de l'automatisation dans les entrepôts et les sites industriels, ce vecteur d'impact va prendre de l'importance dans les prochaines années.

4 mesures de mitigation pour les opérateurs logistiques industriels

1. Déployer des récepteurs multi-constellation

Les récepteurs GPS modernes peuvent recevoir les signaux de plusieurs constellations satellitaires en parallèle : GPS américain, Galileo européen, GLONASS russe, BeiDou chinois. Falsifier simultanément tous ces systèmes est techniquement beaucoup plus difficile et coûteux. Exiger des récepteurs multi-constellation dans les cahiers des charges des nouveaux équipements de navigation et de suivi de flotte est la mesure technique la plus efficace à court terme.

2. Croiser le GPS avec d'autres sources de positionnement

Un système de navigation qui fusionne les données GPS avec d'autres sources accéléromètres inertiels, odométrie, signaux cellulaires, balises UWB en entrepôt est beaucoup plus résistant à une attaque GPS. L'incohérence entre une position GPS modifiée et les autres sources déclenche une alerte. Cette approche de fusion de données est déjà standard dans les systèmes de navigation avancés ; l'enjeu est de s'assurer que les équipements déployés dans la chaîne logistique l'intègrent réellement.

3. Surveiller les anomalies GPS en temps réel

Des indicateurs simples permettent de détecter une attaque GPS en cours : variation soudaine et incohérente de position, dégradation brutale de la qualité du signal, incohérence entre la position GPS et la vitesse mesurée. Ces indicateurs peuvent être calculés en temps réel sur les plateformes de gestion de flotte et déclencher des alertes automatiques. Des solutions spécialisées de détection d'anomalies GPS commencent à émerger sur le marché pour les opérateurs logistiques.

4. Réviser les procédures de livraison pour ne pas reposer uniquement sur le GPS

La confirmation de livraison, la validation de position d'un véhicule et la preuve de passage en zone réglementée ne peuvent pas reposer exclusivement sur les données GPS. Des mécanismes complémentaires QR codes scannés à des points de passage, confirmation téléphonique avec les destinataires, horodatage basé sur des références indépendantes du GPS doivent être intégrés dans les procédures opérationnelles pour les cargaisons à valeur ou dans les zones à risque.

Ce qu'il faut retenir

Le GPS spoofing dans la logistique industrielle n'est plus un risque théorique réservé aux armées et aux services de renseignement. C'est un risque opérationnel réel, accessible à des acteurs malveillants sans compétences techniques avancées, avec des impacts directs sur la sécurité des cargaisons, l'intégrité des systèmes industriels et la fiabilité des processus logistiques. Le RSSI qui gère des flux logistiques industriels doit l'intégrer dans son modèle de menace et pousser ses opérations à adopter les mesures de mitigation disponibles.

Ressources CyberLead

Le Dossier de Sécurité CyberLead regroupe vos risques, exigences, cartographies, incidents et plans d’action dans une vision claire, à jour et partageable. Accédez-y gratuitement, commencez en autonomie, puis faites-le évoluer avec un expert.

Accédez à votre dossier de sécurité

Vous voyez un post LinkedIn sur le sujet , n’hésitez pas et partagez cet article en commentaire !

Partager

Je vais vous poser la question frontalement : est-ce que vous avez encore besoin de payer 15 000 à 50 000 euros un prestataire de pentest manuel, alors qu'une plateforme comme Pentera, Escape ou XBOW tourne en continu sur votre périmètre pour une fraction du prix ? La réponse honnête : ça dépend de ce que vous attendez du pentest. Et c'est là que ça devient intéressant.

Le marché du pentest automatisé a explosé

En 2026, les plateformes de pentest continu ont littéralement pris d'assaut le marché. Pentera teste les réseaux d'entreprise en simulant des attaques automatisées. Escape couvre les API et la logique métier. XBOW simule des adversaires avec de l'IA agentique. Hadrian tourne en continu sur vos surfaces exposées. La promesse est simple : ce qui se faisait une fois par an, avec un rapport livré deux semaines après, se fait maintenant en continu, dès qu'une modification de code est poussée en production.

D'expérience, ce n'est pas la même chose qu'un pentest humain mais c'est redoutablement efficace pour couvrir les vulnérabilités connues, les mauvaises configurations et les surfaces exposées. Les analystes estiment que d'ici 2027, 99% des évaluations de vulnérabilités seront conduites par des agents autonomes. Le pentest manuel deviendra un service de niche pour des problèmes très spécifiques. Ce n'est pas de la prospective : c'est déjà en cours.

Pendant ce temps, les attaquants s'équipent aussi

Le problème, c'est que les acteurs malveillants n'ont pas attendu. Selon le Global Threat Report 2026 de CrowdStrike, le temps moyen d'intrusion d'un groupe eCrime est passé à 29 minutes. Le cas le plus rapide observé : 27 secondes. En 2024, il fallait encore 285 minutes pour exfiltrer des données. En 2025, 72 minutes suffisaient. L'activité des adversaires assistés par IA a augmenté de 89% en un an.

Les attaquants utilisent l'IA pour cartographier les cibles en quelques minutes, identifier les vecteurs d'attaque, générer du phishing hyper-personnalisé et modifier dynamiquement leur code pour contourner les EDR. Le rapport de l'ANSSI sur les menaces liées à l'IA générative confirme la tendance : en 2025, l'IA a principalement été utilisée pour améliorer la vitesse et la qualité des attaques existantes pas encore pour en inventer de nouvelles, mais c'est une question de temps.

Ce que ça signifie concrètement : un scan automatisé de votre périmètre, aussi bon soit-il, ne pense pas comme un attaquant motivé avec un objectif précis. Il couvre les failles connues. Pas les failles logiques, les erreurs de design d'un processus métier, les combinaisons improbables que seul un humain créatif va chercher.

Ce qui meurt : le pentest boîte noire annuel

Soyons directs sur ce qui disparaît : le modèle traditionnel où une société de pentest débarque une semaine, scanne tout, livre un rapport de 200 pages avec des CVE classées par criticité, et revient dans 12 mois. Ce modèle est économiquement condamné. Les RSSI le savent. Les DSI qui négocient les budgets le savent aussi. Pourquoi payer 30 000€ un exercice annuel quand une plateforme à 2 000€/mois teste en continu, en temps réel, et alerte dès qu'une nouvelle surface est exposée ?

La réponse rationnelle pour une organisation mature : vous gardez la plateforme pour la couverture continue, et vous faites appel à un pentester humain pour les missions à haute valeur ajoutée. Red team ciblé sur un scénario réel. Test d'un nouveau système critique avant mise en production. Simulation d'un attaquant avec les TTP d'un groupe APT spécifique à votre secteur. Ce sont des missions que l'automatisation ne remplace pas mais elles représentent peut-être 10% du volume total du marché du pentest actuel.

Ce qui reste : le pentester qui pense comme un adversaire

Le pentester humain qui survivra à cette transformation, c'est celui qui pense comme un attaquant avec un objectif métier réel : accéder aux données RH, atteindre le système de paye, provoquer un arrêt de chaîne de production, exfiltrer la propriété intellectuelle. Pas celui qui cherche des CVE, les outils font ça mieux et plus vite que lui.

En pratique, ce sont des profils qui combinent plusieurs capacités que l'IA ne réplique pas facilement : la compréhension du contexte métier de l'entreprise cible, la créativité dans le chaining d'exploits, la capacité à identifier ce qu'un attaquant réel chercherait précisément dans cette organisation. Un profil qui travaille sur la logique applicative d'un ERP industriel n'est pas remplaçable par Pentera. Un profil qui scanne des IP et documente des CVSS, si.

Le modèle émergent : l'opération de pentest augmentée par l'IA

Ce que je vois se développer chez les prestataires les plus avancés, c'est un modèle hybride : une équipe réduite de pentesters seniors, augmentés par des outils d'IA et des plateformes automatisées, capables de couvrir un périmètre beaucoup plus large avec moins de ressources humaines. Une seule personne avec les bons outils fait aujourd'hui le travail de 3 profils intermédiaires d'il y a 5 ans.

C'est une réduction de coûts structurelle pour les prestataires. Et une pression réelle sur les juniors et les profils généralistes. Ce modèle favorise les pentesters seniors avec une vraie expertise verticale : OT industriel, Cloud souverain, applicatif bancaire, chaîne logistique et défavorise ceux qui ne se sont pas spécialisés. Je crois personnellement que dans 3 ans, le marché du pentest ressemblera à celui du droit : des cabinets généralistes qui disparaissent au profit de boutiques expertes sur des verticales précises.

Ce que ça change pour vous en tant que RSSI

Deux questions à vous poser dans les 12 prochains mois si vous n'avez pas encore revu votre stratégie de test :

1. Votre contrat de pentest annuel est-il encore justifié ?

Comparez honnêtement la valeur apportée par rapport à ce qu'une plateforme continue couvrirait. Dans la plupart des cas, la réponse est non, sauf pour des missions très ciblées. Un RSSI qui continue à dépenser 40 000€ par an en pentest annuel sans avoir de couverture continue a clairement un angle mort dans sa stratégie.

2. Votre prestataire de pentest utilise-t-il l'IA ?

Posez la question directement lors de votre prochain appel d'offres. Est-ce qu'il utilise des outils d'IA et des plateformes automatisées pour augmenter sa productivité ou continue-t-il à travailler comme en 2018 ? La réponse vous dira si vous payez pour l'expertise humaine réelle, ou pour des heures de scan que vous pourriez faire vous-même pour moins cher.

Le métier de pentester n'est pas mort. Mais le pentester qui se contente de faire ce qu'une machine fait mieux que lui, oui. Et selon moi, le vrai risque pour les organisations en 2026, c'est de confondre les deux et de croire que parce qu'elles ont un contrat de pentest, elles sont testées comme un adversaire réel les testerait.

Vous avez un projet de red team, d'évaluation de votre couverture de test ou de réflexion sur votre stratégie de pentest ? Prenez rendez-vous, échangeons sur ce qui a réellement du sens pour votre contexte et votre niveau de maturité.

Ressources CyberLead

Le Dossier de Sécurité CyberLead regroupe vos risques, exigences, cartographies, incidents et plans d’action dans une vision claire, à jour et partageable. Accédez-y gratuitement, commencez en autonomie, puis faites-le évoluer avec un expert.

Accédez à votre dossier de sécurité

Vous voyez un post LinkedIn sur le sujet , n’hésitez pas et partagez cet article en commentaire !

Partager

Le scénario qui se répète

Depuis quelques mois, c’est devenu systématique. À chaque comité de pilotage avec un fournisseur d’équipements industriels, le même sujet revient sur la table : « On aimerait récupérer les données de vos machines pour alimenter nos modèles d’IA. » L’argument est toujours le même : maintenance prédictive, optimisation des performances, réduction des arrêts non planifiés. Sur le papier, c’est séduisant. En pratique, c’est le début d’un casse-tête cybersécurité.

D’expérience, le scénario est presque toujours identique. Le fournisseur propose d’installer un boîtier ou un agent logiciel sur le réseau de production. Ce boîtier remonte des données vers une plateforme cloud, souvent hébergée on ne sait pas trop où, pour alimenter un algorithme de machine learning. Le tout est présenté comme anodin et transparent. Sauf que quand on gratte un peu, on découvre que pour faire fonctionner le système, il faut ouvrir des flux réseau depuis l’extérieur vers l’intérieur du réseau industriel. Et ça, d’un point de vue cybersécurité, c’est une aberration.

Le vrai problème : des flux descendants déguisés en remontée de données

La promesse initiale, c’est de la remontée de données. Du flux sortant. Les machines envoient leurs données de fonctionnement vers le cloud du fournisseur. Jusque-là, on peut encadrer. Mais dans la réalité, les architectures proposées par les fournisseurs nécessitent presque systématiquement des flux descendants : mises à jour des modèles IA, envoi de commandes de reconfiguration, accès distant pour la maintenance de la solution. On se retrouve avec un flux bidirectionnel, parfois même un accès VPN permanent du fournisseur vers le réseau OT.

C’est exactement le type de situation que la CISA et ses partenaires internationaux ont identifié dans leur guide publié en 2025 sur l’intégration sécurisée de l’IA dans les environnements OT. Le document, cosigné par l’ANSSI, le BSI allemand et le NCSC britannique, insiste sur un point fondamental : les opérateurs d’infrastructures critiques doivent exiger transparence et contrôle de la part de leurs fournisseurs sur la façon dont l’IA est intégrée dans leurs produits.

Le contexte ne fait que renforcer cette urgence. En 2025, les environnements industriels européens ont connu une hausse de 43 % des événements de sécurité. Les attaques récentes ont mis en lumière les risques liés à l’interconnexion croissante entre IT et OT, et surtout la dépendance aux prestataires externes dont les accès ne sont pas toujours suffisamment sécurisés. La directive NIS2 place désormais explicitement les fournisseurs dans le périmètre de responsabilité des entités essentielles.

5 réflexes du RSSI face à une demande de connexion IA fournisseur

Le sujet n’est pas d’interdire l’IA en usine. L’intelligence artificielle apporte une vraie valeur ajoutée dans la maintenance prédictive, l’optimisation énergétique ou le contrôle qualité. Le sujet, c’est d’encadrer la façon dont on connecte ces solutions, et de ne pas accepter n’importe quelle architecture sous prétexte que le fournisseur assure que c’est sécurisé. Voici les cinq réflexes que nous avons mis en place.

1. Rassurer et valider la faisabilité en amont

Premier réflexe, et c’est essentiel pour ne pas être perçu comme le service qui bloque tout : rassurer les équipes métier et le fournisseur sur le fait que c’est faisable. Oui, on peut remonter des données industrielles vers une plateforme IA. Oui, la cybersécurité n’est pas là pour empêcher l’innovation. Mais on pose un cadre. On explique qu’il y a des conditions techniques et contractuelles à respecter, que c’est normal, et que ça fait partie de l’intégration. D’expérience, cette posture d’accompagnement change complètement la dynamique. Le RSSI qui commence par « c’est possible, voici comment on s’y prend » obtient une bien meilleure collaboration que celui qui commence par « il faut qu’on vérifie si on a le droit ».

2. Vérifier que le flux est bien sortant, et uniquement sortant

C’est le point technique non négociable. Le flux de données doit être sortant : de l’usine vers le cloud du fournisseur. Pas l’inverse. Concrètement, on demande au fournisseur son architecture réseau détaillée et on vérifie qu’aucun flux descendant n’est nécessaire pour le fonctionnement nominal de la solution. Si le fournisseur a besoin d’un accès entrant pour mettre à jour ses modèles IA ou pour de la maintenance, on exige que ce soit via un mécanisme de pull initié depuis l’intérieur du réseau, jamais un push depuis l’extérieur. Le boîtier ou l’agent va chercher ses mises à jour sur un serveur intermédiaire en DMZ, pas l’inverse. Si le fournisseur ne peut pas fonctionner sans flux descendant direct, c’est un signal d’alerte majeur sur la maturité de son architecture.

3. Vérifier les contraintes légales et réglementaires

Avant toute remontée de données, il faut clarifier le cadre juridique. Quelles données exactement sont remontées ? Des données de fonctionnement machine, ou aussi des données qui pourraient être qualifiées de données personnelles (identifiants opérateurs, horaires de production) ? Où sont stockées ces données ? Dans quel pays ? Sous quelle juridiction ? Le RGPD s’applique-t-il ? Le DPO doit être impliqué dès cette étape. Pour les secteurs réglementés, vérifier la conformité avec NIS2, les exigences sectorielles et les éventuelles restrictions à l’export de données industrielles sensibles. Certaines données de production peuvent avoir une valeur stratégique et leur transfert vers un cloud étranger peut poser des questions de souveraineté industrielle.

4. Évaluer l’acceptabilité en termes de confidentialité

Au-delà du cadre légal, il y a la question de confidentialité métier. Les données de production remontées au fournisseur peuvent révéler des informations stratégiques : cadences de production, taux de rendement, formulations, paramètres de recettes. Si votre fournisseur d’équipements travaille aussi avec votre concurrent, est-ce que les données que vous lui transmettez ne vont pas, même agrégées et anonymisées, alimenter un modèle dont votre concurrent bénéficiera ? Ce n’est pas de la paranoïa, c’est de l’intelligence économique basique. On vérifie avec la direction industrielle et la direction générale que le périmètre de données remontées est acceptable du point de vue de la confidentialité business.

5. Profiter de l’occasion pour mettre à jour le contrat fournisseur

Dernière étape, et probablement la plus structurante sur le long terme. Chaque demande de connexion IA est une opportunité pour remettre à plat les clauses contractuelles relatives aux échanges de données. On formalise dans le contrat : le périmètre exact des données collectées, la finalité du traitement, la durée de conservation, les conditions de suppression, les engagements de localisation, les obligations de notification en cas d’incident, et l’interdiction explicite de réutiliser les données à d’autres fins que celles prévues. La CISA recommande spécifiquement de négocier des accords contractuels détaillant les fonctionnalités IA, de demander un SBOM pour les modèles IA, et d’imposer des politiques explicites d’utilisation des données. C’est l’occasion de professionnaliser la relation et de poser des bases saines pour les années à venir.

Ce qu’il faut retenir

L’IA en usine va devenir la norme, pas l’exception. Les fournisseurs d’équipements industriels intègrent tous des briques d’intelligence artificielle dans leurs offres. Le RSSI qui refuse systématiquement sera contourné. Celui qui accompagne en posant un cadre clair sera écouté et respecté.

Le point de vigilance essentiel reste la direction des flux. Accepter un flux sortant encadré, c’est du pragmatisme. Accepter un flux descendant vers le réseau OT pour faire plaisir à un fournisseur, c’est ouvrir une brèche. Et dans un contexte où les attaques sur les environnements industriels explosent, cette brèche peut coûter très cher.

Ressources CyberLead

Le Dossier de Sécurité CyberLead regroupe vos risques, exigences, cartographies, incidents et plans d’action dans une vision claire, à jour et partageable. Accédez-y gratuitement, commencez en autonomie, puis faites-le évoluer avec un expert.

Accédez à votre dossier de sécurité

Vous voyez un post LinkedIn sur le sujet , n’hésitez pas et partagez cet article en commentaire !

Partager

L'exercice qui ne sert à rien et comment l'éviter

D'expérience, un exercice de crise cyber OT qui ne mobilise que les équipes IT et sécurité apprend très peu de choses utiles. Il teste la réponse informatique à un incident informatique c'est bien, mais ce n'est pas suffisant dans un environnement industriel où la vraie question est : que se passe-t-il quand les automates s'arrêtent, quand la ligne est paralysée, quand les opérateurs ne peuvent plus accéder à la supervision ? Ces questions n'ont de réponses que si les équipes de production sont dans la salle.

Les exercices de crise cyber OT se développent en France depuis l'obligation NIS2 et les recommandations de l'ANSSI, notamment via le programme REMPAR qui simule des attaques sur des infrastructures industrielles critiques. Mais la majorité des entreprises industrielles n'ont pas encore organisé leur premier exercice OT et quand elles le font, elles reproduisent les erreurs classiques des exercices IT transposés sans adaptation.

5 pièges à éviter pour que l'exercice soit vraiment utile

1. Ne pas inviter les équipes de production

C'est l'erreur numéro un. Un exercice de crise cyber OT sans les responsables de production, les chefs de ligne et les opérateurs est un exercice incomplet. Ce sont eux qui prennent les décisions d'arrêt de production, qui gèrent les interfaces physiques des équipements, qui connaissent les procédures de repli manuelles. Sans eux, l'exercice ne teste pas les vraies décisions critiques, il teste seulement la réponse IT à un incident imaginaire dans une usine imaginaire.

2. Construire un scénario 100% informatique sans impact physique

Le propre d'un incident OT, c'est qu'il a des conséquences physiques : arrêt de ligne, perte de production, risque pour la sécurité des personnes dans certains secteurs. Un scénario d'exercice qui se limite à "les serveurs SCADA sont chiffrés" sans explorer les conséquences sur la production passe à côté de l'essentiel. Le scénario doit intégrer explicitement : qu'est-ce qui s'arrête ? Combien de temps ? Quelle est la procédure de repli manuel ? Qui décide de l'arrêt total versus partiel ?

3. Ne pas définir de "zones interdites" dans le scénario

Dans un exercice de crise cyber sur un site industriel, il faut définir explicitement ce qui ne sera pas simulé les actions qui, même en exercice, ne peuvent pas être jouées car elles entraîneraient un risque réel pour la production ou la sécurité. Ces "zones interdites" doivent être communiquées à tous les participants avant le début de l'exercice. Sans cette délimitation, des participants bien intentionnés peuvent prendre des initiatives qui perturbent réellement les opérations.

4. Oublier la communication de crise

Qui prévient les clients si la livraison va être retardée ? Qui communique avec les régulateurs si l'incident touche une infrastructure critique ? Qui gère la communication interne vers les équipes qui ne sont pas dans la cellule de crise ? Ces questions de communication sont systématiquement sous-testées dans les exercices cyber OT. Pourtant, une mauvaise gestion de la communication peut aggraver considérablement l'impact business d'un incident parfois plus que l'incident lui-même.

5. Ne pas faire de retex structuré à chaud

Le retour d'expérience (retex) dans les 24 à 48 heures qui suivent l'exercice est ce qui transforme un exercice en apprentissage réel. Un retex structuré couvre : ce qui a bien fonctionné et doit être capitalisé, ce qui n'a pas fonctionné et doit être corrigé, les décisions qui ont pris trop de temps et pourquoi, les informations qui manquaient et comment les rendre disponibles la prochaine fois. Sans ce retex, l'exercice reste un événement ponctuel sans impact durable sur la maturité de l'organisation.

Comment structurer un exercice OT efficace en pratique

Un exercice de crise cyber OT bien construit suit une logique en quatre temps. D'abord la définition des objectifs pédagogiques : que veut-on tester spécifiquement ? La coordination IT/OT ? La chaîne de décision d'arrêt de production ? La communication de crise externe ? Chaque exercice doit avoir un ou deux objectifs prioritaires clairs, pas une liste de vingt points à tester en même temps.

Ensuite la construction du scénario : il doit être réaliste, basé sur les menaces réelles qui pèsent sur le secteur d'activité, et calibré pour mettre à l'épreuve les objectifs définis. Le scénario doit être suffisamment détaillé pour guider les animateurs, mais suffisamment ouvert pour laisser les participants prendre de vraies décisions.

Puis l'animation de l'exercice : un bon animateur guide sans imposer, injecte des éléments d'information au bon moment, et veille à ce que tous les participants, pas seulement les plus à l'aise, soient impliqués dans les décisions.

Enfin le retex : structuré, facilité, documenté, et suivi d'un plan d'action avec des responsables et des délais. C'est le retex qui donne sa valeur à l'exercice.

Ce qu'il faut retenir

Un exercice de crise cyber OT qui rate ses objectifs, ce n'est pas seulement du temps perdu c'est une fausse assurance. Les participants repartent avec le sentiment d'avoir "fait leur exercice" sans avoir vraiment testé leur capacité de réponse réelle. Les cinq pièges présentés ici sont évitables avec une préparation rigoureuse et une volonté de sortir du confort d'un exercice purement IT transposé à l'OT.

Ressources CyberLead

Le Dossier de Sécurité CyberLead regroupe vos risques, exigences, cartographies, incidents et plans d’action dans une vision claire, à jour et partageable. Accédez-y gratuitement, commencez en autonomie, puis faites-le évoluer avec un expert.

Accédez à votre dossier de sécurité

Vous voyez un post LinkedIn sur le sujet , n’hésitez pas et partagez cet article en commentaire !

Partager

Un modèle né avant Internet, toujours présent dans vos usines

Le modèle de Purdue, conçu dans les années 1990, découpait les réseaux industriels en niveaux étanches : le niveau 0 pour les capteurs et actionneurs, le niveau 1 pour les automates, le niveau 2 pour la supervision, le niveau 3 pour les systèmes de gestion de production, et le niveau 4 pour les systèmes d'entreprise. L'idée était simple : isoler physiquement et logiquement chaque niveau pour contenir les incidents. Dans un monde sans connexions Internet ni interconnexion IT/OT massive, ça fonctionnait.

En 2025, ce modèle est partout mis à rude épreuve. Les usines se connectent au cloud pour les analyses de données de production. Les fournisseurs accèdent à distance aux automates pour la maintenance. Les ERP dialoguent directement avec les systèmes de supervision. La frontière IT/OT a fondu sous la pression de l'industrie 4.0, et le modèle de Purdue ressemble de plus en plus à une belle théorie que personne n'applique vraiment sur le terrain.

Ce que Zero Trust apporte et ce qu'il ne résout pas seul

Le Zero Trust est un paradigme apparu dans le monde IT : ne faire confiance à aucun utilisateur, aucun équipement, aucun flux réseau par défaut, et vérifier systématiquement chaque accès.

Trois principes fondamentaux le structurent.

Le premier est "ne jamais faire confiance, toujours vérifier". Chaque connexion est authentifiée, même si elle vient du réseau interne. Un automate qui envoie des données à un serveur de supervision doit être identifié et son comportement validé en permanence. Le deuxième est le moindre privilège : chaque équipement ou utilisateur n'accède qu'aux ressources strictement nécessaires à sa fonction. Le technicien de maintenance n'a pas accès à l'ensemble du réseau OT, seulement aux équipements de sa zone d'intervention. Le troisième est l'hypothèse de compromission : l'architecture est conçue en partant du principe qu'un attaquant est peut-être déjà à l'intérieur, ce qui implique une segmentation interne rigoureuse et une détection active des comportements anormaux.

Le problème dans l'environnement industriel : les équipements OT ne supportent pas les agents de sécurité, ne parlent pas TLS, ne savent pas s'authentifier auprès d'un annuaire centralisé. Appliquer les principes Zero Trust sur un automate Siemens des années 2000, c'est techniquement impossible sans mécanismes compensatoires.

Vers un modèle Purdue 2.0 : la synthèse pragmatique

Ce qui émerge dans les organisations les plus avancées n'est ni du Purdue pur ni du Zero Trust pur, mais une hybridation pragmatique. L'idée : conserver la logique de segmentation en niveaux du modèle Purdue, mais y appliquer les principes Zero Trust là où c'est techniquement possible, et des contrôles compensatoires là où ça ne l'est pas.

Concrètement : des DMZ industrielles entre les niveaux 2 et 3, des proxys applicatifs pour les accès distants fournisseurs, une authentification forte sur tous les accès IT/OT, et une surveillance comportementale passive sur les réseaux OT via des outils spécialisés. Ce n'est pas parfait, mais c'est applicable dans une usine réelle avec des contraintes de disponibilité non négociables.

3 questions pour évaluer votre maturité actuelle

1. Avez-vous une cartographie à jour de vos flux entre niveaux Purdue ?

Dans la plupart des usines, personne ne sait exactement ce qui passe du niveau 3 au niveau 2 et inversement. Les flux se sont créés au fil des projets, des intégrations ERP, des accès distants fournisseurs. Un audit des flux réseau OT est le point de départ obligatoire avant toute réflexion d'architecture. Sans carte, impossible de définir ce qu'on protège et comment.

2. Vos accès distants fournisseurs sont-ils contrôlés ou subis ?

L'accès distant est le vecteur d'attaque numéro un en environnement OT selon les rapports Dragos et Claroty des dernières années. Si vos fournisseurs se connectent via TeamViewer ou des VPN génériques sans authentification multifacteur et sans supervision en temps réel des sessions, vous avez un risque majeur ouvert en permanence. Mettre en place un bastion industriel Wallix, CyberArk ou équivalent n'est plus optionnel dans un contexte NIS2.

3. Votre détection couvre-t-elle le réseau OT ou seulement le réseau IT ?

La grande majorité des SOC d'entreprise ne voient pas le trafic OT. Ils surveillent les flux IT, les postes utilisateurs, les serveurs. Mais les automates, capteurs industriels et équipements de supervision restent dans une zone aveugle. La détection d'anomalies comportementales sur le réseau OT, le cœur de Nozomi Networks, Claroty ou Dragos, est devenue un prérequis de la maturité cybersécurité industrielle.

Le vrai risque : l'angle mort organisationnel

Dans les missions que j'ai menées, j'observe un pattern récurrent : les équipes IT considèrent que le réseau OT est "isolé donc sécurisé", et les équipes OT considèrent que "la sécurité c'est l'affaire de la DSI". Ce malentendu laisse des zones entières sans propriétaire de sécurité. Le modèle Purdue, mal appliqué, devient une fausse assurance : on croit les niveaux étanches alors qu'ils sont criblés d'exceptions non documentées, un accès VPN créé pour un prestataire il y a trois ans, une liaison directe niveau 2 vers le réseau bureautique ouverte pour un projet pilote et jamais refermée.

La vraie question n'est pas "Purdue ou Zero Trust ?" mais "qui est responsable de la cohérence de mon architecture OT, et a-t-il les moyens de l'évaluer et de l'améliorer ?" Sans réponse claire à cette question, aucun modèle d'architecture ne tiendra dans la durée.

Ce qu'il faut retenir

Le modèle de Purdue reste une référence utile pour structurer la réflexion sur la segmentation industrielle. Mais il ne peut plus être le seul cadre. Les principes Zero Trust : vérification systématique, moindre privilège, hypothèse de compromission doivent s'y superposer progressivement, là où les équipements le permettent. L'enjeu n'est pas de choisir entre deux modèles, c'est de construire une architecture cohérente avec la réalité opérationnelle de votre usine.

Ressources CyberLead

Le Dossier de Sécurité CyberLead regroupe vos risques, exigences, cartographies, incidents et plans d’action dans une vision claire, à jour et partageable. Accédez-y gratuitement, commencez en autonomie, puis faites-le évoluer avec un expert.

Accédez à votre dossier de sécurité

Vous voyez un post LinkedIn sur le sujet , n’hésitez pas et partagez cet article en commentaire !

Partager

La vérité sur l'âge de vos automates

D'expérience, quand on demande à un directeur industriel quel est l'âge moyen de ses équipements OT, la réponse est souvent approximative. Quand on fait l'inventaire réel avec les dates d'installation, on découvre que 30 à 50% des automates, capteurs et systèmes de supervision sont en fin de support officiel de leur constructeur ou en passe de l'être dans les trois à cinq prochaines années. C'est ce que confirme TXOne Networks dans son rapport 2024 : environ 50% des équipements OT déployés dans les infrastructures industrielles mondiales tournent sur des systèmes en fin de vie ou en fin de support de sécurité.

La fin de support, ce n'est pas la fin de la vie opérationnelle. Un automate Siemens S7-300 dont le support officiel s'est terminé en 2023 peut très bien continuer à tourner sans incident pendant encore dix ans. Le problème n'est pas la défaillance mécanique ou logicielle, c'est l'absence de correctifs de sécurité. Un équipement en fin de support qui reçoit de nouvelles vulnérabilités ne bénéficiera d'aucun patch constructeur. Et ces vulnérabilités s'accumulent avec le temps, augmentant mécaniquement la surface d'attaque.

Pourquoi on n'arrête pas les lignes pour changer un automate

La question que pose souvent la direction générale face à ce constat : pourquoi ne pas simplement remplacer les équipements en fin de support ? La réponse est multidimensionnelle. D'abord, le coût : remplacer un automate industriel dans une ligne de production, ce n'est pas seulement le prix de l'équipement c'est l'arrêt de la ligne, la migration des programmes, la requalification du process, les tests de reprise, la formation des équipes. Sur un équipement critique, le coût total peut être dix à vingt fois le prix de l'équipement lui-même.

Ensuite, la disponibilité : dans beaucoup de secteurs industriels, les lignes tournent 24h/24, 7j/7, avec des fenêtres de maintenance planifiées très limitées. Remplacer un automate en production demande une coordination complexe entre les équipes de production, de maintenance, le fournisseur et le RSSI, une coordination qui prend des mois à mettre en place.

Enfin, la dépendance : certains équipements sont intégrés dans des systèmes propriétaires dont les remplaçants n'existent plus sur le marché. Remplacer l'automate impose alors de revoir l'architecture complète de la ligne, un projet pluriannuel et plurimillionnaire.

4 approches pour gérer les équipements en fin de support sans tout remplacer

1. Prioriser par criticité réelle et exposition réseau

Tous les équipements en fin de support ne présentent pas le même niveau de risque. Un automate isolé physiquement, sans connexion réseau, dans une zone à accès restreint, est infiniment moins risqué qu'un contrôleur en fin de support avec un accès réseau ouvert et une interface de maintenance accessible à distance. La priorité doit aller aux équipements les plus exposés, ceux qui ont des connexions réseau, ceux qui contrôlent des process critiques, ceux pour lesquels des CVE actives existent.

2. Déployer des contrôles compensatoires robustes

Pour les équipements qu'on ne peut pas remplacer à court terme, des contrôles compensatoires permettent de réduire le risque : isolation réseau renforcée via des VLAN dédiés et des règles de pare-feu strictes, suppression de tous les accès non nécessaires, surveillance comportementale passive pour détecter toute activité anormale, et mise en place d'une whitelist des communications autorisées. Ces contrôles ne font pas disparaître la vulnérabilité, mais ils réduisent significativement la probabilité et l'impact d'une exploitation.

3. Construire un plan de remplacement pluriannuel réaliste

La bonne approche n'est pas de prétendre qu'on va tout remplacer rapidement. Elle est de construire un plan de remplacement sur 3 à 7 ans, priorisé par le niveau de risque, budgété et validé par la direction. Ce plan doit être intégré dans les cycles d'investissement de l'entreprise, pas traité comme un projet cybersécurité isolé. L'arbitrage doit se faire au niveau de la direction industrielle, pas au niveau du RSSI seul.

4. Négocier le support étendu avec les constructeurs

Beaucoup de constructeurs proposent des programmes de support étendu payant pour les équipements en fin de support officiel. Ces programmes incluent généralement la publication de correctifs critiques, l'accès à une hotline technique dédiée et des bulletins de sécurité. Le coût est significatif, souvent de l'ordre de 15 à 25% du prix d'achat initial par an mais il est souvent bien inférieur au coût d'un remplacement prématuré.

Ce que ça demande du RSSI

Gérer les équipements OT en fin de support n'est pas un problème technique au sens strict. C'est un problème de gouvernance, de budget et de priorisation des risques. Le RSSI industriel qui aborde ce sujet avec sa direction doit pouvoir quantifier le risque en termes d'exposition aux CVE actives, en termes de coût d'incident potentiel et proposer un plan d'action réaliste avec des options chiffrées.

L'erreur classique est d'arriver avec une liste d'équipements à remplacer sans contexte financier. La direction voit un coût, pas un risque géré. L'approche qui fonctionne : présenter le risque résiduel de chaque scénario : statu quo, contrôles compensatoires, remplacement, avec le coût associé à chacun. C'est un arbitrage éclairé que la direction peut faire ; une demande de remplacement de masse sans justification, non.

Ce qu'il faut retenir

Le vieillissement du parc OT est une réalité inévitable dans toute organisation industrielle. La question n'est pas de l'éviter mais de le gérer avec rigueur : inventaire des équipements en fin de support, évaluation de l'exposition réelle de chacun, contrôles compensatoires pour les équipements qui restent, plan de remplacement priorisé pour les autres. Un parc OT vieillissant bien géré est infiniment moins risqué qu'un parc récent laissé sans gouvernance.

Ressources CyberLead

Le Dossier de Sécurité CyberLead regroupe vos risques, exigences, cartographies, incidents et plans d’action dans une vision claire, à jour et partageable. Accédez-y gratuitement, commencez en autonomie, puis faites-le évoluer avec un expert.

Accédez à votre dossier de sécurité

Vous voyez un post LinkedIn sur le sujet , n’hésitez pas et partagez cet article en commentaire !

Partager