Modèles d'IA à usage général : les lignes directrices qui clarifient la chaîne de responsabilités

Intelligence artificielle et droit Publié le 24/07/2025 Dimitri Jorand

La Commission européenne a publié le 18 juillet 2025 des lignes directrices sur les modèles d'IA à usage général. Ce qu'elles précisent sur la qualification de fournisseur.

Un éditeur de logiciel métier pour le secteur médico-social annonce qu'il a « fine-tuné » un grand modèle de langage pour l'adapter à la rédaction de projets personnalisés d'accompagnement. Une entreprise privée développe en interne une variante d'un modèle open source pour l'usage de ses équipes RH. Dans les deux cas, une question juridique se pose immédiatement : ces acteurs restent-ils de simples utilisateurs d'un modèle tiers, ou deviennent-ils eux-mêmes fournisseurs d'un modèle d'IA à usage général, avec les obligations que cela implique ?

La Commission européenne a publié le 18 juillet 2025 des lignes directrices destinées aux fournisseurs de modèles d'IA à usage général. Ces lignes directrices ne créent pas de nouvelles obligations : elles interprètent le règlement européen sur l'IA et précisent, notamment, ce qu'est une modification substantielle susceptible de faire basculer un acteur en aval dans le statut de fournisseur.

Pour un établissement de santé, une collectivité territoriale ou une entreprise qui achète ou fait développer des outils intégrant de l'IA, cette clarification a une portée directe. Elle permet de poser les bonnes questions à un éditeur ou à un intégrateur, et de savoir jusqu'où va sa propre responsabilité de déployeur.

Ce que sont les lignes directrices, et ce qu'elles ne sont pas

Les lignes directrices publiées par la Commission européenne ne sont pas un texte de loi. Elles n'ajoutent aucune obligation nouvelle au règlement européen sur l'IA, mais elles expliquent comment la Commission entend l'appliquer, notamment pour les points les plus ambigus du texte. Une autorité de surveillance nationale ou une juridiction peut s'en écarter, mais elles constituent une référence forte pour anticiper les contrôles.

Pour un directeur d'établissement ou un DPO, cette nuance compte : les lignes directrices n'ont pas la même force qu'un article du règlement. Elles donnent une grille de lecture utile pour dialoguer avec un fournisseur ou un intégrateur qui invoquerait une conformité approximative.

Qualifier un modèle d'IA à usage général

Un modèle d'IA à usage général se caractérise par sa polyvalence : il peut être appliqué à des tâches variées, au-delà d'une fonction unique et prédéfinie. Les lignes directrices détaillent des critères pour distinguer ce type de modèle d'un système d'IA plus spécialisé, construit pour une tâche unique et fermée.

Pourquoi cette distinction compte pour un établissement

Si l'outil utilisé par un centre hospitalier ou une association repose sur un modèle à usage général, la chaîne de responsabilité inclut potentiellement le fournisseur du modèle, le fournisseur du système final et l'établissement déployeur. Si l'outil repose sur un système spécialisé conçu pour une tâche unique, la chaîne peut être plus courte, mais les obligations du déployeur en matière de supervision humaine et d'information restent identiques.

La notion de modification substantielle

C'est l'un des apports les plus concrets des lignes directrices. Un acteur qui prend un modèle existant et le modifie de façon substantielle, par exemple par un ré-entraînement significatif sur de nouvelles données, peut être considéré comme le fournisseur du modèle modifié. Il hérite alors des obligations correspondantes, y compris de documentation et, le cas échéant, d'évaluation des risques.

À l'inverse, un simple paramétrage, un ajustement de prompt ou une utilisation en l'état du modèle ne constitue pas une modification substantielle. Un GHT qui configure un assistant conversationnel avec des instructions internes, sans toucher au modèle lui-même, ne devient pas fournisseur pour autant.

La documentation attendue du fournisseur

Les lignes directrices précisent le niveau de détail attendu de la documentation technique que le fournisseur d'un modèle à usage général doit produire et mettre à disposition des fournisseurs de systèmes en aval. Cette documentation doit permettre de comprendre les capacités du modèle, ses limites connues, les données générales utilisées pour son entraînement et les mesures prises en matière de droit d'auteur.

Pour un intégrateur qui construit un logiciel métier destiné à un CHU ou une entreprise privée, cette documentation constitue la matière première de sa propre notice d'utilisation. Un établissement qui ne reçoit qu'une communication marketing en lieu et place d'une documentation technique doit s'interroger sur la solidité de la chaîne de conformité en amont.

Les questions à poser à son éditeur ou son intégrateur

Un service DSI, RH ou qualité qui négocie un contrat avec un éditeur peut s'appuyer sur les lignes directrices pour structurer ses questions, sans avoir besoin d'une expertise juridique poussée.

1. Identifier le fournisseur du modèle sous-jacent. Demandez son nom et confirmez auprès de votre éditeur que la version utilisée reste conforme à l'originale, sans modification substantielle.
2. Demander si une modification substantielle a eu lieu. Si l'éditeur a ré-entraîné le modèle sur des données spécifiques, demandez qui en assume le statut de fournisseur.
3. Vérifier l'existence d'une documentation technique. Elle doit exister même si elle n'est pas intégralement transmise à l'établissement, pour des raisons de confidentialité industrielle.
4. Demander une notice d'utilisation adaptée à votre contexte. Elle doit préciser les limites du système pour un usage en santé, en RH ou en formation.
5. Clarifier la répartition contractuelle des responsabilités. En cas de dysfonctionnement lié au modèle lui-même, la clause contractuelle doit indiquer qui répond de quoi.
6. Demander une clause de mise à jour. Toute évolution significative du modèle ou de ses conditions d'usage doit être notifiée à l'établissement déployeur.
7. Consigner les réponses dans le registre des usages IA. Cette traçabilité facilite toute vérification ultérieure par une autorité de contrôle ou en interne.

