La famille Processus & rituels répond à une tension que tout le monde connaît : la sécurité ralentit, donc on la met de côté quand il faut livrer. SOCLE refuse ce faux dilemme. Sa réponse tient en une idée : inscrire la sécurité dans les rituels existants de l'équipe (revue de code, planification, mise en production) plutôt que d'en faire une étape séparée qui s'ajoute et qu'on saute.
Une sécurité hors processus est, par construction, contournée à la première pression. Une sécurité intégrée au processus devient un réflexe invisible, qui ne coûte presque rien parce qu'elle se fait là où l'équipe travaille déjà. Toute la famille décline cette idée, depuis la présence dans les rituels jusqu'à l'amélioration continue pilotée par les incidents.
Concrètement, ces exigences parent : la sécurité hors processus systématiquement contournée, la gate désactivée en silence qui donne une fausse assurance, la dissimulation d'un post-mortem accusateur, et les mêmes incidents rejoués faute de boucle d'amélioration. Quatre exigences, des fondamentales (R1) aux souveraines (R3).
Une sécurité hors processus est contournée ; intégrée, elle devient un réflexe.
Les pièges à éviter
Section intitulée « Les pièges à éviter »Les erreurs les plus fréquentes sur ce périmètre :
Exigences
Section intitulée « Exigences »sécurité présente dans les rituels (revue, planification) sans bloquer la vélocité.#
Une sécurité vécue comme un frein est contournée ; absente des rituels, elle est oubliée. L'intégrer aux rituels (revue, planification) sans casser la vélocité la rend routinière et acceptée : elle devient un réflexe d'équipe plutôt qu'une étape subie imposée de l'extérieur.
- Preuve attendue
- Ordre du jour des rituels incluant la sécurité.
Correspondances & menaces parées 2 standards
gates de sécurité définies et acceptées (critères, exceptions tracées).#
Des gates de sécurité floues se rediscutent à chaque release et finissent contournées dans l'urgence. Les définir et les faire accepter d'avance (critères clairs, exceptions tracées) rend les décisions prévisibles : on sait ce qui bloque, et une dérogation reste un choix assumé et documenté.
- Preuve attendue
- Politique de gates ; registre des exceptions.
Correspondances & menaces parées 2 standards
rétrospectives post-incident sans recherche de coupable (blameless).#
La recherche de coupable après incident pousse à cacher les erreurs, et on rejoue les mêmes. Des rétrospectives sans blâme (blameless) libèrent la parole sur les causes réelles : on corrige le système plutôt que de punir l'individu, condition pour apprendre vraiment de chaque incident.
- Preuve attendue
- Comptes rendus post-incident blameless.
Correspondances & menaces parées 2 standards
amélioration continue pilotée par les retours d'incidents et d'audits.#
Sans boucle de retour, les leçons des incidents et des audits se perdent et les failles reviennent. Une amélioration continue pilotée par ces retours transforme chaque incident en correctif durable du processus : la posture progresse par apprentissage plutôt que de stagner entre deux crises.
- Preuve attendue
- Plan d'amélioration alimenté par incidents et audits.