AI Act : fournisseur, déployeur, importateur et requalification en fournisseur

L’AI Act (règlement (UE) 2024/1689 sur l’intelligence artificielle) ne répartit pas ses obligations selon la technologie employée. Il les répartit selon le rôle que joue chaque acteur dans la chaîne qui va du développeur au dernier utilisateur. Le rôle n’est pas figé : l’article 25 transforme un revendeur, un importateur ou un utilisateur en fournisseur dès qu’il touche à la marque, au système ou à son usage prévu.

→ Lire l’explication complète de la marmotte

Les rôles d’opérateur définis à l’article 3 de l’AI Act

L’article 3 définit six rôles. Ils se cumulent et se requalifient, ce qui explique pourquoi la question « quel est notre rôle ? » appelle presque toujours la réponse « lequel, pour quel système ? ».

Fournisseur (point 3) : personne qui développe ou fait développer un système d’IA (intelligence artificielle) ou un modèle d’IA à usage général, et qui le met sur le marché ou met le système en service sous son propre nom ou sa propre marque, à titre onéreux ou gratuit. Deux leviers suffisent : faire développer (sous-traiter ne dédouane pas) et apposer son nom.
Déployeur (point 4) : personne qui utilise un système d’IA sous sa propre autorité, sauf pour une activité personnelle à caractère non professionnel. Le critère est le contrôle de l’usage, pas la propriété du code.
Mandataire (point 5) : personne établie dans l’Union européenne (UE), titulaire d’un mandat écrit d’un fournisseur pour accomplir en son nom certaines obligations.
Importateur (point 6) : personne établie dans l’UE qui met sur le marché un système portant le nom ou la marque d’une personne établie dans un pays tiers.
Distributeur (point 7) : toute personne de la chaîne, autre que le fournisseur ou l’importateur, qui met un système à disposition sur le marché de l’Union.
Opérateur (point 8) : terme générique qui regroupe fournisseur, fabricant de produits, déployeur, mandataire, importateur et distributeur.

Trois définitions servent à raisonner plutôt qu’à qualifier. La mise sur le marché (point 9) est la première mise à disposition dans l’Union ; la mise à disposition (point 10) couvre toute fourniture ultérieure dans une activité commerciale ; la mise en service (point 11) est la fourniture pour un premier usage, directement au déployeur ou pour usage propre. Ce dernier point piège les équipes internes : un système développé en interne et mis en service pour son propre usage fait de l’organisation un fournisseur, sans qu’aucune facture ne circule. La destination (point 12) désigne l’usage prévu par le fournisseur, tel que décrit dans la notice, la documentation commerciale et la documentation technique. C’est elle qui décide si un système relève de l’annexe III, et c’est elle que le cas c de l’article 25 vise.

La carte ci-dessous se lit de gauche à droite le long de la chaîne de valeur ; chaque flèche correspond à un changement de main, donc potentiellement à un changement de rôle.

Les obligations propres à chaque maillon feront l’objet de pages dédiées de la série ; en une ligne chacune :

mandataire (art. 22) : tenir à disposition des autorités la déclaration de conformité et la documentation technique, coopérer avec elles ;
importateur (art. 23) : vérifier avant mise sur le marché l’évaluation de conformité, la documentation, le marquage CE (Conformité Européenne) et la désignation d’un mandataire ;
distributeur (art. 24) : vérifier marquage, déclaration et notice, et suspendre la distribution en cas de doute sur la conformité ;
déployeur (art. 26) : utiliser le système selon la notice, confier le contrôle humain à des personnes compétentes, surveiller le fonctionnement et conserver les journaux au moins six mois.

Le cas le plus fréquent en entreprise, celui de l’organisation qui intègre un modèle par API (Application Programming Interface) et se retrouve à la fois fournisseur de son application et déployeur, est traité dans AI Act et modèle d’IA à usage général appelé par API. La présente page ne refait pas ce travail ; elle couvre l’autre bout du problème, le passage d’un rôle à l’autre.

Requalification en fournisseur : les trois cas de l’article 25

L’article 25, paragraphe 1, est court et lourd de conséquences. Un distributeur, un importateur, un déployeur ou tout autre tiers est considéré comme fournisseur d’un système d’IA à haut risque, et soumis aux obligations de l’article 16, dans trois situations.

