Hermann N.

La norme impose la formalisation des processus liés à la sécurité de l'information — une condition indispensable de conformité et de reproductibilité. Lors du diagnostic, les clients découvrent presque systématiquement que cette formalisation n'existe nulle part par écrit, alors même que les pratiques, elles, existent souvent déjà sur le terrain.

La méthode se joue avant le diagnostic lui-même. Identifier toute la documentation existante permet de déterminer précisément les manquements — qui seront comblés ensuite, lors de la phase de conception du SMSI.

L'équipe projet reste trop souvent confinée à l'IT et à la sécurité, sans les métiers autour de la table. Le RSSI lui-même n'est pas toujours suffisamment formé aux exigences de la norme. Et quand les contrôles sont définis, leur responsabilité n'est presque jamais rattachée clairement au métier censé les porter au quotidien.

Rien de tout cela ne se rattrape après coup. Le sort du SMSI se joue dès le lancement : une direction visiblement impliquée — pas seulement sponsor sur le papier — et un projet communiqué haut et fort, pour que les métiers s'approprient les contrôles plutôt que de les subir.

La DNSSI est souvent mal lue : elle demande à bâtir sa propre échelle d'impacts — contexte, métiers, enjeux propres — et, en parallèle, à classifier selon le référentiel de la loi 05-20 pour identifier ce qui est sensible au sens de la loi. Dans la pratique, seule la grille réglementaire survit ; l'échelle propre à l'entité n'est jamais construite.

Construire sa propre échelle d'impacts donne un sens aux niveaux réglementaires qui suivent, plutôt que de les subir. Les deux classifications avancent en parallèle — mais l'une doit nourrir l'autre.

Chez les entités publiques soumises à la DNSSI, ou qui cherchent à s'y conformer, le plan d'action se réduit trop souvent à une liste d'actions déconnectées, répondant point par point aux règles du référentiel plutôt qu'à une logique d'ensemble.

Une feuille de route structurée par objectifs de maturité clairement définis change la donne : elle permet une amélioration progressive et durable de la sécurité — l'esprit même que la DNSSI cherche à instaurer, à l'opposé d'une liste de cases à cocher qui s'arrête le jour où l'audit est passé.

Le signal ne trompe pas : l'absence de PV de comité de sécurité ou de revue de direction. Les instances de gouvernance sont le cœur d'un SMSI — quand elles s'arrêtent, tout le reste s'essouffle avec elles.

Faire vivre le système commence par faire vivre ses instances : calendrier de comités non négociable, ordres du jour et comptes rendus systématiques — surtout quand rien de grave ne s'est produit entre deux réunions.

Demandez à un métier de chiffrer l'impact financier de la perte d'un de ses actifs informationnels : le silence est souvent la seule réponse. Ce n'est pas un détail méthodologique — c'est le signe direct d'une gestion des risques d'entreprise (ERM) absente, ou déconnectée des métiers.

Un chiffrage ne s'invente pas au niveau opérationnel. La direction doit valider elle-même les niveaux d'impact — financier en premier lieu — et les communiquer clairement aux métiers : sans ce cadrage porté au sommet, la classification reste théorique.

L'audit fournisseur bute sur toute la chaîne : sans clause d'auditabilité au contrat, il n'est même pas permis ; sans inventaire à jour ni critères d'évaluation, il n'est pas possible ; sans référentiel aligné sur la PSSI, il n'est pas comparable ; et externalisé, il coûte cher pour un rapport figé dans le temps — une photo du prestataire à l'instant T, incapable de dire si sa maturité progresse au même rythme que celle de l'entreprise qui l'a commandité.

Chaque maillon a sa réponse : clause d'auditabilité et de réversibilité dès la signature, inventaire des tiers tenu comme un actif vivant, questionnaires gradués par criticité, référentiel calqué sur la PSSI. Sur le coût et la valeur, c'est le problème que résout Rukn : un profil PSSI renseigné une fois, vérifié par un auditeur indépendant, réutilisable auprès de tous les commanditaires, avec un plan d'action livré avant signature.

Le one-shot : une formation, une fois, sans programme SETA (Security Education, Training & Awareness) clairement établi dans la durée. Et quand il y a un effort, il se limite souvent à des formations longues, sans exploiter les autres canaux de sensibilisation disponibles.

Un programme SETA vivant s'échelonne sur l'année, mêle formats courts et longs, canaux variés — et cible large, pas seulement l'équipe IT.