État au 11 août 2026. L’Article 50 du Règlement IA de l'UE (transparence pour certains systèmes qui interagissent avec des personnes, génèrent du contenu synthétique, effectuent une reconnaissance des émotions ou une catégorisation biométrique, ou publient des deepfakes) s'applique depuis le 2 août 2026. La Commission européenne a commencé à faire respecter ces exigences de transparence. Il s'agit du droit actuel pour le code applicatif, et non d'une échéance future.
La majorité des exigences du Chapitre III pour les systèmes à haut risque (Articles 8 à 15 : gestion des risques, gouvernance des données, documentation technique, tenue de registres, instructions aux utilisateurs, supervision humaine, ainsi que précision, robustesse et cybersécurité) n'ont pas pris effet à la date initiale du 2 août 2026. Le Règlement (UE) 2026/1744, le Digital Omnibus sur l'IA, a été publié au Journal officiel le 24 juillet 2026 et est entré en vigueur le 27 juillet 2026. Il reporte l'application de ces obligations pour les systèmes à haut risque au 2 décembre 2027 pour les systèmes classés comme tels en vertu de l’Article 6(2) et de l’Annexe III (systèmes autonomes tels que ceux utilisés dans l'emploi, les services essentiels et les outils de maintien de l'ordre), et au 2 août 2028 pour les systèmes classés en vertu de l’Article 6(1) et de l’Annexe I (IA intégrée dans des produits déjà réglementés ailleurs, comme les dispositifs médicaux ou les machines). Les plans qui considèrent encore août 2026 comme l'échéance critique pour la conformité des systèmes à haut risque se basent sur une date qui a déjà été modifiée.
Ce guide s'adresse aux développeurs. Il ne classe pas votre produit comme à haut risque, ne réalise pas d'évaluation de conformité ni ne remplace un avis juridique. Il identifie le calendrier, les obligations de l’Article 50 qui apparaissent désormais sous forme de texte d'interface et de métadonnées dans une diff, et explique comment une lecture conforme d'une pull request détecte le mode de défaillance courant : un nettoyage qui supprime la divulgation.
Ce qui est applicable maintenant (Article 50)
L’Article 50 définit quatre principales catégories d'obligations de transparence, réparties entre les fournisseurs (l'organisation qui développe le système) et les utilisateurs (l'organisation qui le met en service), sous réserve d'exceptions, notamment pour certains usages policiers. Chacune de ces obligations se manifeste souvent dans le code en cours d'exécution, et pas seulement dans la documentation. Art. 50(1) : un système conçu par un fournisseur pour interagir directement avec une personne doit informer cette personne qu'elle communique avec une IA, sauf si cela serait évident pour une personne raisonnablement informée. Un widget de chat, un agent vocal ou un bot d'assistance nécessite une divulgation visible par l'utilisateur. Art. 50(2) : un fournisseur dont le système génère du contenu synthétique (audio, image, vidéo ou texte) doit marquer cette sortie dans un format lisible par machine, détectable comme généré par IA. Pour les systèmes déjà sur le marché avant le 2 août 2026, la partie concernant le marquage lisible par machine de l’Art. 50(2) est souvent décrite avec une période de transition jusqu'au 2 décembre 2026. Vérifiez le texte transitoire exact dans l'Omnibus et les directives de la Commission pour votre lignée de produits, car les autres obligations de l’Article 50 ne bénéficient pas de ce délai. Art. 50(3) : un utilisateur exploitant un système de reconnaissance des émotions ou de catégorisation biométrique sur des personnes doit informer ces personnes. Art. 50(4) : un utilisateur publiant un deepfake doit toujours divulguer qu'il a été généré ou manipulé artificiellement. Pour un contenu faisant partie d'une œuvre manifestement artistique, créative, satirique, fictive ou analogue, cette obligation de divulgation se limite à être effectuée de manière à ne pas entraver l'affichage ou la jouissance de l'œuvre, plutôt que d'être supprimée. Par ailleurs, le texte généré ou manipulé par IA publié pour informer le public sur une question d'intérêt public nécessite la même divulgation, sauf si le contenu a fait l'objet d'un examen ou d'un contrôle éditorial humain et qu'une personne ou une organisation assume la responsabilité éditoriale de sa publication.
Chacune de ces obligations est généralement mise en œuvre sous forme d'élément d'interface, d'écriture de métadonnées ou de chaîne de texte, ce qui en fait exactement le type de chose qu'un refactoring peut supprimer sans que personne ne la signale comme un changement de conformité. À partir d'août 2026, cette suppression n'est pas « prématurée » : elle crée une lacune de transparence en vigueur.
Exemple concret : un nettoyage d'interface supprime la divulgation
Supposons qu'un chatbot d'assistance ait été livré avec une ligne permanente sous son premier message : « Vous discutez avec un assistant IA. » Une pull request ultérieure reconçoit le widget pour un état plus épuré à la première ouverture et, en supprimant ce que le designer a signalé comme du désordre dans l'onboarding, supprime cette ligne ainsi que trois autres éléments de texte d'introduction. La reconception n'est pas erronée en soi : le widget est plus lisible et les trois autres lignes étaient effectivement superflues. Mais la divulgation de l’Art. 50(1) avait été implémentée sous forme de l'une de ces lignes, donc la supprimer a également supprimé la divulgation, et pas seulement le désordre. Rien dans la diff ne semble inhabituel : une réduction de texte dans un composant de chat n'est pas le type de chose qu'un scanner de bugs, un test QA ou une revue de conception est conçu pour détecter.
C'est ce qu'une vérification de conformité recherche dans une diff : lorsqu'un changement supprime ou affaiblit un élément lié à un contrôle qu'une équipe suit, citez l’Art. 50(1) directement dans la pull request, plutôt que de l'apprendre via une plainte ou un contact d'application après coup.
Les systèmes à haut risque sont reportés, pas annulés
Reporter les exigences pour les systèmes à haut risque de l'Annexe III à décembre 2027 ne rend pas la question sous-jacente, à savoir si un système est considéré comme à haut risque au titre de l'Annexe III, plus facile à répondre plus tard qu'aujourd'hui. Les contrôles derrière les Articles 8 à 15 posent le même type de problème « modifications dans une diff » que le hub de framework suit déjà : une atténuation des risques affaiblie, une vérification de gouvernance des données supprimée, une substitution humaine supprimée comme code mort. Adopter ces habitudes maintenant coûte moins cher que de découvrir des lacunes sous la pression d'une échéance en 2027.
Deux autres groupes de dates ne sont pas affectés par cet omnibus et s'appliquent déjà : les obligations relatives aux pratiques interdites et à l'alphabétisation en IA depuis le 2 février 2025, et les règles sur les modèles d'IA à usage général ainsi que les obligations de gouvernance depuis le 2 août 2025. Une autre modification à connaître dans le même paquet : une nouvelle interdiction couvrant les fournisseurs de systèmes destinés à générer ou manipuler du matériel intime non consenti ou du matériel d'abus sexuel sur mineur, ou des systèmes pour lesquels une telle sortie est un résultat raisonnablement prévisible et reproductible sans modification technique significative et sans garanties raisonnables et adéquates contre celle-ci, ainsi que les utilisateurs qui utilisent un système à cette fin, ajoutée à la liste des pratiques interdites du Règlement et applicable à partir du 2 décembre 2026.
Rôle de heygrc et la limite de l'honnêteté
heygrc est conçu pour analyser chaque pull request par rapport aux frameworks que vous avez sélectionnés, y compris le Règlement IA de l'UE lorsque vous l'avez activé, et pour identifier l'article qu'un changement semble toucher (par exemple, l’Art. 50(1) pour une divulgation de chat supprimée). La découverte est un commentaire de revue avec l'article joint, afin que l'auteur et le relecteur puissent décider en toute connaissance de cause. Il ne certifie pas la conformité au Règlement IA, ne classe pas le statut à haut risque, ne réalise pas d'évaluation de conformité, ne dépose pas de notifications auprès des autorités de surveillance ni ne remplace un conseil juridique. Une revue heygrc verte n'est pas une approbation de la Commission ; c'est un signal précoce, basé sur les articles, indiquant qu'un changement a modifié quelque chose que ces programmes surveillent.
Si votre équipe utilise déjà un outil de revue de bugs ou de qualité sur la même pull request, conservez-le. Ces outils vérifient si le code est correct et sûr. Les questions de l’Article 50 concernent plutôt le fait qu'une personne sache toujours qu'elle communique avec une IA, ou que le contenu synthétique soit toujours marqué. Le nettoyage mentionné ci-dessus peut être propre, typé et bien testé, mais laisser l’Art. 50(1) inachevé. Exécutez les deux couches ; aucune ne remplace l'autre.