Sécurité by design vs sécurité a posteriori

Deux approches s’opposent en matière de sécurité : l’intégrer dès la conception ou l’ajouter après coup. La première demande un effort initial plus important mais produit des systèmes naturellement robustes. La seconde semble plus rapide mais génère une dette de sécurité qui finit toujours par se payer. Ce guide compare ces deux approches et montre pourquoi la sécurité by design est presque toujours préférable.

En résumé : La sécurité by design intègre la protection dès la conception (architecture, choix techniques). La sécurité a posteriori ajoute des couches de protection sur un système déjà construit. La première coûte moins cher et produit des systèmes plus robustes.

Qu’est-ce que la sécurité by design ?

La sécurité by design (ou security by design) consiste à intégrer les exigences de sécurité dès les premières phases d’un projet : conception, architecture, choix technologiques.

Principes fondamentaux :

• Réduction de la surface d’attaque : n’exposer que ce qui est strictement nécessaire
• Moindre privilège : chaque composant n’a que les droits dont il a besoin
• Défense en profondeur : plusieurs couches de protection indépendantes
• Valeurs par défaut sécurisées : le système est sécurisé sans configuration supplémentaire
• Échec sécurisé : en cas d’erreur, le système refuse l’accès plutôt que de l’autoriser

Ces principes ne sont pas des options ajoutées plus tard. Ils façonnent l’architecture dès le départ.

Qu’est-ce que la sécurité a posteriori ?

La sécurité a posteriori consiste à développer d’abord un système fonctionnel, puis à y ajouter des mesures de sécurité ensuite.

Manifestations courantes :

• Ajout d’un pare-feu applicatif (WAF) devant une application vulnérable
• Chiffrement ajouté après que les données circulent déjà en clair
• Audit de sécurité réalisé juste avant la mise en production
• Correctifs appliqués après découverte d’une faille
• Durcissement d’un serveur déjà en production

Cette approche traite les symptômes plutôt que les causes. Elle crée des couches de protection qui compensent des faiblesses structurelles.

Comparaison des deux approches

Aspect	Sécurité by design	Sécurité a posteriori
Moment d’intervention	Conception, architecture	Développement tardif, production
Coût de correction	Faible (décision de conception)	Élevé (refactoring, patches)
Efficacité	Traite les causes	Traite les symptômes
Couverture	Systémique	Ponctuelle
Maintenabilité	Architecture cohérente	Couches superposées
Dette technique	Minimale	Accumulation

Le coût de la correction selon le moment

Plus une faille est découverte tard, plus elle coûte cher à corriger :

Phase	Coût relatif de correction
Conception	1x
Développement	5x
Tests	10x
Production	30x
Après incident	100x+

Une décision d’architecture prise en 5 minutes peut nécessiter des semaines de refactoring si elle doit être corrigée en production.

Erreur fréquente

Penser que la sécurité a posteriori “rattrapera” les lacunes de conception. Un WAF ne corrige pas une injection SQL, il la masque. Un jour, le contournement sera trouvé.

Exemples concrets

Authentification

By design : L’architecture prévoit dès le départ un service d’authentification centralisé. Toutes les applications l’utilisent. Les tokens sont signés, les sessions gérées uniformément. Ajouter du MFA impacte un seul composant.

A posteriori : Chaque application gère sa propre authentification. Certaines stockent les mots de passe en MD5, d’autres en bcrypt, d’autres en clair. Ajouter du MFA nécessite de modifier chaque application. Certaines ne peuvent pas être modifiées (legacy). On ajoute un proxy d’authentification devant, créant une architecture incohérente.

Gestion des secrets

By design : Les secrets (clés API, mots de passe) ne sont jamais dans le code source. L’architecture prévoit un gestionnaire de secrets dès le départ. Les applications savent où chercher leurs credentials.

A posteriori : Les secrets sont dans le code, les fichiers de configuration, les variables d’environnement, parfois en clair dans les logs. On ajoute un gestionnaire de secrets, mais migrer les applications existantes prend des mois. Pendant ce temps, les anciens secrets restent exposés.

Journalisation

By design : Un format de log structuré est défini dès le départ. Chaque événement pertinent pour la sécurité est tracé avec les informations nécessaires (qui, quoi, quand, depuis où). Les logs sont centralisés et indexables.

