AI Act : obligations pratiques pour les SaaS B2B en 2024-2025

# AI Act : obligations pratiques pour les SaaS B2B en 2024-2025

85 % des éditeurs SaaS européens intègrent aujourd'hui au moins une fonctionnalité d'IA dans leur produit (Gartner, 2024) — et la quasi-totalité d'entre eux sous-estiment l'impact du règlement européen sur l'intelligence artificielle, officiellement publié au Journal officiel de l'UE le 12 juillet 2024. Avec des amendes pouvant atteindre 35 millions d'euros ou 7 % du chiffre d'affaires mondial, l'AI Act n'est pas un signal réglementaire de plus : c'est une contrainte opérationnelle majeure qui redessine les roadmaps produit, les architectures techniques et les processus de go-to-market de milliers d'entreprises B2B. Tour d'horizon des obligations concrètes, section par section.

Comprendre la logique de l'AI Act : une approche par le risque

!Professionnels analysant les obligations réglementaires de l'AI Act dans un environnement tech Photo: ALEXANDRE LALLEMAND / Unsplash

L'AI Act adopte une architecture réglementaire fondée sur quatre niveaux de risque, chacun entraînant des obligations proportionnées. Cette logique pyramidale est essentielle à maîtriser avant toute analyse produit.

Risque inacceptable (interdit) : systèmes de notation sociale générale, manipulation subliminale, exploitation des vulnérabilités, reconnaissance faciale en temps réel dans l'espace public (hors exceptions strictes). Ces usages sont interdits à partir d'août 2025.

Risque élevé (High-Risk) : c'est le cœur de la réglementation pour les SaaS B2B. Sont concernés les systèmes d'IA utilisés dans le recrutement et l'évaluation des employés, le scoring de crédit, l'évaluation de solvabilité, les systèmes de contrôle de l'accès à l'éducation, les outils d'aide à la décision médicale, les systèmes de gestion des infrastructures critiques, et les systèmes d'IA à usage des forces de l'ordre ou de la justice.

Risque limité : chatbots, deepfakes, systèmes génératifs. Des obligations de transparence s'appliquent (informer l'utilisateur qu'il interagit avec une IA).

Risque minimal : filtres anti-spam, recommandations de contenu, jeux vidéo. Quasi aucune obligation spécifique.

La difficulté pour les éditeurs SaaS : un même produit peut naviguer entre plusieurs niveaux selon l'usage client final. Un outil RH intégrant un module de scoring de candidats bascule automatiquement en High-Risk, quand bien même son cœur de fonctionnalité (ATS, gestion des offres) resterait en risque minimal.

Calendrier de mise en conformité : ce qui est déjà actif

L'AI Act n'est pas une échéance lointaine. Le règlement suit un calendrier en plusieurs vagues qu'il faut intégrer dès maintenant dans les feuilles de route.

• Août 2024 : Entrée en vigueur du règlement (20 jours après publication au JO)
• Février 2025 : Interdictions des pratiques à risque inacceptable applicables
• Août 2025 : Obligations relatives aux modèles d'IA à usage général (GPAI) et aux systèmes High-Risk relevant de l'Annexe I (infrastructures critiques, sécurité)
• Août 2026 : Pleine application pour la majorité des systèmes High-Risk (Annexe III)
• Août 2027 : Application aux systèmes d'IA embarqués dans des produits déjà couverts par d'autres réglementations (dispositifs médicaux, jouets, etc.)

Pour un éditeur SaaS B2B ciblant le marché RH, fintech ou medtech, l'horizon opérationnel réel est août 2026, soit moins de 24 mois. C'est court pour refondre une architecture de données, former les équipes, établir une documentation de conformité et passer les audits.

Obligations concrètes pour les systèmes à haut risque

Si votre SaaS tombe dans la catégorie High-Risk (Annexe III), voici les 7 obligations principales que le règlement impose aux providers (fournisseurs qui mettent le système sur le marché) :

