Réglementation, souveraineté, compétitivité : faire évoluer le Blue Guide européen pour y intégrer la question de l’Open Source

Quelques jours après les Rencontres Numériques de Strasbourg 2026, les réflexions de l’Atelier 10 « Using European regulation to boost economic competitiveness » continuent à faire leur chemin, notamment une proposition très concrète : utiliser le Blue Guide de la Commission européenne pour clarifier deux angles morts de notre droit du marché intérieur, à savoir la place de l’Open Source dans la notion de mise sur le marché, et l’intégration d’une logique de compétitivité dans une doctrine pensée autour de la seule concurrence.

Pour rappel, les Rencontres Numériques de Strasbourg se sont tenues du 15 au 17 avril 2026 au Parlement européen, pour leur troisième édition co-organisée par Numeum et le Cigref. Le thème retenu, « Mutations numériques : de l’ambition à l’action », a structuré deux jours de plénières et dix ateliers thématiques.

L’Atelier 10, co-présidé par Véronique Lacour (EDF) et Sophie Batas (Dassault Systèmes) et facilité par Vanessa Dewaele (Veolia) a été l’occasion de nombreux échanges. Au fil des débats, l’idée partagée d’une régulation capable de soutenir pleinement les démarches des acteurs privés concourant à une souveraineté Européenne. Les échanges ont fait apparaître la nécessité d’assurer une réelle convergence entre les actions menées par le secteur privé d’une part et par le législateur d’autre part. C’est durant le voyage retour que s’est installée l’idée d’ajuster le Blue Guide de la Commission afin de donner une orientation convergente aux travaux passés et à venir, à la fois concernant ces enjeux de souveraineté (au moins partiellement) et pour pleinement prendre en compte les spécificités de l’Open SOurce. Parce qu’il est à la fois un outil d’interprétation des textes existants et un instrument d’harmonisation pour ceux à venir, il offre le véhicule le plus pragmatique pour porter deux clarifications utiles, sans exclure, en parallèle, des véhicules législatifs plus structurants.

Le diagnostic de l’atelier : la régulation pour donner confiance et renforcer la compétitivité

Le diagnostic partagé par les participants tient en trois frictions :

1. les législations sont perçues comme détournées de leur intention initiale au fil du processus de co-législation, voire lors de leur transposition nationale (cf notre article sur l’articulation des textes européens) ;
2. un investissement compliance qui peine à se traduire en gain d’innovation (et qui crée potentiellement une disparité entre les PMEs non outillée à cette fin et les grands groupes pour qui cela entre dans le business as usual) ;
3. la fragmentation persistante des 27 régimes nationaux qui dilue l’effet d’un marché intérieur pourtant au cœur du projet européen.

Deux chantiers ont été identifiés comme prioritaires : Digital Trust (autour notamment de la révision du schéma EUCS) et Industrial Strategy & Competitiveness (autour du DMA, du Data Act et de la commande publique). Au-delà, un constat transversal a émergé : l’Europe joue pleinement son rôle de protection des consommateurs et des citoyens, mais elle peine à intégrer avec la même finesse les intérêts des acteurs économiques européens. Les deux logiques ne sont pourtant pas antagonistes. Elles se combinent dès lors qu’on accepte de penser la régulation comme un vecteur de compétitivité au même titre qu’un outil de protection. C’était tout notre travail des ateliers qui s’est traduit en deux lots de recommandations :

• un cadre unifié européen de souveraineté à plusieurs niveaux, horizontal, adossé à la révision du Cybersecurity Act et au futur Cloud and AI Development Act (CADA), proposition attendue au premier trimestre 2026), couvrant cloud, logiciel, IA et chaîne d’approvisionnement (semi-conducteurs compris). Les caractéristiques attendues : niveaux scalables, business-centricity, applicabilité TPE/PME, protection contre l’extraterritorialité, stabilité dans le temps, avec une préférence assumée pour un règlement (plutôt qu’une directive afin d’éviter la re-fragmentation en 27 transpositions).
• une stratégie industrielle européenne pour la souveraineté numérique. Elle s’appuie sur deux piliers : 1) une préférence européenne dans la commande publique, inscrite explicitement dans le CADA sur le modèle du Buy American Act et avec des critères de souveraineté opérationnels (localisation des données, juridiction applicable, titularité et licences de la propriété intellectuelle (et gouvernance de l’IP), protection contre l’extraterritorialité et les réglementations en matière d’export control) ; et 2) un fonds souverain numérique européen ouvert à l’épargne citoyenne.

