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

Contexte

Le non-sujet qui devient un sujet

D’expérience, quand on pose la question en audit, la réponse est toujours la même. Les équipes de production pensent que c’est la DSI. La DSI pense que c’est le fournisseur. Et le fournisseur attend qu’on lui passe une commande de prestation. Résultat : les firmwares des automates, des capteurs et des équipements de supervision ne sont jamais mis à jour, ou alors lors d’une migration lourde tous les cinq à dix ans. Entre-temps, les vulnérabilités s’accumulent et les attaquants en profitent.

En 2025, la CISA a publié un rapport signalant une hausse de 40% des dispositifs ICS exposés sur Internet entre 2024 et 2025. Des éditeurs comme Siemens, Rockwell Automation et Schneider Electric publient des correctifs critiques tous les trimestres sur leurs gammes phares. Ces correctifs concernent des failles permettant, dans certains cas, une exécution de code à distance sur des automates en production. Le problème n’est pas le manque de correctifs disponibles. C’est l’absence totale de processus pour les appliquer.

Pourquoi c’est fondamentalement différent du patch IT classique

Dans le monde IT, on déploie des mises à jour via un gestionnaire centralisé, avec des fenêtres de maintenance nocturnes et un rollback automatique en cas de problème. En OT, rien de tout ça n’existe. Mettre à jour le firmware d’un automate Siemens S7-1500 en production, c’est souvent arrêter la ligne. Et arrêter la ligne, c’est une décision qui remonte au niveau direction générale, pas à la DSI.

Autre différence majeure : la durée de vie des équipements. Un serveur IT tourne 3 à 5 ans. Un automate OT peut rester en production 15 à 25 ans. Sur cette durée, le constructeur peut avoir arrêté le support ou décidé de ne plus publier de correctifs pour les versions anciennes. Le RSSI se retrouve à gérer un parc dont certains firmwares n’ont pas été touchés depuis l’installation initiale parfois en 2008 ou 2010.

Il faut aussi compter avec la validation fournisseur. En IT, on teste sur un environnement de préproduction et on déploie. En OT, le patch doit être validé par le constructeur pour chaque configuration terrain. Cette validation peut prendre des semaines, parfois des mois. C’est un frein réel mais un frein qu’on peut anticiper si on s’y prend suffisamment tôt.

5 mesures concrètes pour reprendre le contrôle

1. Inventorier les firmwares existants, version par version

Impossible de gérer ce qu’on ne connaît pas. La première étape est de constituer un inventaire exhaustif des équipements OT avec leur version de firmware actuelle. Des outils comme Claroty, Nozomi Networks ou Dragos permettent cette collecte de manière passive, sans perturber la production. L’objectif n’est pas la perfection : c’est d’identifier les équipements en version connue comme vulnérable, surtout ceux exposés à d’autres segments réseau.

2. Formaliser qui est responsable : RSSI, DSI ou équipes OT ?

C’est la question de gouvernance que personne ne veut trancher. Il faut la poser explicitement en réunion avec la direction de production, la DSI et la direction technique, et définir une matrice RACI claire. Dans la plupart des organisations matures que j’ai accompagnées, c’est l’équipe OT qui porte l’exécution, avec le RSSI comme garant du processus et de la conformité réglementaire.

3. Intégrer les mises à jour dans les fenêtres de maintenance planifiées

Les arrêts machines existent déjà dans toute usine : maintenance préventive annuelle, arrêts techniques trimestriels, révisions hebdomadaires sur certaines lignes. L’enjeu est de ne pas créer de fenêtres supplémentaires mais d’intégrer les mises à jour cybersécurité au même titre que les contrôles mécaniques. Cela nécessite d’anticiper avec les fournisseurs, souvent 3 à 6 mois à l’avance.

4. Exiger la validation fournisseur par écrit avant tout déploiement

Certains correctifs publiés par les éditeurs ne sont pas compatibles avec toutes les configurations terrain. Avant de déployer quoi que ce soit, obtenez par écrit la validation du fournisseur que le firmware est compatible avec votre configuration spécifique. Cette démarche protège aussi l’organisation en cas de dysfonctionnement post-mise à jour et peut valoir de l’or lors d’un audit ou d’une procédure assurance.

5. Mettre en place un suivi des CVE OT par équipement

Abonnez-vous aux bulletins de sécurité de vos principaux fournisseurs et croisez-les avec le catalogue KEV de la CISA. L’objectif n’est pas de traiter chaque CVE publiée, il y en a des centaines par an, mais d’identifier celles qui sont activement exploitées dans la nature et qui touchent vos équipements critiques. Ce suivi peut être assuré par un ingénieur cybersécurité industrielle ou délégué à un prestataire spécialisé.

