Le Digital Omnibus n'est pas une amnistie

Il y a un moment précis, ces dernières semaines, qui mérite qu’on le regarde de près. C’est celui où, à l’intérieur d’une entreprise IT de taille moyenne ou petite qui avait enfin commencé à prendre l’AI Act au sérieux (quelqu’un qui avait commencé à cartographier les systèmes, à poser des questions gênantes aux fournisseurs de modèles, à écrire les premières lignes d’une DPIA), arrive la nouvelle : reporté. Et avec la nouvelle arrive, ponctuelle, la phrase qui l’accompagne : « Tu vois ? Je te disais bien qu’il n’y avait pas le feu. »

Cette phrase est le vrai risque de ce mois de juin 2026. Pas le règlement, pas les dates, pas Bruxelles. Cette phrase.

Parce qu’elle est fausse. Elle est fausse sur les faits, elle est fausse sur le plan stratégique, et elle est fausse, surtout, sur le plan de ce qui devrait mouvoir quiconque construit du logiciel qui pèse sur la vie des gens. Démontons-la pièce par pièce.

Ce qui s’est vraiment passé

Le 16 juin 2026, le Parlement européen a donné son approbation finale au dénommé Digital Omnibus on AI : un règlement qui modifie certaines dispositions du Règlement (UE) 2024/1689 (l’AI Act), au sein du septième paquet de simplification voulu par la Commission. Le vote est passé avec une marge très large : 423 voix pour, 57 contre, 174 abstentions. Le texte n’est pas encore en vigueur : il manque l’adoption formelle du Conseil, attendue d’ici fin juin. Mais la direction est claire, et il vaut mieux la lire correctement avant d’en faire le mauvais prétexte.

La partie qui a fait les titres, c’est le report des obligations sur les systèmes à haut risque. Avec une différence importante par rapport à la proposition initiale : désormais les dates sont fixes, plus conditionnées à la publication des normes harmonisées.

• Les systèmes à haut risque autonomes (ceux de l’annexe III : biométrie, emploi, éducation, crédit, services essentiels, justice, gestion des frontières) s’appliqueront à partir du 2 décembre 2027.
• Les systèmes à haut risque intégrés comme composants de sécurité dans des produits déjà encadrés par une législation sectorielle (annexe I) ont jusqu’au 2 août 2028.
• L’obligation de marquage des contenus générés par l’IA (l’article 50(2) : watermarking lisible par la machine) glisse au 2 décembre 2026.
• L’instauration des bacs à sable réglementaires nationaux est déplacée au 2 août 2027.

Et puis il y a tout le reste. Qui est exactement le sujet.

La partie que personne n’a mise en une : ils ont ajouté des interdictions

Pendant qu’on discutait de reports, le même texte a introduit une nouvelle interdiction parmi les pratiques prohibées par l’article 5. Sont désormais interdits les systèmes d’IA qui génèrent du matériel pédopornographique (CSAM) et ceux qui créent, sans consentement, des images, vidéos ou audios représentant les parties intimes d’une personne identifiable ou ses activités sexuellement explicites : les fameuses applications nudifier, les deepfakes pornographiques. L’interdiction frappe tant celui qui met ces systèmes sur le marché que celui qui les utilise, et n’admet qu’une seule porte de sortie, un safe harbour technique, pour les systèmes dotés de garde-fous efficaces qui empêchent en amont ce type de sortie. Délai pour se conformer : le 2 décembre 2026.

Arrêtez-vous une seconde là-dessus. Dans un texte vendu comme « simplification » et « réduction des charges », l’Union a trouvé le temps et la majorité pour resserrer. Pour élargir le périmètre des pratiques interdites. Pour dire, noir sur blanc, qu’il existe des choses qui ne se font tout simplement pas, indépendamment du coût que l’interdiction impose aux entreprises.

Ce n’est pas la grammaire d’un législateur qui fait marche arrière sur les droits. C’est la grammaire d’un législateur qui confirme l’architecture et, là où il en avait besoin, la renforce. Qui lit le report des échéances sur le haut risque comme un signe d’« assouplissement » lit la moitié de la phrase et ignore l’autre moitié, celle écrite en gras.

Le report est procédural, le cap est confirmé