Cas a : le nom ou la marque. Le tiers commercialise sous son nom ou sa marque un système à haut risque déjà mis sur le marché ou en service. Le texte précise « sans préjudice des dispositions contractuelles prévoyant une autre répartition des obligations » : le contrat peut répartir le travail, mais le nom affiché sur le produit reste le point d’entrée naturel de l’autorité de surveillance du marché. La marque blanche n’est pas un détail de packaging, c’est un transfert de responsabilité.

Cas b : la modification substantielle. Le tiers apporte une modification substantielle à un système déjà à haut risque, qui reste à haut risque au sens de l’article 6. Le point 23 de l’article 3 définit la modification substantielle comme un changement postérieur à la mise sur le marché, non prévu ou planifié dans l’évaluation de conformité initiale, qui affecte la conformité aux exigences du chapitre III, section 2, ou modifie la destination. L’article 43, paragraphe 4, en tire la conséquence : nouvelle évaluation de conformité. Il précise aussi que les changements prédéterminés lors de l’évaluation initiale pour un système qui continue d’apprendre ne sont pas des modifications substantielles.

Cas c : le changement de destination. Le tiers modifie la destination d’un système qui n’était pas classé à haut risque, y compris un système d’IA à usage général, de sorte qu’il le devient. Aucune ligne de code n’a besoin de bouger : un prompt système, une intégration dans un processus de décision listé à l’annexe III, et le rôle bascule.

Le paragraphe 2 règle le sort du fournisseur d’origine. Il cesse d’être fournisseur de ce système, pas de son produit en général. Il doit coopérer étroitement avec le nouveau fournisseur : mettre à disposition les informations nécessaires, fournir l’accès technique et l’assistance raisonnablement attendus pour remplir les obligations, notamment l’évaluation de conformité. Une exception change tout : si le fournisseur initial a clairement précisé que son système ne doit pas être transformé en système à haut risque, il n’est pas tenu de remettre la documentation. Une clause d’exclusion de ce type se rencontre dans les conditions d’utilisation de services d’IA généralistes : elle se lit avant la mise en production, pas après la requalification.

Le paragraphe 3 vise le fabricant d’un produit relevant de la législation d’harmonisation de l’annexe I, section A (machines, dispositifs médicaux, jouets, etc.) : il est considéré comme fournisseur quand le système à haut risque est un composant de sécurité de ce produit, mis sur le marché ou en service sous son nom.

Le paragraphe 4 impose un accord écrit entre le fournisseur d’un système à haut risque et le tiers qui fournit des outils, services, composants ou processus intégrés au système. L’accord précise les informations, capacités, accès technique et assistance nécessaires. L’obligation ne s’applique pas aux tiers qui publient sous licence libre et ouverte des outils ou composants autres que des modèles d’IA à usage général. Le Bureau de l’IA peut élaborer des clauses types volontaires. Les considérants 83 à 86 et 88 éclairent l’ensemble.

L’omnibus numérique (règlement (UE) 2026/1744, en vigueur depuis le 27 juillet 2026) n’a pas modifié la rédaction de l’article 25 : l’extension proposée des devoirs de coopération aux fournisseurs de modèles d’IA à usage général n’a pas été retenue. Pour les dates d’application des obligations à haut risque, la référence est le calendrier de l’AI Act.

Ce que l’article 25 ne couvre pas : modèles d’IA à usage général et systèmes hors haut risque

L’article 25 ne joue que pour les systèmes à haut risque. Un déployeur qui rebaptise un chatbot de support client ne devient pas fournisseur au titre de l’article 25 ; il peut en revanche être fournisseur par l’article 3 directement (il a fait développer et met en service sous son nom), avec les obligations de transparence de l’article 50 qui en découlent.

Le cas de l’affinage d’un modèle d’IA à usage général (GPAI, General-Purpose AI) relève d’un autre mécanisme. Les considérants 97 et 109 envisagent qu’une modification ou un affinage fasse de son auteur le fournisseur du modèle modifié, avec des obligations limitées à cette modification. Les lignes directrices de la Commission sur les modèles à usage général, publiées en juillet 2025, retiennent un critère indicatif fondé sur la part que représente le calcul de l’affinage par rapport au calcul d’entraînement du modèle d’origine. Ce critère est indicatif et révisable : le consulter dans sa version en vigueur avant toute conclusion, plutôt que de recopier un seuil lu sur une slide.

