Le Règlement européen sur l’Intelligence Artificielle (IA Act) instaure un cadre juridique pour distinguer le système d’IA du modèle d’IA. Ces derniers sont dénommés lorsqu’ils ne concernent aucun domaine spécifique, les modèles d’IA à usage généraux ou « GPAI^[1] ». Cet article vise à expliquer le régime juridique applicable à ces objets techniques spécifiques. 

Des lignes directrices sur la portée des obligations applicables aux modèles d’IA à usage général ont été approuvées par la commission le 18 juillet 2025. Elles sont accessibles à l’adresse suivante : https://digital-strategy.ec.europa.eu/fr/library/guidelines-scope-obligations-providers-general-purpose-ai-models-under-ai-act.  

• Différences entre les GPAI et les systèmes d’IA

Le régime des GPAI vise non plus seulement des « systèmes d’IA » finalisés (au sens produit/service), mais une couche amont, réutilisable, servant de base à une multiplicité d’usages en aval.

L’ambition est d’assigner des obligations de transparence/documentation et de conformité « au niveau du modèle », indépendamment de son usage final, tout en réservant un régime renforcé aux modèles dont la puissance et la diffusion peuvent créer des risques d’ampleur « systémique ». 

Sur le plan conceptuel, la distinction « modèle » / « système » est centrale : un modèle (ex. LLM, modèle multimodal) n’est pas en soi un système d’IA prêt à l’emploi ; il doit être intégré dans une architecture (interface, orchestration, paramétrage d’usage, filtrage, monitoring, etc.) pour délivrer un service. 

La Commission européenne insiste sur cette séparation : le Chapitre V porte sur les obligations des fournisseurs de modèles (couche infrastructure), tandis que les obligations relatives aux systèmes d’IA demeurent largement dépendantes du contexte (haut risque, transparence, interdictions, etc.). 

La définition juridique du « modèle d’IA à usage général » (art. 3(63)) renvoie à un modèle affichant une « généralité significative », capable d’exécuter de nombreuses tâches distinctes, et intégrable dans une variété de systèmes/applications en aval - en excluant les modèles utilisés uniquement à des fins de recherche, développement ou prototypage avant mise sur le marché. 

• Catégorisation^[2] et procédure du risque systémique

Le Chapitre V distingue les GPAI simple des GPAI présentant un risque systémique. 

Un GPAI est à risque systémique :

► théoriquement, lorsqu’il peut avoir une incidence significative sur le marché de l’Union en raison de sa portée ou de ses effets négatifs potentiels sur la santé publique, la sûreté, la sécurité, les droits fondamentaux ou la société ; 
► concrètement, c’est le cas, lorsqu’il a des « capacités d’impact élevées » et encore plus concrètement lorsque le calcul cumulé utilisé pour son entraînement dépasse 10^25 FLOP^[3]. Il semblerait que des modèles tels que GPT 4 ou Gemini 1.5 pro ou Claude 3 opus, ou Llama 3.1-405B soient des modèles atteignent ce niveau^[4].

Le texte prévoit explicitement une adaptabilité de ces seuils et critères via actes délégués, pour refléter l’évolution de l’état de l’art (progrès algorithmiques, efficacité matérielle, nouveaux indicateurs). 

Même lorsqu’un modèle ne franchit pas le seuil de calcul, il peut être qualifié de « à risque systémique » par décision de la Commission sur la base de critères d’équivalence (définis à l’annexe XIII) : nombre de paramètres, taille/qualité du jeu de données, la quantité de calcul utilisée pour l’entraînement du modèle, les modalités d’entrée et de sortie du modèle, les critères de référence et les évaluations des capacités du modèles, les critères de référence et les évaluations des capacités du modèle, l’impact du modèle sur le marché intérieur en raison de sa portée (10 000 utilisateurs professionnels), le nombre d’utilisateurs finaux. 

L’article 52 encadre la « procédure ». Le fournisseur doit notifier la Commission dans les deux semaines dès que le critère de calcul est atteint ou qu’il est établi qu’il le sera. Ce qui signifie que sur la base de projection il est possible de déterminer qu’un modèle d’IA atteindra les seuils minimums ce qui impliquera alors de notifier la Commission quand bien même le niveau n’est pas actuellement atteint. 

Dans le cadre de cette notification^[5], le fournisseur peut produire des arguments « suffisamment étayés » pour demander que - malgré le franchissement du seuil- le modèle ne soit pas qualifié de systémique.  Il ne paraît pas possible de développer une argumentation après la notification : la contestation doit être présentée dans la notification elle-même. En pratique, si la notification ne comporte aucun élément permettant de discuter la qualification de « risque systémique », la Commission considérera la condition comme remplie et le fournisseur sera soumis aux obligations correspondantes, sauf à obtenir ultérieurement une requalification du modèle. 

