SOCLE n'est pas qu'un référentiel : c'est une méthode pour s'en servir, ancrée sur le réel. Quatre temps qui forment un cycle : auditer la posture, transformer en comblant les écarts, capaciter l'organisation pour qu'elle tienne seule, et détecter et répondre quand un incident survient, pour en réapprendre. Le tout piloté par un modèle de maturité et une évaluation opposable - et priorisé par les incidents réels, pas par la théorie.
Le niveau R1/R2/R3 est une propriété de l'exigence : la hauteur de la barre, fixée par le référentiel (R1 fondamental, R2 renforcé, R3 souverain). La maturité M0 à M4 est une propriété de votre organisation sur un domaine : à quel point l'exigence est réellement tenue, et elle évolue dans le temps. En clair : R, c'est quoi viser ; M, c'est où vous en êtes.
Un exemple concret : l'exigence « SCA à chaque build » est de niveau R1. Une équipe peut la tenir à M1 (un développeur lance le scan à la main, de temps en temps) ou à M3 (un job bloquant en CI, tracé, sur tous les dépôts). Même exigence R1, deux maturités très différentes : on choisit d'abord ses niveaux R cibles (R1 partout pour commencer), puis on monte en maturité M sur cet ensemble, domaine par domaine.
L'échelle de maturité
Chaque domaine est noté de M0 à M4. On ne vise jamais M4 partout : la cible est différenciée par criticité de produit (tiering). La formule est simple : maturité actuelle x cible par tier = backlog priorisé.
Les quatre piliers
La méthode s'exécute en quatre piliers enchaînés qui forment une boucle. On ne saute pas l'audit : on mesure avant d'agir, on rend l'organisation autonome avant de partir, et on apprend de chaque incident pour relancer le cycle.
Évaluer la posture sur les 16 domaines, calculer le niveau atteint (R1/R2/R3) sur les DOIT, produire des preuves. Sur un grand portefeuille, on n'audite jamais tout à la main : on combine baseline automatisée et deep-dives ciblés. La priorisation ne sort pas d'un tableur abstrait : elle s'ancre sur les vecteurs d'attaque et les incidents réels du catalogue, pour viser d'abord ce qui casse vraiment.
- Cadrage & inventairePortefeuille, plateformes d'orchestration, chaînes de build, cibles de déploiement. Tiering : criticité x surface d'attaque.
- Baseline automatisée à l'échelleScan de posture (SCM, CI/CD, SCA, IaC, conteneurs) sur tous les dépôts et pipelines. Posture chiffrée sur tout le parc en quelques jours.
- Deep-dives ciblésAudit manuel approfondi sur un échantillon, tous les Tier 1 et la plateforme d'orchestration. Threat modeling léger, revue d'architecture.
- Synthèse & extrapolationPosture globale, écarts par domaine, risques systémiques.
- Feuille de route prioriséeBacklog par impact/effort, cibles par tier, restitution exécutive et technique.
LivrablesRapport d'audit (posture par domaine, top risques), cartographie de conformité CRA / NIS2-ReCyF, backlog chiffré, restitution COMEX et équipes, sortie SARIF quand c'est outillable.
Combler les écarts en livrant des actifs réutilisables (pas de la régie ouverte, des sprints cadrés). Un template corrigé corrige tous ses consommateurs : c'est l'effet de levier de la paved road.
LivrablesCode (templates, modules de politique, workflows de référence), documentation d'exploitation, transfert de compétence systématique.
Transformer une mission ponctuelle en relation durable : former, ancrer la culture (domaine CLT), rendre l'organisation autonome pour tenir le niveau seule.
Les trois premiers piliers construisent la posture ; celui-ci la tient quand un incident survient. Aucune chaîne n'est invulnérable : il faut détecter vite, répondre proprement, puis réapprendre. C'est là que les exigences d'observabilité, détection et réponse (domaines ORC et RUN) et le catalogue d'incidents prennent tout leur sens.
- DétecterObservabilité de la chaîne et du runtime ; alerting sur les comportements anormaux (egress, publication, usage de secrets).
- Qualifier & contenirÉvaluer le périmètre touché, isoler, couper les accès et révoquer les secrets compromis.
- Éradiquer & rétablirRetirer la charge, reconstruire depuis une base saine, vérifier la provenance avant de redéployer.
- RéapprendrePost-incident : le cas rejoint le catalogue et déclenche un audit ciblé. La boucle se referme sur le pilier Audit.
BoucleChaque incident réel nourrit la priorisation : on ne durcit pas dans l'abstrait, on ferme d'abord les portes par lesquelles d'autres sont déjà passés.
Une évaluation opposable
Un audit ne vaut que s'il est vérifiable. SOCLE définit un format d'évaluation « as code » : chaque exigence reçoit un statut, et le niveau atteint se calcule sans interprétation.
Le niveau atteint est le plus haut R dont toutes les exigences DOIT de niveau inférieur ou égal sont satisfaites (conforme ou non applicable), borné par le plus haut niveau présent dans le périmètre. Les DEVRAIT n'entrent pas dans le calcul. Niveau 0 = non atteint.
Pour qu'un score soit opposable (et pas du marketing), quatre garde-fous :
Prochaines étapes
Mettre la méthode en pratique
Section intitulée « Mettre la méthode en pratique »La méthode se déploie sur le référentiel : on audite chaque domaine, on cible un niveau par exigence, puis on suit la trajectoire. Voici par où poursuivre.