Cyber Resilience Act pour freelances dev : obligations, contrats et réflexes avant septembre 2026

Le 11 septembre 2026, le Cyber Resilience Act entre dans sa première phase opérationnelle pour les logiciels et produits numériques.

À partir de cette date, les fabricants de produits avec éléments numériques devront notifier certaines vulnérabilités activement exploitées et certains incidents sévères. Pas dans six mois après un comité. La logique officielle démarre par une alerte initiale sous 24 heures, puis une notification plus complète sous 72 heures.

Si tu es développeur freelance, consultant produit, DevOps freelance, expert no-code, créateur de plugin, intégrateur IoT ou éditeur d’un petit SaaS, tu vas forcément entendre parler du Cyber Resilience Act freelance dans les prochains mois. Le risque, c’est de répondre trop vite : “Je ne suis qu’un prestataire, donc ça ne me concerne pas.”

Parfois, cette réponse 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 ne l’était côté responsabilité après livraison. Qui surveille les dépendances ? Qui paie le correctif urgent ? Qui prévient les utilisateurs ? Qui garde la documentation technique ? Le jour où une faille critique sort, ces questions ne sont plus théoriques.

Ce guide ne remplace pas un avocat. Il te donne une méthode de tri pour comprendre ce que le règlement UE 2024/2847 change, ce que tu dois documenter et ce que tu dois mettre dans tes contrats avant septembre 2026.

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é.

Étape 1 : comprendre ce que le Cyber Resilience Act couvre

Le Cyber Resilience Act, ou CRA, est le règlement européen sur les exigences de cybersécurité applicables aux produits comportant des éléments numériques. La Commission européenne rappelle qu’il est entré en vigueur le 10 décembre 2024 et qu’il sera principalement applicable à partir du 11 décembre 2027, avec des obligations de reporting dès le 11 septembre 2026.

En langage freelance, le texte vise les produits numériques mis sur le marché européen : logiciel, matériel connecté, application, composant embarqué, extension, plugin, firmware, outil desktop, produit IoT, solution avec traitement distant, et parfois brique SaaS quand elle est liée au fonctionnement du produit.

Le mot important est “produit”. Une prestation de développement interne ne devient pas automatiquement un produit mis sur le marché. Mais dès que le livrable est commercialisé, distribué, intégré dans une offre, vendu sous une marque ou fourni à des utilisateurs dans l’Union européenne, le CRA peut entrer dans la conversation.

Produit avec éléments numériques

Un produit avec éléments numériques peut être matériel, logiciel ou hybride. Une montre connectée, une caméra IP, un routeur, une app mobile, un client desktop, une bibliothèque logicielle packagée, un plugin commercial ou un firmware peuvent entrer dans le champ.

Le règlement vise l’accès au marché européen. Si ton client vend son produit à des utilisateurs européens, le sujet se pose même si l’équipe de dev est distribuée ou si le code est hébergé hors de France.

Dans une mission, pose toujours cette question simple : le livrable reste-t-il un outil interne, ou devient-il une offre mise à disposition de clients, partenaires ou utilisateurs finaux ?

SaaS, cloud et traitement distant

Le SaaS pur mérite une lecture prudente. Le CRA n’est pas un règlement général sur tous les services numériques. Il vise les produits avec éléments numériques et inclut aussi certains traitements distants nécessaires à leur fonctionnement.

Exemple : tu développes une app mobile B2B vendue par ton client, avec une API backend indispensable au produit. Même si une partie tourne côté cloud, le client peut avoir besoin de traiter l’ensemble comme un produit à sécuriser.

Si tu travailles sur data, cloud, SaaS ou IoT, le CRA croise aussi les réflexes du Data Act pour freelances. Un même produit peut soulever des sujets de sécurité, de données, de réversibilité et de contrat.

Ce qui sort généralement du cœur du sujet

Tout n’est pas CRA. Un site vitrine développé sur mesure pour l’usage interne d’un client n’est pas le même cas qu’un plugin WordPress vendu à 2 000 clients. Un script ponctuel de migration n’est pas le même cas qu’une app mobile publiée sur les stores.

Certaines catégories très réglementées ont aussi leurs propres cadres, par exemple les dispositifs médicaux, l’automobile, l’aviation ou la finance. Dans ces cas, le CRA peut être écarté ou articulé avec une réglementation sectorielle.

Le bon réflexe n’est donc pas de paniquer. Il faut qualifier.

Étape 2 : identifier ton rôle dans la chaîne

