L'IA Act de l'UE s'applique aux entreprises SaaS américaines dès ce mois d'août : Un guide pratique de conformité

Si vous fournissez un logiciel à un client à Berlin, Paris ou Amsterdam — et que votre produit utilise l'IA de quelque manière que ce soit — le 2 août 2026 est la date à cocher sur votre calendrier de conformité. C'est le jour où le Règlement (UE) 2024/1689, plus connu sous le nom de Règlement sur l'IA de l'UE, devient pleinement applicable pour les obligations de transparence, et où les pouvoirs d'exécution de la Commission sur les modèles d'IA à usage général entrent en vigueur. Les amendes peuvent atteindre 7 % du chiffre d'affaires annuel mondial. Et non, peu importe que votre siège social soit à San Francisco, que vos serveurs soient en Virginie et que votre équipe n'ait jamais mis les pieds à Bruxelles.

La plupart des fondateurs américains avec qui nous discutons ont un modèle mental du Règlement sur l'IA de l'UE emprunté au RGPD : quelques bannières de cookies, une mise à jour de la politique de confidentialité, peut-être un addenda relatif au traitement des données. Le Règlement sur l'IA est différent. Il réglemente le produit, pas seulement les données. Il attribue des obligations par rôle — fournisseur, déployeur, distributeur, importateur, représentant autorisé — et il impose des évaluations de conformité avant la mise sur le marché, une documentation technique, une surveillance après commercialisation et un enregistrement dans une base de données à l'échelle de l'UE avant qu'un système à haut risque puisse atteindre légalement un utilisateur européen. Les sanctions sont plus lourdes que celles du RGPD. Le rayon d'action des questionnaires de conformité lors des achats est plus large. Et la loi prévoit une portée extraterritoriale inscrite à l'Article 2.

Ce guide détaille ce que les entreprises SaaS américaines, les fournisseurs de modèles de fondation et les développeurs d'agents d'IA doivent réellement faire d'ici les prochaines échéances, à peu près dans l'ordre où vous devriez le faire.

Étape 1 : Déterminer si le Règlement s'applique à vous

Le champ d'application du Règlement est plus large que ce à quoi la plupart des fondateurs américains s'attendent. L'Article 2 concerne :

• Les fournisseurs mettant des systèmes d'IA sur le marché de l'UE ou les mettant en service dans l'UE, indépendamment de leur lieu d'établissement
• Les déployeurs (vos clients) situés dans l'UE
• Les fournisseurs et déployeurs situés en dehors de l'UE lorsque le résultat (output) du système d'IA est utilisé dans l'UE

Ce dernier point est le piège. Si votre système d'IA basé aux États-Unis traite une transcription, génère un e-mail marketing, évalue un CV ou résume un contrat, et que le résultat final est utilisé par un destinataire basé dans l'UE, vous êtes concerné, même si aucun Européen ne touche directement à votre API. Un fournisseur américain de technologies juridiques dont les résumés finissent dans le dossier d'un cabinet d'avocats néerlandais est concerné. Un outil de recrutement américain dont les classements de candidats sont examinés par un responsable de recrutement à Munich est concerné. Un chatbot américain intégré dans une application SaaS vendue à un client français est concerné.

Le filtre pratique pour la plupart des entreprises SaaS B2B est plus simple : si l'un de vos clients payants, ou les utilisateurs finaux de vos clients, se trouvent dans l'UE, supposez que le Règlement s'applique et travaillez à partir de là.

Étape 2 : Classifier votre rôle et le niveau de risque de votre système

Le Règlement attribue des obligations en fonction de ce que vous faites, et non du nom que vous vous donnez. La plupart des entreprises SaaS entrent simultanément dans l'une ou plusieurs de ces catégories :

