Comprendre le code conduite GPAI dans l'écosystème de l'AI Act

L'AI Act, le Règlement (UE) 2024/1689, encadre les systèmes d'intelligence artificielle mis sur le marché européen selon une logique de risque. Au sein de ce dispositif, les modèles d'IA à usage général — les GPAI, comme les grandes familles de modèles de langage — font l'objet d'obligations propres, distinctes de celles des systèmes à haut risque. C'est précisément pour aider l'industrie à appliquer ces obligations que la Commission a publié le 10 juillet 2025 le General-Purpose AI Code of Practice.

Ce Code de conduite est un outil volontaire, élaboré par treize experts indépendants dans un processus multi-parties prenantes ayant réuni plus de 1 400 participants et 1 600 contributions écrites, selon la page officielle de la Commission européenne. La nuance est capitale pour un dirigeant : le Code lui-même n'impose aucune obligation nouvelle. Il sert de mode d'emploi pour démontrer la conformité à des obligations qui, elles, existent bel et bien dans le Règlement.

L'AI Office — l'autorité de la Commission chargée de la gouvernance des GPAI — et le Comité IA ont confirmé que ce Code constitue un moyen volontaire adéquat pour prouver sa conformité. Concrètement, comme le rappelle la communication d'accompagnement, un fournisseur qui signe bénéficie d'une charge administrative réduite et d'une sécurité juridique accrue par rapport à celui qui prouverait sa conformité par d'autres moyens.

Je ne vais pas re-détailler ici, article par article, l'ensemble des obligations de l'AI Act sur les GPAI : elles tiennent à la documentation technique, au respect du droit d'auteur européen et, pour les modèles les plus puissants, à la gestion des risques systémiques. Pour une lecture exhaustive des obligations applicables aux PME et de leur articulation avec le reste du règlement, je renvoie au guide de référence Regulia sur l'AI Act pour les PME, qui traite ce volet réglementaire en profondeur.

Qui est concerné par le code conduite GPAI ? Analyse pour les PME

C'est la question qui déclenche le plus de malentendus en réunion de direction. La réponse tient dans une distinction fondamentale de l'AI Act : celle entre fournisseur (provider) et déployeur (deployer).

Le fournisseur est celui qui développe un modèle GPAI et le met sur le marché sous son nom. Le déployeur est celui qui utilise ce modèle dans son activité — la très grande majorité des PME françaises. Or les obligations documentées par le Code de conduite pèsent sur les fournisseurs de modèles GPAI, pas sur les déployeurs. Une PME qui installe un assistant conversationnel interne, un RAG documentaire sur ses procédures ou un outil de synthèse à partir d'un modèle open-weight existant n'est, dans l'écrasante majorité des cas, pas fournisseur de GPAI.

Les lignes directrices de la Commission pour les fournisseurs de GPAI apportent trois clarifications précieuses :

  • Des critères techniques clairs définissent quand un modèle est « à usage général », afin que les développeurs sachent s'ils tombent dans le périmètre des obligations.
  • Une approche pragmatique sur les modifications : seuls ceux qui apportent des modifications significatives à un modèle existant doivent se conformer aux obligations de fournisseur ; les changements mineurs — comme un fine-tuning léger de type LoRA sur un jeu de données métier restreint — n'y suffisent généralement pas.
  • Des exemptions pour l'open-source : sous certaines conditions, les fournisseurs de modèles ouverts sont exemptés de certaines obligations, afin de favoriser la transparence et l'innovation.

Pour un dirigeant, la démarche est donc d'abord une qualification : suis-je fournisseur ou déployeur ? Est-ce que je modifie un modèle de façon significative ? Dans mon expérience, une PME de moins de 250 salariés qui exploite l'IA générative en interne relève quasi systématiquement du statut de déployeur — un statut qui l'exonère du Code de conduite GPAI mais pas d'autres obligations transversales de l'AI Act.

Les trois piliers du Code de conduite : Transparence, Copyright et Sécurité

Le Code s'organise en trois chapitres rédigés séparément, dont le champ d'application diffère selon la puissance du modèle. Cette structure tripartite mérite d'être comprise, car elle détermine ce qui s'applique réellement à un développeur français.

