Smartphones et tablettes accèdent aujourd’hui aux mêmes données que les postes fixes — messagerie, fichiers, applications métier — mais échappent souvent à la même rigueur de sécurité. Or un mobile perdu, un Wi-Fi piégé ou une application malveillante suffisent à ouvrir une brèche. Deux briques complémentaires permettent de reprendre le contrôle : le MDM et le MTD.

Souvent confondus, ils ne jouent pas le même rôle : l’un gère et cadre les appareils, l’autre les défend en temps réel contre les menaces. Voici comment ils s’articulent, et comment déployer une flotte mobile réellement maîtrisée.

1. Pourquoi le mobile est un angle mort

Le mobile cumule les facteurs de risque : il transporte des données sensibles, sort en permanence du réseau de l’entreprise, mélange usages pro et perso (BYOD), et multiplie les portes d’entrée — perte ou vol, réseaux Wi-Fi publics, applications piégées, hameçonnage par SMS (smishing).

2. MDM et MTD : deux rôles complémentaires

Le MDM (Mobile Device Management) gère les appareils ; le MTD (Mobile Threat Defense) les défend. Le premier cadre et administre, le second détecte et bloque les menaces en temps réel. L’un sans l’autre laisse un trou.

3. Les 3 vecteurs que couvre le MTD

Une menace mobile n’arrive pas que par les applications. Un bon MTD surveille les trois vecteurs à la fois, en respectant la vie privée de l’utilisateur.

4. Déployer une flotte maîtrisée

• Enrôlement des appareils (corporate et BYOD) et inventaire à jour.
• Politiques de sécurité : verrouillage, chiffrement, mises à jour imposées.
• Séparation pro / perso par conteneur, dans le respect de la vie privée.
• MTD sur les trois vecteurs, avec remédiation automatisée.
• Accès conditionnel : un appareil non conforme n’accède pas aux ressources.
• Effacement à distance (du conteneur pro) en cas de perte ou de départ.

5. Les idées reçues

6. Votre checklist flotte mobile

7. Questions fréquentes

Cas concret : Sécurisation de la flotte mobile d’un organisme public →

« On fera l’audit quand on aura le temps. » Puis survient un contrôle CNIL, un client qui exige une certification, ou une fuite de données. L’audit n’est ni une case à cocher, ni une punition : c’est la photographie honnête de votre niveau de sécurité, celle qui transforme une intuition floue (« on est à peu près protégés ») en plan d’action priorisé.

Reste à savoir de quel audit on parle — car « audit RGPD » et « audit ISO 27001 » ne visent pas la même chose — et par quel bout le prendre sans se noyer. Voici la méthode.

1. RGPD, ISO 27001 : deux logiques complémentaires

On les confond souvent. Le RGPD est une obligation légale centrée sur la protection des données personnelles. L’ISO 27001 est une norme volontaire qui structure la sécurité de toute l’information via un système de management (SMSI). L’un protège les personnes, l’autre organise l’entreprise — et les deux se renforcent.

2. Les 3 natures d’audit à ne pas confondre

Sous le mot « audit » se cachent trois exercices différents. Les mélanger, c’est comparer des choux et des carottes.

3. La méthode en 5 étapes

Quel que soit le référentiel, un audit fiable suit toujours le même fil : on cadre, on collecte, on analyse, on priorise, on suit.

Le livrable clé n’est pas le rapport de constats, mais le plan d’action priorisé par le risque : ce qu’il faut corriger d’abord, avec quel effort et quel impact.

4. Volet RGPD : les 4 fondations

• Registre des traitements : la cartographie de qui traite quelles données, pourquoi et combien de temps. Point de départ non négociable.
• Base légale : chaque traitement doit reposer sur un fondement valide (consentement, contrat, obligation légale, intérêt légitime…).
• Droits des personnes : accès, rectification, effacement, portabilité — des procédures qui répondent dans les délais légaux.
• Sécurité & violations : mesures techniques adaptées et procédure de notification sous 72 h en cas de fuite.

5. Volet ISO 27001 : le SMSI, pas juste des mesures

ISO 27001 ne demande pas d’appliquer aveuglément une liste de mesures, mais de piloter la sécurité par le risque : identifier ses actifs, évaluer les risques, choisir les mesures de l’Annexe A qui les traitent, puis mesurer et améliorer en continu (logique PDCA). La certification atteste que ce système existe et fonctionne.