Un cas concret : ce que révèle vraiment l’inventaire

Un industriel du secteur chimique avec qui j’ai travaillé avait 340 automates en production, sans aucun inventaire firmware existant. Quand on l’a constitué et croisé avec les CVE connues, on a identifié 23 équipements avec des failles critiques actives, dont 4 automates directement impliqués dans le contrôle de procédés à risque élevé. Le directeur de production ne savait pas. La DSI ne savait pas. Personne n’avait la mission explicite de le vérifier.

La bonne nouvelle : une fois la gouvernance clarifiée et l’inventaire constitué, les mises à jour prioritaires ont été traitées en moins de six mois, dans les fenêtres de maintenance existantes, sans arrêt supplémentaire de production. Le coût opérationnel réel était marginal. C’est toujours l’absence de processus qui coûte cher, jamais le patch lui-même.

Ce qu’il faut retenir

Le firmware est le socle de confiance d’un équipement industriel. Laisser cette couche non gérée, c’est accepter que n’importe qui ayant connaissance d’une CVE publique puisse potentiellement prendre la main sur vos machines. Le problème n’est pas technique, c’est organisationnel. La solution passe d’abord par clarifier qui est responsable, avant même de parler d’outils.

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

Contexte

Il y a quelques semaines, un collaborateur vient me voir avec un enthousiasme non dissimulé. Il me montre son écran : Claude Cowork est en train de naviguer sur son ordinateur, d’ouvrir des fichiers, de modifier des documents, de lancer des recherches web. Le tout de manière autonome. Ma première réaction en tant que RSSI : un mélange de fascination technique et de sueur froide.

Claude Cowork, pour ceux qui ne connaissent pas encore, c’est la dernière évolution d’Anthropic. Ce n’est plus un simple chatbot à qui on pose des questions. C’est un agent IA qui prend le contrôle de votre poste de travail : il navigue dans Chrome, écrit des fichiers, exécute du code, interagit avec vos outils métier, se connecte à vos MCP servers, accède à vos données locales. En clair, c’est un collaborateur virtuel avec les droits de la session de l’utilisateur.

Et le problème, c’est que ce n’est pas un cas isolé. En deux semaines, nous avons identifié plus d’une dizaine de collaborateurs qui avaient déjà installé et utilisé l’outil, certains sur des environnements connectés à des services critiques. Personne n’avait demandé d’avis à la DSI, encore moins au RSSI.

Pourquoi c’est différent de ChatGPT

On avait déjà géré l’arrivée de ChatGPT. On avait mis en place des mesures, sensibilisé, encadré l’usage. Mais avec Claude Cowork, on change complètement de dimension. Ce n’est plus l’utilisateur qui copie-colle des données dans un chatbot. C’est l’IA elle-même qui accède directement à l’environnement de travail.

Les risques que nous avons identifiés rapidement :

Prise de contrôle de la session utilisateur

Claude Cowork opère avec les mêmes droits que l’utilisateur connecté. Si le collaborateur a accès à un ERP, à un CRM, à des partages réseau sensibles, l’IA y a accès aussi. Il n’y a pas de ségrégation de droits entre ce que fait l’humain et ce que fait l’agent.

Prompt injection et manipulation externe

C’est le risque le plus sous-estimé. Quand Claude Cowork navigue sur le web ou ouvre des documents, il peut lire du contenu malveillant injecté dans des pages web, des emails ou des fichiers partagés. Un attaquant peut cacher des instructions dans un document anodin qui redirigent le comportement de l’IA. On parle ici d’indirect prompt injection : l’IA exécute une action qu’on ne lui a jamais demandée parce qu’elle a lu une instruction cachée.

Modification et destruction de données

L’IA peut créer, modifier et supprimer des fichiers. Elle peut écrire du code et l’exécuter directement sur le poste. Une mauvaise instruction, une hallucination, ou un prompt injection bien placé, et on se retrouve avec des fichiers critiques altérés ou supprimés.

Fuite de données vers l’extérieur

Chaque interaction avec Claude Cowork envoie des données aux serveurs d’Anthropic. Les fichiers lus, les pages visitées, le contexte de travail : tout remonte. Dans un environnement où l’on manipule des données clients, des documents stratégiques ou des informations financières, cette question de souveraineté des données ne peut pas être ignorée.

Les 7 étapes que nous avons initiées en urgence

Face à la vitesse de déploiement spontané de l’outil, nous avons décidé de ne pas interdire mais d’encadrer. Interdire un outil que les collaborateurs trouvent productif, on sait comment ça finit : ça passe en Shadow IT et on perd toute visibilité.

