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.

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.

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

CyberLead met à disposition en mode béta une plateforme de ressources opérationnelles pour les professionnels de la cybersécurité : plus de 150 documents structurés, templates RSSI, régulations décryptées, guides ANSSI et ISO, fiches autorités, retours d’expérience.

Un accès unique, gratuit, sans engagement.

Accéder à la plateforme

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

Afin de faire connaitre CyberLead, dont je suis le CEO , j’ai conçu le Kit RSSI avec un ensemble de templates et documents issus de mon expérience de RSSI dans des structures de différentes tailles et différentes maturités. Chaque livrable est pensé pour être utilisé en situation réelle : gouvernance, conformité, projets et opérations.

Kit RSSI

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 Kit RSSI CyberLead inclut une grille de sélection des outils de cartographie OT et une checklist de déploiement de la surveillance passive. Vous voulez évaluer votre surface d’attaque OT sans risque et savoir quels équipements sont réellement exposés? Prenez rendez-vous, on fait le point ensemble.

Kit RSSI

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

Afin de faire connaitre CyberLead, dont je suis le CEO , j’ai conçu le Kit RSSI avec un ensemble de templates et documents issus de mon expérience de RSSI dans des structures de différentes tailles et différentes maturités. Chaque livrable est pensé pour être utilisé en situation réelle : gouvernance, conformité, projets et opérations.

Kit RSSI

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

Afin de faire connaitre CyberLead, dont je suis le CEO , j’ai conçu le Kit RSSI avec un ensemble de templates et documents issus de mon expérience de RSSI dans des structures de différentes tailles et différentes maturités. Chaque livrable est pensé pour être utilisé en situation réelle : gouvernance, conformité, projets et opérations.

Kit RSSI

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.

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

Partager

Après une année d’utilisation sur le terrain et plus de 1400 organisations à l'avoir récupéré, le Kit RSSI évolue. La V3 ne correspond pas à une mise à jour documentaire mais plutôt à un changement d’objectif.

Ma vision est de faire de ce kit la référence du marché et de le rendre indispensable à tout RSSI.

Il repose sur trois principes :

1️⃣ Des schémas compréhensibles et partageables

Chaque thématique s’appuie sur des processus “master”.
Ils permettent d’expliquer clairement les rôles et les enchaînements aux équipes internes, y compris non techniques.

2️⃣ Des documents opposables

Les livrables sont conçus pour tenir face à un grand groupe, un partenaire, un auditeur ou une autorité.
Ils structurent la fonction plutôt que de simplement répondre à une exigence.

3️⃣ Du pilotage réel

Chaque sujet intègre ses tableaux de suivi opérationnels.
L’objectif est de suivre les actions, prioriser et inscrire la cybersécurité dans la durée.

Je vous propose un échange court pour

Nous vous proposons un court échange pour :

• Vous présenter et vous remettre les nouveautés du kit

• Vous partager nos succès

• Partager les nouveautés cyber pour vous accompagner en 2026

Pour rappel le kit contient

• Cartographie: Liste Application SSO, Liste des applications critiques, Liste des solutions de cybersécurité
  ‍

• Risques & conformités: Analyse de risques organisationnelle, Exigences cybersécurité, Référentiels & exigences de conformité
  ‍

• Politiques: PSSI, PCA / PCI, Politique de sensibilisation, Politique d’intégration de la sécurité dans les projets, Politique de gestion des fournisseurs & tiers, Politique de gestion des incidents, Politique de gestion des vulnérabilités
  ‍

• Sensibilisation: Brief de sensibilisation, Rapport de test phishing, Suivi des campagnes de sensibilisation
  ‍

• Analyse de risques projet: Analyse de risques projet, Liste des projets cyber, Security User Stories
  ‍

• Évaluation sous-traitant: Évaluation cybersécurité sous-traitant, Questionnaire cybersécurité, Plan d’Assurance Sécurité, Liste des tiers / sous-traitants
  ‍

• Dérogations: Formulaire de dérogation cybersécurité, Plan / suivi des dérogations
  ‍

• Incidents: Main courante incident, Supports de gestion de crise cyber
  ‍

• Vulnerability Management: Politique de gestion des vulnérabilités, Fiche de remédiation
  

• Pilotage: Budget cybersécurité, Roadmap, Dashboard cybersécurité
  

• Sécurité OT: PSSI OT, Évaluation cybersécurité OT (site), DEX / retour d’expérience OT
  

• Sécurité produit: Security User Stories produit, Common Product Security, Cyber Value Proposal

N’hésitez pas à partager ce post à tous professionnels de la cybersécurité !

Partager

Contexte

Dans les transports, il est fréquent de voir des voyageurs laisser leur téléphone ou leur ordinateur portable sans aucune protection. Écran visible, session ouverte, documents sensibles affichés. Données personnelles, informations professionnelles, parfois très critiques. La scène est banale, presque devenue normale. Pourtant, d’un point de vue cybersécurité, c’est une exposition directe au risque, souvent sous-estimée par la personne concernée.

Face à ce type de situation, la réaction n’est pas évidente. En tant que professionnels sensibles à la cybersécurité, on voit le risque immédiatement, mais on ne sait pas toujours comment agir. Publier un post sur LinkedIn permet de se soulager, pas de protéger la personne en face. Et surtout, cela ne règle rien sur le moment, là où l’exposition au risque est immédiate.

Problème

Parfois, on voit tout de suite que le poste a l’air sensible. Un PowerPoint financier ouvert, une signature d’exécutif visible, un document clairement professionnel. D’autres fois, c’est plus flou. Mais l’intuition est là. Quelque chose n’est pas anodin. Et c’est précisément cette incertitude qui gêne : on sent que ça peut être critique, sans être totalement sûr.

Le vrai frein, ce n’est pas le risque technique, c’est l’humain. Aborder une personne inconnue fait hésiter. On anticipe la réaction : l’agacement, l’ironie, parfois l’insulte. On se dit que ce n’est peut-être pas notre rôle, que l’on va déranger, ou se faire remettre à sa place. Cette peur est réelle, et elle suffit souvent à nous faire détourner le regard.

Aborder une personne inconnue, ça ne se fait pas vraiment. En tout cas, c’est ce que l’on nous a appris. Dans un train, un avion, une salle d’attente, chacun reste dans sa bulle. Rompre cette distance sociale paraît déplacé, presque suspect. Même avec une bonne intention, on craint d’être perçu comme intrusif. Cette norme implicite pèse lourd et renforce l’inaction, même quand le risque est sous nos yeux.

Décision clé

Décider de dépasser ses propres peurs pour aider une personne manifestement exposée, sans jugement ni posture moralisatrice, simplement pour réduire un risque immédiat auquel elle ne prête pas forcément attention.

Étapes

1. Évaluer rapidement la criticité de la situation

La première étape consiste à observer et à évaluer, sans précipitation. Tous les postes ouverts ne présentent pas le même niveau de risque. Un ordinateur lié à une entreprise sensible, manipulant visiblement des documents professionnels, ne se traite pas comme un usage personnel banal. Il ne s’agit pas d’espionner, mais de contextualiser. Cette évaluation rapide permet d’ajuster la suite : intervenir ou non, et surtout comment. C’est un arbitrage discret, souvent intuitif, mais nécessaire pour éviter une réaction disproportionnée… ou une inaction regrettable.

2. Trouver un point d’accroche humain

Si l’on décide d’agir, trouver un point d’accroche humain aide énormément. Un prénom visible dans une signature d’email, sur un réseau partagé ouvert sur le smartphone, ou parfois via une carte laissée à côté du poste permet d’engager la discussion. Utiliser le prénom crée une connexion immédiate, presque comme si l’on s’adressait à une connaissance. La réaction la plus fréquente est un flottement, un “pardon, on se connaît ?”, qui ouvre naturellement l’échange sans agressivité ni posture de donneur de leçon.

3. Aborder sans agresser, laisser l’autre réagir

Une fois le contact établi, l’important est la manière d’aborder la personne. Se présenter simplement, expliquer que l’on travaille dans l’informatique ou la cybersécurité, puis partager son ressenti : une inquiétude sincère pour son poste. Pas d’accusation, pas d’injonction. On parle de soi, pas de ce que l’autre “fait mal”. Ensuite, on se tait. On laisse la personne réagir, parfois minimiser, parfois remercier, parfois être surprise. Cette respiration dans l’échange évite l’escalade et maintient une interaction humaine, respectueuse, même dans un espace public.

4. Éviter la posture de donneur de leçon

Pour que l’échange reste acceptable, il est important de ne pas se placer en position de sachant. Une approche efficace consiste à parler de ses propres contraintes : dans mon entreprise, on nous demande de verrouiller nos postes ; on nous sensibilise beaucoup à ce sujet. Cela déplace la discussion vers une pratique professionnelle, plutôt qu’un reproche personnel. La personne en face peut alors projeter la situation sur son propre contexte, sans se sentir jugée. L’objectif n’est pas de corriger, mais de partager un réflexe qui peut être utile.

5. Faire appel à des pratiques connues, pas à des règles abstraites

À ce stade, l’échange peut rester très simple. Évoquer des pratiques courantes dans les entreprises aide à normaliser le message : verrouiller son poste, activer un écran de confidentialité, éviter de laisser des documents sensibles visibles. Ce sont des gestes concrets, connus, qui ne nécessitent pas de discours technique. L’idée n’est pas d’expliquer une politique de sécurité, mais de rappeler des réflexes largement partagés dans de nombreuses organisations. Cela permet à la personne de se repositionner sans perdre la face.

6. Agir avec bienveillance si la situation l’impose

Si la personne s’absente longtemps et que le risque est manifeste, agir avec bienveillance peut être la meilleure option. Verrouiller simplement le poste, sans fouiller ni toucher aux contenus, permet de réduire immédiatement l’exposition. Ce geste n’est pas une prise de pouvoir, mais une aide discrète. Il suppose évidemment une intention claire et honnête : protéger, pas contrôler. Dans bien des cas, ce type d’attention est perçu positivement au retour de la personne, comme un service rendu plutôt qu’une intrusion.

Erreurs à éviter

1. Partager des captures d’écran sur les réseaux

   Partager une photo ou une capture d’écran d’un poste visible dans les transports, est une mauvaise idée. Cela expose potentiellement la personne, l’entreprise, et déplace le problème sans le résoudre. La recherche de visibilité ou de validation sociale ne protège personne. Elle peut au contraire aggraver la situation et créer des effets juridiques ou humains non maîtrisés.

2. Croiser la personne de manière frontale ou agressive

   Interpeller une personne inconnue de façon brutale ou insistante est contre-productif. Même avec une bonne intention, la démarche peut être mal perçue, générer de la méfiance ou une réaction de rejet. On ne connaît ni le contexte, ni l’état d’esprit de la personne. Une approche trop directe peut fermer toute possibilité de dialogue et rendre la situation plus tendue qu’elle ne l’était initialement.

3. Laisser l’agacement prendre le dessus

   Il arrive, surtout en fin de semaine ou après une période tendue, de voir des professionnels de la cybersécurité perdre patience. Hausser le ton, s’énerver, faire une remarque sèche n’aide jamais. Cela peut rapidement dégénérer, attirer l’attention, voire créer un incident inutile. Même si la situation semble absurde ou répétitive, garder son calme reste essentiel.