Chapitre Qui est concerné Objet principal
Transparence Tous les fournisseurs de GPAI Documentation du modèle via un formulaire standardisé (art. 53 AI Act)
Copyright Tous les fournisseurs de GPAI Politique de respect du droit d'auteur européen (art. 53 AI Act)
Sûreté et Sécurité Fournisseurs de modèles à risque systémique uniquement Gestion des risques des modèles les plus avancés (art. 55 AI Act)

Les chapitres Transparence et Copyright offrent à tous les fournisseurs de GPAI une voie pour démontrer leur conformité à l'article 53 de l'AI Act. En revanche, le chapitre Sûreté et Sécurité n'est pertinent que pour le petit nombre de fournisseurs des modèles les plus avancés, soumis aux obligations de l'article 55 pour les GPAI à risque systémique.

Cette séparation est structurante pour une PME : même un développeur français qui construirait réellement un modèle généraliste ne serait, dans la quasi-totalité des cas, concerné que par deux des trois chapitres. Le troisième — le plus lourd, avec évaluations de modèle, tests adversariaux et notifications d'incidents graves — vise des acteurs à l'échelle de calcul très supérieure. La liste des signataires publiée par la Commission le confirme : on y trouve Mistral AI, Anthropic, OpenAI, Microsoft, IBM, mais aussi des acteurs européens comme LINAGORA ou Pleias. À noter que xAI n'a signé que le chapitre Sûreté et Sécurité, s'engageant à démontrer sa conformité transparence et copyright par d'autres moyens adéquats.

Transparence et documentation : simplifier la charge administrative

Le grand apport pratique du Code, pour tout fournisseur, tient dans le Model Documentation Form — un formulaire de documentation standardisé fourni au format DOCX avec le chapitre Transparence. Là où beaucoup redoutent une documentation technique à réinventer, le Code livre une trame prête à remplir.

Ce formulaire permet de documenter de manière structurée les informations nécessaires pour satisfaire l'obligation de transparence de l'AI Act, notamment :

  • Les licences et conditions d'utilisation du modèle, essentielles pour clarifier les droits transmis aux déployeurs situés en aval de la chaîne de valeur.
  • Les spécifications techniques : architecture, nombre de paramètres, modalités d'entrée et de sortie, capacités et limites connues du modèle.
  • Les jeux de données d'entraînement, avec le niveau de description attendu par le règlement, y compris un résumé suffisamment détaillé du contenu utilisé.
  • La consommation énergétique liée à l'entraînement, un point de plus en plus scruté par les acheteurs publics et les grands comptes soucieux de leur bilan carbone.

L'intérêt stratégique est double. D'une part, cette standardisation réduit réellement la bureaucratie : un cadre commun est toujours plus rapide à remplir qu'un dossier à concevoir de zéro. D'autre part, une documentation propre est un actif commercial. Dans un cabinet ou une ETI qui évalue un fournisseur d'IA, la capacité à produire immédiatement une fiche de documentation conforme fait souvent la différence face à un concurrent qui bafouille. C'est un point que je mesure dans notre calculateur de ROI IA : le temps administratif évité a une valeur chiffrable.

Enjeux du Copyright pour les PME françaises utilisant l'IA

Le chapitre Copyright est celui qui expose le plus les développeurs français, car il touche à une pratique répandue : la collecte de données web pour entraîner ou affiner un modèle. L'AI Act impose aux fournisseurs de GPAI de mettre en place une politique de respect du droit d'auteur de l'Union, et le Code de conduite en propose des solutions concrètes.

Une politique de copyright robuste, telle qu'attendue, suppose plusieurs engagements opérationnels :

  • Le respect des réservations de droits exprimées par les ayants droit, notamment via les signaux d'exclusion techniques comme le fichier robots.txt et les protocoles d'opt-out du text and data mining.
  • La vérification des autorisations préalables avant l'exploitation de contenus protégés, plutôt qu'une logique de collecte indiscriminée suivie d'une régularisation improbable.
  • Un mécanisme de gestion des plaintes permettant aux titulaires de droits de signaler une utilisation non autorisée et d'obtenir une réponse.

Ce sujet n'est pas théorique. La Commission a d'ailleurs lancé, comme le signale le Service Desk officiel de l'AI Act, une consultation sur la manière d'identifier et de respecter les réservations de droits des ayants droit, ouverte jusqu'au 9 janvier 2026. Pour une PME qui scrape des données pour construire un modèle métier, ignorer ce pilier revient à bâtir sur une base juridique fragile. J'insiste sur ce point en audit : l'installation on-premise que nous déployons chez IAPRO privilégie systématiquement des modèles dont la provenance des données d'entraînement est documentée, précisément pour protéger nos clients de ce risque en aval.

