Articulation des réglementations en matière d'export control (FR/EU/USA/CH)

Ouvrir et contrôler : l’Open Source à l’épreuve de l’export control en 2026

L’Open Source et le contrôle à l’exportation (export control) n’ont jamais cessé de se croiser. En 2026, la question est cruciale : IA ouverte, chiffrement post-quantique, régime chinois codifié, remise en cause du régime américain sur les modèles d’IA.

Ce billet propose une lecture d’ensemble des trois grandes dynamiques US / UE / Chine (toutes basées sur l’Arrangement de Wassenaar), rappelle l’articulation historique avec les licences libres et en tire des enseignements opérationnels pour les utilisateurs, éditeurs et communautés Open Source.

Utilisés massivement dans le monde entier, les logiciels Open Source se retrouvent en première ligne chaque fois que le législateur s’attache à réguler le numérique : cybersécurité, intelligence artificielle, souveraineté, interopérabilité. À chaque fois, ils font figure de réponse privilégiée tant ils répondent intrinsèquement aux finalités recherchées : transparence et auditabilité, mutualisation des investissements et des coûts de conformité, libre concurrence et interopérabilité. À l’inverse, cette centralité expose l’Open Source à un ensemble de régimes qui n’ont pas été pensés pour les modalités distribuées de production logicielle. Cela génère une absence d’harmonisation dont nous avons récemment documenté les effets pour les trois règlements européens applicables à l’IA.

Le contrôle à l’exportation — dit export control, au premier rang duquel les régimes américains EAR et ITAR — est certainement le régime historiquement le plus en tension avec le mouvement de l’Open Source : il croise directement les enjeux de souveraineté des États et des ensembles régionaux en visant à empêcher la sortie de certaines technologies. Dans le contexte d’instabilité et d’élans protectionnistes que connaît la période récente, ces régimes ont significativement évolué pour plusieurs raisons concomitantes : reconfiguration du régime américain sur les modèles d’intelligence artificielle, entrée en vigueur échelonnée du Cyber Resilience Act européen, codification chinoise du dual-use en décembre 2024 (suivie en avril 2026 par deux décrets renforçant l’arsenal extraterritorial chinois). S’y ajoute une évolution de la pratique elle-même : la production de code assistée par IA générative (majoritairement réalisée sur des serveurs américains, sur la base de modèles américains ou chinois) devient la norme, et bouscule les catégories juridiques classiques du contrôle des exportations.

Justifiés par des motifs de sécurité, ces régimes sont particulièrement intrusifs et peuvent mêmes s’appliquer au-delà des frontières de leur pays d’origine. Ainsi, les systèmes américain et chinois sont dits extraterritoriaux : ils peuvent s’appliquer à des biens produits hors des États-Unis ou de la Chine dès lors que certaines conditions sont réunies (utilisation d’outils importés, intégration de composants, nationalité des contributeurs, etc.). La conformité ne consiste donc pas à satisfaire un régime national isolément, mais à articuler plusieurs régimes en fonction des situations et des pays concernés.

Ce billet vise à proposer, à destination des fabricants, éditeurs, mainteneurs et responsables confrontés à ces questions, une lecture d’ensemble. Il prolonge des travaux plus anciens (voir notamment l’analyse de 2015 sur l’export de logiciels libres de chiffrement dans le modèle américain) et complète des analyses récentes sur l’articulation entre règlements européens et exception Open Source. Il ne prétend pas à l’exhaustivité, mais invite, au contraire, à la discussion et à une amélioration collective ; à cet effet, les sources du schéma d’arbre de décision qui l’accompagne sont partagées sous CC BY-SA 4.0.

Open Source et export control : une coexistence conflictuelle

L’Open Source matérialise une logique de partage sans restriction (le copyleft n’étant qu’une modalité) qui procède d’une démarche individuelle et proactive : l’apposition d’une licence Open Source. Les logiques d’export control, à l’inverse, matérialisent la volonté d’un État de limiter la circulation de certaines technologies, vers certains pays ou certaines personnes, sans prendre en compte la volonté des parties prenantes (voire contre la volonté de celles-ci). L’opposition est frontale.