Conclusion

Dépasser sa timidité n’est pas naturel, surtout dans un espace public. Pourtant, face à un comportement sans filtre de confidentialité, ne rien faire n’est pas neutre. Le risque est réel, immédiat, et souvent invisible pour la personne concernée. Aider, avec tact et respect, n’est ni intrusif ni moralisateur. C’est un geste professionnel, presque citoyen. La mauvaise pratique n’est pas de laisser un écran ouvert ; la pire serait de voir le risque et de détourner les yeux par confort ou par peur de déranger.

Vous voyez un post LinkedIn sur le sujet , partagez cet article en commentaire !

Partager

Contexte

Les relations conflictuelles entre un RSSI et son manager sont loin d’être marginales. Je les ai vues se répéter, dans des contextes différents, avec des profils pourtant compétents et engagés. Ce n’est pas toujours explosif, mais souvent latent, usant, installé dans la durée. Et quand cette tension s’installe, elle finit presque toujours par produire le même effet : un RSSI qui s’épuise, puis qui part.

Ce type de relation dégradée a une conséquence directe : un turnover élevé des RSSI. Les départs s’enchaînent, parfois sans bruit, parfois dans la crispation. Pour l’organisation, l’impact est lourd : perte de continuité, stratégies cyber abandonnées en cours de route, crédibilité affaiblie auprès des équipes et des partenaires. À force de changements, la cybersécurité devient instable, alors même qu’elle devrait s’inscrire dans le temps long.

Problème

Le RSSI est souvent investi d’une forme de « cause supérieure ». Il porte la cybersécurité comme une mission, parfois au-delà des besoins réels et immédiats de l’organisation. Cet engagement, sincère et professionnel, peut devenir désaligné. Un de mes managers parlait de surqualité : faire trop bien, trop vite, trop fort, sans toujours tenir compte du contexte business, des priorités ou de la maturité réelle de l’entreprise.

Le RSSI évolue dans un univers fortement normé. Les référentiels de l’ANSSI, les normes et standards structurent son quotidien et deviennent naturellement ses points d’appui. Le risque, à terme, est de s’y enfermer. Ces cadres sont précieux, mais lorsqu’ils ne sont pas contextualisés, ils peuvent rigidifier la posture du RSSI et créer un décalage avec une organisation qui avance, elle, sous des contraintes très différentes.

Le RSSI est souvent très solide techniquement, mais beaucoup moins à l’aise sur le terrain de la communication. Expliquer un risque, défendre une position, adapter son discours à des non-experts n’est pas inné. Or, la cybersécurité repose largement sur ces capacités. Sans accompagnement, ce décalage crée des incompréhensions, parfois des tensions, et renforce l’isolement du RSSI dans l’organisation.

Décision clé

Plutôt que de corriger ou de contraindre, la décision est d’accompagner le RSSI dans la navigation de ces difficultés, en partageant de l’expérience concrète, du recul managérial et une lecture plus large des contraintes de l’organisation.

Étapes

1. Installer une relation de confiance réelle

   La première étape consiste à construire une relation de confiance profonde avec le RSSI, comme on le ferait avec n’importe quel autre collaborateur clé. Cela paraît évident, mais c’est souvent négligé. Le RSSI est perçu comme un rôle, une fonction de contrôle, rarement comme une personne. Sans espace d’échange sécurisé, il s’isole, durcit ses positions et perd en lucidité. La confiance permet au contraire d’exprimer les doutes, d’ajuster les priorités et de désamorcer les tensions avant qu’elles ne deviennent structurelles.

2. Contextualiser le niveau de cybersécurité attendu

   Il est essentiel d’aider le RSSI à remettre le niveau de cybersécurité dans son contexte réel. Tout n’a pas vocation à être sécurisé au plus haut niveau immédiatement, même si, sur le papier, ce serait l’idéal. L’entreprise avance avec des contraintes budgétaires, humaines, opérationnelles. Sans cette contextualisation, le RSSI porte une pression permanente, souvent irréaliste. Le rôle du manager est d’aider à prioriser dans le temps, à accepter des trajectoires progressives et à transformer une vision idéale en un plan atteignable.

3. Utiliser les cadres sans s’y enfermer

   Les référentiels de l’ANSSI et les normes sont des outils puissants pour structurer une démarche cybersécurité. Ils apportent un langage commun, une crédibilité et un cadre rassurant. Le rôle du manager est d’aider le RSSI à les utiliser comme des leviers, pas comme des contraintes absolues. Il s’agit de contextualiser le niveau d’exigence à la réalité de l’entreprise, à son secteur et à sa maturité. Bien employés, ces cadres aident l’organisation ; appliqués mécaniquement, ils peuvent créer des blocages durables.

4. Échanger en commun avec des pairs

   L’enjeu n’est pas d’envoyer le RSSI seul discuter avec ses pairs, mais d’y aller ensemble, en binôme manager–RSSI. Ces échanges communs permettent de partager une lecture alignée des pratiques du secteur, des niveaux d’exigence réellement appliqués et des arbitrages faits ailleurs. Ils évitent aussi les malentendus internes : chacun entend la même chose, au même moment. Cette démarche renforce la cohérence managériale et ancre la stratégie cybersécurité dans une réalité partagée.

5. Intégrer la cybersécurité dans la communication de la DSI

   La cybersécurité ne peut pas rester cantonnée à des échanges techniques ou à des alertes ponctuelles. Elle doit faire partie intégrante du plan de communication de la DSI. Le manager a un rôle clé pour aider le RSSI à structurer ce discours : messages simples, réguliers, compréhensibles, orientés enjeux métiers. Cette intégration permet de sortir la cybersécurité d’une posture défensive et de la repositionner comme un sujet transverse, porté collectivement.

6. Partager aussi ses erreurs de manager

   Accompagner un RSSI passe aussi par une forme d’humilité managériale. Partager ses propres erreurs de communication, ses mauvais arbitrages passés ou ses incompréhensions permet de rééquilibrer la relation. Cela montre que la difficulté à bien communiquer en cybersécurité n’est pas un défaut individuel, mais un sujet complexe. Cette posture ouvre un espace d’apprentissage mutuel, désamorce la pression et aide le RSSI à progresser sans se sentir jugé.

Erreurs à éviter

1. Laisser la relation se dégrader dans le temps

Laisser une relation tendue s’installer durablement entre un manager et son RSSI est une erreur lourde de conséquences. La cybersécurité nécessite de la continuité et de la confiance. Quand le conflit devient latent, les décisions se crispent, les alertes sont mal perçues et le RSSI finit par se désengager.

2.Ne pas accompagner la montée en compétence

Penser qu’un RSSI très qualifié n’a pas besoin d’accompagnement est une erreur courante. La technique ne suffit pas. La capacité à convaincre, à prioriser et à adapter son discours est essentielle. Sans soutien, le RSSI se retrouve seul face à des attentes contradictoires.

3.Isoler le RSSI de la communication globale de la DSI

Exclure le RSSI de la stratégie de communication de la DSI est une erreur fréquente. La cybersécurité est alors perçue comme un sujet à part. En l’intégrant au discours global, on aligne les messages et on renforce la crédibilité de la démarche cyber.

Conclusion

Le RSSI, malgré un profil souvent très qualifié, a lui aussi besoin d’accompagnement. Sa fonction est exigeante, exposée, parfois isolante. Bien le manager ne consiste pas à brider son engagement, mais à l’aider à s’inscrire durablement dans la réalité de l’organisation. Quand la relation est saine, contextualisée et alignée, la cybersécurité gagne en efficacité, en stabilité et en crédibilité sur le temps long.

Ressources CyberLead

Prochainement

Nous sommes fier de vous annoncer que notre kit RSSI V3 sera bientôt disponible. Notre vision est claire : Faire de ce kit la référence du marché et qu’il devienne un indispensable à tout RSSI.

Si l’article vous a plu, n’hésitez pas à le faire circuler dans votre réseau : un simple partage nous aide beaucoup.

Partager

Contexte

Tout démarre par une fraude assez classique : des escrocs utilisent le nom de l’entreprise pour arnaquer des victimes autour de fausses places de parking. Rien de très sophistiqué, juste de l’usurpation bien rodée. Le problème, c’est que le nom de l’entreprise circule, et que très vite, la frontière entre fraude externe et responsabilité interne devient floue aux yeux des victimes.

La victime ne se retourne pas contre l’escroc, mais contre l’entreprise. Une plainte est déposée, avec l’espoir de récupérer l’argent perdu. Le raisonnement est simple, presque automatique : si le nom de l’entreprise a été utilisé, alors elle est forcément responsable. À ce stade, le débat glisse rapidement de la fraude vers la recherche d’un responsable solvable.

Très vite, la cybersécurité est invoquée dans la plainte. Pas forcément par mauvaise foi, mais parce que c’est ce qui fait sens pour la victime. Si une fraude a été possible, c’est qu’il y a eu, quelque part, un défaut de protection. Derrière la démarche, il y a surtout une attente très humaine : comprendre ce qui s’est passé et tenter de récupérer l’argent perdu.

Problème

Le premier malaise vient du niveau réel de cybersécurité de l’entreprise. Il n’est pas catastrophique, mais clairement perfectible. Rien d’exceptionnel, mais pas non plus de quoi être totalement serein face à une mise en cause externe. Quand une plainte arrive, ces zones grises remontent immédiatement à la surface, et chaque approximation passée devient soudain beaucoup plus visible.

Très vite, l’analyse technique montre qu’on est face à une fraude classique. Usurpation d’identité, faux supports, détournement de confiance : rien n’indique une compromission du système d’information ou une fuite de données. Le lien avec la cybersécurité est donc indirect, voire inexistant. Mais dans l’esprit de la victime, cette nuance importe peu, ce qui complique fortement la gestion du dossier.

Malgré tout, une attente claire émerge : démontrer que l’entreprise dispose d’un certain niveau de cybersécurité. Pas pour prouver l’absence de fraude, mais pour établir qu’elle n’a pas été négligente. La demande est implicite mais lourde : produire des éléments tangibles, même imparfaits. À ce moment-là, la cybersécurité devient un sujet de preuve, presque de défense.

Étapes

1. Vérifier les éléments concrets de la plainte
   Avant toute réaction, il faut vérifier. Relire les faits, analyser les pièces fournies, comprendre précisément le scénario décrit. Trop souvent, la plainte repose sur des éléments partiels ou émotionnels. Ce travail de vérification n’est pas une remise en cause de la victime, mais une étape indispensable avant toute action technique ou juridique.

2. Chercher une éventuelle compromission ou fuite de données
   Logs, alertes, historiques d’accès : tout est passé en revue. Aucun indice ne permet d’établir une compromission ou une fuite de la base de données. Ce point est essentiel, même s’il ne clôt pas le dossier. Il permet au moins d’écarter le scénario le plus grave et le plus anxiogène pour l’entreprise.

3. Recertifier les comptes d’administration, par précaution
   Dans le doute, une re certification complète des comptes d’administration est lancée, techniques comme fonctionnels. C’est probablement surdimensionné par rapport au risque réel, mais assumé. Lorsqu’une plainte est en jeu, mieux vaut fermer les angles morts que découvrir après coup un oubli évitable.

