Cyber Resilience Act : décider si un projet logiciel doit changer de cadrage

Un projet logiciel peut sembler classique au départ : refonte d’un portail client, application embarquée dans un équipement, outil SaaS vertical, connecteur livré à plusieurs clients, module installé chez des partenaires. Le niveau d’exigence change lorsque ce logiciel devient un produit avec éléments numériques mis sur le marché européen, ou lorsqu’il entre dans une chaîne de responsabilité contractuelle plus large.

Le Cyber Resilience Act, ou CRA, n’est donc pas seulement un sujet juridique à traiter en fin de projet. La Commission européenne rappelle que le règlement impose des exigences de cybersécurité aux fabricants sur la planification, la conception, le développement et la maintenance des produits concernés, avec des obligations applicables à chaque étape de la chaîne de valeur.

La page officielle indique aussi que les obligations principales s’appliqueront à partir du 11 décembre 2027, tandis que certaines obligations de notification s’appliquent à partir du 11 septembre 2026 : Cyber Resilience Act, Commission européenne.

Pour une PME, la bonne question n’est pas de transformer chaque projet applicatif en programme de conformité lourd. Elle est plus opérationnelle : faut-il modifier le cahier des charges, les critères de recette, les preuves de sécurité et les responsabilités du prestataire dès maintenant ?

Arbre de décision : le CRA change-t-il le cadrage du projet ?

1. Le logiciel est-il uniquement développé pour un usage interne, sans mise à disposition comme produit ? Si oui, le CRA n’est pas forcément le bon cadre principal, mais les pratiques de sécurité restent utiles.
2. Le logiciel, le composant ou l’équipement connecté est-il destiné à être fourni, vendu, intégré ou distribué sur le marché européen ? Si oui, traiter le sujet CRA dès le cadrage.
3. Votre entreprise joue-t-elle le rôle de fabricant, d’intégrateur, d’importateur, de distributeur ou de simple acheteur ? La réponse oriente les obligations et les clauses à demander.
4. Le produit manipule-t-il des identités, des flux réseau, des mises à jour, des données métier sensibles ou des fonctions critiques ? Si oui, renforcer les critères de sécurité et la traçabilité des décisions.
5. Le projet prévoit-il une maintenance après livraison ? Si oui, la gestion des vulnérabilités, des mises à jour et du support doit être contractualisée, pas laissée à une discussion après mise en production.

Cet arbre ne remplace pas une analyse juridique, mais il évite une erreur fréquente : découvrir au moment de la recette que les preuves de sécurité, la documentation technique et les procédures de vulnérabilité n’ont jamais été prévues dans le budget.

Quand le cadrage doit évoluer

Le signal le plus fort est la mise à disposition d’un produit numérique, matériel ou logiciel, au-delà d’un usage purement interne.

La page de l’ANSSI consacrée aux exigences du CRA souligne que le règlement vise un changement d’approche dans la façon de développer et maintenir les produits numériques, avec des obligations portant notamment sur la gestion des vulnérabilités, les incidents, les mesures de sécurité et la transparence envers les utilisateurs : exigences du CRA, ANSSI.

Dans un projet de transformation numérique, cela déplace plusieurs décisions vers l’amont. Le besoin métier reste le point de départ, mais il faut ajouter des questions qui ne relèvent pas seulement du développement : quelle durée de support est promise, qui reçoit les signalements de vulnérabilité, comment une mise à jour de sécurité est distribuée, quelles dépendances logicielles sont suivies, et quelle preuve sera disponible en cas de demande d’un client ou d’une autorité.

Les livrables à demander au prestataire

Un prestataire ne peut pas garantir à lui seul la conformité d’une organisation, surtout si les responsabilités produit, support et distribution restent chez le client. En revanche, il peut livrer des éléments vérifiables qui rendent la décision possible.

Cette logique complète utilement un cahier des charges informatique : elle transforme la sécurité applicative en critères de livraison, et non en contrôle final détaché du projet.

Chronologie courte d’un cadrage raisonnable

1. Avant le devis : qualifier le rôle de l’entreprise dans la chaîne du produit et l’usage prévu du logiciel.
2. Pendant le cadrage : ajouter les exigences de sécurité, les responsabilités de support et les preuves attendues.
3. Au démarrage : lister les dépendances, les composants tiers, les accès sensibles et les flux de mise à jour.
4. Avant la recette : vérifier les scénarios de vulnérabilité, de correction, de communication client et de retour arrière.
5. Avant la mise en production : figer les exceptions acceptées, le dossier de preuves et les contacts opérationnels.
6. Après livraison : intégrer les vulnérabilités, mises à jour et incidents dans le cycle de maintenance.

La chronologie doit rester proportionnée. Une PME qui édite un logiciel spécialisé n’a pas les mêmes moyens qu’un industriel mondial, mais elle peut éviter les angles morts les plus coûteux : absence de propriétaire, dépendances inconnues, correctifs impossibles à déployer, documentation dispersée et arbitrages non tracés.

Les liens avec les contrôles déjà connus

Le CRA ne remplace pas les contrôles projet habituels. Il les rend plus explicites. Les droits applicatifs restent à cadrer avant la recette, surtout si certains profils peuvent administrer le produit, exporter des données ou déclencher des traitements sensibles. Le sujet rejoint directement les décisions décrites dans droits applicatifs avant recette.

La chaîne de livraison doit aussi être regardée avec pragmatisme. Un scan de dépendances sans règle d’arbitrage crée du bruit ; une exception de sécurité sans date de réexamen devient une dette. Les contrôles décrits dans un pipeline CI/CD sécurisé prennent plus de valeur lorsqu’ils produisent une preuve exploitable : résultat, seuil, décision, responsable et traitement prévu.

Checklist avant de signer le lancement

• Le rôle de l’entreprise dans le produit numérique est écrit noir sur blanc.
• Le périmètre logiciel inclut les composants tiers, connecteurs, API, bibliothèques et services de mise à jour.
• Les exigences de sécurité sont formulées comme des critères vérifiables, pas comme des intentions générales.
• Le prestataire sait quels livrables de sécurité sont attendus et à quel moment ils seront revus.
• La gestion des vulnérabilités couvre la réception d’un signalement, la qualification, la correction et la communication.
• La recette inclut des scénarios d’accès, d’erreur, de mise à jour et de retour arrière.
• Les exceptions de sécurité ont un propriétaire, une justification et une date de réexamen.
• Le dossier de fin de projet reste lisible par la direction, l’IT, le support et un futur prestataire.

La décision utile pour une PME

Le bon arbitrage consiste à traiter le CRA comme un révélateur de maturité projet. Si le logiciel reste interne, le sujet peut nourrir une démarche de sécurité applicative sans devenir un chantier réglementaire. Si le logiciel est fourni comme produit, intégré à un équipement ou distribué à des clients, il faut cadrer plus tôt les responsabilités, les preuves et la maintenance.

Attendre la fin du développement revient à négocier la sécurité au moment où les marges de manœuvre sont les plus faibles. La décision la plus pragmatique consiste à ajouter quelques livrables dès le devis, puis à les faire vivre pendant le projet : périmètre du produit, risques, dépendances, vulnérabilités, mises à jour, recette et preuves. C’est moins spectaculaire qu’un grand programme de conformité, mais beaucoup plus utile pour piloter un projet logiciel sans découvrir les obligations au dernier moment.