AI Act européen après l'Omnibus IA 2026 : ce que les équipes d'ingénierie doivent faire

L'Omnibus IA 2026 a modifié le calendrier des systèmes d'IA à haut risque, tandis que les obligations de transparence de l'article 50 restent applicables à partir du 2 août 2026. Voici la cartographie technique actuelle.

EU AI ActAI OmnibusComplianceAI GovernanceSovereign AIHigh-Risk AI

Calendrier de l'AI Act européen après l'Omnibus IA 2026

Le calendrier de l'AI Act européen a changé en 2026. Les institutions de l'Union ont adopté un Omnibus IA qui reporte les principales exigences relatives aux systèmes à haut risque par rapport aux dates initiales, tandis que l'application générale du règlement et le cadre de transparence de l'article 50 suivent leurs propres échéances.

À la date de révision du 22 juillet 2026, les principaux jalons pratiques sont les suivants :

2 février 2025 — les pratiques interdites et les dispositions relatives à la maîtrise de l'IA ont commencé à s'appliquer.
2 août 2025 — les règles de gouvernance et les obligations des fournisseurs de modèles d'IA à usage général ont commencé à s'appliquer.
2 août 2026 — date générale d'application, y compris les obligations de transparence de l'article 50.
2 décembre 2027 — date d'application adoptée pour les systèmes d'IA à haut risque de l'annexe III.
2 août 2028 — date d'application adoptée pour les systèmes à haut risque liés aux produits réglementés selon l'article 6, paragraphe 1, et l'annexe I.

La législation et les orientations de mise en œuvre pouvant évoluer, les équipes doivent vérifier le texte modificatif final au Journal officiel et les orientations actuelles de la Commission avant de prendre une décision juridique.

Besoin d'une première orientation ? Utilisez l'outil d'évaluation des risques de l'AI Act, exécuté uniquement dans le navigateur. Il couvre le lien avec l'Union, le rôle de l'opérateur, la finalité prévue, les exceptions de l'article 6, paragraphe 3, la transparence et les signaux liés aux autres législations sur les données.

Outil d'évaluation des risques de l'AI Act proposant un parcours d'orientation versionné dans le navigateur

Le calendrier en un seul tableau

| Date | Signification technique actuelle | | --- | --- | | 1er août 2024 | Entrée en vigueur de l'AI Act | | 2 février 2025 | Début d'application des pratiques interdites et de la maîtrise de l'IA | | 2 août 2025 | Début d'application des obligations des fournisseurs de GPAI et des dispositions de gouvernance | | 2 août 2026 | Obligations de transparence de l'article 50 et date générale d'application | | 2 décembre 2027 | Exigences applicables aux systèmes à haut risque de l'annexe III selon le calendrier Omnibus adopté | | 2 août 2028 | Exigences applicables aux systèmes à haut risque liés aux produits réglementés selon le calendrier Omnibus adopté |

Les niveaux de sanctions doivent également être formulés avec précision. Le plafond de 35 millions d'euros ou 7 % du chiffre d'affaires annuel mondial est associé aux violations des pratiques interdites. De nombreuses autres violations par les opérateurs et en matière de transparence relèvent d'un plafond de 15 millions d'euros ou 3 %, sous réserve des règles détaillées du règlement, du traitement des PME, de la proportionnalité et de l'application nationale.

La classification à haut risque dépend de la finalité prévue

L'utilisation d'une IA dans l'emploi, l'éducation, la finance ou la santé ne rend pas automatiquement chaque système « à haut risque ». L'article 6 et l'annexe III identifient des finalités prévues précises.

Exemples courants :

Emploi — publicité ciblée d'offres d'emploi, filtrage des candidatures, évaluation des candidats, décisions de promotion ou de licenciement, attribution de tâches et surveillance des travailleurs.
Éducation — admission, accès, décisions importantes relatives au niveau d'apprentissage, évaluation des acquis et certains usages de surveillance des examens.
Services essentiels — prestations publiques, évaluation de la solvabilité des personnes physiques, tarification et évaluation des risques en assurance vie et santé, répartition des appels d'urgence et triage médical d'urgence.
Biométrie — certains systèmes d'identification biométrique à distance, de catégorisation biométrique et de reconnaissance des émotions lorsque leur utilisation est autorisée. L'authentification simple en face à face est exclue de la catégorie de l'identification à distance.
Infrastructures critiques — composants de sécurité utilisés dans la gestion ou l'exploitation d'infrastructures critiques déterminées.
Forces de l'ordre, migration, justice et élections — uniquement les finalités et conditions énumérées à l'annexe III.