1. Sensibilisation aux risques spécifiques de l’IA agentique

Première action, et probablement la plus urgente : sensibiliser. Pas une sensibilisation générique sur l’IA, mais ciblée sur les risques propres à un agent autonome. Nous avons organisé des sessions courtes avec les équipes concernées pour expliquer la différence entre un chatbot classique et un agent qui agit sur votre poste. La démonstration en live d’un prompt injection sur Claude Cowork a eu un effet immédiat sur la prise de conscience.

2. Mise à jour de la charte informatique

Notre charte informatique ne couvrait pas les agents IA autonomes. Nous avons ajouté une section dédiée couvrant l’utilisation des agents IA : périmètre autorisé, types de données interdites, obligation de déclaration préalable. Cette mise à jour a été validée en urgence avec le DPO et le service juridique.

3. Onboarding systématique par l’IT

Règle non négociable : tout déploiement de Claude Cowork ou d’un agent IA similaire doit passer par l’IT. Pas d’installation sauvage. L’équipe IT vérifie l’environnement, les droits de l’utilisateur, les connexions aux services et les MCP configurés. C’est aussi l’occasion d’appliquer le principe du moindre privilège.

4. Restriction aux environnements sans impact production

C’est la mesure la plus structurante. Nous avons décidé que Claude Cowork ne pouvait être utilisé que sur des comptes et des environnements n’ayant aucun impact sur les services de production, les systèmes industriels et les données clients critiques. En clair : oui pour de la rédaction, de la recherche, du prototypage sur des environnements isolés. Non pour tout ce qui touche à l’opérationnel.

5. Accompagnement Safe AI avec limites de contrôle

Plutôt que de laisser les utilisateurs seuls face à l’outil, nous avons mis en place un accompagnement. Chaque nouveau cas d’usage passe par une évaluation rapide avec l’équipe cybersécurité : quelles données sont concernées, quels accès sont nécessaires, quelles sont les limites de contrôle à configurer.

6. Revue régulière a posteriori

Comme la technologie est nouvelle et que les cas d’usage évoluent vite, nous avons instauré une revue régulière des usages. Toutes les deux semaines, nous analysons les logs d’utilisation, les incidents éventuels, les retours des utilisateurs. C’est du pilotage adaptatif, pas du contrôle rigide.

7. Recherche de solutions sur le marché

Dernier point : nous avons lancé une veille active sur les solutions de sécurisation de l’IA agentique. Plusieurs startups sont en train de se positionner sur ce créneau avec des offres de monitoring, de sandboxing et de contrôle des agents IA. Le marché est encore très jeune, mais il est essentiel de suivre l’évolution. Nous évaluons actuellement trois acteurs spécialisés.

Ce qu’il faut retenir

L’IA agentique représente un changement de paradigme en cybersécurité. On ne parle plus de fuites de données via un copier-coller dans un chatbot. On parle d’un agent autonome qui agit sur nos systèmes avec les droits de nos collaborateurs. Le sujet est trop sérieux pour le traiter en réaction. Il faut anticiper, encadrer, accompagner.

D’expérience, la clé est de ne pas se positionner en opposant mais en accompagnateur. Les collaborateurs vont utiliser ces outils, avec ou sans nous. Notre rôle en tant que RSSI est de créer le cadre qui permet l’innovation sans mettre en danger l’entreprise.

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 scanner qui a fait tomber la ligne

D'expérience, la prise de conscience arrive souvent après un incident. Un responsable cybersécurité dans une cimenterie m'a raconté le moment où il a lancé un scan Nessus sur le réseau OT pour "voir ce qu'il y avait là-dedans". Résultat : trois automates se sont figés simultanément, la ligne s'est arrêtée, et il a fallu un redémarrage manuel avec intervention sur site des techniciens du constructeur. Le scan avait inondé le réseau de requêtes auxquelles les vieux équipements n'étaient pas conçus pour répondre, certains protocoles industriels ne prévoient tout simplement pas de mécanisme de gestion d'erreurs face à un volume de trafic inhabituel.

Ce type d'incident est plus fréquent qu'on ne le croit. Il ne fait pas les gros titres parce que les entreprises préfèrent ne pas l'admettre. Mais dans les cercles RSSI industriels, c'est un classique. Le problème n'est pas le scanner, c'est l'usage d'un outil conçu pour un monde IT dans un environnement OT où la disponibilité prime sur tout le reste.

Pourquoi les scanners actifs sont incompatibles avec l'OT

