Contexte : l'open source, pilier de la souveraineté numérique européenne

L'AI Act, entré en vigueur le 1ᵉʳ août 2024, est le premier cadre législatif au monde encadrant le développement et l'usage des systèmes d'IA selon une approche par les risques. Il classe les systèmes en quatre catégories : risque inacceptable, élevé, limité, minimal. La France y voit, selon la Direction générale des Entreprises, une opportunité de renforcer sa souveraineté numérique, avec un fonds de 400 millions d'euros dédié à neuf clusters IA et un objectif de former 100 000 personnes par an.

Dans cette stratégie, l'open source n'est pas un détail technique : c'est un choix politique. Un modèle dont les poids sont publiés est auditable, rejouable, hébergeable on-premise sans dépendance aux hyperscalers américains. Pour un DPO, c'est la garantie que les données ne quittent jamais l'infrastructure. Pour un RSSI, c'est la capacité d'inspecter la chaîne. Chez IAPRO, toutes nos installations reposent sur cette logique : Ollama, OpenWebUI, RAG local. L'enjeu du législateur était donc délicat — encadrer les risques sans étouffer l'écosystème qui porte l'autonomie européenne. L'article 2(12) est le résultat de cet équilibre. Pour situer chaque brique du règlement, notre hub AI Act recense les analyses par sujet.

Décryptage juridique de l'article 2(12) : le principe de l'exemption

Le texte est d'une concision trompeuse. L'article 2, paragraphe 12, dispose : « Le présent règlement ne s'applique pas aux systèmes d'IA publiés sous licence libre et open source, sauf s'ils sont mis sur le marché ou mis en service en tant que systèmes d'IA à haut risque ou en tant que système d'IA relevant de l'article 5 ou 50. »

Cette exemption s'ajoute à deux autres exclusions structurantes du même article. Le paragraphe 10 exclut l'usage personnel non professionnel par une personne physique. Les paragraphes 6 et 8 excluent l'activité de recherche, de test et de développement menée avant la mise sur le marché — avec une réserve capitale : les tests en conditions réelles ne bénéficient pas de cette exclusion.

Il faut donc distinguer trois situations. Un développeur qui expérimente Mistral 7B sur son poste pour un projet de R&D reste hors champ. Une personne qui utilise un chatbot open source pour ses loisirs reste hors champ. Mais une entreprise qui déploie commercialement un modèle libre dans un produit destiné à des tiers entre, elle, potentiellement dans le périmètre — dès l'instant où le cas d'usage bascule vers le haut risque. L'exemption 2(12) n'est pas un statut acquis par la licence : c'est une exemption conditionnelle, suspendue à la finalité du système. Le glossaire des notions (fournisseur, déployeur, mise sur le marché) est détaillé dans notre glossaire IA.

Les limites de l'exemption : quand l'open source devient « high-risk »

Voici le cœur du sujet, et l'erreur que je vois le plus souvent. Trois portes annulent l'exemption, sans qu'aucune ne dépende de la licence.

Porte 1 — l'article 5 (pratiques interdites) : notation sociale, exploitation de la vulnérabilité des personnes, manipulation subliminale, identification biométrique à distance en temps réel dans l'espace public. Un modèle libre utilisé pour l'une de ces finalités n'est pas « exempté », il est interdit, applicable depuis le 2 février 2025.

Porte 2 — l'annexe III (haut risque) : recrutement et gestion RH, scoring de crédit, biométrie, éducation, justice, infrastructures critiques, accès aux services essentiels. Si votre système Llama fine-tuné trie des CV, il est haut risque, quel que soit son mode de distribution.

Porte 3 — l'article 50 (transparence) : chatbots et IA génératives doivent signaler à l'utilisateur qu'il interagit avec une machine et que le contenu est artificiel. Cette obligation persiste même sur un déploiement open source.

Le principe directeur : c'est l'usage qui qualifie le risque, pas le code. Une licence Apache 2.0 ne transforme pas un système de tri de candidatures en outil « à risque minimal ». Cartographier ces trois portes est la première étape de tout audit IAPRO. Le détail des systèmes à haut risque et de l'analyse d'impact (FRIA) est documenté dans le guide Regulia sur les systèmes à haut risque.

Modèles d'IA à usage général (GPAI) : les obligations spécifiques

Au-delà des systèmes applicatifs, l'AI Act crée une catégorie distincte : les modèles d'IA à usage général (GPAI, general-purpose AI models), les modèles de fondation. Leurs obligations sont entrées en application le 2 août 2025, précisées par les lignes directrices de la Commission européenne.

