IA à usage général (GPAI) sous le règlement IA de l’UE

L’essentiel

• Le modèle d’IA à usage général est la catégorie juridique que le règlement IA réserve aux modèles à large capacité, définie à l’article 3(63) : une généralité significative, l’aptitude à accomplir un large éventail de tâches distinctes et la vocation à être intégré dans d’autres systèmes.
• La Commission européenne présume qu’un modèle est à usage général lorsque sa puissance de calcul d’entraînement dépasse environ 10^23 opérations en virgule flottante et qu’il sait générer du texte, des images ou de la vidéo, la généralité réelle primant toutefois sur le chiffre.
• Un second seuil, plus élevé, fixé à 10^25 opérations, marque l’IA à usage général présentant un risque systémique, soumise aux obligations renforcées de l’article 55.
• Tout fournisseur supporte quatre obligations de base au titre de l’article 53 : documentation technique, information des acteurs en aval, politique de droit d’auteur et résumé public des contenus d’entraînement.
• Le code de bonnes pratiques pour l’IA à usage général, publié le 10 juillet 2025, constitue la voie concrète pour démontrer la conformité, et le socle d’obligations s’applique depuis le 2 août 2025.

Qu’est-ce qu’un modèle d’IA à usage général ?

Un modèle d’IA à usage général, souvent abrégé GPAI, apprend une capacité large à partir de grands volumes de données, puis peut être orienté vers de multiples tâches. Le règlement IA lui donne un sens juridique précis à l’article 3(63) : un modèle qui « fait preuve d’une généralité significative » et qui est « capable d’exécuter de manière compétente un large éventail de tâches distinctes », apte à être intégré dans des systèmes ou applications en aval. Les grands modèles de langage qui équipent les assistants familiers en sont l’illustration la plus nette, aux côtés des modèles d’image et multimodaux des principaux laboratoires. Cette définition compte, car elle désigne qui porte les obligations. Le règlement encadre le modèle lui-même, distinctement de tout produit fini bâti par-dessus. Un laboratoire qui entraîne un modèle et le met sur le marché de l’Union est fournisseur d’un modèle d’IA à usage général, même s’il ne commercialise jamais d’application grand public. Pour une vue d’ensemble du règlement, voyez la plateforme AI Sigil.

IA à usage général, modèle de fondation et IA générative

Ces trois termes décrivent la même technologie sous des angles différents, et les confondre conduit à des erreurs de conformité.

• L’IA à usage général est le terme juridique employé par le règlement IA. C’est lui qui déclenche les obligations exposées ici.
• Le modèle de fondation est la description technique : un grand modèle entraîné sur des données larges, servant de socle à de nombreux usages en aval. La plupart des modèles de fondation sont des modèles d’IA à usage général au sens juridique.
• L’IA générative désigne une capacité, celle de produire du texte, des images, de l’audio ou du code. Un système génératif repose habituellement sur un modèle à usage général, mais « génératif » est une fonctionnalité, pas la catégorie juridique.

Pour cartographier les obligations, raisonnez à partir du terme juridique. Un modèle entre dans le champ parce qu’il est à usage général au sens de l’article 3(63), et non parce qu’une plaquette commerciale l’a qualifié de génératif.

Comment le règlement détermine si votre modèle est à usage général

La puissance de calcul est le premier signal. Dans ses lignes directrices publiées le 18 juillet 2025, la Commission a posé un repère indicatif : un modèle est présumé à usage général lorsque le calcul cumulé d’entraînement dépasse 10^23 opérations en virgule flottante et qu’il sait générer du langage (texte ou audio), du texte vers image ou du texte vers vidéo. Cela correspond grossièrement à des modèles entraînés avec environ un milliard de paramètres. Le chiffre est un point de départ, pas un verdict. La Commission est explicite : la généralité tranche. Un modèle qui franchit le seuil de calcul mais n’accomplit qu’une tâche étroite, comme transcrire la parole ou générer de la musique, peut rester hors catégorie. Un modèle sous le seuil mais réellement polyvalent peut y entrer. Le test lit d’abord la capacité et l’ampleur, et n’utilise le calcul que comme indice. Pour la plupart des organisations qui achètent ou affinent des modèles plutôt que de les entraîner de zéro, la vraie question n’est pas d’avoir franchi 10^23 opérations. C’est de savoir si elles en ont fait assez pour devenir fournisseur à part entière, ce qu’aborde la section sur la chaîne de valeur.

Deux niveaux : usage général et risque systémique

