AI Act 2026-2028 : le calendrier ne suffit plus, place à la gouvernance des usages

Ce qui a réellement changé en juillet 2026

Le texte de référence reste le règlement (UE) 2024/1689. Il n’a pas été remplacé par un "nouvel AI Act". Il a été modifié par le règlement (UE) 2026/1744, intitulé Digital Omnibus on AI, qui simplifie plusieurs aspects de sa mise en œuvre et reprogramme certaines échéances.

La distinction est importante. Le calendrier présenté aujourd’hui doit être lu à partir du texte consolidé au 27 juillet 2026, tout en gardant à l’esprit que cette version consolidée est un outil documentaire. Les versions juridiquement authentiques restent les actes publiés au Journal officiel de l’Union européenne.

Le changement le plus visible concerne les sections 1, 2 et 3 du chapitre III relatives aux systèmes à haut risque. Pour les systèmes classés à haut risque au titre de l’article 6(2) et de l’annexe III, les règles concernées s’appliqueront le 2 décembre 2027. Pour les systèmes relevant de l’article 6(1) et de l’annexe I, notamment certains systèmes intégrés à des produits réglementés, l’échéance est fixée au 2 août 2028.

La Commission justifie ce décalage par la disponibilité tardive de certains standards, spécifications communes, lignes directrices et dispositifs institutionnels nécessaires à une mise en œuvre cohérente. Le report n’efface donc pas les exigences. Il donne davantage de temps pour les rendre applicables dans de meilleures conditions.

Le calendrier utile, avec la décision attendue

Un calendrier réglementaire devient stratégique lorsqu’il est relié à une décision. La date seule dit quand regarder. Elle ne dit pas ce que l’entreprise doit faire.

Cette chronologie ne doit pas être interprétée comme une autorisation d’attendre la veille de chaque échéance. Une date d’application indique le moment où une obligation devient applicable, pas la date idéale pour commencer les travaux.

L’article 4 ne demande pas une formation identique pour tout le monde

La littératie IA est souvent présentée comme la partie la plus facile du règlement : former les salariés, conserver une preuve, puis passer au sujet suivant. La version consolidée de l’article 4 est plus nuancée.

Depuis la modification de 2026, les fournisseurs et déployeurs doivent prendre des mesures pour soutenir le développement de la littératie en matière d’IA de leur personnel et des personnes utilisant des systèmes pour leur compte. Le texte leur demande de tenir compte des connaissances techniques, de l’expérience, de l’éducation, de la formation, du contexte d’utilisation et des personnes ou groupes sur lesquels les systèmes sont susceptibles d’être utilisés. Il précise également que cette obligation n’impose pas de garantir un niveau déterminé de littératie pour chaque individu.

La conséquence pratique est importante : la conformité ne se réduit pas à une session générique intitulée "Comprendre ChatGPT". Elle suppose une approche proportionnée aux responsabilités.

Une organisation mature intégrera cette littératie dans l’onboarding, les politiques d’utilisation, les procédures d’achat, les revues de projets et les exercices d’incident. Elle pourra également documenter les populations visées, le contenu transmis, la date, les mises à jour et, lorsque cela a du sens, l’évaluation de la compréhension.

L’objectif n’est pas de produire davantage de certificats. Il est de réduire le nombre de décisions prises par des personnes qui ignorent ce que le système peut réellement faire, ce qu’il ne peut pas démontrer et ce qu’il ne devrait jamais recevoir comme données.

La transparence de l’article 50 est plus précise qu’un simple label "généré par IA"

Depuis le 2 août 2026, l’article 50 impose plusieurs obligations de transparence distinctes. Les regrouper sous la formule "il faut étiqueter les contenus IA" est séduisant, mais juridiquement insuffisant.

Le premier cas concerne les systèmes destinés à interagir directement avec des personnes. Le fournisseur doit les concevoir de manière à ce que l’utilisateur soit informé qu’il interagit avec une IA, sauf lorsque cela est évident pour une personne raisonnablement informée et attentive dans le contexte considéré.