La distinction que toute équipe technique devrait intérioriser est celle-ci : c’est l’horloge qui a changé, pas la carte.

La logique fondée sur le risque de l’AI Act est intacte. Les catégories de risque sont les mêmes. Les obligations de transparence, de gouvernance des données, de documentation technique, de supervision humaine, de gestion des incidents : elles sont toutes encore là, sous la même forme. La plupart des dispositions du règlement (y compris celles de transparence de l’article 50, sauf le paragraphe sur le watermarking) entrent quand même en application le 2 août 2026. C’est-à-dire dans quelques semaines.

Et c’est là la première erreur, banale, de qui tire le frein : il confond « certaines échéances sur le haut risque ont été reportées » avec « l’AI Act a été reporté ». Ce n’est pas le cas. L’essentiel du règlement démarre comme prévu. Si vos systèmes ne sont pas à haut risque (et statistiquement la majorité ne l’est pas), le report du haut risque ne vous concerne presque pas. Ce qui vous concerne, en revanche, ce sont les dates qui n’ont pas changé.

Il y a plus, et il faut le dire à qui connaît la gestion de projet : les dates fixes sont un cadeau, pas une concession. Pendant deux ans, le grand alibi a été « on ne peut pas se préparer sérieusement tant que les normes harmonisées ne sont pas sorties ». Maintenant cet alibi est mort. Les échéances ne dépendent plus des normes. Elles sont là, écrites, immobiles. Vous pouvez les mettre dans un Gantt et ne plus jamais les déplacer. La certitude de planification que les entreprises réclamaient à grands cris est arrivée : utilisez-la pour planifier, pas pour reporter.

Le travail difficile n’a pas d’échéance que l’on peut déplacer

C’est le cœur de la question, et cela vaut pour toute entreprise de développement, de la software house de huit personnes à l’intégrateur régional.

La partie coûteuse de la compliance à l’AI Act, ce n’est pas le modèle de documentation. Ce n’est pas le PDF à signer. La partie coûteuse, c’est trouver chaque système d’IA dans sa propre organisation et ses propres produits, décider dans quelle catégorie de risque tombe chacun et, surtout, maintenir cet inventaire vivant pendant que l’équipe continue de livrer des fonctionnalités toutes les deux semaines. C’est un travail d’archéologie technique et de discipline de processus. Il ne dépend pas des normes finales. Il ne devient pas plus facile avec le temps : il devient plus difficile, parce qu’entre-temps les systèmes grandissent, se stratifient, changent de fournisseur de modèle, héritent de dépendances.

Qui commence aujourd’hui dispose d’environ dix-huit mois pour affiner un inventaire, une classification, une pipeline de documentation qui se met à jour toute seule. Qui commence fin 2027 aura des semaines, pas des mois. Et il le fera dans la panique, avec une direction qui demande pourquoi on n’en a pas parlé plus tôt, et avec des clients qui ont entre-temps déjà mis la compliance dans leurs cahiers des charges.

Le report, autrement dit, ne déplace pas la fatigue vers l’avant. Il ne déplace vers l’avant que la perception de la fatigue. La fatigue reste là, identique, et elle court ses intérêts pendant que vous l’ignorez.

Le piège de l’« exemption de fait »

Il y a ensuite un argument plus subtil, et honnêtement plus insidieux, qu’il vaut mieux regarder en face. Plusieurs organisations de la société civile ont fait remarquer que le report risque de créer une fenêtre d’exemption de fait : les systèmes à haut risque mis sur le marché avant les nouvelles dates pourraient rester hors de l’application pleine du règlement jusqu’à ce qu’ils soient modifiés de façon substantielle. Traduit pour une entreprise : « si je me dépêche de sortir le système maintenant, je me glisse dans la fenêtre et je m’épargne les obligations. »

C’est une tentation que je comprends. Et c’est exactement le type de raccourci qui, en trois ans, se retourne contre vous.