Le CRA répartit les obligations entre plusieurs acteurs économiques : fabricant, mandataire, importateur, distributeur, mais aussi acteur open source dans certains cas. Pour un freelance, le point décisif est rarement le nom écrit en haut du devis. C’est le rôle réel que tu joues.

Fabricant

Le fabricant est l’acteur qui développe, fabrique ou fait développer un produit avec éléments numériques et le met sur le marché sous son nom ou sa marque. Il porte les obligations les plus lourdes : analyse de risque, exigences de sécurité, documentation technique, suivi des vulnérabilités, mises à jour, informations aux utilisateurs, conformité.

Tu peux t’en rapprocher si tu vends ton propre SaaS, ton plugin commercial, ton logiciel desktop, ton extension navigateur ou une solution packagée sous ta marque.

Tu peux aussi créer un risque si tu fais développer un produit par d’autres freelances, puis que tu le revends comme ta solution. Dans ce cas, tu n’es plus seulement “le dev”. Tu organises la mise sur le marché.

Simple prestataire ou sous-traitant technique

Tu es souvent simple prestataire quand tu développes sur instruction du client, dans son dépôt, sous sa marque, pour son produit, avec ses choix fonctionnels et commerciaux.

Ce rôle peut limiter ton exposition réglementaire directe. Mais il ne te protège pas d’un contrat mal écrit. Un client peut tenter de te transférer des obligations générales de conformité, de maintenance ou de notification sans te donner le budget, le pouvoir de décision ni les accès nécessaires.

Une phrase doit donc apparaître dans ton cadrage : “Le client reste responsable de la mise sur le marché et des obligations réglementaires liées au produit, sauf mission spécifique explicitement prévue.”

Mandataire, importateur ou distributeur

Ces rôles sont moins fréquents pour un freelance solo, mais pas impossibles. Tu peux les croiser si tu représentes un éditeur hors UE, si tu revends une solution logicielle sous une offre européenne ou si tu distribues un produit numérique à tes clients.

Si tu ne fais que recommander un outil, ce n’est pas pareil. Si tu le packages, le revends, le rebaptises, le maintiens et le présentes comme ton offre, ton rôle change.

Éditeur SaaS indépendant

Beaucoup de freelances créent un petit SaaS en parallèle de leurs missions. Tant qu’il s’agit d’un projet privé, le CRA reste lointain. Quand tu l’ouvres à des clients européens, que tu encaisses des abonnements et que le logiciel traite des données ou fonctions utiles à leur activité, il faut regarder le texte avec sérieux.

La même vigilance vaut si tu productises une méthode en outil commercial. Le guide sur productiser son offre freelance parle du modèle économique. Ici, on ajoute la couche sécurité et conformité produit.

Contributeur open source

L’open source n’est pas traité comme une zone magique hors droit. L’Open Source Security Foundation rappelle que le CRA couvre les produits avec éléments numériques, y compris leurs composants, et que les fabricants devront regarder leurs dépendances.

Mais contribuer gratuitement à un projet open source non commercial ne te place pas automatiquement dans la même position qu’un fabricant. Le texte distingue notamment les fabricants et les “open source software stewards”, ces organisations qui soutiennent durablement des projets open source sans être fabricants.

Pour un freelance, la conséquence est pratique : tes clients vont demander plus souvent une liste de dépendances, un SBOM, une politique de vulnérabilité ou une preuve de suivi. Même si tu n’es pas directement visé, ta livraison devra aider le client à répondre.

Ton contrat doit décrire ton rôle réel. Si le client commercialise le produit, il ne peut pas te traiter comme fabricant sans te donner le contrôle qui va avec.

Étape 3 : passer les cas freelance fréquents au crible

Avant de signer, classe ta mission. Ce tri évite de transformer une prestation normale en promesse de conformité illimitée.

Situation	Lecture probable	Réflexe avant signature
Développement sur mesure d’un outil interne	Risque CRA généralement limité	Préciser que l’outil n’est pas destiné à une mise sur le marché.
Maintenance d’une app client déjà commercialisée	Le client peut être fabricant, toi prestataire de maintenance	Définir surveillance, SLA, correctifs de sécurité et preuve de livraison.
Plugin vendu sur une marketplace	Risque fort si tu le vends sous ta marque	Prévoir documentation, suivi des vulnérabilités, mises à jour et support.
Contribution open source bénévole	Souvent hors rôle fabricant direct	Documenter les pratiques si le projet est utilisé par des acteurs commerciaux.
SaaS personnel vendu à des clients	Tu peux être fabricant ou fournisseur du produit	Mettre en place registre de composants, politique sécurité, support et procédure incident.
Agence ou collectif qui revend une solution	L’entité qui revend peut porter le rôle principal	Répartir les responsabilités entre collectif, devs et client final.

