Vous avez un SaaS et une app ? Le CRA regarde l’app
Un SaaS utilisé seulement dans un navigateur est hors du Cyber Resilience Act. Ajoutez une app mobile, un client de bureau ou un appareil qui a besoin de vos serveurs, et tout change. Voici où passe la ligne, avec les articles.
La question revient tous les jours depuis la mise en ligne du test de périmètre : « On est un SaaS, donc on n’est pas concernés, non ? » À moitié vrai. Voici l’autre moitié.
Un SaaS en navigateur seul est hors champ
Le Cyber Resilience Act s’applique aux « produits comportant des éléments numériques » mis sur le marché de l’Union. Un service que vous faites tourner sur vos serveurs, utilisé dans un navigateur, n’est pas un produit mis sur le marché. Le considérant 12 le dit sans détour : le SaaS pur n’est pas couvert. NIS2 peut s’y appliquer à la place, mais seulement au-delà de ses seuils de secteur et de taille, que la plupart des petites sociétés n’atteignent jamais.
Donc si vos clients se connectent sur une page web et que rien d’autre ne tourne chez eux, vous pouvez arrêter ici. Gardez vos pratiques de sécurité, mais la paperasse CRA n’est pas pour vous.
L’app change tout
Ajoutez maintenant au même service une app iOS ou Android, un client de bureau, une extension de navigateur, un outil en ligne de commande, un agent installé sur un serveur, un appareil avec un firmware. Chacun est un logiciel que vous mettez sur le marché. Chacun est un produit comportant des éléments numériques. Le CRA s’y applique.
Et le règlement ne s’arrête pas à l’app. L’article 3, point 2, définit le « traitement de données à distance » : un traitement conçu et développé par le fabricant, sans lequel le produit ne pourrait pas remplir une de ses fonctions. Votre back-end, quand l’app en dépend, c’est exactement ça. Il vient avec le produit. La nomenclature logicielle, le traitement des vulnérabilités et les exigences de conception de l’annexe I couvrent l’app et les parties du back-end dont l’app ne peut pas se passer.
Lecture pratique : le CRA ne réglemente pas votre SaaS. Il réglemente votre app, et il fait entrer votre back-end par l’app.
Ce que ça veut dire cette semaine
Depuis le 11 septembre 2026, l’article 14 s’applique. Si vous apprenez qu’une vulnérabilité de votre app est activement exploitée, l’alerte précoce à votre CSIRT et à l’ENISA est due sous 24 heures, la notification sous 72 heures. Ce compte à rebours vaut pour l’app, et pour les fonctions du back-end dont elle dépend.
Trois choses à avoir en place, dans cet ordre. Un contact sécurité qui est lu, publié dans un fichier security.txt. Une nomenclature logicielle de l’app, régénérée à chaque version. Une procédure d’une page qui dit qui décide, qui notifie, et où sont les modèles. Rien de tout ça ne demande un avocat.
Deux cas limites qu’on nous pose
Un client open source maintenu sans activité commerciale reste hors champ (considérant 18). Dès qu’une société vend du support dessus, ou l’embarque dans un produit payant, l’exception s’arrête.
Un appareil vendu avec une app compagnon : l’appareil est le produit, l’app et le back-end sont son traitement à distance. Un produit, une déclaration, une nomenclature par composant.
Si vous ne savez pas de quel côté de la ligne vous êtes, le test de périmètre gratuit pose huit questions et vous donne un résultat écrit avec les références d’articles.
Ce n’est pas un conseil juridique.