L’articulation des deux régimes est, en réalité, le fruit d’une bataille politique et judiciaire menée aux États-Unis à partir des années 1990 dont il semble intéressant d’en retracer quelques grands traits :

  • D’un point de vue politique, deux épisodes sont emblématiques. Philip Zimmermann, en 1995, a fait publier par MIT Press le code source de PGP sous forme d’un livre (à ce titre protégé par le Premier Amendement et donc non soumis aux restrictions d’export ITAR alors applicables au chiffrement fort). De même Adam Back a pris l’avion en ayant imprimé sur son t-shirt une implémentation de l’algorithme RSA avec la mention « WARNING: this shirt is classified as a munition and may not be exported from the United States, or shown to a foreign national ».
  • D’un point de vue judiciaire, les affaires Bernstein v. U.S. Department of Justice (1999) et Junger v. Daley (2000) ont conduit les juridictions fédérales américaines à reconnaître le code source cryptographique comme une forme d’expression protégée par le Premier Amendement, obligeant le Department of Commerce à instaurer dès 2000 une License Exception TSU pour le code de chiffrement publié. C’est cette doctrine, judiciaire avant d’être règlementaire, qui permet aujourd’hui à OpenSSL, GnuPG ou Let’s Encrypt d’exister et d’être diffusés sans autorisation préalable.

Deux épisodes plus récents ont rappelé les enjeux politico économiques sous-jacents :

  • En mai 2019, le Bureau of Industry and Security (BIS) a ajouté Huawei et soixante-huit affiliés non américains à l’Entity List, interdisant aux entreprises américaines de leur fournir toute technologie d’origine US sans licence. L’effet pratique immédiat fut le retrait par Google du support officiel des Android Mobile Services sur les nouveaux terminaux Huawei. Si cette décision ne concernait par la couche Open Source (aujourd’hui utilisée dans le système d’exploitation mobile de Huawei), l’arrêt du support de Google a clairement remis en cause la domination du fabricant.
  • En octobre 2024, onze développeurs russes ont été retirés du fichier MAINTAINERS du noyau Linux par un patch de Greg Kroah-Hartman, confirmé par Linus Torvalds et commenté ensuite par la Linux Foundation dans une note intitulée « Navigating Global Regulations and Open Source: US OFAC Sanctions ». Le droit des exportations vient ici limiter l’acceptabilité des commit individuels.

Les trois grandes dynamiques d’export control vis à vis de l’Open Source

L’étude des réglementations applicables aux trois grands blocs géographiques (États-Unis, Union européenne et Chine) permet, sans prétendre à l’exhaustivité, de comprendre comment ces régimes s’articulent en pratique.

États-Unis : une exception publicly available solide, mais une zone grise sur l’IA

Le régime américain des Export Administration Regulations (EAR) repose, pour les logiciels et technologies, sur une exception centrale : est exclue du champ d’application de l’EAR toute technologie ou logiciel « already in the public domain » ou « available in usable or operable form to the general public in any country ». L’exception License Exception TSU  spécifique au code cryptographique publié ajoute une obligation de notification au BIS (sans nécessiter un accord formel de ce dernier).

Dans le cadre des EAR, la notion de « public domain » ne renvoie pas au domaine public en droit d’auteur. Mais, elle désigne les technologies ou logiciels librement accessibles au public, sans restriction d’accès ni de diffusion, et disponibles sous une forme directement utilisable. En pratique, cela recouvre largement les logiciels diffusés en Open Source, à condition que le code soit effectivement publié de manière ouverte (par exemple sur un dépôt librement accessible), complet et exploitable, sans contrôle d’accès préalable. Cette exclusion ne s’applique toutefois qu’à la version réellement rendue publique : les branches privées, les dépôts à accès restreint ou les versions incomplètes demeurent soumis à l’EAR.

Couplée à la règle de de minimis (qui définit, en fonction du pays de destination, le seuil — de 0%, 10 % voire 25% — à partir duquel un produit étranger contenant du contenu américain déclenche l’application de la Loi américaine extraterritoriale) elle autorise la circulation mondiale d’OpenSSL, de la plupart des bibliothèques de chiffrement et, désormais, d’une part importante des modèles d’IA à poids ouverts.