Deux situations concrètes

Dans une MAS ou un FAM, la direction envisage d'utiliser un outil d'aide à la rédaction de projets personnalisés reposant sur un modèle de langage générique, non modifié par l'éditeur. L'établissement reste déployeur, ses obligations portent sur l'information des équipes et la vérification humaine systématique des contenus générés avant intégration au dossier de l'usager.

Dans une collectivité territoriale, la DSI fait développer par un prestataire un chatbot interne entraîné de façon spécifique sur les procédures administratives locales à partir d'un modèle open source. Ce ré-entraînement peut être qualifié de modification substantielle. La collectivité doit vérifier avec le prestataire si celui-ci assume alors un statut de fournisseur, et quelles obligations documentaires en découlent, avant la mise en service.

Objections fréquentes

Certains éditeurs affirment que toute intégration d'un modèle tiers reste transparente pour l'établissement, sans besoin de vérification. Les lignes directrices montrent que ce n'est vrai que si aucune modification substantielle n'a eu lieu. D'autres estiment que les lignes directrices, n'étant pas contraignantes, peuvent être ignorées. Elles restent la référence d'interprétation que retiendront vraisemblablement les autorités de surveillance en cas de contrôle.

Pour comprendre plus largement la notion de modèle à usage général et ses implications, DEMETER propose un décryptage dédié sur euaiact.fr, présenté comme une ressource pédagogique et non comme une source officielle.

Ce que change concrètement cette clarification pour les contrats

Avant ces lignes directrices, de nombreux contrats entre éditeurs et établissements restaient silencieux sur l'origine exacte du modèle utilisé et sur les éventuelles adaptations réalisées en amont. La clarification apportée par la Commission donne aux acheteurs un vocabulaire précis pour négocier des clauses adaptées, plutôt que de s'en remettre à des formulations génériques de conformité au règlement européen sur l'IA, souvent insuffisantes pour couvrir les cas de personnalisation poussée d'un modèle.

Pour un OPCO Santé ou un organisme de formation qui envisage de faire développer un outil pédagogique reposant sur un modèle de langage adapté à son référentiel de compétences, cette vigilance contractuelle devient un préalable, et non une option, avant tout déploiement auprès des stagiaires ou des agents en formation.

Ce que votre organisation peut faire maintenant

• Identifier, pour chaque outil d'IA utilisé, si le modèle sous-jacent a été modifié par l'éditeur ou l'intégrateur.
• Demander par écrit qui assume le statut de fournisseur du modèle en cas de ré-entraînement significatif.
• Mettre à jour le registre des usages IA avec ces éléments de qualification.
• Former les équipes DSI et achats à la distinction entre paramétrage et modification substantielle.
• Prévoir une clause contractuelle de notification en cas d'évolution du modèle utilisé.

Ces vérifications s'articulent avec la gouvernance globale de l'IA décrite dans notre article sur la métiers émergents en santé : intégrer de nouvelles expertises sans désorganiser les équipes et dans son complément pratique, IA en santé en France : ce que révèle le premier état des lieux national. Elles s'appuient aussi sur le schéma directeur immobilier en santé : piloter un projet qui relie soins, usages et climat pour tracer les réponses obtenues, et rejoignent les obligations générales détaillées dans notre article sur les AI Pact : les enseignements d'un an de préparation volontaire à l'AI Act. La question de la classification du risque, souvent liée à ces qualifications, est traitée dans notre article sur la data Act : ce que l'accès aux données des objets connectés change pour les organisations.

Conclusion

Les lignes directrices du 18 juillet 2025 donnent une grille claire pour comprendre qui, dans la chaîne d'un outil d'IA, porte le statut de fournisseur du modèle. Poser la question de la modification substantielle avant tout projet de personnalisation, demander une documentation technique et consigner les réponses dans un registre des usages reste le réflexe le plus utile pour un CHU, une collectivité, une association ou une entreprise. Pour être accompagné dans cette qualification, consultez notre page diagnostic AI Act ou notre offre de conseil, et contactez nos équipes via la page contact.

Questions fréquentes

Les lignes directrices du 18 juillet 2025 sont-elles obligatoires ?

Non. Elles interprètent le règlement européen sur l'IA mais n'ont pas de force contraignante autonome. Elles constituent néanmoins la référence d'interprétation la plus probable pour les autorités de surveillance.

Qu'est-ce qu'une modification substantielle d'un modèle ?

C'est une transformation significative d'un modèle existant, par exemple un ré-entraînement important sur de nouvelles données, qui peut faire de l'acteur qui la réalise le fournisseur du modèle modifié.

Un simple paramétrage rend-il mon établissement fournisseur du modèle ?

Non. L'ajustement d'instructions, de prompts ou de paramètres d'usage ne constitue pas, en principe, une modification substantielle au sens des lignes directrices.

Que dois-je demander à mon éditeur pour vérifier la chaîne de responsabilité ?

Le nom du fournisseur du modèle, l'existence d'une éventuelle modification substantielle, la documentation technique disponible et une clause contractuelle de notification en cas d'évolution du modèle.

Ces lignes directrices changent-elles les obligations d'un établissement déployeur ?

Non, elles ne créent pas de nouvelle obligation pour les déployeurs. Elles clarifient la qualification des acteurs en amont, ce qui aide l'établissement à savoir à qui s'adresser en cas de doute.

Que faire si mon intégrateur a ré-entraîné significativement un modèle ?

Il convient de vérifier avec lui s'il assume le statut de fournisseur du modèle modifié et quelles obligations documentaires il a respectées, avant toute mise en production de l'outil.