Depuis le début de l'année, la question qu'on me pose le plus souvent au sujet de l'AI Act n'est pas « comment me mettre en conformité ». C'est « est-ce que je suis seulement concerné ». Et c'est une bonne question, parce que la réponse n'est ni « non, c'est pour les autres » ni « oui, tout votre produit doit être audité demain ».
Le sujet s'est compliqué en mai 2026 : les co-législateurs européens ont trouvé un accord pour décaler une partie du calendrier. Résultat, la plupart des guides en ligne affichent des dates qui ne sont déjà plus exactes. Je fais donc le point sur deux choses concrètes pour un fondateur ou un dirigeant : comment savoir si votre SaaS entre dans le périmètre du règlement (UE) 2024/1689, et ce qui s'applique réellement aujourd'hui par opposition à ce qui est repoussé à 2027 ou 2028.
Le 7 mai 2026, le Conseil, le Parlement et la Commission ont annoncé un accord politique provisoire sur le « Digital Omnibus on AI », un texte de simplification qui modifie l'AI Act sur plusieurs points. Le plus important pour vous est le calendrier.
Dans la version d'origine, le gros des obligations pour les systèmes à haut risque devait s'appliquer le 2 août 2026. Avec l'accord de mai, ces échéances reculent : les systèmes à haut risque dits « autonomes » (ceux de l'annexe III) basculent au 2 décembre 2027, et ceux intégrés à des produits déjà réglementés (annexe I) au 2 août 2028. Les obligations de transparence de l'article 50, elles, sont décalées du 2 août au 2 décembre 2026 — un report de quelques mois seulement.
Point d'attention. Cet accord est politique et provisoire. Il n'a pas encore été formellement adopté par le Parlement et le Conseil. Tant que le vote final n'est pas intervenu, le calendrier d'origine reste juridiquement la référence. En clair : si le texte n'était pas adopté avant le 2 août 2026, les échéances initiales redeviendraient applicables.
Avant de parler de risque, l'AI Act vous demande de savoir quel rôle vous jouez. C'est la première chose à clarifier, et c'est là que beaucoup de fondateurs se trompent.
Le règlement distingue principalement le fournisseur (celui qui développe un système d'IA et le met sur le marché sous son nom) et le déployeur (celui qui utilise ce système dans le cadre de son activité). Ces définitions figurent à l'article 3.
Prenons le cas le plus fréquent. Vous éditez un SaaS B2B et vous y branchez l'API d'un grand modèle de langage — GPT, Claude, Mistral, peu importe. Vis-à-vis de ce modèle, vous êtes un déployeur. Mais si vous construisez par-dessus une fonctionnalité que vous commercialisez sous votre marque, vous devenez, pour cette fonctionnalité, le fournisseur d'un système d'IA. Vous pouvez donc être les deux à la fois, à des étages différents de la chaîne. L'éditeur du modèle, lui, est un fournisseur de modèle d'usage général (GPAI), avec ses propres obligations, distinctes des vôtres.
Pourquoi est-ce décisif ? Parce que les obligations ne pèsent pas sur tout le monde de la même manière, et qu'un fournisseur qui n'a pas clarifié les rôles dans ses contrats risque de se voir imputer des manquements qui relèvent en réalité de l'usage qu'en fait son client. C'est précisément ce que j'aborde dans l'article sur l'AI Act et les contrats SaaS.
L'AI Act repose sur une approche par les risques, avec quatre catégories. Voici ce qu'elles donnent une fois ramenées à un produit concret.
Risque inacceptable (interdit, article 5). Notation sociale, manipulation comportementale subliminale, certaines formes de reconnaissance biométrique. C'est interdit depuis le 2 février 2025. Dans la pratique, l'immense majorité des SaaS B2B ne touche pas à ces usages.
Haut risque (articles 6 et annexe III). IA utilisée dans des domaines sensibles : recrutement et RH, accès au crédit ou à l'assurance, éducation, infrastructures critiques, justice. Si votre produit sert à trier des candidatures ou à décider d'un octroi de crédit, vous êtes probablement ici — avec un régime exigeant (documentation, gestion des risques, supervision humaine). C'est ce régime qui vient d'être repoussé à fin 2027.
Risque limité (article 50). Les systèmes qui interagissent avec des personnes ou génèrent du contenu : chatbots, assistants, génération de texte ou d'image. L'obligation tient en peu de mots : prévenir l'utilisateur qu'il a affaire à une IA, et permettre d'identifier les contenus générés ou manipulés.
Risque minimal. Tout le reste — filtres anti-spam, moteurs de recommandation, traduction, détection d'anomalies. Aucune obligation spécifique au titre de l'AI Act.
En pratique. La plupart des fonctionnalités d'IA que je vois dans les SaaS B2B relèvent du risque limité ou minimal. Autrement dit, vous êtes souvent moins exposé que ce que la couverture médiatique laisse croire. Le piège n'est pas le « haut risque » fantasmé : c'est de passer à côté des deux ou trois obligations qui, elles, s'appliquent déjà.
On raisonne souvent comme si l'AI Act était un événement futur. Une partie est pourtant déjà en vigueur.
Les interdictions de l'article 5 s'appliquent depuis le 2 février 2025. À la même date est entrée en vigueur l'obligation de maîtrise de l'IA (« AI literacy », article 4) : vous devez vous assurer que les personnes qui conçoivent ou utilisent vos systèmes d'IA disposent d'un niveau de compréhension suffisant. Ce n'est pas un document à produire, c'est une démarche de formation interne — facile à mettre en place, souvent oubliée.
Depuis le 2 août 2025, les obligations applicables aux modèles d'usage général (GPAI) sont actives : documentation technique, information des intégrateurs, politique de respect du droit d'auteur, résumé des données d'entraînement (articles 53 et suivants). Bonne nouvelle pour la plupart des startups : vous n'entraînez pas de modèle de fondation, vous êtes en aval. Ces obligations pèsent d'abord sur les éditeurs de modèles, pas sur vous — mais elles déterminent ce que vous pouvez exiger d'eux par contrat.
Enfin, l'obligation de transparence de l'article 50 arrive vite : décembre 2026 selon l'accord de mai. Si votre produit comporte un chatbot ou génère du contenu, c'est l'échéance à inscrire dès maintenant dans votre feuille de route.
Le report du régime « haut risque » à fin 2027 ou 2028 donne de l'air. Il ne justifie pas l'attentisme, pour une raison simple : la conformité produit n'est pas la seule pression que vous subirez.
Vos clients grands comptes, eux, n'attendent pas le calendrier réglementaire. Dès cette année, je vois passer des due diligences et des questionnaires fournisseurs qui posent des questions AI Act très précises avant la signature. Une réponse claire sur votre classification et vos rôles devient un argument commercial. Une réponse floue ralentit la vente, voire la fait capoter. La mise en conformité contractuelle, elle, se prépare donc maintenant — bien avant l'échéance produit.
Si vous voulez un point de départ utile et proportionné, voici la séquence que je recommande à mes clients fondateurs :
Un dernier réflexe, parce que l'AI Act ne vit pas seul : il s'articule avec le RGPD, qui s'applique dès que vos systèmes traitent des données personnelles. Une bonne partie de votre conformité RGPD est d'ailleurs réutilisable pour l'AI Act.
La conformité à l'AI Act ressemble moins à un mur qu'à un escalier dont on a déplacé quelques marches. Le bon mouvement n'est pas de tout faire en une fois, c'est de savoir précisément sur quelle marche vous vous trouvez. Si vous voulez clarifier votre situation et sécuriser vos contrats IA, parlons-en.


Vous avez investi dans le RGPD ? Une partie est réutilisable pour l'AI Act. Ce que votre conformité couvre, ce qu'elle ne couvre pas, et comment articuler les deux.

SaaS, IT, hébergement, intégration : panorama des modes de résiliation d'un contrat informatique en droit français, et des réflexes à avoir.
Avançons ensemble pour accélérer votre activité