• Fournisseur — vous mettez un système d'IA sur le marché sous votre propre nom ou marque commerciale. C'est le cas de presque tous les fournisseurs SaaS qui proposent des fonctionnalités d'IA.
• Déployeur — vous utilisez un système d'IA sous votre autorité (par exemple, vous utilisez un modèle tiers à l'intérieur de votre produit). Les déployeurs ont des obligations plus légères que les fournisseurs, mais elles sont réelles.
• Fournisseur de modèles d'IA à usage général — vous développez ou affinez un modèle de fondation capable d'être utilisé pour de nombreuses tâches. La plupart des entreprises SaaS américaines ne sont pas des fournisseurs de GPAI ; vous consommez les modèles GPAI de quelqu'un d'autre. Mais si vous affinez Llama ou construisez votre propre modèle de fondation, vous avez peut-être franchi la ligne.
• Représentant autorisé — requis pour les fournisseurs non-UE de systèmes à haut risque et de modèles GPAI (plus de détails ci-dessous).

La classification des risques est le second axe. Le Règlement crée quatre niveaux :

La plupart des produits SaaS B2B américains ayant ajouté une fonctionnalité d'IA à leurs flux de travail existants tombent dans la catégorie risque limité et sont soumis aux devoirs de transparence de l'Article 50. Les exceptions comptent : tout ce qui touche aux décisions d'emploi, aux admissions scolaires, à la solvabilité, à la biométrie ou aux services publics essentiels bascule dans le haut risque et représente une charge de travail nettement plus importante.

Étape Trois : Planifiez les échéances qui vous concernent

Les obligations de la Loi s'étalent sur trois ans. Voici la chronologie clarifiée telle qu'elle se présente :

• 2 février 2025 — Les pratiques d'IA interdites (Article 5) et les obligations de littératie en matière d'IA (Article 4) sont devenues exécutoires. Si votre produit met en œuvre l'une des pratiques interdites par l'Article 5, arrêtez. Dès aujourd'hui.
• 2 août 2025 — Les dispositions relatives à la gouvernance et les obligations pour les modèles d'IA à usage général (IAUG) sont entrées en vigueur. Les nouveaux modèles d'IAUG mis sur le marché après cette date doivent s'y conformer immédiatement. Les modèles existants avant cette date ont jusqu'au 2 août 2027.
• 2 août 2026 — L'échéance majeure. Les obligations de transparence de l'Article 50 deviennent exécutoires. Les obligations liées au haut risque au titre de l'Annexe III entrent en vigueur. Les pouvoirs d'exécution de la Commission sur les modèles d'IAUG, y compris la capacité d'émettre des amendes, sont activés. L'exigence de représentant autorisé au titre de l'Article 22 pour les fournisseurs de systèmes à haut risque hors UE devient opérationnelle.
• 2 août 2027 — Les modèles d'IAUG préexistants doivent atteindre une pleine conformité. Les systèmes à haut risque intégrés dans des produits déjà réglementés (jouets, dispositifs médicaux, machines) entrent dans le cadre de la Loi.
• 2 décembre 2027 — Les systèmes à haut risque déjà en service dans des catégories spécifiques de l'Annexe III (biométrie, infrastructures critiques, éducation, emploi, migration, asile, contrôle des frontières) doivent se mettre en conformité.
• 2 août 2028 — Les systèmes à haut risque intégrés dans les produits réglementés (ascenseurs, jouets, etc.) atteignent leur pleine application.

Pour une entreprise SaaS américaine typique fournissant un chatbot ou un assistant d'IA à des clients de l'UE, l'échéance pratique à court terme est le 2 août 2026 pour la transparence de l'Article 50. Pour les fournisseurs de modèles de fondation et les plateformes d'agents d'IA, la fenêtre d'exécution de l'IAUG s'ouvre ce même jour.

Étape Quatre : Effectuez les travaux de transparence de l'Article 50

Si votre produit se situe dans la catégorie de risque limité, c'est cette section qui importe le plus. L'Article 50 exige quatre divulgations spécifiques :

1. Divulgation pour les chatbots : Si une personne interagit avec un système d'IA, elle doit être informée qu'elle interagit avec une IA — sauf si cela est évident au vu du contexte. Le terme « évident » est sujet à interprétation. Une lecture prudente consiste à ajouter une divulgation explicite lors de la première interaction.
2. Marquage du contenu synthétique : Les images, contenus audio, vidéo ou textuels générés ou manipulés par IA doivent être marqués dans un format lisible par machine et détectables comme étant artificiels. Cela implique concrètement l'utilisation de filigranes (watermarking) ou de métadonnées de provenance (type C2PA).
3. Étiquetage des hypertruquages (deepfakes) : Les contenus constituant un hypertruquage doivent être étiquetés comme ayant été générés ou manipulés artificiellement.
4. Étiquetage des textes d'intérêt public : Les textes générés par IA et publiés pour informer le public sur des questions d'intérêt public doivent être signalés comme tels, à moins qu'ils n'aient fait l'objet d'une révision humaine avec responsabilité éditoriale.

