Deux questions, dans l’ordre. Vérifier la sécurité à la fin d’un développement fonctionne-t-il vraiment ? Et sinon, que faut-il faire à la place ?
CVE-1999-0001, la première entrée de la liste Common Vulnerabilities and Exposures, le registre public où sont consignées les vulnérabilités logicielles divulguées, a été la toute première vulnérabilité jamais enregistrée. Une seule entrée. En 2025, cette base de données en a enregistré 48 185 nouvelles en une seule année, un record, en hausse de plus de 20 % par rapport à l’année précédente, selon le 2025 CVE Data Review de JerryGamblin. La surface d’attaque n’a pas simplement augmenté. Elle a explosé, et l’essentiel remonte à des exigences de sécurité que personne n’a jamais écrites.
La réglementation a suivi, mais plus lentement, puis soudain plus du tout lentement. Le RGPD est arrivé en 2018 avec un principe : la protection des données dès la conception. C’était la loi, mais cela se lisait comme un bon conseil assorti d’une sanction. Puis sont venus NIS2, contraignante depuis octobre 2024, et le Cyber Resilience Act, qui entre en vigueur progressivement jusqu’en décembre 2027. Ces textes ne se lisent pas comme des conseils. NIS2 rend les dirigeants personnellement responsables des défaillances dans la gestion des risques de cybersécurité, selon la Commission européenne. Le Cyber Resilience Act va plus loin : à partir de décembre 2027, un produit dépourvu du marquage CE attestant qu’il a été conçu de manière sécurisée dès le départ ne pourra légalement être vendu nulle part dans l’UE, selon le résumé du CRA publié par la Commission européenne elle-même. Pas une amende. Pas un avertissement. Aucun accès au marché.
L’an dernier, un hôpital a lancé un nouveau portail patient. Trois semaines plus tard, un chercheur a découvert qu’en modifiant un seul chiffre dans la barre d’adresse du navigateur, on accédait au dossier d’un autre patient. Le document d’exigences comportait une ligne pour « connexion patient ». Il n’en comportait aucune sur ce que cette connexion avait le droit d’exposer. Personne n’avait écrit cette partie, donc personne ne l’a construite.
Vérifier la sécurité à la fin fonctionne-t-il vraiment ?
Non, et la raison est structurelle, pas une question d’effort. Un document d’exigences indique aux ingénieurs ce qu’ils doivent construire. S’il ne précise pas ce que le logiciel ne doit jamais faire, exposer des données, omettre une piste d’audit, ne pas respecter une norme de chiffrement, alors rien en aval ne vérifie ces points non plus. Les tests détectent les bogues par rapport à une spécification. Ils ne peuvent pas détecter l’absence d’une règle qui n’a jamais été écrite.
C’est tout l’écart entre « tester la sécurité avant la livraison » et « spécifier la sécurité avant de construire », et la plupart des entreprises en sont encore à la première approche. Cela ressemble à de la rigueur. Le résultat : un rapport de test d’intrusion une semaine avant le lancement, une liste de constats et une course pour corriger ce que l’architecture tient déjà pour acquis. À ce stade, le modèle de données est figé, les intégrations tierces sont branchées, et la moitié des constats obtiennent une dérogation plutôt qu’un correctif, parce que reconstruire coûte cher et que la date de lancement ne bougera pas.
Dans son argumentaire pour la proposition initiale du Cyber Resilience Act en 2022, la Commission européenne citait des constats selon lesquels environ 60 % des produits sur le marché étaient livrés avec des vulnérabilités connues dès leur lancement, et deux tiers des cyberattaques remontaient à une vulnérabilité qui aurait pu être éliminée dès la conception. « L’Europe n’est forte que de son maillon le plus faible », a déclaré Thierry Breton, commissaire européen au Marché intérieur, lors de la présentation du Cyber Resilience Act. Il ne parlait pas de coûts. Il parlait des produits qui ont le droit d’exister sur le marché européen.
À quoi ressemble concrètement la spécification au stade des exigences ?
Pas un document d’exigences plus long. Un document différent, rédigé avec les responsables de la sécurité et de la conformité dans la salle, et non relu par eux après coup.
- Écrivez la contrainte à côté de la fonctionnalité, pas dans un document séparé que personne ne lit. « Les utilisateurs peuvent réinitialiser leur mot de passe » figure à côté de « les jetons de réinitialisation expirent au bout de 15 minutes et sont journalisés avec un horodatage et l’identifiant du demandeur », car cette seconde ligne est précisément ce qu’exigent les obligations de notification des incidents de NIS2, et elle ne peut pas être reconstituée à partir d’un code fonctionnel après coup.
- Nommez la réglementation dont découle l’exigence. Pas « chiffrer les données sensibles », mais « chiffrer les données en transit et au repos, conformément à l’annexe I du Cyber Resilience Act, car ce produit est livré avec une connexion réseau ». Une exigence sans source nommée est la première supprimée quand l’échéance se rapproche.
- Intégrez à la revue des exigences, et pas seulement à la revue de sécurité, quelqu’un qui comprend la réglementation. Lorsqu’un responsable de la conformité découvre une spécification, l’architecture est généralement déjà choisie, et à ce stade « ajouter ceci » signifie toujours « reconstruire ceci ».
- Considérez le document d’exigences comme la preuve, et pas seulement comme le plan. En vertu du CRA, les fabricants doivent démontrer comment un produit satisfait à ses exigences essentielles. Un document d’exigences qui énonce déjà la contrainte et sa source réglementaire constitue l’essentiel de cette preuve, rédigée une seule fois, et non reconstituée dans l’urgence avant un audit.
C’est précisément pour cette couche qu’a été conçue la practice AI-Driven Compliance de Calsoft : surveillance continue des contrôles et automatisation des preuves qui continuent de démontrer qu’une exigence est toujours respectée bien après le lancement, plutôt qu’une vérification ponctuelle avant celui-ci. Une fois qu’une contrainte est inscrite dans les exigences, c’est ainsi que vous montrez, de façon continue, que le système la respecte toujours, et pas seulement qu’il la respectait le jour où quelqu’un a donné son approbation.
L’hôpital de cette histoire a fini par corriger la faille de contrôle d’accès. Le correctif a pris un après-midi. Regagner la confiance des patients dont les dossiers avaient été exposés a pris nettement plus de temps, et aucun correctif ne touche à cette partie-là.
Les entreprises qui s’en sortiront bien en 2027 ne seront pas celles qui auront réussi leur revue de conformité. Ce seront celles pour lesquelles la revue n’aura rien trouvé à redire, parce que les exigences l’avaient déjà dit en premier.
FAQ
Pourquoi les exigences de sécurité doivent-elles être définies tôt dans le SDLC ?
Les tests vérifient uniquement ce qui a été construit par rapport à une spécification. Si les exigences de sécurité n’apparaissent jamais dans cette spécification, rien en aval ne détecte leur absence. En vertu du Cyber Resilience Act, une exigence manquante n’est pas un bogue découvert tardivement, c’est un manquement de conformité qui peut exclure totalement un produit du marché européen.
Comment transformer des exigences de conformité en exigences logicielles ?
Inscrivez le libellé de la réglementation directement dans la spécification, pas en note de bas de page. Au lieu de « chiffrer les données sensibles », écrivez « chiffrer les données en transit et au repos, conformément à l’annexe I du Cyber Resilience Act ». Une exigence sans source réglementaire nommée est généralement la première supprimée quand une échéance se rapproche.
Comment maintenir les exigences de sécurité et de conformité à jour lorsque les réglementations évoluent ?
Considérez le document d’exigences comme une preuve vivante, et non comme une validation ponctuelle. NIS2 et le Cyber Resilience Act introduisent leurs obligations progressivement sur plusieurs années : c’est donc la surveillance continue, et non la revue périodique, qui démontre qu’un système satisfait toujours à une exigence après l’évolution de la réglementation qui la sous-tend.
