Illustration article Interoperable Europe Act : Carte des communications télégraphiques du régime européen (1898), dressée d’après le Bureau international des administrations télégraphiques

Interoperable Europe Act : le partage comme principe et l’Open Source comme moyen

Le 3 juin 2026, la Commission européenne a présenté son paquet « souveraineté technologique », qui comprend une stratégie pour des écosystèmes numériques ouverts, aussitôt qualifiée de stratégie Open Source de l’Union. Derrière cette actualité se trouve un socle juridique plus discret : le règlement (UE) 2024/903 pour une Europe interopérable (Interoperable Europe Act), applicable depuis juillet 2024. Premier texte contraignant à organiser le partage et la réutilisation de solutions entre administrations, code source compris, il traite l’Open Source non comme un objet à encadrer, mais comme un instrument de politique publique. Ce billet, qui prolonge notre série consacrée aux réglementations européennes (cf. ressources associées), analyse cette bascule et les perspectives associées.

Ce qu’il faut retenir

L’Interoperable Europe Act ne réglemente pas l’Open Source : il en fait un moyen de politique publique. Depuis le 12 janvier 2025, les administrations (au sens large, c’est-à-dire toutes les organisations publiques) doivent évaluer les effets de leurs nouvelles exigences sur l’interopérabilité transfrontière ; le partage des « solutions d’interopérabilité » (logiciels, spécifications, vocabulaires, licences) devient la règle par défaut, outillé par un portail, un comité européen dédié et des bacs à sable réglementaires. La stratégie Open Source de juin 2026 et le principe open source first du futur Cloud and AI Development Act (CADA) confirment la trajectoire : l’ouverture s’installe comme critère structurant de la commande publique européenne. Reste la condition d’effectivité souvent rappelée : sans gouvernance ni maintenance organisées, une solution partagée n’est pas encore un commun.

De la coordination volontaire au règlement

L’interopérabilité du secteur public européen n’est pas un chantier récent, c’est même l’un des chantiers européens au long cours. Depuis le milieu des années 1990, les programmes successifs IDA, IDABC, ISA puis ISA² (2016-2020) ont financé des briques communes. Révisé en 2017, le cadre européen d’interopérabilité (European Interoperability Framework, EIF) a posé un référentiel partagé en 47 recommandations dans un contexte de soft law (règles non contraignantes). Chaque administration restant libre de s’en saisir, les écarts entre États membres se sont creusés au fil des années (cf. l’exposé des motifs du règlement : « l’EIF actuel ne soutient pas suffisamment la mise en œuvre pratique de services publics numériques européens interopérables » et l’eGovernment Benchmark mesurait encore en 2023 moins de la moitié (49 %) de services accessibles en transfrontière).

Adopté sur le fondement de l’article 172 TFUE relatif aux réseaux transeuropéens, le règlement (UE) 2024/903 change la donne : entré en vigueur le 11 avril 2024 et applicable pour l’essentiel depuis le 12 juillet 2024, il s’impose aux entités de l’Union comme aux organismes publics des États membres dès lors que sont en jeu des services publics numériques transeuropéens (article 1er), c’est-à-dire tous les services numériques dont la fourniture suppose un échange entre administrations par-delà les frontières (ce qui couvre un nombre croissant de situations). Le considérant 6 apporte quelques exemples : reconnaissance mutuelle des diplômes universitaires ou qualifications professionnelles, échanges de données relatives aux véhicules, accès aux données de sécurité sociale et de santé (dont certificats liés à une pandémie), en lien avec les « services publics essentiels » de la décision (UE) 2022/2481 (décennie numérique).

Il y a donc trois conditions cumulatives :

  1. Un service numérique fourni par des administrations, entre elles ou à des personnes physiques/morales ;
  2. nécessitant une interaction par-delà les frontières ;
  3. via leurs réseaux et systèmes d’information.

Le règlement consacre surtout une notion large de solution d’interopérabilité, là où l’interopérabilité est souvent réduite à sa dimension technique (protocoles, API, formats de fichier). Cette solution d’interopérabilité désigne ainsi tout actif réutilisable, qu’il s’agisse d’un logiciel, d’une spécification technique, d’un vocabulaire sémantique, d’une architecture de référence, d’une ligne directrice ou d’une licence. C’est à cette échelle que le règlement organise le partage, et c’est ce qui le rend directement pertinent pour l’écosystème Open Source.

Quatre mécanismes, une même logique

Le règlement met en œuvre plusieurs logiques complémentaires :

1) Des évaluations d’interopérabilité obligatoires afin de favoriser la standardisation entre administrations (article 3)

Avant d’adopter des exigences nouvelles ou substantiellement modifiées concernant un service public numérique transeuropéen, l’administration concernée doit en évaluer les effets sur l’interopérabilité transfrontière et publier les résultats dans un format lisible par machine.

Le comité « Europe interopérable » a adopté dès décembre 2024 des lignes directrices pour cadrer l’exercice (dimensions juridique, organisationnelle, sémantique et technique) ;

2) Un droit au partage et à la réutilisation opposable entre administrations (article 4)