Risques systémiques et seuils techniques : quand la conformité devient critique

Le troisième pilier — Sûreté et Sécurité — ne concerne qu'une poignée d'acteurs mondiaux, mais tout dirigeant qui développe de l'IA doit connaître le seuil qui le déclenche, ne serait-ce que pour situer l'échelle de son propre projet.

L'AI Act définit le risque systémique par référence à des capacités à fort impact, c'est-à-dire des capacités égalant ou dépassant celles des modèles GPAI les plus avancés. Le critère technique est précis : selon la FAQ officielle de la Commission, le règlement présume qu'un modèle entraîné avec une quantité cumulée de calcul supérieure à 10^25 opérations en virgule flottante (FLOP) possède des capacités à fort impact.

Pour donner un ordre de grandeur : ce seuil correspond à des campagnes d'entraînement de plusieurs dizaines de millions d'euros, mobilisant des milliers d'accélérateurs pendant des semaines. Aucune PME française, à ma connaissance, n'entraîne aujourd'hui de modèle atteignant ce niveau. Le fine-tuning d'un modèle open-weight sur des données métier, même ambitieux, se situe des ordres de grandeur en dessous.

La conséquence pratique est rassurante : pour la quasi-totalité des PME, les obligations du chapitre Sûreté et Sécurité ne s'appliquent pas. Connaître ce seuil sert surtout à écarter une inquiétude infondée et à recentrer l'énergie sur ce qui compte vraiment — la transparence et le copyright si l'on est fournisseur, ou les obligations de déployeur si l'on utilise l'IA. Pour situer votre cas d'usage dans la cartographie des risques de l'AI Act, notre hub AI Act IAPRO propose une grille de lecture par niveau de risque.

Calendrier de mise en conformité : les dates clés à retenir

Le calendrier est probablement le point où circulent le plus d'informations erronées, notamment depuis l'accord « omnibus numérique » de mai 2026 qui a décalé certaines échéances. Voici les dates exactes qui gouvernent spécifiquement les GPAI et leur Code de conduite.

Échéance Ce qui s'applique
2 août 2025 Entrée en application des obligations pour les fournisseurs de GPAI + gouvernance / AI Office
2 août 2026 Pouvoirs d'exécution de la Commission, y compris les amendes
2 août 2027 Mise en conformité des modèles GPAI mis sur le marché avant le 2 août 2025

Comme le détaillent les lignes directrices officielles : depuis le 2 août 2025, les fournisseurs de GPAI mettant un modèle sur le marché sont soumis aux obligations et sont invités à collaborer de façon informelle avec les équipes techniques de l'AI Office. À partir du 2 août 2026, la Commission acquiert ses pouvoirs d'exécution et pourra sanctionner. Enfin, les modèles déjà présents sur le marché avant août 2025 disposent d'un délai courant jusqu'au 2 août 2027 pour se mettre en conformité.

Attention à ne pas confondre ce calendrier propre aux GPAI avec les autres échéances de l'AI Act, décalées par l'omnibus. Les systèmes à haut risque de l'annexe III (RH, scoring crédit, biométrie, santé…) ne s'appliquent qu'à partir du 2 décembre 2027, et les obligations de transparence de l'article 50 sur les contenus générés par IA à partir du 2 août 2026. Chaque famille d'obligations a son propre tempo — d'où l'utilité d'une feuille de route datée, adaptée à votre situation.

Avantages stratégiques : transformer la conformité en levier de confiance

Réduire le Code de conduite à une contrainte serait une erreur d'analyse. Pour les rares PME réellement fournisseuses de GPAI, la signature offre un retour sur investissement concret, et pour toutes les autres, la logique sous-jacente inspire une posture commerciale gagnante.

Trois bénéfices se dégagent. Premièrement, la sécurité juridique : la Commission et le Comité IA ayant jugé le Code adéquat, un signataire voit l'application se concentrer sur le suivi de son adhésion, ce qui apporte davantage de prévisibilité et une charge administrative réduite. Deuxièmement, la réputation B2B : dans les appels d'offres, notamment publics ou avec de grands comptes, être signataire d'un Code endossé par la Commission est un signal de sérieux immédiatement lisible. Troisièmement, l'alignement avec la souveraineté numérique : la présence de signataires européens comme Mistral AI ou LINAGORA montre que la conformité et la souveraineté avancent de pair.