La mise en place de cette couche de divulgation n'est pas techniquement difficile, mais elle nécessite une coordination entre les équipes produit, design et juridique. Quelques modèles que nous avons vus fonctionner :

• Un petit badge « assisté par IA » dans les interfaces de chat, avec une infobulle renvoyant vers une page de divulgation plus détaillée.
• Des métadonnées de provenance intégrées au moment de la génération, via la norme C2PA, pour tout contenu multimédia produit.
• Une bibliothèque de chaînes de caractères de divulgation approuvées, localisées dans toutes les langues de l'UE que votre produit dessert.
• Une politique interne stipulant que tout contenu d'« intérêt public » (résumés d'actualités, sujets politiques, informations de santé) passe par une révision éditoriale humaine et est consigné dans un journal.

Étape Cinq : Nommez un représentant autorisé dans l'UE (si nécessaire)

L'Article 22 exige des fournisseurs établis dans des pays tiers — y compris les États-Unis — qu'ils nomment, par mandat écrit, un représentant autorisé dans l'UE avant de mettre un système d'IA à haut risque sur le marché de l'Union. L'Article 54 impose une obligation similaire aux fournisseurs de modèles d'IAUG.

Si vous ne proposez que des systèmes à risque limité soumis aux obligations de transparence de l'Article 50, vous n'avez pas besoin d'un représentant au titre de l'Article 22. Si vous fournissez des systèmes à haut risque ou des modèles d'IAUG, c'est le cas — et en trouver un prend du temps. Les missions du représentant incluent :

• Vérifier que la déclaration UE de conformité et la documentation technique sont en place.
• Tenir la documentation à la disposition des autorités nationales compétentes pendant dix ans.
• Coopérer avec les autorités sur les mesures correctives, les retraits ou les rappels.
• Vous transmettre les plaintes, les rapports d'incidents et les notifications d'incidents graves.
• Mettre fin au mandat (et en informer les autorités) si vous ne respectez pas vos obligations.

Le représentant ne peut pas assumer vos obligations fondamentales de fournisseur au titre des Articles 9 à 17 — cette responsabilité vous incombe. Il est essentiellement votre présence responsable dans l'UE et votre point de contact pour le Bureau de l'IA et les autorités nationales de surveillance du marché.

Les tarifs des services de représentation autorisée se sont stabilisés entre 5 000 € et 25 000 € par an pour les petits fournisseurs, selon la complexité du système, le nombre d'États membres de l'UE desservis et l'étendue de la révision documentaire. Budgétisez cela de la même manière que pour un agent enregistré au Delaware.

Étape Six : Établissez l'ensemble documentaire

Que vous fournissiez un système à haut risque ou un modèle d'IAUG, vous devez fournir une trace documentaire. La Loi énumère plusieurs documents qui doivent exister et être tenus à jour :

