CRA pour les startups : la conformité avec un seul ingénieur

Vous livrez un produit connecté avec une petite équipe, et le CRA va s'appliquer à vous. Ses obligations principales entrent en vigueur le 11 décembre 2027, avec le signalement des vulnérabilités dès le 11 septembre 2026 : il faut donc l'intégrer maintenant, pas plus tard. Deux points piègent les startups : l'obligation de support de sécurité pluriannuelle qui démarre dès que vous placez le produit sur le marché de l'UE, et le fait de devoir tout gérer sans recrutement sécurité dédié.

Ce guide s'adresse aux fondateurs et aux premiers ingénieurs qui doivent être conformes au CRA sans surinvestir ni complexifier leur produit inutilement. Il détaille ce que vous pouvez sereinement laisser de côté, ce que vous ne pouvez pas, et comment une seule personne peut porter l'ensemble du sujet.

Le CRA s'applique-t-il à votre startup ?

Faites quatre vérifications rapides. Le CRA couvre les produits comportant des éléments numériques qui se connectent à un réseau ou à un autre appareil et qui sont mis à disposition sur le marché de l'UE dans le cadre d'une activité commerciale.

Si votre produit entre dans le périmètre, la question suivante est sa catégorie. C'est elle qui détermine si vous vous auto-évaluez ou si vous avez besoin d'un organisme notifié. Confirmez-la avec le guide de classification des produits avant d'y consacrer une seule journée de plus.

Votre principal avantage structurel : l'auto-évaluation

La plus grosse économie possible pour une startup tient à un fait simple : un produit hors des catégories Importante et Critique est un produit par défaut. Pour ces produits, le CRA autorise l'auto-évaluation : vous réalisez vous-même le travail de conformité, vous signez la déclaration UE de conformité, et vous apposez le marquage CE. Aucun organisme externe, aucun frais par produit. Le détail de chaque voie figure dans le guide de l'évaluation de la conformité. Pour une startup, l'enjeu est de ne pas payer une évaluation tierce dont vous n'avez pas besoin.

Important : L'auto-évaluation n'allège pas la conformité. Vous devez toujours répondre aux mêmes exigences essentielles. Vous les attestez vous-même, au lieu de payer quelqu'un pour le faire à votre place.

Les allègements que le CRA prévoit pour les startups

Le CRA prévoit des mesures de soutien écrites spécifiquement pour les microentreprises, les petites et moyennes entreprises et les startups. Le bénéfice de ces allègements dépend de votre taille, selon la définition standard de l'UE : une microentreprise compte moins de 10 salariés et un chiffre d'affaires ou un bilan inférieur ou égal à 2 millions d'euros, et une petite entreprise compte moins de 50 salariés et un chiffre d'affaires ou un bilan inférieur ou égal à 10 millions d'euros.

Quatre allègements qu'une startup peut réellement utiliser :

• Documentation simplifiée : les microentreprises et les petites entreprises peuvent déposer la documentation technique sous une forme simplifiée définie par la Commission, que les organismes notifiés doivent accepter.
• Frais de conformité réduits : lorsque votre produit nécessite un organisme notifié, les besoins spécifiques des PME, y compris des startups, doivent être pris en compte et les frais réduits proportionnellement.
• Bacs à sable réglementaires : les États membres peuvent mettre en place des environnements contrôlés où vous développez et testez un produit innovant au regard du CRA avant de le placer sur le marché, avec un accès facilité pour les startups.
• Soutien direct : le cas échéant, les États membres organisent des actions de sensibilisation et de formation ainsi qu'un canal de conseil dédié aux petites structures, et la Commission oriente vers les financements disponibles.

Astuce : Demandez à votre autorité nationale de surveillance du marché ou à votre pôle d'innovation numérique si le formulaire de documentation simplifiée et un bac à sable réglementaire sont déjà actifs dans votre pays. Les deux dépendent de la mise en œuvre nationale et de la Commission, donc la disponibilité varie.

Devenir conforme avec un seul ingénieur

Vous n'avez pas besoin d'une équipe sécurité. Vous avez besoin d'un responsable identifié et d'une courte liste de tâches automatisées. Cette personne tient le dossier technique, trie les rapports de vulnérabilité entrants et signe la déclaration de conformité. Une seule personne peut porter ce rôle, mais soyez honnête : le traitement continu des vulnérabilités, la livraison des mises à jour et la documentation restent un vrai travail d'ingénierie. Le guide du coût de la conformité CRA modélise l'effort et le budget d'une petite équipe pour que vous puissiez dimensionner correctement les effectifs.

Trois choses méritent d'être automatisées en premier. Chacune est un problème déjà résolu par des outils gratuits, et ensemble elles couvrent vos obligations les plus visibles en début de parcours. C'est un point de départ, pas la vue d'ensemble.

