Déployeur ou fournisseur : pourquoi cette différence est cruciale dans l'EU AI Act

Pour beaucoup d’organisations, l’EU AI Act semble surtout viser les grandes entreprises technologiques qui développent elles-mêmes des systèmes d’IA. C’est une erreur. Dans la pratique, la plupart des organisations ne sont pas des fournisseurs d’IA, mais elles sont bel et bien des déployeurs. Et cela suffit déjà pour avoir des obligations légales concrètes.

Le problème, c’est que beaucoup d’organisations ne savent pas clairement quel rôle elles occupent. Pire encore : certaines pensent être simplement utilisatrices d’un outil acheté sur le marché, alors qu’elles ont déjà franchi sans le vouloir la frontière vers le rôle de fournisseur.

Cette distinction est essentielle. Elle détermine vos responsabilités, votre charge de conformité et, en cas de problème, votre exposition au risque.

Qu’est-ce qu’un déployeur ?

Dans l’EU AI Act, un déployeur est une organisation qui utilise un système d’IA dans un contexte professionnel. Le système peut avoir été développé par un autre acteur. Cela ne change rien au fait que vous avez des obligations dès que vous l’utilisez dans votre organisation.

Le seuil est bas. Dès qu’un système d’IA est utilisé dans votre organisation, vous entrez dans le champ des obligations applicables aux déployeurs.

Et il faut être très clair sur un point : cela vaut aussi pour les usages non autorisés. Si un collaborateur utilise la version gratuite de ChatGPT pour répondre à un client, votre organisation agit déjà comme déployeur — même si vous ne l’aviez pas validé en interne. Et si des données sont introduites dans un outil public, il ne s’agit pas seulement d’un sujet lié au rôle de déployeur : cela peut aussi devenir un problème GDPR.

C’est précisément là que se trouve l’angle mort de nombreuses PME et administrations locales : le shadow AI peut faire de vous un déployeur sans que vous en ayez réellement conscience.

Les obligations d’un déployeur

Les obligations du déployeur sont moins lourdes que celles du fournisseur, mais elles sont bien plus importantes que ce que beaucoup d’organisations imaginent.

### 1. Littératie en IA (article 4)

Vous devez veiller à ce que vos collaborateurs sachent ce qu’ils font lorsqu’ils utilisent l’IA. C’est l’obligation de base déjà en vigueur depuis le 2 février 2025.

### 2. Transparence (article 50)

Pour certains systèmes d’IA, les personnes concernées doivent être informées qu’un système d’IA est utilisé. Un candidat doit savoir si son CV est évalué par un outil d’IA. Un citoyen doit savoir qu’il interagit avec un chatbot et non avec une personne.

### 3. Supervision humaine (article 14)

Pour les usages à haut risque — recrutement, enseignement, soins, services publics — il doit toujours y avoir une intervention ou une capacité d’intervention humaine. La décision finale ne peut pas devenir une simple formalité automatisée.

### 4. Journalisation et surveillance (article 26)

Vous devez pouvoir retracer l’usage de vos systèmes d’IA et, en cas d’incident, démontrer ce qui s’est passé.

### 5. Évaluation des risques

Lorsqu’un système d’IA à haut risque est utilisé, vous devez évaluer si ce système est adapté à votre contexte concret et si les risques sont acceptables.

Quand devenez-vous fournisseur sans le vouloir ?

C’est ici que la situation devient réellement sensible. L’EU AI Act prévoit qu’une organisation peut passer du rôle de déployeur à celui de fournisseur lorsqu’elle modifie de manière substantielle un système d’IA existant.

Concrètement, ce basculement peut se produire dans plusieurs cas.

### Finetuning

Si vous effectuez un finetuning d’un modèle de langage sur vos propres données, vous pouvez être considéré comme fournisseur. La charge de conformité augmente alors très fortement.

### Mise sur le marché sous votre propre nom

Si vous commercialisez un système d’IA développé par un tiers sous votre propre nom, vous êtes considéré comme fournisseur, même si vous n’avez rien modifié sur le plan technique.