Assortis d’un fast-track législatif pour les « sujets numériques critiques », ces sujets sont déjà dans le viseur de la Commission. L’enjeu n’est donc pas de les pousser dans l’agenda, mais de faire en sorte que la rencontre entre ces textes en gestation et les intérêts économiques européens se fasse le plus en amont possible et de la manière la plus harmonieuse possible. À noter, concernant le périmètre de la souveraineté, qu’un consensus a rapidement été atteint concernant l’extension des données à l’ensemble de la chaîne d’approvisionnement. La question est tout aussi importante pour le cloud que pour la circulation des produits souverains, et elle se pose avec une acuité croissante pour les objets connectés (IoT), l’embarqué industriel et plus largement les composants logiciels critiques de la supply chain.

Concernant ce second point, il semble nécessaire d’adapter la réglementation actuelle afin de reconnaître la spécificité de la diffusion numérique des logiciels, et en particulier la mécanique propre à l’Open Source. Les critiques portées avec le CNLL dans le Guide de conformité au CRA pour les communautés Open Source sont justement que la doctrine actuelle de la mise sur le marché a été pensée pour des produits tangibles circulant dans des canaux de distribution identifiables, et qu’elle décrit mal les modalité de diffusion des logiciels libres et Open Source (notamment la publication sur une forge avec une simple offre de contracter). Plutôt que d’ouvrir une doctrine commune, chaque texte sectoriel récent a bâti sa propre exception Open Source, avec ses définitions, ses seuils, et ses zones grises (voir notamment le billet sur l’articulation des règlements).

Intégrer et faire évoluer ces concepts dans la réglementation européenne

Plusieurs textes européens matérialisent les concepts utilisés par les régulations les plus récentes. Pour ce qui nous concerne, il s’agit notamment d’une Décision du 9 juillet 2008 (constituant le cadre de référence du New Legislative Framework, liant politiquement le Parlement, le Conseil et la Commission), les Règlements (CE) nº 765/2008 et (UE) 2019/1020 sur la surveillance du marché, et les différents textes sectoriels (CRA, RIA, PLD pour ne citer qu’eux). En surplomb, le Blue Guide 2022/C 247/01 est une communication interprétative de la Commission qui explique comment le NLF doit être appliqué et harmonise la lecture des textes sectoriels par les autorités nationales. Plus récemment, le Digital Omnibus visera à simplifier l’application des différents dispositifs et le très attendu Cloud and AI Development Act (CADA).

Plusieurs chantiers semblent pouvoir être mobilisés :

• le Digital Omnibus afin de poser une définition harmonisée de l’« activité commerciale » et du commercial Open Source commune au CRA, au RIA et à la PLD.
• le CADA afin d’intégrer les critères de souveraineté opérationnels qui traitent l’Open Source comme un vecteur naturel de résilience, notamment à l’extraterritorialité, et à porter dans le débat public la traduction concrète d’un Buy European soutenable juridiquement au regard de l’article 18 TFUE et des engagements AMP.
• la révision du Blue Guide pour y accueillir la doctrine transversale manquante : typologie des rôles Open Source, critères opérationnels d’activité commerciale, lecture du « produit européen » numérique, traitement des dépendances et de la supply chain.
• à plus long terme, la question d’une révision ciblée de la Décision 768/2008 pour y intégrer un volet numérique, ou d’un acte-cadre horizontal dédié à la mise sur le marché numérique, mérite d’être portée dans la doctrine, à titre de cible architecturale.
  

Clarifier la « mise sur le marché » pour l’Open Source

Les notions de placing on the market et de making available on the market sont codifiées dans la Décision nº 768/2008/CE du Parlement européen et du Conseil du 9 juillet 2008, qui constitue le cadre commun pour la commercialisation des produits, autrement dit le New Legislative Framework (NLF). Ce cadre est le socle de la quasi-totalité des réglementations sectorielles européennes sur les produits : marquage CE, conformité, surveillance du marché, responsabilité du fabricant. Le « Blue Guide » (communication 2022/C 247/01 du 29 juin 2022) en donne la lecture doctrinale officielle et le texte du Cyber Resilience Act (CRA) s’y réfère d’ailleurs explicitement.