Le règlement scinde l’IA à usage général en deux niveaux, et le second pèse nettement plus lourd. L’article 51 fixe la ligne du risque systémique. Un modèle est présumé doté de « capacités à fort impact » lorsque « la quantité cumulée de calcul utilisée pour son entraînement, mesurée en opérations en virgule flottante, est supérieure à 10^25 ». Un modèle peut aussi être désigné par décision de la Commission, d’office ou sur alerte du panel scientifique, selon les critères de l’annexe XIII. L’article 51(3) autorise la Commission à déplacer ces seuils à mesure que le matériel et les algorithmes progressent, afin que la ligne suive la frontière technologique. Les deux chiffres jouent des rôles distincts, faciles à confondre :

• 10^23 opérations : le déclencheur indicatif du statut même d’IA à usage général, issu des lignes directrices.
• 10^25 opérations : le déclencheur du niveau de risque systémique, inscrit à l’article 51.

Une poignée de modèles de pointe franchissent la seconde ligne. La grande majorité des modèles à usage général reste au niveau standard, avec les seules obligations de l’article 53. Identifier le bon niveau est la première décision de conformité, car elle fixe l’ampleur de tout ce qui suit.

Les obligations de tout fournisseur (article 53)

L’article 53(1) pose quatre obligations de base qui s’imposent à tout fournisseur d’un modèle d’IA à usage général, quel que soit le niveau.

1. Documentation technique. Le fournisseur doit « élaborer et tenir à jour la documentation technique du modèle, y compris son processus d’entraînement et de test », conformément à l’annexe XI, et la mettre à disposition du Bureau de l’IA et des autorités nationales sur demande.
2. Information des acteurs en aval. Le fournisseur prépare et tient à jour une documentation destinée aux organisations qui bâtissent sur le modèle, prévue à l’annexe XII, pour qu’elles comprennent les capacités et limites du modèle et respectent leurs propres obligations.
3. Politique de droit d’auteur. Le fournisseur doit « mettre en place une politique de respect du droit de l’Union en matière de droit d’auteur et de droits voisins », notamment en identifiant et respectant les réserves de droits exprimées au titre de l’article 4(3) de la directive sur le droit d’auteur dans le marché unique numérique.
4. Résumé public des contenus d’entraînement. Le fournisseur doit « élaborer et mettre à la disposition du public un résumé suffisamment détaillé du contenu utilisé pour l’entraînement », selon le modèle fourni par le Bureau de l’IA.

Ensemble, ces obligations transforment un modèle, de boîte noire en objet documenté et redevable. Deux des quatre regardent vers l’extérieur, vers les constructeurs en aval et le public, ce qui explique qu’elles demandent le plus de préparation.

L’exception open source (et sa limite)

Le règlement accorde un répit partiel aux modèles ouverts. Au titre de l’article 53(2), un modèle publié sous « licence libre et open source » autorisant l’accès, l’usage, la modification et la distribution, avec paramètres, architecture et informations d’usage rendus publics, est exempté des deux premières obligations : la documentation technique et le dossier d’information en aval. La politique de droit d’auteur et le résumé d’entraînement restent dus. Il existe une limite ferme. L’exception « ne s’applique pas aux modèles d’IA à usage général présentant un risque systémique ». Un modèle de pointe à poids ouverts qui franchit la ligne des 10^25 porte l’ensemble des obligations, licence ouverte ou non. L’ouverture allège la paperasse au niveau standard ; elle n’exempte un modèle systémique de rien.

Les obligations renforcées pour le risque systémique (article 55)

Au niveau du risque systémique, le fournisseur assume quatre obligations supplémentaires au-dessus de l’article 53, énoncées à l’article 55.

• Évaluation du modèle. Le fournisseur doit « réaliser l’évaluation du modèle conformément à des protocoles et outils normalisés », y compris « des tests contradictoires visant à recenser et atténuer les risques systémiques ». Le red teaming passe de bonne pratique à attente légale.
• Évaluation et atténuation des risques. Le fournisseur doit « évaluer et atténuer les risques systémiques possibles au niveau de l’Union », y compris leurs sources, sur l’ensemble du cycle de développement, de mise sur le marché et d’usage.
• Signalement des incidents graves. Le fournisseur doit « suivre, documenter et signaler sans retard injustifié au Bureau de l’IA et, le cas échéant, aux autorités nationales compétentes les informations pertinentes sur les incidents graves », avec les mesures correctives envisageables.
• Cybersécurité. Le fournisseur doit « garantir un niveau adéquat de protection en matière de cybersécurité pour le modèle et son infrastructure physique ».