Mission de développement sur mesure

Tu développes une app métier pour un client, dans son environnement, pour ses équipes internes. Le CRA n’est généralement pas le premier sujet. Il faut surtout cadrer RGPD, sécurité, propriété intellectuelle, maintenance et responsabilité.

Mais si le client indique que l’app sera vendue à ses propres clients, la mission change de nature. Tu ne dois pas découvrir ce point à la recette.

Ajoute une question dans ton brief : “Le livrable sera-t-il commercialisé, distribué, intégré à une offre ou mis à disposition d’utilisateurs externes dans l’Union européenne ?”

Maintenance d’une application existante

La maintenance est le cas le plus piégeux. Tu n’as pas conçu le produit, tu n’as pas choisi toutes les dépendances, tu ne connais pas l’historique de sécurité, mais le client veut un engagement de correction.

Dans ce cas, refuse les formules vagues du type “le prestataire garantit la conformité du logiciel”. Tu peux garantir ton périmètre : audit initial, surveillance de dépendances listées, correctifs sur le code maintenu, délai de réaction, reporting.

Tu ne peux pas garantir tout l’héritage.

Plugin ou extension commercialisée

Un plugin Shopify, WordPress, Figma, Chrome ou VS Code vendu sous ta marque peut te rapprocher du fabricant. Même s’il paraît petit, il peut accéder à des données, modifier un environnement, ouvrir une surface d’attaque ou dépendre de bibliothèques tierces.

Le réflexe minimum : documentation d’installation, changelog, suivi de versions, contact vulnérabilité, politique de support, dépendances, procédure de retrait ou correctif d’urgence.

SaaS personnel

Si ton SaaS devient une activité commerciale, même modeste, lis le CRA comme un sujet produit. Tu dois savoir quelles données tu traites, quelles dépendances tu embarques, comment tu patches, comment tu préviens tes clients et combien de temps tu fournis des mises à jour de sécurité.

Ce point rejoint l’AI Act pour freelances si ton SaaS intègre un modèle d’IA. Il rejoint aussi le RGPD si tu traites des données personnelles.

Mission grand compte

Dans les grands comptes, le CRA va souvent arriver par les achats, la sécurité ou le juridique. Tu verras des questionnaires fournisseurs, des exigences SBOM, des clauses d’incident, des obligations de coopération et des pénalités.

Lis-les avant de répondre “OK” dans un portail. Le guide sur les grands comptes en freelance détaille déjà le piège des circuits fournisseurs : le document signé pèse plus lourd que la promesse orale du manager.

Étape 4 : retenir le calendrier exact

Le calendrier CRA est simple, mais il faut le dire avec des dates précises.

Date	Ce qui se passe	Impact pour toi
10 décembre 2024	Entrée en vigueur du règlement	Le cadre juridique existe déjà.
11 juin 2026	Application des règles sur les organismes d’évaluation de conformité	Impact indirect, surtout pour les produits plus sensibles.
11 septembre 2026	Application des obligations de reporting de l’article 14	Les fabricants doivent notifier certaines vulnérabilités exploitées et incidents sévères.
11 décembre 2027	Application principale du CRA	Les exigences de sécurité, documentation, conformité et suivi deviennent centrales pour les produits concernés.

La date du 11 septembre 2026 est importante pour les freelances, car elle arrive avant l’application principale. Le règlement prévoit aussi que ces obligations de reporting s’appliquent aux produits concernés déjà mis sur le marché avant le 11 décembre 2027. Elle va donc pousser les clients à demander des clauses de notification, des procédures d’incident et des preuves de sécurité dès les nouveaux contrats.

Autrement dit, tu ne dois pas attendre décembre 2027 pour agir. Une app livrée en août 2026 peut encore être en production en septembre 2026. Un plugin livré aujourd’hui peut encore dépendre de tes correctifs dans un an.

Le bon calendrier contractuel commence à la signature, pas à la date d’entrée en application.

Étape 5 : transformer les obligations CRA en pratiques de dev

Le CRA parle de cybersécurité par conception, de gestion des vulnérabilités, de documentation et de mises à jour. Dans ton quotidien, ça se traduit par des pratiques très concrètes.

Sécurité dès la conception

Le règlement exige un niveau de cybersécurité adapté aux risques. Pour un freelance, cela commence avant la première ligne de code.

Dans ton cadrage, identifie :