Un scanner de vulnérabilités actif comme Nessus, Qualys ou OpenVAS fonctionne en envoyant des requêtes réseau pour identifier les équipements, leurs versions logicielles et leurs failles connues. Dans le monde IT, les équipements sont conçus pour répondre à ce type de trafic sans sourciller, les systèmes d'exploitation modernes gèrent les flux de requêtes sans problème.

En OT, les automates, les capteurs et les équipements de supervision industrielle ont été conçus pour exécuter des tâches temps réel avec une fiabilité maximale, pas pour gérer des flux réseau inhabituels. Un automate Siemens S7-300 ou un contrôleur Allen-Bradley des années 2010 peut planter ou redémarrer face à une requête réseau qu'il ne sait pas interpréter. Pire encore : certains équipements réagissent à certaines requêtes de scan en exécutant des actions non prévues sur les process physiques qu'ils contrôlent.

Le risque n'est pas théorique. Il est documenté, reproductible, et potentiellement catastrophique dans un environnement critique comme la chimie, l'énergie ou le traitement des eaux. La règle d'or : ne jamais lancer un scan actif sur un réseau OT en production sans validation préalable du constructeur de chaque équipement concerné.

4 alternatives au scan actif pour cartographier votre surface d'attaque OT

1. La surveillance passive du trafic réseau

Des outils comme Claroty, Nozomi Networks ou Dragos écoutent passivement le trafic réseau OT sans envoyer la moindre requête. Ils identifient les équipements présents, leurs protocoles, leurs versions et leurs comportements habituels. C'est la méthode de référence : aucun risque de perturbation, visibilité complète, et en bonus une détection des anomalies comportementales en temps réel.

2. L'interrogation via les protocoles natifs

Certaines solutions spécialisées savent interroger les équipements OT via leurs propres protocoles industriels ( Modbus, Profinet, DNP3 ) de manière douce, sans générer de trafic anormal. C'est ce que font des outils comme Tenable.OT ou Claroty en mode actif sécurisé. La différence avec un scanner IT générique : ils parlent la langue des équipements, dans les limites que ceux-ci peuvent accepter sans risque.

3. La collecte via les assets management existants

Les systèmes SCADA et MES maintiennent souvent des bases de données d'actifs qui contiennent déjà les versions logicielles et firmware des équipements connectés. Exploiter ces données existantes sans aucun scan réseau est souvent le chemin le plus rapide et le moins risqué pour constituer un premier inventaire exploitable. C'est un point de départ sous-estimé dans beaucoup d'organisations.

4. Les audits terrain avec les équipiers OT

Pour les équipements qui ne communiquent pas sur le réseau, ou dont les informations de version ne sont pas accessibles à distance, il n'y a pas d'autre choix que l'audit terrain. Un technicien qui relève les étiquettes firmware sur les automates lors des fenêtres de maintenance c'est basique, mais ça marche et ça ne casse rien. Dans beaucoup d'usines, c'est encore la méthode la plus fiable pour les équipements les plus anciens.

La bonne gouvernance autour de l'inventaire OT

Constituer l'inventaire, c'est une chose. Le maintenir à jour en est une autre. Dans la plupart des organisations que j'ai accompagnées, l'inventaire OT se dégrade rapidement après sa création initiale : un équipement remplacé en urgence, un firmware mis à jour par un prestataire sans mise à jour de la documentation, une nouvelle machine intégrée en dehors des processus habituels.

La surveillance passive résout ce problème naturellement : elle détecte en temps réel l'apparition de nouveaux équipements, les changements de version et les comportements inhabituels. C'est pourquoi les organisations les plus matures combinent les deux approches : un inventaire initial constitué par audit terrain et complété par les assets managers existants, puis maintenu en continu par une sonde de surveillance passive.

Le RSSI industriel qui n'a pas encore ce niveau de visibilité a une priorité claire avant tout autre projet cybersécurité OT : savoir ce qui tourne dans ses réseaux industriels. On ne peut pas protéger ce qu'on ne voit pas.

Ce qu'il faut retenir

Scanner un réseau OT avec des outils IT, c'est comme faire une radiographie avec un matériel calibré pour un autre usage : au mieux les résultats sont inutilisables, au pire on aggrave le problème. La cartographie des vulnérabilités OT est un métier spécifique, avec des outils spécifiques. Le RSSI qui ne dispose pas encore de ces outils a une priorité claire : identifier quelle solution de monitoring passif OT correspond à son environnement et le déployer avant le prochain audit NIS2.

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 phénomène qui explose

En janvier 2025, le cofondateur de Ledger, David Balland, est enlevé à son domicile dans le centre de la France avec sa compagne. Les ravisseurs lui sectionnent un doigt et exigent une rançon de 10 millions d’euros en cryptomonnaies. L’affaire se termine par l’intervention du GIGN et le gel des fonds par Tether en quelques heures. On pourrait croire à un cas isolé. Ce n’est que le début.