Premièrement, parce que c’est un pari sur une interprétation contestée : ceux qui crient à la faille aujourd’hui sont précisément les organisations qui demain feront de l’advocacy, des signalements, du naming and shaming. Vous construisez un produit dont la conformité repose sur un détail technique que la moitié de l’écosystème attaque déjà. Deuxièmement, parce que l’exemption, à supposer qu’elle tienne, se brise à la première modification substantielle, et dans le logiciel les modifications substantielles sont le métier : vous vous êtes lié les mains sur la roadmap rien que pour ne pas écrire une DPIA. Troisièmement, et c’est le plus important, parce que c’est une posture. C’est la posture de qui traite les droits des personnes comme un coût à contourner plutôt que comme une contrainte de conception. Et les postures, avec le temps, deviennent une culture d’entreprise. Elles deviennent la façon dont vos ingénieurs pensent quand personne ne regarde.

On ne construit pas un avantage concurrentiel durable à l’intérieur d’une fenêtre de trois ans qui se refermera de toute façon. On le construit en faisant les choses de manière à ce qu’elles tiennent quand la fenêtre n’est plus là.

Pour une PME : moins de paperasse ne veut pas dire moins de responsabilité

L’omnibus a réellement allégé quelque chose, et il faut le reconnaître. Les exemptions de certaines obligations prévues pour les PME ont été étendues aux small mid-caps (les entreprises de moyenne capitalisation de taille réduite). L’enregistrement des systèmes que le fournisseur évalue comme non à haut risque (ceux pour lesquels on se prévaut de la dérogation de l’article 6, paragraphe 3) reste obligatoire dans la base de données de l’UE, mais avec un jeu d’informations réduit. Les produits machines qui utilisent l’IA devront se conformer à la seule législation sectorielle de sécurité, sans la double charge. La définition de « composant de sécurité » est plus claire, de sorte que les fonctions d’IA qui se bornent à assister l’utilisateur ou à optimiser les performances ne finissent pas automatiquement dans le cercle du haut risque.

Tout est juste, tout est utile. Mais attention à ne pas confondre deux plans que le législateur a tenus distincts à dessein. Moins de bureaucratie n’est pas moins de responsabilité. L’auto-évaluation de « non haut risque » doit quand même être documentée avant de mettre le système sur le marché, et enregistrée : le régulateur veut savoir qui a décidé de se tenir juste sous le seuil, et pourquoi. La « frontière » reste visible. Simplement, écrire cette évaluation correctement, avec un raisonnement défendable sur l’article 6, devient encore plus central, parce que c’est le document qui vous sauve si quelqu’un conteste la classification.

Pour une PME, c’est en réalité une bonne nouvelle, vue du bon côté : cela veut dire que la barrière d’entrée à la conformité est faite de pensée structurée plus que de formalités coûteuses. Et la pensée structurée est exactement ce qu’une bonne software house sait déjà faire. C’est la même discipline que le développement guidé par les spécifications : définir d’abord ce que tu construis et pourquoi, puis le construire. La compliance, faite ainsi, n’est pas un département séparé. C’est une propriété de la façon dont vous écrivez les choses.

L’échéance la plus proche est déjà au coin de la rue

Pendant que tout le monde regarde 2027 et 2028, l’échéance vivante, celle qui brûle, est bien plus proche : 2 décembre 2026. À partir de cette date, les fournisseurs de systèmes qui génèrent des contenus synthétiques (audio, images, vidéo, texte) doivent garantir que les sorties sont marquées dans un format lisible par la machine et détectables comme artificielles. C’est l’article 50(2). Un peu plus de cinq mois.

Si votre produit contient une quelconque fonction générative destinée au marché européen (un assistant qui écrit des textes, un générateur d’images, une synthèse vocale, un module qui résume des documents en produisant un nouveau contenu), il vous faut, opérationnel d’ici la fin de l’année : un étiquetage visible dans l’interface, des métadonnées lisibles par la machine incorporées à la sortie, et une capacité de détection cohérente. Ce n’est pas trivial. Le considérant 133 cite explicitement le watermark et les méthodes cryptographiques ; la Commission est en train de finaliser un Code of Practice sur le marquage et l’étiquetage qui deviendra la référence pratique. Et si vous intégrez des modèles de tiers (ce que font presque tous), la question à poser à votre fournisseur, aujourd’hui, est précise : comment garantissez-vous la conformité à l’article 50(2), et quelles API de détection m’exposez-vous ? Si vous ne savez pas répondre, vous avez trouvé le premier ticket à ouvrir ce matin.