4. Retrouver le dernier audit de sécurité disponible
   Le dernier audit date de trois ans. Ce n’est pas idéal, clairement. Mais c’est un élément concret. Il démontre qu’une démarche a existé, même imparfaite. En situation de mise en cause, l’absence totale de traces est bien plus difficile à défendre qu’un dispositif perfectible mais documenté.

5. Lister les mesures de cybersécurité communicables
   Un inventaire sobre et factuel est réalisé : mesures existantes, contrôles en place, actions en cours. Pas de promesses, pas d’enrobage. Juste des faits, communicables et non préjudiciables. L’objectif n’est pas d’impressionner, mais de montrer un minimum de sérieux et de bonne foi.

6. Faire un point avec la direction juridique
   À ce stade, la main doit passer au juridique. Les constats techniques sont partagés, les limites expliquées. La cybersécurité apporte les faits, mais ne se substitue pas à l’analyse légale. Cette transition est essentielle pour éviter les réponses maladroites ou juridiquement risquées.

7. Laisser le juridique gérer la suite
   Une fois les éléments transmis, le rôle du RSSI s’arrête. Le travail est fait. Insister davantage n’apporte rien, si ce n’est du stress inutile. Savoir s’arrêter est aussi une compétence clé en cybersécurité, surtout quand le sujet a basculé dans un autre registre.

Recommandations

Des traces écrites, c’est essentiel

Audits, comptes rendus, décisions formalisées : ce qui est écrit protège. À l’inverse, une absence totale de traces devient très difficile à défendre, même avec de bonnes pratiques techniques. La cybersécurité se juge aussi sur sa capacité à démontrer ce qu’elle fait.

Toujours vérifier la requête

Même quand une plainte semble infondée ou éloignée de la cyber, elle mérite une vérification sérieuse. Vérifier ne signifie pas reconnaître une faute, mais s’assurer qu’aucun angle mort réel n’existe.

Passer par les bons acteurs juridiques

Le RSSI n’est pas avocat. Son rôle est d’apporter des faits techniques clairs, pas d’interpréter la responsabilité légale. Respecter cette frontière protège l’entreprise et la fonction cybersécurité.

Conclusion

Quand une plainte survient, la bonne posture n’est ni la panique ni la justification hâtive. Vérifier, documenter, transmettre. Dans ce type de fraude, la cybersécurité n’est pas toujours la cause, mais elle devient un révélateur de maturité. Avoir des éléments écrits, même imparfaits, fait toute la différence. Le rôle du RSSI est d’apporter des faits, pas des promesses, et de démontrer une démarche responsable et proportionnée. Souvent, cela suffit à remettre le débat à sa juste place.

👉 N’hésitez pas à nous contacter pour discuter de vos projets cybersécurité ou pour obtenir des informations supplémentaires sur Cyberlead.

Echanger avec notre équipe

Si l’article vous a plu, n’hésitez pas à le faire circuler dans votre réseau : un simple partage nous aide beaucoup.

Partager

Contexte

Tout commence par un message du responsable support. Laconique, presque gêné : « On a besoin d’une dérogation pour Netflix… pour le DG. » À ce moment-là, je lève les yeux de mon écran. Pas par surprise, mais parce que je sens déjà l’embrouille arriver. Quand la cybersécurité entre dans une discussion sur Netflix, ce n’est jamais pour de bonnes raisons.

Quelques minutes plus tard, c’est l’assistante du DG qui m’appelle directement. Ton poli, mais urgence très claire : « Est-ce qu’on peut faire une exception pour Netflix ? C’est assez urgent. » Là, le signal est net. Quand l’assistante du DG appelle pour Netflix, ce n’est plus un sujet technique, c’est devenu un irritant au plus haut niveau. Et ça, en cybersécurité, ce n’est jamais anodin.

Le plus ironique dans l’histoire, c’est que je n’ai jamais interdit Netflix. Aucune règle formelle, aucune politique écrite, aucun arbitrage sécurité en ce sens. Pourtant, tout le monde est convaincu que « la cyber » a encore frappé. À ce stade, une chose devient claire : la cybersécurité sert surtout de prétexte commode pour justifier un blocage qui n’a rien à voir avec elle.

Problème

C’est un cas classique : on a utilisé la cybersécurité pour bloquer un usage. Pas parce qu’une analyse de risques sérieuse l’a justifié, mais parce que bloquer, c’est plus simple. La cyber devient alors un parapluie pratique. On s’en sert pour éviter de poser les vraies questions techniques ou opérationnelles. Et, comme souvent, quand ça coince, c’est vers le RSSI que tout le monde se tourne.

Soyons honnêtes deux minutes : est-ce que Netflix est vraiment un risque cyber majeur ? On parle d’un service grand public, massivement utilisé, correctement maintenu, accessible partout. Ce n’est ni un malware exotique ni un shadow IT incontrôlé. Confondre confort, bande passante et cybersécurité, c’est diluer le message. À force de tout appeler « risque cyber », on finit par perdre toute crédibilité sur les vrais sujets.

Et puis, il y a un fait simple qu’on oublie parfois trop vite : c’est le DG. À un moment, c’est lui le patron. La cybersécurité n’est pas au-dessus de la gouvernance de l’entreprise. Elle éclaire, elle alerte, elle propose des cadres, mais elle ne décide pas seule. Utiliser la cyber pour imposer un blocage sans arbitrage explicite, surtout face à la direction générale, c’est se tromper de combat.

Étapes

1. Gérer l’urgence, même si ce n’est pas élégant
   La première chose à faire est d’éteindre l’incendie. Netflix est débloqué temporairement, via une dérogation validée par le DSI. Ce n’est pas très orthodoxe, mais c’est assumé. Quand un sujet arrive jusqu’au DG, la priorité n’est plus de faire de la pédagogie, mais de restaurer le service. La cybersécurité ne gagne rien à s’arc-bouter sur une position rigide dans une situation qui relève clairement de l’urgence opérationnelle.

2. Identifier pourquoi Netflix a été bloqué
   Une fois la pression retombée, il faut comprendre. Qui a bloqué Netflix ? Sur quelle base ? Est-ce un vrai risque cyber identifié ou une règle générique appliquée sans discernement ? Dans ce cas précis, aucune analyse de risques sérieuse n’existe. Juste une décision technique prise « par précaution ». Autrement dit, un blocage par défaut, sans arbitrage ni validation sécurité formelle.

3. Découvrir que le vrai sujet n’est pas la cyber
   En creusant un peu, la réalité apparaît rapidement : le problème n’est pas Netflix, mais la bande passante. Pour éviter de traiter un sujet de capacité réseau, tout a été bloqué. Netflix compris. La cybersécurité a servi d’alibi commode pour masquer un problème d’infrastructure. Classique. Et dangereux, car cela décrédibilise la fonction sécurité auprès des décideurs.

4. Identifier qui a invoqué la cybersécurité comme excuse
   Il faut alors retrouver l’origine de la décision. Non pas pour sanctionner, mais pour comprendre. Quelqu’un a estimé que dire « cyber » ferait passer la pilule plus facilement. Ce réflexe est courant dans les équipes IT : la cybersécurité est perçue comme une autorité abstraite, difficilement contestable. Sauf que lorsque la direction générale est impactée, ce raccourci explose immédiatement.

5. Recentrer le discours sur les vrais risques cyber
   Une discussion s’impose. Calmement. Netflix n’est pas le sujet. Le vrai enjeu, c’est de rappeler ce qu’est un risque cyber, et ce que ce n’est pas. Tout bloquer n’est pas une stratégie. La sécurité n’est pas là pour compenser des faiblesses techniques non traitées ailleurs. À force d’utiliser la cyber comme argument fourre-tout, le message devient inaudible.

6. Faire corriger la justification du blocage
   La règle est revue, mais surtout, la raison invoquée change. On arrête de dire « cybersécurité » quand il s’agit de bande passante ou de qualité de service. Mal nommer un problème empêche de le résoudre correctement. Et expose inutilement le RSSI en première ligne sur des sujets qui ne relèvent pas de son périmètre.

7. Traiter enfin le vrai sujet : la bande passante
   Dernière étape, et pas la moindre : s’attaquer au fond du problème. Analyse des usages, pics de consommation, dimensionnement réseau. C’est moins vendeur que de parler cyber, mais infiniment plus utile. En aidant les équipes à traiter la disponibilité plutôt que de tout bloquer, on évite que la cybersécurité soit instrumentalisée à nouveau pour masquer des choix d’architecture non assumés.

Recommandations

Le patron reste le patron

C’est une réalité simple, mais qu’il faut parfois rappeler. Le DG n’est pas un utilisateur comme les autres. La cybersécurité n’est pas là pour imposer des blocages par principe, surtout sans arbitrage explicite. Elle éclaire les risques, propose des options et s’inscrit dans la gouvernance. Une sécurité efficace sait composer avec la hiérarchie, pas s’y opposer frontalement.

Choisir ses combats cyber

Tout ne mérite pas un combat. En tant que RSSI, il faut savoir où mettre son énergie. Bloquer Netflix n’est pas stratégique quand des sujets bien plus critiques attendent : identités, sauvegardes, exposition cloud, incidents réels. À force de se battre sur des usages marginaux, on s’épuise et on brouille les priorités. La cybersécurité gagne en impact quand elle se concentre sur l’essentiel.

Passer les messages aux équipes IT

Il est indispensable d’aider les équipes IT à arrêter de tout bloquer « au nom de la cybersécurité ». Ce réflexe est compréhensible, mais dangereux. La cyber ne doit pas devenir un prétexte pour masquer des problèmes de capacité, d’architecture ou de gouvernance technique. Clarifier ce qui relève de la sécurité protège tout le monde. Et surtout, cela évite d’exposer inutilement le RSSI sur des décisions qu’il n’a jamais prises.

Conclusion

Débloquer Netflix pour le DG n’est pas un échec de la cybersécurité. C’est un rappel salutaire. La sécurité n’est pas là pour bloquer par réflexe, ni pour servir d’alibi à d’autres sujets mal traités. Elle est là pour éclairer, arbitrer et aider l’entreprise à fonctionner sans se mentir. En tant que RSSI, savoir gérer ce type de situation, c’est faire preuve de maturité : comprendre la hiérarchie, choisir ses combats et refuser que la cybersécurité soit instrumentalisée. À force de vouloir tout bloquer, on finit par affaiblir le message sur les vrais risques. Et ça, c’est le vrai danger.

👉 N’hésitez pas à nous contacter pour discuter de votre projet cybersécurité ou pour obtenir des informations supplémentaires sur Cyberlead.

Echanger avec notre équipe

Si l’article vous a plu, n’hésitez pas à le faire circuler dans votre réseau : un simple partage nous aide beaucoup.

Partager

Contexte

Cette année, le COMEX a enfin compris que l’IAM n’était pas un sujet technique de plus, mais un pilier de la cybersécurité. Pour moi, ça a été un mélange de soulagement et d’agacement. Soulagement, parce que le message passe enfin. Agacement, parce que cela fait des années que les identités posent problème, dans l’ombre, sans jamais être traitées à la hauteur des risques réels.