Le critère d'entrée est technique. Selon la FAQ officielle de la Commission, un modèle est présumé « à usage général » lorsque la puissance de calcul d'entraînement dépasse 10^23 FLOP (opérations en virgule flottante) et qu'il peut générer du langage, des images ou de la vidéo. Ce seuil correspond typiquement à l'entraînement d'un modèle d'un milliard de paramètres sur de vastes jeux de données. Il reste indicatif : un modèle en dessous peut qualifier s'il démontre une généralité significative, et inversement.

L'open source bénéficie ici d'une exemption partielle : les fournisseurs de GPAI sous licence libre peuvent être dispensés de la documentation technique et de l'information aux fournisseurs en aval, sous conditions. Mais cette faveur s'efface totalement dès qu'un modèle présente un risque systémique. Ces modèles, même open source, doivent notifier la Commission, conduire des évaluations, signaler les incidents graves et garantir un niveau de cybersécurité adéquat. La souveraineté ne dispense pas de la responsabilité.

Le statut du « provider » : qui est responsable en cas de modification ?

C'est la question qui angoisse le plus les DSI que j'accompagne : « Si je fine-tune Mistral, deviens-je juridiquement fournisseur ? » La réponse de la Commission est rassurante et précise.

La règle est celle du tiers de la puissance de calcul. Un acteur qui modifie ou affine un GPAI ne devient fournisseur, au sens de l'AI Act, que « dans des circonstances exceptionnelles », c'est-à-dire lorsque la modification utilise plus d'un tiers du training compute du modèle d'origine. En dessous de ce seuil, le fine-tuning, l'adaptation par LoRA, la quantization ou les ajustements mineurs ne font pas de vous un fournisseur soumis à l'ensemble des obligations.

Type d'intervention Statut probable Obligations
Utilisation via API ou téléchargement Déployeur Obligations du déployeur uniquement
Fine-tuning léger (< 1/3 du compute) Modificateur non-fournisseur Aucune obligation de fournisseur GPAI
Modification significative (> 1/3 du compute) Nouveau fournisseur Documentation de la modification

Point crucial : même en cas de modification significative, la Commission limite l'obligation à documenter la modification elle-même — les changements apportés et les nouvelles données d'entraînement — et non l'intégralité du modèle. Cette gradation protège l'écrasante majorité des PME européennes qui construisent sur des socles existants. Encore faut-il mesurer précisément son compute : c'est un audit technique que nous intégrons systématiquement.

Transparence et copyright : les obligations persistantes pour les modèles ouverts

L'exemption 2(12) et l'exemption partielle GPAI ne balaient pas tout. Deux obligations traversent l'open source sans s'effacer.

La première concerne le droit d'auteur. Tout fournisseur de GPAI, y compris sous licence libre, doit mettre en œuvre une politique de respect du droit d'auteur de l'Union et utiliser des technologies à l'état de l'art pour identifier et respecter les réserves de droits (opt-out). La seconde impose de publier un résumé suffisamment détaillé des contenus utilisés pour l'entraînement. Ces deux exigences ne bénéficient d'aucune dispense open source : elles visent précisément à équilibrer l'innovation et la protection de la propriété intellectuelle.

Pour les entreprises françaises, cela a une conséquence directe sur le volet RGPD. Un modèle entraîné sur des données personnelles reste soumis au Règlement (UE) 2016/679. La CNIL a publié des recommandations sur la constitution des bases d'entraînement et le respect des droits des personnes. L'article 2(7) de l'AI Act le rappelle : le règlement ne préjuge pas de l'application du droit de la protection des données. Autrement dit, un modèle libre parfaitement exempté au titre de l'AI Act peut rester pleinement soumis au RGPD. Auditabilité et documentation restent vos meilleures assurances — nous y revenons dans notre page dédiée à la documentation technique.

Cybersécurité et confiance : le rôle pivot de l'ANSSI

La robustesse d'un modèle open source ne se décrète pas, elle se teste. C'est ici qu'intervient l'écosystème français de cybersécurité. L'ANSSI (Agence nationale de la sécurité des systèmes d'information) travaille à l'articulation entre l'AI Act et les schémas de certification existants, notamment pour les systèmes à haut risque qui doivent démontrer un niveau de sécurité adéquat tout au long de leur cycle de vie.

Les modèles ouverts présentent un profil de risque spécifique : empoisonnement des données (data poisoning), attaques par exemples adverses, extraction de données d'entraînement, détournement de prompt. Parce que leurs poids sont publics, ils sont à la fois plus auditables — un avantage — et plus exposés à l'ingénierie inverse malveillante. La transparence est une force défensive à condition d'être accompagnée d'un durcissement de l'infrastructure d'hébergement.