• Documentation technique (Annexe IV pour les systèmes à haut risque, Annexe XI pour les modèles d'IAUG) — architecture du système, pratiques de gouvernance des données, méthodologie d'entraînement, résultats d'évaluation, limitations connues.
• Documentation du système de gestion des risques (Article 9) — identification des risques prévisibles, mesures d'atténuation, critères d'acceptation des risques résiduels.
• Documentation sur la gouvernance des données (Article 10) — sources des données d'entraînement, de validation et de test, critères de qualité des données, examen des biais.
• Registres de journalisation (logs) (Article 12) — journaux d'événements automatiques avec un détail suffisant pour permettre la surveillance après commercialisation.
• Conception de la supervision humaine (Article 14) — comment les opérateurs humains peuvent interpréter les sorties, intervenir, passer outre ou arrêter le système.
• Plan de surveillance après commercialisation (Article 72) — comment vous collecterez, analyserez et répondrez aux données de performance et aux incidents en conditions réelles.
• Déclaration UE de conformité (Article 47) — l'attestation juridique que votre système répond aux exigences de la Loi.
• Marquage CE — apposé sur le produit, indiquant la conformité.

Pour les fournisseurs d'IAUG, le Code de bonnes pratiques publié par le Bureau de l'IA en juillet 2025 est devenu la base de référence de facto en matière de conformité. Il est volontaire, mais y adhérer démontre une conformité de bonne foi et vous accorde un traitement favorable lors de toute évaluation ultérieure de l'application de la loi. Les trois chapitres du Code — Transparence, Droit d'auteur, et Sûreté et Sécurité — correspondent étroitement à ce que le Bureau de l'IA recherchera lorsqu'il commencera à exercer ses pouvoirs d'exécution en août 2026.

Étape sept : Anticipez la vague des questionnaires d'achat

Pour la plupart des entreprises SaaS américaines, la première manifestation concrète de la loi sur l'IA de l'UE (AI Act) ne sera pas une visite du Bureau de l'IA. Ce sera un questionnaire d'achat provenant de l'équipe juridique d'un client européen vous demandant quels modèles vous utilisez, sur quelles données d'entraînement ils ont été conçus, quels contrôles vous avez mis en place pour empêcher les utilisations interdites, à quoi ressemblent vos dispositions en matière de résidence des données et si vous avez un représentant au titre de l'article 22.

Ces questionnaires arrivent dès maintenant — bien avant la date de mise en application d'août 2026 — car les acheteurs de l'UE veulent s'assurer de la conformité de leurs fournisseurs avant l'échéance critique. Les cycles de vente s'allongent dans les secteurs réglementés (finance, santé, gouvernement, éducation) car les acheteurs ajoutent des vérifications spécifiques à la loi sur l'IA. Les fondateurs capables de répondre au questionnaire avec assurance dès la première semaine d'un cycle de vente concluront des contrats que leurs concurrents moins préparés perdront.

Constituez dès maintenant un dossier de référence sur la loi sur l'IA. Il doit comprendre :

• Un résumé d'une page sur votre rôle (fournisseur/déployeur/les deux), le niveau de risque et les obligations applicables
• Une liste des modèles sous-jacents que vous utilisez, avec les informations sur les sous-traitants et de type DPA
• Vos informations sur la transparence (Article 50)
• Votre documentation sur la gouvernance des données et les données d'entraînement, caviardée si nécessaire
• Votre procédure de réponse aux incidents et de signalement des incidents graves
• Une copie du mandat de votre représentant autorisé, le cas échéant

Comment le RGPD, le Data Act et le DSA s'articulent

La loi sur l'IA ne remplace pas le droit européen existant. Elle s'y superpose. Un système à haut risque qui traite des données à caractère personnel est réglementé à la fois par la loi sur l'IA et par le RGPD, et les obligations se cumulent. L'article 26, paragraphe 8, de la loi sur l'IA préserve explicitement l'exigence d'analyse d'impact relative à la protection des données (AIPD) du RGPD pour les déployeurs à haut risque. Les obligations de partage de données et de changement de fournisseur du Data Act s'appliquent parallèlement à la conformité à la loi sur l'IA. Les règles de transparence des systèmes de recommandation du Digital Services Act (DSA) s'ajoutent à l'article 50.

Concrètement, cela signifie que votre programme de conformité nécessite un registre intégré. Une seule fonctionnalité d'IA peut déclencher une AIPD au titre du RGPD, une évaluation des risques au titre de la loi sur l'IA, une divulgation au titre de l'article 50, un rapport de transparence sur le système de recommandation au titre du DSA et un engagement de portabilité au titre du Data Act. Traiter ces éléments comme des flux de travail distincts est la meilleure façon de commettre des erreurs. Les traiter comme un programme unique avec une documentation partagée est la meilleure façon de rester sain d'esprit.

À quoi ressemblent réellement les amendes

La structure des sanctions de la loi, prévue à l'article 99, comporte trois niveaux :

• Pratiques interdites (violations de l'article 5) : Jusqu'à 35 millions d'euros ou 7 % du chiffre d'affaires annuel mondial, le montant le plus élevé étant retenu.
• La plupart des autres obligations (Articles 8-15, Article 50, obligations GPAI sous l'Article 101) : Jusqu'à 15 millions d'euros ou 3 % du chiffre d'affaires annuel mondial, le montant le plus élevé étant retenu.
• Informations trompeuses aux autorités : Jusqu'à 7,5 millions d'euros ou 1 % du chiffre d'affaires annuel mondial, le montant le plus élevé étant retenu.

Pour les PME, y compris les startups, les amendes sont plafonnées au plus bas des deux chiffres plutôt qu'au plus élevé. C'est une concession réelle, mais 1 % du chiffre d'affaires reste un chiffre significatif pour une entreprise SaaS en série B, et la définition européenne d'une « PME » s'arrête à 50 millions d'euros de chiffre d'affaires — la plupart des entreprises SaaS américaines en phase de croissance dépassent ce seuil.

La première vague d'actions coercitives fin 2026 et 2027 visera probablement les fournisseurs les plus importants et les plus visibles — les laboratoires de modèles de base et les produits d'IA grand public à large audience. Mais les autorités nationales de surveillance du marché disposent d'un large pouvoir discrétionnaire, et les enquêtes déclenchées par des plaintes peuvent viser n'importe quel fournisseur. Planifiez pour le cas moyen, pas pour le pire des cas : vous ne serez probablement pas le premier mis à l'amende, mais vous ne voulez pas être le fondateur expliquant à un conseil d'administration pourquoi les revenus européens de la société sont désormais bloqués en attendant un plan d'action correctif.

Intégrez la conformité à l'ingénierie, pas à côté

Les équipes de conformité qui éprouvent le plus de difficultés avec la loi sur l'IA sont celles qui la traitent comme un exercice juridique greffé sur un produit fini. Les équipes qui s'en sortent proprement la traitent comme une contrainte de conception du système : la gouvernance des données intégrée à la couche de données, la journalisation intégrée à la couche d'inférence, la surveillance humaine intégrée à l'expérience utilisateur (UX), les informations de transparence intégrées à la bibliothèque de composants. Les exigences de la loi sont pour la plupart des choses qu'un produit d'IA bien conçu devrait déjà faire : évaluation robuste, documentation claire, réponse structurée aux incidents, UX transparente. La loi ne fait que les rendre légalement obligatoires.

Pour les fondateurs américains en particulier, le changement d'état d'esprit consiste à reconnaître que l'UE n'est pas un marché optionnel que l'on peut reporter à « plus tard ». La portée extraterritoriale de la loi via la sortie de résultats (output) dans l'UE signifie que même de petits contrats B2B peuvent vous faire entrer dans son champ d'application. Et la dynamique des questionnaires d'achat signifie que la préparation est un avantage concurrentiel dès maintenant, et pas seulement une ligne budgétaire de conformité.

Gardez également vos documents financiers prêts pour l'audit

Si vous développez une entreprise SaaS en Europe, la conformité à la loi sur l'IA est un élément d'un défi de documentation plus vaste. Vous aurez également besoin de registres financiers impeccables, d'une reconnaissance des revenus justifiable pour les abonnements multi-juridictionnels, d'une documentation sur les prix de transfert et de déclarations TVA-MOSS. Le même instinct d'ingénierie qui conduit à une documentation de conformité propre et versionnée devrait guider votre comptabilité : en texte brut (plain-text), auditable et consultable par un humain ou un auditeur IA.

Gardez vos finances aussi transparentes que votre IA

La leçon fondamentale de l'IA Act — à savoir que la documentation, l'auditabilité et la transparence sont désormais des avantages concurrentiels stratégiques — s'applique tout aussi bien à votre comptabilité. Beancount.io propose une comptabilité en texte brut qui vous offre une transparence totale et un contrôle de version sur vos dossiers financiers, avec la même structure lisible par l'homme et analysable par la machine que celle exigée par la conformité moderne. Pas de boîtes noires, pas de dépendance vis-à-vis d'un fournisseur, et un journal qu'un auditeur (ou votre propre agent IA) peut lire directement. Commencez gratuitement et découvrez pourquoi les développeurs et les professionnels de la finance qui créent des entreprises axées sur l'IA passent à la comptabilité en texte brut.