Le 2 août 2025 a fait entrer en application une partie moins visible de l'AI Act : les obligations relatives aux modèles d'IA à usage général, ou GPAI. L'événement peut sembler éloigné des entreprises qui achètent un assistant, une API ou une application métier. Les obligations visent d'abord les fournisseurs de ces modèles. Pourtant, elles changent la position des intégrateurs et des utilisateurs : ils disposent désormais d'une base plus nette pour demander ce qu'un modèle sait faire, ce qu'il ne sait pas faire et dans quelles conditions il peut être employé.

La Commission européenne a annoncé le 1er août 2025 l'entrée en application de ces règles. Pour les nouveaux modèles mis sur le marché à partir du 2 août, les fournisseurs doivent notamment établir une documentation technique, mettre à disposition des informations pour les acteurs qui intègrent le modèle, adopter une politique de respect du droit d'auteur et publier un résumé du contenu utilisé pour l'entraînement. Les modèles déjà présents sur le marché avant cette date ont jusqu'au 2 août 2027 pour se mettre en conformité.

Cette distinction est importante. Une entreprise française qui utilise un modèle via un fournisseur n'est pas, par défaut, le fournisseur du modèle généraliste. Elle ne peut pas transférer ses propres obligations de déploiement sur l'éditeur, ni lui demander de régler tous les risques de son application. Mais elle peut cesser de choisir un modèle comme une simple commodité interchangeable.

La documentation devient un élément de l'architecture

Le règlement vise les modèles capables d'exécuter un large éventail de tâches et d'être intégrés dans de nombreux systèmes. Leur généralité explique la difficulté : un même modèle peut servir à rédiger, classer, rechercher ou produire du code, selon la couche applicative construite autour de lui. La fiche de la Commission sur les obligations applicables aux GPAI distingue ainsi les exigences générales de documentation, de droit d'auteur et de transparence, et des exigences supplémentaires pour les modèles présentant un risque systémique.

Pour les équipes qui développent une application, cette documentation n'est pas un supplément juridique. Elle sert à concevoir un usage réaliste. Quelles capacités et limites le fournisseur indique-t-il ? Quels paramètres influencent le comportement du modèle ? Quelles conditions d'intégration et d'utilisation sont prévues ? Sans réponses exploitables, il devient difficile de définir des tests, d'informer les utilisateurs ou de traiter un incident.

L'article 53 de l'AI Act prévoit que les informations destinées aux fournisseurs de systèmes en aval doivent leur permettre de comprendre les capacités et limites du modèle afin de respecter leurs propres obligations. Le texte est consultable dans le service desk officiel de l'AI Act. C'est une évolution pratique : une entreprise qui construit un assistant ne devrait plus accepter de ne disposer que d'une présentation commerciale et d'une documentation d'API.

Un cahier des charges peut désormais demander, de façon concrète, les informations nécessaires au cas d'usage : périmètre documenté, modalités de mise à jour, conditions d'accès aux journaux, politique de conservation, procédure d'incident et chemin de sortie. Un cadrage IA en amont du déploiement permet de relier ces demandes à un processus métier plutôt que de les cocher abstraitement.

Les entreprises utilisatrices doivent organiser leur propre responsabilité

Le changement réglementaire ne transforme pas une API en système fiable. L'entreprise qui l'intègre décide encore quels documents il consulte, quels utilisateurs y accèdent et comment un salarié peut contredire sa réponse. Un assistant qui propose une synthèse de contrat doit être évalué dans ce contexte précis, pas sur une performance générale annoncée par son éditeur.

La documentation du modèle doit donc rejoindre les autres éléments de preuve : tests sur des données représentatives, règles de validation humaine, traçabilité des versions et traitement des retours. Une équipe n'a pas besoin d'attendre la dernière échéance du règlement pour instaurer ces pratiques. Elle a intérêt à les mettre en place avant que l'outil ne devienne difficile à remplacer ou que ses réponses influencent une décision sensible.

Le statut des données demeure central. La politique de droit d'auteur et le résumé de contenu d'entraînement exigés des fournisseurs concernent leur chaîne de production. Ils ne répondent pas à la question, plus immédiate pour l'utilisateur, de ce que devient un contrat, une fiche RH ou une note stratégique transmis à une application. C'est pourquoi le choix d'un hébergement et d'une gouvernance souverains doit être discuté avec les flux réels, les accès et les engagements du fournisseur à l'appui.

L'AI Act ne se résume pas non plus aux modèles fermés. Les exceptions prévues pour certains modèles libres ne suppriment pas toute analyse : une organisation qui adapte ou diffuse une brique doit identifier son rôle et les obligations qui lui correspondent. Dans tous les cas, « open » ne signifie ni documenté de façon suffisante, ni prêt à être déployé dans un métier réglementé.

Une occasion de remettre les contrats et les tests au même niveau

La conséquence la plus utile de l'étape d'août 2025 est peut-être de rendre une exigence élémentaire plus difficile à éluder : demander des éléments vérifiables avant l'intégration. Un service métier peut définir les erreurs inacceptables. L'informatique peut prévoir la journalisation et les droits. Les achats peuvent obtenir les engagements de documentation, de support et de réversibilité. Aucun de ces rôles ne suffit seul.

Cette organisation évite deux excès. Le premier consiste à attendre une conformité parfaite avant tout pilote ; on perd alors la possibilité d'apprendre sur un périmètre fermé. Le second consiste à déployer un outil parce qu'il est facile à essayer, puis à découvrir après coup que personne ne peut expliquer ses données, ses accès ou ses mises à jour. Un accompagnement de la conception au déploiement peut donner un propriétaire à chacune de ces décisions.

En novembre 2025, le fait nouveau n'est donc pas que chaque entreprise doive soudain produire sa propre documentation de modèle généraliste. C'est que l'écosystème européen commence à exiger davantage de transparence de ceux qui les fournissent. Les organisations qui en tireront parti ne chercheront pas un tampon réglementaire. Elles transformeront ces informations en critères de sélection, en tests et en clauses contractuelles. C'est la seule manière de faire d'un modèle généraliste une composante maîtrisée d'un système métier.