Avertissement informatif
Cet article propose une analyse technique et pédagogique du Règlement (UE) 2024/2847. Il est fourni à titre strictement informatif et ne constitue en aucun cas un conseil juridique personnalisé. Pour toute évaluation formelle de votre statut de conformité, rapprochez-vous d'un professionnel du droit numérique.
En l'espace de quelques mois, la création logicielle a vécu une révolution démocratique sans précédent. Grâce aux modèles de langage et aux outils de vibe coding (Cursor, Lovable, Claude Code, Bolt.new, ChatGPT), des entrepreneurs sans formation d'ingénieur conçoivent désormais en quelques jours des applications web complètes, des outils métiers et des micro-SaaS intégrant authentification, bases de données et passerelles de paiement.
Mais dans l'Union européenne, cette montée en puissance de la création instantanée croise la route d'un texte juridique monumental : le Cyber Resilience Act (CRA), officiellement adopté sous le nom de Règlement (UE) 2024/2847.
Alors que ses premières obligations contraignantes entrent en vigueur en ce mois de septembre 2026, un grand nombre de créateurs découvrent le texte avec inquiétude. Faut-il paniquer ? Certainement pas.
L'angle d'analyse doit rester rigoureux : l'intelligence artificielle rend le logiciel infiniment plus simple à fabriquer, mais elle ne supprime pas les responsabilités juridiques de celui qui le met sur le marché.
Le Cyber Resilience Act expliqué simplement
Le Cyber Resilience Act est la première législation européenne établissant des règles horizontales de cybersécurité pour les produits comportant des éléments numériques (Products with Digital Elements - PDE).
Pour comprendre son esprit sans jargonner :
- L'objectif : Mettre fin à la mise sur le marché de logiciels truffés de failles de sécurité connues, dépourvus de suivi des correctifs ou livrés avec des mots de passe par défaut.
- Le principe de base : Tout produit logiciel ou matériel connecté vendu dans l'UE doit être sécurisé dès sa conception (Security by Design), documenté et maintenu à travers des mises à jour de sécurité gratuites pendant toute sa durée de vie prévisible (jusqu'à 5 ans).
- Le fabricant : La personne physique ou morale qui développe un produit ou le fait concevoir, et le commercialise sous son propre nom ou sa propre marque.
- La sanction ultime : Les produits non conformes s'exposent à des interdictions de distribution sur le marché unique et à des sanctions administratives pouvant atteindre 15 millions d'euros ou 2,5 % du chiffre d'affaires mondial.
Le CRA concerne-t-il les logiciels et les SaaS ?
C'est la question la plus débattue par les fondateurs de projets web. La réponse exige de la précision juridique (Articles 2 et Considérants 10 à 14 du Règlement).
1. Le SaaS « pur » vs Les applications installables
Les services cloud fournis à distance (les sites web purs consultés dans un navigateur) ne sont pas considérés comme des produits mis sur le marché au sens matériel du CRA ; ils relèvent de la directive NIS 2 (Règlement UE 2022/2555).
Cependant, le piège réside dans le mot « pur » : dès lors que votre SaaS propose une application mobile (sur l'App Store ou le Google Play Store), une extension de navigateur, un client desktop Electron ou une CLI pour vos utilisateurs, ces composants logiciels sont des PDE soumis au CRA. De surcroît, le Considérant 14 précise que les solutions de traitement de données à distance développées par le fabricant et indispensables au fonctionnement du produit entrent également dans l'évaluation.
2. Les logiciels libres et open source
Le CRA exempte les logiciels développés ou distribués en dehors du cadre d'une activité commerciale (Considérant 18). En revanche, si vous monétisez votre code open source (via un abonnement, du support payant ou une offre commerciale à double licence), vous réintégrez le champ réglementaire.
Et le Vibe Coding ? Le statut du code généré par IA
Imaginez un solopreneur qui assemble une application de facturation en combinant un prompt sur Lovable, une base Supabase et un paiement Stripe, puis publie l'application mobile sur les stores d'applications.
Le fait que 95 % du code ait été écrit par ChatGPT, Claude ou Cursor modifie-t-il ses obligations devant la loi européenne ?
Le Règlement (UE) 2024/2847 ne crée strictement aucune catégorie d'exception pour le code généré automatiquement ou assisté par IA. Pour le législateur européen, la méthode d'écriture est neutre. Ce qui compte, c'est l'entité qui met le logiciel à disposition sur le marché sous sa marque.
L'IA n'est pas une entité juridique. Elle ne peut pas signer de déclaration de conformité, elle ne peut pas être fabricante et elle ne répondra pas devant les autorités de surveillance du marché. L'utilisateur de l'outil IA demeure l'unique fabricant légal.
Le paradoxe du Vibe Coder : Créer sans savoir auditer
Cette réalité réglementaire met en lumière le paradoxe que nous documentons régulièrement sur le blog de GVO : la capacité de création a augmenté de façon exponentielle, sans que la capacité d'audit ne progresse automatiquement au même rythme.
Avant l'IA, le parcours d'apprentissage pour concevoir un logiciel mobile ou client imposait d'étudier la sécurité réseau, la gestion des sessions et la cryptographie. Cette contrainte agissait comme un filtre d'acquisition des compétences de base en sécurité.
Aujourd'hui, un créateur peut livrer un produit complet en comprenant à peine comment fonctionnent les politiques Supabase RLS ou la validation des webhooks Stripe.
Le CRA vient clore cette parenthèse d'insouciance : vous pouvez utiliser l'IA pour coder, mais vous avez l'obligation légale de garantir que le produit résultant respecte les exigences essentielles de cybersécurité.
Ce que demande concrètement le CRA : Les exigences essentielles
Le CRA articule ses exigences autour de l'Annexe I. Voici leur traduction opérationnelle pour une équipe de vibe coding :
| Exigence CRA (Règlement UE 2024/2847) | Traduction pratique pour un créateur | Exemple concret Vibe Coding | Source officielle |
|---|---|---|---|
| Sécurité par défaut (Security by Default) | Le produit doit être livré dans sa configuration la plus stricte, sans identifiant par défaut. | Ne jamais livrer une application avec un compte administrateur sans mot de passe ou des tables sans RLS. | Annexe I, Partie I, point 1 |
| Protection des secrets et données | Chiffrement au repos et en transit, protection contre les accès non autorisés. | Bannir les clés d'API secrètes du code client ; appliquer notre protocole pour détecter une clé exposée. | Annexe I, Partie I, point 2 |
| Absence de vulnérabilités connues | Ne pas intégrer de composants ou dépendances présentant des failles publiques non patchées. | Auditer les paquets NPM ajoutés automatiquement par l'agent IA lors de la compilation. | Annexe I, Partie I, point 2 (a) |
| Gestion des vulnérabilités | Obligation de fournir des correctifs de sécurité gratuits et rapides tout au long du support. | Avoir un flux capable de revalider et déployer un patch dès qu'une anomalie critique est signalée. | Annexe I, Partie II |
| Documentation technique & SBOM | Établir un inventaire des composants logiciels (Software Bill of Materials). | Documenter l'arborescence des bibliothèques et sous-traitants d'API sollicités par l'application. | Annexe VII |
| Notification des vulnérabilités exploitées | Alerter l'ENISA et le CSIRT national en cas d'exploitation avérée d'une faille dans les 24h/72h. | Signaler si une table de base de données a été siphonnée suite à une faille d'autorisation IDOR. | Article 14 |
Calendrier officiel : 2026 → 2027
Le calendrier d'application du CRA s'échelonne sur trois ans à partir de son entrée en vigueur :
11 Septembre 2026 : Notification obligatoire des failles
Entrée en application de l'Article 14. Les fabricants de logiciels couverts par le CRA doivent notifier toute vulnérabilité activement exploitée ou tout incident grave ayant un impact sur la sécurité de leur produit dans un délai de 24 heures (alerte précoce) puis 72 heures (notification détaillée) via la plateforme unique gérée par l'ENISA.
11 Décembre 2027 : Application générale et Marquage CE
Entrée en application de l'ensemble du règlement. Tous les logiciels et composants numériques commercialisés dans l'UE doivent :
- Respecter les exigences essentielles de cybersécurité (Annexe I) ;
- Disposer d'une documentation technique et d'une évaluation de conformité ;
- Arborer le marquage CE.
« J'ai fait mon app avec ChatGPT » n'est pas une stratégie de conformité
Certains créateurs imaginent qu'en cas de contrôle ou d'incident, il suffira de répondre : « C'est Cursor ou Lovable qui a écrit cette fonction, je ne savais pas qu'il manquait un filtre d'autorisation ».
Dans le droit européen des produits, cet argument s'appelle une reconnaissance de négligence.
Une IA est un outillage, au même titre qu'un marteau pour un artisan du bâtiment ou qu'un compilateur pour un développeur système. Le fabricant est légalement garant du produit fini.
Comme nous le démontrions dans notre article sur le fait que même les créateurs d'IA ont besoin d'une vérification indépendante, l'outil qui produit le code ne peut pas porter la responsabilité de la vérification. Et comme nous l'avons prouvé, une correction par IA n'est pas une preuve de correction sans revalidation formelle.
Conformité ≠ Absence de vulnérabilité (et vice versa)
Il est fondamental d'éviter deux amalgames dangereux :
- Être « conforme sur le papier » ne protège pas du piratage : Remplir des formulaires administratifs ou adopter un standard ne rend pas magiquement votre base de données étanche si une faille IDOR subsiste dans votre code. C'est tout l'enjeu de comprendre ce que prouve et ne prouve pas une certification de plateforme.
- Utiliser un scanner de sécurité ne confère pas de conformité CRA : Aucun outil automatisé (pas même GVO) ne peut prétendre « vous rendre conforme au CRA » d'un coup de baguette magique. La conformité réglementaire englobe la gouvernance humaine, le support client, les engagements contractuels et la documentation des risques.
Un scanner apporte des preuves techniques d'intégrité. Il ne remplace jamais la responsabilité globale du fabricant.
Le positionnement de GVO : De la vérification technique à la préparation réglementaire
Chez GVO (GoodVibesOnly), notre mission est de démocratiser la vérification logicielle pour ceux qui construisent avec l'IA.
Ce que GVO fait aujourd'hui
GVO fournit un moteur d'audit technique indépendant et déterministe qui vous aide à purger votre application des failles concrètes visées par les exigences de l'Annexe I du CRA :
- Exposition de secrets et clés de chiffrement dans les bundles publics ;
- Routes API ouvertes sans contrôle de session ;
- Absence de sécurité au niveau des lignes de base de données (RLS) ;
- Fuites de ressources et surconsommations qui menacent la disponibilité du service.
Ce que GVO ne fait PAS (Intégrité absolue)
- GVO ne délivre pas de marquage CE.
- GVO n'est pas un organisme notifié.
- GVO ne remplace pas une revue juridique de vos conditions générales ou de votre statut de fabricant.
Notre vision future : Le CRA Readiness
Dans notre feuille de route, nous travaillons sur le mappage progressif de nos contrôles techniques déterministes vers les exigences formelles des référentiels européens. L'objectif est d'offrir aux équipes un tableau de bord clair distinguant :
- Ce qui est vérifié et prouvé automatiquement par le code ;
- Ce qui présente un problème technique à corriger ;
- Ce qui relève d'une procédure organisationnelle nécessitant une revue humaine.
Notre conviction tient en une formule : Readiness ≠ Compliance. La préparation technique est le socle indispensable sur lequel repose la conformité légale.
Checklist pratique CRA pour un Vibe Coder
Si vous commercialisez ou prévoyez de distribuer une application dans l'Union européenne, voici les étapes concrètes à engager dès maintenant :
Checklist d'hygiène CRA pour créateurs d'applications
□ Périmètre : Déterminez si votre application comprend des éléments distribués (application mobile sur l'App Store/Play Store, client desktop, extension de navigateur).
□ Secrets : Vérifiez formellement qu'aucun secret de production (clés Stripe, tokens Supabase Service Role) n'est présent dans votre code frontend.
□ Autorisations : Testez l'isolation des données entre deux utilisateurs distincts pour éliminer les failles IDOR.
□ Inventaire des composants (SBOM) : Conservez un fichier répertoriant vos dépendances NPM clés et vos fournisseurs d'APIs tierces.
□ Mises à jour : Assurez-vous d'avoir un processus simple pour pousser un correctif de sécurité en production en moins de 24 heures.
□ Signalement : Identifiez le canal de contact de votre autorité nationale de cybersécurité (l'ANSSI en France, le CCB en Belgique) pour les obligations de notification.
□ Revue juridique : En cas de doute sur la qualification de vos produits, consultez un avocat spécialisé en droit du numérique.
Pour approfondir la validation de votre architecture avant de la commercialiser, consultez notre guide complet pour auditer la sécurité d'un SaaS avant son lancement.
Conclusion : Grandir avec ses responsabilités
Le Cyber Resilience Act n'a pas été conçu pour briser l'élan des créateurs indépendants ou interdire le vibe coding. Il a été pensé pour que le continent européen ne devienne pas une passoire numérique où n'importe quel logiciel non testé peut exposer les données de millions de citoyens.
L'intelligence artificielle donne à chacun d'entre nous le super-pouvoir de bâtir.
Le droit européen rappelle simplement la règle fondamentale : à grand pouvoir de création correspond une responsabilité de protection.
L'IA peut écrire votre logiciel. Mais elle ne prendra jamais votre place en tant que garant de ce que vous mettez entre les mains du public.