Trois entreprises, trois secteurs
Trois politiques de sécurité pour comprendre pourquoi la première n'était pas appliquée
Comment écrire une politique de sécurité que les équipes appliquent, plutôt qu'une politique qu'elles signent.
Le premier corpus était aligné sur ISO 27001. Rien à lui reprocher sur le fond : périmètre correct, domaines couverts, contrôles traçables. Il a été validé, diffusé, et il n’a pas changé grand-chose. Le deuxième a ajouté l’alignement sur les contraintes métiers, et c’est là que les exigences ont commencé à être discutées plutôt qu’acceptées poliment — signe qu’elles étaient enfin lues. Le troisième a ajouté l’alignement sur les exigences réglementaires du secteur, et le débat s’est déplacé une dernière fois : il n’était plus de savoir si la règle s’appliquait, mais comment.
Chacun de ces corpus comprenait une politique de sécurité générale, une quinzaine de politiques thématiques, les guidelines qui déclinent leurs exigences et les baselines qui les adaptent aux contraintes opérationnelles des équipes — plus les chartes informatiques, dont une charte d’usage de l’intelligence artificielle.
Ce que ces trois passages ont décanté tient dans un modèle réutilisable : une politique de sécurité alignée sur ISO 27001, structurée pour recevoir les deux couches suivantes sans être réécrite.
Ce qui est réutilisable
L’alignement sur la norme ne suffit pas à faire appliquer une politique. C’est la leçon des trois passages, et elle ne s’est pas vue au premier. Une politique alignée sur ISO 27001 est complète, défendable en audit, et inapplicable : elle décrit ce qu’il faut obtenir sans rien dire de ce que cela coûte à ceux qui doivent l’obtenir. Elle est donc signée, publiée, et jamais ouverte.
Trois couches, dans cet ordre, et l’ordre compte :
- la norme donne la charpente — le périmètre, les domaines, la logique de contrôle. Sans elle, le corpus est une collection d’avis ;
- les contraintes métiers rendent la politique applicable. C’est la couche qui transforme « les accès sont revus périodiquement » en une exigence dont l’équipe qui la subit reconnaît qu’elle est tenable ;
- les exigences réglementaires du secteur la rendent non négociable. Tant qu’une règle n’est qu’une bonne pratique, elle s’arbitre contre un délai projet et elle perd. Adossée à un texte, elle change d’interlocuteur et de niveau d’arbitrage.
Inverser l’ordre ne marche pas. Partir du réglementaire produit un corpus défensif que personne ne s’approprie ; partir du métier produit un corpus confortable qui ne passe pas l’audit.
Le corollaire opérationnel : une politique n’est rien sans ses deux étages inférieurs. Les guidelines déclinent l’exigence en pratique, les baselines l’adaptent aux contraintes réelles des équipes. Une politique seule laisse l’interprétation à celui qui a le moins de temps pour la faire.
Le test : demander à l’équipe visée de citer de mémoire la règle qui la concerne. Si elle ne peut pas, la règle n’existe pas — elle est écrite, c’est tout.