6. Les idées reçues

7. Votre checklist « avant de commencer »

8. Questions fréquentes

Cas concret : Refonte du S.I & mise en conformité d’un groupe mutualiste →

Un lundi matin, les écrans affichent un message : « Vos fichiers ont été chiffrés. » La messagerie est muette, les applications métier à l’arrêt, et un compte à rebours réclame une rançon en cryptomonnaie. Cette scène, des milliers d’organisations la vivent chaque année. La bonne nouvelle : une attaque par ransomware n’a rien d’une fatalité. Elle suit un scénario connu — donc anticipable — et se prépare bien avant le jour J.

Dans cet article, nous démontons le fonctionnement d’un rançongiciel étape par étape, nous listons les erreurs qui coûtent cher, puis nous détaillons un plan de remédiation concret et une checklist à garder sous la main. Objectif : que vous, DSI ou responsable IT, sachiez exactement quoi mettre en place — et quoi faire si l’incident survient.

1. Qu’est-ce qu’un ransomware, concrètement ?

Un ransomware (ou rançongiciel) est un logiciel malveillant qui chiffre vos données pour les rendre inutilisables, puis exige une rançon en échange de la clé de déchiffrement. Mais depuis quelques années, les attaquants ne se contentent plus de bloquer : ils volent d’abord les données, puis menacent de les publier. C’est la double extorsion — et parfois la triple, en ajoutant du chantage aux clients ou une attaque par déni de service.

2. Anatomie d’une attaque, étape par étape

Contrairement à l’image d’un « virus » qui frappe au hasard, une attaque par ransomware est un processus piloté, souvent sur plusieurs jours. Comprendre ses phases, c’est identifier autant d’occasions de la détecter et de l’arrêter.

Les portes d’entrée les plus fréquentes

• Hameçonnage (phishing) : un e-mail piégé qui dérobe un mot de passe ou installe un premier logiciel.
• Accès distants exposés : un RDP ou un VPN accessible depuis Internet, sans double authentification.
• Vulnérabilités non corrigées : un serveur ou un équipement en retard de correctifs.
• Chaîne d’approvisionnement : un prestataire ou un logiciel tiers compromis.

3. Les idées reçues qui coûtent cher

4. Se préparer : la défense en profondeur

Aucune mesure unique n’arrête un ransomware. La bonne approche empile des couches complémentaires : si l’une cède, les suivantes tiennent. C’est le principe de la défense en profondeur.

5. En cas d’attaque : le plan de remédiation

Si l’incident survient, l’improvisation aggrave tout. Un plan clair, connu et répété, fait gagner des heures — parfois des jours. Voici la trame en cinq temps.

En parallèle de la technique, deux réflexes : déclencher la cellule de crise (direction, IT, communication, juridique) et notifier qui de droit — en France, la CNIL sous 72 h en cas de violation de données personnelles, et un dépôt de plainte. Conservez les preuves (journaux, systèmes touchés) : elles sont essentielles à l’analyse et à l’assurance.

6. Votre checklist anti-ransomware

7. Questions fréquentes

Cas concret : Exploitation & sécurisation d’un S.I critique multi-sites →

Trop souvent, la sécurité arrive en fin de projet — quand l’architecture est figée, le budget consommé et les délais tendus. Résultat : des rustines coûteuses, des compromis, et des failles qui auraient pu être évitées. Le Security by Design inverse la logique : on intègre la sécurité dès la première ligne du cahier des charges.

Bonne nouvelle : ce n’est pas une question d’outils coûteux, mais de réflexes. Voici les cinq qui changent la trajectoire de vos projets — et pourquoi les adopter tôt coûte bien moins cher que corriger tard.

1. Le Security by Design, c’est quoi ?

C’est un principe simple : concevoir un système en intégrant la sécurité à chaque étape de son cycle de vie, plutôt que de l’ajouter après coup. La sécurité devient une propriété intrinsèque de l’architecture — au même titre que la performance ou la disponibilité — et non un dispositif rapporté.

2. Pourquoi corriger tard coûte si cher

Plus une faille est détectée tard, plus elle est chère à corriger : il faut défaire, retester, redéployer, parfois sous la pression d’un incident. C’est toute la logique du « shift left » : déplacer l’effort de sécurité vers l’amont, là où il est le plus rentable.

3. Les 5 réflexes à adopter

4. Les idées reçues

5. Votre checklist Security by Design

