Faille exploitée dans votre app : qui alerte l'ENISA sous 24 h depuis le 11 septembre 2026 ?

Oui, si vous êtes le fabricant de l'application, pour toute vulnérabilité activement exploitée. Depuis le 11 septembre 2026, l'article 14 du règlement (UE) 2024/2847 sur la cyberrésilience oblige celui qui commercialise l'app sous son nom ou sa marque, même gratuitement, à envoyer une alerte précoce au plus tard 24 heures après avoir eu connaissance de l'exploitation, simultanément au CSIRT désigné comme coordinateur et à l'ENISA, par la plateforme unique de signalement. Si vous développez l'app pour un client qui la publie sous sa propre marque, c'est lui le fabricant et lui qui notifie : votre obligation est contractuelle, et votre retard devient le sien.

Publié au Journal officiel le 20 novembre 2024, le règlement s'applique à partir du 11 décembre 2027, mais son article 71 avance deux blocs :

« Toutefois, l'article 14 est applicable à partir du 11 septembre 2026 et le chapitre IV (articles 35 à 51) à partir du 11 juin 2026. »
Règlement (UE) 2024/2847 du 23 octobre 2024, article 71, paragraphe 2

L'article 14, paragraphe 2, impose trois envois pour chaque vulnérabilité activement exploitée :

• Alerte précoce, « au plus tard 24 heures après en avoir eu connaissance », en indiquant le cas échéant les États membres où l'app a été mise à disposition ;
• Notification de vulnérabilité, au plus tard 72 heures après : nature de l'exploitation, mesures correctives prises et à prendre par les utilisateurs ;
• Rapport final, au plus tard 14 jours après la mise à disposition d'une mesure de correction ou d'atténuation : gravité de la faille, acteur malveillant éventuel, mise à jour de sécurité déployée.

Les incidents graves touchant la sécurité de l'app, comme l'introduction de code malveillant, suivent le même schéma, avec un rapport final dans le mois suivant la notification (article 14, paragraphes 3 à 5).

Le déclencheur est précis : il faut des « preuves fiables » que la faille « a été exploitée par un acteur malveillant dans un système sans l'autorisation du propriétaire du système » (article 3, point 42). Le considérant 68 cite en exemple les fonctions d'identification et d'authentification, et indique que les vulnérabilités découvertes sans intention malveillante (essais, enquêtes, divulgation) ne devraient pas faire l'objet de notifications obligatoires. Le paragraphe 8 impose aussi d'informer les utilisateurs touchés ; à défaut, le CSIRT peut le faire à votre place.

La notification passe par le CSIRT de l'État où sont principalement prises vos décisions de cybersécurité (article 14, paragraphe 7). En France, l'ANSSI a indiqué le 23 septembre 2026 qu'elle interviendrait comme CSIRT national au titre du CRA.

Tout se joue sur la définition du fabricant : celui qui développe un produit numérique, ou le « fait concevoir, développer ou fabriquer », et le commercialise « sous son propre nom ou sa propre marque, à titre onéreux, monétisé ou gratuit » (article 3, point 13).

• Votre propre app, publiée sous votre marque (payante, freemium ou publicitaire) : vous êtes fabricant. Le considérant 11 couvre aussi le traitement de données à distance conçu par le fabricant ou sous sa responsabilité, sans lequel l'app ne pourrait pas remplir l'une de ses fonctions, comme l'API ou la base de données qu'elle appelle : une faille exploitée côté back-end peut alors compter. Un service tiers que vous n'avez pas conçu en est exclu (considérant 12).
• L'app d'un client, publiée sous sa marque : il l'a fait développer et la commercialise, il est le fabricant et notifie. Le règlement ne vous fixe pas de délai propre ; votre contrat de maintenance le fait, ou devrait le faire.
• Une app publiée avant le 11 septembre 2026 : elle est concernée. L'article 69, paragraphe 2, épargne les produits mis sur le marché avant le 11 décembre 2027 jusqu'à une modification substantielle, mais le paragraphe 3, rectifié le 2 juillet 2025, y déroge pour l'article 14.
• Une faille signalée par un chercheur ou un test d'intrusion, sans exploitation établie : pas de notification obligatoire ; le signalement volontaire reste possible (article 15).

Exemple : vous éditez une app de réservation pour salles de sport, publiée sous votre marque. Lundi à 9 h, un club signale des comptes détournés ; à 11 h, vos journaux montrent 312 réinitialisations de mot de passe frauduleuses. Si l'on retient 11 h comme prise de connaissance, l'alerte précoce doit partir au plus tard mardi à 11 h (mardi à 9 h si l'on retient le signalement du club, lecture plus prudente), la notification jeudi à 11 h, et le rapport final dans les 14 jours suivant le correctif. Le texte ne définit pas la prise de connaissance : documentez la date retenue.

Point propre au mobile : l'attente de validation d'une version par les stores ne suspend ni les 24 ni les 72 heures. Une mesure côté serveur (désactiver l'endpoint vulnérable, invalider les jetons) peut, à notre lecture, constituer la « mesure de correction ou d'atténuation » qui fait courir les 14 jours : le texte ne le précise pas.

L'article 64, paragraphe 2, prévoit pour les manquements aux articles 13 et 14 une amende administrative pouvant aller jusqu'à 15 000 000 EUR ou 2,5 % du chiffre d'affaires annuel mondial total, le montant le plus élevé étant retenu. Deux nuances, dont la première ne vise que les micro et petites entreprises (catégories à vérifier : le règlement ne parle pas des indépendants en tant que tels) :

• L'alerte de 24 heures : le paragraphe 10, dans sa version rectifiée le 2 juillet 2025, écarte les amendes pour les fabricants « considérés comme des microentreprises ou des petites entreprises en cas de non-respect du délai visé à l'article 14, paragraphe 2, point a) » (et paragraphe 4, point a), pour les incidents graves). Les 72 heures et le rapport final ne sont pas visés.
• Le calendrier des sanctions : l'article 64 ne fait pas partie des dispositions avancées et s'applique à partir du 11 décembre 2027. Le règlement ne dit donc pas lui-même comment un retard commis d'ici là serait sanctionné : point incertain, pas une tolérance.

Le risque le plus concret se joue avec votre client : s'il manque ses délais parce que vous l'avez prévenu tard, il peut se retourner contre vous (frais d'analyse, perte de clientèle). C'est une mise en cause de responsabilité civile professionnelle, dont la prise en charge dépend des activités déclarées, des plafonds et des exclusions de votre assurance RC pro. Les frais propres à l'incident (investigation, gestion de crise) relèvent plutôt d'une assurance cyber, selon les garanties souscrites. Les amendes dépendent des exclusions de chaque contrat : à vérifier avant l'incident.

• Listez vos apps et leur fabricant : compte développeur, nom affiché sur la fiche du store, marque. Pour chaque app client, faites confirmer par écrit qui notifie.
• Fixez un délai d'alerte nettement inférieur à 24 heures dans vos contrats de maintenance, avec un canal joignable le week-end et une définition partagée de la « preuve fiable ».
• Horodatez chaque signalement et extraction de journaux : c'est votre preuve de la date de prise de connaissance.
• Préparez l'alerte précoce et l'information des utilisateurs : pays de distribution tirés de la console du store, contact technique, message dans l'app, page de statut.
• Relisez vos contrats d'assurance avec ce scénario : recours d'un client fabricant, frais d'incident, amendes. Les risques du métier sont détaillés sur notre fiche développeur mobile.

Si des données personnelles sont touchées, la notification CRA ne remplace rien : le règlement s'applique « sans préjudice » du RGPD (considérant 32), qui a ses propres obligations.