Le second étage du régime est la Foreign Direct Product Rule (FDPR, § 734.9), qui étend la juridiction américaine aux produits fabriqués à l’étranger avec des technologies américaines. Notons ici que l’administration Biden a publié en janvier 2025 une règle dédiée à l’IA. Le Framework for Artificial Intelligence Diffusion étend les obligations EAR pour certains poids de modèles d’IA à closed-weight ainsi qu’une variante FDPR spécifiquement IA, qui exclue expressément les modèles à poids ouverts publiés, sur le modèle connu de l’exception Open Source. Néanmoins, ce dispositif a été « rescindé » (càd rendu non applicable) en mai 2025, ainsi le régime existe sur le papier, mais son application est en suspens et pourrait être réactivé par un simple policy statement. Sur le sujet de l’encadrement des modèles d’IA ouverts, voir notamment notre billet dédié.

Union européenne et France : une architecture stable mais à double étage

En Europe, le régime de contrôle des biens et technologies à double usage est défini par le Règlement (UE) 2021/821 du 20 mai 2021. La Note Générale Logiciels (Annexe 1, alinéa b), prévoit une exception pour les logiciels « dans le domaine public », entendue selon des critères proches de ceux américains : diffusion publique effective, absence de restriction d’usage, accessibilité à un large public sans frais particuliers. Conformément à l’ère du temps, les Annexes ont été mises à jour pour s’étendre aux semi-conducteurs avancés, certains items d’IA et la cryptanalyse post-quantique.

Le Règlement contient un article 4 dit «catch-all », qui permet le contrôle d’items non listés dès lors qu’une autorité nationale a connaissance d’un usage militaire final. Dans le même esprit, un article 5 a été introduit en 2021 pour s’étendre aux cyber-surveillance items susceptibles d’être utilisés à des fins de violation des droits humains. Leur activation est soumise à l’appréciation des autorités nationales.

Le droit français combine, à son niveau, deux régimes complémentaires :

  • Un premier qui est la mise en œuvre nationale du Règlement européen : la France peut ajouter des items à une liste nationale complémentaire sur le fondement de l’article 9 du Règlement (aujourd’hui uniquement utilisé pour les technologies quantiques) ;
  • Un second (fondé sur l’article 30 de la LCEN) qui précédait le Règlement et qui vient ajouter des contraintes spécifiques en matière de logiciels de chiffrement. Un même logiciel de chiffrement peut donc, simultanément, relever du régime dual-use européen et du régime français de la cryptologie (dès lors qu’il contient des fonctions de cryptologie), chaque régime comportant ses propres obligations déclaratives ou d’autorisation. Enfin, une qualification « grand public » (annexe II point 3) allège les formalités sous trois conditions cumulatives : diffusion par vente au détail sans limitation ; prix annoncé publiquement ; installation par l’utilisateur sans assistance substantielle du fournisseur. A priori incompatible avec les logiciels Open Source, ce régime dérogatoire est par ailleurs soumis à appréciation de l’ANSSI (à voir si la récente stratégie pro Open Source de l’ANSSI qui promeut notamment le open by default viendra inverser la tendance).

Chine : l’absence d’exception comme parti-pris

Le régime chinois est celui qui interroge le plus à ce jour : l’Export Control Law de 2020 (CECL) a posé un cadre général complété par les Regulations on Export Control of Dual-Use Items adoptées le 19 octobre 2024 et entrées en vigueur le 1er décembre 2024. Contrairement aux régimes américain et européen, aucun de ces deux textes ne mentionne de notion équivalente à « publicly available »« public domain » ou « open source » . Cette absence est d’autant plus inquiétante que :

  • La portée extraterritoriale de l’article 49 des Regulations de 2024 permet au ministère du Commerce (MOFCOM) de contrôler des items fabriqués hors de Chine, mais contenant des composants d’origine chinoise, ou produits avec des technologies d’origine chinoise. Le principe n’est pas chiffré — contrairement au régime américain –, mais semble faire l’objet de seuils définis par annonces sectorielles (comme le 50 % rule pour les terres rares).
  • Le Catalogue des technologies prohibées ou restreintes à l’export (actualisé en juillet 2025) inclut des domaines directement sensibles pour l’Open Source : IA et apprentissage automatique, cryptographie avancée et post-quantique, algorithmes de navigation de drones, logiciels de séquençage génétique.