• Générez un SBOM en CI : le CRA exige une nomenclature logicielle couvrant au moins vos dépendances de premier niveau, et des outils open source comme Syft et Trivy en produisent une à chaque build. La chaîne d'outils complète est dans le guide de génération de SBOM.
• Surveillez les vulnérabilités : scannez vos dépendances à chaque build et traitez les résultats selon le risque avant qu'ils n'atteignent vos clients. Ce qui compte pour le CRA, c'est que vous triiez et corrigiez, pas l'outil de scan choisi.
• Publiez un contact sécurité : un fichier security.txt et une adresse sécurité fonctionnelle donnent aux chercheurs un moyen de vous signaler un problème. Le guide de mise en place de security.txt fournit un modèle prêt à l'emploi.

Ces trois chantiers sont des gains d'automatisation rapides, pas l'ensemble du travail. La conception sécurisée, l'évaluation des risques, la livraison des mises à jour et les contrôles produit viennent s'y ajouter. Votre documentation technique grandit avec le produit plutôt que dans la précipitation avant le lancement : conservez donc vos notes d'architecture et de sécurité au fil de l'eau. Le contenu requis figure dans le guide de la documentation technique.

Votre processus de traitement des vulnérabilités doit être opérationnel avant l'entrée en vigueur des obligations de signalement, le 11 septembre 2026. À partir de cette date, une vulnérabilité activement exploitée ou un incident grave déclenche un calendrier serré via la plateforme unique de signalement de l'ENISA : une alerte précoce sous 24 heures, puis une notification complète sous 72 heures. Le rapport final diffère selon le cas. Pour une vulnérabilité activement exploitée, il est dû dans les 14 jours suivant la mise à disposition d'une mesure corrective ou d'atténuation. Pour un incident grave, il est dû dans le mois suivant la notification à 72 heures. Vous devez également informer les utilisateurs concernés. Le détail figure dans le guide du signalement des vulnérabilités.

Livrer vite sans repasser toute la conformité à chaque version

Itérer rapidement ne signifie pas relancer l'évaluation de la conformité à chaque sprint. Vous ne la revisitez qu'après une modification substantielle, c'est-à-dire un changement postérieur au lancement qui affecte la conformité du produit aux exigences essentielles, ou qui modifie la finalité prévue pour laquelle il a été évalué. Une mise à jour de sécurité qui se contente de réduire le risque de cybersécurité sans changer la finalité prévue n'est pas une modification substantielle, et un changement mineur comme l'ajout d'une langue à l'interface ne l'est en général pas non plus. Une mise à jour fonctionnelle qui élargit la surface d'attaque ou change ce que fait le produit peut, elle, en être une. Les correctifs de routine et les petites mises à jour partent donc sans réévaluation, et vous réévaluez quand un changement modifie réellement la nature du produit ou son profil de risque.

Si vous développez sur de l'open source ou en assurez l'intendance

Deux faits sur l'open source comptent pour une startup. D'abord, un logiciel libre et open source n'entre dans le périmètre du CRA que lorsqu'il est fourni dans le cadre d'une activité commerciale. Un logiciel que ses mainteneurs ne monétisent pas ne constitue en général pas une activité commerciale, mais la monétisation va au-delà de la simple vente du code : pesez aussi le support payant et les arrangements similaires. Contribuer du code source à un projet qui n'est pas sous votre responsabilité ne fait pas entrer le CRA en jeu pour vous. Monétiser de l'open source, ou l'intégrer dans un produit que vous vendez, fait entrer ce produit dans le périmètre normalement.

Ensuite, le CRA crée un rôle allégé, celui d'intendant de logiciels ouverts, pour une organisation qui, sans être fabricant, soutient le développement d'un logiciel open source destiné à un usage commercial. Les obligations d'un intendant reposent surtout sur une politique de cybersécurité documentée et la coopération avec les autorités. Le signalement des vulnérabilités s'applique dans la mesure où l'intendant participe au développement du produit, et le signalement des incidents graves ainsi que la notification aux utilisateurs s'appliquent lorsqu'un incident touche les systèmes que l'intendant fournit pour ce développement. Ces obligations sont plus légères que l'ensemble complet des obligations du fabricant. Si votre startup est à la fois intendante d'un projet et vendeuse d'un produit, distinguez clairement quelle casquette s'applique à quelle activité, car les obligations diffèrent.

L'obligation de support de cinq ans est un problème de modèle économique

C'est la partie du CRA qu'aucun outil ne permet de contourner. La période de support doit être d'au moins cinq ans, et lorsque le produit est censé être utilisé moins de cinq ans, elle correspond à cette durée d'utilisation prévue plus courte. Pendant cette période, vous traitez les vulnérabilités selon le risque, vous les corrigez sans délai, et vous livrez les mises à jour aux clients.

Pour une entreprise en phase précoce, c'est un vrai engagement, pas une case à cocher :

• L'obligation suit le produit : elle s'attache dès la première mise sur le marché de l'UE, et un pivot ultérieur ne l'éteint pas pour les unités déjà placées.
• Elle doit être intégrée au prix : si votre marge ne couvre pas la période de support, le prix est mal calibré. Intégrez le coût du support dans votre économie unitaire avant le lancement, et attendez-vous à ce qu'il diminue à mesure que la base de code se stabilise.
• Planifiez sur dix ans, pas cinq : chaque mise à jour de sécurité que vous publiez doit rester disponible pendant au moins 10 ans après sa sortie, ou jusqu'à la fin de la période de support si celle-ci est plus longue.
• Publiez la date de fin : vous devez indiquer la date de fin de la période de support, au moins le mois et l'année, au moment de l'achat. Fixez-la de façon délibérée, car clients et acheteurs la liront.