• les données sensibles ;
• les rôles utilisateurs ;
• les accès admin ;
• les API exposées ;
• les dépendances critiques ;
• les secrets ;
• les scénarios d’abus raisonnablement prévisibles.

Ce n’est pas forcément un audit lourd. Sur une petite mission, une page de risques suffit déjà à montrer que tu as pensé sécurité avant livraison.

Configuration sécurisée par défaut

L’annexe I du règlement insiste sur des produits livrés sans vulnérabilité exploitable connue, avec une configuration sécurisée par défaut quand c’est applicable. En freelance, cela 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.

Gestion des vulnérabilités

Tu dois prévoir comment une faille est identifiée, évaluée, corrigée et communiquée. Même si le client reste responsable, ton contrat peut te demander de contribuer à cette chaîne.

Une bonne procédure contient :

• un contact sécurité ;
• un canal de signalement ;
• une méthode de tri de sévérité ;
• un délai de réaction ;
• un processus de patch ;
• une trace des décisions ;
• un message utilisateur si nécessaire.

Si tu fais déjà de la cybersécurité en mission, le guide devenir consultant cybersécurité freelance peut t’aider à transformer ces exigences en offre facturable.

SBOM et dépendances open source

Le SBOM, pour Software Bill of Materials, est la nomenclature des composants logiciels. Dans le CRA, les fabricants doivent identifier et documenter les vulnérabilités et les composants, avec un SBOM dans un format courant et lisible par machine couvrant au minimum les dépendances de premier niveau.

Dans une mission freelance, tu n’as pas toujours à produire un SBOM complet. Mais tu dois pouvoir livrer une liste propre de dépendances, versions, licences, outils de build et composants critiques.

Tu peux utiliser des formats comme SPDX ou CycloneDX si le client les demande. Sinon, une première base exploitable vaut mieux qu’un silence : gestionnaire de paquets, lockfile, versions, outils d’analyse, alertes GitHub ou équivalent, dépendances non maintenues.

Mises à jour de sécurité

Le CRA met l’accent sur la possibilité de corriger les vulnérabilités par des mises à jour de sécurité. Contractuellement, c’est là que les freelances se font piéger.

La livraison initiale ne couvre pas automatiquement une maintenance gratuite illimitée.

Tu dois distinguer :

• bug de livraison dans le périmètre accepté ;
• vulnérabilité découverte après recette ;
• dépendance tierce devenue vulnérable ;
• changement demandé par le client ;
• urgence de production ;
• support de sécurité récurrent.

Sans cette distinction, le client peut considérer qu’une faille découverte huit mois plus tard relève de ta garantie gratuite. Parfois, il aura raison si la faille vient d’une erreur manifeste dans ton code livré. Souvent, il faudra regarder le contrat, la maintenance et le contexte.

Durée de support et modifications substantielles

La Commission rappelle aussi que le fabricant doit déterminer une durée de support pendant laquelle les vulnérabilités du produit sont gérées efficacement, avec une date de fin compréhensible pour l’utilisateur. Le règlement fixe en principe un minimum de cinq ans, sauf si le produit est censé être utilisé moins longtemps. Pour un freelance, cette phrase doit devenir une question commerciale : combien de temps le client veut-il que le produit reste maintenu, et qui paie cette continuité ?

Ne laisse pas le support implicite. Si tu livres un plugin, une app mobile ou une brique SaaS, indique si la mission inclut seulement la livraison initiale, trois mois de garantie de recette, un forfait de maintenance, ou un support de sécurité plus long.

Autre point sensible : la modification substantielle. La guidance CRA publiée par la Commission en juillet 2026 insiste sur ce sujet, car une évolution importante peut changer le niveau de risque ou le statut du produit. Une refonte d’authentification, l’ajout d’une API publique, une intégration IoT ou un changement majeur d’architecture ne se traite pas comme un simple ticket.

Quand le client change profondément le produit après livraison, il faut refaire une analyse de risque. Sinon, tu restes associé à une version que tu ne contrôles plus.

Documentation technique

La documentation n’est plus un bonus. Elle devient une preuve.

Livre au minimum :

• architecture et périmètre ;
• instructions d’installation ;
• variables d’environnement ;
• dépendances et versions ;
• limites connues ;
• tests réalisés ;
• procédure de mise à jour ;
• contact vulnérabilité ;
• historique des correctifs de sécurité.

Si le client veut une documentation de conformité CRA complète, c’est une prestation. Elle doit être chiffrée. Le guide sur le contrat de mission freelance t’aidera à formaliser ce type de livrable.

Conformité, marquage CE et catégories sensibles