Ces devoirs ressemblent à un programme de gestion des risques, raison pour laquelle des cadres comme le profil de l’Université de Berkeley pour les modèles à usage général et de fondation, qui prolonge le cadre de gestion des risques de l’IA du NIST, s’y appliquent sans heurt. En France, l’ANSSI pour le volet cybersécurité et la CNIL pour les données personnelles fournissent des repères nationaux utiles. Pour les organisations dotées de processus de risque structurés, le travail consiste à les étendre au niveau du modèle plutôt qu’à repartir de zéro. Notre approche de la gestion des risques IA suit la même logique.

Le code de bonnes pratiques GPAI : la voie rapide

Le code de bonnes pratiques pour l’IA à usage général, publié le 10 juillet 2025, est l’instrument que la plupart des fournisseurs emploieront. Il est volontaire, mais y adhérer ouvre une présomption de conformité aux obligations des article 53 et article 55 tant que des normes européennes harmonisées n’existent pas. En pratique, c’est la route la plus courte et crédible pour démontrer la conformité. Le code comporte trois chapitres :

• Transparence. Ce chapitre fournit un formulaire de documentation du modèle que le fournisseur remplit une fois, puis partage avec le Bureau de l’IA et les acteurs en aval. Le remplir vaut présomption de conformité aux obligations de documentation des article 53 et article 54.
• Droit d’auteur. Ce chapitre détaille la mise en oeuvre de la politique de droit d’auteur exigée par l’article 53, notamment le respect des réserves de fouille de textes et de données.
• Sûreté et sécurité. Ce chapitre vise les fournisseurs au risque systémique. Il décrit un cadre de sûreté et de sécurité couvrant évaluations du modèle, red teaming, surveillance après commercialisation, cybersécurité, signalement des incidents et redevabilité, qui ensemble satisfont aux devoirs de l’article 55.

Signer le code ne supprime pas les obligations sous-jacentes. Il offre une manière reconnue de les attester, bien plus simple que de défendre une approche maison devant un régulateur.

Fournisseur, déployeur ou fournisseur en aval ?

La question la plus fréquente des praticiens ne porte pas sur les seuils. C’est : « quel rôle jouons-nous ? » Le règlement distingue le fournisseur du modèle du déployeur qui l’utilise, et la réponse change radicalement les obligations. La plupart des organisations sont déployeuses. Elles accèdent à un modèle à usage général via une API ou un contrat d’entreprise et bâtissent par-dessus. Le déployeur n’hérite pas des devoirs de l’article 53, mais il a besoin de la documentation en aval du fournisseur pour remplir ses propres obligations, surtout si son système fini est à haut risque au titre d’autres parties du règlement. Le piège, c’est l’affinage. Un acteur en aval qui modifie un modèle à usage général peut devenir lui-même fournisseur d’un modèle d’IA à usage général, et porter alors les devoirs de l’article 53 pour le modèle modifié. Les lignes directrices retiennent un indicateur : une modification mobilisant plus d’environ un tiers du calcul d’entraînement initial est le type de changement qui franchit la ligne. Un affinage léger reste bien en deçà. Un réentraînement substantiel peut faire basculer une organisation de déployeur à fournisseur sans décision consciente, et c’est pourquoi l’analyse du rôle relève de la gouvernance, non de la seule tête d’un ingénieur. Une règle pratique : documentez la décision de rôle, consignez le calcul utilisé pour tout affinage et conservez le dossier d’information en aval du fournisseur. Ces trois habitudes répondent à l’essentiel des questions d’un régulateur ou d’un client.

Calendrier, application et sanctions

Les dates sont arrêtées. Le règlement IA est entré en vigueur le 1er août 2024. Les obligations relatives à l’IA à usage général s’appliquent depuis le 2 août 2025, un an plus tard. Les modèles déjà sur le marché avant cette date disposent d’un délai plus long, la conformité étant exigée pour le 2 août 2027. L’application des règles GPAI relève du Bureau européen de l’IA, qui supervise les fournisseurs directement, et non par les seules autorités nationales. Le Bureau peut demander la documentation, évaluer les modèles et exiger des mesures correctives. Les sanctions sont calibrées pour compter. Au titre de l’article 101, la Commission peut infliger à un fournisseur de modèle d’IA à usage général une amende pouvant atteindre 3 % de son chiffre d’affaires annuel mondial total ou 15 millions d’euros, le montant le plus élevé étant retenu, pour manquement aux obligations ou défaut de réponse à une demande. Pour un grand fournisseur, c’est un chiffre de niveau conseil d’administration, et c’est pourquoi la conformité GPAI a quitté la revue juridique pour entrer dans la planification produit.