Ce qu’il ne fait pas, en revanche, c’est reconnaître la spécificité de la diffusion numérique des logiciels, et en particulier la mécanique propre à l’Open Source. Les critiques portées avec le CNLL dans le Guide de conformité au CRA pour les communautés Open Source sont justement que la doctrine actuelle de la mise sur le marché a été pensée pour des produits tangibles circulant dans des canaux de distribution identifiables, et qu’elle décrit mal les modalité de diffusion des logiciels libres et Open Source (notamment la publication sur une forge avec une simple offre de contracter).

Plutôt que d’ouvrir une doctrine commune, chaque texte sectoriel récent a bâti sa propre exception Open Source, avec ses définitions, ses seuils, et ses zones grises (voir notamment le billet sur l’articulation des règlements). En conséquence, les trois définitions sont différences et laisse entendre un coût de compliance qualitatif très concret (a fortiori pour une société de taille réduite faisant massivement appel à l’Open Source dans ses produits).

En substance, la Décision 768/2008 définit la mise à disposition comme toute fourniture de produit destiné à être distribué, consommé ou utilisé sur le marché de l’Union dans le cadre d’une activité commerciale, à titre onéreux ou gratuit. Le critère déterminant est bien l’activité commerciale (ce qui est plus large que la gratuité), en revanche aucun exemple ne permet de projeter directement ce concept pour les communautés et les projets Open Source. Ce texte Soit la publication Open Source n’est pas en tant que telle une mise sur le marché, auquel cas les exceptions sectorielles récentes sont largement redondantes et leur complexité est sans objet. Soit elle l’est dès qu’elle s’insère dans une activité commerciale, auquel cas il faut choisir : appliquer la règle commune à tout l’Open Source commercial (ce que font, de fait, les règlements sectoriels, au prix de la fragmentation décrite plus haut), ou reconnaître à certaines formes d’Open Source commercial un statut particulier justifié par des motifs d’intérêt public et la soutenabilité de l’écosystème. On peut y réfléchir par analogie, mais c’est une piste à creuser, pas une analogie établie en droit positif : le régime des Services d’intérêt économique général (SIEG) issu de l’article 106(2) TFUE suppose une mission d’intérêt général confiée par une autorité publique, ce qu’il faudrait démontrer pour une filière Open Source. De la même manière, les statuts dérogatoires de l’économie sociale et solidaire sont adossés à des conditions de gouvernance et de lucrativité précises. L’exercice juridique reste donc à faire, mais la piste mérite d’être instruite sérieusement.

On perçoit, dans chacun des trois textes précités, une volonté de soutenir l’écosystème. La question que mérite de poser le législateur reste pourtant entière : l’Europe considère-t-elle, oui ou non, l’Open Source comme devant être activement protégé ? En l’absence de réponse claire, les régimes d’exception fragmentés ressemblent davantage à un nuage de fumée qu’à une doctrine. Si la réponse est oui, il faut en tirer les conséquences horizontalement, et non texte par texte.

Ce que le Blue Guide pourrait faire concrètement

Sans attendre le prochain train législatif, le Blue Guide peut accueillir une section transversale dédiée au logiciel libre et Open Source, organisée autour de trois blocs.

Des critères opérationnels d’activité commerciale d’abord, suffisamment fins pour rendre compte des modèles réels : seuils, formes d’engagement économique, relations contributeurs/mainteneurs, modèles open core, dual licensing, stewardship, sponsoring, services associés. Une typologie des rôles ensuite (développeur individuel, contributeur ponctuel, mainteneur, Open Source Software Steward au sens de l’article 24 du CRA, éditeur Open Source, intégrateur), alignée avec la terminologie des règlements sectoriels. Une définition commune du commercial open source enfin, qui puisse servir de référence transversale à tout le NLF, du CRA au RIA en passant par la PLD.

L’effet attendu est double : faire cesser la renégociation sectorielle de l’exception Open Source à chaque nouveau texte, et outiller la consultation European Open Digital Ecosystems ouverte par la Commission du 6 janvier au 3 février 2026 (plus de 1 600 contributions reçues). La doctrine industrielle européenne du numérique ouvert se construit maintenant. C’est maintenant qu’il faut la rendre cohérente.

Second prolongement : de la concurrence à la compétitivité

Le droit européen de la concurrence (articles 101 à 109 TFUE) structure un marché intérieur ouvert et compétitif, mais neutre quant à l’origine des acteurs. Ce principe, cohérent avec le projet de marché unique, est en décalage croissant avec les pratiques des autres grands blocs. Les États-Unis ont depuis 1933 bâti une panoplie d’instruments de préférence nationale, récemment complétée par le CHIPS and Science Act (2022) et les dispositifs de soutien de l’Inflation Reduction Act (2022). La Chine articule une politique industrielle assumée autour de Made in China 2025 et de ses dispositifs de substitution d’importations.