Ce que la qualification de rôle ne garantit pas non plus :

aucune sécurité : être fournisseur conforme n’implique ni robustesse aux injections de prompt, ni étanchéité des données ; ces garanties viennent de l’architecture (voir guardrails programmatiques) ;
aucune conformité RGPD (Règlement général sur la protection des données) : le rôle AI Act et le rôle responsable de traitement ou sous-traitant se déterminent séparément, et un même acteur peut être déployeur au sens de l’un et responsable de traitement au sens de l’autre ;
aucune opposabilité du contrat à l’autorité sur la qualification elle-même : le contrat répartit des tâches, il ne réécrit pas la définition de l’article 3.

La qualification d’une situation donnée (tel produit, tel contrat, telle intégration) relève d’un juriste ; cette page donne la grille de lecture et renvoie au texte officiel.

Prérequis et surface d’attaque de la qualification des rôles

Ce qui doit exister avant de qualifier

Aucune qualification n’est possible sans trois artefacts :

Un inventaire des systèmes d’IA par usage, pas par licence. Un même service SaaS (Software as a Service) peut alimenter un résumé de réunion et un tri de candidatures ; seul le second relève de l’annexe III, point 4.
Une classification au regard de l’article 6 pour chaque usage, y compris l’examen de la dérogation de l’article 6, paragraphe 3, documentée par écrit.
Les contrats amont (conditions d’utilisation, clauses d’exclusion d’usage à haut risque, accès à la documentation technique). Sans eux, impossible de savoir si le paragraphe 2 de l’article 25 jouera en cas de requalification. La grille d’évaluation d’un fournisseur d’IA générative et les points de contrat et DPA (Data Processing Agreement) fournissent la matière.

Les vecteurs de requalification involontaire

Traiter la requalification comme une surface d’attaque n’est pas une coquetterie : elle s’exploite par accident, de l’intérieur, et sans laisser de trace dans les outils de sécurité.

Le détournement d’usage par prompt. Un assistant généraliste reçoit un prompt système qui le transforme en évaluateur de solvabilité. Cas c, sans déploiement, sans ticket de changement. Contre-mesure : faire entrer les prompts système et les intégrations métier dans le processus de gestion des changements, avec une question obligatoire sur la destination. La politique d’usage de l’IA générative doit lister les usages annexe III interdits sans revue préalable.
Le shadow AI. Une équipe branche un outil public sur un processus RH (ressources humaines). L’organisation devient déployeur, voire fournisseur, d’un système qu’aucun inventaire ne connaît. Contre-mesure : détection côté proxy et identité, décrite dans shadow AI et assistants publics.
Le réentraînement non prédéterminé. Une boucle de réapprentissage ajoutée après l’évaluation initiale, ou un changement de jeu de données, constitue une modification substantielle. Contre-mesure : versionner le modèle, le jeu d’entraînement et le plan de changements prédéterminés ; tout écart hors plan déclenche une revue.
La marque blanche contractuelle. Une offre revendue « sous notre marque » fait basculer le revendeur en cas a. Contre-mesure : revue juridique systématique des offres en co-branding portant sur un usage annexe III.
Le changement silencieux en amont. Le fournisseur d’origine remplace le modèle sous-jacent d’une API. Pour le déployeur, rien ne change contractuellement ; pour la conformité d’un système à haut risque construit dessus, tout peut changer. Contre-mesure : épingler les versions de modèle quand l’API le permet et surveiller les annonces de dépréciation.

La version plaquette de la « gouvernance de l’IA » tient en un comité trimestriel ; la version qui résiste à un contrôle commence par savoir quel prompt système tourne en production, ce qui n’a jamais rempli un stand de salon.

Exploitation : rôles, journaux et déclencheurs de revue

La qualification n’est pas un livrable ponctuel. Elle se maintient comme un référentiel de configuration.