Rendre la conformité GPAI opérationnelle

Les obligations deviennent gérables dès que chacune est rattachée à un livrable concret :

• La documentation technique correspond à un dossier de modèle tenu à jour (annexe XI).
• L’information en aval correspond à un dossier remis à chaque client (annexe XII).
• La politique de droit d’auteur correspond à une règle écrite et appliquée de sourcing des données.
• Le résumé d’entraînement correspond à un document publié sur le modèle du Bureau de l’IA.
• Pour les modèles systémiques, évaluation, signalement des incidents et cybersécurité correspondent à un programme continu de gestion des risques.

La difficulté n’est pas de les produire une fois. C’est de les garder à jour à mesure que le modèle est réentraîné, que les clients changent et que des incidents surviennent. Une plateforme de gouvernance qui stocke chaque livrable, en suit le responsable et signale son obsolescence transforme une série de devoirs juridiques en un processus répétable. C’est l’objet même d’AI Sigil : réunir la documentation, les registres de risques et les preuves en un seul lieu, pour produire une attestation de conformité à la demande.

Questions fréquentes

ChatGPT est-il une IA à usage général ? Le modèle qui sous-tend ChatGPT est un modèle d’IA à usage général au sens du règlement IA, car il fait preuve d’une généralité significative et accomplit un large éventail de tâches distinctes. Le produit conversationnel est un système bâti sur ce modèle. Le fournisseur du modèle sous-jacent porte les obligations de l’article 53 ; une organisation qui se contente d’utiliser l’assistant est déployeuse. Quelle différence entre IA à usage général et IA générale ? L’IA à usage général est une catégorie juridique et pratique pour les modèles largement capables d’aujourd’hui. L’intelligence artificielle générale (AGI) est un système futur hypothétique qui égalerait ou dépasserait l’humain sur presque toutes les tâches. Le règlement IA encadre l’IA à usage général qui existe ; il ne définit ni ne régule l’AGI comme objet distinct. Qu’est-ce qu’un modèle d’IA à usage général à risque systémique ? Un modèle à usage général est présumé à risque systémique lorsque son calcul cumulé d’entraînement dépasse 10^25 opérations en virgule flottante, au titre de l’article 51. La Commission peut aussi le désigner selon les critères de l’annexe XIII. Ces modèles portent les devoirs supplémentaires de l’article 55, en plus du socle. Les modèles open source doivent-ils se conformer ? En partie. Au titre de l’article 53(2), un modèle réellement libre et open source est exempté de la documentation technique et de l’information en aval, mais doit conserver une politique de droit d’auteur et un résumé public des contenus d’entraînement. L’exception ne joue pas du tout pour les modèles à risque systémique, qui se conforment intégralement. Utiliser un modèle à usage général fait-il de mon entreprise un fournisseur ? Généralement non. Accéder à un modèle et bâtir par-dessus fait de vous un déployeur. Vous pouvez devenir fournisseur si vous modifiez ou affinez le modèle de façon substantielle, la Commission pointant les changements mobilisant plus d’environ un tiers du calcul d’entraînement initial. Consignez ce que vous faites pour clarifier le rôle. Comment un fournisseur démontre-t-il sa conformité ? La voie la plus directe est le code de bonnes pratiques pour l’IA à usage général, publié le 10 juillet 2025. Y adhérer ouvre une présomption de conformité aux obligations des article 53 et article 55 en attendant les normes harmonisées, et son formulaire de documentation du modèle offre un modèle prêt à l’emploi.

Conclusion

L’IA à usage général n’est plus un mot vague. Sous le règlement IA, c’est une catégorie juridique dotée d’une définition claire, de deux seuils de calcul et d’une pile d’obligations en vigueur depuis août 2025. Le chemin est ordonné : confirmer si votre modèle est à usage général, déterminer s’il atteint le niveau systémique, traiter les devoirs de l’article 53 et, le cas échéant, de l’article 55, puis attester par le code de bonnes pratiques. Les organisations qui réussissent traitent le sujet comme un problème de documentation et de gestion des risques, avec des responsables et des échéances, et non comme un exercice juridique ponctuel. Commencez par la qualification, puis construisez les livrables une fois et tenez-les à jour.