Les deux premiers articles de cette série ont posé le cadre (NIS 2 et vos terminaux) puis détaillé les 8 chantiers du ReCyF applicables aux endpoints. Il est temps de passer à l'action : voici un template de conformité que vous pouvez utiliser tel quel ou adapter à votre organisation.
Ce template couvre les 8 objectifs du ReCyF v2.5 qui touchent directement les terminaux mobiles. Pour chaque objectif, vous trouverez ce que l'ANSSI attend, ce que votre MDM peut couvrir, et ce qui relève de vos processus internes.
Comment utiliser ce template
Chaque objectif est présenté sous la forme d'une checklist. Trois colonnes :
- Exigence ReCyF : ce que le référentiel demande, reformulé sans jargon
- Couvert par le MDM : ce que votre outil de gestion de flotte peut automatiser
- Action manuelle requise : ce qui nécessite un processus documenté, une validation humaine, ou un outil complémentaire
Commencez par parcourir la liste et cochez ce qui est déjà en place chez vous. Les cases non cochées sont votre feuille de route.
Objectif 5 : inventaire et maintien en condition
Cartographie des terminaux
- ☐ Tous les terminaux accédant au SI sont inventoriés (modèle, OS, propriétaire)
- ☐ L'inventaire est mis à jour automatiquement (pas de tableur manuel)
- ☐ Les appareils personnels (BYOD) sont identifiés séparément des appareils corporate
MDM : l'inventaire automatique couvre les trois points. Chaque appareil enrôlé remonte modèle, version OS, numéro de série, et type de propriété.
Patching et mises à jour
- ☐ Une politique de mise à jour OS est définie (délai max après publication éditeur)
- ☐ Les mises à jour critiques sont forcées sous 14 jours
- ☐ Un reporting de conformité patch est disponible (% de flotte à jour)
MDM : politiques de mise à jour forcée avec délai de grâce configurable. Le reporting est natif.
Action manuelle : définir le SLA de patching dans votre politique de sécurité (ex : 7 jours pour les correctifs critiques, 30 jours pour les autres).
Objectif 9 : protection contre les codes malveillants
- ☐ Les sources d'installation d'applications sont restreintes (App Store, Play Store, store privé uniquement)
- ☐ L'installation depuis des sources inconnues est bloquée sur Android
- ☐ La détection de jailbreak/root est activée
- ☐ Un appareil compromis (jailbreak, root, politique non conforme) est automatiquement isolé ou signalé
MDM : restriction des sources d'installation, détection jailbreak/root, actions automatiques de remédiation (quarantaine, notification admin, wipe des données pro).
Action manuelle : pour les entités essentielles, documenter la procédure d'isolation d'un appareil compromis et désigner un responsable d'escalade.
Objectif 18 : durcissement de la configuration
Chiffrement
- ☐ Le chiffrement du stockage est actif sur tous les terminaux
- ☐ Un appareil non chiffré est bloqué ou signalé
Politique de verrouillage
- ☐ Code de verrouillage obligatoire (6 caractères minimum recommandé)
- ☐ Verrouillage automatique après 5 minutes d'inactivité maximum
- ☐ Effacement après 10 tentatives échouées (appareils corporate)
Restrictions
- ☐ Les services non nécessaires sont désactivés (AirDrop, partage de connexion, Bluetooth selon contexte)
- ☐ La sauvegarde iCloud/Google des données d'entreprise est contrôlée
- ☐ Un référentiel de configuration documenté existe
MDM : profils de configuration appliqués dès l'enrôlement. Chiffrement vérifié en continu, code de verrouillage imposé, restrictions déployées par groupe d'appareils.
Action manuelle : rédiger le référentiel de configuration (document de référence listant les paramètres cibles par type d'appareil). Le MDM applique ; le document officialise.
Objectif 10 : gestion des identités et des accès
- ☐ L'accès aux applications d'entreprise est conditionné par l'enrôlement MDM
- ☐ L'authentification multifacteur est active pour les accès sensibles (messagerie, VPN, console admin)
- ☐ Les comptes utilisateurs sont liés à un annuaire centralisé (Active Directory, Google Workspace, Okta)
- ☐ Un processus de révocation existe : quand un collaborateur part, ses accès mobiles sont coupés sous 24h
MDM : le store applicatif privé conditionne l'accès aux apps par l'enrôlement. Le wipe sélectif des données pro est disponible pour le départ d'un collaborateur.
Action manuelle : intégrer la révocation MDM dans votre procédure de départ RH (offboarding checklist). L'authentification MFA dépend de votre fournisseur d'identité, pas du MDM seul.
Objectif 8 : sécurisation des accès distants
- ☐ Un VPN d'entreprise (ou accès Zero Trust) est configuré sur les terminaux mobiles
- ☐ Le certificat d'authentification est provisionné automatiquement à l'enrôlement
- ☐ Les connexions VPN sont tracées (logs exploitables)
- ☐ Le per-app VPN est configuré pour les applications sensibles (seul le trafic pro passe par le tunnel)
MDM : déploiement de profils VPN, provisionnement automatique des certificats, per-app VPN.
Action manuelle : choisir et configurer l'infrastructure VPN ou Zero Trust. Le MDM distribue la configuration, mais ne fournit pas le serveur VPN lui-même.
Objectif 11 : maîtrise de l'administration
- ☐ Les administrateurs MDM utilisent des comptes dédiés (pas leur compte utilisateur courant)
- ☐ Les rôles sont séparés dans la console MDM (lecteur, opérateur, administrateur)
- ☐ Les actions critiques (wipe, désenrôlement) nécessitent une authentification renforcée
- ☐ Les logs d'administration sont conservés et consultables
- ☐ Une revue des droits d'accès admin est effectuée tous les 6 mois
MDM : gestion des rôles, logs d'audit, authentification renforcée pour les actions sensibles.
Action manuelle : planifier la revue semestrielle des droits. Documenter qui a accès à quoi et pourquoi.
Objectif 12 : gestion des incidents de sécurité
- ☐ Une procédure de réponse aux incidents mobiles est documentée (perte, vol, compromission)
- ☐ Le MDM déclenche des alertes automatiques sur les événements critiques (jailbreak, non-conformité, absence prolongée de mise à jour)
- ☐ Un processus de verrouillage/wipe à distance est opérationnel et testé
- ☐ Les incidents sont tracés dans un registre (date, appareil, action prise, résolution)
- ☐ Pour les EE : les événements de sécurité des terminaux alimentent un SIEM ou un outil de log management
MDM : alertes automatiques, verrouillage/wipe à distance, télémétrie de conformité.
Action manuelle : rédiger la procédure d'incident. Désigner les rôles (qui reçoit l'alerte, qui décide du wipe, qui informe l'ANSSI si nécessaire). Tester le processus au moins une fois par an avec un exercice simulé.
Objectif 13 : sauvegardes et tests de restauration
- ☐ Les données critiques ne résident pas sur les terminaux (messagerie synchronisée, fichiers dans le cloud, apps métier côté serveur)
- ☐ La configuration MDM (profils, politiques, listes d'apps) est sauvegardée régulièrement
- ☐ Un test de restauration d'un terminal est réalisé au moins une fois par an (enrôlement d'un appareil neuf, vérification que l'environnement de travail est reconstitué)
MDM : l'architecture même du MDM (configurations centralisées, apps distribuées depuis le store) garantit qu'un terminal perdu peut être remplacé en quelques heures.
Action manuelle : sauvegarder la configuration de la console MDM elle-même (export des profils, des groupes, des politiques). Planifier le test annuel de restauration.
Votre score de conformité endpoint
Comptez vos cases cochées. Ce template contient 35 items. Voici comment lire votre score :
- 30-35 items : vous êtes prêt pour un contrôle ANSSI. Formalisez vos preuves.
- 20-29 items : les fondations sont là. Concentrez-vous sur les gaps dans les objectifs 12 (incidents) et 11 (administration), souvent les moins matures.
- 10-19 items : le MDM couvre probablement la partie technique, mais les processus documentés manquent. C'est normal : la plupart des ETI sont ici.
- Moins de 10 : commencez par l'objectif 5 (inventaire) et l'objectif 18 (durcissement). Sans ces deux-là, le reste est fragile.
Le score n'est pas une fin en soi. L'ANSSI ne va pas vérifier vos cases cochées. Ce qui compte, c'est la capacité à prouver que vous avez identifié les risques, mis en place des mesures proportionnées, et que vous pouvez les documenter. Ce template vous donne la structure ; les preuves, c'est votre quotidien opérationnel.
Récapitulatif de la série NIS 2
Cette série en trois articles vous a accompagné du « pourquoi » au « comment faire » :
- NIS 2 et vos terminaux : pourquoi vos smartphones pro sont un sujet de conformité
- Les 8 chantiers du ReCyF : les objectifs de sécurité qui touchent vos endpoints, priorisés en trois vagues
- Ce template : la checklist opérationnelle pour passer de la théorie à la pratique
La conformité NIS 2 n'est pas un projet ponctuel. C'est un cycle : inventorier, configurer, surveiller, documenter, réviser. Un MDM bien configuré automatise la partie technique. Le reste, les processus, la documentation, les revues, c'est ce qui transforme un outil en posture de sécurité.
Cet article propose une lecture pédagogique du ReCyF v2.5 (17/03/2026). Il ne se substitue pas à une analyse de conformité formelle ni au texte officiel publié par l'ANSSI. Consultez le ReCyF complet sur MesServicesCyber.