Le régime transitoire de l’AI Act n’expire pas le 2 décembre : ce que l’article 50 exige réellement des systèmes déjà commercialisés

La date doit être vérifiée avant de devenir un plan de conformité

L’hypothèse selon laquelle le délai transitoire expire le 2 décembre 2026 n’est pas étayée par la documentation institutionnelle décrite dans les sources fournies. La Commission européenne situe l’application des obligations de transparence de l’article 50 à partir du 2 août 2026 et décrit une exception limitée pour certains systèmes mis sur le marché avant cette date. Selon cette explication, l’exception ne constitue pas une prolongation générale de l’AI Act et ne s’applique pas de la même manière à toutes les obligations de transparence.

Cette précision est importante, car un calendrier erroné peut conduire à reporter des contrôles déjà exigibles. Le régime transitoire mentionné est limité au marquage et à la détection des contenus générés ou manipulés, prévus pour les fournisseurs à l’article 50, paragraphe 2. Il n’exonère pas, à lui seul, de l’obligation d’informer une personne lorsqu’elle interagit avec un système d’IA, et ne remplace pas les obligations de divulgation pouvant incomber à la personne qui publie certains contenus.

Cette actualité ne retient donc pas le 2 décembre comme date d’expiration confirmée. La date applicable aux systèmes existants doit être confrontée à la version en vigueur des lignes directrices et des questions fréquentes institutionnelles avant d’être utilisée dans des politiques internes, des communications publiques ou des décisions de lancement. Ce texte propose une lecture opérationnelle de la portée décrite par ces sources ; il ne constitue ni un conseil juridique ni un guide complet sur le règlement sur l’IA.

La transition décrite est étroite : elle concerne le marquage technique de certains résultats

L’article 50 distingue des obligations souvent regroupées de façon imprécise sous l’expression « étiqueter les contenus générés par l’IA ». Pour les fournisseurs de systèmes destinés à interagir directement avec des personnes, le principe est que le système informe la personne qu’elle interagit avec une IA, sauf si cela est évident au regard des circonstances et du contexte d’utilisation. Il s’agit d’une obligation de transparence relative à l’interaction, et non d’une règle concernant les métadonnées d’une image ou d’un texte.

Pour les fournisseurs de systèmes capables de générer des contenus synthétiques audio, image, vidéo ou texte, le paragraphe consacré aux contenus impose que les résultats soient marqués dans un format lisible par machine et permettent de détecter qu’ils ont été générés ou manipulés artificiellement. Les lignes directrices institutionnelles présentent cette exigence comme une caractéristique technique orientée vers la détection, et non comme la simple présence d’une mention visible à l’écran.

L’exception transitoire indiquée par la Commission est limitée à cette dernière matière : le marquage et la détection prévus au paragraphe 2 pour les systèmes déjà mis sur le marché avant le début d’application indiqué. Il ne s’ensuit pas que tous les systèmes existants soient exemptés des autres obligations de l’article 50. Cela ne signifie pas non plus que tout outil intégré à un produit ancien conserve indéfiniment le même traitement : les équipes doivent analyser le système et la version qu’elles mettent effectivement à disposition ou qu’elles modifient.

La mise sur le marché n’est ni une étiquette commerciale ni une date d’annonce

La condition temporelle impose d’identifier si un système a été mis sur le marché avant le 2 août 2026. Dans le langage réglementaire, cette question ne devrait pas être tranchée uniquement à partir de la date d’un communiqué de presse, d’une démonstration publique, d’une version bêta limitée ou de la date de création d’un compte client. Le dossier doit relier le système concerné à sa première mise à disposition sur le marché de l’Union et aux éléments de preuve disponibles à ce sujet.

La difficulté s’accroît pour les produits qui évoluent fréquemment. Un modèle, une interface de génération, un service d’édition et une API peuvent suivre des cycles de lancement distincts. Une mise à jour peut également modifier la capacité de générer du contenu, la méthode de marquage ou le rôle de l’entité qui propose le service. Les informations institutionnelles fournies ne permettent pas d’établir ici une règle automatique pour tous les changements de version. Par prudence, il convient de soumettre les changements importants à un examen documenté plutôt que de présumer que la date d’un produit principal suffit pour tous ses composants.

Cet examen doit associer les équipes produit, ingénierie et conformité ainsi que, le cas échéant, l’équipe éditoriale ou de communication. La section actualités d’Inferama peut aider à suivre les évolutions réglementaires ; les comparaisons et l’espace de découverte peuvent servir à organiser les outils et les capacités, mais ils ne remplacent pas l’analyse de la configuration et de l’usage précis.

Fournisseur et déployeur ont des obligations différentes et peuvent coexister au sein d’une même organisation

La distinction des rôles est essentielle. Le fournisseur se trouve au centre de l’obligation de concevoir ou d’intégrer un marquage lisible par machine dans les résultats des systèmes couverts. La source institutionnelle présente aussi le code de bonnes pratiques relatif à la transparence des contenus générés par l’IA comme un instrument volontaire pertinent pour démontrer le respect de mesures liées au marquage et à la détection. Son caractère volontaire ne fait pas du code une obligation autonome et ne supprime pas la nécessité d’évaluer l’exigence légale applicable.

