Avec le CRA la responsabilité devient un produit comme les autres 

Les communs excellent à répartir la valeur. Ils sont beaucoup moins à l'aise lorsqu'il s'agit de répartir les responsabilités. À trois mois de l’entrée en vigueur des premières obligations du Cyber Resilience Act, l’écosystème open source européen s’est confronté à cet angle mort lors de l’OW2con’26. Fondations, industriels, éditeurs et experts de la conformité y ont moins débattu des failles de sécurité que des responsabilités. Le changement de focale s’explique par la philosophie même du texte. Le règlement européen ne se contente pas d'ajouter une couche cyber aux logiciels commercialisés en Europe. Il impose de connaître le contenu exact d’un produit numérique via un Software Bill of Materials (SBOM), qu’il intègre des composants propriétaires, tiers ou open source. “Il faut savoir exactement quel est le périmètre, quels composants sont utilisés, qui les développe et sous quelles licences”, a expliqué Benjamin Jean, fondateur et directeur général (DG) du cabinet de conseil inno³. Pour beaucoup d'organisations, cette cartographie reste un plan griffonné, malgré des produits fondés sur des centaines, parfois des milliers de briques logicielles. Et l'open source en constitue souvent la part la plus difficile à inventorier, car ses composants s'accumulent silencieusement via des dépendances et des bibliothèques tierces. Le CRA pousse donc ses acteurs à remonter la chaîne jusqu'aux lieux où se prennent les décisions. Publication d'une version, arbitrage d'une vulnérabilité, conservation des preuves, choix d'une gouvernance. Tout devient traçable. “Le principal critère est le contrôle juridique et effectif de la gouvernance et des décisions de publication”, a poursuivi Benjamin Jean. La conformité devient alors une question de pouvoir autant que de cybersécurité. Le CRA ne demande plus seulement comment un logiciel est construit. Il oblige à identifier qui en détient réellement les clés. 

Une frontière mouvante 

Le cœur du débat tient dans deux catégories d’acteurs structurantes du règlement. D'un côté, le Manufacturer met un produit numérique sur le marché européen et assume les obligations les plus lourdes (production de l'inventaire, gestion des vulnérabilités, notification d'incidents, marquage CE, ...). De l'autre, l'Open Source Steward, soutient durablement un projet open source - via une fondation ou une organisation dédiée - sans nécessairement le commercialiser. Cette seconde catégorie a été introduite par le règlement pour reconnaître la spécificité du modèle open source et lui appliquer des obligations allégées. La frontière paraît nette dans le texte. Elle l'est beaucoup moins dans l'atelier des modèles économiques. Une entreprise peut publier son code sous licence ouverte tout en vendant du support. Une fondation peut piloter un projet stratégique et contrôler sa marque sans vendre directement le logiciel. Un éditeur peut ouvrir une partie de sa technologie pour accélérer son adoption commerciale. “On peut être à la fois Open Source Steward pour un projet et Manufacturer pour une version commerciale”, a précisé Olle E Johansson, leader du projet GVIP et contributeur à l'OpenSSF. Le CRA oblige ainsi à lire l'open source non plus seulement par ses licences, mais par ses centres de gravité. Qui décide ? Qui contrôle la marque ? Qui organise la mise à disposition ? “Le logiciel open source publié librement sur un dépôt n'est pas nécessairement un produit mis sur le marché”, a affirmé le fondateur et DG d'inno³. L'ouverture du code ne suffit ni à exonérer ni à qualifier. Ce sont les usages commerciaux, la distribution effective et la maîtrise de la gouvernance qui dessinent la responsabilité. Plusieurs zones grises appellent encore leur jurisprudence. En attendant, chaque acteur tente de savoir de quel côté de la ligne il se trouve. 

La conformité sort du dépôt Git 