Avant de mettre un produit concerné sur le marché, le fabricant doit réaliser une évaluation de conformité, établir une déclaration UE de conformité et apposer le marquage CE quand les conditions sont remplies. La Commission précise que certains produits dits importants ou critiques, listés dans les annexes III et IV, peuvent nécessiter une procédure plus encadrée qu’une auto-évaluation simple.

Pour un freelance, le réflexe est simple : ne promets pas “conformité CRA” si ton périmètre se limite au code. Tu peux produire des éléments techniques utiles, par exemple inventaire des composants, tests réalisés, notes d’architecture, procédure de mise à jour et historique des vulnérabilités corrigées.

La décision de mise sur le marché, la déclaration de conformité, le marquage CE et le choix d’un organisme d’évaluation relèvent généralement du client fabricant. Si le client veut que tu prépares le dossier technique ou que tu échanges avec un organisme, fais-en une ligne de mission séparée.

Étape 6 : cadrer la notification des vulnérabilités et incidents

La partie la plus urgente du CRA pour 2026 concerne la notification. La page de la Commission sur les obligations de reporting indique que les fabricants devront signaler les vulnérabilités activement exploitées et les incidents sévères affectant la sécurité des produits.

L’ENISA précise que la Single Reporting Platform doit être utilisée à partir du 11 septembre 2026 par les CSIRT et les fabricants pour les signalements obligatoires. La plateforme peut aussi servir à des signalements volontaires par d’autres personnes physiques ou morales.

Les délais à connaître

Pour une vulnérabilité activement exploitée, l’article 14 prévoit :

• alerte initiale sous 24 heures après prise de connaissance ;
• notification de vulnérabilité sous 72 heures, sauf si les informations ont déjà été fournies ;
• rapport final au plus tard 14 jours après la disponibilité d’une mesure corrective ou d’atténuation.

Pour un incident sévère affectant la sécurité du produit :

• alerte initiale sous 24 heures ;
• notification d’incident sous 72 heures ;
• rapport final dans le mois suivant la notification d’incident.

Le freelance n’est pas toujours celui qui notifie. Mais il peut être celui qui découvre, confirme, corrige ou documente l’événement. Si ton contrat ne dit rien, tu risques de passer ton week-end à improviser une cellule de crise non facturée.

Qui doit notifier ?

Le texte vise les fabricants pour le reporting obligatoire. Dans une mission client classique, le fabricant sera souvent le client qui commercialise le produit, pas le freelance qui a développé une fonctionnalité.

Mais ton contrat peut t’imposer une obligation d’alerte. C’est normal. Si tu découvres une faille critique dans le produit du client, tu dois prévenir vite et garder une trace.

La nuance est essentielle : alerter le client n’est pas forcément notifier officiellement l’ENISA ou un CSIRT au nom du fabricant.

Quelles informations préparer ?

Même si tu n’es pas le déclarant légal, prépare de quoi aider :

• produit concerné ;
• versions touchées ;
• nature de la vulnérabilité ou de l’incident ;
• niveau de sévérité estimé ;
• exploitation connue ou suspectée ;
• données ou fonctions impactées ;
• mesure temporaire ;
• correctif prévu ;
• date et heure de découverte ;
• personnes informées ;
• preuves techniques conservées.

Un journal simple peut sauver la relation client. Sans trace, tout se rejoue de mémoire.

Avant de signer, exige une phrase claire : qui décide qu’un événement est notifiable, qui déclare, qui communique aux utilisateurs et qui te mandate pour intervenir.

Étape 7 : répartir les responsabilités client et freelance

La bonne grille n’est pas “qui est coupable ?” La bonne grille est “qui fait quoi, quand et avec quel budget ?”

Sujet	Client	Freelance
Mise sur le marché	Décide de vendre, publier ou distribuer le produit	Signale si le périmètre de mission semble concerné
Analyse réglementaire	Fait valider son rôle et ses obligations	Fournit les informations techniques dans son périmètre
Maintenance	Décide du niveau de support et du budget	Intervient si une maintenance est signée
Surveillance CVE	Organise la veille globale produit	Surveille les dépendances prévues au contrat
Correctif de sécurité	Priorise, valide, publie	Diagnostique et corrige dans le périmètre convenu
Notification officielle	Porte généralement la déclaration si fabricant	Alerte, documente et coopère
Communication utilisateurs	Décide du message et du canal	Fournit les éléments techniques exacts
Documentation	Conserve le dossier produit	Livre les documents prévus
Coût des jours urgents	Finance l’intervention hors garantie	Applique le tarif prévu, astreinte incluse si signée