Le deuxième cas concerne les fournisseurs de systèmes générant des contenus synthétiques audio, image, vidéo ou texte. Les sorties doivent être marquées dans un format lisible par machine et détectables comme artificiellement générées ou manipulées. Le règlement exige que les solutions soient efficaces, interopérables, robustes et fiables dans la mesure où cela est techniquement possible, tout en tenant compte de l’état de l’art et des limites techniques. Une exception existe notamment lorsque le système fournit une assistance pour une édition standard ou ne modifie pas substantiellement les données ou leur sémantique.

Le troisième cas concerne les déployeurs de systèmes de reconnaissance des émotions ou de catégorisation biométrique, qui doivent informer les personnes exposées lorsque les conditions de l’article sont réunies.

Le quatrième couvre notamment les deepfakes et certains textes publiés dans le but d’informer le public sur des questions d’intérêt public. Pour les textes, l’obligation connaît notamment une exception lorsqu’un processus de revue humaine ou de contrôle éditorial a eu lieu et qu’une personne physique ou morale assume la responsabilité éditoriale.

Une entreprise qui veut vérifier sa situation doit donc répondre à des questions concrètes : qui doit informer, à quel moment, sur quel canal, de quelle manière, et qui conserve la preuve que le dispositif fonctionne ? Pour les contenus synthétiques, elle doit également savoir quel mécanisme de marquage ou de détection est effectivement utilisé et s’il résiste suffisamment aux transformations prévues.

Métadonnées, provenance signée, watermarking ou autres techniques peuvent contribuer à cette exigence. Aucune ne doit cependant être présentée comme automatiquement conforme dans tous les contextes. L’obligation porte sur le résultat réglementaire attendu, pas sur l’adoption d’une marque ou d’un standard particulier.

Le 2 décembre 2026 mérite un contrôle spécifique

Cette date est moins médiatisée, mais elle cumule deux sujets distincts.

D’abord, l’article 111(4) prévoit que les fournisseurs de systèmes d’IA, y compris des systèmes à usage général, générant du contenu synthétique audio, image, vidéo ou texte et mis sur le marché avant le 2 août 2026 prennent les mesures nécessaires pour respecter l’article 50(2) au plus tard le 2 décembre 2026.

Ensuite, la modification de 2026 a ajouté deux pratiques interdites à l’article 5. L’article 5(1)(ba) vise, dans les conditions précises prévues par le règlement, des systèmes générant ou manipulant des contenus intimes ou sexuellement explicites réalistes concernant une personne identifiable sans son consentement. L’article 5(1)(bb) concerne certains contenus ou performances relevant de la directive 2011/93/UE relative aux abus sexuels sur enfants. Le règlement prévoit des conditions et précisions supplémentaires aux paragraphes 1a et 1b, ce qui interdit de résumer ces dispositions par une formule générale qui effacerait leur champ exact.

Selon l’article 113 consolidé, ces nouvelles interdictions s’appliquent à partir du 2 décembre 2026.

Pour une organisation, la conséquence est simple : si elle développe, distribue ou déploie des fonctions génératives susceptibles d’entrer dans ces catégories, la revue ne doit pas attendre 2027.

Haut risque : qualifier un usage, pas coller une étiquette sur un fournisseur

Le terme "haut risque" est probablement celui qui génère le plus de mauvaises interprétations. Un outil utilisé par les ressources humaines n’est pas automatiquement à haut risque. Une IA employée dans une école ne l’est pas automatiquement non plus. Le règlement demande d’examiner le système, sa finalité et les conditions d’application de l’article 6.