Le rapport Draghi remis à la Commission le 9 septembre 2024 a quantifié la dépendance numérique européenne : environ 80 % des produits et services numériques utilisés en Europe proviennent d’acteurs étrangers. Le rapport appelle à une politique industrielle coordonnée et à des formes de préférence européenne ciblée, en rupture avec la pure neutralité concurrentielle.

Des précédents partiels à mobiliser, aucun régime dédié à la filière numérique ouverte

Le droit européen connaît déjà plusieurs régimes dérogatoires partiels. Les Services d’intérêt économique général (SIEG) au titre de l’article 106(2) TFUE permettent, pour l’accomplissement de missions d’intérêt général, des dérogations aux règles de concurrence. Le régime des aides d’État (article 107(3) TFUE) autorise les projets importants d’intérêt européen commun (PIIEC). Le Règlement (UE) 2022/1031 du 23 juin 2022, dit International Procurement Instrument (IPI), ouvre une voie de préférence réciproque vis-à-vis des pays tiers fermés.

Aucun de ces régimes ne couvre spécifiquement la filière Open Source, pourtant identifiée comme levier stratégique par la Commission elle-même. La question est plus large : ces mécanismes peuvent-ils être mobilisés pour construire une préférence européenne au sens d’un marché favorable à des acteurs qui seraient, cumulativement, européens et porteurs de garanties suffisantes ? L’Open Source, parce qu’il offre par construction des garanties de portabilité et de réversibilité, peut en être l’un des vecteurs naturels. Il ne doit pas en être le seul : toute entreprise européenne qui dépend de composants logiciels tiers est concernée, qu’elle soit ou non elle-même un éditeur Open Source.

Protéger les acteurs européens contre l’extraterritorialité : EAR, OFAC et export controls

La question de l’extraterritorialité s’invite dès que l’on parle de souveraineté numérique. Les Export Administration Regulations (EAR) américaines et les sanctions gérées par l’Office of Foreign Assets Control (OFAC) s’appliquent à tout composant logiciel ou technologie dès lors qu’il contient de la US-origin technology, et ce où qu’il se trouve sur la planète. Un éditeur européen qui intègre une bibliothèque de cryptographie américaine, un intégrateur qui déploie un service cloud sur une infrastructure fournie par un acteur soumis à ces réglementations, une communauté Open Source qui héberge son dépôt sur une forge américaine : tous entrent dans le champ matériel de l’EAR, à des degrés divers. L’Union européenne et ses États membres ne reconnaissent pas formellement cette extraterritorialité, mais les effets pratiques restent bien réels.

Le précédent le plus parlant reste celui de GitHub en juillet 2019. À la suite d’une mise en conformité avec les sanctions OFAC, la plateforme a restreint l’accès aux comptes privés d’utilisateurs situés en Iran, en Syrie et en Crimée, y compris pour des développeurs européens en déplacement dans ces zones. Les dépôts publics Open Source n’étaient pas directement visés, mais les fonctionnalités collaboratives associées, issues, contributions, comptes privés, ont été suspendues. La situation a été régularisée ultérieurement par l’obtention d’une licence OFAC spécifique, mais l’épisode a laissé trace : la dépendance à une forge soumise à un droit extraterritorial est un risque de continuité d’activité, pas une hypothèse d’école. Des incidents comparables ont touché, à d’autres périodes, des utilisateurs de services cloud américains.

Cet angle nourrit la réflexion à double titre. D’abord, une doctrine opérationnelle du « produit européen » n’a de sens que si elle intègre, parmi ses critères, la résistance aux mesures unilatérales étrangères : la capacité pour un acteur européen de poursuivre son activité sans être contraint par un régime d’autorisation d’exportation ou de sanctions extérieur au droit de l’Union. Ensuite, l’Open Source joue là un rôle spécifique : en libérant les composants logiciels et en rendant leur code publiquement accessible, il permet, dans bien des cas, de reconstruire une chaîne d’approvisionnement alternative si l’accès à la brique initiale venait à être coupé. Le droit de forker et de redistribuer, adossé à l’ouverture du code, n’est pas qu’un argument éthique ou technique : c’est une assurance juridique contre l’extraterritorialité. Le cadre européen de la souveraineté numérique gagnerait à le reconnaître explicitement.

