Omnibus : le report de l’AI Act ne solde rien

Le règlement omnibus (UE) 2026/1744 repousse les obligations de l’AI Act sur les systèmes à haut risque au 2 décembre 2027 pour l’annexe III et au 2 août 2028 pour l’annexe I. Il déplace certaines échéances et modifie aussi des dispositions déjà applicables, notamment la littératie.

Un règlement « omnibus » est un texte qui modifie plusieurs actes existants d’un seul geste, ici pour en simplifier ou en décaler l’application. Le règlement (UE) 2026/1744, entré en vigueur le 27 juillet 2026, agit ainsi sur le calendrier du règlement sur l’intelligence artificielle.

Les obligations relatives aux systèmes à haut risque autonomes de l’annexe III, recrutement, crédit, éducation, accès aux services essentiels, passent du 2 août 2026 au 2 décembre 2027. Celles relatives à l’IA intégrée dans des produits déjà réglementés, annexe I, passent du 2 août 2027 au 2 août 2028.

Le tableau se lit d’abord par ses premières lignes : ce sont elles que la lecture rapide oublie.

Le report de l’AI Act ne décale aucune des échéances déjà passées : pratiques interdites, littératie IA, modèles d’usage général, gouvernance et sanctions restent applicables à leur date d’origine. C’est le point que la lecture rapide manque.

Les pratiques interdites et l’obligation de littératie IA s’appliquent depuis le 2 février 2025. Le chapitre des modèles d’usage général, la gouvernance et le chapitre des sanctions s’appliquent depuis le 2 août 2025, avec leurs transitions ; l’article 101 sur les amendes des fournisseurs de modèles fait exception à cette date. Le report ne suspend pas les obligations déjà applicables.

Le même règlement touche pourtant deux de ces volets, et pas dans le sens d’un allègement général. Il ajoute à l’article 5 deux pratiques interdites, la production de contenus intimes non consentis et de matériel pédopornographique, applicables au 2 décembre 2026. Il réécrit aussi l’article 4 : fournisseurs et déployeurs doivent désormais prendre des mesures pour favoriser la maîtrise de l’IA, sans obligation de garantir un niveau spécifique.

Autrement dit : l’obligation d’agir sur la formation des équipes reste exigible aujourd’hui, même allégée dans sa formulation, alors que la mise en conformité des systèmes à haut risque ne l’est pas encore. C’est l’inverse de ce que beaucoup d’organisations ont retenu. Le détail de cette obligation souvent ignorée figure dans la littératie IA, l’obligation passée inaperçue.

Le chapitre des sanctions conserve sa date d’application, avec ses exceptions et ses règles propres : il faut rattacher chaque sanction à une obligation effectivement applicable. La lecture complémentaire sanctions de l’AI Act aide à distinguer ces niveaux.

Préparer la conformité avant décembre 2027 permet de conserver les preuves de conception et d’exploitation au moment où elles existent, sans devoir les reconstruire après coup.

• L’inventaire dépend du périmètre. Les outils adoptés sans déclaration à la direction informatique doivent être recherchés, sans présumer leur nombre.
• La traçabilité est une propriété d’architecture. L’ajouter en exploitation peut demander de reprendre les flux, les contrats de données et les tests.
• La documentation technique se perd. Reconstituer les raisons d’une décision prise deux ans plus tôt suppose de retrouver celui qui l’a prise.
• Les clients n’attendent pas le régulateur. Des exigences contractuelles peuvent figurer dans les appels d’offres ou les revues d’investisseurs avant les échéances réglementaires.

Les pièces de conformité qui se datent, analyse de risque, journaux, décisions de conception, ne se produisent pas rétroactivement, et le report de l’AI Act ne change rien à cette propriété. C’est l’argument qui clôt la discussion.

Une analyse de risque menée avant mise en service ne se rédige pas après : elle porte sur une décision passée. Des journaux absents ne se reconstituent pas ; une reconstruction doit être identifiée comme telle et ne remplace jamais les traces originales.

Une organisation qui attend se retrouvera donc, à la nouvelle échéance, exactement dans la situation où elle est aujourd’hui : avec moins de temps. L’ordre de priorité figure dans ce qui doit exister avant l’échéance.

Prenons un exemple générique. Un outil de présélection de candidatures mis en service à l’automne 2026 peut relever de l’annexe III. Son calendrier doit aussi être lu avec l’article 111 : pour les systèmes antérieurs à l’échéance pertinente, des changements significatifs de conception après cette date conditionnent l’application du régime, sous ses exceptions. Le report ne permet donc pas de conclure automatiquement à une obligation complète en décembre 2027. Conservez néanmoins l’évaluation et les décisions de conception : elles servent l’exploitation et la qualification juridique.