1. Système de gestion des risques (Article 9) Vous devez documenter, tout au long du cycle de vie du produit, un processus continu d'identification, d'analyse et de mitigation des risques liés à votre système d'IA. Ce n'est pas un audit annuel : c'est un processus vivant, intégré à votre SDLC.

2. Gouvernance des données d'entraînement (Article 10) Les datasets utilisés pour entraîner, valider et tester vos modèles doivent respecter des critères de pertinence, représentativité, absence de biais et qualité. Vous devez pouvoir **documenter la provenance, la composition et les pratiques de nettoyage** de vos données.

3. Documentation technique (Article 11 + Annexe IV) Une documentation technique exhaustive doit être maintenue à jour : description du système, des données, de l'architecture, des performances, des mesures de robustesse et cybersécurité. Elle doit être accessible aux autorités nationales sur demande.

4. Journalisation et traçabilité (Article 12) Les systèmes High-Risk doivent générer des **logs automatiques** permettant de retracer les décisions du système sur une période définie. Pour les SaaS B2B, cela implique des choix d'architecture non triviaux (immutabilité des logs, durée de rétention, accès client).

5. Transparence envers les déployeurs (Article 13) Vous devez fournir à vos clients B2B (les "deployers" dans la terminologie de l'AI Act) une **notice d'utilisation claire**, incluant les capacités et limites du système, les conditions d'utilisation pour lesquelles il a été conçu, et les mesures de supervision humaine requises.

6. Supervision humaine (Article 14) Le système doit être conçu pour permettre aux utilisateurs finaux d'exercer une supervision effective : possibilité d'ignorer, de surmonter ou d'interrompre les décisions du système. Le **"human-in-the-loop"** devient une contrainte de design, pas une option UX.

7. Exactitude, robustesse et cybersécurité (Article 15) Des niveaux de performance minimaux doivent être atteints et documentés. La résilience aux attaques adversariales (prompt injection, data poisoning) entre dans le scope réglementaire.

Coût estimé de la conformité : selon une étude du CEPS (Centre for European Policy Studies, 2023), la mise en conformité d'un système High-Risk coûterait entre 6 000 et 7 500 € pour une PME et jusqu'à 400 000 € pour une grande entreprise, sans compter les coûts récurrents de maintenance documentaire.

Cas concrets : quels SaaS B2B sont dans le viseur ?

Pour rendre ces obligations tangibles, voici une analyse de plusieurs verticales SaaS fréquentes :

SaaS RH & Recrutement (ex : Workday, Lever, Teamtailor) Tout module de scoring de CV, de ranking automatique de candidats ou de prédiction de performance tombe en High-Risk (Annexe III, section 4). Les éditeurs doivent prévoir une documentation des biais de leurs modèles, des tests de discrimination (genre, origine, âge) et une interface permettant au recruteur de comprendre et de contester les scores. Workday fait déjà l'objet d'un audit volontaire depuis 2023.

SaaS Fintech & Credit Scoring (ex : Pennylane, Defacto) Les outils d'évaluation de solvabilité ou de scoring de crédit pour les entreprises (B2B credit) relèvent de l'Annexe III, section 5. La traçabilité des décisions de refus ou d'octroi de financement devient obligatoire, avec obligation d'explication compréhensible.

SaaS Santé & MedTech (ex : Doctolib, Owkin) Les systèmes d'aide au diagnostic ou de recommandation thérapeutique combinent AI Act et Règlement sur les Dispositifs Médicaux (MDR). Double contrainte réglementaire, double documentation. Owkin, qui développe des modèles d'IA pour la recherche clinique, a anticipé en structurant son programme de conformité dès 2023.

SaaS Legal & Compliance (ex : Doctrine, Jus Mundi) Les outils d'aide à la décision judiciaire ou quasi-judiciaire sont listés en Annexe III, section 8. Les plateformes d'analyse juridique assistée par IA doivent documenter la supervision humaine et les limitations du système.

SaaS Marketing & Sales (ex : Salesforce Einstein, HubSpot AI) La plupart des fonctionnalités de recommandation, scoring de leads ou personnalisation marketing tombent en risque limité ou minimal. Principal enjeu : les obligations de transparence sur les chatbots et contenus générés par IA (watermarking pour les deepfakes, mention "généré par IA").

Obligations spécifiques pour les modèles GPAI (GPT-like)

L'AI Act introduit une catégorie nouvelle : les General Purpose AI Models (GPAI), qui correspondent aux grands modèles de langage et de génération (LLM, modèles image, etc.). Si votre SaaS développe ou fine-tune ses propres modèles fondationnels (plutôt que de consommer des API tierces comme OpenAI), des obligations supplémentaires s'appliquent dès août 2025 :

• Transparence sur les données d'entraînement : publication d'un résumé des contenus utilisés pour l'entraînement (en lien avec la directive droit d'auteur)
• Politique de respect du droit d'auteur et mécanisme d'opt-out pour les titulaires de droits
• Évaluation des risques systémiques pour les modèles dépassant 10^25 FLOPs d'entraînement (seuil des modèles "à impact systémique" comme GPT-4 ou Gemini Ultra)

