Sophie a passé quatre mois à cartographier les systèmes IA de son organisation. Documentation des modèles, traçabilité des données d'entraînement, registres de risque. Tout ça pour être prête au 2 août 2026.
Le 7 mai, l'accord provisoire sur le Digital Omnibus est annoncé. L'échéance pour les systèmes à haut risque, ceux de l'Annexe III, passe à décembre 2027. Dix-huit mois de plus.
Sophie a refermé son fichier Excel. Et elle a fait exactement ce que font la majorité des organisations dans ce cas.
Elle attend.
"Haut risque" : de quoi parle-t-on vraiment ?
L'AI Act ne concerne pas tous les systèmes IA. Il cible ceux qui influencent des décisions à fort impact sur les personnes. L'Annexe III en dresse la liste : recrutement, attribution de crédit, tarification en assurance, accès aux services publics, gestion d'infrastructures critiques. Si un système IA pèse sur l'une de ces décisions, il entre dans le périmètre.
La liste est souvent plus courte qu'on ne le croit. Et plus critique qu'on ne l'imagine. Un outil de scoring RH, un algorithme de tarification, un système de priorisation des dossiers : ce sont ces systèmes-là qui sont visés. Pas le chatbot du service client.
Ce que le Digital Omnibus a changé, c'est uniquement la date. L'accord provisoire du 7 mai 2026 repousse l'échéance pour les systèmes Annexe III d'août 2026 à décembre 2027. Ce que le report ne change pas : les obligations elles-mêmes. Traçabilité des données d'entraînement, documentation des modèles, supervision humaine effective, explicabilité des décisions. Tout le cadre réglementaire reste intact. Seule l'horloge a bougé.
| Étape | Avant | Après Digital Omnibus |
|---|---|---|
| Entrée en vigueur | Août 2024 | Inchangé |
| IA interdites applicables | Fév 2025 | Inchangé |
| GPAI & gouvernance | Août 2025 | Inchangé |
| Haut risque · Annexe III | Août 2026 | Déc 2027 |
Source : accord provisoire Digital Omnibus · 7 mai 2026
Les trois obligations data que le report ne supprime pas
Pour chaque système à haut risque, l'AI Act exige de prouver trois choses. Ce sont ces trois preuves que les équipes data et conformité doivent être en mesure de produire en décembre 2027.
Que les données d'entraînement étaient appropriées. Représentatives du cas d'usage, documentées, vérifiées pour les biais potentiels. Si l'algorithme de scoring crédit a été entraîné sur des données de 2018, il faut pouvoir expliquer pourquoi ce choix était pertinent. Et ce qu'on a fait pour identifier les angles morts de ce jeu de données.
Que le modèle se comporte comme prévu en production. La traçabilité couvre les décisions prises en production : qui a supervisé quoi, sur quelle base, avec quel niveau de contrôle humain effectif. Un humain doit pouvoir comprendre, interpréter et contester chaque décision produite par le système.
Que les décisions peuvent être expliquées à un non-technicien. Pas dans un notebook Jupyter. Dans un format qu'un responsable métier peut défendre devant un auditeur, ou devant un client dont la demande a été refusée. L'explicabilité n'est pas une fonctionnalité technique. C'est une obligation de communication.
On observe ça chez la majorité de nos clients : les pipelines de données existent et fonctionnent. La documentation de ces pipelines, elle, est absente ou incomplète. Ou dans la tête d'un consultant parti six mois plus tôt. Trois chiffres pour cadrer l'enjeu : 88 % des entreprises utilisent l'IA dans au moins une fonction (McKinsey, 2025), 33 % seulement parviennent à la déployer à l'échelle, et les infractions graves à l'AI Act sont plafonnées à 7 % du chiffre d'affaires mondial. Le principal frein au déploiement à l'échelle, c'est rarement la performance du modèle. C'est la gouvernance de la donnée qui l'alimente. Et l'incapacité à en rendre compte.
L'AI Act ne crée pas ce problème. Il le nomme. Et à partir de décembre 2027, il le rend coûteux. Pour aller plus loin sur la documentation des données et la traçabilité technique, notre article sur la traçabilité IA Act et les obligations data détaille les exigences par type de système.
Conformité et data : le pont que personne ne construit
On a souvent un Chief Data Officer, un DPO, une équipe conformité et une équipe data engineering. Ces quatre entités doivent aujourd'hui collaborer pour démontrer la conformité AI Act sur les systèmes à haut risque. Elles parlent des langues différentes. Vocabulaire, outils, priorités : rien n'est aligné par défaut.
La conformité parle d'articles de loi et de registres de risque. L'équipe data parle de pipelines, de qualité de données et de data lineage. Le CDO parle de feuille de route et de budget. La direction métier veut juste que le système continue à fonctionner.
Quand Sophie a cartographié ses systèmes au premier trimestre 2026, elle a produit un excellent travail de conformité. Ses data engineers, pendant ce temps, continuaient à faire évoluer les pipelines. Le lien entre les deux projets n'a jamais été établi. La cartographie de Sophie est déjà partiellement obsolète.
C'est là que ça coince. Pas dans la technique. Les outils existent : Unity Catalog, Collibra, OpenMetadata permettent d'automatiser la traçabilité et d'alimenter un catalogue en continu. Sur la maturité de ces dispositifs côté données, notre article sur la fiabilité automatisée et la Data Observability pose les mécanismes concrets, depuis le contrat de donnée jusqu'au Data Catalog. Le problème n'est pas technique. Il est dans la communication entre ceux qui construisent les systèmes et ceux qui doivent en rendre compte.
Documenter une décision algorithmique dans un langage décisionnel. Expliquer la traçabilité d'une donnée à un auditeur non-technique. Créer des ponts entre la gouvernance et l'engineering. Ce ne sont pas des tâches de data scientist. Ce sont des tâches de communication. Et c'est là que les organisations ont le plus de retard.
La conformité réglementaire met à nu le même problème, à chaque fois. Les données sont là. Les systèmes tournent. Personne n'a été désigné pour faire le pont entre ceux qui les construisent et ceux qui doivent en rendre compte.
Ce qu'on peut faire maintenant
Le report donne du temps. Voici comment ne pas le gâcher. Trois actions concrètes, sans nécessiter un budget conformité dédié.
Cartographier les systèmes IA à impact décisionnel réel. Pas tous les outils. Ceux qui influencent le recrutement, la tarification, l'accès à un service, l'attribution d'un crédit. La liste des systèmes réellement à haut risque au sens de l'AI Act est souvent plus courte qu'on ne le croit. Et plus critique qu'on ne l'imagine. C'est par là que commence la conformité utile.
Documenter les données d'entraînement pendant qu'on a le contexte. Les personnes qui savent pourquoi on a utilisé ce jeu de données en 2021 sont encore dans l'organisation. Dans 18 mois, peut-être pas. La documentation se fait pendant qu'on peut encore poser les questions. Pas six semaines avant la date limite.
Construire un langage commun entre conformité et équipes data. Pas une formation de deux jours. Un glossaire de travail co-construit qui permet à une responsable conformité de poser les bonnes questions à un data engineer. Et d'obtenir des réponses utilisables par un auditeur. Ce pont-là ne se construit pas en urgence. Sur ce sujet précis, notre article sur la gouvernance fédérée de la donnée pose le modèle de responsabilisation qui rend ce dialogue structurellement possible.
Ces trois actions ne dépendent pas du calendrier réglementaire. Elles construisent une fondation utile quelle que soit la date finale. Et qui servira bien au-delà de l'AI Act.
Sophie a rouvert son fichier Excel le lendemain
Pas parce que le règlement le lui imposait encore. Parce qu'elle avait compris que 18 mois, c'est exactement le temps qu'il faut. Cartographier pendant que les équipes sont encore là. Documenter pendant que le contexte existe. Construire le pont qu'elle n'avait pas eu le temps de construire.
Le report n'est pas une victoire. C'est une parenthèse.
La question, c'est ce qu'on met dedans.