Cependant, une demande de réexamen n’est possible qu’au plus tôt six mois après la décision de désignation et sur la base de raisons nouvelles, objectives et détaillées. 

La Commission peut également désigner un modèle d’office (ou suite à une alerte qualifiée du groupe scientifique). 

Enfin, la Commission doit publier et maintenir une liste des modèles systémiques, tout en protégeant les droits de propriété intellectuelle et les informations confidentielles de nature commercial ou les secrets d’affaires. 

• Obligations de base des fournisseurs de GPAI (art. 53)

Le « socle » de conformité des GPAI repose principalement sur quatre obligations documentaires chacune en vue d’un public bien distinct : 

1/ La documentation de gestion de risque pour le Bureau de l4IA et les autorités nationales compétentes : il s’agit d’une documentation ayant pour objet de comprendre les caractéristiques du GPAI y compris son processus d’entraînement et d’essai et les résultats de son évaluation. Son contenu minimal est listé à l’annexe XI : 

► description générale (tâches, politiques d’usage acceptable, date de diffusion, architecture et nombre de paramètres, modalités d’entrées/sorties, licence), et
► description détaillée du développement (moyens techniques d’intégration, spécifications et choix de conception, données d’entraînement/test/validation - type, provenance, curation, détection de biais -, ressources de calcul dont FLOP, temps d’entraînement, et consommation énergétique connue/estimée).

Elle contient conformément à l’annexe XII les éléments suivants : description du modèle et modalités de diffusion, éléments relatifs à l’intégration (moyens techniques), formats et tailles maximales des entrées/sorties (ex. longueur de fenêtre de contexte), et informations sur les données d’entraînement/test/validation (type, provenance, curation). 

Il est important de noter que ce devoir d’information spécifique est « sans préjudice » de la protection des secrets d’affaires et informations confidentielle. En pratique, il s’agira au moment de la mise à disposition de faire signer un accord de confidentialité, ou en tout état de cause ce ne pas transmettre d’information confidentielle. Il faudra néanmoins communiquer des informations, qui devront être constituées de sorte à ne pas atteindre un secret particulier, ce qui en pratique peut s’avérer compliqué. 

3/ La documentation protectrice des droits d’auteur et droits voisin : une politique de conformité au droit d’auteur et droits voisins de l’UE doit être mise en place, pour identifier et respecter une réservation de droit relative à l’exception de fouilles de texte. 

Rappelons qu’aux termes de l’article L. 122-5-3 du Code de la propriété intellectuelle, toute personne - y compris, le cas échéant, les fournisseurs de GPAI - est autorisée à réaliser des opérations de fouille de textes et de données, ce qui implique notamment la copie ou la reproduction d’œuvres auxquelles elle a eu accès de manière licite, sauf opposition de l’auteur exprimée de façon appropriée. L’article R. 122-28 du même code précise que cette opposition n’est soumise à aucune exigence de forme particulière et n’a pas à être motivée. Lorsque les contenus sont accessibles en ligne, il est en outre indiqué que l’opposition peut être formulée soit au moyen de procédés lisibles par machine (par exemple via des métadonnées), soit par une mention insérée dans les conditions générales d’utilisation du site internet ou du service concerné.

Ainsi, l’IA Act exige, en pratique, que le fournisseur de GPAI soit en mesure de démontrer, au moyen d’une politique formalisée, les mesures qu’il met en œuvre pour (i) empêcher toute fouille de textes et de données lorsque l’auteur s’y est valablement opposé ou, à tout le moins, (ii) vérifier, préalablement à l’entraînement, l’absence d’interdiction exprimée sur les sites et services en ligne dont il entend exploiter les contenus.

4/ La documentation destinée au public : Le fournisseur doit publier un résumé « suffisamment détaillé » du contenu utilisé pour entraîner le modèle, selon le template disponible à l’adresse suivante : https://digital-strategy.ec.europa.eu/en/library/explanatory-notice-and-template-public-summary-training-content-general-purpose-ai-models  

Le renseignement de ce template suppose d’y intégrer trois séries d’informations : 

► des informations générales relatives au fournisseur, aux caractéristiques du modèle et à ses modalités d’entraînement ;
► des informations portant sur les sources de données, selon leurs modalités d’accès (sources publiques, privées, issues d’internet, provenant d’utilisateurs, etc.) ; 
► des informations relatives aux traitements appliqués aux données, notamment au regard du droit d’auteur, de la fouille de textes et de données, ou encore des mécanismes de suppression. 

