- ▸ Deux Codes signés, aucune obligation nouvelle créée
- ▸ GPAI et transparence : ce que recouvrent les deux textes
- ▸ System cards, Red Teaming, Model Spec : les mécanismes revendiqués
- ▸ Présomption de conformité : l'avantage juridique réel du signataire
Le 31 juillet 2026, OpenAI a endossé les deux Codes de bonnes pratiques de l’Union européenne. L’entreprise s’engage à documenter la sécurité, la transparence et la provenance de ses modèles, alors que le règlement (UE) 2024/1689 — l’AI Act — franchit une nouvelle phase. Distinction essentielle, souvent effacée dans les communiqués : ces Codes restent des instruments volontaires, pas des obligations contraignantes.
L’essentiel – OpenAI a endossé le GPAI Code of Practice et le Code de Transparence des contenus générés par IA, selon son annonce du 31 juillet 2026. – Ces Codes sont des instruments volontaires : les signer ouvre une présomption de conformité, sans créer d’obligation légale nouvelle. – L’entreprise dit s’appuyer sur ses dispositifs existants — system cards, Red Teaming Network, Model Spec public. – Le règlement (UE) 2024/1689 prévoit, pour les fournisseurs de modèles à usage général, des amendes jusqu’à 15 M€ ou 3 % du chiffre d’affaires mondial. – L’enjeu réel se joue dans l’écart entre l’engagement affiché et l’obligation opposable devant un régulateur.
Deux Codes signés, aucune obligation nouvelle créée
OpenAI rappelle d’emblée l’échelle de son exposition européenne. « Chaque jour, des millions de personnes en Europe utilisent les outils d’OpenAI pour apprendre, créer, travailler et gérer leurs tâches quotidiennes », écrit l’entreprise dans sa publication du 31 juillet. Ce préambule n’est pas anodin : il installe la légitimité du fournisseur à commenter le cadre qui va l’encadrer.
Le message central tient en une phrase. « Alors que l’AI Act entre dans sa phase suivante, nous partageons la manière dont nous avons renforcé notre approche de la sécurité, de la sûreté, de la transparence et de la provenance, en cohérence avec le cadre de l’UE », indique OpenAI. Le verbe est au passé composé : l’entreprise décrit des pratiques déjà en place, qu’elle aligne sur le vocabulaire réglementaire européen plutôt qu’un chantier lancé pour l’occasion.
Voilà le premier point à isoler pour un juriste ou un délégué à la protection des données. Endosser un Code de bonnes pratiques ne fait naître aucune obligation supplémentaire à la charge du signataire. Le Code est un outil d’application du règlement, négocié entre parties prenantes, que la Commission peut valider. Le signer, c’est accepter une grille de lecture commune de ses propres devoirs légaux — pas s’en ajouter de nouveaux.
GPAI et transparence : ce que recouvrent les deux textes
OpenAI précise la nature de son engagement. « Avec ces principes à l’esprit, nous avons contribué à et endossé deux Codes de bonnes pratiques : le Code de bonnes pratiques de l’UE sur l’IA à usage général [GPAI] et le Code de bonnes pratiques sur la transparence des contenus générés par IA, tous deux élaborés au terme de processus multipartites étendus », détaille l’entreprise. Elle ajoute que ces textes « s’appuient sur les travaux que nous avons fait progresser en matière de sécurité, de sûreté, de transparence, de responsabilité et de provenance ».
Deux textes, deux fonctions distinctes. Le premier, le GPAI Code of Practice, cible les fournisseurs de modèles d’intelligence artificielle à usage général — ces modèles « socles » capables d’alimenter une multitude d’applications. Il traduit en engagements concrets les obligations que le règlement (UE) 2024/1689 fait peser sur cette catégorie : documentation technique, politique de respect du droit d’auteur, information sur les données d’entraînement, gestion des risques systémiques pour les modèles les plus puissants.
Pour comprendre : qu’est-ce qu’un « Code de bonnes pratiques » ? Prévu par le règlement, c’est un référentiel rédigé avec l’industrie, la société civile et les experts, puis reconnu par la Commission. Il n’est pas une loi. Mais l’entreprise qui le respecte bénéficie d’une présomption de conformité : le régulateur considère, sauf preuve contraire, qu’elle satisfait aux obligations correspondantes. Un raccourci probatoire, pas un blanc-seing.
Le second Code porte sur la transparence des contenus générés par IA. Il vise le marquage et la traçabilité — la question de la provenance, que le règlement impose de signaler pour les images, sons et textes synthétiques. Sur ce terrain, l’enjeu n’est plus la robustesse d’un modèle mais la capacité de l’utilisateur final, et de la société, à savoir qu’un contenu a été produit par une machine.
Que les deux Codes soient nés de « processus multipartites étendus » n’est pas un simple argument de méthode. Cette co-construction conditionne leur autorité : plus le texte a agrégé de voix — industriels, académiques, associations — plus il devient difficile pour un fournisseur de le contester ensuite comme inapplicable ou disproportionné.
System cards, Red Teaming, Model Spec : les mécanismes revendiqués
OpenAI met en avant l’antériorité de ses pratiques pour asseoir sa crédibilité. « Depuis des années, nous développons des approches de gouvernance et soutenons des règles applicables qui aident les personnes à bénéficier de l’IA en toute sécurité, un objectif central de l’AI Act », affirme l’entreprise. La formule vise à dissocier son action d’une mise en conformité de dernière minute.
Le détail des dispositifs est plus instructif que la déclaration d’intention. OpenAI cite quatre mécanismes : des tests approfondis des modèles avant leur mise sur le marché, la publication de system cards accompagnant les sorties majeures, l’ouverture des tests à des experts externes via son Red Teaming Network, et la tenue d’un Model Spec public. « Depuis des années, nous avons testé nos modèles de manière approfondie avant de les publier, publié des system cards lors des sorties majeures, fait intervenir des experts extérieurs dans les tests via notre Red Teaming Network, et maintenu le Model Spec public », énumère l’entreprise.
Ces quatre briques recoupent, chacune, une exigence du règlement. La system card documente le comportement et les limites d’un modèle — elle nourrit l’obligation de documentation technique. Le Red Teaming — la mise à l’épreuve adversariale par des experts qui cherchent activement les failles — répond à la logique de gestion des risques. Le Model Spec, qui expose les règles de comportement attendues du modèle, sert la transparence sur les intentions du concepteur.
L’articulation est habile, et c’est précisément ce qui doit retenir l’attention d’un lecteur professionnel. En listant des outils antérieurs à l’AI Act, OpenAI ne dit pas seulement « nous sommes prêts ». L’entreprise construit l’argument que ses pratiques préexistantes remplissent déjà les cases du référentiel — donc que la présomption de conformité lui est acquise sans effort d’adaptation majeur. La conformité devient rétrospective.
Présomption de conformité : l’avantage juridique réel du signataire
Notre lecture : l’intérêt d’OpenAI dans cette adhésion n’est pas moral, il est probatoire. Signer les Codes, c’est acheter de la prévisibilité juridique. Face à un régulateur national ou à l’AI Office européen, le fournisseur qui respecte un Code présumé conforme inverse la charge : ce n’est plus à lui de prouver sa diligence, c’est à l’autorité de démontrer un manquement malgré le respect du référentiel.
Cet avantage a une contrepartie que l’annonce passe sous silence. Un engagement volontaire reste résiliable. Rien n’oblige un signataire à conserver indéfiniment son adhésion, et le respect affiché d’un Code ne vaut que tant que les pratiques réelles suivent. La présomption de conformité est réfragable : elle tombe si un contrôle établit l’écart entre le document et le terrain. L’endossement n’est donc pas un bouclier, mais un point de départ vérifiable.
Qui est concerné au-delà d’OpenAI ? D’abord les autres fournisseurs de modèles à usage général, pour qui le ralliement d’un acteur de cette taille crée un effet d’entraînement : ne pas signer devient un signal négatif face aux clients et aux régulateurs. Ensuite les entreprises européennes qui intègrent ces modèles dans leurs produits — éditeurs, banques, administrations. Leur propre conformité dépend en partie de la documentation transmise en amont par le fournisseur. Un modèle bien documenté allège leur charge ; un modèle opaque la reporte sur elles.
Reste la voix critique, qu’il faut entendre. Des juristes et des associations de défense des droits numériques soulignent depuis la rédaction des Codes que l’auto-régulation par référentiel volontaire peut affaiblir l’ambition du règlement. L’argument : laisser l’industrie co-écrire les modalités d’application de ses propres obligations crée un risque de nivellement par le bas. À l’inverse, les partisans de la méthode répondent que sans l’expertise des concepteurs, un texte technique resterait inapplicable. Le débat n’est pas tranché, et l’adhésion d’OpenAI ne le tranche pas — elle en illustre l’enjeu.
FAQ
Le GPAI Code of Practice a-t-il force de loi ?
Non. C’est un référentiel volontaire adossé au règlement (UE) 2024/1689. Le respecter n’est pas obligatoire, mais ouvre une présomption de conformité aux obligations légales correspondantes. La contrainte juridique reste le règlement lui-même ; le Code n’en est qu’un mode d’emploi reconnu par la Commission.
Qu’est-ce qu’une system card et pourquoi compte-t-elle ?
Une system card est un document publié par le fournisseur qui décrit le comportement d’un modèle, ses limites et les tests menés avant sa mise à disposition. Elle alimente l’obligation de documentation technique prévue par l’AI Act et permet aux entreprises utilisatrices d’évaluer les risques avant intégration.
Que risque un fournisseur qui ne respecte pas ses obligations GPAI ?
Le règlement prévoit, pour les fournisseurs de modèles à usage général, des sanctions pouvant atteindre 15 millions d’euros ou 3 % du chiffre d’affaires annuel mondial, le montant le plus élevé étant retenu. Signer un Code ne supprime pas ce risque : il le réduit en cas de contrôle, à condition que les pratiques réelles correspondent.
Les échéances encore devant nous
Le calendrier de l’AI Act n’est pas clos. Les obligations relatives aux modèles à usage général sont entrées en application, mais les régimes les plus lourds — notamment ceux visant les systèmes à haut risque et les contrôles renforcés — se déploient par paliers jusqu’en 2027 selon le règlement. Pour les fournisseurs comme pour leurs clients européens, la question désormais n’est plus de signer un Code, mais de démontrer, contrôle après contrôle, que le document et la pratique coïncident. À surveiller : les premiers audits qui viendront tester la solidité réelle de cette présomption de conformité.