Le délai accordé par le report de l’AI Act s’utilise comme un budget de temps : activer la journalisation, constituer l’inventaire, rédiger les fiches et concevoir conformes les systèmes construits dès maintenant. C’est la seule lecture qui rende le report utile plutôt que dilatoire.

Je recommande de consacrer ce délai à l’inventaire et à la qualification du rôle système par système, puis d’intégrer traçabilité et supervision dans ce qu’on construit maintenant. Un système encore exploité à la nouvelle échéance devra être évalué selon ses obligations propres, sans présumer que sa conception actuelle les satisfait toutes.

La séquence que je recommande tient en cinq étapes :

1. Activer la journalisation sur chaque système en exploitation. Définissez les événements nécessaires, les droits et la durée de conservation ; des journaux absents ne deviendront pas des traces contemporaines après coup.
2. Constituer l’inventaire. Nommer un responsable, croiser achats et usages déclarés, puis consigner les systèmes identifiés et ceux qui restent à vérifier.
3. Qualifier le rôle de l’organisation pour chaque système : fournisseur, déployeur, ou les deux, et l’annexe éventuellement concernée.
4. Rédiger les fiches avec l’équipe qui a construit ou intégré le système. La méthode est décrite dans écrire la fiche d’un système d’IA.
5. Intégrer traçabilité et supervision humaine dans tout nouveau développement, plutôt que de les ajouter après la mise en service.

La durée de ces chantiers dépend du portefeuille ; leur utilité opérationnelle précède leur éventuelle exigibilité réglementaire. La séquence complète figure dans préparer un contrôle de conformité en deux semaines. Pour un regard extérieur sur l’existant, un audit IA part précisément de cet inventaire.

Un inventaire des systèmes d’IA est exploitable lorsqu’une personne peut retrouver, pour chaque outil, sa finalité, ses données, son responsable et les pièces qui étayent ces informations.

Combien de temps nous faudrait-il, aujourd’hui, pour produire la liste complète des systèmes d’IA que nous exploitons, avec leur finalité et les données qu’ils touchent ? Si la réponse dépasse une journée, le sujet n’est pas le calendrier européen. C’est la visibilité interne.

L’erreur la plus fréquente consiste à lire le report de l’AI Act comme un moratoire général, alors qu’il ne vise que les obligations à haut risque des annexes III et I. Les autres erreurs en découlent.

• Suspendre la formation des équipes. L’obligation de littératie s’applique depuis février 2025 ; sa reformulation par l’omnibus en assouplit le niveau attendu, pas l’existence. Ne rien faire reste un manquement. Une formation IA peut contribuer aux mesures adaptées au rôle des personnes ; le texte n’impose pas à lui seul un programme unique.
• Croire que la liste des pratiques interdites est figée. L’omnibus l’allonge ; le filtre doit être repassé sur les systèmes génératifs avant le 2 décembre 2026.
• Geler l’inventaire en attendant des précisions. L’inventaire ne dépend d’aucune précision réglementaire : il décrit ce que l’organisation exploite déjà.
• Reporter la journalisation au motif que la traçabilité n’est exigée qu’en 2027. Les journaux de 2026 ne pourront pas être produits en 2027.
• Confondre date d’exigibilité et date de conception. Une supervision adaptée peut être requise ; sa présence ne prouve pas que toutes les obligations du système sont satisfaites. Le sujet est développé dans la supervision humaine, la concevoir et non la promettre.
• Ignorer les exigences contractuelles. Les engagements d’achat ou de financement doivent être examinés avec leurs propres échéances.

D’autres contresens circulent sur le texte lui-même ; ils sont recensés dans quatre idées reçues sur l’AI Act.

Le filtre à appliquer au portefeuille est présenté dans pratiques interdites : ce qu’aucun garde-fou ne rattrape.

Un système bien conçu dispose déjà de traces et de mécanismes de supervision utiles à sa conformité, mais ces éléments ne dispensent pas de qualifier ses obligations exactes. Dans mes missions, je les demande d’abord pour l’exploitation.

Comprendre un incident, expliquer une réponse et corriger un comportement demandent ces mécanismes, décrits dans l’observabilité des systèmes d’IA. Il faut ensuite examiner les autres pièces requises : gestion des risques, données, documentation, information des utilisateurs et responsabilités contractuelles.

Le report peut donner du temps pour compléter ce dossier ; il ne transforme pas automatiquement une bonne architecture en conformité juridique démontrée.