C'est exactement le positionnement que nous défendons chez IAPRO. Notre méthode d'installation d'IA souveraine on-premise — modèles ouverts type Mistral ou Llama, servis via Ollama et OpenWebUI sur l'infrastructure du client — s'inscrit naturellement dans cet esprit de transparence et de maîtrise des données. La conformité cesse d'être un coût subi pour devenir un argument de différenciation face aux offres cloud extra-européennes. Pour explorer les dispositifs de financement de cette démarche, notre hub des aides à l'IA recense les leviers Bpifrance et France Num mobilisables.

Feuille de route pour une PME : comment adopter le Code de conduite dès aujourd'hui

Voici la démarche que j'applique en accompagnement, du diagnostic à la mise en œuvre, pour éviter à la fois la sur-conformité anxieuse et l'angle mort réglementaire.

  1. Qualifier votre statut GPAI. Déterminez si vous êtes fournisseur d'un modèle à usage général ou simple déployeur. Dans neuf cas sur dix pour une PME, la réponse est « déployeur », ce qui vous écarte du Code de conduite GPAI tout en vous maintenant sous d'autres obligations de l'AI Act.

  2. Analyser l'impact de vos modifications. Si vous affinez un modèle existant, mesurez si la modification est significative au sens des lignes directrices. Un fine-tuning léger sur des données métier reste généralement en deçà du seuil de requalification en fournisseur.

  3. Décider de la signature, le cas échéant. Si vous êtes effectivement fournisseur, la signature du Code — en adressant le Signatory Form à l'adresse dédiée de l'AI Office — est le chemin le plus économique vers la conformité, avec réduction de la charge administrative à la clé.

  4. Préparer la documentation technique. Appuyez-vous sur le Model Documentation Form fourni par la Commission pour structurer licences, spécifications, jeux de données et consommation énergétique. Les fournisseurs doivent par ailleurs transmettre leurs documents à l'AI Office via la plateforme sécurisée EU SEND, qui garantit confidentialité, intégrité et authenticité.

Cette feuille de route se combine avec l'inventaire des systèmes d'IA que tout organisme devrait tenir. Pour aller plus loin sur les modèles documentaires et le registre interne, le guide Regulia dédié aux documents de conformité propose des trames directement exploitables.

Conclusion : vers une IA souveraine et responsable en France

Le Code de conduite GPAI n'est ni une menace ni une formalité anodine : c'est un instrument d'équilibre entre innovation et sécurité. Pour la grande majorité des PME françaises, qui déploient l'IA sans développer de modèle généraliste, il constitue surtout une grille de lecture rassurante — leurs obligations réelles relèvent du statut de déployeur, pas du Code. Pour les quelques acteurs français qui construisent des modèles, il offre un chemin de conformité allégé et un signal de confiance auprès des clients.

Dans les deux cas, la logique reste la même : documenter, respecter le droit d'auteur, maîtriser ses données. Ces exigences convergent avec ce que je défends au quotidien — une IA installée chez le client, sous son contrôle, protégeant ses intérêts face aux géants technologiques. La conformité, bien menée, n'est pas un frein à l'adoption : elle en est la condition de confiance.

FAQ — Code de conduite GPAI pour les PME

Le code conduite GPAI est-il obligatoire pour toutes les entreprises utilisant l'IA ?

Non. Le Code de conduite est un outil volontaire qui ne vise que les fournisseurs de modèles d'IA à usage général. Les PME qui se contentent de déployer ou d'utiliser des solutions d'IA existantes ne sont pas fournisseurs et ne sont donc pas concernées par le Code, même si d'autres obligations de l'AI Act peuvent s'appliquer à elles en tant que déployeurs.

Quelle différence existe-t-il entre un modèle d'IA généraliste (GPAI) et une application IA classique ?

Un modèle GPAI est un modèle sous-jacent polyvalent, capable d'accomplir un large éventail de tâches, comme un grand modèle de langage. Une application IA classique est un système bâti au-dessus d'un tel modèle pour un usage précis. La PME qui exploite une application relève du statut de déployeur, tandis que les obligations du Code pèsent sur celui qui fournit le modèle généraliste.

