Règlement européen sur l'IA (AI Act) pour les entreprises SaaS : fournisseur, déployeur ou les deux ?

Fournisseur ou déployeur : la qualification qui définit vos obligations¶

Le règlement européen sur l'IA établit des cadres de conformité fondamentalement différents pour les fournisseurs et les déployeurs. Comprendre quel rôle occupe votre entreprise SaaS - et à quel moment cette qualification peut basculer - constitue la première étape essentielle de toute planification de conformité.

Un fournisseur au sens de l'article 3(3) est toute entité qui développe un système d'IA (ou le fait développer) et le met sur le marché ou le met en service sous son propre nom ou sa propre marque, à titre onéreux ou gratuit. Un déployeur au sens de l'article 3(4) est toute entité qui utilise un système d'IA sous sa propre autorité à des fins professionnelles. Pour les entreprises SaaS, cela signifie généralement que l'éditeur est le fournisseur et que le client est le déployeur.

Le facteur décisif est le nom ou la marque qui apparaît sur le système d'IA. Une entreprise SaaS qui propose un outil de recrutement fondé sur l'IA sous sa propre marque est sans ambiguïté un fournisseur, tandis que le service RH qui achète et utilise cet outil est un déployeur. Cela reste vrai même lorsque l'entreprise SaaS intègre des modèles d'IA tiers comme GPT-4 ou Claude - encapsuler une API et la proposer sous votre marque fait de vous le fournisseur de ce système d'IA.

Plusieurs scénarios peuvent brouiller ou déplacer ces qualifications. Les accords en marque blanche sont particulièrement significatifs : en vertu de l'article 25(1)(a), si un client appose son propre nom ou sa propre marque sur un système d'IA à haut risque déjà mis sur le marché, il devient le fournisseur et hérite de toutes les obligations correspondantes. Les modifications substantielles constituent un autre déclencheur - l'article 3(23) les définit comme des modifications non prévues lors de l'évaluation initiale de la conformité, qui nuisent à la conformité du système ou modifient sa finalité prévue.

Le fine-tuning et la personnalisation présentent des cas limites plus nuancés. Le simple ajout de données propres ou l'ajustement d'hyperparamètres ne constitue généralement pas une modification substantielle - les clients restent déployeurs. En revanche, si un client réentraîne significativement un modèle, en altère fondamentalement les capacités ou utilise un système qui n'est pas à haut risque pour une finalité à haut risque, il peut être réputé fournisseur au titre de l'article 25. Les éditeurs SaaS doivent traiter explicitement ces scénarios dans leurs contrats pour prévenir toute ambiguïté.

Classification à haut risque : quand vos fonctionnalités SaaS déclenchent la conformité complète¶

Le règlement européen sur l'IA repose sur un cadre réglementaire fondé sur les risques, dans lequel les systèmes d'IA à haut risque sont soumis aux exigences les plus strictes. L'article 6 établit deux voies de classification à haut risque : les composants de sécurité de produits réglementés (annexe I) et les cas d'usage spécifiques énumérés à l'annexe III.

L'article 6(3) prévoit des exceptions - les systèmes de l'annexe III ne sont pas à haut risque s'ils accomplissent une tâche procédurale étroite, améliorent le résultat d'une activité humaine préalablement réalisée, détectent des schémas de prise de décision sans se substituer à l'évaluation humaine, ou exécutent une tâche préparatoire. Toutefois, les systèmes qui effectuent un profilage de personnes physiques sont toujours à haut risque, indépendamment de ces exceptions.

Les éditeurs SaaS doivent mener une analyse de classification rigoureuse pour chaque fonctionnalité d'IA. Un chatbot généraliste de service client relève du risque limité et n'est soumis qu'à des obligations de transparence. Un moteur de recommandation relève généralement du risque minimal. Mais dès que cette même technologie est appliquée au filtrage de candidats ou à l'évaluation de la solvabilité, elle devient à haut risque et soumise à l'ensemble des exigences de conformité. C'est la finalité prévue - et non la technologie sous-jacente - qui détermine la classification.