L'AI Act prévoit également les bacs à sable réglementaires (regulatory sandboxes), applicables au 2 août 2026 au titre de l'article 57. Ces environnements contrôlés permettent, sous la supervision d'un régulateur, de tester des systèmes innovants en conditions réelles avec une souplesse temporaire. Pour une PME qui déploie un modèle libre dans un cas d'usage sensible, c'est le cadre idéal pour valider la conformité avant la mise sur le marché. Chez IAPRO, notre méthode intègre un durcissement systématique : cloisonnement réseau, journalisation, contrôle d'accès, chiffrement au repos.

Roadmap de conformité : guide pratique pour les entreprises françaises

Voici la méthodologie que j'applique lors de nos audits, en cinq étapes.

  1. Classer le risque du cas d'usage. Confrontez votre finalité aux articles 5 et 50 et à l'annexe III. RH, crédit, biométrie, santé, éducation, justice : haut risque. Chatbot informatif : risque limité. Cette étape prime sur toutes les autres, car elle détermine si l'exemption 2(12) tient.

  2. Évaluer la puissance de calcul. Le modèle utilisé dépasse-t-il 10^23 FLOP ? Votre éventuel fine-tuning franchit-il le tiers du compute d'origine ? Ces deux mesures déterminent votre statut de fournisseur ou de déployeur.

  3. Auditer la licence et les modifications. Vérifiez que la licence est réellement libre et ouverte au sens du règlement, documentez chaque modification, chaque jeu de données ajouté, chaque étape de fine-tuning.

  4. Constituer la documentation technique. Même exempté, un dossier de traçabilité (données, tests, supervision humaine, mesures de sécurité) est votre meilleure protection en cas de contrôle. C'est aussi un prérequis RGPD.

  5. Piloter le calendrier. GPAI depuis le 2 août 2025 ; sanctions (art. 99), transparence (art. 50) et application générale au 2 août 2026 ; systèmes à haut risque de l'annexe III au 2 décembre 2027 après report par l'accord omnibus ; annexe I (produits réglementés) au 2 août 2028.

Pour chiffrer l'effort, testez notre calculateur de ROI IA et croisez-le avec les aides mobilisables.

Analyse ROI : coûts de conformité vs avantages stratégiques de l'open source

La question économique est légitime : mettre en conformité un modèle open source « haut risque » coûte-t-il plus cher qu'acheter une solution propriétaire fermée ? Sur le plan comptable brut, la conformité (audit, documentation, marquage CE le cas échéant, supervision humaine) représente un investissement initial réel. Mais l'analyse s'arrête rarement là où on l'attend.

Une solution propriétaire fermée transfère la charge de conformité au fournisseur — au prix d'une dépendance durable, de coûts de licence récurrents et d'une opacité qui complique tout audit CNIL ou toute démonstration de conformité AI Act. À l'inverse, l'open source souverain internalise l'effort mais capitalise : le modèle est réutilisable, personnalisable, hébergeable on-premise, et la documentation produite sert à la fois l'AI Act et le RGPD. Sur trois à cinq ans, l'auditabilité devient un actif, pas un coût.

Pour financer cette trajectoire, les entreprises françaises disposent de leviers : les dispositifs Bpifrance pour l'investissement en IA, l'accompagnement France Num pour la transformation numérique, et les OPCO (Atlas, 2i, Constructys) pour la formation obligatoire à la maîtrise de l'IA (art. 4, applicable depuis le 2 février 2025). L'exemption 2(12) devient alors ce qu'elle doit être : un accélérateur de souveraineté maîtrisé, pas un pari juridique. Nos déclinaisons par métier chiffrent ces gains secteur par secteur.

Conclusion : vers un écosystème d'IA souveraine et responsable

L'article 2(12) du Règlement (UE) 2024/1689 est une victoire pour l'innovation européenne : il reconnaît que l'open source est un bien commun, condition de la transparence et de l'indépendance technologique. Mais ce n'est pas un permis sans condition. La même phrase qui protège annule sa protection dès que le système bascule vers le haut risque, l'interdiction ou l'obligation de transparence.

La responsabilité se déplace donc du texte vers l'acteur. Développeurs, intégrateurs, déployeurs : chacun doit maîtriser les déclencheurs de risque, mesurer son compute, documenter ses modifications et collaborer en amont avec l'AI Office et l'ANSSI. La conformité ne s'improvise pas la veille d'un contrôle ; elle se conçoit dès la phase de design. C'est précisément la promesse d'une IA souveraine et responsable — celle que nous installons chaque semaine chez nos clients.

FAQ — Open source IA et AI Act

L'exemption de l'article 2(12) signifie-t-elle que les modèles open source ne sont pas régulés du tout ?

Non. L'article 2(12) exclut les IA sous licence libre du champ de l'AI Act uniquement tant qu'elles ne sont ni mises sur le marché comme systèmes à haut risque, ni concernées par l'article 5 (pratiques interdites) ou l'article 50 (transparence). Le RGPD, le droit d'auteur et les obligations GPAI peuvent par ailleurs continuer de s'appliquer indépendamment de cette exemption.