Certaines lacunes peuvent, le cas échéant, être justifiées lorsque l’information est indisponible ou lorsque son obtention ferait peser une charge disproportionnée, sous réserve d’une explication circonstanciée.

Sur le plan temporel, l’obligation de résumé public est applicable depuis le 2 août 2025, mais les modèles placés sur le marché avant cette date doivent être couverts au plus tard le 2 août 2027. 

La Commission ajoute enfin une logique de mise à jour : le résumé doit être mis à jour si le modèle est ré-entraîné sur des données additionnelles et, en principe, à des intervalles de six mois (ou plus tôt si mise à jour matériellement significative). 

• Obligations renforcées pour les GPAI à risque systémique

Pour les modèles qualifiés de systémiques, l’article 55 ajoute aux obligations précité des obligations spécifique pour évaluer, atténuer et gérer les risques systémiques : 

► le fournisseur doit réaliser des évaluations selon des protocoles/outils standardisés reflétant l’état de l’art, incluant des tests documentés afin d’identifier et atténuer les risques systémiques ;
► l’évaluation et l’atténuation des risques systémiques « au niveau de l’Union » : obligation large couvrant les risques pouvant découler du développement, de la mise sur le marché ou de l’usage ;
► la gestion des incidents graves : traçabilité, documentation et notification sans retard injustifié à le Bureau de l’IA (et, si pertinent, aux autorités nationales) des incidents graves et des mesures correctives possibles ;
► la cybersécurité : niveau adéquat de protection du modèle et de l’infrastructure physique associée. 

• Représentant autorisé pour les fournisseurs hors UE (article 54)

Lorsque certains fournisseurs ne sont pas établis dans l’Union européenne, ils ne peuvent distribuer un GPAI sur le territoire de l’Union qu’en désignant un mandataire.

Dans le cadre de l’AI Act, la mission de ce mandataire consiste à s’assurer que le modèle satisfait aux conditions applicables à sa mise sur le marché : il doit notamment détenir la documentation requise, être en mesure de répondre aux demandes des autorités compétentes et mettre à leur disposition les informations pertinentes évoquées ci-dessus.

Il convient de préciser que ces obligations doivent être formalisées dans un contrat écrit, expressément prévu par l’AI Act. En outre, le mandataire est tenu de pouvoir mettre fin à ce contrat s’il estime que le fournisseur n’est pas conforme au règlement. Il en résulte une exigence de vigilance continue : le mandataire doit soit s’assurer de la conformité du fournisseur, soit se désolidariser de lui.

• Exception open source (art. 53.2 et 54.6)

L’article 53.2 et 54.6 exempte les fournisseurs et mandataires de certains modèles diffusés sous licence libre et open source des obligations de documentation (points (a) et (b)), à condition que l’accès/usage/modification/distribution soient permis et que paramètres/poids, architecture et informations d’usage soient rendus publics ; ainsi, l’exemption ne s’applique pas aux modèles systémiques. 

Les documents d’orientation de la Commission apportent une lecture plus précise « compliance » : conditions de licence véritablement libre/open source, transparence sur poids/architecture/usages ; maintien des obligations de politique copyright et de résumé du contenu d’entraînement ; et exclusion totale de l’exemption pour les modèles systémiques. 

• Codes de bonnes pratiques

Le fournisseur, comme le mandataire pour les GPAI avec ou sans risque systémique doivent mettre en œuvre des codes de bonnes pratiques ou alors des normes harmonisées ou alors d’autres moyens appropriés de mise en conformité et les soumette à l’appréciation de la Commission. 

Concernant le code de bonnes pratiques, l’article 56 décrit son contenu. D’une part, le code de bonne pratique doit couvrir les obligations listées ci-avant et préciser : 

► les moyens de s’assurer que la documentation pour les autorités et bureau de l’IA d’une part et celle pour les fournisseurs en aval d’autre part sont misses à jour à la lumière des évolutions du marché et des technologies ; 
► le niveau de détail des résumés de contenu pour l’entrainement ; 
► l’identification du type et de la nature des risques systémiques au niveau de l’Union, y compris leurs origines, le cas échéant ; 
► les mesures, procédures et modalités d’évaluation et de gestion des risques systémiques y compris la documentation y afférentes. Ces éléments devant être proportionnés aux risques, prendre en considération leur gravité et leur probabilité et tenir compte des défis spécifiques que pose la maîtrise de ces risques à la lumière des différentes façons dont ils peuvent apparaître ou se concrétiser tout au long de la chaine de valeur de l’IA, c’est-à-dire de sa conception à sa mise sur le marché, voir sa maintenance et son arrêt. 