Registre des rôles : pour chaque couple (système, usage), le rôle tenu, la base de classification, le contrat amont et la date de dernière revue. Le stocker à côté de l’inventaire des actifs, pas dans un dossier juridique que l’équipe d’exploitation ne voit jamais.
Déclencheurs de revue : nouvelle intégration métier, modification du prompt système, réentraînement ou affinage, changement de marque ou de canal de vente, changement de modèle amont, changement de clause contractuelle. Chacun doit poser la question « cas a, b ou c ? ».
Conservation : un fournisseur de système à haut risque conserve la documentation technique et la déclaration de conformité pendant dix ans après la mise sur le marché (art. 18) ; un déployeur conserve les journaux générés automatiquement au moins six mois (art. 26, paragraphe 6), sauf disposition contraire. Une requalification en cas b ou c fait passer l’organisation du second régime au premier, avec l’archivage qui va avec.
Supervision : journaliser les appels aux systèmes classés, avec l’identité de l’appelant, la version du modèle et la version du prompt système. Sans ces trois champs, impossible de démontrer après coup quel système tournait, pour quelle destination. Le détail côté outillage figure dans observabilité des LLM en production.
Coopération amont : vérifier avant la requalification, pas après, que le fournisseur d’origine fournira documentation et accès technique ; une clause d’exclusion d’usage à haut risque signifie qu’il faudra tout reconstruire seul.

Le coût d’une sanction cadre le sujet : le non-respect des obligations des opérateurs (dont celles de l’article 16) expose à une amende administrative pouvant atteindre 15 millions d’euros ou 3 % du chiffre d’affaires annuel mondial, le montant le plus élevé étant retenu (art. 99, paragraphe 4) ; pour une PME, c’est le moins élevé des deux qui s’applique (art. 99, paragraphe 6).

Exemple : trois requalifications passées au crible de l’article 25

Trois situations typiques du côté architecture, lues avec la grille de l’article 25. Le schéma ci-dessous est l’arbre de décision : on part du tiers et on descend jusqu’au rôle final ; les crochets portent les conditions.

L’ESN qui revend un outil de tri de CV sous sa marque. Une ESN (entreprise de services du numérique) acquiert une licence d’un moteur de présélection de candidatures, le rebaptise et le vend à ses clients. Le tri de CV (curriculum vitae) relève de l’annexe III, point 4, a). Cas a : l’ESN devient fournisseur, avec système de gestion de la qualité, documentation technique, évaluation de conformité, marquage CE et enregistrement. Le contrat avec l’éditeur peut répartir le travail ; il ne retire pas le nom de l’ESN de l’étiquette.

L’équipe qui détourne un assistant généraliste vers le scoring de crédit. Une équipe produit branche un assistant d’IA générative sur les dossiers clients et lui demande une recommandation d’octroi. L’évaluation de solvabilité des personnes physiques relève de l’annexe III, point 5, b) (la détection de fraude financière en est exclue). Cas c : l’organisation devient fournisseur d’un système à haut risque construit sur un système d’usage général. Si les conditions du fournisseur de l’assistant excluent l’usage à haut risque, le paragraphe 2 le dispense de remettre sa documentation : la conformité devra se bâtir sans la documentation du modèle sous-jacent, ce qui peut conduire à abandonner le projet ou à changer de modèle.

L’intégrateur qui réentraîne un système de détection biométrique. Un intégrateur reçoit un système d’identification biométrique à distance déjà évalué, puis le réentraîne sur de nouvelles données pour améliorer ses performances sur un site. Les systèmes d’identification biométrique à distance relèvent de l’annexe III, point 1, a) (la simple vérification d’identité en un contre un en est exclue). Si ce réentraînement ne figurait pas dans le plan de changements prédéterminés, c’est une modification substantielle : cas b, nouvelle évaluation de conformité, et l’intégrateur devient fournisseur. Certains usages de l’identification biométrique en temps réel relèvent en outre des pratiques interdites de l’article 5, à examiner avant même la question du rôle.

Dans les trois cas, la position à retenir est la même : le compromis central de l’article 25 oppose la vitesse de mise en marché (revendre, ajuster, réorienter sans repasser par le fournisseur d’origine) à l’héritage complet de l’article 16. Pour un usage annexe III, la recommandation est de ne pas accepter la requalification par défaut : soit le fournisseur d’origine prend en charge l’usage visé et le documente, soit l’organisation décide en connaissance de cause de devenir fournisseur et budgète le système de gestion de la qualité. Le choix entre les deux dépend d’une seule question : la documentation technique amont est-elle accessible ? Si non, la voie « devenir fournisseur » coûte une reconstruction complète.

FAQ

Un contrat peut-il empêcher la requalification en fournisseur ?