Pour la majorité des SaaS B2B qui consomment des API (OpenAI, Anthropic, Mistral), la responsabilité GPAI incombe principalement au fournisseur du modèle, mais le SaaS reste responsable de son usage applicatif. La chaîne de responsabilité est contractuelle : vérifiez vos conditions d'utilisation avec vos fournisseurs de modèles.

Checklist stratégique : par où commencer ?

Face à la complexité du texte (113 articles, 13 annexes, 180 considérants), voici une approche pragmatique en 5 étapes pour les éditeurs SaaS B2B :

Étape 1 — Cartographie IA : inventoriez toutes les fonctionnalités IA de votre produit (propres et tierces). Classificez chaque feature selon les 4 niveaux de risque. Cet exercice révèle souvent des surprises dans les modules périphériques.

Étape 2 — Analyse des cas d'usage clients : votre produit peut être en risque minimal, mais si vos clients l'utilisent dans un contexte High-Risk (recrutement, crédit), c'est leur responsabilité première — mais vous devez les informer via votre documentation technique.

Étape 3 — Gap analysis documentaire : comparez votre documentation technique actuelle aux exigences de l'Annexe IV. Le delta est souvent conséquent.

Étape 4 — Roadmap technique : intégrez les obligations de logging, de supervision humaine et de robustesse dans votre backlog produit. Priorisez selon le calendrier réglementaire.

Étape 5 — Contrats et supply chain IA : revisez vos CGU, DPA (Data Processing Agreements) et contrats avec vos fournisseurs de modèles pour clarifier les responsabilités selon la chaîne provider/deployer de l'AI Act.

Conclusion : conformité ou avantage concurrentiel ?

L'AI Act impose une charge réglementaire réelle. Mais les éditeurs SaaS qui anticipent intelligemment peuvent transformer la conformité en différenciateur commercial. Sur un marché B2B où les acheteurs entreprises — notamment dans les secteurs régulés (banque, assurance, santé, RH) — deviennent hypersensibles aux risques de gouvernance IA, une certification de conformité AI Act devient un argument de vente tangible.

Les éditeurs américains (Salesforce, Workday, Microsoft) l'ont compris : ils investissent massivement dans la conformité européenne non par contrainte, mais pour protéger leur accès à un marché de 450 millions de consommateurs et établir un standard mondial de confiance. Pour les scale-ups européennes, c'est l'opportunité de construire un avantage natif que leurs concurrents extra-européens mettront des années à répliquer.

La question n'est plus "faut-il se conformer ?" mais "comment transformer la conformité en accélérateur de croissance ?"

— Équipe éditoriale InekIA