Le Blue Guide comme point d’appui doctrinal (et ses limites)

Le Blue Guide est une communication interprétative de la Commission. Sa révision ne requiert pas de procédure législative ordinaire et peut intervenir dans des délais bien plus courts qu’un règlement ou une directive. Il offre un espace pour accueillir une clarification de la notion de « produit européen » dans le contexte numérique, une articulation explicite entre les règles du marché intérieur et les objectifs de compétitivité, et un traitement des produits Open Source à ancrage européen, condition préalable à toute opérationnalisation d’un futur Buy European dans la commande publique.

Il faut y ajouter, explicitement, la question des dépendances et de la software supply chain. Être souverain sur un produit logiciel n’a de sens que si l’on maîtrise aussi ses dépendances transitives, et que si l’on conserve la capacité de les reprendre en main en cas de défaillance, de rachat inamical ou de rupture d’accès. C’est précisément ce que garantit, sous conditions, le fait que ces dépendances soient diffusées sous licence Open Source et que leur code soit publiquement accessible : la réversibilité devient non plus un engagement contractuel fragile, mais une propriété juridique et technique intrinsèque.

Un mot de prudence s’impose. Le Blue Guide 2022 a été conçu pour les législations d’harmonisation de l’Union sur les produits fondées sur le NLF ; il illustre ses notions à partir de directives comme les jouets, la basse tension, la compatibilité électromagnétique, les dispositifs médicaux ou la radio. Il ne cite pas formellement, dans sa version publiée en juin 2022, les textes adoptés postérieurement (CRA, RIA, PLD). Cela étant, la logique du Blue Guide irrigue bien le NLF dans son ensemble, et les textes sectoriels récents s’y réfèrent ou en adoptent les concepts : le CRA le fait explicitement à ses articles 3(21) et 3(22). L’évolution proposée ici consiste donc à prolonger cette irrigation en ajoutant les clarifications doctrinales manquantes, plutôt qu’à laisser chaque nouveau texte réinventer sa propre doctrine. C’est un choix politique autant que technique : il suppose que la Commission accepte de porter une lecture horizontale là où elle a, ces dernières années, raisonné texte par texte.

Objections prévisibles

Trois objections se présenteront et doivent être affrontées directement. La première est l’objection de discrimination : une préférence européenne serait contraire au principe de non-discrimination (article 18 TFUE) et aux engagements de l’Union au sein de l’Accord sur les marchés publics de l’OMC (AMP). La réponse technique existe : le Règlement IPI, précisément, a été adopté pour réintroduire une réciprocité à l’égard des pays tiers qui ne respectent pas les disciplines AMP, et la jurisprudence de la Cour sur les critères d’attribution laisse un espace réel à des critères de souveraineté objectivement justifiés (sécurité, résilience, protection des données). Le débat juridique n’est donc pas de savoir si c’est possible, mais sous quelles conditions précises.

La deuxième est l’objection du coût administratif. Ajouter des critères de souveraineté à la commande publique ou définir un statut pour le commercial Open Source, c’est alourdir le travail des acheteurs et des juristes. C’est vrai, mais il faut comparer ce coût à celui, actuel, de la fragmentation sectorielle : trois définitions de l’activité commerciale, trois périmètres d’exception, un SBOM par texte applicable. La question n’est pas d’éviter un coût, c’est de le déplacer vers un exercice plus lisible et plus réutilisable. La troisième est celle du risque de rupture transatlantique dans un contexte géopolitique sensible. La réponse est que la neutralité concurrentielle actuelle ne protège d’aucune rupture, comme le montrent les décisions unilatérales prises de l’autre côté de l’Atlantique depuis 2022, y compris sur des sujets touchant directement à l’accès aux technologies critiques. Mieux vaut construire une doctrine à froid qu’attendre d’y être contraint à chaud.

Un appel à contribuer à la doctrine européenne

Le moment est exceptionnellement propice. La consultation European Open Digital Ecosystems témoigne d’un appétit réel pour une doctrine industrielle européenne du numérique ouvert ; le rapport Draghi pose le cadre de pensée ; le CADA et la révision du Cybersecurity Act offrent des véhicules concrets ; l’ESTIA ouvre un espace de dialogue inter-industriel. Il serait dommage que, faute de doctrine partagée sur la mise sur le marché numérique et sur l’articulation concurrence/compétitivité, chaque texte continue d’inventer sa propre exception Open Source et sa propre définition du « produit européen ».