De la Salle de Crise à la Planche à Dessin

Pourquoi la résilience 2026 se joue avant l’incident.

Si les chroniques précédentes nous ont permis d’explorer les mécanismes de la gestion de crise et de la réaction face à l’incident, il est essentiel d’élargir le spectre. Une organisation résiliente n’est pas seulement celle qui se relève vite, c’est celle qui a été conçue pour encaisser les chocs.

En ce début d’année, un constat s’impose : le cadre réglementaire (Cyber Resilience Act, NIS2) et les impératifs économiques nous poussent à changer de paradigme. Nous passons d’une logique de “protection périmétrique” à une logique de “qualité native”.

1. Le Contexte : L’équation économique et réglementaire

Pendant longtemps, le modèle de développement numérique a privilégié la vitesse de mise sur le marché (“Time to Market”) au détriment de la robustesse, partant du principe que les correctifs (patchs) viendraient régler les problèmes ultérieurement.

Ce modèle atteint aujourd’hui ses limites pour deux raisons factuelles :

1. La réalité économique : Il est admis qu’un défaut de sécurité corrigé en phase de production coûte jusqu’à 100 fois plus cher que s’il avait été traité lors de la conception. Dans un contexte budgétaire tendu, la résilience “by design” devient un levier de performance financière.

2. La pression normative : Avec le Cyber Resilience Act (CRA), le législateur européen transforme la sécurité en une exigence de marché. Un produit numérique (logiciel ou objet connecté) doit désormais présenter des garanties de sécurité natives pour être commercialisé. De son côté, NIS2 impose une rigueur dans la gouvernance qui ne peut plus se satisfaire d’approximations.

L’enjeu n’est plus seulement de savoir éteindre l’incendie, mais de s’assurer que les matériaux utilisés pour la construction sont ignifugés.

2. L’Approche : Le “Compliance as Code” comme standard

Comment concilier ces exigences de conformité avec l’agilité nécessaire aux opérations ? La réponse réside dans l’évolution de nos méthodes : le “Compliance as Code”.

Ce concept propose de ne plus traiter la conformité comme une couche administrative (des documents PDF vérifiés une fois par an), mais de l’intégrer directement dans les outils techniques.

Concrètement, cela signifie traduire une règle de gouvernance en barrière technique automatisée :

• Approche traditionnelle : Une politique écrite demande de ne pas utiliser de composants obsolètes.

• Approche Résiliente : Le système de déploiement bloque automatiquement tout code contenant une librairie dont la maintenance n’est plus assurée.

C’est ce qu’on appelle le “Shift Left” : déplacer le contrôle le plus tôt possible dans la chaîne de production. Cette approche permet de réduire la “dette technique”, cette accumulation de systèmes vieillissants et vulnérables qui fragilise la résilience globale de l’organisation.

3. Passage à l’acte : Sécuriser la chaîne d’approvisionnement

Pour mettre en œuvre cette stratégie, le point de contrôle le plus efficace se situe au moment de l’achat ou du lancement de projet. C’est ici que l’on décide, ou non, d’importer un risque futur.

Voici une grille de lecture en trois points pour évaluer la maturité d’une solution ou d’un fournisseur, au regard des exigences 2026 :

1. La Maintenabilité dans la durée

La première cause d’obsolescence (et donc de risque) est l’arrêt du support de sécurité.

• La question clé : La durée garantie de fourniture des correctifs de sécurité couvre-t-elle la durée d’amortissement prévue du produit ?

• Le point de vigilance : Un décalage entre ces deux durées crée mécaniquement une période de risque où l’entreprise devra gérer des failles sans support éditeur.

2. La Transparence des composants (SBOM)

Nous intégrons de plus en plus de “boîtes noires”. Or, la résilience exige de savoir ce que l’on opère.

• La question clé : Le fournisseur est-il capable de fournir un SBOM (Software Bill of Materials), c’est-à-dire la liste des ingrédients logiciels tiers intégrés dans sa solution ?

• Le point de vigilance : L’absence de visibilité sur les sous-composants empêche d’évaluer l’exposition à des vulnérabilités critiques de type “Supply Chain”.

3. La Réversibilité et l’Indépendance

La résilience, c’est aussi la capacité à survivre à la défaillance d’un partenaire.

• La question clé : Existe-t-il une procédure documentée et standardisée pour récupérer les données et migrer vers une autre solution en cas de rupture de contrat ?

• Le point de vigilance : Les formats propriétaires ou chiffrés sans clé client créent une dépendance forte (Vendor Lock-in) qui peut devenir critique en cas d’incident chez le fournisseur.

Et si le fournisseur ne répond pas aux critères ?

Il ne s’agit pas de bloquer systématiquement, mais de décider en conscience. Si une solution critique ne respecte pas ces standards, elle doit faire l’objet de mesures compensatoires (cloisonnement, surveillance accrue) et d’une acceptation formelle du risque par le métier.

L’Essentiel pour Agir

1. Changez de posture — La résilience la plus rentable se construit à la conception (“Shift Left”). N’acceptez plus de “dette technique” sciemment lors de la signature d’un contrat.

2. Adoptez le “Compliance as Code” — Les exigences réglementaires (NIS2) ne sont pas des documents à archiver, mais des règles techniques à scripter. Si une règle de sécurité repose sur une action humaine manuelle, elle échouera en temps de crise. Automatisez les barrières.

3. Utilisez le levier réglementaire — Le CRA et NIS2 sont vos alliés. Utilisez ces textes pour exiger légitimement de vos fournisseurs la transparence (SBOM) et la maintenabilité longue durée. C’est à l’achat que se joue la sécurité de demain.

Bibliographie

“Cyber Resilience Act (CRA)”

https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act

Le texte cadre européen transformant la sécurité et la maintenance des produits numériques en obligation de marché.

“La Directive NIS 2”

https://cyber.gouv.fr/la-directive-nis-2

Le portail de référence de l’ANSSI détaillant les obligations de gouvernance et de gestion des risques pour les entités régulées.

“Secure by Design”

https://www.cisa.gov/securebydesign

L’initiative internationale (co-signée par l’ANSSI) établissant les principes de sécurité par défaut pour les fabricants de logiciels.

“Good Practices for Supply Chain Cybersecurity”

https://www.enisa.europa.eu/publications/good-practices-for-supply-chain-cybersecurity

Le guide complet de l’ENISA pour gérer les risques liés aux fournisseurs et valider la transparence de la chaîne logistique.

“Intégrer la sécurité dans les projets”

https://cyber.gouv.fr/publications/integrer-la-securite-dans-les-projets

Le guide méthodologique de l’ANSSI justifiant l’approche “Shift Left” et le traitement de la sécurité dès la phase de conception.