EU AI Act en production : ce que les équipes digitales doivent changer concrètement avant fin 2026

L'EU AI Act est en cours de déploiement, par phases. Adopté en 2024, il s'applique déjà en partie : les interdictions absolues depuis février 2025, les obligations de gouvernance pour les modèles à usage général depuis août 2025, et la transparence depuis août 2026. Le 27 juillet 2026, un règlement de simplification (le « Digital Omnibus »), validé par le Conseil de l'UE fin juin et signé le 8 juillet, est entré en vigueur : il reporte les obligations sur les systèmes à haut risque autonomes (Annexe III) au 2 décembre 2027, et celles sur les systèmes à haut risque intégrés à des produits déjà réglementés (Annexe I) au 2 août 2028. La transparence (article 50 : chatbots, deepfakes, contenus générés par IA) n'a pas bougé : elle s'applique depuis le 2 août 2026, comme prévu. Seul le marquage des contenus synthétiques (article 50(2)) bénéficie d'un délai de grâce jusqu'au 2 décembre 2026, et uniquement pour les fournisseurs de systèmes déjà mis sur le marché avant le 2 août 2026. Si vous pilotez des projets digitaux en Europe, la fenêtre s'est donc élargie pour le haut risque, pas pour la transparence.

Ce qui m'a frappé en suivant la mise en oeuvre de ce règlement côté terrain, c'est l'écart entre ce que les équipes pensent qu'il implique et ce qu'il implique vraiment. La plupart des acteurs digitaux ne sont pas "fournisseurs d'IA" au sens du règlement, et pourtant ils ont des obligations. Cet article vise à clarifier ce qui change concrètement pour une équipe de delivery, une DSI ou une agence digitale en 2026.

EU AI Act : les quatre niveaux de risque des systèmes IA

L'EU AI Act ne régule pas "l'intelligence artificielle" en général. Il régule des systèmes IA selon leur niveau de risque, en distinguant quatre catégories : les usages interdits, les systèmes à haut risque, les systèmes avec obligations de transparence, et les systèmes à risque minimal.

Les usages interdits depuis février 2025 incluent la notation sociale par des autorités publiques, la manipulation subliminale, et certains usages biométriques en temps réel dans les espaces publics. Le Digital Omnibus de juillet 2026 y ajoute deux nouvelles interdictions, la génération d'images intimes non consenties (les « nudifiers ») et de contenus pédopornographiques par IA, applicables à compter du 2 décembre 2026. Pour une équipe digitale standard, ces cas restent rares.

Les systèmes à haut risque incluent des outils utilisés dans les processus RH (recrutement automatisé, évaluation des candidats), dans l'éducation, dans la justice, dans les infrastructures critiques, ou dans les services publics. Ces obligations, initialement prévues au 2 août 2026, ont été reportées par le Digital Omnibus au 2 décembre 2027 pour les systèmes autonomes, et au 2 août 2028 pour ceux intégrés à des produits déjà réglementés. C'est là que ça devient concret pour beaucoup d'équipes, avec davantage de temps désormais pour s'y préparer sérieusement.

Les obligations de transparence concernent les chatbots, les systèmes de génération de contenu et les deepfakes : l'utilisateur doit être informé qu'il interagit avec une IA. Je détaille ces obligations, et surtout leurs limites réelles, dans Article 50 de l'AI Act : qui est concerné, et pourquoi tout le monde ne l'est pas.

Les systèmes à risque minimal, la grande majorité des outils IA du quotidien (filtres de spam, recommandations de contenu, outils de traduction), sont soumis à très peu d'obligations.

Fournisseurs et déployeurs d'IA : qui est vraiment concerné par l'EU AI Act

La distinction clé du règlement est entre fournisseurs (ceux qui développent ou mettent sur le marché un système IA) et déployeurs (ceux qui utilisent un système IA développé par un tiers dans un contexte professionnel).

Une agence digitale ou une DSI qui intègre ChatGPT, Claude ou Gemini dans ses outils internes est un déployeur. Ses obligations sont plus légères que celles d'un fournisseur, mais elles existent.

En tant que déployeur d'un système à haut risque, vous devrez, à partir de décembre 2027 (ou août 2028 selon le cas) : désigner une personne responsable de la conformité IA, assurer une supervision humaine des décisions automatisées, documenter les usages, informer les personnes concernées si les décisions les impactent, et tenir un registre des incidents. Le report ne dispense pas de s'y préparer, il donne simplement plus de marge pour le faire correctement.

En tant que déployeur d'un système avec obligation de transparence, vous devez signaler les deepfakes et certains textes d'intérêt public (article 50(4)). L'obligation d'informer l'utilisateur qu'il parle à une IA (article 50(1)) vise le fournisseur : si vous concevez vous-même l'assistant conversationnel, elle vous incombe, ce qui concerne aujourd'hui beaucoup de projets digitaux.