Un tel code de bonnes pratiques a été publié le 10 juillet 2025. Il est disponible en cliquant sur le lien suivant : https://digital-strategy.ec.europa.eu/fr/policies/contents-code-gpai#ecl-inpage-Signatories-of-the-AI-Pact . 

Ce code a été approuvé par une décision d’adéquation en date du 1er août 2025, conformément à l’article 56, paragraphe 6, § 2.

Il s’articule en trois volets :

► transparence : un formulaire destiné à être complété par les signataires, afin de faciliter la satisfaction des obligations de transparence ;
► droit d’auteur et droits voisins : un guide opérationnel détaillant les mesures à mettre en œuvre pour assurer la conformité aux exigences relatives aux droits de propriété littéraire et artistique ;
► sécurité et sûreté : une méthodologie, de même nature, visant à structurer la mise en conformité avec les obligations applicables en matière de sécurité.

Les signataires sont listés sur le site de la commission. Y figure notamment : Open AI, Amazon, Anthropic, Microsoft, Mistral AI, Google…

• Conclusion et checklist de conformité

Le Chapitre V impose une conformité amont, qui concerne le modèle et non le système, qui ne se confond pas avec la conformité aval (système). Pour les juristes, le point structurant est d’organiser la responsabilité et la preuve le long de la chaîne de valeur (documentation, droits d’auteur/TDM, transparence publique, gestion des incidents et cybersécurité pour les modèles systémiques), et de verrouiller contractuellement l’échange d’information entre fournisseur du modèle et intégrateurs. 

Ainsi, en substance il convient a minima de : 

► qualifier l’objet : modèle GPAI vs système ; 
► documenter « annexe XI » (autorités) et « annexe XII » (fournisseur aval) et organiser la mise à jour continue (processus + responsabilité + preuves). 
► mettre en place une politique copyright/TDM opérationnelle, intégrant la gestion des réservations de droits (opt-out) exprimées par moyens appropriés/machine-readable. 
► produire et publier le résumé public du contenu d’entraînement selon le template Commission, avec stratégie d’arbitrage transparence / secret d’affaires, et gouvernance de mise à jour. 
► anticiper le statut « systémique » : critères, procédure de notification et capacité à justifier/contester, puis préparation des exigences article 55. 
► définir une stratégie « codes de bonnes pratiques » et préparer la relation d’exécution centralisée avec le Bureau de l’IA. 

Dans le cadre du cycle « le Règlement sur l’Intelligence artificielle », nous vous proposons de nous retrouver chaque mois pour améliorer notre compréhension commune de ce règlement et que vous soyez ainsi prêt pour son entrée en application :

• #1 Entrée en vigueur et champ d’application de l’IA Act : quel périmètre exact pour les juristes ?
• #2 Pratiques d’IA interdites : analyse des dispositions de l’article 5
• #3 Classifications juridiques des systèmes d’IA : comprendre les catégories de risque
• #4 Obligations juridiques concrètes des fournisseurs d’IA à haut risque : exigences et conformité
• #5 Transparence et explicabilité juridiques des systèmes d’IA : portée exacte des obligations pour les juristes
• #6 Modèles d’IA à usage général : encadrement et responsabilités
• #7 Impacts de l’IA Act sur les contrats IT : adaptations nécessaires
• #8 Mesures de soutien à l’innovation : bacs à sable réglementaires et autres initiatives
• #9 Gouvernance interne et responsabilité juridique : analyse critique des obligations organisationnelles
• #10 Mise en œuvre et surveillance : rôle des autorités nationales et européennes
• #11 Bases de données de l’UE sur les IA à haut risque : transparence et accessibilité
• #12 Codes de conduite et lignes directrices : rôle et élaboration
• #13 Sanctions en cas de non-conformité : cadre et implications

Le département Contrats informatique, données & conformité peut vous accompagner dans tout le cycle de vie du SIA et notamment pour répondre à vos obligations en tant que fournisseur ou mandataire de GPAI.

Pour toute question, n’hésitez pas à nous contacter.

^[1] General-purpose AI models

^[2] L’IA Act parle de classification mais il nous semble que catégorisation est plus adaptée. 

^[3] Floating-point operation, en virgule flottante. 

^[4] https://epoch.ai/data-insights/models-over-1e25-flop.

^[5] Il nous semble que cela doit se faire en même temps, au risque de voir son modèle considéré à risque systémique alors même qu’il ne l’est pas, et sans pouvoir revenir sur cette décision avant 6 mois et avec des éléments nouveaux (v. infra).