Le compte à rebours quantique est lancé : RSA, ECC et TLS tremblent déjà. Pour survivre à l’ère post-quantique, le code doit évoluer aussi vite que les menaces, en plaçant la cryptographie au cœur du DevSecOps.
Dès 2027, l’ANSSI n’homologuera plus de produits dépourvus de mécanismes post-quantiques, et à l’horizon 2030, il ne sera plus raisonnable d’acquérir des solutions qui n’y résistent pas. Tels sont les propos de Vincent Strubel, Directeur général de l’ANSSI, tenus aux Assises de la Cybersécurité 2025. L’informatique quantique menace non seulement les protocoles de chiffrement, mais aussi tout le paysage logiciel. Bibliothèques, API et routines cryptographiques actuelles risquent de devenir vulnérables dans les prochaines années. Pour anticiper cette transition, les équipes AppSec doivent s’impliquer dès aujourd’hui, et les développeurs devenir des acteurs clés afin de sécuriser code, composants et processus.
Intégrer la cryptographie au cœur du cycle de vie logiciel
Si la puissance des ordinateurs quantiques menace les algorithmes connus comme RSA, Diffie-Hellman ou ECC, le risque ne se limite pas aux réseaux : il touche directement le logiciel. Pour rester sécurisée, chaque application, API ou bibliothèque utilisant le chiffrement devra être auditée, corrigée ou remplacée. Pour chiffrer leurs applications, les développeurs s’appuient aujourd’hui sur des bibliothèques éprouvées telles qu’OpenSSL, BouncyCastle ou libsodium. Bien qu’efficace, cette approche reste risquée et laisse de nombreuses incertitudes : quelles méthodes cryptographiques le code utilise-t-il ? Quels composants embarquent des algorithmes obsolètes ? Les bibliothèques réputées sûres sont-elles correctement intégrées ? Une détection automatisée par les outils SAST va permettre d’alerter les développeurs avant qu’une faille ne soit exploitée. Les équipes AppSec doivent considérer la cryptographie comme un élément auditable et suivi en continu : inventorier algorithmes, bibliothèques et protocoles, ainsi que la durée de vie des clés et les systèmes critiques. Cela permettra d’obtenir une vision de sécurité dynamique, socle de toute migration vers la cryptographie post-quantique.
Nouveaux algorithmes, nouvelles exigences
Le NIST a sélectionné CRYSTALS-Kyber pour protéger l’échange de clés entre systèmes et CRYSTALS-Dilithium pour garantir l’authenticité des messages grâce aux signatures numériques. Cependant, leur intégration nécessite plus qu’un simple remplacement : des clés plus longues et de nouvelles structures nécessitent d’adapter les API, les formats de stockage et les protocoles comme TLS, SSH ou VPN, tandis que les bibliothèques RSA et ECC vont devenir des points de fragilité. Pour bâtir un socle logiciel post-quantique, les équipes AppSec doivent intégrer ces transformations dans le cycle de développement, en incluant les modules cryptographiques directement dans les revues de code, les tests ainsi que les pipelines CI/CD.
Cryptographie hybride : stratégie de transition
La cryptographie hybride associe algorithmes classiques et post-quantiques pour se protéger à la fois contre les menaces actuelles et celles à venir. Les développeurs doivent créer des API et des systèmes de gestion de clés capables de gérer les deux types d’algorithmes simultanément. Les tests et l’assurance qualité vont vérifier que les échanges hybrides fonctionnent correctement et que les nouveaux algorithmes s’intègrent sans problème. Cette méthode limite les risques, mais augmente la complexité, ce qui impose une collaboration encore plus étroite entre les équipes de développement et de sécurité.
Le DevSecOps à l’ère quantique
Pour devenir un levier de qualité logicielle, préparant les applications à l’ère quantique dès leur conception, la cryptographie post-quantique ne doit pas être traitée comme une simple mise à jour, mais intégrée en permanence dans le développement logiciel. Dans ce cadre, les pipelines DevSecOps doivent inclure des règles cryptographiques vérifiables, des analyses automatisées et des contrôles dès le commit (approche “shift left”), afin de détecter et corriger les failles dès leur apparition.
Sécuriser la chaîne d’approvisionnement logicielle
Au-delà du code développé en interne, les organisations doivent surveiller l’ensemble de leur chaîne d’approvisionnement logicielle. Bibliothèques, images de conteneurs et composants open source peuvent rapidement devenir des points de fragilité s’ils ne respectent pas les standards post-quantiques. Les équipes AppSec doivent donc enrichir leur SBOM avec des métadonnées cryptographiques, identifier les algorithmes tiers utilisés, vérifier si leurs fournisseurs disposent d’une feuille de route PQC et planifier les mises à jour ou remplacements nécessaires. Avec l’entrée en vigueur du Cyber Resilience Act en 2027, la conformité cryptographique ne sera plus une option. L’ENISA invite d’ailleurs déjà les entreprises à évaluer la maturité post-quantique de leur chaîne logicielle, un aspect encore trop souvent négligé !
L’ère post-quantique n’est plus une perspective lointaine. Les équipes AppSec doivent en devenir les moteurs, car les organisations qui préparent dès aujourd’hui leurs applications, bibliothèques et pipelines de build prendront une avance stratégique. Avec NIS-2 et le Cyber Resilience Act, la sécurité cryptographique devra être prouvée, mesurable et intégrée dans les processus. Celles qui attendront l’arrivée effective des ordinateurs quantiques risquent de se retrouver piégées par des bibliothèques obsolètes, un code hérité difficile à migrer et des contraintes réglementaires accrues. En structurant un inventaire cryptographique, en automatisant l’analyse et en intégrant la PQC dans une démarche DevSecOps, cette mutation devient concrète. La sécurité n’est plus un état statique, mais un cycle d’adaptation continue, capable d’évoluer au rythme des menaces, y compris celles de l’ère quantique.
____________________________
Par Frédéric Malo, Solutions Engineer, Checkmarx
puis