Ce tableau doit vivre dans ton devis, ton contrat ou une annexe sécurité. S’il reste dans ta tête, il ne sert à rien.

Dans mes missions Scrum, j’ai appris à me méfier des responsabilités “partagées” qui ne sont 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.

Étape 8 : écrire les clauses utiles dans ton contrat

Le CRA ne t’oblige pas à transformer chaque devis en roman juridique. Mais il rend certaines clauses beaucoup plus importantes pour les missions dev, app, SaaS, plugin, IoT et maintenance.

Périmètre sécurité

Décris ce qui est inclus : revue de dépendances, durcissement basique, tests automatisés, audit manuel, correction de failles connues, documentation, accompagnement à la notification.

Décris aussi ce qui est exclu : pentest complet, conformité CRA globale, certification, analyse juridique, surveillance 24/7, astreinte, correction de composants hors périmètre.

Niveau de test

Écris les tests prévus : lint sécurité, audit dépendances, tests d’authentification, revue de droits, vérification des secrets, scan de conteneur, tests OWASP ciblés, ou pentest externe.

Si le client refuse le budget de test, note-le. Un refus oral ne suffit pas.

Dépendances tierces et open source

Indique que le produit peut intégrer des composants tiers ou open source, avec leurs licences et cycles de maintenance. Précise qui valide les dépendances sensibles, qui accepte les licences et qui décide de remplacer une dépendance abandonnée.

Pour les composants open source, le bon réflexe est aussi de vérifier la licence. Le guide sur la propriété intellectuelle en freelance complète ce point.

Maintenance corrective et support post-livraison

Sépare la garantie de livraison et la maintenance de sécurité.

Une clause saine peut dire :

“Les corrections liées à une non-conformité du livrable au cahier des charges validé sont incluses pendant la période de recette. Les vulnérabilités découvertes après recette, hors faute démontrée du prestataire dans le périmètre livré, relèvent d’une maintenance corrective facturée ou d’un contrat de support distinct.”

Fais adapter cette formulation par un juriste si l’enjeu financier est important.

Ajoute aussi une durée. Par exemple : “Le support de sécurité est fourni pendant la durée du contrat de maintenance signé. À défaut de contrat de maintenance, aucune surveillance continue des vulnérabilités, dépendances ou incidents postérieurs à la recette n’est incluse.”

Délai de réaction

Ne promets pas “intervention immédiate” si tu n’as pas vendu d’astreinte.

Prévois plutôt :

• délai d’accusé de réception ;
• délai de première analyse ;
• plage horaire ;
• tarif urgence ;
• canal de contact ;
• conditions d’accès à la production.

Responsabilité plafonnée

Un client peut te demander de porter une responsabilité disproportionnée sur un produit qu’il exploite, modifie et commercialise. Refuse les clauses qui te rendent responsable de pertes indirectes, perte de chiffre d’affaires, atteinte à l’image, sanctions administratives ou incident causé par une modification client hors contrôle.

Le plafonnement de responsabilité doit être cohérent avec ton assurance, ton chiffre d’affaires et le prix de la mission. Si le client refuse, facture le risque ou fais relire.

Obligation de coopération

Prévois une obligation réciproque : accès aux logs, accès au dépôt, accès à l’infrastructure, interlocuteur décisionnaire, validation rapide des correctifs, conservation des preuves, information si le client modifie le code.

Sans coopération du client, tu ne peux pas porter une obligation de résultat sur l’incident.

Réversibilité et documentation livrée

La sécurité dépend aussi de la capacité à reprendre le produit. Indique ce qui est remis : dépôt de code, documentation d’installation, scripts, variables d’environnement sans secrets, inventaire des dépendances, procédures de déploiement, notes de sécurité.

Ce point rejoint les réflexes du Data Act et du contrat de mission. Une livraison propre réduit aussi les litiges.

Exclusion si le client modifie le code

Ajoute une clause simple : ta responsabilité ne couvre pas les modifications, configurations, déploiements ou intégrations réalisés sans ton accord ou hors procédure prévue.

Ce n’est pas pour fuir toute responsabilité. C’est pour éviter d’être appelé six mois plus tard sur une faille introduite par un hotfix sauvage.

Étape 9 : regarder un exemple concret

Prenons un cas fréquent : tu livres une app B2B à un client SaaS. L’app permet à ses propres clients de suivre des tickets, d’uploader des documents et de gérer des utilisateurs. Tu développes le front, une API, un module d’authentification et quelques workflows.

