- Marriott/Starwood (2018) : la présence de l\'attaquant pendant quatre ans sans détection a exposé 500 millions de personnes dont les données n\'étaient pas uniformément chiffrées dans les systèmes Starwood — des données qui auraient dû être protégées lors de l\'intégration post-acquisition mais ne l\'ont jamais été.
- Le déploiement tardif du chiffrement coûte systématiquement plus cher que le déploiement préemptif — rétrofiter le chiffrement sur des systèmes existants en production requiert des arrêts planifiés, des migrations de données et des tests de régression que la conception initiale aurait évités.
- Les exceptions de performance sont le principal mécanisme du déploiement tardif : le chiffrement est désactivé pour des raisons de latence ou de throughput lors du déploiement initial, avec l\'intention de le réactiver "quand les performances seront améliorées" — une intention qui n\'est jamais suivie d\'effet.
- La pression des délais de mise en production est un facteur structurel : les équipes de développement qui travaillent sous contraintes temporelles déprioritisent systématiquement les exigences de sécurité non bloquantes — dont le chiffrement fait partie lorsqu\'il n\'est pas dans les critères d\'acceptation.
- L\'absence de critères d\'acceptation liés au chiffrement dans les processus de validation des nouvelles fonctionnalités est la cause organisationnelle la plus fréquente du déploiement tardif.
- Les outils de SAST et de CSPM intégrés dans les pipelines CI/CD permettent de bloquer les déploiements sans chiffrement — une approche "shift left" qui traite le chiffrement comme une exigence non négociable.
Le déploiement tardif du chiffrement suit des patterns organisationnels précis qui se répètent dans les organisations de tailles et de secteurs différents. Ce n\'est pas une question de compétence ou de volonté — les équipes connaissent l\'importance du chiffrement. C\'est une question de priorisation et d\'incentives : dans les organisations qui n\'ont pas intégré le chiffrement dans leurs critères de livraison, il est systématiquement déprioritisé face aux exigences fonctionnelles qui, elles, bloquent la mise en production.
Pour un RSSI ou un architecte sécurité, identifier les mécanismes précis qui produisent le déploiement tardif dans leur organisation est la condition préalable à leur correction. Les approches génériques ("sensibiliser les développeurs à la sécurité") ont des effets limités sur des mécanismes structurels qui peuvent être traités par des changements de processus et d\'outillage.
Les mécanismes organisationnels du déploiement tardif
L\'absence de critères d\'acceptation liés au chiffrement est le mécanisme organisationnel le plus courant. Lorsque les user stories et les critères de définition of done (DoD) ne mentionnent pas le chiffrement, les développeurs ne peuvent pas être tenus responsables de son absence — et dans un contexte de pression calendaire, ce qui n\'est pas un critère d\'acceptation n\'est pas livré.
La revue de sécurité placée après la mise en production est un autre mécanisme fréquent. Dans les organisations où la revue de sécurité est une étape optionnelle ou post-production, les problèmes de chiffrement identifiés créent des "security debt items" qui rejoignent des backlogs de remédiation jamais prioritisés face aux nouvelles fonctionnalités. L\'ancienneté de ces items croît jusqu\'à ce qu\'un incident force la remédiation dans les pires conditions.
La violation Citibank de 2011 (360 000 comptes via traversal d\'API) illustre le résultat d\'un déploiement de l\'API sans les contrôles d\'autorisation appropriés — une décision qui a probablement été une déprioritisation lors du déploiement initial, avec l\'intention de traiter la sécurité dans une version ultérieure. Les APIs déployées sans autorisation fine au niveau des ressources individuelles constituent un pattern fréquent de dette de sécurité créée lors du déploiement initial. La correction — implémenter une validation d\'autorisation objet-par-objet — est triviale à écrire mais nécessite un arrêt et un test de régression significatif en production. Cette complexité de la remédiation est précisément ce que la conception sécurisée initiale aurait évité.
Les mécanismes techniques du déploiement tardif
Les exceptions de performance sont le mécanisme technique le plus fréquent. Lors des phases de test de charge et de performance, le chiffrement — qui ajoute une latence mesurable, particulièrement sur les systèmes à fort volume de transactions — est parfois désactivé pour atteindre les benchmarks de performance requis. Si cette désactivation n\'est pas explicitement reversée avant la mise en production, le système est déployé sans chiffrement.
La complexité d\'intégration est un autre mécanisme technique. Le chiffrement de données dans des systèmes qui ont plusieurs consommateurs — des applications qui lisent et écrivent dans la même base de données — requiert que tous les consommateurs soient mis à jour simultanément pour gérer le chiffrement. Cette coordination inter-équipes est souvent plus difficile à organiser que la mise à jour d\'un seul système, conduisant à des reports répétés qui transforment une décision temporaire en état permanent.
Le shift-left du chiffrement : les approches qui fonctionnent
Les approches efficaces pour traiter le déploiement tardif du chiffrement sont celles qui le transforment de contrainte optionnelle en condition nécessaire du déploiement. L\'intégration d\'outils de scan de secrets et de configuration dans les pipelines CI/CD (GitLeaks, truffleHog, AWS Config Rules, Azure Policy) permet de bloquer les builds ou les déploiements qui ne respectent pas les exigences de chiffrement définies. Cette approche ne dépend pas de la vigilance des développeurs — elle s\'applique automatiquement à chaque commit et chaque déploiement.
La violation Home Depot de 2014 (56 millions de cartes via credentials prestataire) résultait en partie d\'un déploiement tardif du chiffrement P2PE dans les terminaux de point de vente. Home Depot avait planifié une migration vers des terminaux intégrant le chiffrement P2PE et les cartes à puce EMV, mais ce projet n\'avait pas encore été complété au moment de l\'incident. Ce timing — la violation survenant juste avant la mise à jour planifiée du système de paiement — est caractéristique du risque créé par les périodes de transition pendant lesquelles une mise à jour de sécurité est planifiée mais pas encore déployée. La migration post-incident a été accélérée et complétée en quelques mois — démontrant que la capacité d\'exécution existait mais n\'avait pas été prioritisée suffisamment tôt.
L\'incident Deutsche Bank de 2019 (transmission de données d\'employés au mauvais destinataire) illustre un déploiement tardif des contrôles de DLP (Data Loss Prevention) sur les systèmes de communication interne. Les données transmises par erreur auraient pu être identifiées et retenues par un système DLP configuré pour détecter la présence de données personnelles sensibles dans les communications sortantes. Les systèmes DLP existaient dans l\'organisation mais n\'avaient pas été déployés sur le canal de communication qui a été le vecteur de l\'incident. Ce déploiement partiel — DLP sur certains canaux mais pas tous — est typique d\'une gouvernance qui traite la sécurité comme un projet avec une portée limitée plutôt que comme une exigence couvrant l\'ensemble des vecteurs d\'exposition.
La cyberattaque contre Sony Pictures en 2014 a exposé des données internes dont des mots de passe stockés en clair dans des fichiers Excel sur le réseau partagé. Des fichiers nommés explicitement "passwords.xls" contenaient des credentials d\'accès à des systèmes sensibles — un exemple extrême de déploiement tardif des pratiques minimales de protection des credentials. Sony disposait de systèmes IT sophistiqués mais les pratiques de gestion des secrets n\'avaient pas été standardisées et étaient laissées à la discrétion des équipes individuelles. Un audit basique des partages réseau à la recherche de fichiers contenant des patterns de mots de passe aurait identifié cette exposition avant l\'incident.