Depuis, la France est devenue la capitale mondiale des enlèvements liés aux cryptomonnaies. Plus de 30 cas documentés depuis 2025, dont une vingtaine rien qu’en France. En février 2026, CNN rapporte le sauvetage d’une mère et sa fille séquestrées à Manosque. Les « wrench attacks », ces agressions physiques visant à forcer le transfert de crypto, ont bondi de 75 % en un an avec 72 incidents confirmés dans le monde. L’Europe concentre plus de 40 % des cas, et la France en représente 80 % au niveau européen.

Les pertes liées aux agressions physiques ont dépassé 40 millions de dollars en 2025. Et ces chiffres ne comptent que les cas rapportés.

Pourquoi le RSSI est concerné

On pourrait penser que les enlèvements pour crypto sont un problème de sécurité personnelle qui ne concerne pas l’entreprise. C’est une erreur d’analyse. Plusieurs raisons font que ce sujet atterrit directement sur le bureau du RSSI.

Les fuites de données créent les cibles

Les attaquants ne choisissent pas leurs victimes au hasard. Les fuites de données des plateformes d’échange, les registres publics d’entreprises, les réseaux sociaux et les déclarations fiscales permettent d’identifier les détenteurs, leur patrimoine estimé et leur adresse. La fuite de la base clients de Ledger en 2020 continue d’alimenter des campagnes de phishing physique par courrier postal en 2026, avec de fausses lettres imitant Ledger et Trezor demandant aux victimes de saisir leur phrase de récupération.

Les dirigeants et collaborateurs sont exposés

Dans une entreprise où des dirigeants ou collaborateurs sont connus pour détenir des cryptomonnaies, le risque n’est plus seulement cyber mais physique. Un directeur financier, un fondateur, un responsable blockchain : tous peuvent devenir des cibles. L’enlèvement d’un collaborateur a des conséquences directes sur l’entreprise, même si la rançon demandée est en cryptomonnaies personnelles.

Le phishing physique est une nouvelle menace

Les criminels envoient désormais des lettres postales physiques aux utilisateurs de wallets Ledger et Trezor, imitant les communications officielles des fabricants. Ces lettres demandent de scanner un QR code ou d’entrer une phrase de récupération sous prétexte de vérification de sécurité. C’est du social engineering old school, mais il fonctionne parce que les gens font confiance au courrier physique.

6 mesures que le RSSI peut initier

Ce sujet est à la frontière entre la cybersécurité et la sûreté physique. Le RSSI ne peut pas tout résoudre seul, mais il peut impulser une démarche et coordonner les actions avec la direction, les RH et la sûreté.

1. Audit OSINT des expositions personnelles

Première action concrète : faire réaliser un audit OSINT pour les dirigeants et collaborateurs exposés. L’objectif est de reconstituer ce qu’un attaquant pourrait trouver en sources ouvertes : adresse personnelle dans les registres d’entreprise, publications sur les réseaux sociaux mentionnant des cryptomonnaies, présence dans des fuites de données connues. Des sociétés spécialisées comme Perimeter Lab, fondée par d’anciens employés de Ledger, proposent exactement ce type de prestation.

2. Sensibilisation ciblée des collaborateurs concernés

Les collaborateurs détenant des cryptomonnaies doivent être sensibilisés aux risques spécifiques : ne jamais mentionner ses avoirs crypto sur les réseaux sociaux, se méfier des courriers physiques demandant des phrases de récupération, comprendre que la détention de hardware wallets peut faire d’eux des cibles physiques.

3. Nettoyage des données publiques

Travailler avec le service juridique pour retirer les adresses personnelles des dirigeants des registres publics accessibles en ligne. Le député Paul Midy a introduit une proposition de loi pour automatiser ce retrait en France. En attendant, des démarches volontaires sont possibles auprès des registres du commerce et des bases de données d’entreprises.

4. Renforcement de la sécurité physique

Pour les collaborateurs identifiés comme à risque : revue des dispositifs de sûreté au domicile, mise en place d’alertes, coordination avec les forces de l’ordre locales si nécessaire. Certaines entreprises ont commencé à proposer un accompagnement sûreté à leurs dirigeants exposés, incluant des audits physiques de domicile et des procédures d’urgence.

5. Politique de sécurité pour les hardware wallets

Si l’entreprise utilise des wallets hardware pour des activités professionnelles, une politique de sécurité dédiée est indispensable : stockage sécurisé des clés, multi-signature obligatoire pour les transactions importantes, rotation des accès, procédure de révocation en cas de compromission. Le point clé : aucun collaborateur ne doit pouvoir, seul, transférer des fonds significatifs sous la contrainte.

