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 est déjà pleinement applicable sur deux volets : les interdictions absolues depuis février 2025, et les obligations de gouvernance pour les modèles à usage général depuis août 2025. 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. Les obligations de transparence (article 50, chatbots, deepfakes, contenus générés par IA), elles, restent dues le 2 août 2026 comme prévu, avec un délai de grâce jusqu'au 2 décembre 2026 pour la seule obligation de filigrane sur les contenus déjà en marché. Si vous pilotez des projets digitaux en Europe, la fenêtre s'est donc élargie pour le haut risque, mais pas pour la transparence : ces obligations-là restent à quelques jours près.

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.

Ce que l'EU AI Act régule vraiment

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 une nouvelle interdiction, la génération d'images intimes non consenties (les « nudifiers ») et de contenus pédopornographiques par IA, avec une période transitoire jusqu'au 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.

Qui est vraiment concerné dans une équipe digitale

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 (chatbot, générateur de contenu), vous devez informer les utilisateurs qu'ils interagissent avec une IA. C'est une obligation qui concerne aujourd'hui presque tous les projets digitaux incluant un assistant conversationnel.

Ce qui change concrètement dans un process de delivery

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.

Ce que les équipes font mal en ce moment

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.