• Emploi et gestion de la main-d'œuvre (catégorie 4) : IA utilisée pour le recrutement, le filtrage des candidats, les offres d'emploi ciblées, les décisions relatives à l'emploi, la répartition des tâches et le suivi des performances
• Accès aux services essentiels (catégorie 5) : notation de crédit, évaluation de la solvabilité, évaluation des risques et tarification en assurance vie et santé
• Éducation (catégorie 3) : IA déterminant l'admission, évaluant les acquis d'apprentissage, évaluant le niveau d'éducation, surveillant le comportement des étudiants pendant les examens
• Biométrie (catégorie 1) : identification biométrique à distance, catégorisation biométrique et systèmes de reconnaissance des émotions, lorsqu'ils sont autorisés

Obligations des fournisseurs : le cadre de conformité complet pour l'IA à haut risque¶

Les fournisseurs de systèmes d'IA à haut risque font face à un cadre réglementaire complet couvrant les exigences préalables à la mise sur le marché, l'évaluation de la conformité et les obligations continues après commercialisation. Pour les entreprises SaaS, ces exigences doivent être intégrées dès le départ aux processus de développement produit.

L'article 9 impose un système de gestion des risques continu et itératif tout au long du cycle de vie de l'IA. Les fournisseurs doivent identifier et analyser les risques connus et prévisibles, estimer et évaluer les risques liés à l'utilisation prévue et aux mauvaises utilisations raisonnablement prévisibles, mettre en œuvre des mesures d'atténuation appropriées et documenter les risques résiduels.

L'article 10 établit des exigences de gouvernance des données pour les systèmes entraînés avec des données. Les jeux de données d'entraînement, de validation et de test doivent être pertinents, représentatifs et, dans la mesure du possible, exempts d'erreurs. Les fournisseurs doivent documenter la provenance des données, mettre en place des mécanismes de détection et de correction des biais, et établir des pratiques appropriées pour le traitement des catégories particulières de données à caractère personnel utilisées uniquement à des fins de détection des biais.

Exigences de documentation technique au titre de l'annexe IV¶

L'annexe IV précise des exigences de documentation complètes directement applicables aux produits SaaS. La documentation doit couvrir la description générale (finalité prévue, identification du fournisseur, historique des versions, toutes les formes de mise sur le marché y compris les API, configuration matérielle requise et description des interfaces utilisateur), le processus de développement (spécifications de conception, architecture du système, ressources de calcul utilisées, principaux choix de conception et leur justification) et les exigences relatives aux données (méthodologies d'entraînement, description et provenance des jeux de données, méthodes d'acquisition des données, procédures d'étiquetage).

Pour les systèmes SaaS mis à jour en continu, la documentation des modifications prédéterminées est déterminante - une documentation détaillée de toutes les modifications anticipées et des solutions techniques garantissant la conformité continue. Elle est essentielle pour éviter des évaluations de la conformité répétées. L'article 11 prévoit que les PME et les start-ups peuvent utiliser un formulaire simplifié de documentation technique établi par la Commission européenne.

• La documentation doit être conservée pendant 10 ans après la mise sur le marché du système
• Les tests et la validation doivent inclure des métriques d'exactitude, de robustesse et de conformité, avec des journaux de test datés et signés
• Les mesures de supervision humaine doivent être documentées conformément aux exigences de l'article 14
• Les modifications prédéterminées doivent être documentées pour éviter des évaluations de la conformité répétées

Voies d'évaluation de la conformité¶

L'article 43 établit deux voies d'évaluation de la conformité. Le contrôle interne (annexe VI) permet une auto-évaluation lorsque le fournisseur a appliqué des normes harmonisées ou des spécifications communes couvrant toutes les exigences pertinentes. L'évaluation par un tiers, réalisée par un organisme notifié (annexe VII), est obligatoire pour les systèmes d'identification biométrique à distance et les systèmes qui tirent des inférences sur des caractéristiques personnelles à partir de données biométriques, avec une certification valable quatre ans.

Pour les produits SaaS mis à jour en continu, l'article 43(4) offre une flexibilité essentielle : les modifications prédéterminées lors de l'évaluation initiale de la conformité et documentées dans les spécifications techniques ne constituent pas des modifications substantielles nécessitant une nouvelle évaluation. Cela permet aux systèmes à apprentissage continu de fonctionner sans évaluations répétées - à condition que les modifications aient été anticipées et documentées en amont.

