Open source AI Act France : ce que le règlement européen prévoit réellement

Le Règlement (UE) 2024/1689, dit AI Act, encadre notamment les modèles d'IA à usage général (GPAI, pour General-Purpose AI), capables d'accomplir un large éventail de tâches et d'être intégrés dans différents systèmes. Depuis le 2 août 2025, leurs fournisseurs relèvent d'un cadre fondé sur la documentation, la transparence, le droit d'auteur et la coopération avec les autorités, renforcé en cas de risque systémique. Pour le détail, voyez ce panorama destiné aux PME françaises.

L'open source n'y constitue pas une exemption générale. Le considérant 102 reconnaît sa contribution à la recherche et à l'innovation, puis pose deux séries de critères :

  • La licence doit permettre d'accéder au modèle, de l'utiliser, de le modifier et de le redistribuer, y compris ses versions modifiées. Créditer l'auteur ou maintenir des conditions de distribution comparables reste admis.
  • La publication doit rendre publics les paramètres, dont les poids, ainsi que les informations sur l'architecture et sur l'usage du modèle, afin d'assurer un niveau élevé de transparence et d'ouverture.

Ce que couvre réellement l'allègement

L'article 53, paragraphe 2, dispense ces modèles de certaines obligations documentaires, mais pas de la politique relative au droit d'auteur ni du résumé des contenus d'entraînement. La dérogation ne s'applique pas aux modèles à risque systémique. Les lignes directrices de la Commission européenne précisent les notions de fournisseur et de mise sur le marché, ainsi que les conditions applicables aux licences libres.

Six objets doivent rester distincts : le modèle, ses poids, son code, ses données d'entraînement, sa documentation et le système final. Le considérant 102 ne cite pas la publication des données d'entraînement parmi ses trois éléments. Un modèle aux poids publics n'est donc pas nécessairement ouvert sur toute sa chaîne. Mon fil directeur est simple : l'ouverture peut réduire certaines obligations, sans supprimer les exigences de transparence restantes ni les responsabilités du déploiement.

Positions des ministères français : une ligne officielle encore indirecte

La source française centrale est la réponse publiée le 28 mai 2026 par le ministère délégué chargé de l'intelligence artificielle et du numérique, après une question de la sénatrice Cathy Apourceau-Poly. Il faut bien distinguer les deux textes. La question réclame des « codes et poids transparents » et un recours exclusif à des centres SecNumCloud. La réponse ne reprend pas ces demandes comme règle générale.