Le rôle de l'opérateur compte également. Un fournisseur, un déployeur, un importateur, un distributeur et un fabricant de produits peuvent être soumis à des obligations différentes. Une organisation peut exercer plusieurs rôles pour un même système.

Article 6, paragraphe 3 : l'exception qu'une case à cocher ne peut pas trancher

Un système relevant de l'annexe III peut échapper à la classification à haut risque lorsqu'il ne présente pas de risque important de préjudice et n'influence pas matériellement la décision concernée. Le règlement mentionne notamment une tâche procédurale limitée, l'amélioration d'une activité humaine déjà achevée, la détection de tendances sans remplacer ni influencer l'évaluation humaine, ou l'exécution d'une tâche préparatoire.

Trois précautions sont essentielles :

Un système de l'annexe III qui réalise le profilage de personnes physiques reste à haut risque.
Ces exceptions ne remplacent pas l'analyse distincte de la voie des produits réglementés prévue à l'article 6, paragraphe 1.
Un fournisseur qui invoque une exception doit documenter son évaluation avant la mise sur le marché ou la mise en service et effectuer l'étape d'enregistrement applicable.

C'est pourquoi l'outil SovAIHub renvoie « Examen de la classification au titre de l'article 6, paragraphe 3, nécessaire » au lieu de déclarer qu'un tel système présente un risque minimal.

L'article 50 s'applique à partir du 2 août 2026

Le 20 juillet 2026, la Commission européenne a publié les lignes directrices adoptées et une foire aux questions complémentaire sur les obligations de transparence de l'article 50. Elles confirment que les obligations sont plus précises que « tout étiqueter dès que l'IA a été utilisée ».

Les fournisseurs de systèmes conçus pour un véritable échange direct et bidirectionnel avec des personnes physiques doivent veiller à ce que celles-ci soient informées dès le début de la première interaction, sauf si la nature artificielle de l'interaction est évidente dans le contexte. Les traitements en arrière-plan et les communications de machine à machine ne déclenchent pas cette obligation d'interaction.
Les fournisseurs de systèmes générant des contenus synthétiques audio, image, vidéo ou texte entrant dans le champ d'application doivent permettre un marquage lisible par machine efficace. Les lignes directrices examinent des exclusions et exceptions concernant notamment le code source, les courtes séquences, les sorties de machine à machine, certaines sorties de développement industriel en boucle fermée, l'édition standard, la faisabilité technique et des situations industrielles ou interentreprises limitées.
Les déployeurs doivent signaler clairement les hypertrucages concernés au plus tard lors de la première exposition. Ils ne peuvent pas se fier uniquement au marquage lisible par machine du fournisseur, car leur propre information doit être perceptible par les personnes.
Les déployeurs qui publient des textes générés ou manipulés par l'IA sur des questions d'intérêt public ne peuvent invoquer l'exception liée à l'examen humain ou au contrôle éditorial que si l'examen porte réellement sur le fond et qu'une personne ou entité responsable assume la responsabilité éditoriale. Les simples vérifications d'orthographe, de grammaire ou de forme sont insuffisantes.
Les déployeurs de systèmes de reconnaissance des émotions ou de catégorisation biométrique doivent informer les personnes exposées, que le traitement soit effectué en temps réel ou a posteriori.

Les obligations des fournisseurs et des déployeurs doivent donc être cartographiées séparément dans les exigences produit et les preuves de test.

Il n'existe pas de délai de grâce général pour l'article 50. La Commission décrit uniquement une transition limitée pour l'obligation de marquage et de détection de l'article 50, paragraphe 2, concernant les systèmes mis sur le marché avant le 2 août 2026 ; ces systèmes doivent respecter cette obligation précise à partir du 2 décembre 2026. Les contenus générés avant le 2 août 2026 n'ont pas à être étiquetés rétroactivement.