Marquage CE : des badges de conformité numériques pour les produits logiciels¶

Les exigences de marquage CE s'appliquent aux systèmes d'IA à haut risque avant leur mise sur le marché. L'article 48(2) traite spécifiquement des SaaS et des produits numériques, en exigeant un marquage CE numérique facilement accessible via l'interface à partir de laquelle le système est accessible, via un code lisible par machine facilement accessible ou par tout autre moyen électronique.

La mise en œuvre pratique pour un SaaS consiste à afficher le marquage CE numérique dans l'interface du logiciel, à le rendre accessible via des codes lisibles par machine (codes QR ou points de terminaison d'API), ou à fournir d'autres moyens électroniques garantissant un accès facile. Le marquage doit être visible, lisible et permanent, et inclure le numéro d'identification de l'organisme notifié si une évaluation par un tiers a été réalisée.

Les fournisseurs doivent également établir une déclaration UE de conformité (article 47) pour chaque système d'IA, tenue à jour et à la disposition des autorités nationales pendant dix ans après la mise sur le marché. L'enregistrement dans la base de données de l'UE (articles 49 et 71) impose aux fournisseurs de s'enregistrer et d'enregistrer leurs systèmes d'IA à haut risque avant la mise sur le marché.

Surveillance après commercialisation et signalement des incidents¶

Les obligations du fournisseur se poursuivent tout au long du cycle de vie du système d'IA. L'article 72 exige un système de surveillance après commercialisation proportionné à la nature de la technologie et à ses risques. Ce système doit collecter, documenter et analyser activement et systématiquement les données de performance pendant toute la durée de vie du système, évaluer la conformité continue et analyser les interactions avec d'autres systèmes d'IA lorsque c'est pertinent.

Les exigences de journalisation de l'article 12 imposent que les systèmes à haut risque permettent techniquement l'enregistrement automatique des événements tout au long de leur durée de vie. Les journaux doivent permettre d'identifier les situations présentant un risque, de faciliter la surveillance après commercialisation et d'assurer la supervision par le déployeur. Les fournisseurs doivent conserver les journaux pendant six mois au minimum.

Le signalement des incidents (article 73) impose aux fournisseurs de signaler les incidents graves - définis comme un décès, une atteinte grave à la santé, des dommages aux biens, des dommages environnementaux, une perturbation d'infrastructures critiques ou une violation des droits fondamentaux - aux autorités de surveillance du marché. Le délai standard est de 15 jours après l'établissement du lien de causalité ; les incidents les plus graves, touchant la vie ou la santé, doivent être signalés sous deux jours.

Obligations des déployeurs et comment les fournisseurs SaaS doivent accompagner leurs clients¶

Si les déployeurs sont soumis à moins d'exigences réglementaires directes, les déployeurs de systèmes d'IA à haut risque assument des obligations significatives au titre de l'article 26. Les fournisseurs SaaS doivent rendre possible et accompagner la mise en conformité de leurs clients.

La supervision humaine constitue l'obligation centrale du déployeur. Les déployeurs doivent confier la supervision humaine à des personnes physiques disposant des compétences, de la formation, de l'autorité et du soutien nécessaires. Ces personnes doivent comprendre les capacités et les limites du système, rester conscientes du biais d'automatisation, interpréter correctement les sorties et conserver le pouvoir de passer outre ou d'interrompre le système. Pour les systèmes d'identification biométrique, une vérification par au moins deux personnes physiques est requise avant toute action.

La transparence envers les personnes concernées impose aux déployeurs de systèmes à haut risque qui prennent des décisions concernant des individus d'informer ces personnes de l'utilisation du système d'IA. En vertu de l'article 86, les personnes concernées ont le droit d'obtenir des explications claires et pertinentes sur le rôle du système d'IA et sur les principaux éléments de la décision.

Les analyses d'impact sur les droits fondamentaux (article 27) sont requises pour certains déployeurs : les organismes de droit public, les entités privées fournissant des services publics et tout déployeur utilisant une IA d'évaluation de la solvabilité ou des risques en assurance. La FRIA doit documenter les processus du déployeur, la durée et la fréquence d'utilisation, les catégories de personnes concernées, les risques spécifiques pour les droits fondamentaux, les mesures de supervision humaine et les actions d'atténuation des risques.