6. Veille et coordination avec les autorités

La police nationale française a créé fin 2024 une unité spécialisée dans les crimes liés aux cryptomonnaies, collaborant avec des entreprises d’analyse blockchain comme Chainalysis pour tracer les rançons. Le RSSI doit maintenir une veille active sur les incidents rapportés et les modes opératoires. Le cadre réglementaire MiCA, attendu pour mi-2026, devrait également renforcer les exigences de sécurité.

Ce qu’il faut retenir

La menace crypto n’est plus virtuelle. Elle est physique, violente, et elle touche la France en premier. Les clés physiques de type Ledger ou Trezor, conçues pour protéger les actifs numériques, deviennent paradoxalement un marqueur de richesse qui attire les criminels. Le RSSI ne peut pas ignorer ce risque sous prétexte qu’il sort du périmètre technique.

D’expérience, c’est exactement le type de menace hybride qui définit le rôle moderne du RSSI. La cybersécurité ne s’arrête pas au firewall. Quand les données fuitées d’une plateforme servent à planifier un enlèvement, la frontière entre sécurité informatique et sûreté physique n’existe plus.

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 borgne dans votre réseau OT

D'expérience, quand on demande à un RSSI industriel combien de capteurs IoT sont déployés dans son usine, la réponse oscille entre "une centaine" et "je ne sais pas exactement". Quand on fait l'inventaire réel, on se retrouve souvent avec deux à cinq fois plus d'équipements que prévu — des capteurs de température ajoutés lors d'un projet pilote, des passerelles WiFi installées par la maintenance, des équipements de mesure connectés directement sur le réseau sans autorisation formelle. Ces équipements existent, ils communiquent, et ils ne sont dans aucun registre de sécurité.

C'est le paradoxe de l'IoT industriel : ces capteurs sont déployés pour améliorer la visibilité opérationnelle — mesurer, surveiller, optimiser — mais ils créent en parallèle une zone d'ombre dans la posture de sécurité. Selon le rapport Forescout 2025, les attaques ciblant les équipements IoT industriels ont augmenté de 136% en un an. Et dans la grande majorité des cas analysés, le vecteur d'entrée initial était un équipement IoT non géré, non patché, ou accessible avec ses identifiants d'usine.

Pourquoi les capteurs IoT sont une cible de choix

Les capteurs IoT industriels cumulent plusieurs caractéristiques qui en font des cibles attractives. Ils sont nombreux et souvent identiques — compromettre un modèle de capteur, c'est potentiellement compromettre des centaines d'équipements en même temps. Ils fonctionnent avec des ressources limitées qui ne permettent pas d'embarquer des agents de sécurité ou de gérer des certificats complexes. Ils sont rarement mis à jour — le cycle de mise à jour d'un capteur industriel, quand il existe, est souvent annuel ou bi-annuel. Et ils sont souvent connectés directement au réseau IT pour transmettre leurs données vers des plateformes cloud d'analyse, créant des ponts entre le réseau OT et l'extérieur.

Un capteur IoT compromis peut servir de point d'appui pour une reconnaissance du réseau interne, un mouvement latéral vers d'autres équipements, l'exfiltration de données de production, ou dans les cas les plus sévères, la perturbation des process industriels qu'il est censé surveiller.

4 mesures pour réduire la surface d'attaque IoT en usine

1. Inventorier tous les équipements IoT — y compris ceux qu'on ne connaît pas

La première mesure est la plus difficile à accepter psychologiquement : reconnaître qu'on ne sait pas ce qui est connecté sur le réseau. Une sonde de surveillance passive — Claroty, Nozomi, Forescout — permet de découvrir automatiquement tous les équipements présents sur le réseau, y compris ceux qui n'ont jamais été déclarés. Le résultat de cet inventaire est souvent une surprise, et c'est précisément pour ça qu'il faut le faire.

2. Segmenter les capteurs IoT dans des VLAN dédiés

Les capteurs IoT n'ont aucune raison légitime d'accéder à d'autres équipements du réseau que les serveurs de collecte de données vers lesquels ils envoient leurs mesures. Les isoler dans des VLAN dédiés avec des règles de pare-feu strictes limite considérablement la propagation en cas de compromission. Si un capteur est infecté, il ne peut pas servir de tremplin vers le reste du réseau.

3. Changer systématiquement les identifiants d'usine