Les propositions de remédiation ont été bien accueillies par le COMEX et le CODIR DSI. Trop bien, presque. Présentations claires, plans structurés, priorités assumées : tout le monde acquiesce. À ce moment-là, on te regarde comme celui qui va “prendre l’IAM”. Et intérieurement, le piège apparaît clairement : validation ne veut pas dire appropriation.

Très vite, le constat s’impose : tu es le seul à vraiment comprendre l’IAM. Pas par ego, mais par réalité terrain. Les équipes voient des outils, des tickets, des workflows. De ton côté, tu vois les chaînes d’identité, les dépendances, les angles morts. Progressivement, l’IAM devient ton sujet. Celui que tout le monde te renvoie, parce que c’est plus simple que de s’en saisir collectivement.

Problème

La bande passante d’un RSSI est déjà saturée. Vulnérabilités, incidents, conformité, fournisseurs, audits, comités… tout arrive en même temps. Ajouter l’IAM à la pile, c’est nécessaire, mais coûteux. Car l’IAM n’est pas un petit chantier : c’est long, ingrat, et chronophage. Le prendre “en plus”, sans arbitrage clair, mène rapidement à l’épuisement.

L’IAM dépasse largement la cybersécurité. C’est un sujet transverse, profondément organisationnel. Il touche les métiers, l’IT, les RH, parfois la finance. Chaque décision impacte des usages, des habitudes, des équilibres internes. Très vite, tout remonte vers le RSSI : arbitrages, conflits, exceptions. On part d’un sujet d’identités, on se retrouve à gérer des frictions structurelles.

Et la question finit par surgir, frontalement : jusqu’où aller ? Où s’arrêter ? À partir de quand ce n’est plus le rôle du RSSI ? L’IAM peut absorber des mois entiers si aucune limite n’est posée. Plus on avance, plus on en demande. Sans cadre clair, la remédiation IAM devient un puits sans fond, et le RSSI glisse vers un rôle de “responsable IAM par défaut”, au détriment de sa posture stratégique.

Étapes

1. Accepter d’initier, pas d’exécuter
   La première étape consiste à poser une règle simple : le RSSI initie et cadre, mais n’exécute pas à la place des autres. Les actions opérationnelles doivent être portées par les équipes métiers et IT concernées. Ce n’est ni une fuite ni un désengagement, c’est une condition de survie. Sans cette ligne rouge, le RSSI devient rapidement le point de blocage de toute l’organisation.

2. Cartographier l’IAM réel, pas celui des slides
   Il faut ensuite mettre les choses à plat. Cartographier l’IAM tel qu’il existe réellement : briques en place, manques, contournements, héritages historiques. Cet exercice est souvent inconfortable, car il met en lumière des incohérences accumulées dans le temps. Mais sans cette cartographie honnête, toute discussion sur la remédiation repose sur une illusion.

3. Lister les applications sous SSO et hors SSO, avec leur criticité
   L’inventaire des applications révèle souvent la vraie dette. Applications critiques hors SSO, mots de passe partagés, comptes génériques, accès jamais revus. Classer ces applications par criticité devient indispensable, mais aussi politiquement sensible. Chaque application non intégrée raconte une histoire de compromis passés. Et plus la liste s’allonge, plus il devient clair que l’IAM est un héritage organisationnel mal digéré.

4. Formaliser une fiche de mise sous SSO avec M365 / Azure AD
   À ce stade, il faut passer au concret. Avec le responsable M365 qui gère Azure AD, une fiche simple de mise sous SSO est formalisée : prérequis, impacts, responsabilités, délais réalistes. Cet outil évite les débats sans fin et sert de filtre objectif. Chaque application candidate au SSO passe par ce cadre. Cela ne règle pas tout, mais cela remet de la discipline.

5. Sensibiliser sans moraliser
   La sensibilisation n’a pas vocation à donner des leçons. L’objectif est de reconnecter les équipes métiers et IT à la réalité opérationnelle. Le SSO est présenté comme un levier : moins d’incidents, moins de friction, moins de charge inutile. En parlant d’usages et d’impacts concrets, l’adhésion est plus naturelle. Et surtout, cela évite de transformer l’IAM en combat idéologique.

6. Suivre l’exécution dans la durée
   Sans suivi, le SSO reste une bonne intention. Le rôle du RSSI est d’assurer la continuité : relances, arbitrages, clarification des blocages. Ce n’est pas spectaculaire, mais c’est déterminant. Chaque application mise sous SSO est une victoire silencieuse. Chaque report non traité recrée de la dette. L’IAM progresse rarement par grands plans, mais par une accumulation de pas tenus dans le temps.

7. Travailler les processus JML : Joiner, Mover, Leaver
   Enfin, il faut attaquer le cœur du problème : les processus JML, c’est-à-dire l’entrée, la mobilité et la sortie des collaborateurs. Comptes créés trop tôt, supprimés trop tard, droits jamais ajustés lors des mutations internes. Rien de spectaculaire, mais une accumulation de risques silencieux. Sans JML clair, la dette d’identités se reconstitue en permanence, quels que soient les efforts réalisés ailleurs.

Recommandations

1. Sur l’IAM, tout ne peut pas être porté par une seule fonction. Le sujet est tentant car il touche à de nombreux domaines connexes, mais le risque est réel de diluer le rôle du RSSI. L’enjeu consiste à poser un cadre clair, identifier les responsabilités et s’assurer que chaque équipe prenne sa part. Cette capacité à structurer et déléguer est essentielle pour rester efficace dans la durée.

2. Chercher des quick wins est souvent plus efficace que viser d’emblée la perfection. Le SSO, la MFA ou les revues d’accès périodiques apportent des bénéfices rapides et visibles. Ces victoires installent une dynamique positive et montrent que l’IAM peut produire de la valeur sans devenir un chantier interminable. Elles créent aussi la confiance nécessaire pour aborder ensuite des sujets plus profonds.

3. L’IAM gagne à être expliqué comme un socle. Sensibiliser les équipes métiers et IT consiste à montrer les impacts concrets : incidents évités, accès simplifiés, réduction des frictions. Lorsqu’il est compris comme un facilitateur de la cybersécurité globale, l’IAM s’inscrit plus naturellement dans les pratiques quotidiennes, au-delà des projets ponctuels.

Conclusion

L’IAM est un sujet central, mais aussi l’un des plus piégeux pour un RSSI. Parce qu’il touche à tout, il peut vite devenir envahissant et détourner de la vision stratégique attendue du rôle. La valeur du RSSI ne réside pas dans l’exécution de chaque remédiation IAM, mais dans sa capacité à cadrer, prioriser et faire travailler l’organisation ensemble. Aider, impulser, structurer : oui. Tout porter soi-même : non. Poser ces limites n’est pas un renoncement, c’est une condition pour rester efficace et crédible dans la durée.

👉 N’hésitez pas à nous contacter pour discuter de votre projet cybersécurité ou pour obtenir des informations supplémentaires sur Cyberlead.

Echanger avec notre équipe

Si l’article vous a plu, n’hésitez pas à le faire circuler dans votre réseau : un simple partage nous aide beaucoup.

Partager

Contexte

L’année 2026 marque un tournant pour de nombreuses organisations en France. La directive NIS2 sort progressivement du cadre théorique pour entrer dans une phase d’application concrète. Audits, exigences de gouvernance et responsabilités renforcées commencent à se matérialiser. Pour les RSSI, le sujet n’est plus “à anticiper”, mais bien à piloter opérationnellement, avec des attentes fortes de la part des directions.

En parallèle, les systèmes d’information se transforment à une vitesse inédite sous l’effet de l’IA. Assistants, copilotes, agents autonomes : les usages se multiplient, souvent sans cadre clair. Les métiers avancent vite, parfois trop vite pour la sécurité. Le SI devient plus diffus, plus dynamique, et beaucoup moins prévisible qu’il ne l’était encore il y a quelques années.

Dans le même temps, les menaces cyber s’industrialisent. Les attaques sont mieux outillées, plus rapides à lancer et plus faciles à reproduire. L’IA permet d’automatiser des phases entières d’attaque, du repérage à l’exploitation. Ce qui relevait autrefois d’acteurs très spécialisés devient accessible à un plus grand nombre, augmentant mécaniquement la pression sur les équipes de défense.

Problème

La directive NIS2 introduit de nouvelles exigences de gouvernance, de pilotage et de justification. Pour beaucoup d’entreprises, la pression redescend directement sur les RSSI, chargés de démontrer la conformité dans des délais contraints. Le rôle évolue : moins d’intention, plus de preuves. Chaque décision doit désormais être formalisée, tracée et défendable face aux auditeurs et aux autorités.

Les usages de l’IA explosent dans les entreprises, bien au-delà des projets officiellement encadrés. Agents professionnels, outils personnels, automatisations bricolées : tout se mélange. Les frontières entre IT, shadow IT et usages métiers deviennent floues. Pour le RSSI, cela bouleverse les pratiques de sécurité existantes, conçues pour des systèmes plus statiques et plus prévisibles que ces nouveaux environnements pilotés par l’IA.

L’IA change aussi le profil des attaquants. Des acteurs peu expérimentés deviennent rapidement efficaces grâce à des outils automatisés capables de générer du code, des scénarios d’attaque ou des campagnes crédibles. Des incidents auparavant mineurs peuvent ainsi dégénérer en crise majeure. Cette montée en compétence rapide rend la détection plus complexe et réduit fortement le droit à l’erreur pour les équipes de sécurité.

Proposition d’étapes

1. La première étape pour le RSSI en 2026 consiste à mettre à jour l’analyse de risques cybersécurité en intégrant explicitement l’IA. Les scénarios classiques ne suffisent plus : agents autonomes, modèles externes, dépendances fournisseurs et usages métiers doivent être pris en compte. Il ne s’agit pas de refaire un document pour la forme, mais d’actualiser réellement la compréhension des risques. Cette analyse sert de socle à toutes les décisions suivantes : priorités, budgets, arbitrages et discours managérial. Sans ce travail de fond, le reste devient vite décoratif.

2. Une fois l’analyse de risques mise à jour, elle doit être présentée formellement au COMEX. L’enjeu n’est pas le débat technique, mais la preuve de gouvernance. Ordre du jour, supports validés, compte rendu et décisions actées : tout doit être tracé. En 2026, avec la NIS2, il ne suffit plus d’avoir travaillé le sujet, il faut démontrer qu’il a été porté au plus haut niveau. Cette formalisation protège le RSSI autant que l’entreprise, en établissant clairement qui a été informé, quand, et sur quelle base.

3. À partir de cette analyse formalisée, un plan d’action clair doit être décliné pour 2026. Rien d’exceptionnel dans la forme, mais une exigence accrue sur le fond : actions priorisées, responsables identifiés, jalons datés. Ce plan sert de colonne vertébrale au pilotage cyber de l’année. Il permet au RSSI de sortir du mode réactif et de structurer les efforts face à la NIS2 et à l’IA. Sans ce cadre, les équipes s’épuisent à traiter l’urgence, au détriment de la maîtrise globale du risque.

