Le règlement de l’Union européenne sur l’intelligence artificielle atteint sa date générale d’application le 2 août 2026. Pour un développeur, cette date ne signifie pas qu’il faut ajouter le même badge « généré par IA » à chaque écran. Il faut décrire chaque système d’IA, identifier le fournisseur et le déployeur, afficher l’information de l’article 50 dans le parcours utilisateur, conserver les signaux de traçabilité et donner à une personne habilitée un vrai moyen d’intervenir. Cet article met ce travail technique en regard du texte consolidé du règlement (UE) 2024/1689 publié sur EUR-Lex et des lignes directrices de la Commission sur l’article 50, vérifiés le 28 août 2026.
Il s’agit d’un guide technique, pas d’un conseil juridique. L’AI Act contient des règles qui dépendent du rôle, de la finalité, du mode d’utilisation et du secteur. L’équipe doit encore vérifier les faits, le droit national applicable, les obligations de protection des données et l’autorité compétente. Les solutions ci-dessous sont des modèles d’ingénierie, pas une qualification juridique de votre produit.
Les dates qui changent votre feuille de route
Les obligations de transparence de l’article 50 s’appliquent à partir du 2 août 2026. Pour le fournisseur d’un système d’IA générative mis sur le marché avant cette date, la transition limitée du marquage et de la détection de l’article 50, paragraphe 2, court jusqu’au 2 décembre 2026. La Commission indique que le contenu déjà créé et disponible avant le 2 août n’a pas à être étiqueté rétroactivement. Cette transition ne supprime pas les autres obligations applicables dès le 2 août. Traitez ces dates comme deux étapes de mise en production.
Les autres échéances sont faciles à confondre. Interdictions, définitions et culture de l’IA s’appliquent depuis le 2 février 2025. Gouvernance et modèles d’IA à usage général s’appliquent depuis le 2 août 2025. Selon l’article 113 modifié, les exigences de haut risque du chapitre III, sections 1 à 3, s’appliquent aux systèmes de l’annexe III de l’article 6, paragraphe 2, le 2 décembre 2027, et aux systèmes liés à des produits de l’article 6, paragraphe 1, et de l’annexe I, le 2 août 2028. Les fournisseurs et déployeurs de systèmes destinés aux autorités publiques doivent agir avant le 2 août 2030. L’article 12 n’est donc pas une obligation générale de journalisation pour chaque chatbot en août 2026.
Utilisez la présentation actuelle de l’AI Act par la Commission et relisez EUR-Lex avant une mise en production.
Commencez par le rôle et la juridiction
L’article 2 couvre le fournisseur qui met un système d’IA ou un modèle à usage général sur le marché de l’Union ou en service dans l’Union, qu’il soit établi dans l’Union ou un pays tiers. Il couvre les déployeurs de l’Union et les fournisseurs ou déployeurs de pays tiers lorsque le résultat est utilisé dans l’Union. Importateurs, distributeurs, fabricants de produits et mandataires sont aussi concernés. Sont exclus les domaines hors droit de l’Union et les systèmes exclusivement militaires, de défense ou de sécurité nationale.
Selon l’article 3, le fournisseur développe ou fait développer un système et le met sur le marché ou en service sous son nom ou sa marque. Le déployeur utilise un système sous son autorité, sauf usage personnel non professionnel. Un fournisseur cloud peut fournir le modèle, tandis que votre entreprise déploie l’agent qui l’appelle. Si elle appose son nom, modifie substantiellement un système à haut risque ou change sa finalité pour le rendre à haut risque, l’article 25 peut la faire devenir fournisseur. Documentez cette décision.
Créez une ligne d’inventaire pour chaque système utilisateur et modèle ou service réutilisable. Notez fournisseur, déployeur, finalité, marchés, modalités, interaction directe, évaluation du risque, versions, intégrations et approbateur. Un court schéma vaut mieux qu’une étiquette de produit :
personne -> interface -> information IA -> adaptateur modèle -> politique de sortie
-> marque de provenance -> étiquette ou contrôle -> publication
-> journal d’événements -> suivi et réponse
L’article 50 couvre quatre surfaces techniques
La FAQ de la Commission sur l’article 50 explique le champ. Implémentez les obligations séparément.
| Surface de l’AI Act | Rôle responsable | Conséquence minimale pour le produit |
|---|---|---|
| Interaction directe | Fournisseur | Informer la personne qu’elle interagit avec une IA, sauf si le contexte le rend évident. |
| Son, image, vidéo ou texte synthétique | Fournisseur | Ajouter une marque lisible par machine permettant de détecter la création ou la manipulation artificielle. |
| Exposition à la reconnaissance des émotions ou à la catégorisation biométrique | Déployeur | Informer les personnes exposées et traiter les données selon les règles de l’Union applicables. |
| Deepfake ou texte généré sur une question d’intérêt public | Déployeur | Fournir une information claire et distincte dès la première exposition, sous réserve des exceptions de l’article 50, paragraphe 4. |
Information dans un chatbot ou un agent
Les lignes directrices de la Commission décrivent quatre conditions cumulatives pour l’article 50, paragraphe 1 : système d’IA, véritable échange dans les deux sens, communication directe de l’IA sans intermédiaire humain, et autre partie personne physique. Un service qui parle uniquement à un autre service diffère d’un agent de support qui diffuse du texte à un client. Interprétez étroitement l’exception « évident », car elle retire une information.
Affichez l’information avant le premier jeton. Elle doit être visible dans la transcription, accessible aux technologies d’assistance et rester présente lors des appels d’outils ou d’un transfert humain. « Vous échangez avec un assistant IA » est plus clair qu’un nom de marque ou un avatar humain. Enregistrez sa version et son affichage dans un événement d’audit. Dans une interface vocale, annoncez l’IA avant l’échange. Une vérification humaine ultérieure ne supprime pas l’obligation initiale.
Contenu synthétique et provenance
L’article 50, paragraphe 2, fait peser le marquage sur le fournisseur, y compris celui d’un système à usage général produisant son, images, vidéo ou texte synthétiques. La marque doit être lisible par machine et permettre de détecter la création ou manipulation artificielle. La solution doit être efficace, interopérable, robuste et fiable dans la mesure techniquement possible, selon le contenu, le coût et l’état de la technique. Un badge visible seul n’est pas une marque lisible par machine, qui ne remplace pas non plus l’information visible du déployeur pour un deepfake.
Les exceptions couvrent l’assistance à l’édition standard, une sortie qui ne modifie pas substantiellement l’entrée du déployeur ou sa sémantique, et les systèmes autorisés par la loi pour détecter, prévenir, enquêter ou poursuivre les infractions. Les lignes directrices examinent des exemples plus étroits de communication machine à machine et de production en boucle fermée. N’en faites pas une exception générale pour les outils internes. Conservez la décision et son responsable.
Deepfakes et texte d’intérêt public
Le déployeur doit signaler le contenu image, audio ou vidéo généré ou manipulé par IA qui constitue un deepfake. La Commission le définit par sa ressemblance avec une personne, un objet, un lieu, une entité ou un événement existant ou vraisemblable et par une apparence fausse d’authenticité ou de véracité. L’information doit être perceptible sans outil spécial ni action supplémentaire. Placez « généré ou manipulé par IA » à côté du média, dans son nom accessible ou dans un signal sonore dès la première exposition. Pour une œuvre manifestement artistique, satirique ou fictive, elle peut se limiter à l’existence du contenu sans gêner sa présentation.
La règle du texte s’applique lorsqu’un texte généré ou manipulé est publié pour informer le public sur une question d’intérêt public. Les exemples comprennent politique, administration, justice, droits fondamentaux, sécurité, santé, environnement, sécurité des consommateurs et évolutions économiques, financières, scientifiques ou culturelles. L’exception de l’article 50, paragraphe 4, exige un examen humain ou un contrôle éditorial et une personne physique ou morale responsable. Une correction orthographique ne suffit pas. Sans preuve d’examen substantiel et de responsabilité, gardez l’étiquette.
Journaliser sans tout collecter
L’article 12 s’applique aux systèmes à haut risque lorsque les exigences du chapitre III deviennent applicables. Le système doit permettre l’enregistrement automatique des événements pendant son cycle de vie. Les journaux doivent fournir une traçabilité adaptée à la finalité : situations créant un risque ou une modification substantielle, suivi après commercialisation de l’article 72 et suivi de fonctionnement de l’article 26, paragraphe 5. Pour l’identification biométrique à distance de l’annexe III, point 1 a), l’article 12 ajoute la période d’utilisation, la base, l’entrée correspondante et les vérificateurs.
L’article 19 impose au fournisseur de conserver les journaux automatiques sous son contrôle pendant une durée adaptée à la finalité et au moins six mois, sauf droit contraire, notamment en matière de données. L’article 26, paragraphe 6, fixe le même minimum pour les journaux du déployeur. Ces règles n’autorisent pas la conservation indéfinie des conversations. Définissez une classe, limitez l’accès, chiffrez le stockage et séparez télémétrie et contenu. Hachez ou caviardez les données inutiles et faites valider les champs identifiants.
Une enveloppe d’événement peut prendre cette forme :
{
"trace_id": "tr_7f3c",
"system_version": "agent-2026.08.28",
"model_id": "model-release",
"actor_role": "deployer",
"content_class": "text",
"mark_applied": true,
"label_shown": true,
"human_review": "not_required",
"override": false,
"created_at": "2026-08-28T12:00:00Z"
}
Ces identifiants sont un exemple, pas un schéma imposé par l’UE. Reliez l’information, la version, le traitement de sortie, la décision et la publication sans secrets ni transcriptions complètes dans chaque journal. Pour un usage à haut risque, permettez au fournisseur et au déployeur de récupérer, interpréter et corréler les événements. Le guide d’observabilité des agents IA traite des traces, métriques et rédactions.
La supervision humaine doit être opérationnelle
L’article 14 concerne les systèmes à haut risque. Le fournisseur doit les concevoir avec des outils humain-machine permettant une supervision efficace pendant l’utilisation. Les mesures doivent être proportionnées au risque, à l’autonomie et au contexte. Il faut comprendre les limites, détecter les anomalies, reconnaître le biais d’automatisation, interpréter la sortie, l’ignorer ou l’annuler, et interrompre le système par un bouton d’arrêt ou une procédure conduisant à un état sûr.
L’article 26 demande au déployeur de confier la supervision à des personnes compétentes, formées, autorisées et soutenues. « Quelqu’un a regardé » ne suffit pas si cette personne ne voit pas les éléments utiles, ne peut pas refuser la recommandation ou arrêter l’action. Placez la validation avant l’effet irréversible. Affichez sortie, entrées, limites, contrôles et action. Distinguez refus, modification, escalade et arrêt. Enregistrez qui a contrôlé et pourquoi.
Pour les systèmes à haut risque de l’annexe III, point 1 a), l’article 14, paragraphe 5, exige une vérification séparée et une confirmation par au moins deux personnes physiques compétentes, formées et habilitées avant qu’un déployeur agisse sur l’identification, sous réserve de l’exception de proportionnalité prévue par le droit de l’Union ou national pour les activités répressives, la migration, le contrôle aux frontières et l’asile. Il s’agit d’une règle ciblée, pas d’une obligation universelle de double vérification pour chaque sortie d’IA.
Un flux de données déployable
Gardez les contrôles dans des services déterministes autour du modèle. La passerelle d’interaction gère l’information initiale et la langue. L’adaptateur enregistre la version et normalise les métadonnées. Le service de sortie détermine la destination, applique ou vérifie la marque lisible par machine et décide si une étiquette visible ou un examen humain est nécessaire. La passerelle de politique bloque la publication sans le signal requis. Le service d’approbation conserve le vérificateur, la décision et l’arrêt. Le magasin d’événements reçoit un enregistrement corrélé minimal. Le suivi cherche les informations manquantes, erreurs de marque, textes non examinés, appels d’outils inattendus et arrêts défaillants.
Ne cachez pas ces contrôles dans un prompt. Seule l’interface peut garantir l’information avant le flux de réponse, et seul le pipeline de sortie peut conserver la marque après export. Pour les permissions de l’agent et les résultats d’outils non fiables, consultez le guide sur la prompt injection et la sécurité MCP. Pour séparer orchestration, politique et effets secondaires, consultez le guide d’architecture d’agent IA de production.
Suivi et rythme des mises à jour
Traitez l’article 50 comme un invariant de mise en production. Chaque build qui change modèle, interface, rendu, export ou localisation doit tester l’information au premier échange, la conservation de la marque après transformation, l’information du deepfake et le blocage d’un texte d’intérêt public sans contrôle ou étiquette. Testez clavier, lecteur d’écran, mobile, voix et API : l’article 50, paragraphe 5, exige une information claire et distincte accessible.
En production, alertez sur une information manquante, une erreur de provenance, une marque supprimée, une publication sans human_review, un vérificateur sans autorité ou un arrêt sans état sûr. Examinez chaque semaine un échantillon de traces. Vérifiez chaque mois conservation, accès, formation et changements du modèle ou du fournisseur. Faites chaque trimestre une revue documentée du risque et du flux de données. Réexaminez immédiatement après un incident grave, une version du fournisseur, une nouvelle modalité ou finalité, une modification substantielle ou une nouvelle ligne directrice.
Ce rythme est une pratique d’ingénierie, pas un intervalle légal. Pour les systèmes à haut risque, alignez la gestion des risques et le suivi après commercialisation sur les articles 9 et 72. L’article 112 prévoit l’évaluation des changements possibles de la liste de l’article 50 au 2 août 2028, puis tous les quatre ans. Gardez un registre des sources avec le texte consolidé d’EUR-Lex, les orientations de la Commission, le statut du code de pratique et l’autorité nationale responsable.
Checklist avant mise en production
- Notez fournisseur, déployeur, finalité, lien avec l’Union, utilisateurs et destinations.
- Déterminez le paragraphe de l’article 50 et conservez les preuves des exceptions.
- Affichez l’information d’interaction avant le premier jeton et vérifiez l’accessibilité.
- Appliquez une marque lisible par machine à la frontière du fournisseur et testez-la après export.
- Ajoutez l’information de première exposition pour deepfakes et texte d’intérêt public.
- Définissez examen substantiel, responsabilité éditoriale, autorité, annulation et arrêt sûr.
- En cas de haut risque, implémentez enregistrement, propriété, accès, conservation et escalade.
- Reliez chaque version aux enregistrements du modèle, de la marque et du suivi.
- Vérifiez les sources officielles avant toute version importante et après un changement.
Sources : règlement (UE) 2024/1689, lignes directrices, FAQ Article 50, calendrier et faits essentiels. Le texte légal et les orientations font foi. Cet article ne remplace pas un conseil juridique, privacy ou sectoriel.