• Fournir des instructions d'utilisation complètes répondant aux exigences de l'article 13
• Permettre la supervision humaine grâce à une conception d'interface appropriée
• Donner accès aux journaux et fournir des outils d'interprétation
• Fournir la documentation technique nécessaire à l'AIPD
• Proposer une formation aux superviseurs humains et communiquer les métriques d'exactitude
• Mettre en place des canaux de signalement des incidents

Exigences contractuelles : ce que les contrats SaaS intégrant de l'IA doivent prévoir¶

L'article 13 prescrit les informations spécifiques que les fournisseurs doivent communiquer aux déployeurs. Les contrats SaaS doivent intégrer ces exigences de manière systématique, avec des clauses contractuelles claires couvrant chaque élément.

Les informations obligatoires comprennent l'identité et les coordonnées du fournisseur, la finalité prévue et les caractéristiques de performance détaillées, le niveau des métriques d'exactitude, de robustesse et de cybersécurité, les circonstances connues susceptibles d'entraîner des risques, les spécifications des données d'entrée, les caractéristiques attendues des sorties et les consignes d'interprétation, les modifications prédéterminées et leur incidence sur la conformité, les mesures de supervision humaine, les besoins en ressources de calcul, la durée de vie attendue et les mécanismes de journalisation.

Le cadre contractuel doit inclure des clauses de qualification claires confirmant le statut de fournisseur et de déployeur, des limitations du périmètre d'utilisation prévue assorties de clauses d'usages interdits explicites, des garanties du fournisseur quant à la conformité aux articles 9 à 15, des garanties du déployeur quant à la conformité à l'article 26, des obligations de partage d'informations, des exigences de coopération pour la surveillance après commercialisation et le signalement des incidents, ainsi que des motifs de résiliation en cas de manquement grave ou de changement de qualification.

IA à usage général : obligations supplémentaires lors de l'intégration de modèles de fondation¶

Les entreprises SaaS qui intègrent des modèles d'IA à usage général comme GPT-4, Claude ou Gemini sont confrontées à un cadre réglementaire spécifique. L'article 3(63) définit les modèles GPAI comme ceux qui présentent une généralité significative, sont capables d'exécuter un large éventail de tâches distinctes et peuvent être intégrés dans une variété de systèmes en aval.

Distinction essentielle : les entreprises SaaS qui intègrent des modèles GPAI sont généralement des fournisseurs de systèmes d'IA ou des fournisseurs en aval - et non des fournisseurs de modèles GPAI. Elles ne sont pas soumises aux obligations des articles 53 à 55 relatives aux modèles GPAI, qui incombent à OpenAI, Anthropic, Google et aux autres développeurs de modèles de fondation. Les entreprises SaaS doivent en revanche respecter les exigences applicables aux systèmes d'IA selon leur classification de risque.

Les fournisseurs de modèles GPAI doivent fournir une documentation permettant aux fournisseurs en aval de comprendre les capacités et les limites du modèle. En vertu de l'article 53(1)(b), les fournisseurs de GPAI peuvent être tenus de communiquer des informations complémentaires dans un délai de 14 jours à compter d'une demande pertinente pour l'intégration. Les modèles GPAI présentant un risque systémique - ceux entraînés avec une puissance de calcul cumulée supérieure à 10^25 FLOPS - sont soumis à des exigences supplémentaires, notamment des évaluations de modèle, des tests contradictoires et des protections en matière de cybersécurité.

Calendrier : les dates clés pour la planification de la conformité SaaS¶

En janvier 2026, plusieurs dispositions majeures sont déjà applicables, et les obligations de transparence de l'article 50 entrent en application le 2 août 2026.

Déjà en vigueur : les pratiques d'IA interdites (2 février 2025), dont la notation sociale, l'IA manipulatrice et la biométrie non autorisée. Les exigences de maîtrise de l'IA (2 février 2025), qui obligent les organisations à garantir un niveau suffisant de maîtrise de l'IA à leur personnel. Les obligations relatives aux modèles GPAI (2 août 2025) pour les fournisseurs de modèles de fondation. Les structures de gouvernance (2 août 2025), avec un régime de sanctions actif pouvant atteindre 35 millions d'euros ou 7 % du chiffre d'affaires mondial.