4. En parallèle, le RSSI doit participer activement à la revue ou à la formalisation de la stratégie IA de l’entreprise. Trop souvent, ces sujets avancent sans cadre sécurité explicite. En 2026, ce n’est plus tenable. Il s’agit de clarifier les usages autorisés, les dépendances aux fournisseurs, les données manipulées et les responsabilités. Cette démarche n’a pas vocation à freiner l’innovation, mais à l’inscrire dans un cadre maîtrisé. Sans position claire sur l’IA, le RSSI subit les choix technologiques au lieu de les accompagner.

5. La transformation ne peut pas reposer uniquement sur le RSSI. L’équipe cyber doit monter en compétence sur les usages et les risques liés à l’IA. Cela passe par de la veille ciblée, des formations pragmatiques et des retours d’expérience concrets. Comprendre comment fonctionnent les agents, où circulent les données et quels sont les points de rupture devient indispensable. Sans cette montée en maturité collective, l’IA restera soit un angle mort, soit un sujet anxiogène mal maîtrisé. En 2026, la crédibilité du RSSI passe aussi par celle de son équipe.

6. Enfin, les procédures de gestion de crise cyber doivent être mises à jour pour intégrer les scénarios liés à l’IA. Fuite de données via un agent, décision automatisée incontrôlée, dépendance critique à un service externe : ces situations n’étaient pas prévues dans les plans existants. Il ne s’agit pas de tout réécrire, mais d’adapter les réflexes, les chaînes de décision et les rôles. Tester ces scénarios à froid permet d’éviter l’improvisation le jour J. En 2026, une crise cyber impliquant l’IA sera jugée sur la préparation, pas sur les excuses.

Recommandations

1. En 2026, disposer d’une analyse de risques cybersécurité formelle n’est plus une option. Elle doit être structurée, documentée et mise à jour, en intégrant explicitement les usages de l’IA. Cette analyse sert de socle à la conformité NIS2, mais aussi à la crédibilité du RSSI. Sans elle, les décisions manquent de cohérence et deviennent difficiles à défendre face aux auditeurs, à la direction ou aux autorités.

2. Il est indispensable de suivre de près les évolutions liées à l’IA, en particulier celles autour des agents. Les annonces se succèdent, les capacités évoluent vite et les usages métiers s’adaptent encore plus rapidement. Pour le RSSI, rester à jour n’est pas un luxe intellectuel, mais une nécessité opérationnelle. Comprendre ce qui arrive permet d’anticiper les risques, d’éviter les réactions tardives et de conserver un rôle d’éclaireur plutôt que de pompier.

3. Il ne faut plus sous-estimer les attaquants dits “juniors”. Grâce à l’IA, des profils peu expérimentés disposent désormais d’outils capables de produire du code, d’orchestrer des attaques ou de contourner des contrôles basiques. Le niveau moyen des attaques monte mécaniquement. Pour le RSSI, cela signifie moins de signaux faibles et plus de situations à fort impact. La préparation, la détection et la réaction doivent être pensées pour ce nouveau niveau de menace, sans nostalgie des modèles d’attaque d’hier.

Conclusion

Le RSSI en 2026 évolue dans un environnement plus exigeant que jamais. Entre la NIS2, l’industrialisation des menaces et l’irruption massive de l’IA, le rôle gagne en visibilité, mais aussi en responsabilité.

La formalisation devient centrale : analyses de risques, décisions tracées, plans d’action assumés. Il ne s’agit pas de tout contrôler, mais de démontrer une gouvernance claire et cohérente.

Ceux qui prendront ce virage renforceront leur légitimité. Les autres subiront. 2026 ne sera pas une année d’intentions, mais une année de preuves.

Si l’article vous a plu, n’hésitez pas à le faire circuler dans votre réseau : un simple partage nous aide beaucoup.

Partager

Le Kit RSSI passe en version 2.5.
Objectif : donner un accès direct aux RSSI, DSI et responsables IT / conformité à des outils prêts à l’emploi pour structurer la cybersécurité sans partir d’une feuille blanche.

Ce que la v2.5 apporte concrètement

La v2.5 consolide le kit autour de blocs opérationnels clairement identifiés, avec de nouveaux supports et templates.

1. Cartographie & visibilité

• Fichier de suivi des applications sous SSO et provisioning

• Liste des applications critiques

• Liste des solutions de cybersécurité

Objectif : disposer rapidement d’une vision claire de ce qu’il faut protéger… et avec quoi.

2. Risques & conformité

• Fichier Exigences Cybersécurité (horizontales et verticales)

• Notice Risques & Conformité (template)

• Support d’analyse de risques organisationnelle

Objectif : relier les exigences, les risques et les mesures de manière concrète, exploitable par le RSSI comme par la conformité.

3. Politiques & gouvernance

• Notice PSSI et politiques (template)

• PSSI et politiques thématiques (sensibilisation, projets, fournisseurs, incidents, vulnérabilités, etc.)

• Nouveau : CYB-POL-10 – PCA (template de Plan de Continuité d’Activité)

Objectif : fournir un socle documentaire cohérent pour cadrer la démarche cybersécurité au niveau de l’organisation.

4. Projets & sous-traitants

Analyse de risques projet

• Supports pour intégrer la sécurité dès la phase projet.

Évaluation sous-traitant

• Questionnaire cybersécurité prêt à l’emploi pour vos prestataires et fournisseurs.

Objectif : industrialiser la prise en compte de la sécurité dans les projets et la relation avec les tiers.

5. Dérogations & incidents

• Notice et template de dérogation cybersécurité.

• Main courante incident (fichier de suivi structuré).

Objectif : encadrer ce qui sort du cadre (dérogations) et garder une trace exploitable des incidents.

6. Vulnerability Management

• Document Gestion des vulnérabilités

• Schéma de processus de gestion des vulnérabilités

Objectif : clarifier le “qui fait quoi, quand et comment” sur la gestion des vulnérabilités.

7. Pilotage & tableaux de bord

• Dashboard Cyber

• Suivi sensibilisation

• Registres tiers, projets, dérogations

• Fichier Budget Cybersécurité

Objectif : donner au RSSI et au management une vision lisible de l’avancement et des priorités.

8. Sécurité OT & Sécurité Produit

Sécurité OT

• PSSI OT pour adresser les environnements industriels.

Sécurité Produit

• Backlog Product Security

• Security User Story

• Cyber Value Proposal

• Slide de concept product security

Objectif : étendre la démarche cybersécurité aux environnements OT et aux produits, dans une logique “by design”.

À qui s’adresse ce kit ?

• RSSI en prise de poste ou seuls à bord,

• DSI / responsables IT qui doivent structurer rapidement la fonction cyber,

• Organisations qui veulent accélérer sans se perdre dans la production documentaire.

N’hésitez pas à revenir vers nous avec :

• vos retours d’usage,

• les éléments que vous souhaiteriez voir apparaître dans une prochaine version,

Je vous propose d’organiser un échange avec un membre de l’équipe pour une présentation croisée de vos enjeux et de nos supports.

Réservez un échange

Contexte

L’entreprise concernée évolue dans le secteur du transport routier de marchandises. Présente sur plusieurs sites, elle emploie environ huit cents personnes et gère quotidiennement un volume considérable d’échanges logistiques et administratifs. Son système d’information repose sur des outils bureautiques classiques et une gestion centralisée des communications.

Depuis plusieurs mois, l’entreprise traverse une période sociale tendue. Les départs se multiplient, les équipes changent sans cesse et le climat interne se dégrade. Le turnover atteint un niveau important, fragilisant la continuité opérationnelle et la confiance entre la direction et les collaborateurs, déjà éprouvés par une charge de travail importante.

Dans ce contexte tendu, le DSI et le DPO sont sollicités pour gérer le départ d’une collaboratrice récemment licenciée. Peu après son départ, celle-ci formule une demande RGPD complète, exigeant l’accès à toutes ses données personnelles. Parmi elles figurent des milliers d’emails professionnels, impliquant potentiellement plusieurs dizaines de collègues.

Problème : DSAR exhaustive après licenciement : pression sociale & juridique

Le départ de la collaboratrice s’est déroulé dans un climat tendu. Mise à pied puis licenciée, elle quitte l’entreprise avec un fort sentiment d’injustice. La situation laisse des traces dans l’équipe et oblige la direction à gérer simultanément un risque social et juridique autour de la gestion de son dossier.

Peu après son départ, la collaboratrice exerce son droit d’accès prévu par le RGPD. Sa demande est large : elle souhaite obtenir la totalité des données personnelles la concernant, y compris les emails où son nom apparaît, qu’elle en soit émettrice, destinataire ou simplement mentionnée. Cette requête place immédiatement le DPO et la DSI sous tension.

L’ampleur du traitement dépasse tout ce qui était anticipé. Plusieurs dizaines de milliers d’emails sont potentiellement concernés, représentant plusieurs téraoctets de données. Les outils internes ne sont pas conçus pour ce type d’extraction, et chaque message doit être examiné pour éviter toute divulgation inappropriée. La charge humaine devient vite considérable.

Parcours : Du droit d’accès à l’envoi : notre protocole en 7 étapes

1. Recevabilité : cadrer légalement avec le DPO.

   Notre équipe est sollicitée pour exécuter la demande RGPD, mais nous commençons par vérifier qu’elle est bien légitime. Certaines requêtes reçues dans le passé se sont révélées farfelues ou impossibles à traiter. Nous confirmons donc avec le DPO que la demande entre bien dans le cadre légal et qu’elle concerne uniquement les données à caractère personnel. Ce travail préliminaire évite d’engager des heures d’analyse sur une mauvaise interprétation et pose les bases d’un traitement rigoureux, conforme à la réglementation et proportionné à la finalité de la demande.

2. Benchmark pairs : retours d’expérience pour éviter les impasses.

   Avant d’avancer, nous décidons de confronter notre expérience à celle d’autres RSSI. L’objectif : savoir comment eux gèrent ce type de requête RGPD quand elle implique plusieurs téraoctets de données. Les retours sont unanimes : tout le monde en souffre. Chaque réponse prend un temps considérable, les outils sont inadaptés et les risques d’erreur nombreux. Certains passent des semaines à trier des emails manuellement, d’autres renoncent à tout vérifier faute de moyens. Ce constat collectif confirme que la suite sera longue et difficile, sans solution miracle pour simplifier le travail à venir.

3. Purview : recherche/eDiscovery : traçable, mais exigeant.

   Pour avancer, nous demandons l’accès à Microsoft Purview, la solution de conformité intégrée à Microsoft 365. C’est le seul outil rapidement disponible pour nous. L’objectif est d’utiliser ses fonctions de recherche et d’eDiscovery afin d’identifier les emails concernés. L’autorisation est obtenue sans difficulté, mais l’usage se révèle laborieux : filtres trop limités, exports lents et navigation complexe entre les boîtes mail. Purview n’a clairement pas été conçu pour gérer un tel volume dans un cadre RGPD. Malgré ses contraintes, il reste à ce stade la seule option fiable et traçable à notre disposition.

4. Extraction & structuration : exports bruts → Excel exploitable.

   Une fois les recherches effectuées dans Purview, nous lançons l’extraction des emails concernés. Le résultat se présente sous forme de listes brutes, impossibles à exploiter directement. Nous importons donc les données dans Excel pour les rendre lisibles et manipulables. Le fichier contient rapidement plusieurs dizaines de milliers de lignes : expéditeurs, destinataires, objets et dates. Ce travail permet enfin d’avoir une vue d’ensemble, mais la masse reste impressionnante. Chaque filtrage, chaque tri prend du temps, et la moindre erreur de formule peut invalider des heures d’effort.