Deux grandes voies existent. La première, prévue à l’article 6(1), concerne les systèmes d’IA qui sont eux-mêmes des produits ou des composants de sécurité de produits couverts par certaines législations d’harmonisation de l’Union figurant à l’annexe I, lorsqu’une évaluation de conformité par un tiers est requise. La seconde, prévue à l’article 6(2), renvoie aux cas d’usage de l’annexe III, notamment dans certains domaines de biométrie, infrastructures critiques, éducation, emploi, services essentiels, forces de l’ordre, migration, justice ou processus démocratiques.

La Commission a publié en mai 2026 un projet de lignes directrices consacré à cette classification. Au 30 août 2026, la page officielle consultée les présente encore comme des lignes directrices en projet, non juridiquement contraignantes. Elles constituent une aide d’interprétation utile, mais elles ne doivent donc pas être présentées comme un texte final ayant la même valeur que le règlement.

Une méthode de qualification pragmatique peut suivre cette séquence : déterminer d’abord si l’outil entre dans le champ de la définition d’un système d’IA, identifier sa finalité et son usage prévu, vérifier s’il relève de l’article 6(1) ou d’un cas de l’annexe III, examiner les conditions et exceptions applicables, puis qualifier le rôle de l’organisation et la date correspondante.

L’erreur la plus fréquente consiste à commencer par le nom du modèle. Or GPT, Claude, Gemini, Mistral ou tout autre modèle ne sont pas en eux-mêmes une catégorie de risque applicable à tous leurs usages. Un même modèle sous-jacent peut alimenter un assistant de rédaction à faible enjeu et un système utilisé dans un processus beaucoup plus sensible. C’est l’usage qui change la qualification.

Une entreprise peut cumuler plusieurs rôles sans le savoir

Le règlement distingue plusieurs opérateurs : fournisseur, déployeur, importateur, distributeur, représentant autorisé et, dans certaines situations, fournisseur en aval.

Cette distinction n’est pas administrative. Elle détermine les obligations.

Une entreprise peut être déployeur lorsqu’elle utilise un assistant interne, puis devenir fournisseur lorsqu’elle intègre une fonction d’IA dans un produit qu’elle commercialise sous son propre nom. Elle peut également s’appuyer sur un modèle GPAI externe tout en devenant fournisseur du système aval qu’elle construit autour de celui-ci. Son statut peut donc varier système par système, produit par produit et parfois version par version.

La question utile n’est pas "utilisons-nous une IA tierce ?". Elle est plutôt : que faisons-nous exactement de ce système et sous quelle responsabilité le mettons-nous à disposition ?

Cette lecture a une conséquence contractuelle immédiate. Une organisation qui ne connaît pas son rôle aura beaucoup de mal à demander à son fournisseur les informations nécessaires, à négocier la bonne répartition de responsabilité ou à prouver qu’elle a contrôlé sa chaîne de dépendance.

Ce que la direction doit réellement décider

La conformité ne peut pas être abandonnée à un référent isolé chargé de "s’occuper de l’IA". Plusieurs arbitrages relèvent de la direction.

Il faut d’abord définir quels usages sont acceptables, lesquels exigent une validation préalable et lesquels doivent être interdits. Il faut ensuite désigner la personne ou la fonction responsable de la qualification d’un nouveau système, préciser quelles preuves doivent être conservées et décider du niveau d’exigence imposé aux fournisseurs.

Cette gouvernance doit également répondre à des risques qui dépassent le texte de l’AI Act. Une dépendance excessive à un fournisseur peut fragiliser un produit. Une API peut traiter des données que l’entreprise n’aurait jamais dû lui transmettre. Une évolution silencieuse de modèle peut modifier les résultats d’un processus validé quelques semaines plus tôt. Un système peut être juridiquement utilisable mais techniquement mal sécurisé. Une décision automatisée peut enfin devenir impossible à expliquer lorsque personne ne sait quelle version du système était active le jour où elle a été prise.

Le rôle de la direction consiste donc à arbitrer entre innovation, exposition réglementaire, risque opérationnel et dépendance technologique. La conformité n’est qu’une partie du problème.