A posteriori : Chaque composant log dans son format. Certains en texte, d’autres en JSON, d’autres pas du tout. Après un incident, on découvre qu’il manque des informations critiques. On ajoute des logs, mais l’historique est perdu.

Scénario 1 : L’application legacy

Une entreprise exploite une application métier développée il y a 10 ans. À l’époque, la sécurité n’était pas une priorité. L’application :

• Utilise des requêtes SQL construites par concaténation (injection SQL)
• Stocke les mots de passe en MD5 sans sel
• Expose une API sans authentification sur le réseau interne
• Tourne avec un compte administrateur système

L’équipe sécurité demande une remédiation. Options :

Option A — Correction a posteriori :

• Ajouter un WAF devant l’application (coût : 2 semaines)
• Forcer le renouvellement des mots de passe (coût : 1 semaine)
• Ajouter une authentification au niveau du reverse proxy (coût : 1 semaine)
• Créer un compte de service dédié (coût : 3 jours)
• Total : ~1 mois, failles structurelles toujours présentes

Option B — Refonte by design :

• Réécrire les requêtes avec des requêtes préparées
• Migrer vers bcrypt avec rotation progressive
• Implémenter une authentification native
• Appliquer le principe de moindre privilège
• Total : ~3 mois, mais problèmes résolus à la racine

L’option A est choisie pour des raisons de délai. Deux ans plus tard, une injection SQL est exploitée malgré le WAF (contournement). Le coût de l’incident dépasse largement celui de la refonte.

Scénario 2 : Le projet greenfield

Une équipe démarre un nouveau projet. Dès le kickoff, un architecte sécurité participe aux discussions.

Décisions prises en phase de conception :

• Authentification : utilisation d’un provider OIDC existant, pas de gestion de mots de passe dans l’application
• Autorisation : modèle RBAC défini dans un service dédié, pas de logique d’accès dispersée dans le code
• Secrets : intégration native avec le gestionnaire de secrets de l’entreprise
• Logs : format structuré JSON, événements de sécurité définis dans un schéma partagé
• Données sensibles : chiffrement au repos et en transit, colonnes PII identifiées dans le modèle de données

Résultat après 18 mois :

• Zéro faille critique découverte lors des audits
• Conformité réglementaire obtenue sans effort supplémentaire
• Temps de réponse aux incidents réduit grâce aux logs exploitables
• Coût de maintenance sécurité intégré dans le développement normal

Comment passer au security by design

Impliquer la sécurité dès le début

La sécurité n’est pas une validation finale. Elle participe aux :

• Revues d’architecture : identifier les risques structurels
• Choix technologiques : évaluer la posture sécurité des composants
• Définitions des stories : inclure les critères de sécurité dans le “done”

Définir des standards

Plutôt que de réinventer à chaque projet :

• Patterns d’authentification approuvés
• Méthodes de gestion des secrets standardisées
• Format de journalisation commun
• Checklist de conception sécurisée

Automatiser les vérifications

Intégrer les contrôles dans le pipeline :

• Analyse statique du code (SAST)
• Scan des dépendances vulnérables
• Vérification des configurations (IaC)
• Tests de sécurité automatisés

Ces contrôles détectent les régressions avant qu’elles n’atteignent la production.

À retenir

1. La sécurité by design intègre la protection dès la conception — elle traite les causes plutôt que les symptômes et produit des systèmes naturellement robustes.

2. La sécurité a posteriori compense des faiblesses structurelles — elle ajoute des couches de protection qui masquent les problèmes sans les résoudre.

3. Le coût de correction augmente exponentiellement avec le temps — une faille corrigée en conception coûte 1, en production elle coûte 30 ou plus.

4. Les systèmes legacy accumulent une dette de sécurité — chaque patch ajouté complexifie l’architecture sans éliminer les risques fondamentaux.

5. Passer au security by design nécessite un changement culturel — impliquer la sécurité dès le début, définir des standards, automatiser les vérifications.

Liens utiles

• Menace, risque, vulnérabilité, attaque — Comprendre les concepts pour concevoir sécurisé
• Pourquoi la sécurité échoue — Les dynamiques qui poussent vers le a posteriori
• Sécurité : une question de compromis — Arbitrer entre protection et contraintes
• Principes de sécurité — Les fondamentaux appliqués à l’infrastructure