Bien utiliser son DPO : périmètre, gouvernance et risques de dilution de la fonction
Bien utiliser son DPO : périmètre, gouvernance et risques de dilution de la fonction
Note - publiée le 19 mai 2026
Note - publiée le 19 mai 2026
I. Une fonction transversale ne doit pas devenir une fonction fourre-tout
La désignation d’un DPO ne doit pas conduire à faire de lui le réceptacle général de toutes les difficultés liées aux données, aux outils numériques, à l’intelligence artificielle, à la cybersécurité, aux contrats ou à la gouvernance interne.
Le DPO occupe bien une fonction transversale. C’est même une condition de son utilité. Il doit être associé aux questions relatives à la protection des données personnelles, informer et conseiller l’organisme, contrôler le respect du RGPD, contribuer aux analyses d’impact, coopérer avec l’autorité de contrôle et servir de point de contact. Il doit donc comprendre l’environnement réel dans lequel les traitements sont mis en œuvre : les outils utilisés, les données qui circulent, les services concernés, les prestataires impliqués, les mesures de sécurité, les projets en cours et les pratiques métiers.
Cette compréhension doit nécessairement dépasser le seul RGPD documentaire. Un DPO utile ne peut pas se limiter aux mentions d’information, au registre des traitements ou aux clauses de sous-traitance. Il doit comprendre les logiques d’IA lorsqu’un système traite des données personnelles. Il doit comprendre les enjeux cyber lorsque les mesures de sécurité conditionnent la confidentialité, l’intégrité ou la disponibilité des données. Il doit comprendre les contrats lorsque les flux, les garanties et les obligations des sous-traitants structurent la conformité. Il doit aussi comprendre les métiers, parce qu’une recommandation juridiquement correcte mais opérationnellement inapplicable ne sert pas à grand-chose, à part décorer un dossier.
Mais comprendre n’est pas absorber.
C’est ici que le glissement commence. Parce qu’un sujet touche à la donnée, il est envoyé au DPO. Un nouvel outil ? DPO. Un projet IA ? DPO. Un incident de sécurité ? DPO. Un prestataire à contrôler ? DPO. Une procédure interne ? DPO. Une question cyber ? DPO. À force, la fonction devient un point de convergence de tout ce que l’organisation n’a pas structuré ailleurs.
Ce réflexe peut sembler efficace à court terme. Il donne l’impression qu’un interlocuteur unique maîtrise l’ensemble du sujet. En réalité, il peut produire l’effet inverse : brouiller le rôle du DPO, affaiblir la responsabilité des métiers, créer une dépendance excessive à une personne ou à un prestataire, et faire perdre au DPO le recul nécessaire pour exercer sa mission de conseil et de contrôle.
Le sujet n’est donc pas de réduire le rôle du DPO. Il est de le clarifier.
Le DPO doit élargir sa compréhension des sujets connexes à la protection des données, sans diluer sa fonction propre. Il peut travailler avec le RSSI sans devenir RSSI. Il peut intervenir sur un projet IA sans devenir responsable global de la conformité IA. Il peut analyser des clauses RGPD sans devenir responsable contractuel. Il peut proposer une méthode sans devenir le décideur final de l’organisation.
La proximité des sujets justifie la coopération. Elle ne justifie pas l’absorption.
Un DPO réellement utile n’est donc pas celui à qui l’on confie tout. C’est celui que l’organisation associe suffisamment tôt, informe correctement, écoute sérieusement, et place dans une gouvernance où chaque acteur conserve son rôle.
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. Éclairer les arbitrages sans devenir juge et partie
Le DPO peut identifier un risque, analyser un écart, recommander une mesure, proposer une méthode, documenter une réserve ou alerter sur les conséquences d’un choix. C’est même le cœur de sa fonction. Mais il ne doit pas être placé seul en position d’arbitrer les choix de l’organisme.
La distinction est importante. Le DPO peut dire : “Voici les risques. Voici les options. Voici les conséquences possibles. Voici les garanties à prévoir. Voici les points qui doivent être arbitrés.”
Mais la décision finale appartient à l’organisme : direction, responsable de traitement, sous-traitant, métiers ou instances internes compétentes. Le DPO n’est pas là pour confisquer la décision. Il est là pour la rendre plus lucide.
Ce point est essentiel lorsque les sujets deviennent techniques ou transversaux : choix d’un outil, niveau de sécurité retenu, recours à un prestataire, déploiement d’un système d’IA, calendrier de remédiation, niveau de risque accepté, budget mobilisé. Le DPO peut éclairer ces choix au regard de la protection des données personnelles. Il peut recommander, alerter, prioriser, expliquer pourquoi une option est plus prudente qu’une autre.
Mais il ne doit pas devenir celui qui décide, exécute, pilote, puis contrôle les décisions qu’il a lui-même portées. C’est là que le risque juridique apparaît.
Le RGPD n’interdit pas au DPO d’exercer d’autres missions. En revanche, ces missions ne doivent pas créer de conflit d’intérêts. Le problème ne tient donc pas seulement au cumul de titres sur un organigramme. Il tient à la réalité des fonctions exercées. La vraie question est simple : La mission confiée au DPO le conduit-elle à déterminer ce qu’il devra ensuite contrôler ? Si oui, le périmètre devient sensible.
Un DPO peut travailler avec le RSSI sans devenir RSSI. Il peut comprendre les mesures de sécurité sans déterminer seul toute la politique de sécurité. Il peut être associé à un projet IA sans devenir responsable global de la conformité IA. Il peut analyser les clauses RGPD d’un contrat sans devenir responsable unique de la négociation contractuelle. Il peut proposer une mesure de remédiation sans assumer à lui seul l’arbitrage budgétaire, technique ou organisationnel.
La difficulté commence lorsque les grilles de lecture se mélangent. Le DPO regarde d’abord les traitements sous l’angle des données personnelles, des droits et libertés des personnes, de la licéité, de la minimisation, de la transparence, de la sécurité, de la proportionnalité et de la documentation.
D’autres grilles existent : cyber, métier, économique, juridique, technique, stratégique. Elles doivent dialoguer avec celle du DPO. Mais elles ne doivent pas être fusionnées dans une fonction confuse, où l’on ne sait plus si la décision a été prise pour protéger les personnes, réduire les coûts, simplifier le projet, accélérer le calendrier ou éviter un conflit interne.
Le risque n’est donc pas seulement juridique. Il est aussi opérationnel. Lorsque tout passe par le DPO, l’organisme peut avoir l’impression d’une meilleure maîtrise. En pratique, il peut produire l’effet inverse : un goulot d’étranglement.
Si le DPO doit tout voir, tout lire, tout valider, tout rédiger, tout corriger, tout suivre et tout expliquer, l’organisation ne devient pas plus mature. Elle devient dépendante d’une personne ou d’un prestataire.
Ce modèle affaiblit les métiers, qui cessent de s’approprier leurs responsabilités. Il affaiblit la direction, qui peut être tentée de déléguer ses arbitrages. Il affaiblit aussi le DPO, qui perd le temps nécessaire à sa vraie valeur ajoutée : veille, analyse, contrôle, amélioration des méthodes, suivi des plans d’action, préparation des sensibilisations, revue des traitements à risque, accompagnement des AIPD et identification des écarts récurrents.
Ce temps n’est pas du vide. C’est le temps qui permet d’éviter que l’organisation ne fonctionne uniquement dans l’urgence. Un DPO utilisé seulement lorsqu’un problème arrive devient un pompier documentaire. Utile, parfois. Mais insuffisant. Un DPO bien utilisé doit pouvoir éclairer les arbitrages avant qu’ils ne deviennent des problèmes, conserver une distance suffisante pour contrôler les pratiques, et disposer du temps nécessaire pour améliorer progressivement la gouvernance de l’organisme.
Le bon équilibre est donc le suivant : Le DPO éclaire. L’organisme arbitre. Les métiers exécutent. Le DPO contrôle et alerte.
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. Organiser une gouvernance praticable autour du DPO
Le DPO n’est pas seulement une vigie juridique. Il est aussi, en partie, un stratège opérationnel. Pas parce qu’il déciderait à la place de l’organisme. Mais parce qu’il doit aider à transformer les obligations RGPD en méthodes applicables. C’est un équilibre difficile.
Une méthode trop lourde ne sera pas appliquée.
Une méthode trop légère ne sécurisera pas suffisamment les traitements.
Une méthode hors budget restera théorique.
Le rôle du DPO est donc d’aider l’organisme à construire une diligence proportionnée : assez robuste pour réduire les risques, assez claire pour être comprise, assez réaliste pour être appliquée, assez documentée pour être contrôlable, assez évolutive pour être améliorée. C’est là que se situe une vraie partie de sa valeur.
Pas dans la production d’une conformité parfaite sur le papier, mais dans la construction d’une conformité praticable, adaptée aux moyens, aux usages, aux métiers, aux risques et au niveau de maturité réel de l’organisme. Une méthode que personne n’utilise n’est pas une méthode exigeante. C’est une décoration documentaire. Cette gouvernance suppose aussi que le DPO ne soit pas le seul capteur du risque.
Un bon DPO n’est pas celui qui découvre tout par lui-même. C’est celui qui met l’organisation en capacité de faire remonter les bons signaux au bon moment. L’organisme ne peut pas attendre du DPO qu’il devine seul le lancement d’un nouvel outil, la création d’un nouveau fichier, le recours à un nouveau prestataire, un projet IA en préparation, un incident de sécurité, une demande d’exercice de droits, une nouvelle campagne marketing, une modification des pratiques RH ou un transfert de données non anticipé.
Si le DPO apprend tout après coup, il ne conseille plus vraiment. Il répare. Et souvent, il répare trop tard. Il faut donc organiser des circuits de remontée simples, connus et réellement utilisés :
consultation du DPO en amont des nouveaux projets ;
alerte en cas de nouveau traitement ;
procédure de remontée des violations de données ;
canal dédié aux demandes d’exercice de droits ;
information en cas de nouveau prestataire ;
consultation sur les projets IA impliquant des données personnelles ;
référents internes par service ;
points réguliers avec les fonctions clés ;
documentation des décisions prises malgré réserve ou alerte.
Le DPO ne remplace pas les métiers. Il leur donne une méthode pour faire remonter ce qui doit l’être. Cette logique vaut particulièrement pour les sujets voisins du RGPD.
L’intelligence artificielle, la cybersécurité, les contrats, la sous-traitance et les pratiques métiers ne doivent pas être ignorés par le DPO. Mais ils ne doivent pas non plus être empilés sur lui sans distinction. Sur un projet d’intelligence artificielle impliquant des données personnelles, le DPO doit être associé : bases légales, minimisation, transparence, information des personnes, droits, sécurité, documentation, analyse d’impact lorsque nécessaire. Mais il ne devient pas automatiquement responsable global de la conformité IA.
Sur les sujets cyber, le DPO doit comprendre les mesures de sécurité, les risques de violation de données, les procédures d’alerte et les impacts possibles sur les personnes. Mais il ne devient pas RSSI.
Sur les contrats et la sous-traitance, le DPO peut contribuer à l’analyse des clauses RGPD, des obligations du sous-traitant, des flux, des garanties et des risques associés. Mais il ne devient pas responsable unique de la négociation contractuelle.
Sur les pratiques métiers, le DPO doit comprendre les contraintes réelles pour formuler des recommandations applicables. Mais il ne décide pas à la place des opérationnels.
La bonne logique n’est donc pas l’absorption. C’est la coopération organisée. Le DPO doit être au croisement des sujets, pas au centre d’un entonnoir où tout finit par tomber. Une gouvernance utile repose sur cette distinction : chaque acteur conserve son rôle, mais les informations nécessaires circulent au bon moment.
C’est cette circulation qui permet au DPO d’être réellement efficace : voir assez tôt, comprendre assez largement, conseiller utilement, alerter clairement, puis contrôler avec suffisamment de recul.
Un DPO réellement augmenté n’est donc pas un DPO chargé de tout faire.
C’est un DPO mieux associé, mieux informé, mieux outillé, et intégré dans une organisation capable de faire remonter les bons risques avant qu’ils ne deviennent des urgences.
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. Recommandations opérationnelles : bien utiliser son DPO
Bien utiliser son DPO ne consiste pas à lui confier toutes les tâches liées aux données personnelles. Cela consiste à lui donner les moyens d’exercer correctement sa fonction : comprendre les traitements, être associé assez tôt, recevoir les informations utiles, éclairer les arbitrages, contrôler la cohérence des pratiques et alerter lorsque c’est nécessaire.
La première recommandation est donc de clarifier le périmètre du DPO.
Le DPO intervient sur la protection des données personnelles. Il peut dialoguer avec les fonctions voisines : IT, RSSI, juridique, métiers, conformité IA, direction. Mais il ne les remplace pas. Cette clarification doit être connue en interne, sinon l’organisme finit mécaniquement par orienter vers le DPO tout ce qu’il ne sait pas ranger ailleurs. Et là, on ne parle plus de gouvernance, mais de débarras organisationnel avec adresse mail.
La deuxième recommandation est d’associer le DPO suffisamment tôt.
Un DPO consulté lorsque l’outil est déjà choisi, le prestataire déjà signé, le formulaire déjà publié ou le projet IA déjà lancé n’est pas réellement associé. Il est utilisé comme tampon de fin de chaîne. Or le rôle du DPO est précisément d’éclairer les risques avant que les décisions ne soient figées. L’association en amont permet de poser les bonnes questions : quelles données ? quelle finalité ? quelle base légale ? quels accès ? quels sous-traitants ? quelle sécurité ? quelles garanties ? quels droits pour les personnes ?
La troisième recommandation est de préserver son indépendance fonctionnelle.
Le DPO doit pouvoir formuler des alertes, documenter ses réserves, signaler les écarts et rendre compte au niveau approprié de direction. Il ne doit pas recevoir d’instruction sur le sens de ses avis ni être sanctionné pour avoir exercé ses missions. Cette indépendance ne sert pas à protéger l’ego du DPO, activité déjà suffisamment répandue dans le monde professionnel. Elle sert à garantir que l’organisme puisse recevoir une analyse libre, utile et loyale des risques.
La quatrième recommandation est d’éviter les cumuls de fonctions à risque.
Le cumul n’est pas interdit par principe. Mais il doit être analysé concrètement. La question n’est pas seulement : “le DPO est-il compétent pour faire cela ?” La vraie question est : “cette mission le conduit-elle à déterminer ce qu’il devra ensuite contrôler ?” Si le DPO choisit seul un outil, fixe seul une architecture, arbitre seul un niveau de risque ou pilote seul une mesure qu’il devra ensuite contrôler, le périmètre devient sensible. Le risque n’est pas l’expertise du DPO. Le risque est qu’il devienne juge et partie.
La cinquième recommandation est de documenter les arbitrages.
Le DPO éclaire les options. L’organisme assume les décisions. Lorsqu’un choix est fait malgré un risque identifié, il doit être tracé : option retenue, raisons du choix, risques acceptés, garanties prévues, mesures de réduction, réserves éventuelles du DPO, calendrier de réexamen. Cette documentation évite deux erreurs classiques : faire comme si aucun risque n’existait, ou laisser croire que le DPO aurait décidé à la place de l’organisme.
La sixième recommandation est d’organiser les remontées d’information.
Le DPO ne peut pas deviner les nouveaux traitements depuis son bureau, par invocation mystique du registre. L’organisme doit prévoir des circuits simples : consultation en amont des nouveaux projets, alerte en cas d’incident, canal pour les demandes de droits, information en cas de nouveau prestataire, référents internes, points réguliers avec les fonctions clés. Sans remontée, il n’y a pas de pilotage. Il y a seulement de la découverte tardive, souvent suivie d’un soupir collectif.
La septième recommandation est de laisser du temps à la veille, au contrôle et à l’amélioration continue.
Le rôle du DPO ne se limite pas à répondre aux sollicitations. Il doit aussi suivre les évolutions de la CNIL, du CEPD, des pratiques sectorielles, des outils, des risques liés à l’IA, de la cybersécurité et des méthodes de conformité. Il doit pouvoir relire les procédures, contrôler les actions mises en œuvre, identifier les écarts récurrents et proposer des ajustements. Ce temps est moins visible qu’une réunion d’urgence. Il est souvent plus utile.
La huitième recommandation est de construire une méthode proportionnée.
Une gouvernance RGPD doit être adaptée aux moyens réels de l’organisme. Une procédure trop lourde ne sera pas appliquée. Une procédure trop légère ne réduira pas suffisamment les risques. Une procédure hors budget restera théorique. Le DPO doit aider à trouver ce point d’équilibre : suffisamment sérieux pour protéger les personnes, suffisamment simple pour être utilisé, suffisamment documenté pour être contrôlé.
La neuvième recommandation est de distinguer coopération et absorption.
Le DPO doit coopérer avec les fonctions cyber, IA, juridique, IT, RH, métiers ou direction. Mais coopérer ne signifie pas absorber. Sur un projet IA, il intervient sur les enjeux de données personnelles. Sur la cybersécurité, il apprécie les impacts sur la protection des données. Sur les contrats, il contribue à l’analyse RGPD des flux et garanties. Sur les métiers, il aide à rendre les pratiques compatibles avec les exigences de protection des données. Mais chaque fonction doit rester identifiable.
Enfin, la dixième recommandation est de faire vivre la gouvernance dans le temps.
Un DPO n’est pas utile seulement au moment de rédiger des documents ou de répondre à une urgence. Sa valeur tient aussi à sa capacité à faire progresser l’organisme : meilleure anticipation, meilleure remontée des risques, meilleure documentation, meilleure sensibilisation, meilleurs arbitrages. La conformité RGPD n’est pas un bloc figé. C’est une organisation qui apprend à mieux traiter ses données.
Bien utiliser son DPO, ce n’est pas tout lui confier. C’est lui donner une place claire, des informations utiles, une indépendance réelle, des relais internes et des arbitrages assumés par l’organisme. C’est à cette condition que le DPO peut jouer pleinement son rôle : non pas remplacer l’organisation, mais l’aider à devenir plus diligente.
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