Le règlement (UE) 2024/1689 n'impose pas les mêmes obligations à celui qui développe un système d'IA et à celui qui l'utilise. L'écart n'est pas marginal : il se compte en ordres de grandeur de charge documentaire. C'est donc la première question à trancher, et celle sur laquelle se concentrent la plupart des erreurs d'auto-évaluation — en particulier chez les éditeurs de logiciels qui intègrent un modèle tiers dans un produit vendu sous leur marque.
Deux définitions, un critère
L'article 3, point 3, définit le fournisseur comme la personne physique ou morale qui développe ou fait développer un système d'IA ou un modèle d'IA à usage général et 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.
L'article 3, point 4, définit le déployeur comme la personne physique ou morale utilisant sous sa propre autorité un système d'IA, sauf lorsque ce système est utilisé dans le cadre d'une activité personnelle à caractère non professionnel.
Le critère discriminant est le nom sous lequel le système est mis à disposition, non l'auteur du code. Une entreprise qui n'écrit pas une ligne de code peut être fournisseur si elle diffuse sous sa marque un système développé par un tiers. À l'inverse, une entreprise qui développe un outil strictement pour son usage interne met le système en service, ce qui la place également du côté du fournisseur pour cet outil — une lecture que beaucoup de directions informatiques n'anticipent pas.
La gratuité n'est pas exonératoire : le texte mentionne explicitement la mise à disposition à titre gratuit.
Les trois situations de basculement de l'article 25
L'article 25, paragraphe 1, énumère les cas dans lesquels un distributeur, un importateur, un déployeur ou tout autre tiers est considéré comme fournisseur d'un système à haut risque et se voit soumis aux obligations de l'article 16.
Le premier cas est l'apposition du nom ou de la marque sur un système à haut risque déjà mis sur le marché ou en service, sans préjudice des arrangements contractuels prévoyant une autre répartition des obligations.
Le deuxième cas est la modification substantielle apportée à un système à haut risque déjà mis sur le marché ou en service, de telle manière qu'il reste un système à haut risque.
Le troisième cas est la modification de la destination d'un système d'IA, y compris un système à usage général, qui n'était pas classé comme à haut risque et est déjà mis sur le marché ou en service, de telle manière que le système concerné devient un système à haut risque.
La notion de modification substantielle est définie à l'article 3, point 23 : une modification apportée après la mise sur le marché ou en service, non prévue ni planifiée dans l'évaluation initiale de la conformité, qui affecte la conformité du système aux exigences applicables ou entraîne une modification de la destination.
Point de vigilance
Les trois cas de l'article 25 ne se déclenchent qu'en présence d'un système à haut risque, ou d'un système qui le devient. Apposer sa marque sur un chatbot de support relevant du seul article 50 ne fait pas basculer vers le statut de fournisseur au titre de l'article 25 — mais transfère bien la charge des obligations de transparence du paragraphe 2, qui pèsent sur le fournisseur du système.
Le cas le plus fréquent : l'éditeur qui intègre un modèle tiers
La configuration se répète d'un dossier à l'autre. Un éditeur français propose un logiciel métier. Il y ajoute une fonction d'analyse ou de recommandation en appelant l'interface d'un modèle à usage général fourni par un tiers. La fonction est vendue sous sa marque, dans son produit, à ses clients.
Cet éditeur est fournisseur du système d'IA qu'il met sur le marché, quelle que soit l'origine du modèle sous-jacent. Le fournisseur du modèle à usage général conserve ses propres obligations, prévues au chapitre V et applicables depuis le 2 août 2025, mais elles ne se substituent pas à celles de l'éditeur.
Le point qui décide de la charge réelle est ensuite la destination du système ainsi construit. Si la fonction relève de l'annexe III — évaluation de candidats, scoring de solvabilité, priorisation d'accès à un service essentiel — l'éditeur devient fournisseur d'un système à haut risque et hérite du chapitre III, section 2 : système de gestion des risques de l'article 9, gouvernance des données de l'article 10, documentation technique de l'article 11, enregistrements de l'article 12, transparence et notice d'utilisation de l'article 13, contrôle humain de l'article 14, exactitude, robustesse et cybersécurité de l'article 15. S'y ajoutent le système de gestion de la qualité de l'article 17, l'évaluation de la conformité de l'article 43, la déclaration UE de conformité de l'article 47, le marquage CE de l'article 48 et l'enregistrement de l'article 49.
Si la fonction ne relève pas de l'annexe III, la charge se limite pour l'essentiel aux obligations de transparence de l'article 50 et à l'article 4.
L'écart entre les deux scénarios est tel qu'il justifie de traiter la question de la destination comme une décision produit, en amont, et non comme une question de conformité, en aval.
Personnalisation, réglage fin, changement de finalité
Trois opérations courantes sont régulièrement mal qualifiées.
Le paramétrage d'un outil dans les limites prévues par l'éditeur — choix d'options, réglage de seuils documentés, personnalisation de l'interface — ne constitue pas une modification substantielle. L'évaluation initiale de la conformité les a par hypothèse prévus.
Le réglage fin d'un modèle sur des données propres est plus délicat. Il ne conduit pas mécaniquement au statut de fournisseur de système à haut risque : tout dépend de l'effet sur la conformité et sur la destination. En revanche, il déplace la charge de la preuve, puisque le comportement du système ne découle plus seulement de ce que l'éditeur a documenté.
Le changement de finalité est le cas le plus net. Utiliser un système de classement documentaire généraliste pour trier des candidatures modifie la destination et fait entrer le système dans l'annexe III. C'est le troisième cas de l'article 25, et il se produit le plus souvent sans décision explicite, par extension progressive d'un usage.
Ce que le règlement organise entre les acteurs
L'article 25 ne se contente pas de désigner un responsable. Son paragraphe 2 prévoit que, dans les cas de basculement, le fournisseur initial n'est plus considéré comme fournisseur du système concerné, tout en restant tenu de coopérer étroitement, de fournir les informations nécessaires et de donner l'accès technique et l'assistance raisonnablement attendus, sauf s'il a clairement exclu la transformation de son système en système à haut risque.
Le paragraphe 4 impose au fournisseur d'un système ou d'un outil intégré à un système à haut risque de préciser par écrit, avec le fournisseur du système à haut risque, les informations, capacités et assistance nécessaires pour permettre à ce dernier de se conformer au règlement.
La conséquence pratique est contractuelle. La qualification des rôles, les engagements de fourniture de documentation et les conditions d'accès technique sont des clauses à négocier au moment de la contractualisation, pas des points à découvrir lors d'un contrôle.
Le cumul des rôles est la norme, pas l'exception
Une même organisation est fréquemment déployeur pour ses outils internes et fournisseur pour son produit commercialisé. Les deux analyses doivent être conduites séparément, système par système, et elles n'aboutissent pas nécessairement au même endroit.
Deux autres qualifications complètent le tableau, moins fréquentes mais réelles. L'importateur, défini à l'article 3, point 6, est établi dans l'Union et met sur le marché un système portant le nom d'une personne établie dans un pays tiers ; ses obligations figurent à l'article 23. Le distributeur, défini au point 7, met un système à disposition sans être fournisseur ni importateur ; ses obligations figurent à l'article 24. Une PME qui revend une solution étrangère sans y apposer sa marque relève de l'une de ces deux catégories, et non du régime du fournisseur.
Le test en quatre questions
Pour chaque système inscrit à l'inventaire, quatre questions suffisent à trancher dans la grande majorité des cas.
Le système est-il mis à disposition de tiers sous votre nom ou votre marque ? Si oui, vous êtes fournisseur pour ce système.
L'avez-vous développé, ou fait développer, pour votre usage propre ? Si oui, vous en êtes également fournisseur, en tant que personne qui met le système en service.
L'utilisez-vous sous votre autorité sans le rediffuser ? Si oui, vous êtes déployeur, et vos obligations relèvent de l'article 26 s'il s'agit d'un système à haut risque, de l'article 50 s'il relève de la transparence.
Avez-vous modifié sa destination ou son fonctionnement au-delà de ce que la notice prévoit ? Si oui, reprenez l'analyse depuis le début : l'article 25 peut avoir déplacé votre position.
La réponse doit être écrite, datée, et adossée à l'article invoqué. C'est ce document, et non la conclusion elle-même, qui a une valeur probante.
Avertissement
Cet article présente une lecture opérationnelle du règlement et ne constitue pas un conseil juridique. Amada Piedade intervient sur le volet méthodologique et documentaire de la conformité. En cas de doute sur la qualification d'un système, référez-vous au texte et aux articles cités.
Pour appliquer ce test à vos propres systèmes, le diagnostic AI Act en reprend la séquence, question par question.
Sources
Règlement (UE) 2024/1689 du 13 juin 2024, articles 3 (points 3, 4, 6, 7 et 23), 9 à 15, 16, 17, 23, 24, 25, 26, 43, 47, 48, 49 et 50, et annexe III — texte sur EUR-Lex.
Règlement (UE) 2026/1744 du 8 juillet 2026 modifiant le règlement (UE) 2024/1689, notamment le calendrier des obligations relatives aux systèmes à haut risque — texte au Journal officiel du 24 juillet 2026.
Commission européenne, lignes directrices sur la définition d'un système d'intelligence artificielle, 6 février 2025 — page de publication.