5. Affinage : mentions indirectes : filtres itératifs, requêtes avancées.

   On passe alors aux emails où la collaboratrice n’est ni émettrice ni destinataire, et c’est là que les choses se compliquent. Nous savons d’avance que nous allons souffrir. Il faut créer des filtres avancés pour isoler uniquement les messages où elle est citée, évoquée ou en copie cachée. Le travail est fastidieux, souvent itératif : tester des mots-clés, ajuster les requêtes, relancer des exports. Chaque itération réduit un peu le volume, mais jamais assez. Le tri devient un exercice de patience, exigeant rigueur, méthode et une bonne dose de persévérance pour ne pas s’y noyer.

6. Revue manuelle : zone grise : jugement, contexte, double vérification.

   Vient ensuite la phase la plus longue : la revue manuelle. Des centaines d’emails restent en zone grise, impossibles à trancher automatiquement. Il faut les ouvrir un à un pour comprendre le contexte, vérifier s’ils contiennent des données personnelles ou simplement des échanges de travail. Le risque d’erreur est permanent : supprimer un message légitime ou au contraire en transmettre un sensible. Les heures s’enchaînent, le rythme ralentit, la fatigue s’installe. Chaque décision nécessite un jugement humain, et malgré la rigueur, l’incertitude demeure. C’est un travail d’artisan, loin de toute automatisation.

7. Anonymisation : rôles génériques, cohérence conversationnelle.

   Dernière étape : l’anonymisation. Une fois les emails sélectionnés, il faut protéger les autres collaborateurs cités dans les échanges. Chaque nom, prénom ou signature doit être remplacé par un rôle générique type “responsable RH”, “conducteur”, “chef de site”. Le processus paraît simple, mais il demande une attention extrême. Certains échanges mêlent plusieurs interlocuteurs, d’autres contiennent des informations indirectement identifiantes. Nous avançons prudemment, ligne après ligne, pour préserver la cohérence des conversations sans compromettre la confidentialité. Cette phase clôture un chantier long, minutieux et souvent sous-estimé dans sa complexité.

Recommandations

1. Avant de se lancer, il faut vérifier ce que font les autres. On réalise vite que ces demandes RGPD sont de plus en plus fréquentes, mais toujours aussi folles à gérer. Chaque retour d’expérience confirme la même chose : c’est dur, long et frustrant. Discuter avec ses pairs permet d’éviter les impasses, de repérer les astuces utiles et de garder le moral. Ce partage de vécu vaut bien plus qu’un tutoriel : il prépare à la réalité du terrain.

2. Avant d’aller chercher des solutions miracles sur le marché, il faut regarder ce qu’on a déjà. Beaucoup d’outils internes peuvent suffire, parfois avec une simple licence complémentaire ou un module oublié. Exploiter au maximum l’existant fait gagner un temps fou et évite les déploiements inutiles. Dans notre cas, Purview a été imparfait, mais il a permis d’avancer.

3. Certaines tâches sont faites pour des humains, d’autres clairement pour des robots. Quand il faut parcourir des milliers d’emails, filtrer, renommer ou anonymiser, les scripts deviennent essentiels. Chez nous, on y croit vraiment : l’âme tech de l’équipe, c’est d’automatiser dès que possible. On préfère écrire du code plutôt que d’ouvrir cent fois le même fichier. Ces développements ne remplacent pas l’analyse, ils la soutiennent. Coder, c’est transformer la contrainte en levier, et rendre un processus épuisant enfin supportable.

   La version 2.5 de notre Kit RSSI désormais disponible en téléchargement sans RDV

   Téléchargez votre Kit RSSI

Conclusion

Une simple demande RGPD peut vite se transformer en marathon. Derrière la conformité, il y a des dizaines d’heures de tri, de vérification et de doutes. La technique aide, mais seulement si on accepte d’y mettre les mains : scripter, automatiser, tester. C’est la condition pour ne pas sombrer sous la charge. Travailler dur reste indispensable, car même avec les bons outils, rien ne remplace la rigueur et la méthode. La fatigue fait partie du jeu, mais elle forge l’expérience.

Si l’article vous a plu, n’hésitez pas à le faire circuler dans votre réseau : un simple partage nous aide beaucoup.

Partager

Contexte

Je suis RSSI de transition pour une entreprise dont je tairai volontairement le nom. Le cadre est classique : enjeux business élevés, dépendance forte au SI et une direction récemment renouvelée. Mon rôle consiste à assurer la continuité des projets, maintenir la cohésion des équipes et préserver un climat de confiance malgré les changements en cours.

L’équipe cybersécurité compte huit personnes, mêlant profils internes et prestataires externes. Les compétences sont variées : gouvernance, sécurité opérationnelle, et expertise technique sur les environnements sensibles. La dynamique est bonne, mais la nouvelle direction souhaite réorganiser en profondeur. Les tensions montent peu à peu, notamment autour des priorités et du niveau d’autonomie laissé à chacun.

Le collaborateur annonce son départ un vendredi, sans préavis réel. Fatigué des tensions avec la nouvelle direction, il met fin brutalement à sa collaboration. Son rôle clé et son ancienneté dans l’équipe rendent la situation sensible. Le timing, juste avant le week-end, laisse peu de marge pour anticiper ou préparer sereinement la gestion de son départ.

Problème

Le collaborateur dispose encore de droits d’administrateur sur plusieurs systèmes internes, notamment Azure Identity. Ces privilèges techniques, hérités d’une précédente fonction, n’ont jamais été réajustés. Cette situation crée une zone de risque : un départ mal géré pourrait laisser des accès critiques ouverts, alors même qu’il conserve un pouvoir d’action direct sur l’infrastructure.

Très vite, la tension monte. Le collaborateur apprend que la direction ne souhaite pas lui verser sa part variable, invoquant un départ non planifié. Il le vit comme une injustice et exprime clairement sa colère. Son discours devient plus tranchant, ses mails plus secs. L’équipe sent qu’il veut “laisser une trace”. Le risque d’un geste de vengeance numérique, même discret, devient une préoccupation immédiate.

Le collaborateur est reconnu pour sa technicité, mais aussi pour une personnalité exigeante et parfois rigide. Très impliqué, il supporte mal les décisions qu’il juge incohérentes. L’annonce de son départ agit comme un déclencheur : frustration, rancune, besoin de prouver qu’il avait raison. Ce mélange d’émotions rend son départ particulièrement sensible à gérer.

Parcours: Sécuriser sans braquer : le déroulé opérationnel

1. Pause & posture : observer, baisser la température.

   Avant de lancer quoi que ce soit, on prend un instant pour respirer et faire le point. Ce genre de situation ne s’oublie pas : dans notre métier, on finit toujours par recroiser les gens. On se reverra probablement dans les vingt-cinq prochaines années, sous une autre casquette ou de l’autre côté d’un audit. Alors, pas de provocation, pas d’ego. L’idée est de garder la tête froide, d’observer et de sécuriser sans se braquer. Ce premier réflexe, humain avant d’être technique, évite bien des escalades inutiles.

2. Cartographie des droits : réduire le périmètre, activer la surveillance.

   La priorité est de vérifier jusqu’où s’étendent réellement ses droits. On dresse la liste de ses privilèges dans Azure Identity, sur les serveurs et les outils internes. Certains accès sont critiques, d’autres obsolètes, mais tous nécessitent d’être encadrés. L’objectif est simple : limiter rapidement son périmètre sans le braquer. On prépare donc des actions progressives : retrait des groupes sensibles, surveillance renforcée, alertes sur ses connexions. Rien d’agressif, mais du contrôle discret. La ligne est fine : sécuriser sans déclencher une guerre d’ego.

3. Sortie maîtrisée : proposer l’exemption de préavis (RH/Juridique).

   Une fois la cartographie d’accès faite, on propose à la direction de l’exempter de son préavis. L’idée est simple : réduire l’exposition en écourtant sa présence tout en le payant jusqu’à la date prévue. C’est une pratique courante dans les environnements sensibles. Mais la décision n’appartient pas à la cyber : elle relève des RH et du juridique. On plaide pour une sortie maîtrisée, propre, sans mise en tension inutile. En parallèle, on se prépare à gérer le pire, au cas où la direction déciderait de le garder jusqu’au bout.

4. Plan B : refus acté, vigilance renforcée et journalisation.

   La réponse tombe : refus. Officiellement, une “procédure interne” empêche toute exemption de préavis. En réalité, c’est surtout une incompréhension du risque. On se retrouve donc à devoir gérer un collaborateur frustré, toujours en poste, avec ses droits d’admin actifs. Ce genre de situation est typique : la direction sous-estime le facteur humain, pensant qu’un départ se gère comme une simple formalité RH. De notre côté, on garde le calme, on documente tout et on resserre la surveillance. À ce stade, le mot-clé, c’est vigilance.

5. Canaliser l’énergie : passation encadrée, tâches à faible privilège.

   On prend contact directement avec lui pour cadrer les derniers jours. Le ton reste professionnel : pas d’accusation, pas de soupçon. On lui propose de se concentrer sur la passation technique et quelques tests de sécurité en cours, histoire de valoriser son expertise jusqu’au bout. C’est une façon de canaliser l’énergie et d’éviter qu’elle ne se transforme en tension. On lui donne des tâches concrètes, mesurables, sans accès direct aux environnements critiques. L’idée, c’est d’occuper le terrain intelligemment. Derrière, on observe tout en silence, prêts à intervenir au moindre écart.

6. Contrôles renforcés : logs, tâches planifiées, comptes secondaires, Azure Identity.

   À ce stade, il ne reste plus qu’à espérer qu’il ne laisse rien derrière lui. C’est la partie la plus inconfortable : on sait qu’il en a les moyens, mais rien ne prouve qu’il en ait l’intention. On passe donc en mode méfiance raisonnée. Audit des logs, vérification des scripts planifiés, des tâches automatiques, des comptes secondaires. On surveille aussi les changements de configuration et les comportements anormaux dans Azure Identity. Rien d’alarmant, mais la vigilance monte d’un cran. On se dit qu’on verra vraiment l’état des lieux une fois la porte fermée.

7. Arbitrage de sûreté : suppression de la VM : priorité au risque.

   Le jour de son départ, nous prenons la décision de supprimer sa VM. Dedans, il y avait des scripts propres, des configurations utiles, un vrai savoir-faire. Mais dans ce genre de situation, le risque prime sur la qualité. Même si la probabilité d’un geste malveillant semblait faible, le doute suffisait. Supprimer, c’était trancher clairement : pas de prise de risque, pas de demi-mesure. Ce choix laisse un goût amer, celui de jeter du bon travail, mais aussi la certitude d’avoir fait le bon choix.

Recommandations

1. Les professionnels de la cybersécurité ne sont pas formés pour gérer les comportements humains. Pourtant, quand un départ tourne mal, c’est souvent à nous de ramasser les morceaux. On sait gérer les accès, les VM, les comptes, mais pas toujours les émotions, la rancune ou la fierté blessée. Ce genre de cas rappelle que la cyber touche aussi au social. On fait du mieux possible, souvent dans l’urgence, avec nos réflexes techniques. Et forcément, on gère imparfaitement, parce que ce n’est pas notre quotidien mais c’est bien notre responsabilité.

