Les outils d'IA de codage relèvent-ils du règlement européen sur l'IA ?

Champ d'application, qualification des systèmes, rôles de fournisseur et de déployeur, obligations applicables et calendrier.

Champ d'application, qualification des systèmes, rôles de fournisseur et de déployeur, obligations applicables et calendrier.

Introduction

Le règlement européen sur l’intelligence artificielle structure désormais l’ensemble du domaine. Son application aux outils de développement suppose de distinguer plusieurs qualifications.

L’architecture du règlement

Il gradue les obligations selon le niveau de risque.

Certaines pratiques sont interdites.

Les systèmes à haut risque, limitativement définis, sont soumis à des obligations substantielles.

Certains systèmes sont soumis à des obligations de transparence.

Les modèles d’usage général font l’objet d’un régime propre, pesant sur leurs fournisseurs.

Les autres systèmes ne sont soumis qu’aux règles générales.

La qualification d’un outil d’assistance au codage

Il n’entre pas, par sa fonction, dans les domaines à haut risque limitativement énumérés, qui visent notamment la biométrie, les infrastructures critiques, l’éducation, l’emploi, l’accès aux services essentiels, la répression et la justice.

Il ne constitue pas davantage un composant de sécurité d’un produit soumis à une réglementation harmonisée.

Il n’est donc pas, en principe, un système à haut risque.

Cette qualification peut changer selon l’usage : un outil intégré à un système lui-même à haut risque suit le régime de ce système.

Les rôles

Le règlement distingue le fournisseur, qui développe ou fait développer un système et le met sur le marché ou en service sous son nom, et le déployeur, qui l’utilise sous sa propre autorité.

L’éditeur de l’outil est fournisseur.

L’entreprise qui l’utilise pour développer ses propres logiciels est déployeur, avec des obligations limitées pour les systèmes qui ne sont pas à haut risque.

Une entreprise qui intègre un modèle tiers dans son produit et le met à disposition sous son nom peut en revanche devenir fournisseur du système ainsi constitué, avec les obligations correspondantes.

Cette bascule est le point d’attention principal pour un éditeur de logiciel.

Les obligations de transparence

Les personnes interagissant avec un système d’intelligence artificielle doivent en être informées, lorsque cela n’est pas évident au regard des circonstances.

Les contenus générés ou manipulés doivent être identifiés comme tels, selon des modalités adaptées.

Ces obligations concernent le produit développé, lorsqu’il intègre des fonctions d’intelligence artificielle destinées aux utilisateurs, plus que l’outil ayant servi à le développer.

Les modèles d’usage général

Les fournisseurs de modèles d’usage général sont soumis à des obligations propres : documentation technique, information des fournisseurs en aval, politique de respect du droit d’auteur, résumé des données d’entraînement.

Ces obligations pèsent sur les éditeurs de modèles, non sur leurs utilisateurs.

Elles présentent toutefois un intérêt indirect : la documentation produite éclaire les conditions d’usage des productions.

Le calendrier

Le règlement se déploie par étapes, selon les catégories de systèmes et d’obligations.

Son calendrier a fait l’objet d’aménagements.

La vérification des échéances applicables à chaque catégorie doit intervenir au moment de la qualification, et non se déduire d’une lecture générale.

Ce qui pèse réellement sur un éditeur

La qualification de son propre produit, lorsqu’il intègre des fonctions d’intelligence artificielle.

Les obligations de transparence envers ses utilisateurs.

La qualification de fournisseur lorsqu’il met à disposition un système sous son nom.

Les obligations sectorielles, lorsque le produit est destiné à un domaine à haut risque.

L’usage d’outils pour développer, en tant que tel, ne crée pas d’obligation propre au titre du règlement.

L’articulation avec les autres corps de règles

Le règlement sur l’intelligence artificielle ne remplace ni le règlement sur la protection des données, ni les règles sur la propriété intellectuelle, ni le droit de la consommation.

Ces cadres se cumulent : la conformité à l’un ne vaut pas conformité aux autres.

Une décision automatisée relève ainsi simultanément du régime des décisions exclusivement automatisées prévu par le règlement sur la protection des données et des obligations du règlement sur l’intelligence artificielle.

La documentation

Une fiche par système intégré au produit : finalité, qualification, fournisseur du modèle, rôle de l’entreprise, données traitées, mesures de contrôle humain, information délivrée.

Cette documentation répond simultanément aux exigences réglementaires et aux questionnaires clients.

Qualifier son produit, pas ses outils

Ce qui déclenche les obligations est le produit livré, non la méthode employée. Notre expertise en intelligence artificielle conduit ces qualifications.

En résumé

  • Un outil d’assistance au codage n’est pas, par sa fonction, un système à haut risque.
  • Intégrer un modèle tiers sous son nom peut conférer la qualité de fournisseur.
  • Les obligations de transparence visent le produit livré, non l’outil de développement.
  • Le calendrier se déploie par étapes et a fait l’objet d’aménagements.
  • Les cadres se cumulent : la conformité à l’un ne vaut pas conformité aux autres.

Questions fréquentes

Un outil d'assistance au codage est-il à haut risque ?
Généralement non. Les systèmes à haut risque sont ceux relevant des domaines limitativement énumérés ou constituant un composant de sécurité d'un produit réglementé.
L'utilisateur a-t-il des obligations ?
Le déployeur d'un système à haut risque a des obligations propres. Pour les autres systèmes, les obligations sont principalement de transparence et pèsent sur le fournisseur.
Quand ces obligations s'appliquent-elles ?
Le règlement se déploie par étapes selon les catégories de systèmes et d'obligations, et son calendrier a fait l'objet d'aménagements.

Nous contacter :

Nous répondons volontiers à toutes vos questions. Écrivez-nous à mc@cabinetpersee.com , contactez le cabinet sur WhatsApp, ou remplissez notre formulaire de contact.

Articles associés

Autres analyses juridiques du cabinet

Un acquéreur peut-il refuser d'acheter un logiciel vibe-codé ?

Portrait de Matthieu Ciutti

Matthieu Ciutti

Associé fondateur

Quelle assurance couvre les risques du vibe-coding ?

Portrait de Matthieu Ciutti

Matthieu Ciutti

Associé fondateur

Qui est l'auteur d'un logiciel écrit à 90 % par une IA ?

Portrait de Matthieu Ciutti

Matthieu Ciutti

Associé fondateur

Peut-on breveter une fonctionnalité développée par vibe-coding ?

Portrait de Matthieu Ciutti

Matthieu Ciutti

Associé fondateur