Supply chain logicielle : les nouvelles normes de sécurité en 2025

La supply chain logicielle, nouveau terrain de bataille de la cybersécurité

Depuis quelques années, les attaques visant la chaîne d’approvisionnement logicielle — ce qu’on appelle la supply chain dans le jargon — sont devenues l’une des menaces les plus redoutées par les équipes de sécurité informatique. Le principe est simple mais redoutable : plutôt que d’attaquer directement une entreprise, les cybercriminels compromettent un outil, une bibliothèque ou un prestataire tiers utilisé par leurs cibles. L’affaire SolarWinds en 2020 avait frappé les esprits à l’échelle mondiale, et depuis, le secteur n’a cessé de chercher des réponses structurées. En 2025, ces réponses prennent enfin la forme de normes concrètes, notamment en Europe et en France.

Ce que change la directive NIS2 pour les entreprises françaises

Entérinée au niveau européen en 2022 et transposée progressivement dans le droit national des États membres, la directive NIS2 (Network and Information Security 2) impose désormais des obligations beaucoup plus strictes en matière de gestion des risques liés aux tiers. En France, l’ANSSI (Agence Nationale de la Sécurité des Systèmes d’Information) joue un rôle central dans la mise en œuvre opérationnelle de ces exigences. Concrètement, les entreprises considérées comme « essentielles » ou « importantes » — et leur périmètre est bien plus large qu’on ne le pense, couvrant désormais des secteurs comme l’énergie, la santé, les transports, mais aussi les fournisseurs de services numériques — doivent être en mesure de cartographier l’ensemble de leurs dépendances logicielles et d’évaluer le niveau de risque associé à chacune.

Ce n’est pas qu’une formalité administrative. NIS2 prévoit des sanctions financières significatives en cas de manquement, pouvant aller jusqu’à 10 millions d’euros ou 2 % du chiffre d’affaires annuel mondial. La pression réglementaire est donc réelle, et elle pousse les organisations françaises à revoir en profondeur leurs pratiques d’achat et d’intégration de composants logiciels tiers.

Le SBOM, ou comment savoir ce qu’il y a vraiment dans votre logiciel

L’un des concepts qui s’impose comme un standard incontournable en 2025 est le SBOM, pour Software Bill of Materials. L’idée est analogue à la liste d’ingrédients d’un produit alimentaire : il s’agit de disposer d’un inventaire exhaustif de tous les composants, bibliothèques et dépendances qui constituent un logiciel donné. Cela peut paraître évident, mais dans la réalité du développement moderne — où un projet peut embarquer des centaines de bibliothèques open source, elles-mêmes dépendantes d’autres bibliothèques — la traçabilité est souvent très lacunaire.

En 2025, plusieurs initiatives françaises et européennes poussent à la généralisation du SBOM. Le Cyber Resilience Act européen, en cours de finalisation, rendra obligatoire la production de SBOM pour de nombreux produits numériques mis sur le marché dans l’UE. Des acteurs français comme Wallix ou Tenable France accompagnent déjà leurs clients dans cette démarche, et des outils open source comme Syft ou CycloneDX gagnent en maturité. L’objectif : permettre à n’importe quelle organisation de savoir, en quelques clics, si une vulnérabilité découverte dans une bibliothèque donnée affecte l’un de ses logiciels en production.

L’IA au service de la sécurisation de la chaîne logicielle

La dimension IA s’invite naturellement dans ce débat, et c’est là que la convergence avec l’actualité technologique française devient particulièrement intéressante. Des startups tricolores, mais aussi des grands groupes comme Thales ou Capgemini, développent ou intègrent des solutions d’intelligence artificielle pour analyser en continu les dépendances logicielles et détecter des comportements anormaux. L’IA permet notamment d’automatiser la veille sur les vulnérabilités connues (les fameux CVE, Common Vulnerabilities and Exposures), de prioriser les correctifs à appliquer en fonction du contexte réel de l’entreprise, et même de détecter des modifications suspectes dans le code source d’une bibliothèque open source avant qu’elles ne soient signalées officiellement.

Cette approche prédictive est d’autant plus précieuse que le volume de nouvelles vulnérabilités publiées chaque année ne cesse d’augmenter. En 2024, plus de 29 000 CVE ont été recensées selon la base de données nationale américaine NVD — un record. Face à cette inflation, les équipes humaines seules ne peuvent plus assurer une veille efficace sans assistance algorithmique. L’IA devient donc un maillon indispensable de la chaîne de sécurité, et non plus seulement un outil annexe.

Vers une culture de la sécurité dès la conception

Au-delà des outils et des réglementations, ce que révèlent les nouvelles normes de 2025, c’est une transformation culturelle profonde dans la façon dont les organisations françaises appréhendent la sécurité logicielle. Le paradigme du Secure by Design — intégrer la sécurité dès les premières phases de conception d’un logiciel, plutôt que de la greffer en fin de cycle — gagne du terrain, porté à la fois par les exigences réglementaires et par une prise de conscience progressive des équipes de développement.

Cette évolution se traduit concrètement par l’essor des pratiques DevSecOps, qui intègrent les tests de sécurité directement dans les pipelines de développement continu. Des formations dédiées se multiplient, soutenues notamment par des dispositifs publics comme le plan France 2030 qui finance la montée en compétences des développeurs sur ces sujets. L’ANSSI publie régulièrement des guides pratiques à destination des équipes techniques, et son référentiel sur la sécurité des développements logiciels fait désormais figure de document de référence dans de nombreuses DSI françaises. La route est encore longue — la majorité des PME françaises reste loin du compte en matière de maturité sur ces sujets — mais la direction est clairement tracée. La sécurité de la supply chain logicielle n’est plus l’affaire exclusive des grands groupes ou des opérateurs d’importance vitale : elle concerne, à des degrés divers, toute organisation qui développe, achète ou utilise des logiciels. C’est-à-dire, aujourd’hui, à peu près tout le monde.