6. Questions fréquentes

Cas concret : Audit & sécurisation de l’environnement cloud d’un grand établissement →

« On bascule les boîtes mail dans le cloud, c’est l’affaire d’un week-end. » C’est ainsi que commencent la plupart des migrations Microsoft 365 qui tournent mal : mails introuvables le lundi, utilisateurs bloqués, partages de fichiers ouverts à tous, sécurité restée à la porte. Une migration réussie n’est pas un copier-coller — c’est un projet piloté, où l’on prépare, on teste, on bascule par vagues, et on sécurise dès le premier jour.

Voici ce qu’on migre réellement, les approches possibles, et la méthode pour une bascule maîtrisée — sans perte de données ni faille ouverte.

1. Ce qu’on migre vraiment (pas seulement la messagerie)

Réduire Microsoft 365 à Outlook, c’est ignorer 80 % du projet. Une migration touche cinq chantiers interdépendants, et c’est leur coordination qui fait la réussite — ou l’échec.

2. Trois approches, trois niveaux de risque

3. La méthode en 5 phases

Quelle que soit l’approche, une migration maîtrisée suit toujours le même enchaînement. On ne bascule jamais avant d’avoir piloté.

La vague pilote (phase 3) est décisive : un groupe représentatif migre en premier, révèle les surprises (règles de messagerie, partages, apps tierces) et valide le mode opératoire avant le passage à l’échelle.

4. Sécuriser dès le premier jour

Une migration est le meilleur moment pour poser une base saine — bien plus difficile à corriger une fois tout le monde installé. Les fondamentaux à activer d’emblée :

• MFA pour tous : l’authentification multifacteur bloque l’immense majorité des piratages de compte.
• Accès conditionnel : restreindre les connexions selon l’appareil, le lieu ou le risque.
• Partages & invités maîtrisés : par défaut, on ne partage pas « à tout Internet » ; on cadre l’accès externe.
• Protection des données & sauvegarde : politiques de fuite (DLP) et sauvegarde tierce — le cloud n’est pas une sauvegarde.

5. Les idées reçues

6. Votre checklist migration

7. Questions fréquentes

Cas concret : Réassureur international — Migration full cloud & sécurisation →

Un incendie de datacenter, un ransomware, une simple erreur humaine… et toute l’activité s’arrête. La question n’est plus « si », mais « quand ». Un Plan de Reprise (PRA) et un Plan de Continuité (PCA) transforment une catastrophe potentielle en interruption maîtrisée. Encore faut-il les bâtir sur les bonnes bases — et les tester.

Beaucoup d’organisations pensent en avoir un… jusqu’au jour où il faut s’en servir. Voici comment poser un plan réellement fiable, en commençant par les deux chiffres qui structurent tout : le RTO et le RPO.

1. PRA, PCA : de quoi parle-t-on ?

Le PCA (Plan de Continuité d’Activité) vise à maintenir l’activité, même en mode dégradé, pendant l’incident — c’est la vue métier. Le PRA (Plan de Reprise d’Activité) vise à remettre le SI en service après un sinistre — c’est la vue technique.

2. Les 2 chiffres qui structurent tout : RTO et RPO

Avant toute solution technique, deux objectifs à fixer par service : combien de temps peut-on rester sans lui, et combien de données peut-on se permettre de perdre.

RPO (Recovery Point Objective) : la quantité de données que l’on accepte de perdre — pilotée par la fréquence des sauvegardes. RTO (Recovery Time Objective) : le délai maximal pour rétablir le service — piloté par la stratégie de reprise.

3. Par où commencer : la méthode en 5 étapes

4. La stratégie dépend du RTO visé

Plus le RTO est court, plus la solution est sophistiquée — et coûteuse. On dimensionne donc par criticité : les services vitaux d’abord.

5. Sauvegardes : la base non négociable

• Règle 3-2-1 : 3 copies, 2 supports, 1 hors site / hors ligne.
• Immuabilité : des copies que ni un attaquant ni une erreur ne peuvent modifier.
• Isolation : la sauvegarde n’est pas accessible avec les identifiants du SI courant.
• Tests de restauration réguliers : une sauvegarde jamais restaurée n’existe pas vraiment.

6. Les idées reçues

7. Votre checklist PRA / PCA

8. Questions fréquentes

Cas concret : Migration de datacenter & rebuild du S.I d’un groupe mutualiste →