L’AI Act n’est pas un substitut à la cybersécurité

Un système conforme sur le papier peut rester vulnérable.

L’AI Act prévoit lui-même des exigences de robustesse et de cybersécurité pour les systèmes à haut risque, mais il ne constitue pas un cadre général de sécurité pour tous les usages de l’IA. Une organisation doit donc continuer à traiter les scénarios techniques classiques et ceux qui sont propres aux systèmes modernes : fuite de données confidentielles dans les prompts, injection de prompts, empoisonnement de données, manipulation d’une chaîne RAG, compromission d’un connecteur, extraction d’informations, changement non maîtrisé d’un modèle, dépendance à une API ou mauvaise séparation des privilèges.

La gouvernance IA doit ainsi s’articuler avec le RGPD lorsqu’il existe un traitement de données personnelles, avec NIS2 lorsque l’entité entre dans son champ, avec DORA pour les organisations concernées du secteur financier, ainsi qu’avec les obligations sectorielles et les politiques internes de sécurité.

Il faut éviter une confusion fréquente : conformité et sécurité se recouvrent parfois, mais aucune ne prouve automatiquement l’autre.

Pour une direction ou un RSSI, cela signifie qu’un projet IA devrait entrer dans les mécanismes ordinaires de sécurité : analyse de menace, gestion des accès, journalisation, contrôle des secrets, revue des fournisseurs, tests, réponse à incident et continuité d’activité. L’étiquette "IA" ne dispense pas de ces fondamentaux.

Les achats deviennent un point de contrôle stratégique

Beaucoup d’organisations découvriront leur niveau réel de dépendance lorsqu’elles chercheront les informations nécessaires auprès de leurs fournisseurs.

Avant d’adopter une solution importante, il devient pertinent de savoir quelle version de modèle est utilisée, quel rôle le fournisseur revendique au regard de l’AI Act, quelle documentation est disponible, comment les prompts et sorties sont conservés, si les données peuvent être réutilisées pour l’entraînement, quels sous-traitants interviennent, où les traitements sont réalisés, comment les changements de modèle sont notifiés et quelles garanties existent en cas d’incident.

La réversibilité mérite la même attention. Une organisation ne devrait pas découvrir au moment d’un changement de fournisseur qu’elle ne peut ni exporter ses données, ni reconstituer les décisions prises, ni savoir quelle version du système a produit un résultat.

Les contrats devraient donc traiter la sécurité, la conservation, la localisation lorsque celle-ci est pertinente, les changements significatifs, la disponibilité de la documentation, les mécanismes de transparence, l’assistance en cas de contrôle, les responsabilités et les conditions de sortie.

L’enjeu est moins de créer une "clause AI Act" générique que de contractualiser les dépendances qui auront réellement un effet sur le risque.

Une feuille de route plus utile qu’une checklist

Pour une organisation qui commence aujourd’hui, la première étape n’est pas de produire cent pages de politique interne. Elle consiste à créer un système de décision suffisamment simple pour être utilisé.

Dans les 30 prochains jours

L’objectif devrait être de nommer un responsable de la coordination, de recenser les principaux usages déclarés et non déclarés, d’identifier ceux qui touchent des données personnelles, confidentielles ou stratégiques, et de qualifier les fournisseurs les plus structurants. Les usages manifestement incompatibles avec la politique interne ou insuffisamment maîtrisés doivent être traités immédiatement plutôt que placés dans une liste à revoir plus tard.

Dans les 90 jours

Le registre doit devenir exploitable : propriétaire du système, finalité, fournisseur, modèle ou service, catégories de données, rôle de l’organisation, niveau de risque estimé, obligations identifiées, décision d’autorisation et prochaine date de revue. Une procédure d’homologation proportionnée peut alors éviter que chaque nouvel outil reparte de zéro. C’est également à ce stade qu’une politique d’utilisation acceptable, une littératie différenciée et des exigences contractuelles communes commencent à produire de la valeur.

