Tu développes des logiciels, apps, plugins, extensions ou briques SaaS pour tes clients ? Voici comment comprendre le Cyber Resilience Act, cadrer ton rôle et éviter de porter une responsabilité floue.
Depuis le 11 septembre 2026, le Cyber Resilience Act est entré dans sa première phase opérationnelle. Les fabricants de produits numériques doivent désormais signaler certaines vulnérabilités activement exploitées et certains incidents sévères, avec une alerte initiale sous 24 heures.
Si tu es développeur freelance, DevOps freelance, créateur de plugin ou éditeur d’un petit SaaS, tu vas forcément croiser ce texte. Le réflexe naturel, c’est de répondre : « Je ne suis qu’une prestataire, ça ne me concerne pas. » Parfois, ça tient juridiquement. Souvent, c’est trop court contractuellement.
J’ai déjà vu des missions agiles où tout semblait cadré côté backlog, mais rien côté responsabilité après livraison. Qui surveille les dépendances ? Qui paie le correctif urgent ? Le jour où une faille critique sort, ces questions ne sont plus théoriques.
Le CRA ne transforme pas chaque freelance dev en fabricant. Il oblige surtout à arrêter de livrer du logiciel sans rôle, sans preuves et sans procédure de sécurité.
Le CRA, règlement UE 2024/2847, fixe des exigences de cybersécurité pour les produits comportant des éléments numériques. La Commission européenne rappelle son calendrier :
| Date | Ce qui s’applique |
|---|---|
| 10 décembre 2024 | Entrée en vigueur du règlement |
| 11 juin 2026 | Règles sur les organismes d’évaluation de conformité |
| 11 septembre 2026 | Obligations de signalement de l’article 14 |
| 11 décembre 2027 | Application complète : exigences de sécurité, documentation, marquage CE |
Le mot important est « produit ». Une app mobile, un client desktop, une bibliothèque packagée, un plugin commercial, un firmware ou un objet connecté peuvent entrer dans le champ. Le SaaS pur demande une lecture prudente : le CRA n’encadre pas tous les services en ligne, mais il couvre les traitements distants nécessaires au fonctionnement d’un produit, comme l’API backend indispensable à une app vendue par ton client.
À l’inverse, un outil interne développé sur mesure n’est pas le même cas qu’un plugin WordPress vendu à 2 000 clients. Certains secteurs, comme les dispositifs médicaux ou l’automobile, relèvent aussi de leurs propres règles.
Pose donc une question dans chaque brief : « Le livrable sera-t-il commercialisé, distribué ou mis à disposition d’utilisateurs externes dans l’Union européenne ? » Tu ne dois pas découvrir la réponse à la recette.
Si ton produit traite aussi des données, le CRA croise les réflexes du Data Act pour freelances.
Le CRA répartit les obligations entre fabricant, mandataire, importateur et distributeur. Pour un freelance, le point décisif n’est pas l’intitulé du devis, c’est le rôle que tu joues.
Le fabricant développe ou fait développer un produit et le met sur le marché sous son nom. Il porte les obligations lourdes : analyse de risque, documentation technique, suivi des vulnérabilités, mises à jour, marquage CE. Tu t’en rapproches si tu vends ton propre SaaS, ton plugin ou ton extension sous ta marque, ou si tu fais développer un produit par d’autres freelances pour le revendre comme ta solution.
Tu restes le plus souvent prestataire quand tu codes sur instruction du client, dans son dépôt, sous sa marque. Ce rôle limite ton exposition réglementaire directe, mais il ne te protège pas d’un contrat mal écrit qui te transfère la conformité, la maintenance ou la notification sans budget ni pouvoir de décision.
| Situation | Lecture probable | Réflexe avant signature |
|---|---|---|
| Outil interne sur mesure | Risque CRA généralement limité | Écrire que l’outil n’est pas destiné au marché |
| Maintenance d’une app déjà vendue | Client fabricant, toi mainteneur | Définir surveillance, délais et correctifs |
| Plugin vendu sous ta marque | Tu peux être fabricant | Documentation, suivi des failles, support |
| SaaS personnel payant | Tu peux être fabricant | Inventaire des composants, procédure incident |
La maintenance est le cas le plus piégeux. Tu n’as pas choisi toutes les dépendances ni l’historique, mais le client veut un engagement. Garantis ton périmètre (code maintenu, dépendances listées, délai de réaction), pas tout l’héritage. Dans les grands comptes, ces exigences arrivent par les questionnaires fournisseurs : lis-les avant de cocher « OK ».
Si le client commercialise le produit, il ne peut pas te traiter comme fabricant sans te donner le contrôle qui va avec.
Depuis le 11 septembre 2026, la Commission impose aux fabricants de signaler les vulnérabilités activement exploitées et les incidents sévères, via la plateforme unique de l’ENISA. Ces obligations visent aussi les produits déjà mis sur le marché avant décembre 2027.
L’article 14 prévoit trois temps :
Dans une mission classique, le fabricant qui notifie sera le client qui vend le produit. Mais c’est souvent toi qui découvres, confirmes ou corriges. Alerter le client n’est pas notifier l’ENISA à sa place. Ton contrat doit donc prévoir une obligation d’alerte, de coopération et de documentation, pas une obligation de déclaration.
Prépare un journal type : produit et versions touchées, nature et sévérité de la faille, exploitation connue ou suspectée, mesure temporaire, correctif, date et heure de découverte, personnes informées. Sans trace, tout se rejoue de mémoire, et la relation client en pâtit.
Avant de signer, exige une phrase claire : qui décide qu’un événement est notifiable, qui déclare, qui informe les utilisateurs et qui te mandate pour intervenir.
L’annexe I du règlement exige des produits livrés sans vulnérabilité exploitable connue et configurés de façon sécurisée par défaut. En freelance, ça veut dire : pas de compte admin partagé, pas de mot de passe par défaut, pas de clé API dans le dépôt, pas de debug exposé en production. Ça paraît basique. C’est souvent là que les incidents commencent.
Les fabricants doivent tenir un SBOM (Software Bill of Materials), une nomenclature lisible par machine couvrant au moins les dépendances de premier niveau. Tu n’as pas toujours à le produire, mais livre au minimum une liste propre des dépendances, versions et licences, avec les lockfiles. Si le client exige un SBOM formel en SPDX ou CycloneDX, chiffre-le comme un livrable. Pour les licences open source, le guide sur la propriété intellectuelle en freelance complète ce point.
Le fabricant doit annoncer une durée de support, en principe d’au moins cinq ans, sauf si le produit est censé servir moins longtemps. Pour toi, c’est une question commerciale : qui maintient le produit pendant cette période, et qui paie ? Écris si ta mission couvre seulement la livraison, une garantie de recette ou un forfait de maintenance.
Les lignes directrices publiées par la Commission en juillet 2026 précisent qu’une évolution qui change le niveau de risque, comme une refonte de l’authentification ou une API publique, peut constituer une modification substantielle. Celui qui la réalise ou la commande devient alors fabricant du produit modifié. Ces chantiers ne se traitent pas comme un simple ticket.
Si tu fais déjà de la sécurité en mission, ces exigences peuvent devenir une offre : le guide pour devenir consultant cybersécurité freelance t’aide à la structurer.
Dans mes missions Scrum, j’ai appris à me méfier des responsabilités « partagées » jamais traduites en tâches. Partagé ne veut pas dire clair. Le jour où une faille sort, il faut un propriétaire pour chaque décision.
Périmètre sécurité. Liste ce qui est inclus (audit des dépendances, tests d’authentification, vérification des secrets) et ce qui est exclu (pentest complet, conformité CRA globale, surveillance 24/7). Si le client refuse le budget de test, note-le par écrit.
Garantie et maintenance. C’est là que les freelances se font piéger. Une formulation saine : « Les corrections liées à une non-conformité au cahier des charges validé sont incluses pendant la recette. Les vulnérabilités découvertes après recette, hors faute démontrée du prestataire, relèvent d’une maintenance facturée ou d’un contrat de support distinct. » Fais-la adapter par un juriste si l’enjeu est important.
Délai de réaction. Ne promets pas d’intervention immédiate sans astreinte vendue. Fixe un délai d’accusé de réception, un délai de première analyse, une plage horaire et un tarif urgence.
Responsabilité plafonnée. Refuse de porter les pertes indirectes, l’atteinte à l’image ou les sanctions administratives d’un produit que le client exploite et commercialise. Ton plafond doit rester cohérent avec ton assurance et le prix de la mission.
Coopération et modifications client. Exige l’accès aux logs, au dépôt et à un interlocuteur décisionnaire. Exclus les modifications faites sans ton accord : sinon, on t’appellera six mois plus tard pour une faille introduite par un hotfix sauvage.
Le guide sur le contrat de mission freelance t’aide à formaliser ces clauses. Si la facture d’un correctif devient contestée, tu bascules dans la logique du litige client.
Une faille critique ne se gère pas seulement avec du code. Elle se gère avec un contrat, des accès, une procédure et un budget.
Tu n’as pas besoin de devenir juriste pour répondre proprement au CRA. Voici la routine à mettre en place dès ta prochaine signature.
Et une demande de « petit correctif sécurité » hors périmètre mérite, comme tout scope creep, un prix et un délai.
Pas automatiquement. Une contribution bénévole à un projet non commercial ne te place pas dans le rôle de fabricant, et le texte prévoit un statut à part pour les organisations qui soutiennent durablement des projets open source. Tes clients te demanderont en revanche plus souvent des dépendances traçables.
Oui pour le signalement : depuis le 11 septembre 2026, il s'applique aussi aux produits déjà sur le marché. Les autres exigences ne visent ces produits que s'ils subissent une modification substantielle après le 11 décembre 2027.
Le non-respect des exigences essentielles et des obligations du fabricant peut coûter jusqu'à 15 millions d'euros ou 2,5 % du chiffre d'affaires mondial. Ces amendes visent les opérateurs économiques, d'où l'intérêt de ne pas endosser par contrat un rôle qui n'est pas le tien.
Le CRA vise la sécurité des produits numériques. NIS2 vise la cybersécurité de certaines organisations essentielles ou importantes, et DORA la résilience numérique du secteur financier. Un même client grand compte peut être soumis aux trois.
25 juin 2026 · 9 min
6 juillet 2026 · 8 min
8 mai 2026 · 8 min
