On entend encore trop souvent que la sécurité bloque les projets.
C’est une phrase pratique. Elle permet de désigner un coupable clair, identifiable, souvent extérieur à l’équipe projet.
Le projet avance, puis “la sécu” arrive.
Elle pose des questions.
Elle demande des corrections.
Elle refuse une mise en production.
Elle réclame une analyse complémentaire.
Conclusion rapide : la sécurité ralentit tout le monde.
Sauf que, dans beaucoup de cas, ce n’est pas exactement ce qui se passe.
Ce qui bloque réellement les projets, ce n’est pas la sécurité.
C’est le flou.
Le flou dans les règles.
Le flou dans les responsabilités.
Le flou dans les critères de validation.
Le flou dans les délais.
Le flou dans les exceptions.
Le flou dans le niveau de risque acceptable.
Et quand tout est flou, la sécurité devient mécaniquement le moment où le problème apparaît.
Pas forcément le moment où il a été créé.
Le faux problème : “la sécurité bloque”
Dire que la sécurité bloque les projets, c’est souvent confondre la cause et le symptôme.
Oui, une équipe sécurité peut bloquer un déploiement.
Oui, elle peut demander des corrections.
Oui, elle peut refuser une architecture ou une exposition publique.
Oui, elle peut ralentir une mise en production.
Mais la vraie question est rarement :
“Pourquoi la sécurité bloque ?”
La vraie question devrait plutôt être :
“Pourquoi découvre-t-on ce problème aussi tard ?”
Parce que si un projet arrive en phase finale avec :
- une exposition Internet non prévue
- des données sensibles mal identifiées
- aucun modèle de menace
- des secrets stockés n’importe où
- une architecture non documentée
- des droits IAM trop larges
- aucun monitoring
- aucun plan de rollback
- aucune validation de conformité
- des dépendances critiques non maîtrisées
le problème n’est pas que la sécurité “bloque”. Le problème, c’est que le projet a avancé pendant des semaines ou des mois sans garde-fous clairs.
Et à la fin, quelqu’un découvre que le risque est trop élevé.
Le flou crée de la dette organisationnelle
On parle souvent de dette technique.
On parle aussi de dette sécurité.
Mais il existe une autre forme de dette, beaucoup plus insidieuse : la dette organisationnelle.
Elle apparaît quand les règles existent quelque part, mais que personne ne sait vraiment :
- où les trouver
- à qui elles s’appliquent
- si elles sont obligatoires
- comment les interpréter
- qui peut accorder une exception
- combien de temps prend une validation
- à quel moment contacter la sécurité
- ce qui est bloquant ou non bloquant
Résultat : chacun avance avec sa propre interprétation.
Les équipes produit pensent être dans les clous.
Les équipes techniques pensent avoir fait “comme d’habitude”.
Les équipes sécurité pensent que les règles sont connues.
Le management pense que le sujet est maîtrisé.
Et tout le monde découvre trop tard que ce n’était pas le cas.
Ce n’est pas un problème de mauvaise volonté.
C’est un problème d’organisation.
Des règles floues produisent des décisions floues
Une règle sécurité qui n’est pas claire est souvent pire qu’une règle absente.
Parce qu’elle donne l’illusion d’un cadre.
Prenons un exemple classique :
“Les accès doivent être sécurisés.”
Très bien. Mais ça veut dire quoi?
- MFA obligatoire?
- SSO obligatoire?
- Pas de compte local?
- Pas de compte partagé?
- Rotation des secrets?
- Accès conditionnel?
- Bastion?
- VPN?
- Just-in-time access?
- Revues périodiques?
Autre exemple :
“Les données sensibles doivent être protégées.”
Là encore, très bien. Mais quelles données?
- Données personnelles?
- Données clients?
- Données financières?
- Données internes?
- Données contractuelles?
- Données techniques?
- Logs applicatifs?
Et “protégées”, ça veut dire quoi?
- Chiffrement au repos?
- Chiffrement en transit?
- Tokenisation?
- Restriction d’accès?
- Audit trail ?
- DLP?
- Durée de rétention limitée?
- Environnement isolé?
Quand une règle peut être interprétée de dix façons différentes, il ne faut pas s’étonner que dix équipes l’appliquent différemment.
Une règle bien écrite ne doit pas laisser de place à l’interprétation.
Elle doit permettre à une équipe de comprendre ce qui est attendu, ce qui est recommandé, ce qui est obligatoire et ce qui est interdit.
Sinon, le jour où la sécurité tranche, la décision semble arbitraire.
Pas parce qu’elle l’est forcément.
Mais parce que le cadre n’a jamais été rendu explicite.
Un processus opaque est vécu comme un mur
Un autre problème très courant : le processus de validation sécurité existe, mais il est opaque.
Les équipes savent qu’elles doivent “voir avec la sécurité”.
Mais elles ne savent pas vraiment :
- quand le faire
- par quel canal
- avec quelles informations
- sous quel délai
- avec quel niveau de détail
- avec quels critères de décision
- avec quelles conséquences si un point est refusé
Dans ce contexte, la sécurité est vécue comme une boîte noire.
On envoie une demande.
On attend.
On reçoit des questions.
On répond.
On attend encore.
Puis on reçoit parfois un avis défavorable, une liste de corrections, ou une demande d’analyse supplémentaire.
Même quand la décision est justifiée, l’expérience est mauvaise.
Et quand l’expérience est mauvaise, les équipes contournent.
Pas forcément par malveillance, plus souvent par fatigue.
Elles apprennent que “passer par la sécurité” est lent, incertain et pénible.
Donc elles essayent de l’éviter jusqu’au dernier moment.
Puis la sécurité arrive, tard, et bloque. Tout le monde confirme son biais initial et cela crée une boucle toxique interminable.
L’absence de SLA détruit la confiance
Un point souvent sous-estimé : les délais de réponse.
Une équipe projet peut gérer une contrainte sécurité.
Elle peut gérer une correction technique.
Elle peut gérer une validation obligatoire.
Ce qu’elle gère beaucoup moins bien, c’est l’incertitude.
Si une équipe ne sait pas si la sécurité va répondre en deux jours, deux semaines ou jamais, elle ne peut pas planifier correctement.
Et quand elle ne peut pas planifier, elle prend des raccourcis.
Un processus sécurité sans SLA est un processus qui crée naturellement de la frustration.
Pas besoin d’un SLA ultra-complexe.
Mais il faut au minimum être clair sur quelques engagements :
- accusé de réception sous X jours
- premier retour sous X jours
- délai cible selon le type de demande
- niveau d’urgence accepté
- critères d’escalade
- responsabilités côté projet
- responsabilités côté sécurité
La sécurité n’a pas besoin de promettre l’impossible.
Elle doit surtout éviter le silence radio.
Parce que du point de vue d’une équipe projet, une absence de réponse est déjà une forme de blocage.
Quelques signaux que votre sécurité est trop floue
Il existe des symptômes assez faciles à reconnaître.
Si vous entendez régulièrement :
“On ne savait pas qu’il fallait vous contacter.”
“On découvre les règles maintenant.”
“La sécurité a dit non, mais on ne sait pas quoi faire.”
“On va passer en prod et on régularisera après.”
Alors le problème n’est probablement pas uniquement culturel.
Il y a probablement un problème de clarté, de processus ou de capacité.
Et il faut le traiter comme tel.
Le flou arrange parfois tout le monde
Il faut aussi être honnête : le flou n’existe pas toujours par accident.
Parfois, il arrange.
Il arrange les équipes qui veulent avancer sans contrainte.
Il arrange les managers qui ne veulent pas arbitrer.
Il arrange les organisations qui préfèrent éviter les décisions difficiles.
Il arrange même parfois la sécurité, qui peut garder une marge d’interprétation confortable.
Mais ce confort est temporaire.
Le flou finit toujours par coûter cher.
Il coûte en retards.
Il coûte en frustrations.
Il coûte en escalades.
Il coûte en contournements.
Il coûte en dette technique.
Il coûte en exposition au risque.
Et parfois, il coûte en incident.
La clarté demande un effort au départ.
Mais elle évite beaucoup de chaos ensuite.
Conclusion
La sécurité ne bloque pas les projets par nature.
Ce qui bloque les projets, c’est souvent le flou accumulé autour de la sécurité :
- règles imprécises
- processus opaques
- absence de SLA
- critères inconnus
- responsabilités mal définies
- exceptions mal cadrées
- arbitrages jamais assumés
Une sécurité efficace n’est pas une sécurité molle.
C’est une sécurité claire.
Elle sait dire ce qui est attendu, ce qui est obligatoire, ce qui est acceptable et ce qui ne l’est pas.
Et surtout, elle évite de transformer chaque validation en surprise de dernière minute.
Parce qu’au fond, les équipes projet peuvent vivre avec des contraintes.
Ce qu’elles supportent beaucoup moins, c’est de découvrir les règles une fois la partie presque terminée.
La sécurité ne bloque pas les projets.
Le flou, oui.
Dans un prochain article, je reviendrai sur un point directement lié : pourquoi une sécurité consultée trop tard devient presque toujours brutale, même quand elle a raison.
