Sur mon calendrier, le 11 septembre 2026 est entouré et non, ce n'est pas l'anniversaire de mon chat : c'est la date où une partie du Cyber Resilience Act européen passe de « texte voté » à « obligation qui tombe ». Le code du site est dans un repo privé sur GitHub sous licence MIT, mais qu'en serait-il s'il était public ? Je pense que c'est la question que doivent se poser pas mal de devs.
La réponse courte tient en une phrase, et elle va rassurer la plupart d'entre nous. La réponse longue mérite dix minutes, parce que « ça dépend » cache trois statuts juridiques très différents. À la fin de ce billet, vous saurez lequel est le vôtre, et ce qui vous tombe dessus (ou pas) le 11 septembre.
Le 11 septembre 2026 n'allume pas tout le CRA
D'abord, tuons une panique. Cette date n'active pas l'intégralité du règlement. Le gros du CRA (les exigences de sécurité sur le produit, l'évaluation de conformité, le marquage CE) s'applique le 11 décembre 2027. Ce qui s'allume en septembre 2026, c'est un seul article : l'article 14, les obligations de signalement.
Concrètement, à partir de cette date, un fabricant qui découvre une vulnérabilité activement exploitée dans son produit, ou un incident grave qui touche sa sécurité, doit prévenir. Le tempo est serré :
- 24 heures pour une première alerte (early warning) ;
- 72 heures pour une notification étoffée ;
- 14 jours après la mise à disposition d'un correctif pour le rapport final sur la vulnérabilité (un mois pour un incident grave).
Le signalement part vers le CSIRT du pays d'établissement principal et vers l'ENISA, via une plateforme unique (la Single Reporting Platform), censée être opérationnelle pile pour la date.
Et oui, ça mord sur l'existant. La plupart des exigences du CRA ne visent que les produits « substantiellement modifiés » après décembre 2027. L'article 14, lui, s'applique aux produits déjà sur le marché. Un logiciel sorti en 2024 et toujours en service devra être signalé s'il se fait exploiter. Pas de clause grand-père pour se cacher derrière.
Le mot qui décide tout : « activité commerciale »
Maintenant, la vraie question : qui est ce fameux fabricant ? Le CRA ne demande pas qui a écrit le code. Il demande qui l'a mis sur le marché, et dans quelles conditions.
Le texte est net sur le point qui nous concerne : un logiciel open source qui n'est pas monétisé par ses auteurs n'entre pas dans l'activité commerciale. Publier n'est pas vendre, et le règlement sait faire la différence.
Là où ça se corse, c'est la définition de « monétisé ». Le législateur a anticipé les cas tordus. Ne comptent pas comme activité commerciale (liste tirée des considérants) :
- recevoir du soutien financier d'entreprises sans en tirer de profit ;
- avoir des entreprises qui contribuent au code ;
- faire des releases régulières ;
- être hébergé sur un dépôt ouvert ;
- accepter des dons sans intention de faire du profit ;
- être soutenu par une organisation à but non lucratif.
En revanche, ça bascule en commercial si vous acceptez des dons qui dépassent les coûts de conception et de maintenance, ou si vous facturez du support technique au-delà du remboursement de vos frais réels. Le curseur se pose sur l'intention de profit, pas ailleurs.
Trois profils sur le marché
Le plus simple, c'est de se représenter le CRA comme un marché avec trois profils : le fabricant qui tient un stand, le steward qui gère la halle, et le simple passant qui traverse sans rien vendre. Voici les trois cas de dev francophone les plus courants.
Cas 1, le package Composer gratuit. Vous publiez un bundle Symfony sur Packagist, licence MIT, zéro monétisation. Vous n'avez pas de stand : vous avez posé votre travail sur une table en accès libre. Vous n'êtes pas fabricant (pas d'activité commerciale), et vous n'êtes pas steward non plus (on verra pourquoi juste après). Vous êtes un simple passant. Le CRA ne vous demande rien.
Cas 2, le contributeur. Vous envoyez une PR à Symfony, à Doctrine, à FrankenPHP. Le guide OpenSSF pour les devs est explicite : le règlement ne s'applique pas aux contributeurs d'un projet open source tiers. S'il s'applique quelque part, c'est au projet qui reçoit, pas à vous qui poussez le commit. Contribuer ne vous met aucune obligation sur le dos.
Cas 3, le side-project monétisé. Vous transformez votre bidouille du week-end en produit : un SaaS payant, une app vendue, un plugin sous licence commerciale, bref un truc avec des éléments numériques que vous mettez sur le marché contre paiement. Là, vous avez un stand. Vous êtes fabricant, plein champ. Le signalement vous concerne dès septembre 2026, et le reste (sécurité dès la conception, SBOM, conformité) en décembre 2027.
Les trois cas tiennent dans un tableau, à garder sous le coude :
| Votre situation | Votre statut CRA | Ce qui vous tombe dessus | À partir de quand |
|---|---|---|---|
| Package ou app open source, non monétisé | Hors champ (simple passant) | Rien d'obligatoire | Sans objet |
| Contribution à un projet tiers (Symfony, Doctrine, FrankenPHP…) | Hors champ | Rien | Sans objet |
| Produit à éléments numériques mis sur le marché contre paiement | Fabricant | Signalement, puis sécurité dès la conception, SBOM, conformité CE | Signalement le 11 sept. 2026, le reste le 11 déc. 2027 |
| Personne morale qui soutient durablement un OSS destiné au commercial | Steward | Politique de cybersécurité documentée, gestion des vulnérabilités, coopération. Aucune amende | 11 déc. 2027 |
Le steward, ce faux épouvantail
Reste le mot qui a fait le plus peur dans la communauté : open-source software steward. Une catégorie inventée par le CRA, et souvent mal comprise.
Un steward, au sens du règlement, c'est une personne morale (pas physique), autre qu'un fabricant, dont l'objet est de soutenir de façon systématique et durable le développement de logiciels open source destinés à des activités commerciales, et qui assure la viabilité de ces produits.
Deux mots comptent. « Personne morale » : un individu n'est jamais steward. Vous, seul derrière votre clavier, ne pouvez pas l'être, quoi que vous publiiez. La catégorie vise des fondations, des consortiums, des structures qui portent des briques dont dépend la moitié de l'industrie.
L'exemple que tout dev PHP a en tête, c'est la PHP Foundation, qui finance le travail sur le langage lui-même et se décrit dans ses propres mots comme le steward de PHP. Détail savoureux : la PHP Foundation n'est pas, en tant que telle, une entité juridique. Elle fonctionne à travers l'Open Source Collective, qui lui sert d'hébergeur fiscal. Or le CRA réclame une « personne morale ». On tient là, en un seul exemple, le genre de nœud que le règlement va obliger tout l'écosystème à démêler.
Le steward a des obligations, mais allégées (article 24) : mettre en place et documenter une politique de cybersécurité vérifiable, gérer les vulnérabilités, coopérer avec les autorités. Et le point qui change tout : l'article 64(10) exclut les stewards des amendes administratives. Ils ont des devoirs, pas d'épée de Damoclès financière. L'idée du législateur : responsabiliser les structures qui tiennent l'écosystème à bout de bras, sans les étrangler.
Et Symfony, Doctrine, FrankenPHP ?
La question vraiment intéressante, celle qui n'a pas de réponse propre dans ce billet, c'est le sort des mainteneurs sur qui repose tout notre code. Et le meilleur exemple, c'est FrankenPHP, le serveur applicatif qui fait justement tourner ce blog.
Derrière FrankenPHP, il y a trois entités très différentes : un individu (Kévin Dunglas, son créateur), une entreprise (la coopérative française Les-Tilleuls, qui le sponsorise) et, depuis mai 2025, une fondation (la PHP Foundation, qui le soutient officiellement). Trois statuts CRA possiblement distincts pour une seule brique de votre stack. Je ne vais pas trancher ici lequel est fabricant, steward ou hors champ : ce n'est pas mon rôle, et ce billet n'est pas un avis juridique. Ça, ce sont leurs équipes légales qui le régleront, dossier par dossier.
Ce que je peux décrire, c'est le mécanisme. Le poids du CRA ne tombe pas sur le code open source lui-même. Il tombe sur celui qui met un produit fini sur le marché en l'intégrant. Et cet intégrateur, pour se mettre en règle, va se retourner vers ses dépendances : il va réclamer des SBOM, une politique de divulgation, des correctifs documentés. La pression ne descend pas du régulateur vers le mainteneur bénévole ; elle transite par les fabricants commerciaux, qui la répercutent en amont sur les projets qu'ils embarquent.
Même simple passant, la météo change
Donc, hors champ, rien à faire ? Pas tout à fait. Même si le CRA ne vous vise pas directement, il change le climat autour de vous.
Les fabricants qui embarquent votre package vont devenir plus exigeants. Attendez-vous à des demandes : un SBOM, un fichier security.txt, une politique de signalement de vulnérabilités, un contact clair pour les remontées. Rien d'obligatoire pour vous, mais un dépôt avec une politique de divulgation propre et un SBOM à jour devient un argument pour les fabricants qui l'intègrent. À fonctionnalité égale, c'est celui-là qu'ils choisiront.
Tenez, mon cas, celui de l'intro. Mon dépôt est privé aujourd'hui, sous licence MIT. Imaginons que je l'ouvre demain : est-ce que ça changerait quelque chose ? Non. Je l'ai fait passer dans l'arbre ci-dessus : une application non monétisée, pas un produit vendu. Ouvert ou fermé, je reste un simple passant, le CRA ne me demande rien. Et pourtant, j'ai depuis longtemps un SECURITY.md dans le dépôt : une adresse pour signaler, un accusé de réception sous 48 heures, des fenêtres de correction (critique sous 7 jours, haute sous 30). Je ne l'ai pas écrit pour Bruxelles, je l'ai écrit parce que c'est de l'hygiène. Le CRA ne fait souvent que rendre obligatoire en aval ce que beaucoup d'entre nous faisaient déjà par sérieux.
Le vrai pari du CRA
Au fond, le CRA ne transforme pas les hobbyistes en accusés. Ce serait un contresens de le lire ainsi. Ce qu'il acte, c'est une bascule : la sécurité n'est plus la responsabilité isolée d'un bout de code, elle devient une propriété de toute la chaîne d'approvisionnement. Le régulateur a choisi de tenir le maillon qui vend, en pariant que la pression remonterait d'elle-même jusqu'aux fondations et aux mainteneurs.
C'est un pari. Il suppose que les fabricants financeront vraiment la sécurité des dépendances qu'ils exploitent gratuitement, au lieu de se contenter de leur réclamer des SBOM par mail. On saura en décembre 2027 si le ruissellement coule dans ce sens-là.
En attendant, ouvert ou fermé, ce blog reste une application non monétisée, et je reste un simple passant. Et vous, en relisant vos dépôts Packagist et vos side-projects : passant, ou déjà un pied sur le marché ?
Une coquille, une erreur dans ce billet ? Signale-la-moi.