Un directeur informatique m’a récemment montré fièrement son « cartable de politiques de sécurité ».
En l’ouvrant, j’ai trouvé 47 pages d’instructions détaillées sur comment configurer un coupe-feu, comment nommer les fichiers et comment effectuer une sauvegarde.
Ce n’était pas des politiques. C’était un regroupement de procédures.
Cette confusion est très répandue, même (surtout) dans des organisations certifiées ISO 27001. Et ça crée des problèmes : des documents impossibles à maintenir, des employés qui ne savent pas ce qu’on attend d’eux, et des auditeurs qui créent des non-conformités.
La distinction fondamentale
La politique dit QUOI. La procédure dit COMMENT.
C’est aussi simple que ça, mais ça change tout dans la façon dont vous structurez votre documentation de sécurité.
Une politique établit les règles, les attentes et les limites. Elle reflète les valeurs et les obligations légales de l’organisation. Elle s’adresse à tout le monde et ne change pas souvent.
Une procédure décrit les étapes concrètes pour accomplir une tâche précise. Elle s’adresse aux personnes qui exécutent cette tâche. Elle change chaque fois que le processus ou l’outil change.
Un exemple qui clarifie tout
Prenons la gestion des accès.
La politique dit :
« Tout accès aux systèmes de l’organisation doit être accordé selon le principe du moindre privilège et revu au minimum une fois par année. »
La procédure dit :
- Ouvrir le système de gestion des identités
- Sélectionner le compte concerné
- Vérifier les droits actifs selon la matrice des accès
- Documenter la révision dans le registre partagé
- Aviser le gestionnaire si un écart est détecté
Même sujet, deux niveaux complètement différents. La politique survit au changement d’outil. La procédure, elle, doit être mise à jour chaque fois que l’outil change.
Pourquoi la confusion coûte cher
Quand vous mélangez les deux, voici ce qui arrive en pratique :
- Vos politiques deviennent impossibles à approuver : la gestion doit valider chaque changement de détail technique, ce qui paralyse la mise à jour des documents
- Vos procédures deviennent rapidement obsolètes : elles sont enterrées dans des documents « officiels » que personne n’ose toucher
- Vos employés sont perdus : ils cherchent une règle claire et trouvent un manuel technique, ou l’inverse
- Vos auditeurs signalent des lacunes : ISO 27001 exige que vous puissiez démontrer que vos politiques existent ET que vos procédures sont appliquées. Si les deux sont fusionnés, rien n’est démontrable clairement
Comment structurer vos documents correctement
Une structure saine ressemble à ceci.
Niveau 1 : politique
Approuvée par la gestion, révisée annuellement.
- Courte : 1 à 3 pages maximum
- Langage de gestion, pas de technique
- Répond à : pourquoi, quoi, pour qui, quelles conséquences
Niveau 2 : procédure
Gérée par l’équipe informatique ou les responsables de processus, mise à jour au besoin.
- Aussi longue que nécessaire
- Langage opérationnel, étapes numérotées
- Répond à : comment, avec quoi, dans quel ordre, qui valide
Niveau 3 : instructions de travail ou guides (optionnel)
- Spécifiques à un outil, un système ou un contexte
- Captures d’écran, listes de vérification, formulaires
Les questions à vous poser pour chaque document
Avant de créer ou de classer un document, posez-vous :
- Est-ce que ça dit ce qui est attendu, ou comment le faire?
- Est-ce que la gestion doit approuver ça, ou l’équipe opérationnelle?
- Est-ce que ça change si on change d’outil?
- Est-ce que tous les employés doivent le lire, ou seulement ceux qui exécutent la tâche?
Si ça change dès qu’on change d’outil, c’est une procédure. Si la gestion doit l’approuver à chaque mise à jour, vous avez probablement fusionné les deux niveaux par erreur.
Une politique sans procédure, c’est une règle que personne ne sait appliquer. Une procédure sans politique, c’est une recette sans raison d’être.
Les deux sont nécessaires. Les deux jouent un rôle différent. Et les deux doivent être maintenus séparément pour rester utiles.
Bref, si votre politique fait plus de trois pages, elle contient probablement des procédures. Si votre procédure dit « l’organisation s’engage à », elle est devenue une politique.
Séparez les deux. Assignez un responsable à chaque niveau. Et assurez-vous que vos politiques sont lues par la gestion et vos procédures par les équipes qui les appliquent.
C’est une discipline simple, mais elle fait la différence entre une documentation qui sert à quelque chose et une documentation qui dort dans un dossier partagé que personne n’ouvre.
Votre cartable mélange les deux? Parlons-en.