### Changement fondamental de finalité

Si vous utilisez un système d’IA pour une finalité fondamentalement différente de celle pour laquelle il a été conçu, vous pouvez également être considéré comme fournisseur.

C’est là que beaucoup d’organisations sous-estiment le risque. Elles pensent simplement adapter ou intégrer un outil existant, alors qu’en réalité elles se rapprochent d’un rôle beaucoup plus lourd sur le plan réglementaire.

Pourquoi cela compte autant

Parce que les obligations du fournisseur sont nettement plus lourdes. Le fournisseur porte la responsabilité principale de la conformité du système : documentation, exigences techniques, évaluation de conformité, enregistrement éventuel, gestion des risques, qualité des données, obligations de suivi, etc.

En d’autres termes : un déployeur doit encadrer un usage responsable. Un fournisseur doit démontrer la conformité du système lui-même.

La différence est énorme.

Les sanctions

L’EU AI Act prévoit un régime de sanctions par niveaux.

- En cas de non-respect de l’obligation de littératie en IA : jusqu’à 15 millions d’euros ou 3 % du chiffre d’affaires mondial annuel.

- En cas de non-respect des obligations applicables aux déployeurs dans les usages à haut risque : jusqu’à 15 millions d’euros ou 3 %.

- En cas de recours à des pratiques d’IA interdites : jusqu’à 35 millions d’euros ou 7 % du chiffre d’affaires mondial annuel.

À titre de comparaison, le GDPR prévoit un plafond de 20 millions d’euros ou 4 %. L’EU AI Act peut donc aller encore plus loin.

Mais le montant de l’amende n’est pas le seul enjeu. La question de la responsabilité démontrable compte tout autant. Les autorités ne regarderont pas seulement ce qui s’est mal passé, mais aussi ce que votre organisation avait mis en place pour l’éviter. L’absence de formation à la littératie en IA est particulièrement difficile à défendre, parce qu’il s’agit d’une obligation claire, connue et relativement simple à organiser.

Ce que vous devez faire maintenant

### Étape 1 : déterminer votre rôle

Examinez vos systèmes d’IA un par un. Êtes-vous déployeur, fournisseur, ou parfois les deux selon le système ou l’usage ?

### Étape 2 : inventorier vos obligations

Si vous utilisez uniquement un système à risque minimal, vos obligations restent relativement limitées. Mais dès qu’un usage touche au haut risque, le niveau d’exigence augmente nettement.

### Étape 3 : vérifier que vous n’êtes pas devenu fournisseur sans le vouloir

Avez-vous modifié un système ? Effectué un finetuning ? Repositionné un outil sous votre propre nom ? Changé sa finalité initiale ? Il faut l’évaluer explicitement.

### Étape 4 : former vos collaborateurs

Vos administrateurs IT, en particulier, doivent comprendre la différence entre déployeur et fournisseur, et savoir à quel moment la frontière peut être franchie.

### Étape 5 : documenter et démontrer

La charge de la preuve repose sur l’organisation. Lors d’un audit, la question ne sera pas : « y avez-vous pensé ? » mais : « pouvez-vous démontrer ce que vous avez mis en place ? »

Un aperçu clair des formations suivies, avec des certificats par collaborateur mentionnant les acquis évalués et les thèmes couverts par l’EU AI Act, reste l’un des moyens les plus concrets de démontrer que vous avez pris vos obligations au sérieux.

En conclusion

L’EU AI Act n’a pas été conçu pour freiner l’innovation. Il a été conçu pour faire en sorte que l’IA soit utilisée de manière sûre, responsable et traçable.

En tant que déployeur, vous ne devez pas paniquer. Mais vous devez savoir quel est votre rôle, quelles obligations en découlent, et à partir de quel moment vous basculez vers un rôle plus lourd.

La différence entre une organisation qui comprend cela et une organisation qui l’ignore peut littéralement se chiffrer en millions.