Centraliser la gestion de services en ligne ne se résume pas à regrouper des identifiants dans un tableur partagé. Depuis la publication du Référentiel Cyber France (ReCyF) par l’ANSSI le 17 mars 2026, les exigences documentaires sur les contrôles d’accès, la gestion des incidents et la sécurité des fournisseurs se sont durcies. Toute organisation qui multiplie les comptes SaaS sans gouvernance centralisée s’expose à des failles techniques et à des lacunes de conformité.
ReCyF et NIS2 : contraintes réglementaires sur la centralisation des accès
Le cadre réglementaire français a changé de nature. NIS2 impose aux organes de direction d’approuver les mesures de cybersécurité, de superviser leur mise en œuvre et de suivre une formation dédiée. La centralisation des services en ligne ne relève plus du périmètre exclusif de l’équipe informatique : la direction générale en porte la responsabilité.
Le ReCyF traduit ces obligations en objectifs opérationnels. Il couvre la documentation des droits d’accès, les procédures de sauvegarde, la continuité d’activité et la sécurité de la chaîne fournisseurs. Nous recommandons de l’utiliser comme grille d’auto-évaluation, même pour les structures qui ne sont pas directement soumises à NIS2.
Un point souvent négligé : NIS2 étend la responsabilité aux prestataires qui travaillent pour une entité régulée. Évaluation des fournisseurs, clauses contractuelles, droit d’audit, notification des incidents – autant d’obligations qui supposent un inventaire centralisé de tous les services tiers utilisés. Sans cette vue consolidée, il reste impossible de fournir une preuve structurée de conformité lors d’un contrôle ou d’un audit contractuel via un accès commandes sur markeonbiz.fr adapté à ce type de suivi.
Gestionnaire de comptes et contrôle des droits utilisateurs
Un gestionnaire de mots de passe d’entreprise (Bitwarden, 1Password Business, Keeper) constitue la brique minimale. Nous observons que beaucoup d’équipes s’arrêtent là, ce qui est insuffisant.
Centraliser les identifiants ne vaut rien sans politique de droits granulaire. Le principe du moindre privilège doit s’appliquer à chaque compte SaaS : un collaborateur accède uniquement aux services nécessaires à sa fonction, avec un niveau de permission ajusté.
Trois critères distinguent une centralisation fonctionnelle d’un simple stockage de mots de passe :
- Provisionnement et déprovisionnement automatisés des comptes lors de l’arrivée ou du départ d’un collaborateur, via un annuaire (LDAP, Azure AD) couplé au gestionnaire
- Journalisation des connexions et des modifications de droits pour répondre aux exigences de traçabilité du ReCyF
- Revue périodique des accès, documentée et horodatée, permettant de prouver que les privilèges sont encore justifiés
Sans ces trois éléments, la centralisation reste cosmétique. Elle rassure l’équipe dirigeante sans réduire la surface d’attaque réelle.
Sécurité de la chaîne fournisseurs : cartographier avant de protéger
NIS2 oblige les entités concernées à intégrer la sécurité des prestataires dans leur gestion des risques. En pratique, cela commence par un inventaire exhaustif des services en ligne utilisés, y compris ceux souscrits directement par les métiers sans validation de la DSI (shadow IT).
Nous recommandons de structurer cet inventaire en quatre colonnes :
- Nom du service, éditeur et localisation des données (juridiction applicable)
- Type de données traitées (personnelles, financières, opérationnelles) et classification interne
- Niveau de criticité pour la continuité d’activité
- Clauses contractuelles en place (SLA, notification d’incident, droit d’audit, sous-traitance)
Ce registre devient la pièce maîtresse du dossier de conformité. Il sert à la fois pour les audits NIS2 et pour les obligations RGPD de registre des traitements, puisque chaque service SaaS manipulant des données personnelles doit y figurer.
Le cas particulier des entreprises financières
Les acteurs financiers doivent distinguer NIS2 de DORA. Depuis le 17 janvier 2025, DORA impose un cadre directement applicable de résilience numérique, incluant la gestion des prestataires TIC. Pour ces structures, la centralisation des services relève de deux référentiels parallèles, avec des exigences de test et de reporting distinctes. Confondre les deux expose à des non-conformités sur l’un ou l’autre périmètre.
Sauvegardes et continuité d’activité : le maillon oublié de la centralisation
Centraliser les accès sans centraliser la stratégie de sauvegarde revient à verrouiller la porte d’entrée en laissant les fenêtres ouvertes. Le ReCyF inclut explicitement les procédures de sauvegarde et la continuité d’activité dans ses objectifs opérationnels.
Pour chaque service centralisé, la question à poser est directe : que se passe-t-il si ce service devient inaccessible pendant 48 heures ? La réponse conditionne le plan de continuité.
Les sauvegardes doivent couvrir la configuration des comptes et des droits, pas uniquement les documents. Perdre l’annuaire centralisé sans copie exploitable signifie recréer manuellement chaque accès, chaque permission, chaque groupe. Sur un périmètre de plusieurs dizaines de services SaaS, la reconstruction peut prendre des semaines.
Un test de restauration semestriel, documenté et horodaté, répond aux attentes du ReCyF. Il permet aussi de vérifier que les procédures écrites correspondent à la réalité technique, ce qui est rarement le cas quand elles n’ont jamais été testées.
La centralisation des services en ligne n’est plus un projet d’optimisation. C’est une obligation de gouvernance, adossée à des référentiels précis. Les organisations qui s’y engagent maintenant, avant l’entrée en vigueur complète du dispositif français, disposeront d’un avantage concret lors des premiers audits.