C'est la mesure la plus simple et pourtant la moins appliquée. Les identifiants par défaut des capteurs IoT industriels sont publiquement documentés — sur les sites des constructeurs, sur Shodan, dans les bases de données d'attaquants. Un simple scan du réseau avec ces identifiants permet à n'importe qui d'accéder à des centaines d'équipements. Mettre en place un processus de changement systématique des identifiants à la mise en service est non négociable.

4. Mettre en place une détection comportementale sur le trafic IoT

Un capteur de température qui commence à scanner d'autres adresses réseau ou à établir des connexions vers des destinations inconnues — c'est un signal d'alerte clair. La surveillance comportementale passive permet de détecter ces anomalies sans perturber le fonctionnement des équipements. C'est la seule approche qui permet de détecter une compromission sur un équipement qui ne peut pas embarquer d'agent de sécurité.

L'angle mort organisationnel

Au-delà des mesures techniques, le problème IoT en usine a une dimension organisationnelle forte. Dans beaucoup d'entreprises industrielles, les capteurs IoT sont achetés et déployés par les équipes de production ou de maintenance, sans validation préalable de la DSI ou du RSSI. Le service IT n'est consulté que pour la connexion réseau — et encore, pas toujours. Ce shadow IoT est la conséquence directe d'un processus d'achat qui ne prévoit pas de validation cybersécurité pour les équipements "petits" ou "périphériques".

La solution passe par une politique d'achat claire : tout équipement se connectant au réseau industriel — quelle que soit sa taille ou son coût — doit faire l'objet d'une validation cybersécurité avant déploiement. Ce n'est pas une bureaucratie supplémentaire, c'est un garde-fou indispensable face à la prolifération des objets connectés en milieu industriel.

Un retour terrain qui illustre l'enjeu

Lors d'un audit dans une usine pharmaceutique, nous avons identifié 47 capteurs de température et d'humidité connectés au réseau OT pour surveiller les conditions de stockage des produits finis. Sur ces 47 capteurs, 41 utilisaient encore les identifiants d'usine, 12 n'avaient pas reçu de mise à jour firmware depuis leur installation initiale — soit plus de quatre ans — et 6 étaient directement accessibles depuis le réseau IT sans aucune règle de filtrage. Aucun de ces capteurs n'apparaissait dans le registre d'actifs de la DSI. Pourtant, certains d'entre eux stockaient localement des données de traçabilité réglementaire. La compromission de ces capteurs aurait eu des conséquences directes sur la conformité réglementaire du site — bien au-delà de la cybersécurité au sens strict.

Ce qu'il faut retenir

Les capteurs IoT industriels sont le nouveau périmètre à sécuriser. Nombreux, souvent mal gérés, connectés à des réseaux critiques, ils représentent une surface d'attaque en expansion rapide. Les quatre mesures présentées ici — inventaire, segmentation, changement des identifiants, détection comportementale — constituent le socle minimal d'une démarche de sécurisation IoT en environnement industriel.

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 terrain

Un lundi matin, 6h30. L’équipe de production lance la première ligne d’emballage. Tout est prêt : matières premières, opérateurs, planning de commandes. Sauf qu’aucune étiquette ne sort. L’imprimante d’étiquettes, celle qui imprime les DLC, les numéros de lot, les informations de traçabilité obligatoires, est bloquée. Le PC qui la pilote affiche un écran figé. Et sans étiquettes conformes, aucun produit ne peut être expédié. La chaîne est à l’arrêt.

Ce scénario n’a rien d’exceptionnel. Dans l’agroalimentaire, l’étiquetage est un point de passage obligatoire. Les réglementations européennes imposent une traçabilité complète : DLC, numéro de lot, allergènes, origine. Sans étiquette conforme, le produit ne peut pas quitter l’usine. L’imprimante d’étiquettes n’est pas un périphérique anodin. C’est un équipement critique de la chaîne de production.

Le PC oublié de la cybersécurité

Et c’est là que le sujet cyber entre en jeu. Le PC qui pilote cette imprimante, on le connaît bien dans l’industrie. C’est souvent un poste sous Windows 7 ou Windows 10 jamais mis à jour, installé il y a cinq ou dix ans par l’intégrateur de la ligne. Il est sur le réseau de production, parfois même sur le réseau bureautique par facilité. Il n’a pas d’EDR, pas d’antivirus à jour, pas de politique de patching. Et personne ne s’en occupe côté IT parce que c’est du ressort de la production ou de la maintenance.

En 2025, les vulnérabilités affectant les imprimantes se sont multipliées. Plus de 750 modèles d’imprimantes Brother, Fujifilm et Toshiba ont été ciblés par des exploits actifs depuis juillet 2025. Canon a publié un correctif critique pour la CVE-2025-1268 permettant l’exécution de code arbitraire via ses pilotes. Les vulnérabilités du Print Spooler Windows continuent d’être exploitées année après année.