À quoi ressemblent les preuves techniques pour les systèmes à haut risque

Il reste utile de commencer tôt le travail détaillé de conformité. Le socle de preuves comprend :

| Obligation | Preuve technique | | --- | --- | | Gestion des risques (art. 9) | Registre des risques versionné et relié aux versions et aux incidents | | Gouvernance des données (art. 10) | Traçabilité, adéquation et qualité des données, et dossiers d'examen des biais | | Documentation technique (art. 11) | Finalité prévue, architecture, versions, limites et dossier de validation | | Journalisation (art. 12) | Enregistrements automatiques d'événements conçus pour la traçabilité | | Instructions d'utilisation (art. 13) | Capacités, limites, supervision, données d'entrée et maintenance | | Contrôle humain (art. 14) | Autorité désignée, points de contrôle, neutralisation/interruption et formation | | Exactitude et robustesse (art. 15) | Tests de qualité, d'échec, adversariaux, de dérive et de cybersécurité | | Conformité et enregistrement | Évaluation applicable, déclarations, marquage et enregistrements en base de données |

Ces documents ne peuvent pas être reconstitués de manière fiable après plusieurs mois d'exploitation. Les journaux, références d'évaluation, approbations et historiques de modification doivent être intégrés au processus de livraison.

Le déploiement souverain facilite la preuve ; il ne crée pas la conformité

L'AI Act n'impose ni l'auto-hébergement ni l'isolement réseau. Un déploiement contrôlé peut néanmoins faciliter la production de preuves :

Les journaux d'exécution et d'appel d'outils peuvent couvrir l'intégralité du parcours d'une requête.
Les versions du modèle, du prompt, du système de recherche et des politiques peuvent être figées et reproduites.
Les flux de données et les accès administrateur peuvent être inspectés directement.
L'évaluation peut être exécutée sur des jeux de données approuvés sans envoyer d'exemples sensibles à un évaluateur externe.
La provenance des artefacts et les approbations de version peuvent être conservées avec le dossier du système.

La contrepartie est la responsabilité. L'auto-hébergement transfère à l'organisation la disponibilité, les correctifs, la provenance des modèles, la sécurité, la supervision et les opérations du cycle de vie. L'isolement réseau réduit fortement l'exposition au réseau externe, mais ne supprime pas les risques liés aux supports amovibles, aux administrateurs, aux accès physiques ou à l'importation d'artefacts.

Une séquence de préparation pratique

Inventorier les systèmes et les rôles. Enregistrer la finalité prévue, le propriétaire, les utilisateurs, les personnes concernées, le marché, le fournisseur, le déployeur, le modèle, les outils et la limite de déploiement.
Rechercher les pratiques interdites. Traiter toute correspondance possible avec l'article 5 comme une condition d'arrêt et d'examen.
Effectuer l'analyse de l'article 6. Identifier précisément la voie de l'annexe III ou des produits réglementés et documenter toute exception invoquée.
Cartographier séparément l'article 50. Distinguer les obligations de marquage du fournisseur des obligations d'information du déployeur.
Construire la chaîne de preuves. Versionner les jeux de test, les résultats d'évaluation, les journaux, les approbations, les artefacts de modèle, les incidents et les modifications substantielles.
Relier les preuves aux responsabilités. Un contrôle sans responsable, fréquence d'examen ou barrière de publication n'est pas un contrôle opérationnel.

Le projet d'AI System Passport rassemble cet inventaire, les preuves, les évaluations et l'historique des changements. Le modèle Sovereign EvalOps ajoute des barrières de régression, tandis que Sovereign AI FinOps relie les coûts d'exploitation à l'utilisation et aux résultats.

Références officielles

Révisé le 22 juillet 2026. Cet article fournit une orientation technique et ne constitue pas un avis juridique. Vérifiez le Journal officiel et les orientations actuelles de la Commission, et consultez un conseil qualifié pour les décisions de classification ou de conformité.