Non pour les cas b et c, qui découlent de faits techniques (modification, destination). Pour le cas a, le texte réserve une « autre répartition des obligations » par contrat, ce qui organise le partage des tâches sans effacer le nom apposé sur le produit. La portée exacte d’une clause donnée se fait valider par un juriste.

Le fournisseur initial reste-t-il responsable après la requalification ?

Il cesse d’être fournisseur du système modifié ou réorienté, mais reste tenu de coopérer (informations, accès technique, assistance), sauf s’il avait clairement exclu la transformation en système à haut risque. Il reste fournisseur de son produit d’origine.

Un développement purement interne échappe-t-il au rôle de fournisseur ?

Non. La mise en service pour usage propre (art. 3, point 11) suffit : une organisation qui développe ou fait développer un système à haut risque et l’utilise en interne sous son nom en est le fournisseur et le déployeur à la fois.

🐝 Ce qui arrive si on s’en passe

Sans registre des rôles ni déclencheurs de revue, un prompt système modifié ou un réentraînement hors plan fait basculer l’organisation en fournisseur sans qu’aucune instance ne l’enregistre. Elle porte alors les obligations de l’article 16 sans documentation technique, sans évaluation de conformité et sans journaux exploitables, et découvre l’écart au moment où une autorité demande le dossier. La coopération du fournisseur d’origine, si elle était due, n’a jamais été demandée en temps utile ; si une clause d’exclusion existait, la documentation amont est perdue d’avance. Les journaux qui auraient prouvé quelle version servait quelle destination n’existent pas, ce qui interdit de démontrer après coup qu’un usage n’était pas à haut risque.

🦫 Explication de la marmotte 🍫

La loi européenne sur l’intelligence artificielle donne un rôle à chaque acteur. Le fournisseur fabrique un logiciel d’intelligence artificielle, ou le fait fabriquer, puis le propose sous son nom. Le déployeur l’utilise pour son travail. L’importateur fait entrer dans l’Europe un logiciel venu d’un autre pays. Le distributeur le revend. Le mandataire représente en Europe un fournisseur installé ailleurs. Chaque rôle a ses devoirs, et ceux du fournisseur sont les plus lourds : prouver que le logiciel respecte les règles, écrire sa documentation, la garder dix ans, vérifier avant de le vendre que le logiciel respecte les règles.

Ces devoirs deviennent très exigeants quand le logiciel sert à des décisions graves sur des personnes : choisir un candidat à un emploi, accorder un prêt, reconnaître quelqu’un à son visage. La loi parle alors de système « à haut risque ».

L’article 25 dit qu’un revendeur ou un utilisateur devient fournisseur dans trois cas : il vend ce logiciel sous son propre nom, il le transforme profondément sans que ce changement ait été prévu au départ, ou il l’emploie pour une décision grave alors qu’il n’était pas fait pour ça. À cet instant, tous les devoirs du fournisseur lui tombent dessus. Le fabricant d’origine doit l’aider en partageant ses documents, sauf s’il avait écrit clairement que son logiciel ne devait pas servir à ce genre d’usage. Quand personne ne remarque ce changement de rôle, l’entreprise se retrouve sans dossier le jour d’un contrôle, et l’amende peut atteindre 15 millions d’euros.

Pages voisines

La citent

AI Act : fournisseur, déployeur, importateur et requalification en fournisseur

Elle cite

: les deux pages se citent l’une l’autre.

AI Act : fournisseur, déployeur, importateur et requalification en fournisseur

AI Act : fournisseur, déployeur, importateur et requalification en fournisseur

Les rôles d’opérateur définis à l’article 3 de l’AI Act

Requalification en fournisseur : les trois cas de l’article 25

Ce que l’article 25 ne couvre pas : modèles d’IA à usage général et systèmes hors haut risque

Prérequis et surface d’attaque de la qualification des rôles

Ce qui doit exister avant de qualifier

Les vecteurs de requalification involontaire

Exploitation : rôles, journaux et déclencheurs de revue

Exemple : trois requalifications passées au crible de l’article 25

FAQ

Un contrat peut-il empêcher la requalification en fournisseur ?

Le fournisseur initial reste-t-il responsable après la requalification ?

Un développement purement interne échappe-t-il au rôle de fournisseur ?

🐝 Ce qui arrive si on s’en passe

🦫 Explication de la marmotte 🍫

À lire aussi

Pages voisines