Fournisseur, déployeur, ou les deux ?
Avant la classification, une question détermine vos obligations : quel est votre rôle au sens de l'Acte ?
Fournisseur
Vous développez un système d'IA et le mettez à disposition — soit comme produit, soit comme service embarqué dans votre plateforme SaaS. Vous êtes responsable de la conception du système, de son entraînement, de sa documentation technique et de sa conformité.
Une entreprise SaaS qui construit un moteur de tri de CV et le vend à des services RH est fournisseur d'un système d'IA à haut risque.
Déployeur
Vous intégrez un système d'IA construit par quelqu'un d'autre dans votre produit ou vos flux de travail. Vous êtes responsable de son utilisation — vous assurer qu'il est utilisé conformément à sa destination, que les utilisateurs sont informés, et qu'une supervision humaine est en place.
Une entreprise SaaS qui intègre une API de scoring de crédit tierce dans sa plateforme est déployeur d'un système d'IA à haut risque.
Les deux
Si vous construisez des fonctionnalités IA sur un modèle fondation (un modèle GPAI) et les exposez à des utilisateurs finaux, vous êtes simultanément déployeur du modèle GPAI et fournisseur du système d'IA en aval.
Une entreprise SaaS qui construit une fonctionnalité d'analyse de contrats utilisant une API LLM et la vend à des cabinets juridiques est à la fois déployeur (du LLM) et fournisseur (du système d'analyse de contrats).
Cette distinction importe parce que les fournisseurs et les déployeurs ont des obligations différentes — et dans la plupart des architectures SaaS, vous êtes les deux simultanément pour différentes parties de votre stack.
Profil 1 — SaaS RH : recrutement, performance et gestion des effectifs
Le domaine 4 de l'Annexe III couvre les systèmes d'IA utilisés dans l'emploi, la gestion des travailleurs et l'accès au travail indépendant. Il est délibérément large. Si votre plateforme SaaS inclut l'une des fonctionnalités IA suivantes, la présomption de haut risque s'applique :
- →Tri de CV ou classement de candidats
- →Présélection ou rejet automatisé de candidats
- →Outils d'évaluation d'entretien (y compris analyse vidéo)
- →Évaluation de la performance ou scoring des employés
- →Allocation de tâches, surveillance du travail ou scoring de productivité
- →Systèmes de recommandation de promotion ou de licenciement
La présomption peut être réfutée en vertu de l'Article 6(3) — mais uniquement si le système effectue une tâche procédurale étroite, n'influence pas matériellement les résultats et ne profile pas les individus. En pratique, la plupart des fonctionnalités IA RH ne satisfont pas ce seuil. Un système qui classe les candidats influence le résultat de l'embauche. Un système qui score la performance influence les décisions de promotion ou de licenciement.
Ce que beaucoup d'entreprises SaaS RH négligent : l'obligation s'applique même si un humain prend la décision finale. L'Acte n'exige pas que l'IA décide de manière autonome. Il exige que le système d'IA influence matériellement le processus de décision — et c'est précisément ce pour quoi la plupart des fonctionnalités IA RH sont conçues.
Obligations en cas de haut risque (fournisseur)
Système de gestion des risques
Documenter les risques connus et prévisibles du système — y compris les risques de biais sur les caractéristiques protégées. Ce n'est pas une évaluation ponctuelle.
Gouvernance des données
Les données d'entraînement doivent être suffisamment représentatives des populations que le système évaluera. Des tests de biais sur l'âge, le genre et l'origine ethnique sont requis.
Transparence envers les déployeurs
Vos clients SaaS RH (les employeurs) sont des déployeurs. Vous devez leur fournir des instructions d'utilisation couvrant les limitations, la finalité prévue et les conditions nécessitant une supervision humaine.
Conception pour la supervision humaine
Le système doit être conçu de sorte que les déployeurs puissent effectivement surveiller, outrepasser et corriger ses sorties. Un bouton 'revoir toutes les décisions IA' n'est pas suffisant — la conception doit rendre la supervision genuinement faisable.
Obligations des déployeurs (pour vos clients)
Vos clients SaaS, en tant que déployeurs, doivent réaliser une évaluation de l'impact sur les droits fondamentaux avant utilisation, surveiller le système en fonctionnement et journaliser son utilisation. Vous devriez les informer de ces obligations contractuellement.
Profil 2 — SaaS finance et assurance : crédit, risque et éligibilité
Le domaine 5 couvre les systèmes d'IA utilisés pour évaluer la solvabilité, fixer les primes d'assurance ou déterminer l'accès aux services essentiels — y compris les prestations sociales, les services d'urgence et l'aide sociale.
Déclencheurs haut risque dans les SaaS finance :
- →Scoring de crédit ou évaluation de la solvabilité
- →Recommandations d'approbation ou de rejet de prêt
- →Calcul de primes d'assurance basé sur des profils de risque individuels
- →Détection de fraude affectant l'accès individuel aux comptes
- →Systèmes KYC (Know Your Customer) prenant des décisions d'éligibilité
- →Évaluations d'adéquation d'investissement
Le domaine est défini par les conséquences pour l'individu, et non par la sophistication technique du système. Un modèle de scoring basé sur des règles qui produit une décision de crédit est soumis au domaine 5 au même titre qu'un réseau de neurones faisant la même chose — si le résultat affecte matériellement l'accès aux services financiers.
La nuance B2B
De nombreuses entreprises SaaS finance vendent à des banques et institutions financières, pas directement aux consommateurs. Cela ne supprime pas l'obligation — cela la distribue. En tant que fournisseur, vous devez toujours la documentation technique, la gestion des risques et la conception de supervision à vos clients B2B. Vos clients, en tant que déployeurs, doivent les évaluations de conformité et l'enregistrement dans la base de données UE. La relation contractuelle entre vous et vos clients doit refléter explicitement cette répartition des responsabilités — l'Acte ne permet pas qu'elle reste implicite.
Une clarification introduite par la proposition Digital Omnibus (pas encore en vigueur au mars 2026) : l'utilisation des données personnelles en IA pour les évaluations de solvabilité est explicitement abordée, alignant les obligations de l'AI Act avec les protections de l'Article 22 RGPD sur la prise de décision automatisée. Les DPO des SaaS finance devraient suivre cela attentivement.
Obligations en cas de haut risque (fournisseur)
Gestion des risques
Inclut la documentation du risque de résultats discriminatoires — un modèle de crédit qui désavantage systématiquement un groupe protégé est un risque prévisible qui doit être traité, pas seulement noté.
Documentation technique
Doit couvrir l'architecture, la méthodologie d'entraînement, les indicateurs de performance sur les sous-groupes démographiques, les limitations connues et la portée d'utilisation prévue. Doit être tenue à jour.
Évaluation de la conformité
Auto-évaluation pour la plupart des systèmes du domaine 5. Doit être réalisée avant la mise sur le marché. Documenter l'évaluation — elle doit être disponible pour les autorités de surveillance du marché sur demande.
Enregistrement dans la base de données UE
Les systèmes à haut risque doivent être enregistrés avant déploiement. L'enregistrement est public. Il requiert le nom du système, la finalité prévue, les coordonnées du fournisseur et un résumé de l'évaluation de conformité.
Profil 3 — SaaS B2B avec moteurs de scoring et de recommandation
C'est le profil le plus courant et le plus mal compris. Les entreprises SaaS construisant des moteurs de scoring et de recommandation supposent souvent qu'elles ne sont pas réglementées parce que leur sortie est 'juste une suggestion.' L'EU AI Act n'accepte pas cette interprétation.
La classification dépend de trois variables : le domaine dans lequel le système opère, qui est scoré ou classé, et si la sortie influence matériellement une décision conséquente affectant une personne physique.
Matrice de classification pour les moteurs de scoring :
| Usage | Domaine | Classification |
|---|---|---|
| Recommandation de produit (e-commerce) | Aucun domaine réglementé | Risque minimal — aucune obligation |
| Classement de contenu (plateforme média) | Aucun domaine réglementé | Risque minimal — aucune obligation |
| Lead scoring (outil de vente B2B) | Aucun domaine réglementé | Risque minimal — aucune obligation |
| Scoring de candidats (outil RH) | Annexe III, Domaine 4 | Présumé haut risque |
| Scoring de solvabilité client | Annexe III, Domaine 5 | Présumé haut risque |
| Scoring de risque pour assurance | Annexe III, Domaine 5 | Présumé haut risque |
| Scoring de performance étudiante | Annexe III, Domaine 3 | Présumé haut risque |
| Scoring de risque fournisseur (procurement) | Aucun domaine réglementé | Risque minimal — aucune obligation |
L'insight central : la même architecture technique — un modèle de scoring qui classe des entités — produit des résultats réglementaires entièrement différents selon le domaine. Un modèle de scoring fournisseur et un modèle de scoring candidat peuvent être techniquement identiques. Réglementairement, ils ne le sont pas.
Le piège du profilage
L'Article 6(3) offre une échappatoire à la classification haut risque pour les systèmes de l'Annexe III qui ne 'profilent pas les individus' — défini comme le traitement automatisé de données personnelles pour évaluer des aspects de la vie d'une personne tels que la performance, la situation économique, la santé, les préférences ou le comportement. Si votre moteur de scoring traite des données personnelles pour classer ou évaluer des individus dans un domaine réglementé, il les profile presque certainement au sens de l'Acte. L'exception ne s'applique pas.
Profil 4 — SaaS avec chatbots et IA générative
Les entreprises SaaS intégrant de l'IA générative — qu'il s'agisse d'un chatbot orienté client, d'un outil de génération de documents ou d'un assistant IA — font face à deux couches réglementaires distinctes qui opèrent indépendamment du cadre de classification haut risque.
Couche 1 — Article 50 : Transparence (en vigueur au 2 août 2026)
Les chatbots doivent divulguer leur nature IA
Tout système d'IA conçu pour interagir avec des personnes physiques doit informer ces personnes qu'elles interagissent avec une IA — clairement, au début de l'interaction. La seule exception est lorsque c'est évident dans le contexte. Un chatbot de support client sur une plateforme SaaS n'est pas 'évident dans le contexte.' La divulgation est requise.
Le contenu généré par IA doit être étiqueté
Si votre SaaS génère des contenus audio, vidéo ou image synthétiques, ceux-ci doivent être étiquetés comme générés par IA dans un format lisible par machine. Cela s'applique aux fonctionnalités de génération de documents, de synthèse vocale et de création d'images. La génération de texte à des fins d'information sur des sujets d'intérêt public nécessite également un étiquetage.
Les fonctionnalités de reconnaissance des émotions nécessitent une notification
Si votre SaaS inclut une fonctionnalité qui infère des états émotionnels à partir des entrées utilisateur — analyse de ton, scoring de sentiment appliqué à des individus — les utilisateurs doivent être notifiés lorsqu'un tel système est actif.
Couche 2 — Obligations GPAI (en vigueur au 2 août 2025)
Si vous intégrez un modèle GPAI (une API LLM telle que GPT-4, Claude, Gemini ou un équivalent open-source) dans votre produit SaaS, vous êtes déployeur de ce modèle GPAI. Vos obligations en tant que déployeur sont définies à l'Article 26 et dépendent de la classification de risque du système en aval que vous construisez.
Votre système en aval peut hériter de la classification haut risque
Si vous construisez une fonctionnalité alimentée par GPAI qui opère dans un domaine de l'Annexe III — par exemple, un assistant IA qui aide les responsables RH à évaluer des candidats — le système en aval peut être classifié comme haut risque, indépendamment du modèle sous-jacent. Le fait que le modèle soit à usage général ne rend pas l'application à risque minimal.
Vous ne pouvez pas externaliser contractuellement les obligations du fournisseur
Certaines entreprises SaaS supposent que, parce qu'elles utilisent une API, le fournisseur du modèle (OpenAI, Anthropic, Google) porte toutes les obligations. C'est incorrect. En tant que fournisseur de l'application en aval, vous portez les obligations associées à la classification de cette application. Le fournisseur du modèle GPAI porte les obligations pour le modèle. Les deux ensembles d'obligations coexistent simultanément.
Les conditions d'utilisation des fournisseurs GPAI ne valent pas conformité
Accepter les politiques d'utilisation d'une API LLM n'équivaut pas à réaliser une évaluation de conformité au titre de l'EU AI Act. Si le système que vous construisez est à haut risque, vous devez une évaluation de conformité sur ce système — pas sur le modèle sous-jacent.
La question à laquelle chaque entreprise SaaS doit répondre
La classification au titre de l'EU AI Act n'est pas évidente. Elle nécessite de répondre à une séquence spécifique de questions — la même séquence que le framework 6 gates formalise :
Une fonctionnalité de votre produit utilise-t-elle un système d'IA qui pratique des pratiques interdites au titre de l'Article 5 ? (Manipulation subliminale, notation sociale, identification biométrique en temps réel, etc.)
Un système d'IA de votre produit est-il un composant de sécurité d'un produit réglementé par l'Annexe I ? (Dispositifs médicaux, machines, véhicules, aviation.)
Un système d'IA de votre produit tombe-t-il dans l'un des 8 domaines de l'Annexe III ? (Biométrie, infrastructure, éducation, emploi, services essentiels, répression, migration, justice.)
Un modèle d'IA que vous développez ou déployez se qualifie-t-il comme modèle GPAI à risque systémique au titre de l'Article 51 ? (Seuil de calcul d'entraînement de 10²⁵ FLOPs.)
Une fonctionnalité IA orientée client nécessite-t-elle une divulgation de transparence au titre de l'Article 50 ? (Chatbots, contenu synthétique, reconnaissance des émotions.)
Fournissez-vous ou déployez-vous un modèle GPAI, déclenchant les obligations de l'Article 53 ?
Un 'non' aux Gates 1 à 4 avec un 'oui' au Gate 5 signifie aucune obligation haut risque mais des obligations de transparence actives. Un 'oui' au Gate 3 signifie des obligations haut risque indépendamment de vos réponses aux Gates 5 et 6. Les gates ne sont pas des alternatives — elles sont cumulatives. Plusieurs gates peuvent se déclencher simultanément.
Ce que 'risque minimal' signifie réellement
La plupart des fonctionnalités IA SaaS tombent genuinement dans la catégorie du risque minimal ou nul — recherche assistée par IA, recommandation de produit, filtrage de spam, automatisation de base. Pour celles-ci, l'EU AI Act n'impose aucune obligation obligatoire. Des codes de conduite volontaires existent mais ne sont pas requis.
Cependant, 'risque minimal' est une conclusion qui doit découler de la classification, et non une hypothèse formulée avant celle-ci. L'échec de conformité le plus courant dans les SaaS n'est pas de construire des systèmes à haut risque sans garde-fous — c'est de construire des systèmes à haut risque tout en supposant un risque minimal parce que la fonctionnalité 'ne fait que des suggestions.'
L'Acte évalue les conséquences, pas les intentions.
Évaluez votre stack SaaS avec le framework 6 gates
L'évaluation gratuite Sprinkling Act parcourt les six gates réglementaires — Article 5, Article 6, Annexe III, Articles 50–53 — et produit une notation en étoiles, un score et une piste d'audit traçable. 9 questions, résultat instantané. Le résultat n'est pas un conseil juridique. C'est une classification défendable, mappée article par article, que vous pouvez présenter à votre équipe juridique, votre conseil ou vos investisseurs.
Établir votre position →Sources
- [1]EUR-Lex (July 12, 2024) — Regulation (EU) 2024/1689 — Artificial Intelligence Act (full text) eur-lex.europa.eu/eli
- [2]EU AI Act — Article 3 — Definitions (Provider, Deployer, AI System) artificialintelligenceact.eu/article
- [3]EU AI Act — Article 6 — Classification Rules for High-Risk AI Systems artificialintelligenceact.eu/article
- [4]
- [5]EU AI Act — Article 26 — Obligations of Deployers of High-Risk AI Systems artificialintelligenceact.eu/article
- [6]
- [7]EU AI Act — Article 53 — Obligations for Providers of General-Purpose AI Models artificialintelligenceact.eu/article
- [8]EU AI Act — Annex III — High-Risk AI Systems Referred to in Article 6(2) artificialintelligenceact.eu/annex
Les interdictions Art. 5 et les règles GPAI s’appliquent aujourd’hui. La transparence suit dans 105 jours. La question n’est pas quand — c’est si vous avez documenté votre position.