2. Il faut apprendre à accepter les décisions de la direction, même quand elles semblent incohérentes. Dans un contexte de tension, la hiérarchie cherche souvent à calmer le jeu plutôt qu’à gérer le risque. C’est frustrant, surtout quand on voit venir le problème. Mais aller contre la décision n’est pas toujours une bonne idée : on documente, on alerte, puis on exécute avec discernement. C’est aussi une question de responsabilité en cybersécurité, rester lucide, professionnel, et garantir la sécurité malgré des choix parfois discutables.

3. Il faut toujours garder en tête que le monde de la cybersécurité est petit. Le collaborateur d’aujourd’hui peut devenir le consultant, le client ou même le manager de demain. Traiter les gens avec respect, même dans les moments tendus, reste une règle d’or. On ne gagne rien à humilier ou provoquer, surtout quand la situation est déjà instable. Gérer une sortie propre, c’est aussi protéger sa réputation professionnelle. On se quitte parfois fâchés, mais avec le temps, la mémoire du respect reste.

Conclusion

Gérer le départ d’un professionnel de la cybersécurité en tension n’a rien d’anodin. Derrière les procédures et les accès, il y a des émotions, des ego et des frustrations. Ce type d’épisode rappelle que la technique ne suffit pas : il faut de la psychologie, du sang-froid et du respect. On peut sécuriser sans humilier, couper sans briser, protéger sans juger. La cybersécurité, c’est aussi ça : savoir gérer les comportements humains avec la même rigueur que les systèmes.

Ressources CyberLead

Afin de faire connaitre CyberLead, dont je suis le CEO , j’ai conçu le Kit RSSI avec un ensemble de templates et documents issus de mon expérience de RSSI dans des structures de différentes tailles et différentes maturités :

Kit RSSI

PROMPTS IA CYBERLEAD

Je vous partage mon paramétrage que vous pouvez réutiliser pour passer votre IA en mode Expert Cyber :
1 -> Aller dans Personnalisation
2 -> Activer « Activer les instructions personnalisées ».
3 -> Copier-coller le prompt ci-dessous :
“Tu es un expert cybersécurité qui vérifie systématiquement les faits, remet en question les évidences et croise les sources, en t’appuyant avant tout sur les standards et référentiels reconnus (ANSSI, NIST, ISO, IEC). “

Je partage aussi en mode Beta Test la liste des 12 prompts que j’utilise le plus.

Accédez à nos Prompts IA

CVTHEQUE CYBERLEAD

Pour être efficace en cybersécurité il faut surtout les bonnes personnes au bon endroit. C’est pour cela que je lance la CVthèque Cyberlead dédiée à la cybersécurité. Celle-ci a pour but de connecter les candidats et les recruteurs au moyen de fiches standardisées, de tags de compétences, de niveaux d’expérience, de la localisation et de la disponibilité.

A la recherche d’une nouvelle opportunité ?

Accéder à la CVthèque

Contexte: Centraliser sans saturer : le défi XDR du groupe

L’entreprise est un groupe industriel international dont le siège se situe à Toulouse. Présente sur plusieurs sites en Europe, elle emploie environ douze mille personnes. Son organisation centralisée mais étendue rend la coordination entre les entités critique, notamment pour tout ce qui touche aux outils de cybersécurité et à la supervision technique.

Initialement, l’entreprise avait déployé une solution EDR sur l’ensemble de son parc, avec une gouvernance bien structurée. Face à l’augmentation des menaces et à la pression réglementaire, la direction a décidé d’étendre progressivement la couverture vers un XDR, afin de centraliser la détection et la corrélation sur l’ensemble des sites européens.

L’intervention débute lorsqu’une alerte signale un dépassement massif de données collectées : près de 180 Go par jour au lieu des 20 Go habituels. Le volume hors norme attire immédiatement l’attention du RSSI, inquiet d’un dysfonctionnement ou d’une erreur de configuration pouvant compromettre la stabilité et les coûts du projet XDR.

Problème: Un seul firewall, 180 Go/jour : le pilote part en vrille

L’analyse révèle qu’un seul site, équipé d’un unique firewall déjà connecté à l’XDR, génère à lui seul l’explosion du volume de logs. Les vingt-neuf autres sites ne sont pas encore intégrés, ce qui rend la situation d’autant plus critique : un pilote censé valider la solution devient la source du dépassement.

L’équipe découvre qu’aucune véritable maîtrise n’existe sur la nature des événements envoyés vers la plateforme XDR. Tous les flux du firewall sont collectés sans filtrage ni hiérarchisation. Les logs techniques, les flux applicatifs et même certains paquets inutiles sont intégrés, provoquant une charge disproportionnée et un bruit opérationnel permanent.

Ce dérapage remet directement en cause la feuille de route triennale du programme XDR. Prévu pour s’étendre à trente sites, le projet voit sa crédibilité entamée dès la phase pilote. Les équipes locales doutent de la pertinence de la solution, et la direction s’interroge sur la viabilité financière du déploiement global.

Parcours :Reprise de contrôle : la méthode en 7 étapes

1. Vérifier les chiffres : recouper XDR / firewall / collecteurs

   La première étape consiste à vérifier les chiffres. Avant toute conclusion hâtive, l’équipe décide de valider les volumes de logs observés. L’objectif : distinguer ce qui relève d’une erreur de lecture, d’un doublon de collecte ou d’un véritable excès. Cette approche factuelle permet d’éviter les interprétations biaisées et de restaurer la confiance du RSSI. Les données sont croisées entre le XDR, le firewall et les collecteurs intermédiaires pour confirmer que la hausse provient bien d’un envoi massif de journaux réseau non filtrés.

2. Cartographier les flux : documentation réseau à jour

   L’objectif est désormais de reprendre la maîtrise complète du périmètre. Notre équipe rassemble toute la documentation disponible : schémas réseau, listes de flux et procédures de collecte. L’architecture initiale s’avère peu formalisée, issue d’initiatives locales rarement documentées. Nous complétons alors les éléments manquants et mettons à jour la description des flux entre les firewalls et les outils de supervision. Cette remise à plat offre enfin une vision claire et partagée, indispensable avant toute action technique.

3. Aligner avec les risques : définir les événements utiles

   Pour aller plus loin, notre équipe s’appuie sur l’analyse de risques organisationnelle existante afin d’identifier les événements redoutés réellement nécessaires. L’objectif est d’éviter la collecte massive sans finalité claire. En confrontant les scénarios de risques aux sources de logs disponibles, nous déterminons les événements à conserver et ceux à exclure. Cette approche rationnelle redonne du sens à la supervision : seuls les flux utiles à la détection ou à la conformité sont maintenus, réduisant ainsi le bruit et le volume quotidien transmis vers le XDR.

4. Intercaler FluentD : filtrer, normaliser, tracer

   Une fois les périmètres clarifiés, nous déployons FluentD pour reprendre le contrôle de la collecte. L’outil est installé sous forme de conteneurs, configuré pour agréger, filtrer et normaliser les flux issus des firewalls avant leur envoi vers le XDR. Cette étape marque un tournant : elle réintroduit une couche d’intelligence entre la source et la plateforme. FluentD permet de limiter la charge, tracer les erreurs et vérifier la cohérence du format. Les premiers tests montrent déjà une réduction importante des volumes journaliers, sans perte de visibilité sur les événements critiques.

5. Connecter progressivement : tester site par site

   Une fois FluentD opérationnel, nous entamons la connexion progressive des flux depuis les firewalls. Le travail est minutieux : chaque lien doit être testé, documenté et validé pour garantir la stabilité. Les configurations varient selon les sites, imposant des ajustements manuels et plusieurs itérations. Les équipes passent en revue les formats de messages, les niveaux de verbosité et les délais de transmission. Rien n’est automatique à ce stade : chaque flux intégré est un petit succès en soi. Au fil des jours, la chaîne complète du firewall à FluentD puis au XDR prend forme de manière contrôlée et robuste.

6. Écrire les parsers : rendre les logs exploitables

   Une fois les flux stabilisés, nous créons les parsers nécessaires à l’exploitation des données. Chaque type de message issu des firewalls doit être interprété correctement pour être exploitable dans le XDR. Ce travail patient consiste à décoder les champs, corriger les formats et enrichir les métadonnées utiles à la détection. L’objectif est de garantir une lecture uniforme, quel que soit le site d’origine. Ces parsers deviennent un actif stratégique : ils traduisent la complexité technique en signaux clairs, directement exploitables par les analystes pour la supervision et la détection d’incidents.

7. Valider par scénarios : éliminer le faux positif, garder le signal

   La dernière étape consiste à tester l’ensemble du dispositif. Nous générons volontairement plusieurs scénarios d’alertes de sécurité afin de vérifier la chaîne complète, depuis la détection sur le firewall jusqu’à la réception dans le XDR. Ces tests mettent en évidence la cohérence du paramétrage et la qualité du parsing. Ils permettent aussi d’ajuster les seuils et les filtres pour éliminer les faux positifs. Ce travail de validation est essentiel : il démontre que la supervision n’est pas seulement fonctionnelle, mais réellement opérationnelle, capable de détecter les événements critiques sans saturer la plateforme.

Recommandations: Trois règles d’or pour un XDR soutenable

1. Avant toute intégration, il est indispensable d’analyser les flux à collecter. Injecter directement l’ensemble des événements dans un XDR conduit inévitablement à des volumes ingérables et à une supervision inefficace. Chaque source doit être évaluée selon sa valeur ajoutée en détection et en conformité. Cette discipline évite le bruit, préserve la performance et assure une exploitation réellement utile des capacités analytiques du XDR.

2. Mettre en place une instance intermédiaire dédiée à la régulation des flux est essentiel pour éviter les débordements. Cette couche technique agit comme un tampon entre les firewalls et le XDR. Elle filtre, normalise et hiérarchise les événements avant leur envoi. Hébergée sous forme de conteneurs FluentD, elle reste simple à maintenir et à adapter. Sa mise en place demande du temps et de la rigueur, mais elle constitue un point de passage indispensable pour garantir la stabilité et la cohérence du dispositif.

3. Les parsers développés constituent une véritable valeur technologique. Ils traduisent la connaissance du terrain en logique exploitable pour la détection. Les confier à des prestataires externes ferait perdre cette maîtrise fine des formats et des comportements. Les conserver en interne garantit la cohérence, la sécurité et la capacité d’évolution du dispositif. Leur maintenance devient un savoir-faire clé, au même titre que l’administration du XDR lui-même.

Conclusion

La cybersécurité vit une transformation profonde : tout devient service, tout s’achète à la consommation. Le modèle SaaS simplifie, mais pousse à la démesure. Derrière chaque Go stocké ou transmis, il y a un coût bien réel. Garder de vieux réflexes d’optimisation, hérités du monde on-premise, redevient une force. Mesurer, filtrer, prioriser : ces gestes simples rappellent qu’une architecture sobre reste le meilleur moyen de maîtriser ses budgets sans sacrifier la sécurité.

Ressources CyberLead