Le déployeur, quant à lui, est la personne qui utilise un système dans un contexte donné. Lorsqu’il divulgue un contenu image, audio ou vidéo constituant un deepfake, il doit révéler qu’il a été généré ou manipulé artificiellement dans les conditions prévues. Une règle spécifique existe également pour les déployeurs qui génèrent ou manipulent un texte publié afin d’informer le public sur des questions d’intérêt public. Cette seconde situation comprend des nuances et des exceptions qui exigent une évaluation du contrôle humain, de la révision éditoriale et de la responsabilité éditoriale.

Une entreprise peut fournir un service génératif et l’utiliser aussi pour publier des campagnes, des actualités, des vidéos ou des communications sur son propre site. Dans ce cas, il ne convient pas de retenir un rôle unique pour l’ensemble du produit. Chaque activité doit être tracée : fournir le système, intégrer une capacité tierce, générer un élément, le modifier et le diffuser. Le résultat peut déclencher des obligations différentes à différentes étapes.

Le marquage lisible par machine et la divulgation au public répondent à des problèmes différents

Une étiquette visible, une mention de crédit, une icône ou un avertissement dans une publication peuvent être utiles à la compréhension d’une personne. Ils ne sont toutefois pas équivalents, par définition, à un marquage lisible par machine permettant de détecter l’origine artificielle ou la manipulation. Les lignes directrices officielles distinguent les mesures de marquage et de détection des obligations d’étiquetage ou de divulgation applicables aux déployeurs. Les équipes ne devraient pas présenter une solution visuelle comme une preuve suffisante du respect de l’exigence technique sans en vérifier la portée.

Inversement, une métadonnée ou un signal intégré au contenu peut ne pas suffire pour que le public reçoive une divulgation claire, identifiable et opportune dans l’interface où le contenu est présenté. L’article 50 prévoit des conditions de clarté, de distinguabilité et d’accessibilité pour les informations exigées. La conception du produit doit tenir compte à la fois de la persistance d’un signal technique et du moment, du format et de la compréhension de l’avis destiné aux personnes.

Les sources fournies indiquent également qu’il existe des exceptions et des conditions contextuelles, notamment pour certains usages artistiques, créatifs, satiriques ou fictifs ainsi que pour certains textes soumis à une révision et à une responsabilité éditoriales. Ces exceptions ne doivent pas être appliquées sur le seul fondement du nom d’une rubrique, d’une campagne ou d’un compte. Le raisonnement reliant les faits du cas à l’exception invoquée doit être conservé.

Éléments de preuve à réunir avant un lancement ou un examen

Les preuves opérationnelles doivent permettre de répondre à plusieurs questions : quel système a été utilisé, à quelle date il a été mis sur le marché, quel résultat il a produit, quelles mesures techniques ont été appliquées et quel avis le public a reçu. Une fiche produit générique ou une déclaration commerciale du fournisseur permet rarement de démontrer tous ces éléments. Il est préférable de conserver un dossier par système et par version, relié à l’inventaire des fournisseurs, à l’historique des modifications et aux décisions de publication.

Pour le marquage, il est raisonnable de conserver la spécification technique reçue du fournisseur, la méthode utilisée pour vérifier la détectabilité et les limites connues lorsque le contenu est transformé, téléchargé, converti ou distribué par des tiers. Pour la divulgation, il convient de conserver des captures ou des journaux de l’interface, le texte de l’avis, le public visé, le moment où il apparaît et la décision relative aux exceptions. Il s’agit de recommandations d’organisation et de preuve ; elles ne remplacent pas les exigences que les autorités compétentes peuvent préciser.

La surveillance de l’article 50 relève principalement des autorités nationales de surveillance du marché. La documentation institutionnelle prévoit également un rôle pour le Bureau de l’IA et le Contrôleur européen de la protection des données dans certains domaines. La répartition exacte des compétences dépend du cas et de l’entité concernée. Pour un service transfrontière, un fournisseur établi hors de l’Union ou une incertitude concernant une exception, la documentation institutionnelle en vigueur et un avis spécialisé peuvent être nécessaires.

Ce qui peut être affirmé avec certitude et ce qui reste incertain

Sur la base des sources institutionnelles fournies, on peut affirmer que les obligations de transparence ne forment pas un bloc unique, que l’exception transitoire citée est limitée au marquage et à la détection prévus au paragraphe applicable aux fournisseurs, et que fournisseurs et déployeurs ont des responsabilités distinctes. On peut également affirmer que le code de bonnes pratiques cité est volontaire et qu’il est présenté comme une voie permettant d’appuyer la démonstration de conformité à certaines obligations, et non comme un substitut automatique à toutes les autres.

Il n’est pas possible d’affirmer de manière responsable, au vu des éléments résumés disponibles pour cette rédaction, que le 2 décembre 2026 est la date d’expiration de cette exception. Il n’est pas non plus possible de trancher abstraitement si une mise à jour déterminée conserve la qualité de système existant, si une œuvre entre dans une exception ou si un avis particulier est accessible dans tous les contextes. Ces questions dépendent des faits, de la version en vigueur des lignes directrices et, le cas échéant, de l’interprétation des autorités.

La mesure utile ne consiste pas à attendre une étiquette unique ou une déclaration de conformité du fournisseur. Elle consiste à constituer un registre vérifiable qui sépare le système, la date, le type de contenu, le rôle, le marquage technique, la divulgation et la décision éditoriale. Cette séparation réduit le risque de confondre une communication destinée à l’utilisateur avec un signal détectable par machine, ou une obligation du fournisseur avec une obligation de la personne qui publie.

Poursuivre l’exploration

Corrections et transparence

Si vous repérez une information incorrecte ou obsolète, envoyez-nous la page et la source à vérifier.