C’est l’échéance que le débat sur le report obscurcit de façon coupable. Elle est proche, elle est technique, et elle touche la grande majorité des produits qui utilisent l’IA générative. Aucun report ne vous couvre ici.

Le biais sort de la niche du haut risque

Il y a une nouveauté qui mérite plus d’attention qu’elle n’en a reçu, parce qu’elle est à la fois une opportunité et une responsabilité. L’article 10, paragraphe 5, autorise, à titre exceptionnel et dans la mesure strictement nécessaire, le traitement de catégories particulières de données personnelles (les données « sensibles » de l’article 9 du RGPD) pour détecter et corriger les biais dans les systèmes. Jusqu’ici cette possibilité ne valait que pour les systèmes à haut risque. L’omnibus l’étend aussi aux systèmes non à haut risque.

C’est une ouverture qui change le tableau pour quiconque veut offrir des services sérieux de fairness auditing. Cela signifie qu’on peut concevoir un suivi des biais documenté et défendable même sur des systèmes qui ne relèvent pas du haut risque, en alignant AI Act et RGPD sans vivre dans le gris réglementaire. Mais, et c’est là la responsabilité, l’ouverture n’est pas un raccourci pour traiter des données sensibles à volonté. La contrainte de « stricte nécessité » reste, avec tout ce qu’elle implique : une base juridique solide (le considérant 70 renvoie à l’intérêt public important de l’article 9(2)(g) du RGPD), une DPIA, la minimisation, la pseudonymisation, la limitation de la conservation (les données s’effacent une fois le biais corrigé) et une séparation nette, architecturale, entre le jeu de données d’audit et celui de production.

Qui sait faire cela correctement tient entre les mains une offre commerciale concrète, pas une formalité. La différence entre les deux, c’est la qualité de la documentation qui la fait.

La compliance est un fossé, pas une taxe

À ce stade, la question stratégique devient : pourquoi une entreprise IT de taille moyenne ou petite devrait-elle dépenser de l’énergie sur tout cela, maintenant, alors que le marché lui dit qu’elle peut attendre ?

Parce que le marché qui vous dit d’attendre est le même qui, dans dix-huit mois, mettra la conformité à l’AI Act dans chaque appel d’offres de l’administration publique et dans chaque due diligence d’un client grand compte. La compliance n’est pas une taxe qu’on paie à contrecœur. C’est un fossé concurrentiel. Au moment où la majorité de vos concurrents utiliseront le report comme excuse pour ne pas bouger, qui a bougé arrive à l’appel d’offres avec un inventaire des systèmes, une classification défendable, une pipeline de documentation et une histoire à raconter. Les autres arrivent avec une promesse.

Dans un secteur où la confiance est rare et difficile à démontrer, pouvoir dire « ce travail, nous l’avons déjà fait, voici les documents » vaut plus que n’importe quelle présentation commerciale. C’est la version adulte du « security by design » : la compliance by design comme signal de sérieux technique. Et pour une PME, qui ne peut pas rivaliser sur le prix avec les grands ni sur le marketing, le sérieux technique démontrable est l’un des rares leviers qui fonctionnent vraiment.

Les droits des personnes n’ont pas de date d’application

Je retire l’habit du consultant et je mets celui que je porte plus volontiers.

Sous toute la discussion sur les échéances et les annexes, il y a une chose simple. Les systèmes que nous construisons décident si une personne obtient un entretien, un prêt, une place sur une liste, un soin. Ils touchent la dignité d’êtres humains qui ne savent presque jamais qu’ils ont été traités par un modèle, et n’ont presque jamais le moyen de le contester. L’AI Act, avec tous ses défauts et ses compromis, est la tentative la plus sérieuse à ce jour de mettre ces systèmes sous une règle qui place la personne au centre au lieu de la sortie.

Le report déplace la date à laquelle certaines obligations deviennent exigibles. Il ne déplace pas d’un seul jour le moment où un système mal conçu fait du mal à quelqu’un. Ce moment, c’est maintenant, chaque fois que le système tourne. Le fait que l’État ne puisse pas encore vous sanctionner pour une certaine carence ne signifie pas que la carence ne produise pas de conséquences sur des personnes réelles. La conformité formelle arrive en 2027 ; le devoir envers qui se trouve de l’autre côté de l’écran est déjà là, et il n’a jamais eu de grace period.