Une PME française qui modifie légèrement un modèle existant doit-elle se conformer au code ?

Non, dans la plupart des cas. Les lignes directrices de la Commission adoptent une approche pragmatique : seules les modifications significatives d'un modèle entraînent les obligations de fournisseur. Un fine-tuning léger de type LoRA sur un jeu de données métier restreint reste généralement en deçà de ce seuil et ne requalifie pas la PME en fournisseur de GPAI.

Quels sont les bénéfices concrets de la signature du Code de conduite par rapport à une conformité standard ?

La signature procure une charge administrative réduite et une sécurité juridique accrue. La Commission et le Comité IA ayant jugé le Code adéquat, l'application se concentre sur le suivi de l'adhésion, ce qui apporte davantage de prévisibilité. S'y ajoute un bénéfice réputationnel : être signataire d'un Code endossé par la Commission est un signal de sérieux dans les appels d'offres B2B.

Comment le Code de conduite traite-t-il les questions de droits d'auteur sur les données d'entraînement ?

Le chapitre Copyright impose aux fournisseurs de mettre en place une politique de respect du droit d'auteur européen. Cela suppose de vérifier les autorisations préalables, de respecter les réservations de droits exprimées via des signaux comme le robots.txt, et de gérer les plaintes des ayants droit. Ce pilier est crucial pour toute PME qui collecte des données web pour entraîner un modèle.

À partir de quelle date les sanctions financières pour non-conformité peuvent-elles être appliquées ?

Pour les fournisseurs de GPAI, les pouvoirs d'exécution de la Commission, incluant les amendes, entrent en application le 2 août 2026. Les obligations elles-mêmes s'appliquent depuis le 2 août 2025, et les modèles déjà sur le marché avant cette date bénéficient d'un délai courant jusqu'au 2 août 2027 pour se mettre en conformité.

Quels sont les critères techniques qui définissent un modèle à 'risque systémique' ?

L'AI Act présume qu'un modèle entraîné avec une quantité cumulée de calcul supérieure à 10^25 opérations en virgule flottante (FLOP) possède des capacités à fort impact et présente donc un risque systémique. Ce seuil correspond à des entraînements de plusieurs dizaines de millions d'euros. Aucune PME française n'atteint aujourd'hui ce niveau, ce qui l'exonère du chapitre Sûreté et Sécurité.

Le code de conduite s'applique-t-il aux modèles d'IA en open-source ?

Les lignes directrices de la Commission précisent que, sous certaines conditions, les fournisseurs de modèles open-source sont exemptés de certaines obligations, afin de favoriser la transparence et l'innovation. L'exemption n'est toutefois pas totale : les obligations relatives au risque systémique demeurent pour les modèles les plus puissants, même ouverts. Il convient de vérifier les conditions précises d'exemption au cas par cas.

Comment soumettre officiellement ses documents de conformité à l'AI Office (plateforme EU SEND) ?

Les fournisseurs de modèles GPAI doivent utiliser la plateforme sécurisée EU SEND pour transmettre à l'AI Office les documents liés à leurs obligations : notifications de modèles à risque systémique, demandes de réévaluation, rapports d'incidents graves. Toutes les transmissions sont chiffrées afin de garantir la confidentialité, l'intégrité et l'authenticité des informations partagées avec la Commission.

Que se passe-t-il si une PME ne signe pas le code de conduite mais souhaite rester conforme à l'AI Act ?

La signature n'est pas obligatoire. Un fournisseur qui ne signe pas doit démontrer sa conformité par d'autres moyens adéquats et, conformément aux lignes directrices, transmettre à l'AI Office un rapport expliquant comment il entend respecter l'AI Act. Cette voie est possible mais plus lourde : elle expose à davantage d'incertitude juridique et à une charge administrative supérieure à celle des signataires.

Pour aller plus loin avec IAPRO

Vous développez un modèle d'IA ou vous déployez une solution générative en interne et vous voulez savoir précisément où vous vous situez dans l'AI Act ? Notre formule d'audit de conformité AI Act qualifie votre statut, cartographie vos obligations réelles et vous livre une feuille de route datée. Nous couplons cet audit à notre offre d'installation d'IA souveraine on-premise, pour transformer la contrainte réglementaire en avantage de souveraineté. Contactez-moi via la page contact IAPRO pour un premier échange sans engagement.

Liens utiles