Source : Mayer, Valentin and Schüll, Moritz and Urbach, Nils and Urbach, Nils and Wendt, Domenik and Dannich, Walter, The EU AI Act and Its Transparency Obligations (May 27, 2026). 

Sommaire : L'IA Act transforme la transparence éthique en obligation juridique stricte, articulée autour de la traçabilité, de l'explicabilité et de la communication. La conformité impose une gestion dynamique de la chaîne de valeur, car un acteur peut être requalifié en « fournisseur » s'il modifie substantiellement un système. Les obligations s'accumulent selon les niveaux de risque (jusqu'au risque systémique pour les IA à usage général). Opérationnellement, cela exige une gouvernance en quatre phases (de l'idéation à la surveillance), automatisant la documentation technique et formant le personnel à la surveillance humaine pour gérer les alertes et les notifications d'incidents.

L'entrée en vigueur du règlement de l'Union européenne sur l'intelligence artificielle (IA Act) marque le passage d'un cadre éthique volontaire à un régime de conformité juridique contraignant. Cette transition impose une compréhension rigoureuse des mécanismes de transparence, pivots de la confiance et de la sécurité des produits. 

1. Fondements conceptuels de la transparence selon l'IA Act

Le règlement ne définit pas la transparence de manière isolée, mais l'opérationnalise comme un ensemble d'exigences concrètes découlant des travaux du Groupe d'experts de haut niveau (HLEG) de la Commission européenne. Le cadre réglementaire transforme les trois piliers du HLEG en obligations de conformité :

• Traçabilité (T) : Documentation systématique des jeux de données, des processus de conception et des logs d'événements pour permettre l'auditabilité du système.
• Explicabilité (E) : Capacité à rendre intelligibles les processus techniques et les décisions humaines tout au long du cycle de vie du système.
• Communication (C) : Obligation d'informer les utilisateurs de la nature artificielle du système et de ses limites opérationnelles.

2. Typologie des acteurs et interdépendances de la chaîne de valeur

L'IA Act définit des responsabilités spécifiques en fonction du rôle occupé. Contrairement à une vision en silos, le règlement reconnaît une chaîne de valeur séquentielle où les obligations (documentation, assurance qualité) font l'objet d'un « transfert » (handover) entre acteurs.

Dynamique de responsabilité et requalification (Art. 25) : Un acteur peut cumuler plusieurs rôles (ex: Fournisseur et Importateur). De plus, un importateur, distributeur ou déployeur est requalifié en "fournisseur" s'il appose sa marque sur le système ou s'il apporte une modification substantielle à un système d'IA à haut risque, assumant alors l'intégralité des obligations de conception.

3. Matrice de classification des risques et systèmes d'IA

Le cadre s'articule autour d'une double classification : par niveau de risque et par nature fonctionnelle (notamment pour l'IA à usage général).

Définition technique du système d'IA (Art. 3(1))

Un système n'est soumis au règlement que s'il répond à trois critères cumulatifs :

1. Une base machine conçue pour fonctionner avec différents niveaux d'autonomie.
2. Une capacité d'adaptabilité après déploiement (critère critique pour la gestion des risques évolutifs).
3. L'inférence de sorties (prédictions, décisions) influençant des environnements réels ou virtuels.

Classification par risque et cumul d'obligations

Le règlement distingue quatre catégories (Inacceptable, Haut risque, Risque de transparence, Minimal). Une observation cruciale est que les obligations liées au risque de transparence (Art. 50) peuvent être cumulatives : un système peut être classé « Haut risque » en raison de son domaine d'application (ex: recrutement) tout en étant soumis aux obligations de transparence s'il interagit avec des humains.

Systèmes d'IA à usage général (GPAI)

Le règlement sépare les modèles GPAI standards de ceux présentant un « risque systémique » (Art. 51), évalué selon leurs capacités de calcul ou leur impact sur le marché intérieur.

4. Répertoire des obligations de transparence par catégorie d'opérateur

Pour les Fournisseurs (Haut risque & GPAI)

• Documentation technique multiniveau : Pour les GPAI, le fournisseur doit maintenir une documentation pour l'IA Office (Art. 53(1)(a)) et une documentation distincte destinée aux fournisseurs en aval pour faciliter l'intégration.
• Transparence des données : Obligation de rendre public un résumé des données d'entraînement utilisées pour le modèle GPAI (Art. 53(1)(b)).
• Enregistrement et Marquage : Inscription dans la base de données de l'UE et apposition du marquage CE avant la mise sur le marché.

Pour les Déployeurs

• Information et Droits Fondamentaux : Notification obligatoire des travailleurs et de leurs représentants. Pour les secteurs sensibles (éducation, emploi, services publics essentiels), le déployeur doit confirmer la réalisation d'une analyse d'impact sur les droits fondamentaux (Art. 27) auprès des autorités.
• Notification des incidents graves : En cas de dysfonctionnement ou de défaillance pouvant entraîner un préjudice important (Art. 73), les délais de rapport aux autorités sont strictement hiérarchisés : 2 jours (menace pour la vie/santé), 10 jours (incidents à grande échelle), ou 15 jours (cas standards).

5. Cadre d'opérationnalisation : les quatre phases d'implémentation

Mayer et al. (2025) proposent d'utiliser les "Research Questions" (RQ) comme une check-list pour les risk managers afin de transformer le droit en processus IS (Information Systems).

1. Idéation de l'IA (Portfolio Management) :
   • Question clé : Comment intégrer la classification des risques dès l'évaluation du portefeuille de cas d'usage ?
   • Action : Établir une base de traçabilité dès la conception pour justifier le choix de classification (ou d'exemption).
2. Stratégie d'IA (Gouvernance) :
   • Question clé : Comment suivre l'évolution des rôles d'opérateur au sein de l'organisation ?
   • Action : Définir des structures de contrôle pour anticiper les coûts de conformité liés au passage du rôle de distributeur à celui de fournisseur.
3. Conception et Développement (Transparency by Design) :
   • Question clé : Quels outils peuvent automatiser la création de "Model Cards" et de documentation technique ?
   • Action : Se référer aux normes harmonisées (comité technique JTC 21) pour traduire les exigences juridiques en spécifications techniques auditables.
4. Opération à l'échelle (Surveillance) :
   • Question clé : Comment opérationnaliser la surveillance humaine (human-in-the-loop) au quotidien ?
   • Action : Mise en œuvre de programmes de littératie en IA (Art. 4) pour que le personnel comprenne la documentation technique et sache réagir aux alertes de risques.

6. Conclusion et limites du cadre actuel

L'IA Act transforme une aspiration éthique en une condition sine qua non d'accès au marché européen. Toutefois, il y a des ambiguïtés persistantes, notamment sur l'interprétation pratique de l'explicabilité et de la densité de documentation requise. Pour les institutions financières et autres acteurs régulés, la conformité ne pourra être atteinte que par une approche holistique, où la transparence est intégrée dès l'architecture technique, s'appuyant sur les standards de normalisation européens en cours de finalisation.