Les annonces de 2024 et 2025 en matière de terres rares confirment une pratique d’application discrétionnaire difficile à anticiper. Pour un projet Open Source dont la communauté comprend des contributeurs relevant de juridictions tierces ainsi que pour tout réutilisateur de ces projets, c’est une réelle épée de Damoclès.

Deux récents décrets State Council, d’application immédiate et en réaction aux mesures extraterritoriales américaines et européennes, démontre que cet instrument de régulation devient central : Regulations on the Security of Industrial and Supply Chains (7 avril 2026) et Regulations on Countering Foreign Improper Extraterritorial Jurisdiction(13 avril 2026).

Un arbre de décision pour s’orienter

Le schéma qui accompagne ce billet reprend et généralise l’arbre de décision qu’inno³ a produit dans le cadre d’une étude client menée dans un contexte sectoriel spécifique. Il situe les différentes règles relatives à l’export de technologie française hors cadre européen en articulant les principales lois d’export control susceptibles d’être mobilisées. Pour mémoire, les régimes se cumulent :

Schéma Open Source & Export control rules

(Accédez au fichier source ou à une version HD via le repo git dédié. N’hésitez pas à contribuer directement en proposant une modification via le repo ou via inno3.fr)

Enseignements, recommandations et questions ouvertes

La maîtrise de la chaîne logicielle — disons know your supply chain, par analogie avec le know your customer du droit bancaire — n’est plus seulement une exigence de conformité aux licences libres ou un bon principe de cybersécurité ; elle est aussi, en 2026, une discipline de droit extraterritorial. Plusieurs enseignements se dégagent :

  • Le premier est documentaire : la Software Bill of Materials (SBOM), rendue obligatoire par le CRA, est l’instrument pivot d’une conformité export control maîtrisée. Il est ainsi possible de la considérer comme un asset à destinations multiples : cybersécurité, conformité licences, due diligence export. Voir en complément nos analyses sur le CRA et l’Open Source, en particulier le guide CRA co-rédigé avec le CNLL.
  • Le deuxième est en termes de gouvernance : les mécanismes de Contributor License Agreement (CLA) et de Developer Certificate of Origin (DCO) ont été conçus pour sécuriser la chaîne de titularité des droits d’auteur. Ils peuvent être enrichis d’une clause de déclaration d’origine et de résidence du contributeur, accompagnée d’un engagement à signaler tout statut personnel susceptible d’engager un régime extraterritorial (sanctions, export control). Cette approche, proche de ce que la Linux Foundation a commencé à formaliser dans ses compliance guidelines, trouve à s’exercer aussi bien dans les projets d’infrastructure que dans les initiatives IA. Une telle évolution ne doit pas alourdir disproportionnellement les projets communautaires : une mention déclarative simple, intégrée au DCO, suffit dans la plupart des cas et n’engage pas le mainteneur à procéder à une vérification active.
  • Le troisième est en termes de stratégie. Publier un composant cryptographique, un dataset ou des poids de modèle ne relève pas du même exercice selon qu’on vise une reconnaissance scientifique, une adoption communautaire ou une diffusion commerciale. Le choix de la licence, la documentation du contexte (modèles de menace, cas d’usage, limitations), l’architecture de la publication (dépôt principal, miroirs) influent directement sur la qualification « publicly available » au sens EAR et « dans le domaine public » au sens de la Note Générale Logiciels du Règlement européen. Les stratégies Open Source deviennent ainsi de plus en plus centrales dans les stratégies de développement des grandes organisations, voire dans les équilibres géopolitiques — l’ouverture devenant alors un levier d’internationalisation et de standardisation.
  • Le quatrième est prospectif. Plusieurs questions demeurent ouvertes et méritent d’être signalées telles quelles, notamment : l’avenir du dispositif américain sur les modèles d’IA, la question de l’intelligence artificielle générative utilisée comme outil de production de code (fait-elle tomber le code dans ces lois extraterritoriales) ou encore celle de l’application du régime chinois (voir aussi ce billet).