Pendant des années, un logiciel pouvait être vendu en Europe sans qu’aucune règle générale n’impose un niveau de sécurité. C’est fini. Le Cyber Resilience Act, le règlement européen 2024/2847, s’applique à presque tout ce qui contient du logiciel et se connecte à quelque chose : objets connectés, mais aussi applications mobiles et logiciels installés. Il est entré en vigueur en décembre 2024, et sa première obligation concrète s’applique depuis le 11 septembre 2026 : signaler les failles exploitées. Si votre entreprise publie une app ou vend un logiciel, vous êtes probablement concerné, même si quelqu’un d’autre l’a développé pour vous.
Votre app est-elle concernée ?
Le règlement vise les « produits comportant des éléments numériques », c’est-à-dire tout produit logiciel ou matériel destiné à se connecter à un appareil ou à un réseau. Les orientations publiées par la Commission en juillet 2026 sont explicites : une application mobile téléchargée sur un store et installée sur un téléphone est un tel produit, tout comme un programme installé sur un ordinateur. Il faut en plus qu’elle soit fournie dans le cadre d’une activité commerciale, ce qui ne se limite pas au prix : une app gratuite qui se finance par la publicité ou exige des données personnelles pour être utilisée l’est aussi.
Le serveur qui fait tourner l’app est souvent inclus. Le règlement couvre les « solutions de traitement de données à distance » conçues par le fabricant, sans lesquelles le produit ne pourrait pas remplir une de ses fonctions. Son considérant 11 cite précisément l’exemple d’une application mobile qui dépend d’une interface ou d’une base de données développée par son éditeur. À l’inverse, une application web utilisée uniquement dans le navigateur et un site vitrine sortent du champ, sauf s’ils servent au fonctionnement d’un produit. Quant aux logiciels proposés en ligne sur abonnement, le SaaS, le règlement les renvoie en principe à une autre réglementation, la directive NIS2.
Fait développer ne veut pas dire pas responsable
C’est le point qui surprend le plus nos clients. Le règlement appelle « fabricant » celui qui développe un produit ou le fait concevoir et développer, puis le commercialise sous son propre nom ou sa propre marque. Autrement dit, si une agence développe votre app et que vous la publiez sous votre marque, c’est vous, à la lecture du texte, qui portez les obligations du fabricant. Le prestataire a évidemment un rôle à jouer, mais c’est votre nom qui figure sur la fiche du store, et c’est à vous que les autorités s’adresseront.
Un logiciel développé sur mesure pour un seul client professionnel reste dans le champ : la Commission précise seulement que le fabricant et son client peuvent alors convenir, par contrat, de déroger à deux exigences, la configuration sécurisée par défaut et la gratuité des mises à jour de sécurité. Le cas d’un outil développé uniquement pour un usage interne est moins tranché : un produit fabriqué pour son propre usage n’est en principe pas mis sur le marché, mais la frontière mérite d’être examinée au cas par cas.
Depuis septembre : 24 heures pour signaler
Depuis le 11 septembre 2026, un fabricant qui apprend qu’une faille de son produit est activement exploitée, ou qu’un incident grave en affecte la sécurité, doit le signaler en trois temps :
- Une alerte précoce dans les 24 heures après en avoir pris connaissance
- Une notification dans les 72 heures, avec les premières informations sur la faille et les mesures prises
- Un rapport final au plus tard 14 jours après la mise à disposition d’un correctif pour une faille, ou un mois après la notification pour un incident
Le signalement passe par une plateforme unique gérée par l’ENISA, l’agence européenne de cybersécurité, et parvient au centre de réponse national. En Belgique, c’est le Centre pour la Cybersécurité Belgique. Il faut aussi informer les utilisateurs touchés et leur dire comment se protéger. Cette obligation vaut pour tous les produits concernés, y compris ceux déjà sur le marché avant 2027. Elle n’est en revanche pas rétroactive : selon la Commission, une exploitation dont le fabricant avait connaissance avant le 11 septembre 2026 n’a pas à être signalée.
Vingt-quatre heures, c’est court, et le délai court à partir du moment où vous savez. En pratique, il faut savoir à l’avance qui reçoit l’alerte, qui décide, et qui remplit le formulaire. Une app dont personne ne surveille les dépendances ni les journaux ne découvrira pas une faille exploitée à temps, et c’est précisément ce que le texte veut changer.
La question n’est plus de savoir si votre app aura une faille, mais qui s’en rendra compte, et en combien de temps.
Décembre 2027 : la sécurité devient une exigence du produit
À partir du 11 décembre 2027, le reste du règlement s’applique. Les produits devront être conçus selon une liste d’exigences essentielles, dont voici l’essentiel :
- Aucune vulnérabilité exploitable connue au moment de la mise sur le marché, et une configuration sécurisée par défaut
- Des mises à jour de sécurité gratuites, automatiques par défaut lorsque c’est pertinent, pendant une période d’assistance d’au moins cinq ans, sauf si le produit est censé servir moins longtemps
- Une nomenclature des composants logiciels, au moins des dépendances directes, dans un format lisible par machine
- Un point de contact pour recevoir les signalements de failles, et une politique pour les traiter
- Une documentation technique et une déclaration de conformité, conservées dix ans, et un marquage CE qui, pour un logiciel, peut figurer sur la déclaration ou sur le site qui l’accompagne
Pour la grande majorité des apps et logiciels, l’évaluation se fait par contrôle interne : pas d’organisme extérieur, mais un dossier à tenir. Seules certaines catégories, comme les gestionnaires de mots de passe, les VPN ou les navigateurs, suivent une procédure plus stricte. Les produits mis sur le marché avant décembre 2027 n’y sont soumis qu’en cas de modification substantielle, mais une app qui publie régulièrement de nouvelles versions y viendra vite.
Les sanctions, et ce qui est prévu pour les petites entreprises
Le non-respect des exigences essentielles ou des obligations de signalement peut coûter jusqu’à 15 millions d’euros ou 2,5 % du chiffre d’affaires mondial annuel, le montant le plus élevé étant retenu. Les autorités doivent tenir compte de la taille de l’entreprise, et le règlement prévoit que les micro et petites entreprises ne soient pas sanctionnées pour un retard de l’alerte de 24 heures. Les délais de 72 heures et de rapport final restent dus. Les États membres doivent aussi proposer aux petites structures des actions de sensibilisation, de formation et un canal de contact dédié.
Par où commencer
Dès maintenant, trois choses suffisent à ne pas être pris de court : désigner qui reçoit et traite une alerte de sécurité, publier une adresse de contact pour les signalements de failles, et dresser la liste des composants tiers que votre app embarque. D’ici fin 2027, il faudra ensuite décider d’une période d’assistance réaliste, organiser les mises à jour et constituer le dossier technique. Si votre app peut déjà se corriger rapidement, sans attendre la validation des stores, vous avez une longueur d’avance.
Ce n’est pas un avis juridique : pour un cas limite, un juriste tranchera. C’est en revanche un chantier que nous intégrons à nos projets en ingénierie produit et en plateformes et infrastructure : dépendances suivies, mises à jour prévues, journaux exploitables. Si votre app a été développée il y a quelques années et que personne ne sait vraiment ce qu’elle contient, écrivez-nous : un état des lieux suffit souvent à savoir où vous en êtes.