À quel moment précis un modèle open source perd-il son statut d'exemption ?

Dès que sa finalité le fait basculer dans une catégorie régulée : usage biométrique, scoring RH, notation de crédit ou tout cas de l'annexe III (haut risque), toute pratique interdite de l'article 5, ou toute interaction relevant de la transparence (article 50). C'est l'usage effectif qui déclenche la régulation, jamais le mode de distribution ou la licence choisie.

Qu'est-ce que le seuil des 10^23 FLOP et pourquoi est-il important pour les développeurs ?

C'est le critère indicatif retenu par la Commission pour présumer qu'un modèle est « à usage général » (GPAI). Il correspond à la puissance de calcul typiquement nécessaire pour entraîner un modèle d'un milliard de paramètres. Au-delà, avec une capacité générative, le fournisseur porte des obligations de documentation et de copyright, même sous licence libre. Le seuil reste indicatif, non absolu.

Si je fais un fine-tuning d'un modèle Llama ou Mistral, deviens-je responsable du fournisseur ?

Seulement en cas de modification significative. La Commission fixe le seuil à plus d'un tiers de la puissance de calcul d'entraînement du modèle d'origine. En dessous, votre fine-tuning, adaptation LoRA ou quantization ne fait pas de vous un fournisseur GPAI soumis à l'ensemble des obligations. Au-dessus, vous documentez uniquement la modification apportée, pas le modèle entier.

Quelle est la différence entre une modification « mineure » et une modification « significative » selon l'AI Act ?

La ligne de partage est quantitative : une modification est significative lorsqu'elle mobilise plus d'un tiers du training compute du modèle initial. En dessous, la modification est mineure et n'entraîne pas de statut de fournisseur. La Commission a retenu ce seuil élevé pour que l'immense majorité des adaptations reste hors du périmètre des obligations lourdes.

Les systèmes d'IA à haut risque bénéficiant de licences libres doivent-ils obtenir un marquage CE ?

Oui. Dès qu'un système open source est mis sur le marché comme système à haut risque, l'exemption de l'article 2(12) tombe et l'intégralité des obligations s'applique : évaluation de conformité, documentation technique, supervision humaine et marquage CE lorsque le régime l'exige. La licence libre ne dispense d'aucune de ces exigences essentielles à la mise sur le marché.

Quelles sont les dates clés pour la mise en conformité des modèles GPAI open source ?

Les obligations GPAI s'appliquent depuis le 2 août 2025. Les pouvoirs de sanction de la Commission entrent en application le 2 août 2026. Les modèles GPAI mis sur le marché avant le 2 août 2025 doivent se conformer au plus tard le 2 août 2027, en application de l'article 111 du Règlement (UE) 2024/1689.

Comment l'ANSSI intervient-elle dans la certification des modèles d'IA ouverts ?

L'ANSSI travaille à l'articulation entre l'AI Act et les schémas de certification de cybersécurité, notamment pour garantir la robustesse des systèmes à haut risque face aux attaques (empoisonnement de données, exemples adverses, extraction). Elle accompagne le durcissement des infrastructures d'hébergement et contribue au cadre des bacs à sable réglementaires, applicables au 2 août 2026 au titre de l'article 57.

L'exemption de l'article 2(12) s'applique-t-elle aux tests en conditions réelles (real-world testing) ?

Non. L'article 2(8) exclut la recherche, les tests et le développement antérieurs à la mise sur le marché, mais précise explicitement que les tests en conditions réelles ne sont pas couverts par cette exclusion. Un modèle libre testé auprès d'utilisateurs réels entre donc dans le champ du règlement, sauf recours encadré à un bac à sable réglementaire.

Quelles sont les obligations spécifiques pour les modèles open source présentant un risque systémique ?

L'exemption partielle open source s'efface totalement. Les fournisseurs de GPAI à risque systémique, même sous licence libre, doivent notifier la Commission, réaliser des évaluations de modèle, signaler les incidents graves et garantir une cybersécurité adéquate. Ces obligations, entrées en application le 2 août 2025, visent à contenir les risques d'impact significatif sur le marché de l'Union.

Pour aller plus loin avec IAPRO

Vous déployez ou envisagez un modèle open source — Mistral, Llama, Qwen — et vous voulez savoir précisément où se situe votre cas d'usage sur l'échelle de risque de l'AI Act ? C'est exactement l'objet de notre audit de conformité IAPRO : classification du risque, mesure du compute, cartographie des déclencheurs 2(12) et plan d'action documenté. Discutons de votre projet via notre page contact et sécurisons votre déploiement souverain avant les échéances de 2026 et 2027.

Liens utiles