Avant le 2 décembre 2026

Les fournisseurs concernés par l’article 111(4) doivent avoir traité la transition vers l’article 50(2). Les acteurs potentiellement concernés par les nouvelles interdictions de l’article 5 doivent avoir vérifié leurs fonctionnalités et leurs garde-fous. Les organisations qui publient ou diffusent des contenus générés doivent aussi vérifier que leurs processus de transparence fonctionnent réellement, pas uniquement qu’ils existent dans une procédure.

Avant 2027 et 2028

Pour les systèmes susceptibles d’être classés à haut risque, les travaux les plus lourds ne doivent pas commencer au dernier trimestre précédant l’échéance. Gestion des risques, gouvernance des données, documentation technique, journalisation, supervision humaine, précision, robustesse et cybersécurité nécessitent souvent des choix d’architecture et des preuves accumulées dans le temps. Le délai supplémentaire doit être utilisé pour construire ces mécanismes, pas pour repousser la qualification.

Mesurer la gouvernance plutôt que compter les réunions

Une gouvernance devient pilotable lorsqu’elle produit quelques indicateurs simples. Le nombre de comités IA organisés n’est pas le meilleur d’entre eux.

Une direction peut suivre la proportion d’usages recensés disposant d’un propriétaire identifié, le nombre d’outils non homologués détectés, la proportion des fournisseurs critiques ayant remis la documentation attendue, le pourcentage des populations ayant reçu une littératie adaptée à leur rôle, le délai moyen de qualification d’un nouveau cas d’usage, le nombre d’incidents ou quasi-incidents, ou encore la part des systèmes disposant d’une procédure de retrait et d’une date de revue.

Ces indicateurs n’ont aucune valeur réglementaire universelle. Ils servent à répondre à une question de gouvernance : sommes-nous capables de démontrer que notre dispositif fonctionne réellement ?

C’est une différence importante. Un registre parfaitement rempli mais jamais revu devient vite une archive. Une politique IA que personne ne connaît reste un document. Une formation sans lien avec les usages réels crée une preuve d’activité, pas nécessairement une maîtrise du risque.

Le bon livrable n’est plus un calendrier, c’est une capacité de preuve

Le calendrier 2026-2028 reste indispensable parce qu’il empêche de confondre ce qui est déjà applicable avec ce qui a été différé. Mais la véritable maturité se situe ailleurs.

Une organisation doit progressivement être capable de montrer quels systèmes elle utilise, pour quelles finalités, qui en est responsable, quel rôle juridique elle assume, comment elle a qualifié le risque, quelles données circulent, quels fournisseurs interviennent, quelles mesures de sécurité ont été prises et quand l’ensemble a été revu pour la dernière fois.

Cette capacité de preuve est aussi une capacité de pilotage. Elle permet de désactiver un outil devenu trop risqué, d’expliquer une décision, de changer de fournisseur, de répondre à un incident, de préparer un contrôle ou simplement de savoir où l’entreprise dépend réellement d’un modèle externe.

L’AI Act n’a donc pas été repoussé à 2028. Il est déjà là, mais il ne s’applique pas partout de la même manière ni au même moment. Le changement de calendrier de juillet 2026 rend cette distinction encore plus importante.

La question stratégique n’est plus : "quand devons-nous être conformes ?"

Elle devient : "pouvons-nous démontrer, pour chaque système important, que nous savons ce qu’il fait, pourquoi nous l’utilisons, quel risque nous acceptons et quelles mesures nous avons réellement mises en place ?"

C’est probablement là que commence la gouvernance de l’IA.

Pour aller plus loin

• ENISA, Artificial Intelligence Cybersecurity Challenges — repères sur les enjeux de cybersécurité liés aux systèmes d’IA.
• NIST, Artificial Intelligence Risk Management Framework — cadre méthodologique complémentaire de gestion des risques IA, non substitut au droit européen.