Conformité EU AI Act dans le delivery : cadrage, gouvernance, documentation

C'est là que l'articulation avec le delivery management devient directe. Intégrer les exigences de l'EU AI Act dans un projet IA ne se fait pas en fin de projet avec un audit de conformité. Ca se fait en amont, au cadrage.

Au cadrage : qualifier le niveau de risque du système

Avant de définir le périmètre technique, il faut répondre à une question simple : le système IA qu'on va déployer est-il à haut risque au sens du règlement ? Ca détermine le niveau d'effort de conformité à prévoir.

La réponse dépend du secteur du client, de la nature des décisions que le système va prendre ou recommander, et des personnes que ces décisions vont affecter. Un outil de scoring candidats pour une DRH est à haut risque. Un outil de synthèse de comptes-rendus pour une équipe marketing n'en est pas un.

Cette qualification doit être documentée et traçable. C'est une décision de cadrage, pas une décision technique.

En cours de projet : gouvernance et supervision humaine

Pour les systèmes à haut risque, le règlement impose une supervision humaine "effective". Ca ne veut pas dire qu'un humain valide chaque output de l'IA, mais que le système est conçu pour qu'une intervention humaine soit possible et que les opérateurs soient formés pour exercer ce contrôle.

Concrètement, ça se traduit dans les specs : prévoir des écrans de validation avant toute décision automatisée impactante, journaliser les actions du système, documenter les cas où l'IA peut se tromper et comment l'opérateur le détecte.

Ces exigences ne sont pas très différentes de ce qu'un bon delivery manager intègrerait de toute façon dans un système sensible. L'EU AI Act les formalise et les rend opposables.

À la livraison : documentation et registre

Le règlement exige que les déployeurs tiennent une documentation technique sur le système IA utilisé, ses finalités, ses limites, et les mesures de supervision mises en place. Pour les systèmes à haut risque, un registre d'utilisation doit être conservé pendant au moins six mois.

C'est une charge documentaire nouvelle, mais qui s'intègre naturellement dans un processus de delivery rigoureux. Si vous documentez déjà vos décisions d'architecture et vos spécifications, la compliance EU AI Act représente un effort marginal. Si vous ne documentez pas, c'est le signal que votre delivery a un problème plus large.

EU AI Act : les trois erreurs de conformité les plus fréquentes

Trois erreurs reviennent régulièrement dans les projets que j'observe.

La confusion entre ce qui est interdit et ce qui est réglementé. L'EU AI Act n'interdit pas l'IA en entreprise. Il encadre certains usages. La plupart des projets digitaux relèvent des catégories à risque minimal ou avec obligation de transparence seulement, pas du haut risque.

L'attente d'un guide exhaustif avant d'agir. La Commission Européenne publie des guidance documents, mais ils arrivent progressivement. Attendre d'avoir tout compris pour commencer à se mettre en conformité, c'est garantir d'être en retard. Les principes fondamentaux (qualifier le risque, documenter les usages, assurer la supervision humaine) sont clairs et applicables maintenant.

La délégation à un juriste sans implication des équipes techniques. La conformité EU AI Act n'est pas un sujet purement juridique. Elle demande une collaboration entre le juridique, la DSI ou le delivery manager, et les équipes métier. Les obligations techniques (supervision humaine, journalisation, gestion des incidents) ne peuvent pas être spécifiées sans les équipes qui construisent le système.

Comment intégrer ça dans votre pratique de delivery

La bonne approche est simple à résumer : traiter la conformité EU AI Act comme une contrainte de cadrage, pas comme un audit de fin de projet.

Dans la pratique, ca veut dire ajouter deux questions au template de cadrage de tout projet intégrant de l'IA : "Quel est le niveau de risque de ce système au sens de l'EU AI Act ?" et "Qui est responsable de la supervision humaine des outputs ?". Ces deux questions orientent tout le reste.

Mon expertise en intelligence artificielle intègre désormais systématiquement cette dimension réglementaire dans le cadrage des projets clients. Non pas comme une couche de compliance ajoutée en fin de parcours, mais comme une contrainte de conception au même titre que la performance ou la sécurité.

Pour les équipes qui ont besoin d'un point de départ concret, la Commission Européenne publie les textes officiels et les guidance associés. L'AI Office est l'organe de supervision créé pour accompagner la mise en oeuvre. Ces deux sources sont les références à suivre.

L'EU AI Act n'est pas une contrainte supplémentaire posée sur l'IA. C'est la formalisation d'une exigence qui devrait être naturelle pour quiconque pilote des systèmes automatisés qui affectent des personnes : comprendre ce qu'on déploie, documenter les décisions, et s'assurer qu'un humain reste dans la boucle là où ça compte.