AI Act article 50 : ce qu'un dev e-commerce doit livrer avant le 2 août 2026

Le 2 août 2026, l'article 50 de l'AI Act devient applicable. Chatbot qui doit s'annoncer, visuels générés à marquer, textes à étiqueter : ce sont des obligations qui se traduisent en lignes de code, pas en clauses de CGV. Voici ce qu'un dev e-commerce doit livrer — et les trois pièges techniques que personne ne mentionne.

Ce qui bascule le 2 août

L'AI Act (règlement UE 2024/1689) s'applique par vagues. Celle du 2 août 2026 concerne l'article 50 : les obligations de transparence. Elle touche beaucoup plus de boutiques que les volets « haut risque » dont tout le monde a parlé en 2025, parce qu'elle vise des choses banales : un chatbot de support, une photo produit retouchée par IA, un guide d'achat rédigé par un LLM.

Quatre blocs deviennent applicables :

• 50(1) — un système d'IA qui interagit directement avec une personne doit l'informer qu'elle parle à une IA
• 50(2) — les contenus synthétiques (image, audio, vidéo, texte) doivent porter un marquage lisible par machine
• 50(4) — les deepfakes doivent être signalés de façon visible, et les textes publiés pour informer le public sur des sujets d'intérêt public doivent être étiquetés
• 50(5) — l'information doit arriver au plus tard lors de la première interaction, de façon claire, distinguable et accessible

Côté sanctions, un manquement à l'article 50 relève de l'article 99(4) : jusqu'à 15 M€ ou 3 % du CA mondial, le montant le plus élevé des deux. Bonne nouvelle pour les structures modestes : l'article 99(6) inverse la règle pour les PME et start-ups, c'est le montant le plus bas qui s'applique. En France, DGCCRF, CNIL et Arcom sont dans la boucle.

Le 20 juillet 2026 — il y a dix jours — la Commission a adopté ses guidelines sur l'article 50, qui complètent le Code de bonnes pratiques sur la transparence des contenus générés par IA publié en version finale le 10 juin. Le Code est volontaire ; les obligations qu'il sert à respecter ne le sont pas. Y adhérer donne une présomption de conformité ; ne pas y adhérer oblige à démontrer soi-même, devant l'autorité de surveillance, des moyens « équivalents et adéquats ».

La question qui décide de tout : fournisseur ou déployeur ?

Avant d'écrire une ligne de code, il faut trancher ça, parce que les obligations ne tombent pas au même endroit :