Vous pouvez rendre cet engagement plus tenable, mais faites attention à ce qui vous en décharge réellement, ou pas :

• Choisissez des dépendances stables : chaque bibliothèque qui évolue vite représente autant d'années de maintenance que vous vous engagez à assumer. Préférez des composants stables et bien maintenus, même s'ils sont moins excitants.
• Versionnez de façon délibérée : définissez des générations de produits et planifiez la transition du support entre elles, pour éviter de maintenir un nombre illimité de versions actives.
• Les mesures d'atténuation ne vous déchargent pas : un transfert écrit du support à un acquéreur, un arrangement d'entiercement (escrow), ou le passage en open source des composants critiques pour la sécurité peuvent maintenir les correctifs, mais aucun d'entre eux ne supprime, à lui seul, votre obligation.

Si vous cessez votre activité et ne pouvez plus vous conformer, vous devez en informer les autorités de surveillance du marché et, dans la mesure du possible, vos utilisateurs, avant que la cessation ne prenne effet. Ce qu'il advient de l'obligation résiduelle une fois l'entreprise disparue n'est pas clairement tranché et dépend de la juridiction. Planifiez dès maintenant, pendant que vous le pouvez encore, le scénario de cessation d'activité, et documentez-le dans le dossier technique.

Transformer la conformité en argument commercial et en financement

Pour une startup, le travail de conformité CRA sert deux objectifs à la fois : il ouvre l'accès au marché de l'UE, et il vous donne des preuves à remettre à un acheteur entreprise ou à un investisseur.

Constituez une seule fois votre dossier de due diligence. Les équipes achats de l'UE peuvent demander, lors de l'intégration d'un fournisseur, un SBOM à jour, une déclaration de conformité signée et un processus documenté de divulgation des vulnérabilités avec un délai de réponse. Ce sont des preuves solides, pas une démonstration de conformité totale, puisque la conformité réelle repose in fine sur le respect de chaque exigence essentielle. Mais les avoir rassemblées au même endroit vous évite de courir après les preuves plus tard, et c'est le même dossier que la due diligence technique d'un investisseur peut demander à voir.

Les investisseurs veulent savoir que vous pouvez livrer légalement. Le non-respect des exigences essentielles ou des obligations centrales du fabricant expose à des amendes administratives pouvant atteindre 15 millions d'euros ou 2,5 % du chiffre d'affaires annuel mondial total, le montant le plus élevé étant retenu. Plus concrètement, un produit placé sur le marché de l'UE à partir du 11 décembre 2027 doit respecter le CRA pour pouvoir y être vendu. Présenter la conformité comme un accès au marché et une entrée sur le marché de l'UE avec moins de risques passe mieux devant un conseil d'administration que la présenter comme un coût.

Des programmes publics peuvent financer une partie du travail. Des instruments européens comme Horizon Europe, le Programme pour une Europe numérique et l'EIC Accelerator soutiennent la cybersécurité et le développement de produits sécurisés, et les programmes nationaux s'y ajoutent. Les montants et les critères d'éligibilité varient, vérifiez donc auprès de votre pôle national d'innovation numérique ce qui est ouvert. Présentez votre dossier autour de la construction de produits numériques sûrs et dignes de confiance plutôt que comme une simple case réglementaire à cocher.

Si des certifications de sécurité reviennent en discussion commerciale, sachez où se situe le CRA par rapport à elles. Le chevauchement avec un SMSI est traité dans le guide CRA vs ISO 27001, et les équipes IoT grand public liront utilement le guide EN 303 645.

Erreurs fréquentes des startups

• « On s'occupera de la sécurité après la levée » : sur un runway compté, rattraper la sécurité après coup brûle le cash que vous venez de lever. Intégrez les bases dès le premier sprint.
• « On a fixé le prix sans compter l'obligation de support » : la maintenance de sécurité pluriannuelle doit être intégrée à votre économie unitaire. Si ce n'est pas le cas, le prix est mal calibré.
• « Notre responsable conformité est parti, et personne n'a repris » : quand une seule personne détient le dossier technique et le processus de signalement, son départ crée un trou dans la conformité. Formalisez par écrit qui porte ce rôle.
• « L'acquéreur reprendra l'obligation » : un accord peut transférer le travail de support, mais il ne vous décharge pas à lui seul de l'obligation légale. Traitez ce point explicitement dans les termes du contrat, et ne présumez de rien.
• « On ajoutera le CRA quand on s'étendra dans l'UE » : si des utilisateurs de l'UE peuvent déjà accéder à votre produit, vous fournissez déjà le marché de l'UE, et rattraper la conformité plus tard revient à tout reconstruire. Concevez dès le départ pour les obligations de 2027.
• « On est trop jeunes pour être concernés » : être une startup vous donne droit à des allègements, pas à une exemption. L'obligation s'attache dès la première mise sur le marché, quel que soit votre stade.