La sécurité sort elle aussi de son territoire naturel. Le simple dépôt Git, cet espace où les communautés développent, stockent et publient leur code, ne suffit plus. Les échanges ont montré que de nombreux projets disposent déjà de mécanismes de revue, de correction et de gestion des vulnérabilités. Mais une pratique connue des mainteneurs ne vaut pas encore preuve devant un régulateur. Les travaux menés entre inno³ et The Document Foundation autour de LibreOffice ont cristallisé cette bascule. La fondation a choisi de se mesurer volontairement aux exigences applicables aux fabricants, non pour réécrire son code, mais pour éprouver sa capacité à documenter sa propre maturité. “LibreOffice voulait être aussi conforme qu'un Manufacturer”, a indiqué Benjamin Jean. L'enjeu n'était donc pas seulement de sécuriser davantage, mais de rendre la sécurité lisible, opposable et maintenable. Les ateliers ont porté sur les procédures, les dossiers techniques, les circuits de décision et l'implication des instances de gouvernance. L'écosystème open source s'est longtemps appuyé sur des routines communautaires efficaces mais peu formalisées. Le CRA change la valeur de ces routines. Ce qui n'est pas documenté risque de ne pas exister. “Le défi n'est pas d'atteindre la conformité mais de la maintenir”, a averti Olle E Johansson. La conformité n'est donc pas juste une photographie prise le jour d'un audit. Elle devient un film continu. “Dans le CRA, il faut s'en préoccuper tous les jours”, a-t-il insisté. La cybersécurité cesse d'être une simple affaire de correctifs. Elle s'impose désormais discipline de gouvernance. 

Les dépendances changent de prix 

La documentation n'est qu'une partie de l'équation. Le CRA remet de l'économie là où l'industrie voyait trop souvent de la gratuité. Lorsqu'un fabricant intègre une dépendance open source dans un produit commercialisé en Europe, il n'embarque pas seulement une fonctionnalité. Il embarque une dette de suivi, de documentation et de risque. Les SBOM, ces inventaires détaillés des composants logiciels utilisés dans un produit, deviennent alors plus qu'un fichier de conformité. Ils transforment la supply chain logicielle en objet de pilotage. “Le SBOM dont parle le CRA concerne le produit livré”, a précisé Olle E Johansson. Il ne s'agit pas seulement de lister ce qui se trouve dans un dépôt source, mais ce qui arrive effectivement chez l'utilisateur. Pour les industriels, cette exigence change la manière de regarder les dépendances. Un composant open source n'est plus seulement évalué pour sa qualité technique, sa licence ou sa popularité. Il porte désormais un coût de surveillance, de maintenance, d'audit et de dialogue avec l'amont. “Il faut parler aux fabricants dans leur langue, celle du coût par dépendance”, a-t-il poursuivi. Cette nouvelle comptabilité pourrait faire bouger le financement de l'open source. Si les fabricants deviennent responsables des briques qu'ils réutilisent, soutenir les projets critiques devient une mesure de réduction du risque. “Nous pouvons espérer que cela change le financement de l'open source”, a estimé Stéphane Fermigier co-président du Conseil National du Logiciel Libre (CNLL). Le CRA ne crée pas la dépendance aux communs logiciels. Il en affiche le prix. 

Le risque d’un nouveau péage logiciel 

Et cette promesse a son ombre portée. Dès qu'une responsabilité devient coûteuse, sa prise en charge peut faire l’objet d’une commercialisation. Plusieurs participants ont pointé l'émergence de sociétés prêtes à proposer aux industriels un guichet unique pour gérer leur chaîne d'approvisionnement logicielle. Pour un fabricant confronté à des milliers de dépendances, l'offre a tout d'un raccourci. Elle promet un interlocuteur, des documents, une couche de confiance. Mais elle peut aussi installer un nouveau péage entre le financement de la conformité et celui de la maintenance du code. “Je vois de plus en plus d'entreprises dire aux fabricants qu'elles prendront en charge toute leur supply chain”, a alerté Olle E Johansson. Le risque n'est pas l'intermédiation en elle-même. Il tient à la captation de valeur. Le CRA pourrait renforcer les acteurs en charge d’emballer le logiciel plutôt que ceux qui le produisent. “Il faut trouver une manière simple pour les fabricants de fournir des ressources en amont”, a plaidé Olle E Johansson. Le chantier reste donc ouvert. Financement mutualisé, contribution upstream, maintenance contractualisée ou courtage de confiance. Aucun modèle ne s'est encore imposé. Mais la question ne relève plus seulement de l'éthique. Le numérique moderne s’est bâti sur des fondations open source entretenues collectivement. Une partie du numérique moderne repose sur des fondations open source entretenues collectivement. Le CRA ne change pas l'architecture de l'édifice. Le réglement oblige à inscrire un nom sur le plan.