Le résultat, c’est un cocktail explosif : un PC non protégé connecté au réseau, avec un système obsolète, pilotant un équipement critique sans lequel la production s’arrête. C’est exactement le type de cible que les ransomwares adorent.

Pourquoi l’agroalimentaire est particulièrement exposé ?

L’industrie agroalimentaire combine plusieurs facteurs aggravants. La contrainte de temps est absolue : les produits frais n’attendent pas. Un arrêt de production de quelques heures peut signifier des tonnes de matières premières perdues, des commandes non honorées, des pénalités de la grande distribution.

L’agro est devenue une cible prioritaire des cyberattaquants. Le Food and Ag-ISAC a recensé 84 attaques ransomware significatives entre février et avril 2025. Les attaques sur Marks & Spencer et Co-op au Royaume-Uni ont montré que même les grands acteurs sont vulnérables, avec des rayons vides et des commandes en ligne gelées. La directive NIS2 place désormais une grande partie du secteur dans les entités essentielles ou importantes, avec des obligations de sécurité renforcées.

Et le maillon faible, c’est souvent ce PC d’atelier que tout le monde a oublié. L’attaquant ne vise pas forcément l’ERP ou le SCADA. Il vise le point d’entrée le plus facile. Et un PC sans EDR sur le réseau de production, c’est une porte ouverte.

Plan d’action : 5 mesures concrètes et proportionnées

Le sujet des PC industriels sans EDR ne se règle pas avec un projet de transformation à six mois. Il faut des mesures pragmatiques, applicables rapidement, sans perturber la production. Voici ce que nous avons mis en place.

1. Inventaire et cartographie des postes OT exposés

Première étape indispensable : savoir exactement combien de PC non gérés par l’IT existent dans les ateliers, ce qu’ils pilotent, sur quel réseau ils sont connectés, quelle version de Windows ils exécutent. Dans notre cas, nous avons découvert 14 postes « fantômes » répartis sur trois sites de production. Certains étaient encore sous Windows 7. L’inventaire a été réalisé conjointement avec les responsables de production et la maintenance, car ces postes ne figuraient dans aucun référentiel IT.

2. Segmentation réseau immédiate

Action prioritaire : isoler ces PC du réseau bureautique. Un PC d’atelier qui pilote une imprimante d’étiquettes n’a aucune raison d’avoir accès à Internet ou au réseau d’entreprise. Nous avons mis en place des VLAN dédiés par ligne de production avec des règles de firewall strictes. Le PC ne communique qu’avec l’imprimante et le serveur de données d’étiquetage. Rien d’autre.

3. Déploiement d’un EDR compatible OT

Contrairement à une idée reçue, il existe désormais des EDR capables de fonctionner sur des postes industriels, y compris sous Windows 7 ou XP. Des solutions comme FortiEDR ou TEHTRIS supportent les systèmes legacy avec une empreinte légère qui ne perturbe pas les processus de production. Le déploiement se fait poste par poste, en coordination avec la production, sur des créneaux de maintenance planifiés.

4. Mise en place d’un plan de continuité d’étiquetage

Un RSSI qui connaît le terrain sait qu’on ne peut pas promettre le risque zéro. Il faut donc un plan B. Nous avons mis en place un dispositif de secours : une imprimante d’étiquettes autonome préconfigurée, avec un PC de backup isolé et des modèles d’étiquettes prêt à l’emploi. En cas de compromission du poste principal, la production peut basculer en moins de 15 minutes.

5. Intégration de l’OT dans la gouvernance cyber

Dernière mesure, et la plus structurante sur le long terme : intégrer officiellement les équipements OT dans le périmètre de la cybersécurité. Les PC d’atelier doivent figurer dans le référentiel des actifs, avoir un responsable identifié, être inclus dans les campagnes de patching et les audits de sécurité. La directive NIS2 l’exige désormais explicitement pour les entités du secteur agroalimentaire.

Ce qu’il faut retenir

Une imprimante d’étiquettes n’est pas un gadget. Dans l’agroalimentaire, c’est un équipement critique dont dépend la capacité à expédier. Et le PC qui la pilote est souvent le maillon le plus faible de toute l’infrastructure. Sans EDR, sans patching, sans segmentation, c’est une invitation ouverte pour n’importe quel attaquant.

Le sujet n’est pas technique, il est organisationnel. C’est la zone grise entre l’IT et la production qui crée le risque. Tant que ces postes restent dans l’angle mort de la cybersécurité, ils resteront la cible la plus facile pour arrêter une 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