Quand une signature ne suffit plus
Une entreprise européenne intègre un modèle d’IA générative dans un logiciel RH. Le service juridique reçoit ensuite un courrier rassurant : l’éditeur du modèle annonce son adhésion au Code de pratique pour l’IA à usage général. La direction respire. Puis, quelques jours plus tard, un client public demande : « Êtes-vous conformes aux articles 53 et 55 de l’AI Act ? Pouvez-vous fournir les preuves ? »
Ce n’est pas la même question.
Signer un Code de pratique n’est pas être automatiquement conforme. C’est s’engager dans une méthode reconnue par la Commission européenne pour démontrer cette conformité. La nuance est essentielle. Elle marque le passage d’une Europe qui élabore ses règles à une Europe qui commence à demander des comptes.
Depuis le 2 août 2025, les obligations applicables aux fournisseurs de modèles d’IA à usage général — les GPAI, pour General-Purpose AI — sont entrées en application. À partir du 2 août 2026, l’AI Office européen doit pouvoir exercer plus pleinement ses pouvoirs de contrôle sur les nouveaux modèles concernés. Le compte à rebours n’est donc plus théorique : il devient opérationnel.
Pour l’étape « Observer » du Sentier du Savoir, ce moment est particulièrement intéressant. Il oblige à distinguer trois niveaux souvent confondus : la loi, le Code volontaire et le signal de marché.
Un Code volontaire, mais adossé à une loi contraignante
Le Code de pratique GPAI a été publié le 10 juillet 2025, après un processus de rédaction impliquant des experts indépendants, des entreprises, des représentants des États membres et des organisations de la société civile. Son objectif est clair : aider les fournisseurs de modèles d’IA à usage général à respecter les obligations prévues par l’AI Act.
Ces obligations portent principalement sur deux articles.
L’article 53 concerne les fournisseurs de modèles d’IA à usage général. Il leur impose notamment de tenir une documentation technique, de fournir certaines informations aux acteurs qui intègrent leurs modèles dans des systèmes d’IA, de mettre en place une politique de respect du droit d’auteur et de publier un résumé suffisamment détaillé des contenus utilisés pour l’entraînement.
L’article 55 vise les modèles d’IA à usage général présentant un risque systémique. Il ajoute des obligations plus lourdes : évaluation des risques, réduction des risques, suivi des incidents graves et cybersécurité adaptée au niveau de puissance et d’impact du modèle.
Le Code ne remplace donc pas l’AI Act. Il propose une voie pratique pour démontrer que les obligations sont prises au sérieux. C’est une différence majeure : le Code est volontaire dans son adhésion, mais les obligations auxquelles il renvoie sont juridiques.
Le calendrier à ne pas confondre
Le débat public sur l’AI Act souffre souvent d’un problème de calendrier. Plusieurs dates coexistent, ce qui crée de la confusion.
Le 2 août 2025 marque l’entrée en application des obligations pour les fournisseurs de modèles d’IA à usage général. Les nouveaux modèles placés sur le marché européen doivent donc tenir compte de ces règles.
Le 10 juillet 2025 correspond à la publication du Code de pratique GPAI. Il arrive juste avant l’entrée en application des obligations, comme un outil d’accompagnement.
Entre 2025 et 2026, plusieurs grands acteurs de l’IA signent tout ou partie du Code. Ce mouvement donne au texte une importance économique et politique : il devient progressivement un langage commun du marché.
Le 2 août 2026 constitue une étape importante pour l’exécution. L’AI Office peut alors renforcer ses demandes d’information, ses évaluations et ses exigences vis-à-vis des fournisseurs concernés.
Enfin, le 2 août 2027 concerne les modèles déjà placés sur le marché avant août 2025, qui bénéficient d’un délai plus long pour être mis en conformité.
Ce calendrier montre que l’Europe ne procède pas uniquement par interdiction. Elle met en place une transition : obligation juridique, Code volontaire, période d’adaptation, puis montée en puissance des contrôles.
Ce que signer le Code ne signifie pas
L’un des risques serait de transformer la signature du Code en label marketing. Or, il faut être précis.
Signer le Code ne signifie pas que le fournisseur est automatiquement conforme à toutes les obligations de l’AI Act. Cela signifie qu’il choisit une méthode reconnue pour faciliter la démonstration de conformité.
Signer le Code ne dispense pas non plus un intégrateur de ses propres responsabilités. Une entreprise, un hôpital, une banque, une administration ou une PME qui utilise un modèle d’IA dans un système concret doit encore analyser son propre usage, son contexte, ses risques et ses obligations.
Signer le Code ne bloque pas les contrôles. L’AI Office peut demander des informations, conduire des évaluations et exiger des mesures correctrices. La signature peut faciliter le dialogue avec l’autorité, mais elle ne supprime pas le pouvoir de contrôle.
Enfin, signer le Code ne remplace pas les futurs standards techniques européens. Le Code joue surtout un rôle de pont : il comble l’intervalle entre l’entrée en application du règlement et l’arrivée progressive de normes harmonisées plus détaillées.
Trois piliers : transparence, droit d’auteur, sécurité
Le Code de pratique GPAI repose sur trois grands chapitres.
Le premier pilier est la transparence. Les fournisseurs doivent documenter les caractéristiques de leurs modèles : capacités, limites, modalités d’usage, informations techniques utiles aux acteurs qui les intègrent dans des systèmes d’IA. L’objectif n’est pas de publier tous les secrets industriels, mais de rendre possible une compréhension suffisante du modèle par les acteurs concernés.
Le deuxième pilier est le droit d’auteur. Les fournisseurs doivent mettre en place une politique visant à respecter le droit européen, notamment sur les contenus utilisés pour entraîner les modèles. C’est l’un des points les plus sensibles, car il touche directement les créateurs, les éditeurs, les médias, les artistes et les détenteurs de droits.
Le troisième pilier concerne la sûreté et la sécurité. Il vise surtout les modèles les plus avancés, ceux qui peuvent présenter un risque systémique. Il s’agit alors d’évaluer les scénarios de dérive, de tester les capacités dangereuses, de documenter les incidents et de renforcer la cybersécurité autour du modèle et de son infrastructure.
Ces trois blocs traduisent une idée simple : un modèle d’IA puissant ne peut plus être traité comme un simple logiciel. Il devient une infrastructure cognitive utilisée par d’autres acteurs. À ce titre, il doit être documenté, contrôlable et responsable.
La liste des signataires : un indicateur de marché
La Commission européenne publie une liste de signataires du Code. On y trouve notamment de grands acteurs internationaux de l’IA et du cloud, mais aussi des entreprises européennes ou spécialisées.
Cette liste ne doit pas être lue comme un classement moral. Elle doit être lue comme un signal de marché.
Quand des acteurs majeurs adoptent un même modèle de documentation, les acheteurs publics, les grandes entreprises et les directions juridiques ont tendance à s’en servir comme référence. Même les fournisseurs non signataires peuvent alors être poussés à produire des documents équivalents.
C’est ici que le Code volontaire devient indirectement contraignant. Juridiquement, il reste possible de démontrer sa conformité autrement. Mais économiquement, il devient de plus en plus difficile de répondre à un appel d’offres européen sans documentation claire, sans politique de droit d’auteur et sans stratégie de gestion des risques.
Pour une PME, une collectivité ou une association qui achète une solution d’IA, la question n’est donc pas seulement : « Le fournisseur est-il connu ? » La question devient : « Peut-il produire des preuves lisibles ? »
Le point aveugle : ne pas confondre modèle et système
L’AI Act distingue les modèles d’IA à usage général et les systèmes d’IA. Cette distinction est centrale.
Un modèle d’IA à usage général peut servir à produire du texte, analyser des documents, générer du code, résumer des contenus ou alimenter des assistants. Il est polyvalent.
Un système d’IA, lui, correspond à un usage plus concret : recrutement, notation de dossiers, aide au diagnostic, surveillance, gestion d’infrastructures, scoring, assistance administrative, etc.
Le Code GPAI concerne d’abord le niveau du modèle. Mais les risques apparaissent souvent au niveau du système, c’est-à-dire dans l’usage réel. Un même modèle peut être peu problématique dans un outil de brouillon rédactionnel et beaucoup plus sensible dans un logiciel RH ou médical.
C’est pourquoi une entreprise ne peut pas se contenter de dire : « Mon fournisseur a signé le Code. » Elle doit encore se demander : « Que faisons-nous avec ce modèle ? Dans quel contexte ? Avec quelles données ? Pour quelles décisions ? Avec quel contrôle humain ? »
Ce que les dirigeants et citoyens peuvent vérifier dès maintenant
Pour un dirigeant de PME, une collectivité, une école, un média ou une association, l’enjeu n’est pas de devenir juriste spécialisé en IA. L’enjeu est de poser les bonnes questions avant d’acheter ou de déployer un outil.
Le fournisseur peut-il fournir une documentation technique compréhensible ?
Explique-t-il les limites du modèle, ou se contente-t-il d’un discours commercial ?
Précise-t-il les conditions d’utilisation des données ?
Publie-t-il une politique de respect du droit d’auteur ?
Indique-t-il s’il est signataire du Code de pratique GPAI ou s’il applique des mesures équivalentes ?
Donne-t-il des informations sur la sécurité, les incidents et les mises à jour ?
Permet-il à l’utilisateur professionnel de conserver des preuves en cas d’audit ?
Ces questions changent la posture de l’acheteur. Il ne s’agit plus seulement de comparer des fonctionnalités ou des prix. Il s’agit de vérifier la solidité documentaire d’un fournisseur.
Le dilemme européen : réguler assez tôt, sans figer l’innovation
Le Code GPAI illustre un dilemme classique des technologies émergentes : faut-il réguler tôt, au risque de mal comprendre la technologie, ou réguler tard, au risque de laisser les usages se verrouiller avant tout contrôle ?
C’est le dilemme de David Collingridge : au début d’une technologie, il est encore possible de l’orienter, mais ses effets sont mal connus ; plus tard, ses effets deviennent visibles, mais la technologie est déjà installée, coûteuse à modifier et parfois irréversible dans ses usages.
L’Union européenne tente ici une voie intermédiaire. Elle ne bloque pas les modèles d’IA à usage général. Elle n’attend pas non plus que les dommages éventuels soient pleinement établis. Elle demande une documentation, une politique de droit d’auteur, une évaluation des risques et une capacité de contrôle.
Cette stratégie peut être critiquée. Certains y verront une charge administrative excessive. D’autres estimeront au contraire que le cadre reste trop dépendant de la coopération volontaire des géants technologiques. Mais le point central est ailleurs : l’Europe cherche à transformer une technologie opaque en objet gouvernable.
Conclusion : du discours d’innovation à la preuve vérifiable
Le Code de pratique GPAI n’est pas un simple document de comité. Il devient un test de maturité pour l’écosystème de l’IA.
Jusqu’ici, beaucoup d’acteurs ont vendu l’intelligence artificielle à travers des promesses : gain de temps, productivité, créativité, automatisation, souveraineté, compétitivité. L’entrée en application de l’AI Act impose un autre langage : documentation, traçabilité, responsabilité, sécurité, preuve.
Pour Le Phare Info, ce moment est précieux à observer. Il montre comment une société tente de reprendre prise sur une technologie qui avance plus vite que ses institutions. Il montre aussi que la régulation ne se joue pas seulement dans les textes juridiques, mais dans les formats de preuve que les acteurs économiques acceptent progressivement comme standards.
La vraie question n’est donc plus seulement : « L’Europe va-t-elle freiner ou accélérer l’IA ? »
La question devient : « Peut-on construire une IA dont les promesses soient vérifiables, discutables et contrôlables ? »
C’est exactement le rôle du Sentier du Savoir : apprendre à ne pas confondre annonce, conformité déclarée et preuve réelle.
Pour prolonger dans le Sentier du Savoir
Cet article peut être relié à un texte fondateur sur le dilemme de Collingridge : réguler tôt, quand on ne sait pas encore tout, ou réguler tard, quand il est déjà difficile de changer de trajectoire.
Il peut aussi ouvrir un atelier pratique : apprendre à lire un dossier de conformité GPAI comme on lit un article scientifique. Qui affirme ? Quelle preuve est fournie ? Quelle limite est reconnue ? Quelle information manque ? Quelle déclaration peut être vérifiée par un tiers ?
Observer l’IA, ce n’est pas seulement suivre l’innovation. C’est apprendre à regarder les preuves derrière les promesses.
Repères de sources
- Commission européenne, Code of Practice GPAI : The General-Purpose AI Code of Practice
- Commission, processus et calendrier : Drawing-up a General-Purpose AI Code of Practice
- Q&A signataires : Questions and answers on signing the Code
- Signatory Taskforce : page AI Office
- AI Act, calendrier et GPAI : Introduction to the Code of Practice
- Règlement (UE) 2024/1689 : EUR-Lex AI Act
Dans ce triptyque
Pour replacer cette actualité dans un cadre plus durable :
Prolonger avec le Sentier du Savoir : Tester les preuves d’un dossier GPAI : méthode en six étapes
Approfondir avec le texte fondateur : David Collingridge : réguler tôt ou tard — le dilemme du Code GPAI
Vous devez être connecter pour pouvoir voter
