Dans une mission de management de transition, la cybersécurité arrive rarement au bon moment. Elle surgit quand tout brûle déjà : incidents récurrents, dette technique, équipes fatiguées, projets en dérive, fournisseurs en roue libre, et parfois une direction qui veut “sécuriser” sans ralentir. Le paradoxe est là : la cyber est une discipline d’anticipation, mais la transition est un art de l’urgence. Et dans l’urgence, on ne manque pas de solutions, on manque de décisions.
La plupart des organisations ne tombent pas parce qu’elles n’ont pas entendu parler de MFA, de patching ou de segmentation. Elles tombent parce qu’elles repoussent des arbitrages qui froissent, coûtent, interrompent, ou forcent à regarder la réalité en face. Un DSI de transition n’a pas le luxe de promettre un “programme cyber” sur 18 mois : il doit trancher, protéger, réduire le risque vite, avec des moyens imparfaits, sans casser l’activité. C’est précisément pour ça que certaines décisions sont si difficiles : elles ne sont pas techniques, elles sont politiques.
Décider que le MFA devient non négociable, même si ça râle partout
Le MFA est devenu un mantra, mais dans la vraie vie, l’implémentation se heurte toujours au même mur : l’expérience utilisateur, les exceptions, les systèmes anciens, les comptes partagés, les prestataires, les dirigeants qui veulent “un contournement”, les métiers terrain qui n’ont pas de réseau stable. Résultat : on le met “sur les accès sensibles”, puis “sur les admins”, puis “sur le VPN”, puis on s’arrête là, et l’attaque passe par l’angle mort.
La décision difficile, ce n’est pas de “déployer le MFA”. C’est de décréter un périmètre clair et irréversible : messagerie, accès distants, outils collaboratifs, accès aux données sensibles, et surtout comptes à privilèges. Cela implique de gérer les cas impossibles en les isolant, pas en les excusant. Cela implique aussi une vérité qui fâche : si un fournisseur ne peut pas faire du MFA, il ne doit plus avoir d’accès direct. Le MFA devient une clause contractuelle et un prérequis d’architecture, pas un sujet de “sensibilisation”.
En transition, l’approche la plus robuste est souvent progressive mais ferme : un calendrier court, des dates, des exceptions limitées dans le temps, et un reporting factuel au Comex. Le MFA ne doit pas être un projet “en cours”. Il doit devenir un état.
Décider que le patching passe avant les nouveaux projets, même si ça fait perdre des points politiques
La gestion des correctifs est l’un des rares leviers cyber qui réduisent réellement le risque à grande échelle. Et pourtant, elle est traitée comme une activité secondaire, car elle ne fait pas rêver. Les patchs ne s’affichent pas sur les slides de transformation. Ils se traduisent en fenêtres de maintenance, en redémarrages, en tests, en incidents potentiels. Dans une organisation sous tension, c’est exactement ce que tout le monde cherche à éviter.
La décision difficile, c’est d’assumer un principe brutal : tant qu’un socle n’est pas patché, on gèle ou on ralentit certaines initiatives. Cela ne veut pas dire arrêter l’innovation. Cela veut dire hiérarchiser : la meilleure fonctionnalité du monde ne compensera jamais une exposition massive. Un ransomware ne demande pas un business case : il prend.
En pratique, un DSI de transition doit imposer une règle de pilotage : un inventaire fiable, une classification par criticité, un cycle de patching standard (mensuel) et des cycles accélérés pour les vulnérabilités critiques (48–72 heures selon le contexte). Et surtout, une décision que peu osent prendre : rendre visible la dette de patching, équipe par équipe, domaine par domaine, jusqu’à ce que l’organisation comprenne que le risque est réel, quantifié, et imputable.
Décider de segmenter le réseau, même si l’architecture actuelle “fait tourner” l’entreprise
La segmentation, c’est l’opération chirurgicale par excellence. Elle ne donne pas de bénéfice immédiat visible aux métiers, mais elle change tout en cas d’attaque : elle empêche la propagation, elle limite l’impact, elle transforme une catastrophe globale en incident local. Et c’est précisément pour ça qu’elle est repoussée : parce que “ça marche aujourd’hui”, parce que “on n’a pas de temps”, parce que “on risque de casser des flux”.
La décision difficile, c’est d’accepter que le réseau plat est une illusion de simplicité et un multiplicateur de risque. Segmenter, ce n’est pas “refaire le réseau”. C’est définir des zones, des frontières, et des règles minimales : postes utilisateurs, serveurs, systèmes critiques, sauvegardes, OT/IoT si présent, prestataires, environnements de production. Dans beaucoup d’organisations, le simple fait de protéger sérieusement l’infrastructure de sauvegarde et les systèmes d’identités via des segments dédiés change le scénario d’attaque.
En transition, la segmentation doit être pensée comme un chantier incrémental : commencer par les actifs les plus critiques, sécuriser les chemins d’administration, limiter les flux est-ouest, et documenter au fil de l’eau. Ce n’est pas une “refonte”, c’est une réduction progressive de la surface d’attaque.
Décider d’installer un EDR partout, puis de l’exploiter vraiment
Beaucoup d’entreprises ont un EDR parce qu’il fallait en avoir un, mais elles ne l’exploitent pas. Les alertes s’accumulent, les consoles deviennent un cimetière de notifications, et l’illusion de sécurité s’installe : “on est équipés”. Or un EDR non opéré est une assurance non payée : ça donne bonne conscience, mais ça ne protège pas.
La décision difficile, c’est double. D’abord : standardiser, couvrir, durcir, y compris sur les postes “spéciaux”, les exceptions, les filiales, les environnements hybrides. Ensuite : mettre en place l’exploitation opérationnelle, c’est-à-dire des règles de triage, une capacité de réponse, et un lien clair avec l’IT (isoler un poste, bloquer un hash, couper une session, déclencher une investigation). Un EDR doit être relié à une chaîne de décision qui fonctionne en heures, pas en semaines.
En transition, le point clé n’est pas la technologie, c’est le modèle d’exploitation : qui regarde quoi, à quelle fréquence, avec quel niveau de responsabilité, et avec quel filet juridique. Sans ce cadre, l’EDR devient un produit de plus dans la pile, et la pile, elle, ne sauve personne.
Décider que les comptes à privilèges ne sont plus un folklore d’administrateurs
Les comptes à privilèges sont l’objectif naturel de presque toutes les attaques modernes. Et pourtant, on y trouve encore des pratiques héritées : comptes partagés, mots de passe inchangés, droits trop larges, sessions non tracées, accès prestataires permanents, absence de séparation des rôles. Tout le monde sait que c’est dangereux, mais peu osent imposer la discipline, car cela touche à la culture des équipes IT et à la vitesse d’intervention.
La décision difficile, c’est d’imposer un modèle de privilèges minimal : séparation des comptes nominaux et admin, bastion ou équivalent, rotation des secrets, traçabilité, suppression des comptes orphelins, et réduction drastique des droits locaux. Cela implique un effort de fond, mais le retour sur risque est énorme. C’est aussi un signal culturel : la sécurité n’est pas une option, elle fait partie de la compétence.
En transition, cette décision est souvent le marqueur le plus visible d’un DSI qui prend ses responsabilités : on ne négocie pas sur l’administration. On la structure.
Décider que la sauvegarde est un système de survie, pas un stockage
On découvre souvent la fragilité des sauvegardes le jour où on en a besoin. Sauvegardes non testées, restaurations trop longues, sauvegardes accessibles depuis le réseau standard, absence d’immutabilité, documentation inexistante, dépendance à une personne clé. Quand une attaque touche l’identité ou l’Active Directory, c’est toute la chaîne de restauration qui devient incertaine.
La décision difficile, c’est d’investir dans des sauvegardes “résilientes” même si personne ne veut payer pour quelque chose qui n’apporte pas de fonctionnalités. Cela veut dire : segmentation de l’infra de sauvegarde, contrôle strict des accès, copies immuables, rotation hors-ligne ou air-gapped si possible, tests de restauration réguliers, et priorisation des services à restaurer. Cela veut dire aussi accepter un arbitrage : mieux vaut restaurer vite l’essentiel que promettre de tout restaurer et échouer.
En transition, c’est souvent la décision la plus rationnelle : elle ne prévient pas l’attaque, mais elle rend l’entreprise capable de survivre.
Décider d’arbitrer : la sécurité parfaite n’existe pas, mais l’inaction est un choix
La cyber est le royaume du “il faudrait”. Il faudrait tout patcher, tout segmenter, tout chiffrer, tout superviser, tout gouverner. Une mission de transition oblige à la vérité : on ne fera pas tout, tout de suite. Donc il faut arbitrer. Et arbitrer, c’est renoncer, donc s’exposer politiquement.
La décision difficile, c’est d’assumer publiquement une stratégie de réduction de risque : un plan 30-60-90 jours, des mesures de base non négociables, et des chantiers structurants lancés sans attendre qu’ils soient “parfaits”. Il faut aussi décider qui porte le risque résiduel. Quand une exception est accordée, elle doit être datée, documentée, et portée par un sponsor métier ou direction, pas absorbée silencieusement par l’IT.
Le DSI de transition joue alors son rôle le plus crucial : traduire la technique en risque compréhensible, transformer les débats en décisions, et créer un mouvement réel. La cyber n’est pas une checklist, c’est une posture d’organisation. Et les décisions difficiles sont précisément celles qui transforment une posture en réalité.
Au fond, la question n’est pas “est-ce qu’on peut se faire attaquer ?” La question est “quand ça arrivera, est-ce qu’on aura pris les décisions qui empêchent l’entreprise de s’effondrer ?” En transition, c’est rarement le manque d’outils qui fait tomber une organisation. C’est l’absence de courage pour trancher.
En savoir plus sur GDL T&C
Subscribe to get the latest posts sent to your email.