AIPD : des risques à mesurer, des arbitrages à assumer
AIPD : des risques à mesurer, des arbitrages à assumer
Note - publiée le 7 mai 2026
Note - publiée le 7 mai 2026
I. Avant d’arbitrer un risque, il faut d’abord comprendre le traitement réel
Le premier risque d’une AIPD, ce n’est pas de mal remplir une matrice. C’est de mal comprendre le traitement. On peut avoir une grille de cotation propre, des niveaux de gravité, des scores, des mesures, des cases parfaitement alignées. Si le traitement analysé est mal délimité, si sa finalité réelle est floue, si les acteurs sont mal identifiés, si les flux sont incomplets ou si le fonctionnement opérationnel est raconté de manière trop idéale, alors toute l’analyse repose déjà sur une base fragile.
L’AIPD concerne les traitements susceptibles d’engendrer un risque élevé pour les droits et libertés des personnes concernées. Elle n’est donc pas seulement un exercice documentaire : elle doit permettre de construire et documenter un traitement conforme au RGPD et respectueux de la vie privée.
Mais pour analyser correctement un risque, encore faut-il savoir de quoi l’on parle. Un traitement ne se résume pas à son nom dans un registre. Il faut identifier ce qu’il fait concrètement : quelles données sont collectées, auprès de qui, par quel canal, pour quelle finalité, par quels outils, avec quels accès, quels destinataires, quelles durées de conservation, quels sous-traitants, quels exports éventuels, quels environnements de stockage, et quel périmètre exact est couvert par l’analyse.
C’est une étape moins spectaculaire que la cotation des risques. Mais elle est déterminante. Une AIPD qui part d’un traitement mal cadré risque d’évaluer un objet qui n’existe pas vraiment, ou qui ne correspond pas à la réalité du terrain.
La finalité doit notamment être formulée de manière concrète. Une formule vague du type “gestion”, “amélioration du service” ou “sécurisation du dispositif” ne suffit pas. Elle donne une direction générale, mais elle ne permet pas toujours de comprendre ce que le traitement fait réellement aux personnes concernées. Or l’analyse de risque dépend précisément de cette réalité : collecter, surveiller, rapprocher, décider, orienter, exclure, conserver, transmettre, scorer ou profiler ne produisent pas les mêmes effets.
Le même raisonnement vaut pour les personnes concernées. Un traitement portant sur des clients adultes dans un contexte commercial ordinaire ne se regarde pas de la même manière qu’un traitement concernant des mineurs, des patients, des salariés, des personnes âgées, des personnes vulnérables ou des bénéficiaires d’un accompagnement social. La donnée ne porte pas le même risque selon le contexte, la relation de pouvoir, la vulnérabilité éventuelle et les effets produits.
L’AIPD doit donc commencer par une chose assez simple, mais souvent négligée : décrire le traitement réel. Pas le traitement tel qu’il est supposé fonctionner dans la procédure. Pas le traitement tel qu’il est présenté en réunion. Pas le traitement tel qu’il devrait fonctionner dans une version propre de l’organisation. Le traitement tel qu’il existe.
Si les données sont censées transiter par une plateforme sécurisée, mais qu’en pratique elles circulent aussi par email, il faut documenter l’email. Si des exports Excel sont utilisés pour faciliter le suivi, il faut les intégrer. Si des copies locales, impressions papier, dossiers partagés, transmissions informelles ou accès mutualisés existent dans le fonctionnement ordinaire, ils font partie de l’analyse.
C’est souvent dans ces espaces gris que le risque se loge.
L’AIPD doit également décrire le fonctionnement nominal du traitement, c’est-à-dire son fonctionnement normal, en l’absence d’incident, de panne, d’accès illicite ou d’événement dégradé. Cette étape est essentielle, parce qu’un traitement peut être problématique même lorsqu’il fonctionne exactement comme prévu.
Un traitement peut être techniquement stable et juridiquement fragile. Il peut produire des effets significatifs sur les personnes sans incident de sécurité : orientation d’un dossier, déclenchement d’une alerte, segmentation d’un public, évaluation d’un profil, préparation d’une décision, décision automatisée ou semi-automatisée, accès ou refus à un droit, un service, un avantage, un emploi ou une prise en charge.
Autrement dit, l’AIPD ne doit pas regarder uniquement ce qui pourrait mal tourner. Elle doit aussi regarder ce que le traitement produit lorsqu’il marche normalement.
C’est là que la méthode devient sérieuse. Avant de parler de fuite, de piratage, d’erreur humaine ou de perte de disponibilité, il faut comprendre le parcours ordinaire de la donnée : son point d’entrée, son stockage, ses usages, ses accès, ses circulations, ses effets, sa durée de vie et son sort final. Sans cette description, l’analyse des risques arrive trop tôt.
L’AIPD ne commence donc pas par la peur. Elle commence par le réel. Et c’est seulement une fois ce réel correctement décrit que l’organisme peut passer à la suite : vérifier si le traitement est nécessaire, proportionné, suffisamment limité, suffisamment transparent, puis identifier les scénarios de risque pertinents.
La matrice vient après. Elle ne doit pas servir à masquer une mauvaise compréhension du traitement. Elle doit formaliser une analyse déjà construite. Une AIPD utile repose donc sur une première exigence : cadrer précisément le traitement et son fonctionnement nominal, avant de prétendre en mesurer les risques. Sans ce cadrage, l’arbitrage final perd sa valeur, parce qu’on ne sait pas vraiment ce qui a été arbitré.
Le règlement européen sur l’intelligence artificielle, dit AI Act, est entré en vigueur le 1er août 2024, avec une application échelonnée selon les catégories d’obligations.
Certaines dispositions sont déjà applicables, notamment les interdictions de certaines pratiques et l’exigence de maîtrise de l’IA, tandis que d’autres, en particulier celles relatives aux systèmes d’IA à haut risque, devaient entrer en application plus tardivement.
Dans ce contexte, la Commission européenne a présenté le 19 novembre 2025 une proposition de Digital Omnibus on AI Regulation, explicitement décrite comme une simplification ciblée de certaines dispositions de l’AI Act. Le Conseil a arrêté sa position le 13 mars 2026 et le Parlement européen a adopté la sienne le 26 mars 2026.
La présente note ne constitue pas un bilan d’application du régime haut risque. Un tel bilan serait prématuré. Elle vise plus modestement, mais aussi plus utilement, à analyser la logique de la simplification proposée.
Sous cet angle, la thèse défendue ici est simple : l’AI Omnibus ne rééquilibre pas réellement l’architecture de l’AI Act ;
il en aménage surtout le calendrier, allège certains points pour des catégories déterminées d’entreprises, et révèle une priorité politique de diffusion économique de l’IA davantage qu’une refonte cohérente de la chaîne de conformité.
Le premier constat est que l’AI Omnibus ne procède pas à une simplification de fond du régime haut risque. La proposition de la Commission et la position du Conseil reposent notamment sur l’idée que les obligations centrales du chapitre III devraient s’appliquer lorsque les standards, les outils et les mesures de soutien à la conformité seront disponibles, avec des dates butoirs si cette disponibilité n’est pas confirmée à temps. Le Conseil a résumé cette logique en expliquant que l’ajustement du calendrier devait permettre l’application des règles lorsque les standards et outils nécessaires seraient prêts.
Cette approche peut se comprendre pratiquement. Mais elle révèle surtout que l’infrastructure de conformité n’était pas complètement prête au moment où le cadre a été conçu. Un report peut éviter un atterrissage chaotique. Il ne constitue pas, en lui-même, une amélioration normative.
Ce point est essentiel. Le problème ne semble pas être, d’abord, que les critères du régime haut risque seraient tous excessifs en eux-mêmes. Le problème paraît plutôt tenir à l’insuffisante préparation de leur méthode de contrôle. Des exigences comme la robustesse, la qualité des données, la supervision humaine, la traçabilité ou la surveillance après commercialisation ont une portée réelle seulement si elles peuvent être traduites en référentiels, protocoles, standards, seuils, méthodes de documentation et pratiques d’évaluation.
Or la Commission elle-même présente les standards harmonisés comme l’outil destiné à transformer les exigences juridiques du texte en langage technique commun, et reconnaît que ce travail n’était pas achevé dans les délais initialement attendus. L’Omnibus apparaît ainsi moins comme une simplification du contenu des obligations que comme une réponse au retard de l’infrastructure censée permettre leur mise en œuvre.
Le second constat, plus politique, concerne la création et la mobilisation de la catégorie des PEMC.
La Commission a clairement choisi d’étendre à ces entreprises intermédiaires certains avantages ou assouplissements jusque-là réservés aux PME et aux jeunes pousses. Dans son agenda de simplification, elle a présenté cette orientation comme un moyen de réduire les charges administratives et de soutenir la compétitivité.
C’est probablement le marqueur politique le plus révélateur de l’Omnibus. En effet, le texte ne simplifie pas principalement par rôle dans la chaîne de l’IA, mais d’abord par profil économique du bénéficiaire. Or cette logique n’est pas neutre. Elle suggère moins une reconstruction de la conformité autour des fonctions juridiques et opérationnelles des acteurs qu’un soutien ciblé à une strate intermédiaire d’entreprises que l’Union souhaite voir adopter et déployer davantage l’IA.
Ce choix appelle deux observations.
D’une part, il n’est pas illégitime, en soi, de prendre en compte la taille des opérateurs. Une régulation mature doit pouvoir distinguer entre une petite structure de bonne foi, encore en phase d’appropriation, et un acteur disposant déjà d’une capacité significative d’organisation, de documentation et de contrôle interne.
D’autre part, l’extension des allégements aux PEMC n’apparaît pas comme une nécessité technique évidente du point de vue de la cohérence du régime.
Elle ressemble davantage à un choix de politique économique qu’à une réponse démontrée à un blocage juridique ou méthodologique précisément identifié.
De ce point de vue, l’AI Omnibus confirme une tendance déjà visible dans d’autres projets de simplification récents : la simplification est pensée d’abord par entité économique, beaucoup moins par acteur de la chaîne normative.
Le troisième constat est que l’Omnibus touche à l’un des rares points qui auraient pu servir de socle commun transversal à l’ensemble des systèmes d’IA : la maîtrise de l’IA. Dans le cadre actuellement en vigueur, l’article 4 impose aux fournisseurs et aux déployeurs de prendre des mesures pour garantir un niveau suffisant de maîtrise de l’IA pour leur personnel et les personnes agissant pour leur compte. La Commission présente cette disposition comme une exigence réelle, rappelant qu’une simple lecture de la notice ou une information superficielle ne suffit pas nécessairement.
Or la proposition d’Omnibus transforme cette logique en un mécanisme d’encouragement par la Commission et les États membres, ce qui affaiblit clairement la densité normative de l’exigence. Ce déplacement est regrettable. Il ne réduit pas seulement une charge. Il désactive partiellement un principe qui aurait pu servir de base horizontale commune à une régulation plus cohérente de l’IA.
À cet égard, l’Omnibus donne parfois le sentiment d’une simplification qui retarde ou atténue plutôt qu’elle ne réorganise.
Or l’expérience d’autres cadres européens, notamment en protection des données, montre qu’il existe une différence entre la fermeté de la norme et la fermeté de son enforcement. Il est parfaitement possible de maintenir des obligations juridiques substantielles tout en organisant une montée en charge progressive par la pédagogie, les lignes directrices, les référentiels, les mesures correctrices et, seulement ensuite, la sanction lourde lorsque la mauvaise foi, la persistance ou la récidive le justifient. L’Omnibus semble parfois choisir une autre voie : alléger la norme elle-même ou différer son effectivité, là où une stratégie de déploiement gradué aurait peut-être suffi.
Dès lors, si l’on voulait vraiment simplifier intelligemment, il aurait sans doute fallu raisonner autrement. Non pas d’abord par taille d’entreprise, mais par acteur de la chaîne de l’IA.
Si l’objectif prioritaire est le soutien au fournisseur, il faut améliorer les outils qui conditionnent sa conformité réelle : référentiels, standards, sandbox, méthodes d’évaluation, articulation avec les procédures sectorielles. Si l’objectif prioritaire est l’extension de l’usage de l’IA, il faut alors clarifier la situation du déployeur : obligation de supervision, documentation de l’usage, information, remontée d’incidents, responsabilité en cas de mauvais paramétrage ou de mésusage. Dans les deux cas, la simplification devrait porter sur les fonctions exercées dans le cycle de vie du système, et non exclusivement sur la taille ou la catégorie économique de l’entité concernée.
En définitive, l’AI Omnibus présente une utilité politique et pratique réelle.
Il permet de traiter la question des délais, de la préparation des outils de conformité, de certaines redondances procédurales et de l’extension d’assouplissements à une catégorie élargie d’entreprises.
Mais il ne faut pas lui faire dire plus qu’il ne fait. Il ne reconstruit pas la logique du régime. Il ne simplifie pas prioritairement par acteur de la chaîne de l’IA. Il n’apporte pas, à ce stade, de réponse pleinement satisfaisante à la question centrale de l’opérabilité des obligations haut risque. Et il ne transforme pas un report d’entrée en application en amélioration substantielle du droit.
À ce stade, l’Omnibus doit donc être lu pour ce qu’il est : moins un rééquilibrage juridique de l’AI Act qu’un instrument de gestion politique et économique de son déploiement.
II. Un traitement peut être problématique avant même l’incident
Une AIPD ne doit pas être construite uniquement autour de l’accident. C’est une erreur assez fréquente : on pense immédiatement à la fuite de données, au piratage, à l’accès illégitime, à la perte de disponibilité, à l’erreur humaine ou au prestataire défaillant. Ces scénarios doivent évidemment être analysés. Mais ils ne suffisent pas.
Un traitement peut déjà poser problème dans son fonctionnement normal. Il peut être stable, sécurisé, techniquement maîtrisé, et pourtant produire des effets discutables sur les personnes concernées.
C’est pour cela que l’analyse de nécessité et de proportionnalité doit intervenir avant la cartographie des scénarios de risque. Elle ne consiste pas encore à évaluer un incident. Elle consiste à vérifier si le traitement, dans sa conception même, est justifié, adéquat, limité et proportionné au regard de sa finalité.
La question n’est donc pas seulement : “Que se passe-t-il si le traitement dysfonctionne ?”
La question est aussi : “Que produit le traitement lorsqu’il fonctionne exactement comme prévu ?”
Cette distinction change beaucoup de choses. Un traitement peut être nuisible sans panne, sans fuite, sans attaque, sans erreur technique. Il peut être nuisible parce qu’il collecte trop de données, parce qu’il suit les personnes trop finement, parce qu’il produit un score trop influent, parce qu’il déclenche une décision difficilement contestable, parce qu’il repose sur une finalité trop large, ou parce qu’il rend l’exercice des droits théorique. Dans ce cas, le risque ne vient pas d’un événement extérieur. Il vient du traitement lui-même.
C’est là que l’AIPD doit éviter une confusion assez confortable : croire que le risque commence seulement lorsque quelque chose se passe mal. Non. Parfois, le problème est précisément que tout se passe comme prévu.
L’analyse doit donc vérifier si la finalité est suffisamment claire, si la base légale est cohérente, si les données collectées sont réellement nécessaires, si les opérations sont proportionnées, si des moyens moins intrusifs existent, si les personnes comprennent ce qui se passe, si leurs droits sont effectifs, et si les accès, les flux et les durées de conservation sont correctement encadrés. Cette logique rejoint aussi les principes de protection des données dès la conception et par défaut, prévus par l’article 25 du RGPD.
Le point central est simple : un traitement ne devient pas proportionné parce qu’il est pratique, habituel ou utile pour le métier. Il devient défendable lorsqu’il est réellement nécessaire à l’objectif poursuivi, lorsqu’il ne peut pas être raisonnablement remplacé par une solution moins intrusive, et lorsque ses modalités restent mesurées au regard de ses effets sur les personnes concernées.
C’est une différence importante. Un outil peut être très efficace pour l’organisation et trop intrusif pour les personnes.
Une donnée peut être utile et pourtant non nécessaire.
Un accès peut être confortable et pourtant trop large.
Une conservation peut arranger les équipes et pourtant durer trop longtemps.
Une automatisation peut fluidifier un processus et pourtant rendre l’arbitrage opaque.
L’AIPD doit permettre de regarder ces tensions sans les lisser. C’est aussi pour cela qu’il faut distinguer les scénarios nominaux nuisibles des scénarios dégradés plausibles. Les premiers sont générés par le fonctionnement normal du traitement : collecte excessive, profilage trop intrusif, décision défavorable insuffisamment explicable, surveillance trop fine, réutilisation inattendue de données, opacité empêchant l’exercice effectif des droits, exclusion ou discrimination liée au fonctionnement ordinaire du traitement. Les seconds relèvent d’un fonctionnement altéré, incidentel ou abusif : accès illégitime, divulgation à un mauvais destinataire, altération de données, indisponibilité, erreur humaine, extraction abusive ou compromission d’un compte.
Cette distinction est essentielle. Si l’AIPD ne regarde que les scénarios dégradés, elle risque de passer à côté du sujet le plus sensible : le traitement peut être correctement sécurisé, mais mal conçu au regard des droits et libertés.
Un dispositif de surveillance peut fonctionner parfaitement et être trop intrusif. Un outil de scoring peut produire exactement le résultat attendu et créer une perte de chance.
Un traitement RH peut être bien hébergé et pourtant organiser un suivi excessif.
Un système d’aide à la décision peut ne jamais tomber en panne et pourtant orienter durablement des personnes sur la base de critères contestables.
Dans ces hypothèses, ajouter une mesure de sécurité ne suffit pas toujours.
Parfois, la bonne réponse n’est pas de mieux protéger le traitement.
C’est de le modifier.
Réduire les données.
Réduire la granularité.
Réduire les accès.
Réduire la conservation.
Retirer un croisement.
Ajouter une intervention humaine.
Rendre la logique plus compréhensible.
Renoncer à une fonctionnalité.
C’est là que l’AIPD rejoint sa vraie fonction : elle ne sert pas seulement à sécuriser un traitement déjà décidé. Elle sert aussi à demander si ce traitement doit être maintenu tel qu’il a été conçu. Une analyse sérieuse ne peut donc pas séparer artificiellement la conformité du traitement et les risques qu’il génère.
Avant de coter un risque, il faut regarder si le traitement mérite lui-même d’être reconfiguré. La sécurité répond à la question : comment éviter que le traitement soit détourné, perdu, altéré ou exposé ?
La nécessité et la proportionnalité répondent à une question plus brutale : avait-on besoin de traiter ces données, de cette manière, avec cette intensité, pour atteindre cette finalité ?
C’est souvent cette question qui fait vraiment travailler l’AIPD.
Le traitement peut alors apparaître nécessaire et globalement proportionné. Il peut être nécessaire mais insuffisamment encadré. Il peut être partiellement justifié avec plusieurs mesures de réduction à prévoir. Il peut aussi être disproportionné en l’état. Cette appréciation d’ensemble doit précéder l’analyse des scénarios de risque, parce qu’elle permet de savoir si l’on part d’un traitement solide ou déjà fragile dans sa conception.
Une AIPD utile ne doit donc pas seulement se demander comment éviter l’incident. Elle doit aussi demander si le fonctionnement ordinaire du traitement est acceptable.
Et si le fonctionnement normal produit déjà un effet excessif sur les personnes, alors le risque n’est pas dans l’accident. Il est dans la conception même du traitement.
Le règlement européen sur l’intelligence artificielle, dit AI Act, est entré en vigueur le 1er août 2024, avec une application échelonnée selon les catégories d’obligations.
Certaines dispositions sont déjà applicables, notamment les interdictions de certaines pratiques et l’exigence de maîtrise de l’IA, tandis que d’autres, en particulier celles relatives aux systèmes d’IA à haut risque, devaient entrer en application plus tardivement.
Dans ce contexte, la Commission européenne a présenté le 19 novembre 2025 une proposition de Digital Omnibus on AI Regulation, explicitement décrite comme une simplification ciblée de certaines dispositions de l’AI Act. Le Conseil a arrêté sa position le 13 mars 2026 et le Parlement européen a adopté la sienne le 26 mars 2026.
La présente note ne constitue pas un bilan d’application du régime haut risque. Un tel bilan serait prématuré. Elle vise plus modestement, mais aussi plus utilement, à analyser la logique de la simplification proposée.
Sous cet angle, la thèse défendue ici est simple : l’AI Omnibus ne rééquilibre pas réellement l’architecture de l’AI Act ;
il en aménage surtout le calendrier, allège certains points pour des catégories déterminées d’entreprises, et révèle une priorité politique de diffusion économique de l’IA davantage qu’une refonte cohérente de la chaîne de conformité.
Le premier constat est que l’AI Omnibus ne procède pas à une simplification de fond du régime haut risque. La proposition de la Commission et la position du Conseil reposent notamment sur l’idée que les obligations centrales du chapitre III devraient s’appliquer lorsque les standards, les outils et les mesures de soutien à la conformité seront disponibles, avec des dates butoirs si cette disponibilité n’est pas confirmée à temps. Le Conseil a résumé cette logique en expliquant que l’ajustement du calendrier devait permettre l’application des règles lorsque les standards et outils nécessaires seraient prêts.
Cette approche peut se comprendre pratiquement. Mais elle révèle surtout que l’infrastructure de conformité n’était pas complètement prête au moment où le cadre a été conçu. Un report peut éviter un atterrissage chaotique. Il ne constitue pas, en lui-même, une amélioration normative.
Ce point est essentiel. Le problème ne semble pas être, d’abord, que les critères du régime haut risque seraient tous excessifs en eux-mêmes. Le problème paraît plutôt tenir à l’insuffisante préparation de leur méthode de contrôle. Des exigences comme la robustesse, la qualité des données, la supervision humaine, la traçabilité ou la surveillance après commercialisation ont une portée réelle seulement si elles peuvent être traduites en référentiels, protocoles, standards, seuils, méthodes de documentation et pratiques d’évaluation.
Or la Commission elle-même présente les standards harmonisés comme l’outil destiné à transformer les exigences juridiques du texte en langage technique commun, et reconnaît que ce travail n’était pas achevé dans les délais initialement attendus. L’Omnibus apparaît ainsi moins comme une simplification du contenu des obligations que comme une réponse au retard de l’infrastructure censée permettre leur mise en œuvre.
Le second constat, plus politique, concerne la création et la mobilisation de la catégorie des PEMC.
La Commission a clairement choisi d’étendre à ces entreprises intermédiaires certains avantages ou assouplissements jusque-là réservés aux PME et aux jeunes pousses. Dans son agenda de simplification, elle a présenté cette orientation comme un moyen de réduire les charges administratives et de soutenir la compétitivité.
C’est probablement le marqueur politique le plus révélateur de l’Omnibus. En effet, le texte ne simplifie pas principalement par rôle dans la chaîne de l’IA, mais d’abord par profil économique du bénéficiaire. Or cette logique n’est pas neutre. Elle suggère moins une reconstruction de la conformité autour des fonctions juridiques et opérationnelles des acteurs qu’un soutien ciblé à une strate intermédiaire d’entreprises que l’Union souhaite voir adopter et déployer davantage l’IA.
Ce choix appelle deux observations.
D’une part, il n’est pas illégitime, en soi, de prendre en compte la taille des opérateurs. Une régulation mature doit pouvoir distinguer entre une petite structure de bonne foi, encore en phase d’appropriation, et un acteur disposant déjà d’une capacité significative d’organisation, de documentation et de contrôle interne.
D’autre part, l’extension des allégements aux PEMC n’apparaît pas comme une nécessité technique évidente du point de vue de la cohérence du régime.
Elle ressemble davantage à un choix de politique économique qu’à une réponse démontrée à un blocage juridique ou méthodologique précisément identifié.
De ce point de vue, l’AI Omnibus confirme une tendance déjà visible dans d’autres projets de simplification récents : la simplification est pensée d’abord par entité économique, beaucoup moins par acteur de la chaîne normative.
Le troisième constat est que l’Omnibus touche à l’un des rares points qui auraient pu servir de socle commun transversal à l’ensemble des systèmes d’IA : la maîtrise de l’IA. Dans le cadre actuellement en vigueur, l’article 4 impose aux fournisseurs et aux déployeurs de prendre des mesures pour garantir un niveau suffisant de maîtrise de l’IA pour leur personnel et les personnes agissant pour leur compte. La Commission présente cette disposition comme une exigence réelle, rappelant qu’une simple lecture de la notice ou une information superficielle ne suffit pas nécessairement.
Or la proposition d’Omnibus transforme cette logique en un mécanisme d’encouragement par la Commission et les États membres, ce qui affaiblit clairement la densité normative de l’exigence. Ce déplacement est regrettable. Il ne réduit pas seulement une charge. Il désactive partiellement un principe qui aurait pu servir de base horizontale commune à une régulation plus cohérente de l’IA.
À cet égard, l’Omnibus donne parfois le sentiment d’une simplification qui retarde ou atténue plutôt qu’elle ne réorganise.
Or l’expérience d’autres cadres européens, notamment en protection des données, montre qu’il existe une différence entre la fermeté de la norme et la fermeté de son enforcement. Il est parfaitement possible de maintenir des obligations juridiques substantielles tout en organisant une montée en charge progressive par la pédagogie, les lignes directrices, les référentiels, les mesures correctrices et, seulement ensuite, la sanction lourde lorsque la mauvaise foi, la persistance ou la récidive le justifient. L’Omnibus semble parfois choisir une autre voie : alléger la norme elle-même ou différer son effectivité, là où une stratégie de déploiement gradué aurait peut-être suffi.
Dès lors, si l’on voulait vraiment simplifier intelligemment, il aurait sans doute fallu raisonner autrement. Non pas d’abord par taille d’entreprise, mais par acteur de la chaîne de l’IA.
Si l’objectif prioritaire est le soutien au fournisseur, il faut améliorer les outils qui conditionnent sa conformité réelle : référentiels, standards, sandbox, méthodes d’évaluation, articulation avec les procédures sectorielles. Si l’objectif prioritaire est l’extension de l’usage de l’IA, il faut alors clarifier la situation du déployeur : obligation de supervision, documentation de l’usage, information, remontée d’incidents, responsabilité en cas de mauvais paramétrage ou de mésusage. Dans les deux cas, la simplification devrait porter sur les fonctions exercées dans le cycle de vie du système, et non exclusivement sur la taille ou la catégorie économique de l’entité concernée.
En définitive, l’AI Omnibus présente une utilité politique et pratique réelle.
Il permet de traiter la question des délais, de la préparation des outils de conformité, de certaines redondances procédurales et de l’extension d’assouplissements à une catégorie élargie d’entreprises.
Mais il ne faut pas lui faire dire plus qu’il ne fait. Il ne reconstruit pas la logique du régime. Il ne simplifie pas prioritairement par acteur de la chaîne de l’IA. Il n’apporte pas, à ce stade, de réponse pleinement satisfaisante à la question centrale de l’opérabilité des obligations haut risque. Et il ne transforme pas un report d’entrée en application en amélioration substantielle du droit.
À ce stade, l’Omnibus doit donc être lu pour ce qu’il est : moins un rééquilibrage juridique de l’AI Act qu’un instrument de gestion politique et économique de son déploiement.
III. Un scénario de risque doit décrire un dommage concret, pas une hypothèse abstraite
Une fois le traitement cadré, son fonctionnement nominal décrit, et sa nécessité interrogée, l’AIPD peut réellement entrer dans l’analyse des scénarios de risque. Mais là encore, il faut éviter un piège : écrire des scénarios trop généraux. Dire “risque de violation de données”, “risque d’accès non autorisé” ou “risque d’erreur” ne suffit pas. Ce sont des catégories. Pas encore des scénarios.
Un scénario utile doit raconter quelque chose de précis. Il doit dire ce qui se produit, dans quel contexte, par quelle cause, sur quelles personnes, avec quel dommage possible, et avec quelles conséquences sur leurs droits et libertés. Sinon, l’analyse reste trop abstraite pour orienter les mesures.
La CNIL rappelle que l’analyse de risques suppose d’identifier les risques, puis d’évaluer leur vraisemblance et leur gravité pour mettre en place des mesures adaptées. Mais pour évaluer correctement un risque, encore faut-il que le scénario soit assez concret. Une gravité ne se mesure pas sérieusement sur une formule vague. Une vraisemblance non plus.
Le bon point de départ n’est donc pas : “Quel risque juridique existe ?”
Mais plutôt : “Que peut-il arriver concrètement à une personne concernée à cause de ce traitement ?”
Un accès illégitime, par exemple, n’a pas la même portée selon le contexte. Il peut concerner une simple donnée de contact, un dossier social, une donnée de santé, une donnée relative à un mineur, une information professionnelle sensible, une donnée pénale, un historique de comportement ou un élément susceptible d’exposer la personne à une discrimination.
Même événement apparent. Dommage potentiel très différent.
C’est pour cela que le scénario doit partir des personnes affectées et des droits concernés : confidentialité, réputation, autonomie, possibilité d’exercer ses droits, accès à un service, accès à un emploi, prise en charge, sécurité physique ou psychologique, perte financière, exclusion, discrimination, perte de chance.
L’AIPD ne doit pas produire une liste décorative de risques. Elle doit identifier les scénarios qui peuvent réellement changer quelque chose pour les personnes.
Cette exigence vaut autant pour les scénarios nominaux nuisibles que pour les scénarios dégradés plausibles. Les premiers résultent du fonctionnement normal du traitement : collecte excessive, profilage trop intrusif, décision défavorable difficilement explicable, surveillance trop fine, réutilisation inattendue, opacité empêchant l’exercice des droits, exclusion ou discrimination. Les seconds résultent d’un fonctionnement altéré ou abusif : accès illégitime, divulgation à un mauvais destinataire, altération de données, perte de disponibilité, erreur humaine, extraction abusive, compromission d’un compte, défaillance d’un prestataire. Cette distinction évite de réduire l’AIPD à une analyse de sécurité.
Elle oblige à regarder deux familles de risques :
ce que le traitement produit parce qu’il fonctionne normalement ;
ce qu’il peut produire lorsqu’il fonctionne mal, trop largement, trop longtemps, ou entre de mauvaises mains.
Une fois le scénario formulé, il faut ensuite apprécier sa vraisemblance et sa gravité.
La vraisemblance répond à une question simple : ce scénario peut-il raisonnablement survenir dans les conditions observées ?
La gravité répond à une autre question : si le scénario survient, que produit-il concrètement pour les personnes concernées ?
Ces deux questions sont liées, mais elles ne jouent pas le même rôle.
La vraisemblance oblige à regarder le fonctionnement réel : accès trop larges, comptes partagés, absence de journalisation, export fréquent, pratique informelle, prestataire peu encadré, absence de procédure, outil mal paramétré, erreur déjà rencontrée, flux non maîtrisé.
La gravité oblige à regarder le dommage : donnée sensible, personne vulnérable, effet durable, décision importante, impossibilité de corriger rapidement, exposition massive, atteinte au secret professionnel, risque de discrimination, perte d’un droit, atteinte à la réputation, impossibilité d’exercer un recours.
Une AIPD sérieuse doit tenir ces deux dimensions. Mais elle ne doit pas les traiter comme deux chiffres froids. La cotation n’a de valeur que si elle est justifiée par des facteurs concrets.
La méthode doit donc éviter deux facilités.
La première consiste à noter “au ressenti”.
La seconde consiste à croire qu’une note devient objective parce qu’elle est dans un tableau.
Dans les deux cas, c’est fragile.
Une note de vraisemblance doit s’expliquer : le scénario est-il exceptionnel, possible, crédible, probable, déjà rencontré ? Une note de gravité doit aussi s’expliquer : la conséquence est-elle limitée, modérée, notable, importante, durable, difficilement réversible, grave ou particulièrement préjudiciable ? Le modèle La méthode de DefentaData repose justement sur cette double lecture vraisemblance / gravité, avec une justification du niveau retenu et une attention portée aux droits et libertés effectivement affectés.
L’objectif n’est pas de produire une certitude mathématique.
L’objectif est de rendre le raisonnement contrôlable.
On doit pouvoir relire l’AIPD et comprendre pourquoi tel scénario a été considéré comme modéré, élevé ou critique. On doit pouvoir comprendre pourquoi la gravité a été retenue à tel niveau. On doit pouvoir voir quels éléments ont pesé : nature des données, vulnérabilité des personnes, volume, fréquence, effet produit, réversibilité, mesures existantes, historique d’incidents ou qualité des accès.
C’est là que la notion de crainte structurante prend sa place. Tous les risques ne jouent pas le même rôle dans l’analyse. Certains risques sont fréquents mais corrigibles. Ils relèvent d’un pilotage opérationnel sérieux, sans forcément remettre en cause le traitement.
D’autres risques sont moins probables mais beaucoup plus graves. Ils touchent le cœur de ce que l’organisme ne doit pas banaliser : exposition de données sensibles, exclusion d’un droit, surveillance excessive, profilage opaque, atteinte durable à la réputation, erreur difficilement réversible, dommage sur une personne vulnérable.
La probabilité compte. Mais elle ne doit pas effacer la gravité.
Le RGPD et les lignes directrices européennes inscrivent l’AIPD dans une logique de gestion continue des risques pour les droits et libertés des personnes, en particulier lorsque le traitement est susceptible d’engendrer un risque élevé. Cette logique serait vidée de son intérêt si un scénario fortement dommageable était mécaniquement banalisé au seul motif qu’il paraît peu fréquent. Un incident rare mais destructeur reste un sujet majeur.
À l’inverse, un incident fréquent mais de faible gravité ne doit pas être artificiellement transformé en risque critique uniquement parce qu’il se répète. Il peut appeler des mesures de pilotage, de correction, de procédure, de formation, de contrôle. Mais sa fréquence ne suffit pas toujours à le placer au même niveau qu’un dommage grave, durable ou difficilement réversible.
C’est pour cela qu’un scénario de risque doit être écrit de manière suffisamment précise. Pas pour remplir une case. Pour préparer l’arbitrage.
Si le scénario est flou, les mesures seront floues.
Si le dommage est mal décrit, la gravité sera mal comprise.
Si les personnes affectées sont mal identifiées, l’analyse sera abstraite.
Si la cause du risque n’est pas claire, la mesure retenue risque de ne traiter qu’un symptôme.
Une AIPD utile doit donc aboutir à des scénarios lisibles :
un événement concret ;
une cause identifiable ;
des personnes exposées ;
un dommage possible ;
une vraisemblance justifiée ;
une gravité justifiée ;
des mesures à apprécier ensuite.
C’est seulement à ce prix que la suite de l’AIPD devient sérieuse. Parce qu’on ne réduit pas un risque qu’on n’a pas décrit. On ne maîtrise pas un scénario qu’on a seulement nommé. Et on ne peut pas assumer un arbitrage si l’on n’a jamais vraiment formulé ce qui pourrait arriver.
Le règlement européen sur l’intelligence artificielle, dit AI Act, est entré en vigueur le 1er août 2024, avec une application échelonnée selon les catégories d’obligations.
Certaines dispositions sont déjà applicables, notamment les interdictions de certaines pratiques et l’exigence de maîtrise de l’IA, tandis que d’autres, en particulier celles relatives aux systèmes d’IA à haut risque, devaient entrer en application plus tardivement.
Dans ce contexte, la Commission européenne a présenté le 19 novembre 2025 une proposition de Digital Omnibus on AI Regulation, explicitement décrite comme une simplification ciblée de certaines dispositions de l’AI Act. Le Conseil a arrêté sa position le 13 mars 2026 et le Parlement européen a adopté la sienne le 26 mars 2026.
La présente note ne constitue pas un bilan d’application du régime haut risque. Un tel bilan serait prématuré. Elle vise plus modestement, mais aussi plus utilement, à analyser la logique de la simplification proposée.
Sous cet angle, la thèse défendue ici est simple : l’AI Omnibus ne rééquilibre pas réellement l’architecture de l’AI Act ;
il en aménage surtout le calendrier, allège certains points pour des catégories déterminées d’entreprises, et révèle une priorité politique de diffusion économique de l’IA davantage qu’une refonte cohérente de la chaîne de conformité.
Le premier constat est que l’AI Omnibus ne procède pas à une simplification de fond du régime haut risque. La proposition de la Commission et la position du Conseil reposent notamment sur l’idée que les obligations centrales du chapitre III devraient s’appliquer lorsque les standards, les outils et les mesures de soutien à la conformité seront disponibles, avec des dates butoirs si cette disponibilité n’est pas confirmée à temps. Le Conseil a résumé cette logique en expliquant que l’ajustement du calendrier devait permettre l’application des règles lorsque les standards et outils nécessaires seraient prêts.
Cette approche peut se comprendre pratiquement. Mais elle révèle surtout que l’infrastructure de conformité n’était pas complètement prête au moment où le cadre a été conçu. Un report peut éviter un atterrissage chaotique. Il ne constitue pas, en lui-même, une amélioration normative.
Ce point est essentiel. Le problème ne semble pas être, d’abord, que les critères du régime haut risque seraient tous excessifs en eux-mêmes. Le problème paraît plutôt tenir à l’insuffisante préparation de leur méthode de contrôle. Des exigences comme la robustesse, la qualité des données, la supervision humaine, la traçabilité ou la surveillance après commercialisation ont une portée réelle seulement si elles peuvent être traduites en référentiels, protocoles, standards, seuils, méthodes de documentation et pratiques d’évaluation.
Or la Commission elle-même présente les standards harmonisés comme l’outil destiné à transformer les exigences juridiques du texte en langage technique commun, et reconnaît que ce travail n’était pas achevé dans les délais initialement attendus. L’Omnibus apparaît ainsi moins comme une simplification du contenu des obligations que comme une réponse au retard de l’infrastructure censée permettre leur mise en œuvre.
Le second constat, plus politique, concerne la création et la mobilisation de la catégorie des PEMC.
La Commission a clairement choisi d’étendre à ces entreprises intermédiaires certains avantages ou assouplissements jusque-là réservés aux PME et aux jeunes pousses. Dans son agenda de simplification, elle a présenté cette orientation comme un moyen de réduire les charges administratives et de soutenir la compétitivité.
C’est probablement le marqueur politique le plus révélateur de l’Omnibus. En effet, le texte ne simplifie pas principalement par rôle dans la chaîne de l’IA, mais d’abord par profil économique du bénéficiaire. Or cette logique n’est pas neutre. Elle suggère moins une reconstruction de la conformité autour des fonctions juridiques et opérationnelles des acteurs qu’un soutien ciblé à une strate intermédiaire d’entreprises que l’Union souhaite voir adopter et déployer davantage l’IA.
Ce choix appelle deux observations.
D’une part, il n’est pas illégitime, en soi, de prendre en compte la taille des opérateurs. Une régulation mature doit pouvoir distinguer entre une petite structure de bonne foi, encore en phase d’appropriation, et un acteur disposant déjà d’une capacité significative d’organisation, de documentation et de contrôle interne.
D’autre part, l’extension des allégements aux PEMC n’apparaît pas comme une nécessité technique évidente du point de vue de la cohérence du régime.
Elle ressemble davantage à un choix de politique économique qu’à une réponse démontrée à un blocage juridique ou méthodologique précisément identifié.
De ce point de vue, l’AI Omnibus confirme une tendance déjà visible dans d’autres projets de simplification récents : la simplification est pensée d’abord par entité économique, beaucoup moins par acteur de la chaîne normative.
Le troisième constat est que l’Omnibus touche à l’un des rares points qui auraient pu servir de socle commun transversal à l’ensemble des systèmes d’IA : la maîtrise de l’IA. Dans le cadre actuellement en vigueur, l’article 4 impose aux fournisseurs et aux déployeurs de prendre des mesures pour garantir un niveau suffisant de maîtrise de l’IA pour leur personnel et les personnes agissant pour leur compte. La Commission présente cette disposition comme une exigence réelle, rappelant qu’une simple lecture de la notice ou une information superficielle ne suffit pas nécessairement.
Or la proposition d’Omnibus transforme cette logique en un mécanisme d’encouragement par la Commission et les États membres, ce qui affaiblit clairement la densité normative de l’exigence. Ce déplacement est regrettable. Il ne réduit pas seulement une charge. Il désactive partiellement un principe qui aurait pu servir de base horizontale commune à une régulation plus cohérente de l’IA.
À cet égard, l’Omnibus donne parfois le sentiment d’une simplification qui retarde ou atténue plutôt qu’elle ne réorganise.
Or l’expérience d’autres cadres européens, notamment en protection des données, montre qu’il existe une différence entre la fermeté de la norme et la fermeté de son enforcement. Il est parfaitement possible de maintenir des obligations juridiques substantielles tout en organisant une montée en charge progressive par la pédagogie, les lignes directrices, les référentiels, les mesures correctrices et, seulement ensuite, la sanction lourde lorsque la mauvaise foi, la persistance ou la récidive le justifient. L’Omnibus semble parfois choisir une autre voie : alléger la norme elle-même ou différer son effectivité, là où une stratégie de déploiement gradué aurait peut-être suffi.
Dès lors, si l’on voulait vraiment simplifier intelligemment, il aurait sans doute fallu raisonner autrement. Non pas d’abord par taille d’entreprise, mais par acteur de la chaîne de l’IA.
Si l’objectif prioritaire est le soutien au fournisseur, il faut améliorer les outils qui conditionnent sa conformité réelle : référentiels, standards, sandbox, méthodes d’évaluation, articulation avec les procédures sectorielles. Si l’objectif prioritaire est l’extension de l’usage de l’IA, il faut alors clarifier la situation du déployeur : obligation de supervision, documentation de l’usage, information, remontée d’incidents, responsabilité en cas de mauvais paramétrage ou de mésusage. Dans les deux cas, la simplification devrait porter sur les fonctions exercées dans le cycle de vie du système, et non exclusivement sur la taille ou la catégorie économique de l’entité concernée.
En définitive, l’AI Omnibus présente une utilité politique et pratique réelle.
Il permet de traiter la question des délais, de la préparation des outils de conformité, de certaines redondances procédurales et de l’extension d’assouplissements à une catégorie élargie d’entreprises.
Mais il ne faut pas lui faire dire plus qu’il ne fait. Il ne reconstruit pas la logique du régime. Il ne simplifie pas prioritairement par acteur de la chaîne de l’IA. Il n’apporte pas, à ce stade, de réponse pleinement satisfaisante à la question centrale de l’opérabilité des obligations haut risque. Et il ne transforme pas un report d’entrée en application en amélioration substantielle du droit.
À ce stade, l’Omnibus doit donc être lu pour ce qu’il est : moins un rééquilibrage juridique de l’AI Act qu’un instrument de gestion politique et économique de son déploiement.
IV. Une mesure ne vaut que si elle modifie réellement le risque
Une fois les scénarios identifiés, l’AIPD doit passer à une question plus exigeante : que fait-on du risque ?
C’est souvent ici que l’analyse peut redevenir trop documentaire. On identifie un risque, puis on inscrit en face une mesure : une procédure, une charte, une clause, une information, une habilitation, un contrôle, une journalisation, une formation.
Le tableau se remplit. Le document devient plus rassurant. Mais une mesure ne vaut pas parce qu’elle est écrite. Elle vaut si elle change quelque chose.
Une mesure utile doit avoir un lien direct avec le scénario qu’elle prétend traiter. Elle doit prévenir le risque, le limiter, le détecter, le corriger, réduire sa vraisemblance, réduire sa gravité, ou rendre ses effets plus maîtrisables. Si elle ne fait rien de tout cela, elle peut être utile pour l’organisation générale de la conformité, mais elle ne doit pas être surestimée dans l’analyse du risque.
Le RGPD ne demande pas une accumulation abstraite de garanties. Il impose des mesures techniques et organisationnelles appropriées au regard des risques. La CNIL rappelle dans la même logique que l’analyse de risques doit permettre d’évaluer la vraisemblance et la gravité des risques afin de mettre en place des mesures de sécurité appropriées.
Cela implique une distinction importante. Certaines mesures relèvent de la documentation : mentions d’information, clauses contractuelles, procédures internes, politique de conservation, traçabilité des décisions. Elles sont nécessaires, mais elles ne réduisent pas toujours directement le dommage si le scénario survient.
Certaines mesures relèvent de l’organisation : séparation des rôles, limitation des accès, validation humaine, revue périodique, sensibilisation, double contrôle. Elles peuvent réduire la vraisemblance d’un scénario, notamment lorsqu’il dépend d’une erreur humaine, d’un accès trop large ou d’une absence de supervision.
Certaines mesures relèvent de la technique : authentification forte, chiffrement, pseudonymisation, journalisation, cloisonnement, sauvegardes, contrôle des exports, suppression automatique. Elles peuvent réduire la probabilité de survenance du scénario, limiter l’exposition, ou réduire les conséquences d’un incident.
Et certaines mesures relèvent de la conception même du traitement : supprimer une catégorie de données, réduire la granularité d’un suivi, abandonner un croisement, raccourcir la conservation, limiter les destinataires, réintroduire une intervention humaine, modifier le parcours de collecte. Ces dernières sont parfois les plus importantes.
Parce que lorsque le risque est attaché à la logique même du traitement, ajouter une mesure de sécurité ne suffit pas. Sécuriser un traitement excessif ne le rend pas automatiquement proportionné. Chiffrer une donnée qui n’aurait pas dû être collectée ne règle pas le problème de minimisation. Journaliser des accès trop larges ne justifie pas nécessairement leur existence. Informer les personnes d’un traitement trop intrusif ne suffit pas à le rendre acceptable.
Parfois, la bonne réponse n’est pas d’ajouter une garantie. C’est d’arrêter de faire quelque chose d’excessif. C’est là que l’AIPD doit éviter une autre facilité : considérer qu’une mesure existante fait automatiquement baisser le niveau de risque. Une procédure existe, donc le risque baisse. Une charte est signée, donc le risque baisse. Une information est donnée, donc le risque baisse. Une journalisation est prévue, donc le risque baisse.
Pas nécessairement. La vraie question est plus simple et plus sévère : Avec cette mesure, le scénario est-il moins vraisemblable ? Si le scénario survient malgré tout, ses conséquences sont-elles moins graves ?
Si la réponse est non, la mesure ne doit pas être valorisée artificiellement. Une AIPD sérieuse ne consiste donc pas à soustraire quelques points parce qu’une garantie existe. Elle consiste à réexaminer le risque après les mesures existantes, puis après les mesures complémentaires envisagées. Le raisonnement doit rester lisible : risque brut, mesures déjà en place, effet réel de ces mesures, mesures complémentaires, risque résiduel.
Cette logique évite deux erreurs. La première consiste à sous-estimer le risque parce que l’organisme dispose déjà de documents, de procédures ou de clauses. Une mesure formelle peut être insuffisante si elle n’est pas appliquée, si elle n’est pas contrôlée, si elle est inconnue des équipes, ou si elle ne répond pas au scénario principal.
La seconde consiste à croire qu’une mesure complémentaire règle tout parce qu’elle paraît sérieuse sur le papier. Une authentification forte peut réduire certains risques d’accès illégitime, mais elle ne corrige pas une finalité trop large. Une politique de conservation peut encadrer les durées, mais elle ne protège pas si les copies de travail continuent à circuler ailleurs. Une information renforcée peut améliorer la transparence, mais elle ne transforme pas une surveillance excessive en traitement proportionné.
L’AIPD doit donc apprécier l’effectivité réelle des mesures. Une mesure doit être identifiable, pertinente, réaliste, mise en œuvre ou planifiée, rattachée à un scénario précis, et vérifiable. Si elle dépend d’un chantier futur, d’un budget incertain, d’un prestataire non engagé ou d’un paramétrage non testé, elle ne peut pas être traitée comme une garantie déjà acquise. Le risque résiduel ne doit pas être calculé sur des intentions.
Il doit être apprécié à partir de ce qui est effectivement en place, ou de ce qui est suffisamment décidé, planifié, attribué et vérifiable. Cela vaut particulièrement lorsque le traitement ne peut être accepté que sous conditions. Dans ce cas, les mesures complémentaires ne sont pas de simples recommandations de confort. Elles deviennent les conditions de l’acceptabilité du traitement. Elles doivent être reliées à un responsable, un délai, un effet attendu et, idéalement, une modalité de vérification.
L’AIPD doit alors permettre de dire précisément :
ce risque était initialement élevé ;
telles mesures existaient déjà ;
elles réduisaient partiellement le risque, mais pas suffisamment ;
telles mesures complémentaires sont nécessaires ;
après leur mise en œuvre effective, le risque résiduel devient acceptable, ou reste problématique.
C’est cette chaîne qui donne de la valeur à l’analyse. Sans elle, l’AIPD devient une liste de bonnes intentions. La CNIL rappelle d’ailleurs que l’AIPD permet de cartographier et d’évaluer les risques d’un traitement, puis d’établir un plan d’action pour les réduire à un niveau acceptable, aussi bien avant la mise en œuvre que dans le suivi du traitement. L’idée de plan d’action est importante.
Elle montre que l’AIPD ne se limite pas à constater le risque. Elle doit produire une trajectoire. Certaines mesures peuvent être immédiates. D’autres peuvent être prévues à court ou moyen terme. Certaines peuvent conditionner le lancement du traitement. D’autres peuvent relever d’un suivi périodique. Mais elles doivent toutes être rattachées à une logique : prévenir, réduire, détecter, corriger ou reconfigurer.
L’enjeu n’est donc pas de multiplier les mesures pour donner l’impression d’une maîtrise. L’enjeu est de choisir les mesures qui répondent vraiment aux scénarios identifiés.
Une AIPD utile doit assumer cette hiérarchie. Toutes les mesures ne se valent pas. Une mesure de conception peut parfois réduire davantage le risque qu’une mesure documentaire. Une restriction d’accès peut être plus importante qu’une formation générale. Une réduction de données peut être plus protectrice qu’une information longue et illisible. Une intervention humaine réelle peut être plus déterminante qu’une clause de principe.
La mesure doit être jugée à son effet. Pas à son apparence. C’est seulement après cette appréciation que l’on peut parler sérieusement de risque résiduel. Avant cela, on ne sait pas encore si le risque a été réduit, simplement encadré, ou seulement raconté autrement.
L’AIPD doit donc maintenir une exigence simple : ne pas confondre l’existence d’une mesure avec son efficacité. Une mesure écrite peut rassurer. Une mesure effective réduit le risque. Et dans une AIPD, c’est la seconde qui compte.
Le règlement européen sur l’intelligence artificielle, dit AI Act, est entré en vigueur le 1er août 2024, avec une application échelonnée selon les catégories d’obligations.
Certaines dispositions sont déjà applicables, notamment les interdictions de certaines pratiques et l’exigence de maîtrise de l’IA, tandis que d’autres, en particulier celles relatives aux systèmes d’IA à haut risque, devaient entrer en application plus tardivement.
Dans ce contexte, la Commission européenne a présenté le 19 novembre 2025 une proposition de Digital Omnibus on AI Regulation, explicitement décrite comme une simplification ciblée de certaines dispositions de l’AI Act. Le Conseil a arrêté sa position le 13 mars 2026 et le Parlement européen a adopté la sienne le 26 mars 2026.
La présente note ne constitue pas un bilan d’application du régime haut risque. Un tel bilan serait prématuré. Elle vise plus modestement, mais aussi plus utilement, à analyser la logique de la simplification proposée.
Sous cet angle, la thèse défendue ici est simple : l’AI Omnibus ne rééquilibre pas réellement l’architecture de l’AI Act ;
il en aménage surtout le calendrier, allège certains points pour des catégories déterminées d’entreprises, et révèle une priorité politique de diffusion économique de l’IA davantage qu’une refonte cohérente de la chaîne de conformité.
Le premier constat est que l’AI Omnibus ne procède pas à une simplification de fond du régime haut risque. La proposition de la Commission et la position du Conseil reposent notamment sur l’idée que les obligations centrales du chapitre III devraient s’appliquer lorsque les standards, les outils et les mesures de soutien à la conformité seront disponibles, avec des dates butoirs si cette disponibilité n’est pas confirmée à temps. Le Conseil a résumé cette logique en expliquant que l’ajustement du calendrier devait permettre l’application des règles lorsque les standards et outils nécessaires seraient prêts.
Cette approche peut se comprendre pratiquement. Mais elle révèle surtout que l’infrastructure de conformité n’était pas complètement prête au moment où le cadre a été conçu. Un report peut éviter un atterrissage chaotique. Il ne constitue pas, en lui-même, une amélioration normative.
Ce point est essentiel. Le problème ne semble pas être, d’abord, que les critères du régime haut risque seraient tous excessifs en eux-mêmes. Le problème paraît plutôt tenir à l’insuffisante préparation de leur méthode de contrôle. Des exigences comme la robustesse, la qualité des données, la supervision humaine, la traçabilité ou la surveillance après commercialisation ont une portée réelle seulement si elles peuvent être traduites en référentiels, protocoles, standards, seuils, méthodes de documentation et pratiques d’évaluation.
Or la Commission elle-même présente les standards harmonisés comme l’outil destiné à transformer les exigences juridiques du texte en langage technique commun, et reconnaît que ce travail n’était pas achevé dans les délais initialement attendus. L’Omnibus apparaît ainsi moins comme une simplification du contenu des obligations que comme une réponse au retard de l’infrastructure censée permettre leur mise en œuvre.
Le second constat, plus politique, concerne la création et la mobilisation de la catégorie des PEMC.
La Commission a clairement choisi d’étendre à ces entreprises intermédiaires certains avantages ou assouplissements jusque-là réservés aux PME et aux jeunes pousses. Dans son agenda de simplification, elle a présenté cette orientation comme un moyen de réduire les charges administratives et de soutenir la compétitivité.
C’est probablement le marqueur politique le plus révélateur de l’Omnibus. En effet, le texte ne simplifie pas principalement par rôle dans la chaîne de l’IA, mais d’abord par profil économique du bénéficiaire. Or cette logique n’est pas neutre. Elle suggère moins une reconstruction de la conformité autour des fonctions juridiques et opérationnelles des acteurs qu’un soutien ciblé à une strate intermédiaire d’entreprises que l’Union souhaite voir adopter et déployer davantage l’IA.
Ce choix appelle deux observations.
D’une part, il n’est pas illégitime, en soi, de prendre en compte la taille des opérateurs. Une régulation mature doit pouvoir distinguer entre une petite structure de bonne foi, encore en phase d’appropriation, et un acteur disposant déjà d’une capacité significative d’organisation, de documentation et de contrôle interne.
D’autre part, l’extension des allégements aux PEMC n’apparaît pas comme une nécessité technique évidente du point de vue de la cohérence du régime.
Elle ressemble davantage à un choix de politique économique qu’à une réponse démontrée à un blocage juridique ou méthodologique précisément identifié.
De ce point de vue, l’AI Omnibus confirme une tendance déjà visible dans d’autres projets de simplification récents : la simplification est pensée d’abord par entité économique, beaucoup moins par acteur de la chaîne normative.
Le troisième constat est que l’Omnibus touche à l’un des rares points qui auraient pu servir de socle commun transversal à l’ensemble des systèmes d’IA : la maîtrise de l’IA. Dans le cadre actuellement en vigueur, l’article 4 impose aux fournisseurs et aux déployeurs de prendre des mesures pour garantir un niveau suffisant de maîtrise de l’IA pour leur personnel et les personnes agissant pour leur compte. La Commission présente cette disposition comme une exigence réelle, rappelant qu’une simple lecture de la notice ou une information superficielle ne suffit pas nécessairement.
Or la proposition d’Omnibus transforme cette logique en un mécanisme d’encouragement par la Commission et les États membres, ce qui affaiblit clairement la densité normative de l’exigence. Ce déplacement est regrettable. Il ne réduit pas seulement une charge. Il désactive partiellement un principe qui aurait pu servir de base horizontale commune à une régulation plus cohérente de l’IA.
À cet égard, l’Omnibus donne parfois le sentiment d’une simplification qui retarde ou atténue plutôt qu’elle ne réorganise.
Or l’expérience d’autres cadres européens, notamment en protection des données, montre qu’il existe une différence entre la fermeté de la norme et la fermeté de son enforcement. Il est parfaitement possible de maintenir des obligations juridiques substantielles tout en organisant une montée en charge progressive par la pédagogie, les lignes directrices, les référentiels, les mesures correctrices et, seulement ensuite, la sanction lourde lorsque la mauvaise foi, la persistance ou la récidive le justifient. L’Omnibus semble parfois choisir une autre voie : alléger la norme elle-même ou différer son effectivité, là où une stratégie de déploiement gradué aurait peut-être suffi.
Dès lors, si l’on voulait vraiment simplifier intelligemment, il aurait sans doute fallu raisonner autrement. Non pas d’abord par taille d’entreprise, mais par acteur de la chaîne de l’IA.
Si l’objectif prioritaire est le soutien au fournisseur, il faut améliorer les outils qui conditionnent sa conformité réelle : référentiels, standards, sandbox, méthodes d’évaluation, articulation avec les procédures sectorielles. Si l’objectif prioritaire est l’extension de l’usage de l’IA, il faut alors clarifier la situation du déployeur : obligation de supervision, documentation de l’usage, information, remontée d’incidents, responsabilité en cas de mauvais paramétrage ou de mésusage. Dans les deux cas, la simplification devrait porter sur les fonctions exercées dans le cycle de vie du système, et non exclusivement sur la taille ou la catégorie économique de l’entité concernée.
En définitive, l’AI Omnibus présente une utilité politique et pratique réelle.
Il permet de traiter la question des délais, de la préparation des outils de conformité, de certaines redondances procédurales et de l’extension d’assouplissements à une catégorie élargie d’entreprises.
Mais il ne faut pas lui faire dire plus qu’il ne fait. Il ne reconstruit pas la logique du régime. Il ne simplifie pas prioritairement par acteur de la chaîne de l’IA. Il n’apporte pas, à ce stade, de réponse pleinement satisfaisante à la question centrale de l’opérabilité des obligations haut risque. Et il ne transforme pas un report d’entrée en application en amélioration substantielle du droit.
À ce stade, l’Omnibus doit donc être lu pour ce qu’il est : moins un rééquilibrage juridique de l’AI Act qu’un instrument de gestion politique et économique de son déploiement.
V. Le risque résiduel est le vrai point de sortie de l’AIPD
Une AIPD ne se termine pas lorsque les risques ont été cotés. Elle se termine lorsque l’organisme sait ce qu’il reste comme risque après les mesures existantes et les mesures complémentaires retenues.
C’est une différence importante.
La cotation brute permet de comprendre le niveau initial du risque. L’analyse des mesures permet de savoir ce qui peut être réduit, encadré ou corrigé. Mais le point décisif, celui qui donne réellement son sens à l’AIPD, c’est le risque résiduel.
Autrement dit : Une fois les garanties appliquées, que reste-t-il concrètement comme risque pour les droits et libertés des personnes concernées ?
C’est cette question qui doit guider la conclusion.
Si elle n’est pas posée clairement, l’AIPD peut donner une impression de maîtrise sans véritable arbitrage. Le document existe, les scénarios sont listés, les mesures sont inscrites, le risque semble traité. Mais on ne sait pas vraiment si le traitement est acceptable, acceptable sous conditions, à modifier, à suspendre ou à soumettre à une consultation préalable.
Le risque résiduel oblige l’organisme à sortir de la simple analyse pour entrer dans la décision. Il faut donc distinguer plusieurs situations.
Lorsque les mesures existantes et complémentaires permettent de ramener le risque à un niveau faible ou modéré, le traitement peut généralement être regardé comme acceptable dans le cadre de l’AIPD, sous réserve que les informations analysées soient exactes et que les mesures soient réellement appliquées.
Lorsque le risque reste significatif mais paraît maîtrisable, le traitement peut être acceptable sous conditions. Dans ce cas, l’AIPD doit dire précisément quelles mesures doivent être mises en œuvre, dans quel délai, par quel acteur, et avec quelle vérification. Une condition qui n’a ni responsable, ni échéance, ni contrôle prévisible ressemble davantage à une intention qu’à une garantie.
Lorsque le risque demeure élevé malgré les mesures prévues, le traitement ne peut pas être traité comme un simple sujet documentaire. Il faut réexaminer la conception du traitement, réduire son périmètre, modifier ses modalités, renforcer les garanties, voire différer sa mise en œuvre.
Et lorsque le risque élevé persiste malgré les mesures raisonnablement envisageables, la question d’une consultation préalable de l’autorité de contrôle doit être posée. Le RGPD prévoit cette consultation lorsque l’analyse d’impact indique que le traitement présenterait un risque élevé en l’absence de mesures prises par le responsable de traitement pour atténuer ce risque. La CNIL prévoit également un service de soumission d’AIPD dans les hypothèses de consultation obligatoire.
Le risque résiduel n’est donc pas une simple ligne de fin de tableau. C’est le point où l’organisme doit dire si le traitement peut être mis en œuvre, maintenu, modifié, conditionné, suspendu ou réexaminé. Cette étape doit aussi éviter une confusion classique : accepter un risque ne veut pas dire l’effacer. Un risque accepté reste un risque.
La différence, c’est qu’il est identifié, documenté, justifié, encadré et assumé. L’organisme doit pouvoir expliquer pourquoi il considère ce risque résiduel acceptable au regard de la finalité poursuivie, des droits et libertés concernés, des mesures prévues, du contexte du traitement et des alternatives disponibles.
À l’inverse, un risque résiduel mal décrit finit par affaiblir toute l’AIPD. On ne sait plus vraiment ce qui est accepté. On ne sait plus si les mesures sont des conditions, des recommandations ou de simples pistes. On ne sait plus si le traitement peut être lancé immédiatement ou seulement après modification. On ne sait plus qui porte l’arbitrage.
Et lorsque personne ne porte l’arbitrage, il n’a souvent pas disparu. Il s’est simplement caché dans le document. C’est pour cela que la conclusion de l’AIPD doit être claire. Elle doit pouvoir dire, sans détour inutile :
le traitement est acceptable en l’état ;
le traitement est acceptable sous réserve de mesures complémentaires ;
le traitement doit être modifié avant mise en œuvre ou poursuite ;
le traitement présente un risque élevé persistant et nécessite une analyse supplémentaire, voire une consultation préalable ;
le traitement doit être abandonné ou reconfiguré.
Ce n’est pas une formalité. C’est le moment où l’AIPD cesse d’être une analyse et devient une décision de gouvernance. Le risque résiduel doit aussi être suivi dans le temps.
Une AIPD n’est pas un document figé. Un traitement évolue : changement d’outil, extension de finalité, ajout de données, nouveaux destinataires, modification des accès, nouveau sous-traitant, augmentation du volume, incident, réclamation, évolution technologique. Ce qui était acceptable à un instant donné peut devenir insuffisamment maîtrisé plus tard.
La CNIL rappelle que l’AIPD doit s’inscrire dans une logique de suivi du traitement et qu’elle peut être nécessaire non seulement avant la mise en œuvre, mais aussi lorsque le traitement évolue ou lorsque les risques changent. Cela signifie que le risque résiduel n’est pas seulement une conclusion. C’est aussi un point de surveillance.
Si le traitement est accepté sous conditions, il faut vérifier que les conditions sont effectivement mises en œuvre. Si le risque est modéré mais sensible, il faut prévoir un suivi. Si le traitement repose sur des mesures techniques ou organisationnelles fragiles, il faut les contrôler. Si le contexte change, il faut rouvrir l’analyse.
Une AIPD sérieuse doit donc permettre de répondre à trois questions finales :
Qu’est-ce qui reste ?
Qui accepte que cela reste ?
Quand faudra-t-il vérifier si cela reste encore acceptable ?
C’est ce triptyque qui donne une vraie valeur à la conclusion. Sans cela, l’AIPD peut devenir un document qui rassure sans décider. Or le but n’est pas de produire une analyse élégante. Le but est de rendre l’arbitrage lisible.
Le risque résiduel est donc le vrai point de sortie de l’AIPD : il concentre ce que l’organisme a compris, ce qu’il a corrigé, ce qu’il a encadré, ce qu’il accepte encore et ce qu’il devra surveiller.
Le règlement européen sur l’intelligence artificielle, dit AI Act, est entré en vigueur le 1er août 2024, avec une application échelonnée selon les catégories d’obligations.
Certaines dispositions sont déjà applicables, notamment les interdictions de certaines pratiques et l’exigence de maîtrise de l’IA, tandis que d’autres, en particulier celles relatives aux systèmes d’IA à haut risque, devaient entrer en application plus tardivement.
Dans ce contexte, la Commission européenne a présenté le 19 novembre 2025 une proposition de Digital Omnibus on AI Regulation, explicitement décrite comme une simplification ciblée de certaines dispositions de l’AI Act. Le Conseil a arrêté sa position le 13 mars 2026 et le Parlement européen a adopté la sienne le 26 mars 2026.
La présente note ne constitue pas un bilan d’application du régime haut risque. Un tel bilan serait prématuré. Elle vise plus modestement, mais aussi plus utilement, à analyser la logique de la simplification proposée.
Sous cet angle, la thèse défendue ici est simple : l’AI Omnibus ne rééquilibre pas réellement l’architecture de l’AI Act ;
il en aménage surtout le calendrier, allège certains points pour des catégories déterminées d’entreprises, et révèle une priorité politique de diffusion économique de l’IA davantage qu’une refonte cohérente de la chaîne de conformité.
Le premier constat est que l’AI Omnibus ne procède pas à une simplification de fond du régime haut risque. La proposition de la Commission et la position du Conseil reposent notamment sur l’idée que les obligations centrales du chapitre III devraient s’appliquer lorsque les standards, les outils et les mesures de soutien à la conformité seront disponibles, avec des dates butoirs si cette disponibilité n’est pas confirmée à temps. Le Conseil a résumé cette logique en expliquant que l’ajustement du calendrier devait permettre l’application des règles lorsque les standards et outils nécessaires seraient prêts.
Cette approche peut se comprendre pratiquement. Mais elle révèle surtout que l’infrastructure de conformité n’était pas complètement prête au moment où le cadre a été conçu. Un report peut éviter un atterrissage chaotique. Il ne constitue pas, en lui-même, une amélioration normative.
Ce point est essentiel. Le problème ne semble pas être, d’abord, que les critères du régime haut risque seraient tous excessifs en eux-mêmes. Le problème paraît plutôt tenir à l’insuffisante préparation de leur méthode de contrôle. Des exigences comme la robustesse, la qualité des données, la supervision humaine, la traçabilité ou la surveillance après commercialisation ont une portée réelle seulement si elles peuvent être traduites en référentiels, protocoles, standards, seuils, méthodes de documentation et pratiques d’évaluation.
Or la Commission elle-même présente les standards harmonisés comme l’outil destiné à transformer les exigences juridiques du texte en langage technique commun, et reconnaît que ce travail n’était pas achevé dans les délais initialement attendus. L’Omnibus apparaît ainsi moins comme une simplification du contenu des obligations que comme une réponse au retard de l’infrastructure censée permettre leur mise en œuvre.
Le second constat, plus politique, concerne la création et la mobilisation de la catégorie des PEMC.
La Commission a clairement choisi d’étendre à ces entreprises intermédiaires certains avantages ou assouplissements jusque-là réservés aux PME et aux jeunes pousses. Dans son agenda de simplification, elle a présenté cette orientation comme un moyen de réduire les charges administratives et de soutenir la compétitivité.
C’est probablement le marqueur politique le plus révélateur de l’Omnibus. En effet, le texte ne simplifie pas principalement par rôle dans la chaîne de l’IA, mais d’abord par profil économique du bénéficiaire. Or cette logique n’est pas neutre. Elle suggère moins une reconstruction de la conformité autour des fonctions juridiques et opérationnelles des acteurs qu’un soutien ciblé à une strate intermédiaire d’entreprises que l’Union souhaite voir adopter et déployer davantage l’IA.
Ce choix appelle deux observations.
D’une part, il n’est pas illégitime, en soi, de prendre en compte la taille des opérateurs. Une régulation mature doit pouvoir distinguer entre une petite structure de bonne foi, encore en phase d’appropriation, et un acteur disposant déjà d’une capacité significative d’organisation, de documentation et de contrôle interne.
D’autre part, l’extension des allégements aux PEMC n’apparaît pas comme une nécessité technique évidente du point de vue de la cohérence du régime.
Elle ressemble davantage à un choix de politique économique qu’à une réponse démontrée à un blocage juridique ou méthodologique précisément identifié.
De ce point de vue, l’AI Omnibus confirme une tendance déjà visible dans d’autres projets de simplification récents : la simplification est pensée d’abord par entité économique, beaucoup moins par acteur de la chaîne normative.
Le troisième constat est que l’Omnibus touche à l’un des rares points qui auraient pu servir de socle commun transversal à l’ensemble des systèmes d’IA : la maîtrise de l’IA. Dans le cadre actuellement en vigueur, l’article 4 impose aux fournisseurs et aux déployeurs de prendre des mesures pour garantir un niveau suffisant de maîtrise de l’IA pour leur personnel et les personnes agissant pour leur compte. La Commission présente cette disposition comme une exigence réelle, rappelant qu’une simple lecture de la notice ou une information superficielle ne suffit pas nécessairement.
Or la proposition d’Omnibus transforme cette logique en un mécanisme d’encouragement par la Commission et les États membres, ce qui affaiblit clairement la densité normative de l’exigence. Ce déplacement est regrettable. Il ne réduit pas seulement une charge. Il désactive partiellement un principe qui aurait pu servir de base horizontale commune à une régulation plus cohérente de l’IA.
À cet égard, l’Omnibus donne parfois le sentiment d’une simplification qui retarde ou atténue plutôt qu’elle ne réorganise.
Or l’expérience d’autres cadres européens, notamment en protection des données, montre qu’il existe une différence entre la fermeté de la norme et la fermeté de son enforcement. Il est parfaitement possible de maintenir des obligations juridiques substantielles tout en organisant une montée en charge progressive par la pédagogie, les lignes directrices, les référentiels, les mesures correctrices et, seulement ensuite, la sanction lourde lorsque la mauvaise foi, la persistance ou la récidive le justifient. L’Omnibus semble parfois choisir une autre voie : alléger la norme elle-même ou différer son effectivité, là où une stratégie de déploiement gradué aurait peut-être suffi.
Dès lors, si l’on voulait vraiment simplifier intelligemment, il aurait sans doute fallu raisonner autrement. Non pas d’abord par taille d’entreprise, mais par acteur de la chaîne de l’IA.
Si l’objectif prioritaire est le soutien au fournisseur, il faut améliorer les outils qui conditionnent sa conformité réelle : référentiels, standards, sandbox, méthodes d’évaluation, articulation avec les procédures sectorielles. Si l’objectif prioritaire est l’extension de l’usage de l’IA, il faut alors clarifier la situation du déployeur : obligation de supervision, documentation de l’usage, information, remontée d’incidents, responsabilité en cas de mauvais paramétrage ou de mésusage. Dans les deux cas, la simplification devrait porter sur les fonctions exercées dans le cycle de vie du système, et non exclusivement sur la taille ou la catégorie économique de l’entité concernée.
En définitive, l’AI Omnibus présente une utilité politique et pratique réelle.
Il permet de traiter la question des délais, de la préparation des outils de conformité, de certaines redondances procédurales et de l’extension d’assouplissements à une catégorie élargie d’entreprises.
Mais il ne faut pas lui faire dire plus qu’il ne fait. Il ne reconstruit pas la logique du régime. Il ne simplifie pas prioritairement par acteur de la chaîne de l’IA. Il n’apporte pas, à ce stade, de réponse pleinement satisfaisante à la question centrale de l’opérabilité des obligations haut risque. Et il ne transforme pas un report d’entrée en application en amélioration substantielle du droit.
À ce stade, l’Omnibus doit donc être lu pour ce qu’il est : moins un rééquilibrage juridique de l’AI Act qu’un instrument de gestion politique et économique de son déploiement.
VI. L’arbitrage ne doit pas être symétrique par défaut
L’AIPD repose classiquement sur deux axes : la vraisemblance et la gravité. C’est nécessaire. La vraisemblance permet d’apprécier si un scénario peut raisonnablement se produire, au regard du fonctionnement réel du traitement, des vulnérabilités identifiées, des pratiques observées et des mesures déjà en place.
La gravité permet d’apprécier l’ampleur des conséquences possibles pour les personnes concernées : atteinte à la confidentialité, exclusion, discrimination, perte de chance, atteinte à la réputation, dommage matériel, impossibilité d’exercer un droit, atteinte à la sécurité physique ou psychologique, ou effet difficilement réversible.
La CNIL rappelle d’ailleurs que le niveau d’un risque est estimé en fonction de sa gravité et de sa vraisemblance : la gravité renvoie aux impacts potentiels, tandis que la vraisemblance traduit la possibilité que le risque se réalise. Mais cette double lecture ne signifie pas que les deux critères doivent toujours peser de manière strictement symétrique dans l’arbitrage final. C’est là qu’il faut être prudent.
Une matrice classique peut donner l’impression que la vraisemblance et la gravité se compensent naturellement. Un risque très grave mais peu vraisemblable descend mécaniquement. Un risque très vraisemblable mais peu grave remonte mécaniquement. La lecture paraît équilibrée. Elle peut pourtant devenir trop automatique.
Le problème n’est pas que cette méthode soit inutile. Elle permet de structurer l’analyse. Le problème est qu’elle peut masquer la question la plus importante : quel type de risque l’organisme refuse-t-il réellement de banaliser ? Selon les traitements, la réponse ne sera pas toujours la même.
Pour un organisme, la crainte structurante peut être le scénario rare mais destructeur : fuite de données sensibles, divulgation d’informations intimes, erreur produisant une perte de droit, décision automatisée défavorable, atteinte durable à une personne vulnérable.
Pour un autre, la crainte structurante peut être la répétition d’incidents moins graves, mais nombreux, mal maîtrisés, qui finissent par rendre le traitement structurellement fragile : erreurs fréquentes, droits mal exercés, accès trop larges, information systématiquement insuffisante, conservation non tenue, correction trop lente.
Dans les deux cas, l’AIPD doit permettre à l’organisme de choisir sa grille d’arbitrage. Pas au sens où il pourrait manipuler les résultats pour les rendre plus confortables. Mais au sens où il doit expliciter ce qu’il considère comme déterminant dans le traitement analysé.
C’est ici que l’arbitrage devient asymétrique. L’asymétrie ne signifie pas nécessairement que la gravité doit toujours dominer en toutes circonstances. Elle signifie que l’organisme ne doit pas laisser la matrice décider seule de ce qui compte.
Il doit déterminer si, dans le traitement étudié, le danger principal tient plutôt :
à un dommage grave même peu probable ;
à une répétition d’incidents moins graves mais structurels ;
à une erreur difficilement réversible ;
à une exposition massive ;
à une atteinte concernant des personnes vulnérables ;
à une opacité qui empêche les personnes d’exercer leurs droits ;
à une décision qui produit un effet important sur l’accès à un droit, un service, un emploi ou une prise en charge.
Cette décision méthodologique doit être assumée. Si l’organisme considère qu’un dommage très grave ne doit jamais être banalisé, même avec une vraisemblance faible, il doit le dire. Si, dans un autre contexte, il considère qu’une récurrence élevée de petits incidents constitue le vrai signal d’alerte, il doit aussi le dire. Ce qui n’est pas acceptable, c’est de laisser une grille uniforme produire une conclusion apparemment neutre, sans que l’organisme ait réellement interrogé ce qu’il cherche à éviter.
La symétrie parfaite est confortable. Elle donne le sentiment que le calcul arbitre à la place de l’organisation. Mais l’AIPD n’est pas un exercice de neutralisation morale par tableau. C’est une méthode de décision.
Le RGPD vise les risques pour les droits et libertés des personnes concernées. La CNIL rappelle que l’AIPD concerne les traitements susceptibles d’engendrer un risque élevé pour ces droits et libertés. Le CEPD inscrit également l’AIPD dans une logique de gestion des risques liés aux traitements à haut risque. Cette logique suppose que l’organisme ne se contente pas de calculer. Il doit interpréter.
Une note de risque n’a donc de sens que si elle est accompagnée d’une lecture d’acceptabilité. Un score peut dire qu’un risque est modéré. Mais si ce risque porte sur une donnée très sensible, une personne vulnérable, un effet irréversible ou un droit essentiel, l’organisme peut décider de le traiter comme prioritaire.
À l’inverse, un score peut paraître élevé parce qu’un incident mineur est très fréquent. Cela peut appeler une correction rapide, une procédure plus fiable, une formation ou un contrôle. Mais cela ne signifie pas automatiquement que le traitement présente le même niveau d’alerte qu’un scénario rare mais gravement dommageable. La cotation mesure. L’arbitrage qualifie. Cette distinction est essentielle.
Elle évite deux erreurs. La première consiste à minimiser un scénario grave au motif qu’il est peu probable. La seconde consiste à dramatiser mécaniquement un scénario peu grave au seul motif qu’il est fréquent.
Dans une AIPD, l’organisme doit donc construire une lecture d’acceptabilité qui ne soit pas purement arithmétique. La vraisemblance et la gravité doivent être analysées ensemble, mais leur poids dans l’arbitrage final peut varier selon le traitement, les personnes concernées, les données traitées, la finalité poursuivie et les effets possibles.
Cela suppose de documenter clairement la méthode retenue.
Si la gravité est considérée comme structurante, il faut l’expliquer.
Si la récurrence est considérée comme le signal principal, il faut l’expliquer.
Si certains critères entraînent un surclassement du risque, il faut les identifier : données sensibles, mineurs, personnes vulnérables, effet durable, effet difficilement réversible, exposition massive, atteinte au secret professionnel, profilage, décision produisant un effet significatif.
L’objectif n’est pas de rendre l’AIPD plus sévère pour le plaisir. L’objectif est d’éviter que la méthode rende le risque plus acceptable qu’il ne l’est réellement.
Un arbitrage asymétrique bien documenté permet justement de rendre l’analyse plus honnête. Il montre que l’organisme ne se contente pas d’appliquer une grille mécanique. Il dit ce qu’il considère comme déterminant, pourquoi, et avec quelles conséquences sur l’acceptabilité du traitement.
L’AIPD doit donc aboutir à une conclusion lisible :
ce scénario est acceptable, parce que le risque est faible et maîtrisé ;
ce scénario est surveillé, parce qu’il est fréquent mais corrigible ;
ce scénario est conditionné, parce qu’il est sérieux et nécessite des mesures fortes ;
ce scénario bloque ou reconfigure le traitement, parce que le dommage potentiel est trop grave ou trop difficilement assumable.
L’arbitrage asymétrique n’est pas un artifice. C’est la reconnaissance d’une réalité simple : tous les risques ne se valent pas, même lorsqu’ils obtiennent un score comparable. Deux scénarios peuvent avoir la même note. Ils ne racontent pas nécessairement la même chose. L’un peut traduire une gêne fréquente mais réversible. L’autre peut traduire une atteinte rare mais durable à un droit essentiel.
Les traiter de la même manière parce qu’ils partagent un score identique serait précisément ce que l’AIPD doit éviter. Le rôle de l’AIPD n’est donc pas seulement de produire une note finale. Il est de rendre compréhensible le raisonnement qui conduit à l’acceptation, à la réduction, à l’encadrement, à la modification ou au refus du traitement.
La vraisemblance et la gravité sont les deux axes de l’analyse. Mais l’arbitrage final doit rester une décision assumée. Pas une simple conséquence automatique du tableau.
Le règlement européen sur l’intelligence artificielle, dit AI Act, est entré en vigueur le 1er août 2024, avec une application échelonnée selon les catégories d’obligations.
Certaines dispositions sont déjà applicables, notamment les interdictions de certaines pratiques et l’exigence de maîtrise de l’IA, tandis que d’autres, en particulier celles relatives aux systèmes d’IA à haut risque, devaient entrer en application plus tardivement.
Dans ce contexte, la Commission européenne a présenté le 19 novembre 2025 une proposition de Digital Omnibus on AI Regulation, explicitement décrite comme une simplification ciblée de certaines dispositions de l’AI Act. Le Conseil a arrêté sa position le 13 mars 2026 et le Parlement européen a adopté la sienne le 26 mars 2026.
La présente note ne constitue pas un bilan d’application du régime haut risque. Un tel bilan serait prématuré. Elle vise plus modestement, mais aussi plus utilement, à analyser la logique de la simplification proposée.
Sous cet angle, la thèse défendue ici est simple : l’AI Omnibus ne rééquilibre pas réellement l’architecture de l’AI Act ;
il en aménage surtout le calendrier, allège certains points pour des catégories déterminées d’entreprises, et révèle une priorité politique de diffusion économique de l’IA davantage qu’une refonte cohérente de la chaîne de conformité.
Le premier constat est que l’AI Omnibus ne procède pas à une simplification de fond du régime haut risque. La proposition de la Commission et la position du Conseil reposent notamment sur l’idée que les obligations centrales du chapitre III devraient s’appliquer lorsque les standards, les outils et les mesures de soutien à la conformité seront disponibles, avec des dates butoirs si cette disponibilité n’est pas confirmée à temps. Le Conseil a résumé cette logique en expliquant que l’ajustement du calendrier devait permettre l’application des règles lorsque les standards et outils nécessaires seraient prêts.
Cette approche peut se comprendre pratiquement. Mais elle révèle surtout que l’infrastructure de conformité n’était pas complètement prête au moment où le cadre a été conçu. Un report peut éviter un atterrissage chaotique. Il ne constitue pas, en lui-même, une amélioration normative.
Ce point est essentiel. Le problème ne semble pas être, d’abord, que les critères du régime haut risque seraient tous excessifs en eux-mêmes. Le problème paraît plutôt tenir à l’insuffisante préparation de leur méthode de contrôle. Des exigences comme la robustesse, la qualité des données, la supervision humaine, la traçabilité ou la surveillance après commercialisation ont une portée réelle seulement si elles peuvent être traduites en référentiels, protocoles, standards, seuils, méthodes de documentation et pratiques d’évaluation.
Or la Commission elle-même présente les standards harmonisés comme l’outil destiné à transformer les exigences juridiques du texte en langage technique commun, et reconnaît que ce travail n’était pas achevé dans les délais initialement attendus. L’Omnibus apparaît ainsi moins comme une simplification du contenu des obligations que comme une réponse au retard de l’infrastructure censée permettre leur mise en œuvre.
Le second constat, plus politique, concerne la création et la mobilisation de la catégorie des PEMC.
La Commission a clairement choisi d’étendre à ces entreprises intermédiaires certains avantages ou assouplissements jusque-là réservés aux PME et aux jeunes pousses. Dans son agenda de simplification, elle a présenté cette orientation comme un moyen de réduire les charges administratives et de soutenir la compétitivité.
C’est probablement le marqueur politique le plus révélateur de l’Omnibus. En effet, le texte ne simplifie pas principalement par rôle dans la chaîne de l’IA, mais d’abord par profil économique du bénéficiaire. Or cette logique n’est pas neutre. Elle suggère moins une reconstruction de la conformité autour des fonctions juridiques et opérationnelles des acteurs qu’un soutien ciblé à une strate intermédiaire d’entreprises que l’Union souhaite voir adopter et déployer davantage l’IA.
Ce choix appelle deux observations.
D’une part, il n’est pas illégitime, en soi, de prendre en compte la taille des opérateurs. Une régulation mature doit pouvoir distinguer entre une petite structure de bonne foi, encore en phase d’appropriation, et un acteur disposant déjà d’une capacité significative d’organisation, de documentation et de contrôle interne.
D’autre part, l’extension des allégements aux PEMC n’apparaît pas comme une nécessité technique évidente du point de vue de la cohérence du régime.
Elle ressemble davantage à un choix de politique économique qu’à une réponse démontrée à un blocage juridique ou méthodologique précisément identifié.
De ce point de vue, l’AI Omnibus confirme une tendance déjà visible dans d’autres projets de simplification récents : la simplification est pensée d’abord par entité économique, beaucoup moins par acteur de la chaîne normative.
Le troisième constat est que l’Omnibus touche à l’un des rares points qui auraient pu servir de socle commun transversal à l’ensemble des systèmes d’IA : la maîtrise de l’IA. Dans le cadre actuellement en vigueur, l’article 4 impose aux fournisseurs et aux déployeurs de prendre des mesures pour garantir un niveau suffisant de maîtrise de l’IA pour leur personnel et les personnes agissant pour leur compte. La Commission présente cette disposition comme une exigence réelle, rappelant qu’une simple lecture de la notice ou une information superficielle ne suffit pas nécessairement.
Or la proposition d’Omnibus transforme cette logique en un mécanisme d’encouragement par la Commission et les États membres, ce qui affaiblit clairement la densité normative de l’exigence. Ce déplacement est regrettable. Il ne réduit pas seulement une charge. Il désactive partiellement un principe qui aurait pu servir de base horizontale commune à une régulation plus cohérente de l’IA.
À cet égard, l’Omnibus donne parfois le sentiment d’une simplification qui retarde ou atténue plutôt qu’elle ne réorganise.
Or l’expérience d’autres cadres européens, notamment en protection des données, montre qu’il existe une différence entre la fermeté de la norme et la fermeté de son enforcement. Il est parfaitement possible de maintenir des obligations juridiques substantielles tout en organisant une montée en charge progressive par la pédagogie, les lignes directrices, les référentiels, les mesures correctrices et, seulement ensuite, la sanction lourde lorsque la mauvaise foi, la persistance ou la récidive le justifient. L’Omnibus semble parfois choisir une autre voie : alléger la norme elle-même ou différer son effectivité, là où une stratégie de déploiement gradué aurait peut-être suffi.
Dès lors, si l’on voulait vraiment simplifier intelligemment, il aurait sans doute fallu raisonner autrement. Non pas d’abord par taille d’entreprise, mais par acteur de la chaîne de l’IA.
Si l’objectif prioritaire est le soutien au fournisseur, il faut améliorer les outils qui conditionnent sa conformité réelle : référentiels, standards, sandbox, méthodes d’évaluation, articulation avec les procédures sectorielles. Si l’objectif prioritaire est l’extension de l’usage de l’IA, il faut alors clarifier la situation du déployeur : obligation de supervision, documentation de l’usage, information, remontée d’incidents, responsabilité en cas de mauvais paramétrage ou de mésusage. Dans les deux cas, la simplification devrait porter sur les fonctions exercées dans le cycle de vie du système, et non exclusivement sur la taille ou la catégorie économique de l’entité concernée.
En définitive, l’AI Omnibus présente une utilité politique et pratique réelle.
Il permet de traiter la question des délais, de la préparation des outils de conformité, de certaines redondances procédurales et de l’extension d’assouplissements à une catégorie élargie d’entreprises.
Mais il ne faut pas lui faire dire plus qu’il ne fait. Il ne reconstruit pas la logique du régime. Il ne simplifie pas prioritairement par acteur de la chaîne de l’IA. Il n’apporte pas, à ce stade, de réponse pleinement satisfaisante à la question centrale de l’opérabilité des obligations haut risque. Et il ne transforme pas un report d’entrée en application en amélioration substantielle du droit.
À ce stade, l’Omnibus doit donc être lu pour ce qu’il est : moins un rééquilibrage juridique de l’AI Act qu’un instrument de gestion politique et économique de son déploiement.
Sources principales
Sources principales
RGPD, article 35 – Analyse d’impact relative à la protection des données
RGPD, article 25 – Protection des données dès la conception et par défaut
CNIL – L’analyse d’impact relative à la protection des données, AIPD
CNIL – Listes des traitements pour lesquels une AIPD est requise ou non
CEPD – Guidelines 4/2019 on Article 25 Data Protection by Design and by Default, PDF