Le Gouvernement y réaffirme la stratégie nationale cloud de 2021, le développement d'une offre de confiance et la qualification SecNumCloud délivrée par l'ANSSI (Agence nationale de la sécurité des systèmes d'information). Il rappelle aussi la loi SREN du 21 mai 2024, qui impose à l'État, à ses opérateurs et à certains groupements d'intérêt public de protéger leurs données les plus sensibles hébergées sur un cloud commercial contre les législations extraterritoriales.

Sur l'auditabilité, la réponse renvoie au droit européen : exigences de transparence, de documentation et de sécurité, contrôle par le Bureau européen de l'IA, demandes d'informations et évaluations. Elle mentionne un acte d'exécution, alors en consultation publique, selon lequel les enquêteurs pourront solliciter un accès au code. Son statut actuel doit être vérifié.

Ce que la source ne permet pas d'affirmer

Cette réponse ne fixe aucune obligation générale de publier le code ou les poids. Elle ne consacre pas de préférence réglementaire pour l'open source et ne décrit pas de position coordonnée entre ministères. Le dossier ne documente aucune position autonome de la Culture ou de la Défense sur ce sujet ; l'ANSSI y apparaît comme autorité de qualification.

Je propose donc une lecture en trois niveaux :

Niveau État de la source
Droit européen Cadre GPAI, licence libre et contrôle par la Commission
Ligne française Données sensibles, cloud de confiance et lois extraterritoriales
Zone d'incertitude Politique nationale propre de soutien ou de contrainte envers l'open source

Open source, souveraineté et données : pourquoi la France relie les deux sujets

Le lien vient d'abord de l'exposition juridique. La réponse gouvernementale présente SecNumCloud comme une protection contre les accès non autorisés d'autorités d'États tiers disposant d'une loi extraterritoriale, avec le Cloud Act américain en exemple. Le modèle ouvert entre dans cette réflexion parce qu'il peut être audité, déplacé et hébergé sans dépendre d'une seule API, l'interface d'accès proposée par un fournisseur.

Selon le Gouvernement, la qualification repose sur des critères élevés de cybersécurité, un siège et un hébergement des données dans l'Union européenne, ainsi qu'une clause de réversibilité. Le capital détenu hors UE est plafonné à 24 % pour un actionnaire unique et à 39 % collectivement en cas de pluralité. La commande publique illustre cette ligne : l'UGAP a acheté 84 M€ de prestations cloud en 2025, dont 69 % vers des opérateurs européens et 22 M€ d'offres SecNumCloud.

L'ouverture ne suffit pas

Le rapport du Sénat « ChatGPT, et après ? » décrit une chaîne de valeur étendue des matières premières aux consommateurs. Le modèle n'en est qu'un maillon : bibliothèques, données d'entraînement, API, accélérateurs matériels, calcul, journaux et mises à jour comptent également. Des poids publics peuvent tourner sur une infrastructure étrangère. À l'inverse, un modèle hébergé dans un environnement de confiance peut rester peu auditable si ses poids ou sa documentation sont inaccessibles.

Pour éviter cette confusion, je recommande une grille en cinq questions :

  • Ouverture du modèle : quels poids, informations d'architecture, documents d'usage et conditions de licence sont réellement accessibles pour la version précise que l'organisation prévoit d'exploiter ?
  • Contrôle juridique : à quel droit l'hébergeur et ses sous-traitants sont-ils soumis, et quelles garanties contractuelles couvrent les demandes d'accès émanant d'autorités étrangères ?
  • Localisation : où se trouvent les documents, les prompts, les sorties, les journaux et les sauvegardes, y compris pendant la maintenance ou le support ?
  • Maîtrise opérationnelle : qui administre l'environnement, applique les correctifs, surveille les usages et peut interrompre le service sans dépendre d'un tiers ?
  • Auditabilité : l'organisation peut-elle prouver quelle version tournait à une date donnée, avec quels paramètres, quels tests et quelles modifications ?

Modèles open source et modèles à risque systémique : une exemption à manier avec prudence

La Commission distingue les modèles GPAI soumis au cadre général et ceux pouvant présenter un risque systémique, notamment pour les droits fondamentaux, la sécurité ou le contrôle du modèle. Pour ces derniers, le fournisseur doit évaluer et atténuer les risques. L'article 55 ajoute des exigences concernant les évaluations, le suivi des incidents graves et la cybersécurité.

Lire les seuils sans les transformer en test universel

Selon le communiqué de la Commission, ses lignes directrices retiennent le dépassement de 10^23 opérations en virgule flottante, associé à certaines capacités de génération, pour identifier un modèle GPAI. L'article 51 présume par ailleurs le risque systémique au-delà de 10^25 opérations pour l'entraînement. Ces seuils ne remplacent pas une analyse juridique : la qualification dépend aussi des capacités, de l'impact et d'une éventuelle décision de la Commission.

Le vrai sujet : la fragmentation des rôles

Un projet ouvert se déroule rarement sous une seule responsabilité. Un développeur publie les poids, une communauté les modifie, un intégrateur les affine avec des données spécifiques, puis une entreprise les déploie dans un système métier. Chacun peut occuper une position différente au regard de l'AI Act. Je recommande donc d'exiger des réponses écrites à ces questions :

  • Identité et mise sur le marché : qui est le fournisseur du modèle, qui le met sur le marché, et sous quel nom ou quelle marque cette version est-elle distribuée ?
  • Licence et publication : quelle licence s'applique, quelles restrictions contient-elle, et quels éléments sont réellement publics plutôt que simplement annoncés dans une fiche descriptive ?
  • Version et risques : quelle version est documentée, quelles modifications ont été apportées, et qui assume les évaluations de risques avant et après l'intégration ?

Le Code de bonnes pratiques pour les modèles GPAI peut structurer la démarche d'un fournisseur, et les lignes directrices en expliquent les implications. Il ne confère toutefois aucune immunité automatique et ne remplace pas l'analyse du système déployé. L'open source peut favoriser la transparence, mais sa réutilisation rend une gouvernance claire encore plus nécessaire lorsque le modèle alimente un système à fort impact.

Cas pratique : auditer un modèle ouvert avant un déploiement français

Prenons un cas fictif : une PME industrielle de 80 salariés veut exploiter un modèle de langage ouvert pour interroger ses documents internes. Voici la méthode que je propose :

  1. Qualifier le modèle : vérifier s'il s'agit d'un modèle à usage général, identifier l'auteur de la mise à disposition et conserver une empreinte de chaque version téléchargée.
  2. Analyser la licence : contrôler les poids, l'architecture, la documentation, les restrictions d'usage, les obligations d'attribution et les conditions de redistribution, y compris pour les versions modifiées.
  3. Cartographier les flux : recenser données personnelles, secrets d'affaires, prompts, sorties, journaux et jeux de fine-tuning, c'est-à-dire d'affinage, puis préciser leur base légale et leur durée de conservation.
  4. Examiner l'infrastructure : comparer hébergement local, cloud européen et offre SecNumCloud, en rappelant que cette qualification concerne le service cloud et ne certifie jamais le modèle lui-même.
  5. Organiser l'auditabilité : tenir un registre des versions et des changements, tester sécurité, biais et performances, puis prévoir procédure d'incident, mécanisme de retrait et plan de réversibilité.
  6. Attribuer les responsabilités : répartir par contrat les obligations de l'éditeur, de l'hébergeur, de l'intégrateur et de l'exploitant, avec un responsable nommé pour chaque décision de mise en production.
Scénario Bénéfices Risques
Exécution locale sur données sensibles Maîtrise des flux, portabilité Sécurité, correctifs et compétences à assumer
Affinage par un prestataire Meilleure adaptation au métier Rôle modifié, données exposées, traçabilité
Appel via une API commerciale Mise en œuvre rapide Dépendance, droit applicable, version moins contrôlable

Aucun de ces scénarios n'est conforme par nature. Le résultat dépend du système complet, de la documentation disponible et des choix d'exploitation. Si l'usage touche à un métier réglementé, le hub IA par métier aide à replacer ces contrôles dans leur contexte professionnel.

Quelle stratégie pour les organisations françaises : conformité, souveraineté et retour sur investissement

Trois architectures méritent d'être comparées avant toute décision :

Option Données et audit Coûts et maintenance Vitesse et réversibilité
Modèle fermé via API Contrôle limité par le contrat Usage facturé, exploitation réduite Rapide, dépendance plus forte
Modèle ouvert maîtrisé Contrôle et audit renforcés Calcul, sécurité et supervision internes Plus long, portabilité accrue
Combinaison selon la sensibilité Contrôle adapté à chaque usage Gouvernance et routage à financer Progressif, sortie à organiser

L'open source peut réduire les coûts de licence et améliorer la portabilité. Il transfère toutefois une partie de la dépense vers le calcul, l'intégration, la sécurisation, le monitoring, la gestion des versions et les compétences. Le calculateur de ROI IA doit donc servir à raisonner sur le cycle de vie, pas sur le seul prix d'accès.

Ma grille de décision croise huit critères : sensibilité des données, criticité de l'usage, besoin d'audit, volume de requêtes, latence, localisation, maturité technique et coût de réversibilité. Elle rejoint la ligne française documentée : protection des données sensibles, cloud de confiance, offre européenne compétitive, commande publique et coopération européenne. La France semble promouvoir un écosystème de confiance et l'auditabilité plutôt qu'une obligation générale d'utiliser des modèles ouverts. Cette lecture reste provisoire, car les actes européens et les pratiques du Bureau de l'IA demeurent déterminants.

Plan d'action proposé en 90 jours

  • Jours 1 à 30 : inventorier les modèles utilisés, qualifier les rôles juridiques, cartographier les données et identifier les usages qui exigent un examen prioritaire par la direction, le DPO et le RSSI.
  • Jours 31 à 60 : tester l'infrastructure envisagée, analyser les licences, mesurer les performances réelles et évaluer les risques sur un périmètre limité, avec des données adaptées au niveau de sensibilité.
  • Jours 61 à 90 : consolider la documentation, chiffrer le cycle de vie et présenter à un comité de validation une décision écrite, incluant conditions de retrait et plan de réversibilité.

L'objectif reste de choisir une architecture d'IA souveraine et conforme, sans confondre ouverture technique, sécurité juridique et souveraineté opérationnelle.

FAQ — open source, AI Act et position française

L'AI Act exempte-t-il automatiquement les modèles d'IA open source ?

Non. L'AI Act prévoit une dérogation ciblée, pas une exemption générale. Un modèle publié sous licence libre, avec poids, architecture et informations d'usage accessibles, peut être dispensé de certaines obligations documentaires de l'article 53. La politique de droit d'auteur et le résumé des contenus d'entraînement demeurent, et la dérogation disparaît si le modèle présente un risque systémique.

Quels éléments doivent être publiés pour qu'un modèle soit considéré comme libre et ouvert ?

Le considérant 102 de l'AI Act vise trois éléments publics : les paramètres, dont les poids, les informations sur l'architecture et les informations sur l'usage du modèle. La licence doit aussi permettre d'accéder au modèle, de l'utiliser, de le modifier et de le redistribuer. Créditer l'auteur ou maintenir des conditions de distribution comparables reste admis.

Quelle est la position officielle du Gouvernement français sur l'open source dans l'AI Act ?

Aucune doctrine dédiée n'apparaît dans les sources examinées. La réponse ministérielle publiée le 28 mai 2026 au Sénat défend le cloud de confiance, SecNumCloud et la protection contre les lois extraterritoriales, puis traite l'auditabilité par le contrôle européen des fournisseurs. Elle n'impose pas les modèles open source et ne fixe aucune préférence réglementaire en leur faveur.

SecNumCloud certifie-t-il un modèle d'intelligence artificielle ?

Non. SecNumCloud, qualification délivrée par l'ANSSI, porte sur un service cloud : cybersécurité, localisation du siège et des données dans l'Union, limites de capital non européen et clause de réversibilité. Elle renseigne sur l'environnement d'exécution, pas sur les biais, la performance, la licence ou la conformité d'un modèle hébergé dans ce service, qui s'évaluent séparément.

Un modèle open source peut-il être soumis aux obligations applicables aux risques systémiques ?

Oui. La publication sous licence libre ne retire pas un modèle de la catégorie du risque systémique. L'article 51 présume ce risque au-delà de 10^25 opérations en virgule flottante d'entraînement, et la Commission peut aussi désigner un modèle selon ses capacités ou son impact. Le fournisseur doit alors évaluer et atténuer ces risques.

Qui est responsable lorsqu'un modèle ouvert est modifié puis intégré dans une application ?

La réponse dépend du rôle réel de chaque acteur. Le développeur initial, celui qui modifie le modèle, l'intégrateur et l'exploitant peuvent relever de qualifications différentes. Il faut identifier qui met le modèle ou le système sur le marché, sous quel nom, avec quelle version documentée, puis répartir contractuellement tests, incidents, mises à jour et retrait.

Un modèle open source garantit-il que les données françaises restent souveraines ?

Non. Des poids téléchargeables peuvent tourner sur une infrastructure étrangère ou insuffisamment sécurisée. La souveraineté dépend aussi du droit applicable à l'hébergeur, de la localisation des données, des journaux, des prompts, des mises à jour et de la maîtrise opérationnelle. L'ouverture facilite l'hébergement local et la portabilité, mais elle ne protège pas seule les données françaises.

Comment choisir entre un modèle fermé et un modèle ouvert pour un cas d'usage sensible ?

Je propose de comparer sensibilité des données, criticité de l'usage, besoin d'audit, volume de requêtes, latence, localisation, maturité technique et coût de réversibilité. Un modèle fermé peut convenir à un usage peu sensible. Un modèle ouvert sur infrastructure maîtrisée se justifie davantage pour des données sensibles, à condition d'en assumer l'exploitation et la documentation.

Pour aller plus loin avec IAPRO

Vous hésitez entre API fermée, modèle ouvert et architecture hybride ? Consultez notre hub d'accompagnement AI Act, puis contactez IAPRO pour cadrer votre cas d'usage, vos données et vos contraintes d'hébergement.

Vérifiez vos aides en 2 minutes

Chaque dispositif (Bpifrance, France Num, aides régionales, OPCO) a ses propres critères d'éligibilité et ses propres délais. Notre simulateur croise votre profil avec les dispositifs actifs, ou échangez directement avec un expert IAPRO.

Vérifier mon éligibilité Demander un diagnostic gratuit de 30 min

Vérifiez vos aides en 2 minutes

Votre projet IA est peut-être finançable à 40-80 %. Le simulateur IAPRO croise 14 dispositifs (Bpifrance, Région Hauts-de-France, OPCO, CIR) et vous envoie le détail par email.

Vérifier mon éligibilité Demander un diagnostic gratuit de 30 min

Liens utiles