Le 2 août 2026, les obligations de transparence de l'article 50 deviennent applicables et le contrôle par les autorités nationales devient pleinement opérationnel. Le Digital Omnibus sur l'IA, adopté le 29 juin 2026, fixe la date d'application de l'annexe III pour les systèmes à haut risque au 2 décembre 2027 et celle de l'annexe I pour les systèmes intégrés dans des produits au 2 août 2028.

• 2 février 2025 : pratiques d'IA interdites applicables, avec les sanctions maximales
• 2 août 2025 : obligations relatives aux modèles GPAI en vigueur ; autorités nationales désignées
• 2 août 2026 : les obligations de transparence de l'article 50 s'appliquent aux fournisseurs et aux déployeurs
• 2 décembre 2026 : marquage lisible par machine exigé pour les systèmes génératifs déjà sur le marché ; deux nouvelles interdictions de l'article 5 s'appliquent
• 2 août 2027 : chaque État membre doit disposer d'au moins un bac à sable réglementaire de l'IA opérationnel (article 57)
• 2 décembre 2027 : entrée en application de l'ensemble des exigences relatives aux systèmes d'IA à haut risque de l'annexe III
• 2 août 2028 : les exigences s'appliquent à l'IA à haut risque intégrée dans des produits réglementés

Stratégies pratiques de conformité pour le développement SaaS¶

Intégrer les exigences du règlement européen sur l'IA au développement produit nécessite des cadres de gouvernance systématiques et une intégration dans les processus.

Priorités immédiates (T1 2026) : réaliser un inventaire des systèmes d'IA sur l'ensemble des produits et fonctionnalités, classer chaque système par catégorie de risque, identifier les responsabilités de fournisseur et de déployeur pour chaque scénario de déploiement, mener une analyse des écarts par rapport aux exigences applicables et évaluer la posture de conformité des fournisseurs d'IA tiers.

Construction des fondations (T1-T2 2026) : mettre en place un comité de gouvernance de l'IA avec des responsabilités claires, élaborer une politique d'IA alignée sur l'approche fondée sur les risques, déployer des programmes de formation à la maîtrise de l'IA, créer des modèles de documentation technique et d'évaluation des risques, et mettre à jour les conditions générales d'utilisation et les contrats SaaS avec les informations requises par l'article 13.

Conformité des systèmes à haut risque (T2-T3 2026) : mettre en œuvre les systèmes de gestion des risques de l'article 9, établir les procédures de gouvernance des données de l'article 10, rédiger la documentation technique de l'annexe IV, concevoir des mécanismes de supervision humaine conformes aux exigences de l'article 14, mettre en place les systèmes de journalisation de l'article 12 et se préparer à l'évaluation de la conformité.

Classification des cas d'usage : comment les fonctionnalités d'IA courantes des SaaS sont réglementées¶

Les chatbots de service client relèvent du risque limité et sont soumis aux obligations de transparence de l'article 50. Les utilisateurs doivent être informés qu'ils interagissent avec une IA, sauf si cela ressort clairement des circonstances. Aucune évaluation de la conformité ni documentation obligatoire n'est requise au-delà de l'obligation de transparence.

Les moteurs de recommandation relèvent généralement du risque minimal pour les recommandations de produits de base ou la personnalisation de contenu. Ils deviennent toutefois à haut risque s'ils servent au profilage de personnes pour des décisions d'emploi ou pour déterminer l'accès à des services essentiels.

L'IA de RH et de recrutement est explicitement à haut risque au titre de la catégorie 4 de l'annexe III. Cela couvre l'IA utilisée pour le recrutement et la sélection, le filtrage des candidats, les offres d'emploi ciblées, les décisions relatives à l'emploi, la répartition des tâches fondée sur le comportement individuel et le suivi des performances. L'ensemble des exigences de conformité s'applique.

Les outils d'évaluation du crédit et d'analyse financière sont explicitement à haut risque au titre de la catégorie 5 de l'annexe III pour l'évaluation de la solvabilité, la notation de crédit et l'évaluation des risques en assurance vie et santé. L'exception : l'IA utilisée uniquement pour détecter la fraude financière n'est pas à haut risque.