Il y a une façon humaniste, et non bureaucratique, de lire l’AI Act : comme la liste, écrite mal et à grand-peine, des choses que nous nous devons les uns aux autres quand nous déléguons des décisions à une machine. Lue ainsi, l’idée d’« exploiter la fenêtre » pour en faire moins sonne pour ce qu’elle est : pas une astuce de gestion, mais une petite lâcheté de conception. Et les entreprises, exactement comme les personnes, finissent par ressembler aux raccourcis qu’elles s’autorisent.

Quoi faire maintenant, concrètement

Si vous êtes l’équipe qui venait juste de commencer à pousser, voici la liste pour ne pas perdre l’élan. Rien d’exotique : des choses qu’on peut commencer cette semaine.

1. Fixez les dates qui n’ont pas changé. Mettez le 2 août 2026 (l’essentiel des obligations) et le 2 décembre 2026 (watermarking et interdiction nudifier/CSAM) dans le plan, en gras, non déplaçables. Ce sont les prochaines, pas celles de 2027.
2. Inventoriez chaque système d’IA. Dans les produits, dans les processus internes, dans les intégrations avec des modèles de tiers. Une feuille vivante, avec un responsable, un fournisseur de modèle, une catégorie de risque provisoire. C’est le document dont dépend tout le reste.
3. Classez, et écrivez le pourquoi. Pour chaque système, une évaluation de risque. Pour ceux que vous déclarez « non à haut risque » au titre de l’article 6(3), un raisonnement défendable et l’enregistrement (désormais plus léger) dans la base de données de l’UE.
4. Fermez le front du watermarking. Pour chaque fonction générative destinée au marché de l’UE : étiquette dans l’interface, métadonnées lisibles par la machine, détection. Et ouvrez le ticket au fournisseur du modèle : « comment garantissez-vous l’article 50(2) ? ».
5. Mettez en œuvre le safe harbour sur la génération d’images. Si un composant génère des images ou des vidéos, les garde-fous contre les NCII et le CSAM se conçoivent et se documentent dans le risk management, ils ne s’ajoutent pas après coup.
6. Transformez le bias auditing en une offre. Avec l’extension de l’article 10(5) au non-haut-risque, construisez une pipeline AI-Act-plus-RGPD documentée : DPIA, séparation des jeux de données, effacement une fois la correction faite. C’est vendable.
7. Structurez le cycle de vie des modèles. Data lineage, model cards, documentation technique, journalisation. Utilisez les dix-huit mois pour le construire comme une pratique, pas pour le reporter comme une corvée.

Le pari européen, et le nôtre

L’Europe a fait un pari explicite : qu’on puisse construire une industrie de l’IA compétitive sans brader les droits des personnes, et que le respect de ces droits puisse même devenir un trait distinctif du produit européen. C’est un pari difficile, fait de compromis imparfaits comme cet omnibus, et rien ne garantit qu’il le gagne. Mais c’est le nôtre, et il est infiniment plus intéressant que l’alternative.

Le Digital Omnibus, bien lu, n’affaiblit pas ce pari : il le confirme et en fixe le calendrier. Il nous a donné quelques mois de plus non pour que nous fassions moins, mais pour que nous fassions mieux les choses qui doivent être faites de toute façon. C’est une fenêtre pour arriver préparés, pas une amnistie pour ne pas se présenter.

Pour une entreprise IT de taille moyenne ou petite qui venait juste de prendre tout cela au sérieux, le message est un seul, et il faut le dire à voix haute lundi matin en réunion : ce n’est pas le moment de lever le pied de l’accélérateur. C’est le moment d’appuyer plus fort. Parce que le travail difficile n’expire pas, les droits des personnes n’ont pas de grace period, et dans dix-huit mois il y aura ceux qui sont arrivés avec les documents en main et ceux qui sont arrivés avec des excuses. Décidez aujourd’hui de quel côté vous voulez être.

L'auteur

Andrea MargiovanniIA

Je suis le rapport entre IA et régulation européenne comme un fait politique, pas comme un spectacle technique. Je travaille avec des équipes qui doivent la rendre compatible avec AI Act, CRA, NIS2 sans réduire la conformité à une liste à cocher.

Voir le parcours →