• Les obligations 50(1) (annoncer l'IA) et 50(2) (marquage machine) pèsent sur le fournisseur du système
• Les obligations 50(4) (deepfakes, textes d'intérêt public) pèsent sur le déployeur

Le réflexe naturel du prestataire est de se dire : « j'intègre l'API d'OpenAI ou de Mistral, je suis déployeur, le marquage c'est leur problème ». C'est vrai dans le cas simple. Mais l'article 25 pose un piège que beaucoup d'intégrateurs vont découvrir trop tard : on devient juridiquement fournisseur dès lors qu'on met un système d'IA sur le marché sous sa propre marque, ou qu'on le modifie substantiellement, ou qu'on le détourne de sa finalité prévue.

Traduit en langage de projet : vous branchez un LLM tiers, vous l'habillez d'un system prompt maison, vous l'appelez « Assistant Boutique X » et vous le vendez comme une fonctionnalité de votre module. Vous venez probablement de devenir fournisseur, et d'hériter du 50(1) et du 50(2). C'est un point à arbitrer avec le client — et à écrire dans le contrat — avant la mise en prod.

Cas 1 : le chatbot de la boutique

C'est le cas le plus fréquent et le plus vite réglé. L'article 50(1) prévoit une exemption si le caractère IA est « évident pour une personne raisonnablement informée, attentive et avisée, compte tenu du contexte ». Le piège est là : plus votre UX est réussie, moins l'exemption tient.

Un widget intitulé « Assistant IA » avec une icône de robot ? L'évidence est défendable. Un widget nommé « Sophie, votre conseillère » avec un avatar photoréaliste, un délai de frappe simulé et un tutoiement chaleureux ? L'évidence ne tient plus — c'est même exactement ce que le texte cherche à couvrir. L'anthropomorphisme de votre chatbot est devenu un risque de conformité.

Trois exigences techniques à respecter, qui viennent du 50(5) :

• Timing : au plus tard à la première interaction. Pas dans un footer, pas dans une FAQ, pas au troisième message.
• Clair et distinguable : l'information ne doit pas être noyée dans la conversation. Un premier message de bot qui dit « Bonjour ! » puis, quinze lignes plus bas, « au fait je suis une IA », ne passe pas.
• Accessible : le texte renvoie explicitement aux exigences d'accessibilité. Un pictogramme sans alternative textuelle, ou une mention en gris clair à 2,5:1 de contraste, ne remplit pas l'obligation.

En pratique, dans un template PrestaShop, la mention se pose en dehors du flux de messages, dans une région annoncée aux lecteurs d'écran :

{# modules/aichat/views/templates/front/widget.tpl — ou Twig en BO #}
<div class="aichat" role="region"
     aria-labelledby="aichat-disclosure">

  {# Mention obligatoire : hors flux de messages, lue en premier #}
  <p id="aichat-disclosure" class="aichat__disclosure">
    {l s='You are chatting with an AI assistant, not a human agent.'
       mod='aichat'}
  </p>

  <ol class="aichat__messages" aria-live="polite">
    {* messages *}
  </ol>
</div>

/* Contraste ≥ 4.5:1, pas de mention masquée au scroll */
.aichat__disclosure {
    position: sticky;
    top: 0;
    color: #1a1a2e;
    background: #eef0f6;
    font-size: .875rem;
    padding: .5rem .75rem;
}

Deux détails qui coûtent cher si on les oublie : la chaîne doit être traduite dans toutes les langues du shop (une boutique multi-pays UE qui n'affiche la mention qu'en français est en défaut sur les autres marchés), et la mention doit survivre au chargement asynchrone du widget. Si votre bundle JS met deux secondes à s'initialiser et que la mention arrive après le premier message du bot, le « au plus tard à la première interaction » n'est pas tenu. Rendez-la côté serveur, dans le HTML initial.

Cas 2 : les visuels produits générés par IA (le piège du pipeline d'images)

C'est ici que se cache le vrai sujet technique, et il est spécifique à notre métier.

L'article 50(2) exige que les sorties des systèmes génératifs soient marquées « dans un format lisible par machine et détectables comme générées ou manipulées artificiellement », avec des solutions « efficaces, interopérables, robustes et fiables ». Le règlement est neutre technologiquement : il ne nomme aucun standard. Mais le Code de bonnes pratiques pousse vers une approche multi-couches — métadonnées de provenance embarquées dans le fichier (en pratique C2PA / Content Credentials, avec l'ISO 22144 en préparation) et filigrane invisible au niveau pixel, censé survivre à la compression, au recadrage et au changement de format.

Or que fait une boutique PrestaShop, Magento ou Sylius avec une image produit ? Elle la régénère. En sept déclinaisons. Via GD ou Imagick. Puis elle la convertit en WebP ou AVIF. Puis elle la passe à un CDN qui réoptimise à la volée.

Chacune de ces étapes détruit les métadonnées C2PA. Le manifeste est stocké dans une box JUMBF que imagecopyresampled() ne connaît pas, que la conversion WebP par défaut n'emporte pas, et que la plupart des optimiseurs CDN suppriment activement pour gagner quelques kilo-octets. Résultat : un visuel correctement marqué par le générateur arrive nu sur la fiche produit. Si vous êtes fournisseur au sens de l'article 25, vous êtes en défaut sur le 50(2) — et vous ne l'aurez jamais vu passer, parce que rien dans votre CI ne teste la présence d'un manifeste de provenance.

Le premier réflexe est donc de vérifier. Avant même de corriger, mesurez : combien de vos visuels générés par IA ont perdu leur provenance en sortie de pipeline ? Le CLI de référence est c2patool.

# Le fichier source sortant du générateur porte-t-il un manifeste ?
c2patool source/product-4213.png

# Et après la chaîne de régénération PrestaShop ?
c2patool img/p/4/2/1/3/4213-home_default.webp
# → "No claim found" dans la quasi-totalité des cas

Ensuite, on réinjecte le manifeste après régénération. En PrestaShop, l'endroit logique est un service appelé en aval de ImageManager::resize(), branché sur le hook actionWatermark ou sur votre propre commande de régénération :

<?php

declare(strict_types=1);

namespace YourVendor\AiTransparency\Service;

use Symfony\Component\Process\Exception\ProcessFailedException;
use Symfony\Component\Process\Process;

/**
 * Réinjecte un manifeste de provenance C2PA détruit par la régénération
 * des déclinaisons d'images (GD/Imagick + conversion WebP).
 */
final class ProvenancePreserver
{
    private const PROCESS_TIMEOUT = 30;

    public function __construct(
        private readonly string $c2paToolPath,
        private readonly string $manifestPath
    ) {
    }

    /**
     * Vérifie la présence d'un manifeste et le réapplique si nécessaire.
     *
     * @param string $imagePath Chemin absolu de la déclinaison régénérée
     *
     * @return bool True si l'image porte un manifeste en sortie
     *
     * @throws ProcessFailedException Si l'outil de signature échoue
     */
    public function ensureManifest(string $imagePath): bool
    {
        if (!is_file($imagePath)) {
            return false;
        }

        if ($this->hasManifest($imagePath)) {
            return true;
        }

        return $this->attachManifest($imagePath);
    }

    private function hasManifest(string $imagePath): bool
    {
        $process = new Process([$this->c2paToolPath, $imagePath]);
        $process->setTimeout(self::PROCESS_TIMEOUT);
        $process->run();

        return $process->isSuccessful();
    }

    private function attachManifest(string $imagePath): bool
    {
        $process = new Process([
            $this->c2paToolPath,
            $imagePath,
            '--manifest', $this->manifestPath,
            '--force',
            '--output', $imagePath,
        ]);
        $process->setTimeout(self::PROCESS_TIMEOUT);
        $process->mustRun();

        return true;
    }
}

Deux compléments indispensables :

• Désactivez le stripping de métadonnées sur le CDN pour les chemins d'images produits. Cloudflare Polish, Fastly Image Optimizer et leurs équivalents suppriment les métadonnées par défaut. C'est une case à décocher, pas du code.
• Ajoutez un test en CI. Une assertion « toute image marquée comme générée par IA en base porte un manifeste après régénération » vous évitera de découvrir le problème lors d'un contrôle.

Cas particulier : si le visuel relève du deepfake au sens du 50(4) — typiquement un mannequin virtuel photoréaliste, un avatar de personne inexistante en photo lifestyle — le marquage machine ne suffit plus. Il faut une divulgation visible pour l'utilisateur. C'est un arbitrage à poser avec le client dès le brief créatif, pas au moment de la mise en ligne.

Cas 3 : les textes générés — ce qui n'est PAS concerné

Ici, la lecture courante est trop large, et ça vaut la peine d'être précis, parce que la précision fait gagner du temps.

Le 50(4) impose l'étiquetage visible des textes générés par IA publiés dans le but d'informer le public sur des sujets d'intérêt public. Une fiche produit, une description de catégorie, un e-mail transactionnel, une réponse de chatbot : ce ne sont pas des textes d'intérêt public. Vous n'avez pas à coller un badge « généré par IA » sur vos 40 000 descriptions produits.

En revanche, le contenu éditorial d'une boutique peut basculer dans le périmètre. Un article de blog sur la sécurité d'un produit, un dossier santé ou nutrition sur un site de compléments alimentaires, un guide sur une réglementation : si c'est généré par IA et publié pour informer, la question se pose sérieusement.

Et là intervient l'exemption la plus utile du texte : pas d'obligation d'étiquetage si le contenu a fait l'objet d'une revue humaine ou d'un contrôle éditorial, et qu'une personne physique ou morale en assume la responsabilité éditoriale.

Attention au niveau d'exigence : il s'agit d'un vrai contrôle éditorial par quelqu'un doté de la compétence et du jugement professionnel pertinents. Un passage au correcteur orthographique ou une relecture en diagonale ne qualifie pas. Et l'exemption suppose de pouvoir identifier ce responsable — donc de le tracer.

C'est une exigence de traçabilité, donc du code. Une table dédiée suffit :

CREATE TABLE `PREFIX_ai_content_provenance` (
    `id_ai_content_provenance` INT UNSIGNED NOT NULL AUTO_INCREMENT,
    `entity_type`   VARCHAR(64)  NOT NULL COMMENT 'cms, product, category…',
    `id_entity`     INT UNSIGNED NOT NULL,
    `id_lang`       INT UNSIGNED NOT NULL,
    `generator`     VARCHAR(128) NOT NULL COMMENT 'Modèle et version utilisés',
    `id_reviewer`   INT UNSIGNED NULL     COMMENT 'Employé ayant validé',
    `reviewed_at`   DATETIME     NULL,
    `date_add`      DATETIME     NOT NULL,
    PRIMARY KEY (`id_ai_content_provenance`),
    KEY `idx_entity` (`entity_type`, `id_entity`, `id_lang`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

Et la requête qui vous dit, à tout moment, quels contenus générés n'ont pas de responsable identifié — donc lesquels ne bénéficient pas de l'exemption :

<?php

declare(strict_types=1);

/**
 * Contenus générés par IA sans revue humaine tracée.
 *
 * @return array<int, array<string, string>>
 */
public function findUnreviewedContent(string $entityType): array
{
    $query = new \DbQuery();
    $query->select('p.id_entity, p.id_lang, p.generator, p.date_add')
        ->from('ai_content_provenance', 'p')
        ->where('p.entity_type = "' . pSQL($entityType) . '"')
        ->where('p.id_reviewer IS NULL')
        ->orderBy('p.date_add ASC');

    return \Db::getInstance()->executeS($query) ?: [];
}

Ce registre a un bénéfice qui dépasse la conformité : il répond enfin à la question « qui a écrit ça, avec quel modèle, et qui l'a validé ? » sur un catalogue où l'IA rédige depuis deux ans.

Les icônes officielles de l'UE

Détail pratique peu connu : la Commission met à disposition un jeu d'icônes officielles pour signaler les contenus générés par IA — trois variantes (« IA », « généré par l'IA », « modifié par l'IA »), en SVG et PNG, quatre déclinaisons de couleur, librement réutilisables. Elles font partie de la section 2 du Code de bonnes pratiques.

Leur usage reste facultatif — les obligations d'étiquetage, non. Mais quand une divulgation visible est requise, utiliser le pictogramme officiel plutôt qu'un badge maison est le choix le plus défendable, et ça vous économise une discussion avec le designer.

Le calendrier réel

• 2 août 2026 : l'article 50 est applicable. Régime de sanctions actif.
• 2 décembre 2026 : fin du délai de grâce sur le marquage des contenus pour les systèmes d'IA déjà sur le marché avant le 2 août. Ce sursis ne couvre pas un système que vous mettez en prod maintenant.

Autrement dit : si vous livrez un chatbot ou un pipeline de génération de visuels en août, vous êtes dans le régime plein dès le premier jour.

Ce que je ferais cette semaine

• Inventorier. Listez chaque point où de l'IA touche l'expérience client : chatbot, recommandations conversationnelles, génération de visuels, rédaction de contenus, réponses automatiques aux avis. C'est plus long que prévu.
• Qualifier le rôle. Pour chaque point : fournisseur ou déployeur ? Vérifiez l'article 25 si vous rebrandez un système tiers sous votre marque.
• Poser la mention chatbot côté serveur, traduite, contrastée, dans une région accessible — c'est une heure de travail et c'est le manquement le plus visible.
• Auditer le pipeline d'images avec c2patool, et désactiver le stripping de métadonnées sur le CDN.
• Tracer les contenus générés et identifier le responsable éditorial, pour pouvoir invoquer l'exemption du 50(4).
• Documenter. En cas de contrôle, ce qui est demandé est la démonstration de moyens adéquats. Un registre et une décision écrite valent mieux qu'une bonne intention.

Conclusion

L'AI Act a été traité pendant deux ans comme un sujet juridique. L'article 50 le fait atterrir dans le code : un attribut ARIA, une chaîne de traduction, un manifeste de provenance qui survit à une conversion WebP, une colonne id_reviewer. Rien d'insurmontable — mais rien qui se règle par une mise à jour de CGV.

Le vrai enseignement pour notre métier est ailleurs : la conformité passe désormais par la chaîne de build. Un manifeste C2PA détruit par un optimiseur d'images est un défaut de conformité produit par une décision d'infrastructure, invisible pour le juriste comme pour le marketing. C'est exactement le genre d'angle mort qu'un développeur est le seul à pouvoir voir — et à pouvoir tester en CI.

Vous voulez faire le point sur les usages IA d'une boutique et ce qu'ils impliquent techniquement ? Contactez-moi pour un audit de conformité côté implémentation.

Sources

• Article 50 : Obligations de transparence — texte intégral, EU Artificial Intelligence Act
• Guidelines sur les obligations de transparence (adoptées le 20 juillet 2026) — Commission européenne
• Code de bonnes pratiques sur la transparence des contenus générés par IA — Commission européenne
• Icônes officielles de l'UE pour l'étiquetage des contenus IA — Commission européenne
• Article 99 : Sanctions — EU Artificial Intelligence Act
• Article 25 : Responsabilités le long de la chaîne de valeur de l'IA
• C2PA — Coalition for Content Provenance and Authenticity