La recette est signée. Huit mois plus tard, une vulnérabilité critique est découverte dans une dépendance utilisée par l’API. Elle est activement exploitée sur le marché.

Scénario sans clause

Le client t’appelle le vendredi soir. Il considère que tu as livré “un produit sécurisé”, donc que le correctif est gratuit. Il veut aussi que tu l’aides à qualifier la faille, rédiger le message client, préparer la notification et déployer en urgence.

Tu n’as plus les accès complets. Le dépôt a été modifié par son équipe. La dépendance a changé de version depuis ta livraison. Personne ne sait si une maintenance était incluse.

La discussion tourne vite au conflit : qui paie, qui décide, qui a introduit la faille, qui doit prévenir les utilisateurs ?

Si la facture devient contestée, tu bascules dans la logique du litige client en freelance. Et ce n’est jamais le bon moment pour découvrir que le contrat était flou.

Scénario avec clause de maintenance et procédure incident

Le contrat prévoit une maintenance de sécurité de 2 jours par mois, un tarif urgence, un canal de contact, une liste de dépendances suivies, un délai de première analyse sous 8 heures ouvrées et une obligation de coopération du client.

La procédure dit que le client reste responsable de la notification officielle, car il commercialise le produit. Toi, tu dois alerter, qualifier techniquement, proposer une mitigation, livrer le patch et documenter les éléments disponibles.

Tu consultes le lockfile, tu identifies les versions touchées, tu proposes une mesure temporaire, tu patches, tu notes l’heure de découverte, l’heure de correction, le commit, le déploiement et les limites restantes.

La mission reste tendue, mais elle est pilotable.

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.

Étape 10 : préparer tes checklists avant signature et livraison

Tu n’as pas besoin d’une usine documentaire sur chaque mission. Tu as besoin de deux checklists courtes, réutilisables et adaptées au risque.

Checklist avant signature

• Le produit est-il destiné à un usage interne ou à une mise sur le marché ?
• Qui commercialise, publie ou distribue le produit ?
• Quel est ton rôle exact : prestataire, mainteneur, éditeur, revendeur, collectif, sous-traitant ?
• Le client attend-il une conformité CRA globale ou seulement une contribution technique ?
• Le produit entre-t-il dans une catégorie importante ou critique qui exige une évaluation plus poussée ?
• Quelles exigences sécurité sont incluses dans le prix ?
• Quel budget est prévu pour les tests ?
• Qui surveille les CVE et dépendances ?
• Un SBOM ou inventaire de composants est-il demandé ?
• Quelle maintenance est prévue après livraison ?
• Quelle durée de support sécurité est annoncée aux utilisateurs ?
• Qui décide et finance les correctifs urgents ?
• Qui notifie un incident ou une vulnérabilité activement exploitée ?
• Quel interlocuteur légal et sécurité sera disponible côté client ?
• Quelles exclusions protègent ton périmètre si le client modifie le code ?

Checklist de livraison

• Dépôt de code remis ou accès confirmé.
• Liste des dépendances et versions exportée.
• Lockfiles présents et cohérents.
• Secrets retirés du dépôt.
• Variables d’environnement documentées sans valeurs sensibles.
• Tests sécurité réalisés et résultats conservés.
• Vulnérabilités connues listées avec arbitrage client.
• Documentation d’installation fournie.
• Procédure de mise à jour décrite.
• Durée de support ou absence de support continu rappelée par écrit.
• Contact vulnérabilité indiqué.
• Changelog et commits de sécurité identifiables.
• Limites connues et exclusions rappelées.
• Procès-verbal de recette ou validation écrite obtenu.

Cette checklist protège aussi contre le scope creep en freelance. Une demande de “petit correctif sécurité” peut être légitime. Mais si elle sort du périmètre signé, elle doit avoir un prix, un délai et une priorité explicites.

Cyber Resilience Act, RGPD, NIS2 et DORA : ce que le CRA ne remplace pas

Le CRA ne remplace pas le RGPD. Si ton produit traite des données personnelles, tu dois toujours gérer base légale, information, sous-traitance, sécurité, droits des personnes, durée de conservation et violation de données.

Il ne remplace pas l’AI Act. Si ton logiciel intègre une IA qui interagit avec des utilisateurs, prend part à une décision ou produit du contenu, tu dois regarder le cadre IA en plus.

Il ne remplace pas NIS2. NIS2 vise la cybersécurité de certaines entités essentielles ou importantes. Le CRA vise la cybersécurité des produits avec éléments numériques. Les deux peuvent se croiser chez un client grand compte, mais ils ne répondent pas à la même question.