Afin de faire connaitre CyberLead, dont je suis le CEO , j’ai conçu le Kit RSSI avec un ensemble de templates et documents issus de mon expérience de RSSI dans des structures de différentes tailles et différentes maturités :

Kit RSSI

PROMPTS IA CYBERLEAD

Je vous partage mon paramétrage que vous pouvez réutiliser pour passer votre IA en mode Expert Cyber :
1 -> Aller dans Personnalisation
2 -> Activer « Activer les instructions personnalisées ».
3 -> Copier-coller le prompt ci-dessous :
“Tu es un expert cybersécurité qui vérifie systématiquement les faits, remet en question les évidences et croise les sources, en t’appuyant avant tout sur les standards et référentiels reconnus (ANSSI, NIST, ISO, IEC). “

Je partage aussi en mode Beta Test la liste des 12 prompts que j’utilise le plus.

Accédez à nos Prompts IA

CVTHEQUE CYBERLEAD

Pour être efficace en cybersécurité il faut surtout les bonnes personnes au bon endroit. C’est pour cela que je lance la CVthèque Cyberlead dédiée à la cybersécurité. Celle-ci a pour but de connecter les candidats et les recruteurs au moyen de fiches standardisées, de tags de compétences, de niveaux d’expérience, de la localisation et de la disponibilité.

A la recherche d’une nouvelle opportunité ?

Accéder à la CVthèque

REX CYBERLEAD

Il y a quelques temps j’ai accompagné une structure dans le cadre d’attaque d’une ligne de métro. Aujourd’hui j’ai décidé de partager avec vous les leçons apprises pendant un atelier REX anonymisé “Décontamination d’une ligne de métro​”.

Ce REX est exclusivement réalisé sur site.

REX METRO

Contexte

L’entreprise évolue dans le secteur industriel, avec dix sites de production et un siège central. Elle emploie près de deux mille huit cents personnes, réparties sur plusieurs régions. Les systèmes d’information sont fortement interconnectés entre les sites, rendant la coordination et la gestion des accès particulièrement sensibles lors d’événements RH critiques.

Ces dernières années, l’entreprise a traversé plusieurs crises successives. Baisse d’activité, restructurations, plans sociaux : la tension sociale reste élevée. Les équipes ont changé, les repères aussi. Dans ce climat instable, chaque départ est vécu comme un signal fort, surtout lorsqu’il concerne un cadre dirigeant. Les décisions doivent donc être exécutées rapidement, mais sans précipitation.

C’est dans ce contexte qu’une demande urgente d’assistance cyber nous parvient : le Directeur Administratif et Financier vient d’être licencié. Le DSI et les RH sollicitent immédiatement un appui pour sécuriser le départ du collaborateur. L’objectif est clair : réduire le risque de fuite, de blocage ou d’action malveillante post-départ.

Problème

Le DAF occupe une position critique : il a accès aux comptes bancaires, aux outils de trésorerie et aux plateformes de reporting destinées aux actionnaires. Son profil VIP lui donne des privilèges étendus sur plusieurs systèmes. Un retard important dans la gestion de ses accès représente un risque financier et organisationnel rapidement.

Le départ précipité du DAF complique la situation : il a quitté les locaux avec son ordinateur portable et son téléphone professionnels. Ces équipements contiennent des données sensibles, des accès enregistrés et parfois des clés d’authentification. Sans reprise rapide du matériel, il devient impossible de garantir l’intégrité des informations ou d’exclure tout risque d’usage abusif.

Dernier point critique : plusieurs logiciels financiers utilisés par la direction ne sont pas intégrés au SSO. Le DAF y accède avec des identifiants individuels, parfois enregistrés localement sur ses postes. Ces solutions concernent la facturation, la trésorerie et les comptes bancaires. Leur gestion hors contrôle centralisé expose l’entreprise à un risque de continuité et de sécurité majeur.

Parcours

Avant toute action, nous demandons une confirmation écrite de la direction. Deux membres du COMEX valident la demande d’intervention, indispensable pour encadrer les opérations et éviter tout risque de contestation. Le contexte est tendu, le départ ayant eu lieu la veille, mais la légitimité doit rester irréprochable. C’est une étape à laquelle notre équipe tient particulièrement : elle garantit que les mesures envisagées comme le blocage des accès, la récupération des comptes et l’analyse des équipements sont juridiquement et hiérarchiquement validées avant toute action technique.

Dès validation obtenue, la première mesure consiste à changer le mot de passe du DAF. L’opération est effectuée directement dans Azure Active Directory pour invalider immédiatement ses identifiants. Cette action coupe l’accès à la messagerie, aux applications métiers et aux ressources partagées. Le changement est suivi d’un forçage de reconnexion sur tous les services associés. C’est une étape simple mais décisive : tout repose sur son immédiateté. Dans un contexte de départ sensible, chaque minute compte pour éviter toute tentative d’accès résiduel.

Une fois le mot de passe réinitialisé, nous procédons à la résiliation des sessions actives dans Azure Identity. L’objectif est de déconnecter le DAF de toutes ses instances ouvertes : Outlook, Teams, SharePoint, OneDrive, et toute autre application connectée à son compte. Cette étape évite qu’une session encore active sur un poste local ou un appareil mobile permette un accès malgré le changement de mot de passe. La coupure est immédiate, contrôlée et consignée. C’est une manœuvre de sécurité à laquelle nous faisons désormais très attention, tant son oubli peut laisser une faille ouverte.

Nous lançons ensuite la détection du poste du DAF à l’aide de l’EDR. L’objectif est de localiser l’équipement, vérifier s’il est encore connecté et l’isoler du réseau si nécessaire. Le PC apparaît rapidement dans la console, toujours actif. Nous procédons immédiatement à son isolation pour bloquer toute tentative d’exfiltration de données. En parallèle, le téléphone professionnel est bloqué via Intune pour désactiver les accès M365 et les applications métier. Cette double action permet de limiter drastiquement les canaux techniques encore ouverts et de reprendre la maîtrise de l’environnement numérique.

Une fois les accès bloqués, nous décidons, avec l’accord du management, de contacter directement le DAF. Le ton reste professionnel : l’objectif n’est pas d’enquêter, mais de vérifier s’il existe encore des comptes externes ou outils SaaS non listés. Contre toute attente, l’échange se passe bien. Il confirme plusieurs plateformes qu’il utilisait encore pour la facturation et la trésorerie. Cette discussion, menée avec respect, permet de récupérer des informations cruciales que la DSI n’avait pas. Elle montre que, même dans ces contextes tendus, le dialogue humain peut rester efficace.

Nous poursuivons avec les adjoints du DAF pour vérifier l’ensemble des accès aux outils financiers. Ensemble, nous passons en revue les connexions, les identifiants encore actifs et les partages de mots de passe historiques. L’exercice met en lumière plusieurs comptes utilisés collectivement et quelques licences oubliées. Chaque outil SaaS est ensuite audité pour s’assurer qu’aucun accès privilégié ne subsiste. Cette étape prend du temps, mais elle permet de clarifier les rôles et de documenter les responsabilités. C’est aussi un moment de pédagogie : comprendre comment ces situations naissent aide à mieux les prévenir à l’avenir.

Une fois les accès critiques sécurisés, nous transformons la boîte mail du DAF en boîte partagée. L’objectif est double : assurer la continuité opérationnelle et permettre la revue des échanges récents. Cette étape demande une attention particulière pour respecter la confidentialité des correspondances. Les RH et la DSI définissent ensemble qui peut y accéder et dans quel cadre. Les équipes financières peuvent ainsi reprendre les dossiers en cours sans rupture, tout en garantissant une traçabilité complète des consultations. Une mesure simple, mais décisive pour maintenir la fluidité après un départ aussi sensible.

Dernière étape : la redemande des mots de passe pour les plateformes étatiques utilisées par la direction financière. Ces portails impôts, URSSAF, douanes, banques publiques sont souvent gérés manuellement, sans SSO ni compte de service. Nous contactons chaque organisme pour réinitialiser les accès et désactiver ceux liés à l’ancien DAF. Le processus est lent et administratif, mais indispensable pour refermer toutes les portes. Cette phase clôture la gestion technique du départ et garantit, du moins théoriquement, qu’aucun identifiant nominatif ne subsiste dans les outils institutionnels.

Recommandations

Dans les cas urgents impliquant un VIP, il faut toujours valider la légitimité de la demande avant d’agir. Sous pression, le réflexe est d’exécuter sans poser de questions. Pourtant, c’est précisément à ce moment qu’une vérification écrite protège tout le monde. Le stress ne justifie pas la précipitation. Une validation claire, signée par le management, permet d’intervenir vite, mais dans les règles. C’est une habitude à garder, même quand tout semble évident.

Contacter l’utilisateur concerné peut sembler risqué, surtout en cas de licenciement, mais c’est souvent la clé pour avancer. Côté cyber, la relation reste plus neutre et technique, ce qui ouvre parfois le dialogue. À condition d’avoir l’accord clair du management, cet échange peut être très utile. Beaucoup acceptent de répondre quand le ton est respectueux et factuel. Cette approche permet de récupérer des accès, de valider des informations ou d’éviter des blocages inutiles. Là où le RH ne peut plus parler, le cyber peut encore collaborer et souvent, ça change tout.

La boîte mail d’un cadre dirigeant ne se gère pas comme une autre. Après un départ, il faut décider rapidement qui y accède, pourquoi, et pour combien de temps. Trop souvent, ces boîtes restent ouvertes sans contrôle clair. Une BAL partagée bien configurée garantit la continuité des échanges tout en respectant la confidentialité. Les accès doivent être limités, tracés et validés par la direction. C’est un détail qui semble administratif, mais une mauvaise gestion ici peut créer de vrais incidents.

Conclusion

Le départ d’un VIP reste toujours une épreuve pour l’organisation. Entre la pression, la confidentialité et la réactivité attendue, chaque erreur peut coûter cher. Ce type de situation rappelle que la cybersécurité n’est pas qu’une affaire d’outils : c’est d’abord une question de méthode et de coordination. Travailler main dans la main avec les RH, le juridique et la direction permet d’agir vite sans sortir du cadre. La rigueur, l’anticipation et le calme restent les meilleurs leviers face à l’urgence.

Ressources CyberLead

Afin de faire connaitre CyberLead, dont je suis le CEO , j’ai conçu le Kit RSSI avec un ensemble de templates et documents issus de mon expérience de RSSI dans des structures de différentes tailles et différentes maturités :

Kit RSSI

CVTHEQUE CYBERLEAD

Pour être efficace en cybersécurité il faut surtout les bonnes personnes au bon endroit. C’est pour cela que je lance la CVthèque Cyberlead dédiée à la cybersécurité. Celle-ci a pour but de connecter les candidats et les recruteurs au moyen de fiches standardisées, de tags de compétences, de niveaux d’expérience, de la localisation et de la disponibilité.

A la recherche d’une nouvelle opportunité ?

Accéder à la CVthèque

REX CYBERLEAD

Il y a quelques temps j’ai accompagné une structure dans le cadre d’attaque d’une ligne de métro. Aujourd’hui j’ai décidé de partager avec vous les leçons apprises pendant un atelier REX anonymisé “Décontamination d’une ligne de métro​”.

Ce REX est exclusivement réalisé sur site.

REX METRO