Toute entité de l’Union ou organisme public peut demander à une autre administration les solutions d’interopérabilité qu’elle a développées, y compris le code source et la documentation associée.

Les exceptions prévues par le texte (l’art. 4, § 1) sont au nombre de trois : a) les solutions soutenant des processus hors mission de service public de l’entité concernée ; b) les solutions sur lesquelles des tiers détiennent des droits de propriété intellectuelle limitant le partage à des fins de réutilisation (dans une logique proche de l’Open Data) et c) les solutions dont l‘accès est exclu ou limité en raison d’informations sensibles liées à la protection des infrastructures critiques ou des intérêts de la défense ou de la sécurité publique, y compris les infrastructures nationales critiques. Ces exceptions sont ainsi relativement proches du cadre prévu par la Loi Pour une République Numérique (LPRN) concernant l’Open Data appliqué aux logiciels développés par le secteur public en France (cf notre guide sur la LPRN).

À l’instar du recours entre administrations prévu par la LPRN, le règlement ne prévoit aucun régime de sanction : son effectivité reposera sur l’effet direct du texte devant le juge, le suivi du comité et la conditionnalité des financements européens.

À noter que le règlement permet à l’entité qui partage de poser des conditions (garanties de coopération, soutien, maintenance, exclusion de responsabilité en cas d’usage abusif) et d’exiger du réutilisateur une évaluation de sa capacité à gérer de manière autonome cybersécurité et évolution de la solution. Il est intéressant de noter par ailleurs que la licence EUPL est cité nommément en l’article 8 (qui prévoit que lorsque les portails, catalogues ou répertoires publics « recueillent des solutions à code source ouvert, ils permettent l’utilisation de la licence publique de l’Union européenne »). Le considérant 36 explicite l’intention : renforcer la clarté juridique et la reconnaissance mutuelle des licences entre États membres, sans exclure les autres licences Open Source. Créée par la Commission européenne en 2007 pour la diffusion des logiciels du secteur public puis révisée en 2017, l’EUPL fait foi dans toutes les langues officielles de l’Union et organise sa compatibilité avec les principales licences copyleft (GPL, AGPL, MPL, CeCILL, etc.).

L’article 4 dans son § 3 offre une voie de sortie élégante : publier la solution sur le portail (ou un catalogue connecté) vaut exécution de l’obligation, et dispense alors des conditions du § 2.

3) Une gouvernance dédiée afin d’opérationnaliser

Le comité « Europe interopérable » (Interoperable Europe Board), qui réunit Commission et États membres, pilote un agenda annuel ; chaque État membre désigne une autorité nationale compétente et un point de contact unique. La France a désigné assez naturellement la DINUM (qui pilote et met à jour le Référentiel général d’interopérabilité (RGI) en France) pour coordonner la politique d’interopérabilité des administrations.

Voir à ce sujet la liste officielle des autorités nationales compétentes du portail Europe interopérable, qui indique pour la France « Direction interministérielle du Numérique (DINUM) ».

4) Des espaces d’expérimentation et d’appui

Au-delà du portail Europe interopérable qui sert de point d’accès à ces solutions, des bacs à sable réglementaires d’interopérabilité sont prévus. De même il est possible de citer la coopération GovTech, une académie de formation et un suivi annuel via le rapport sur l’état de l’interopérabilité dans l’Union, dont la première édition a été publiée le 16 décembre 2025.

L’Open Source comme instrument de politique publique