Il ne remplace pas DORA. DORA concerne la résilience opérationnelle numérique du secteur financier et de certains prestataires ICT. Si tu travailles pour une banque, une assurance ou une fintech, le CRA peut s’ajouter à un cadre DORA déjà exigeant.

Il ne remplace pas ton contrat.

Le texte pose des obligations. Ton contrat répartit le travail, le coût et la responsabilité entre ton client et toi.

Conclusion : ton plan d’action avant septembre 2026

Le Cyber Resilience Act freelance n’est pas un sujet réservé aux directions juridiques. Si tu développes des logiciels, apps, plugins, extensions, objets connectés ou briques SaaS, il va entrer dans tes missions par les questionnaires sécurité, les clauses de maintenance, les demandes de SBOM et les procédures d’incident.

Voici la routine à mettre en place dès maintenant.

1. Ajoute une question “mise sur le marché ou usage interne ?” dans ton brief.
2. Classe ton rôle : prestataire, mainteneur, éditeur, revendeur ou collectif.
3. Refuse les promesses de conformité globale si tu ne contrôles pas le produit.
4. Livre au minimum une liste de dépendances, une documentation d’installation et les limites connues.
5. Sépare garantie de recette, maintenance corrective et support de sécurité.
6. Prévois qui alerte, qui notifie, qui corrige et qui paie.
7. Garde une trace des vulnérabilités, correctifs, versions et décisions client.

Tu n’as pas besoin de devenir juriste pour travailler proprement. Tu dois surtout arrêter de laisser la sécurité dans les angles morts du devis.

Le 11 septembre 2026 arrive vite. Les freelances qui sauront cadrer ces sujets sans dramatiser auront un avantage net : ils parleront le langage des clients sérieux, sans accepter une responsabilité qui ne leur appartient pas.

FAQ

Questions fréquentes

Le CRA concerne-t-il un freelance développeur web ? +

Oui, parfois. Si tu développes un site vitrine ou un outil interne sur mesure, le CRA n'est généralement pas le sujet principal. Si tu développes une app, un plugin, une extension, un logiciel ou une brique intégrée à un produit commercialisé en Europe, il faut qualifier le rôle du client et le tien.

Un SaaS est-il concerné par le Cyber Resilience Act ? +

Un SaaS pur n'est pas automatiquement traité comme n'importe quel produit matériel, mais le CRA peut couvrir des produits avec éléments numériques et certains traitements distants nécessaires à leur fonctionnement. Pour un SaaS commercial, il faut analyser le périmètre, les fonctions, la mise à disposition sur le marché européen et les autres textes applicables.

Qui doit notifier une vulnérabilité sous le CRA ? +

Le reporting obligatoire de l'article 14 vise les fabricants. Dans une mission freelance classique, le client qui commercialise le produit sera souvent mieux placé pour notifier officiellement. Le freelance doit surtout avoir une obligation d'alerte, de coopération et de documentation clairement prévue au contrat.

Faut-il fournir un SBOM à chaque client ? +

Pas forcément dans un format complet sur chaque petite mission. En revanche, pour un produit logiciel commercialisé, un inventaire des dépendances devient un réflexe sérieux. Si le client demande un SBOM formel, par exemple SPDX ou CycloneDX, il faut le chiffrer comme un livrable.

Que faire avec les dépendances open source ? +

Liste les dépendances, leurs versions, leurs licences et leur niveau de maintenance. Surveille les vulnérabilités critiques si c'est prévu au contrat. Le CRA pousse les fabricants à mieux connaître leur chaîne logicielle, donc les freelances devront livrer des composants plus traçables.

Puis-je facturer les correctifs de sécurité ? +

Oui, si le correctif sort de la garantie de recette ou d'une faute démontrée dans ton périmètre livré. Le plus important est de distinguer dans le contrat la correction de non-conformité, la maintenance de sécurité, l'urgence de production et les évolutions demandées par le client.

Le client peut-il me transférer toute la responsabilité CRA ? +

Il peut essayer de l'écrire, mais tu ne dois pas l'accepter sans contrôle, budget et assurance adaptés. Si le client met le produit sur le marché, décide de son exploitation et communique avec les utilisateurs, il doit garder les responsabilités correspondantes.

Quelle différence entre CRA, NIS2 et DORA ? +

Le CRA vise la cybersécurité des produits avec éléments numériques. NIS2 vise la cybersécurité de certaines organisations essentielles ou importantes. DORA vise la résilience numérique du secteur financier. Un même client peut être concerné par plusieurs textes, mais ton rôle freelance doit être cadré mission par mission.