Les précédentes analyses du CRA, du règlement IA ou de la nouvelle directive sur la responsabilité du fait des produits défectueux présentaient l’Open Source (écosystèmes et produits) comme un objet à sécuriser, à exempter partiellement ou à responsabiliser (cf. Open Source et IA : trois règlements européens, trois logiques, un même écosystème). L’Interoperable Europe Act procède différemment, il ne crée pas d’obligations pesant sur les projets ou les entreprises de l’écosystème Open Source, au contraire il fait de l’ouverture le mode de fonctionnement attendu des administrations (ce qui les rapprochera des pratiques et des écosystèmes ouverts). Le règlement impose de donner la priorité aux solutions n’emportant pas de restrictions de licence (l’Open Source en tête même si ce n’est pas la seule voie possible), et cela à fonctionnalités, coût et cybersécurité équivalents (condition dénoncée par la FSFE comme une échappatoire ayant « édulcoré » le texte en trilogue. Le partage par défaut, la publication du code, la documentation des solutions vont ainsi devenir la norme, rejoignant ce que les politiques Open Source volontaristes promeuvent depuis vingt ans, favorisant à terme l’émergence d’une infrastructure juridique commune.

Cette logique s’incarne notamment dans un outillage dédié : le catalogue de solutions Open Source de l’UE, dépôt géré par la Commission pour les solutions développées par et pour les institutions et administrations ; la forge code.europa.eu ; l’observatoire OSOR (qui suit depuis plus de quinze ans les politiques Open Source du secteur public) ; l’OSPO de la Commission et le réseau des OSPO publics européens.

Le premier agenda annuel adopté en application du règlement, l’Agenda 2026, assume cette orientation : labellisation de solutions « Interoperable Europe » (les deux premières, Core Vocabularies et DCAT-AP, en décembre 2025), cartographie des solutions sur l’architecture de référence EIRA, lignes directrices de partage et de réutilisation, promotion du catalogue Open Source et financement de projets multi-pays via le programme pour une Europe numérique.

Une trajectoire confirmée

S’il est parfois possible de douter de l’effectivité de ce type de norme potentiellement assez théorique, la tendance actuelle laisse penser que l’interopérabilité deviendra enfin effective et que l’Open Source en sortira grandi. Le paquet souveraineté technologique présenté le 3 juin 2026 prolonge cette dynamique au-delà du seul secteur public. Autour d’une communication chapeau, il réunit le Chips Act 2.0, le Cloud and AI Development Act (CADA), une feuille de route pour le numérique dans l’énergie et la stratégie pour des écosystèmes numériques ouverts, à l’élaboration de laquelle nous avions contribué lors des consultations préparatoires.

Plusieurs facteurs donnent confiance :

  • La stratégie en trois piliers qui pense en termes de transformation d’écosystème numérique européen : des actifs de confiance (dépôts de code partagés, schémas de licence, services réutilisables), des communautés outillées (formation et reconnaissance aux personnes qui contribuent à l’Open Source, simplification des règles de contribution) et une gouvernance forte (ouverture et souveraineté intégrées dès la conception des investissements numériques).
  • Le basculement de la commande publique : appui aux acheteurs (rédaction des marchés, critères d’évaluation, maintenance de long terme), principe « open source first » (ou au moins accompagnés) pour les achats de cloud et d’IA des administrations porté par le CADA, dans la continuité du marché « Sovereign Cloud » d’avril 2026 qui faisait pour la première fois de la souveraineté le critère principal d’attribution.
  • Enfin la sécurisation de la chaîne d’approvisionnement logicielle : la Commission annonce des référentiels communs pour ses dépôts de code couvrant veille des vulnérabilités, conformité des licences et détection des risques de dépendance, autant de sujets au cœur de nos accompagnements en transparence de la chaîne logicielle.

Cette trajectoire européenne entre en résonance avec le débat français : le rapport de la commission d’enquête de l’Assemblée nationale sur les dépendances numériques précédemment analysé propose notamment une obligation d’Open Source dans la commande publique à l’horizon 2030. Les deux mouvements se répondent : l’Interoperable Europe Act et la stratégie de juin fournissent la base réglementaire nécessaire sur laquelle des politiques nationales volontaristes peuvent désormais s’appuyer.

Pour conclure

L’IEA ouvre la voie à un changement de pratiques au sein des administrations, les amenant indirectement de plus en plus vers l’Open Source et les communs numériques. Trois chantiers concrets se dégagent :

  • Évaluer et documenter : intégrer l’évaluation d’interopérabilité en amont des projets (dans une dynamique de « interoperable by design ») ;
  • Partager en organisant la suite : choisir des licences adaptées (EUPL et compatibilités), soigner documentation et métadonnées, et surtout prévoir la gouvernance et la maintenance de ce qui est publié. Publier un code ne suffit pas à créer un commun : nous renvoyons aux analyses d’« Ouvrir pour durer » sur les conditions qui font d’une brique logicielle une infrastructure durable ;
  • Saisir les opportunités : catalogue et labels européens pour donner de la visibilité aux solutions publiques françaises, bacs à sable pour expérimenter dans un cadre sécurisé, financements du programme pour une Europe numérique pour mutualiser entre États membres.

Pour les entreprises du logiciel et les prestataires du secteur public, le signal est tout aussi fort : les critères d’achat évoluent vers l’ouverture, la portabilité, la réversibilité et le coût complet. Les acteurs capables de démontrer la conformité de leur chaîne logicielle et la durabilité de leur modèle de maintenance partiront avec une longueur d’avance.

Ce droit au partage ne jouant qu’entre administrations, une entreprise ou un particulier ne pourra pas exiger la communication d’une solution sur le fondement de l’article 4. Néanmoins,le § 4 du même article vise expressément les tiers, qui peuvent adapter toute solution rendue publique, l’adaptation devant alors être republiée de la même manière, dans une logique de share alike. Pour l’accès au code source public, d’autres régimes s’appliquent telle que la Loi pour une République numérique (articles L300-2 et L312-1-3 du CRPA) en France et plus largement la directive Open Data (UE) 2019/1024 qui prévoit l’accès ainsi que la réutilisation (seul le cadre français s’étend néanmoins au logiciel). L’IEA organise le partage entre administrations ; l’Open Data organise l’accès de toutes et tous.

Après une décennie de textes qui apprenaient à l’Europe à se protéger, l’Interoperable Europe Act et la stratégie qui le prolonge dessinent l’étape suivante : apprendre à partager. Nous suivrons par la suite la mise en œuvre du règlement, son agenda annuel et sa déclinaison française.

Image mise en avant : « Carte des communications télégraphiques du régime européen », C. Van Hoven d’après le Bureau international des administrations télégraphiques, 1898. Source : Wikimedia Commons / Digital Commonwealth, domaine public