Digital Omnibus européen 2026 : ce qui pourrait changer pour le Web Analytics, les cookies, la Data et l’intelligence artificielle

L’Europe prépare une révision importante de sa réglementation numérique. Et pour une fois, les changements envisagés touchent directement plusieurs aspects de mon métier : le tracking, la mesure d’audience, la gestion du consentement, l’exploitation des données, le développement d’applications métier et l’intégration de l’intelligence artificielle.

Voici le document source (14756/26, procédure 2025/0360 (COD) du Conseil de l’Union européenne du 21 octobre 2026 mise à jour au 28 octobre 2026. https://data.consilium.europa.eu/doc/document/ST-14756-2026-INIT/en/pdf?utm_source=webanalyste.com

Le changement le plus intéressant concerne les cookies. Le Conseil de l’Union européenne propose d’élargir les situations dans lesquelles certaines mesures d’audience et de performance publicitaire pourraient être réalisées sans consentement préalable. Il souhaite aussi réduire la répétition des demandes de consentement et permettre aux navigateurs de transmettre automatiquement les choix des internautes.

Ce n’est pas une évolution secondaire. Elle pourrait modifier la manière dont nous concevons les plans de taggage, configurons les plateformes de gestion du consentement (CMP), exploitons les données Analytics et mesurons la performance des sites web.

Data Marketing

Comment suivre les conversions de leads jusqu’au CRM ?

13/10/2026

D’autres propositions concernent les données pseudonymisées, les traitements nécessaires au développement de l’IA, la notification des incidents de sécurité et le partage des données.

Mais il faut poser une distinction essentielle : ces dispositions ne sont pas encore des obligations applicables.

Le 21 octobre 2026, le Comité des représentants permanents des États membres (Coreper) a arrêté un mandat de négociation avec le Parlement européen. Le texte transmis le 22 octobre constitue donc la position du Conseil, et non un règlement définitivement adopté.

C’est cette position que j’analyse, en distinguant les modifications proposées, leurs conditions et leurs conséquences opérationnelles pour les entreprises.

Ce qui change potentiellement pour les entreprises : les 8 points à retenir

Data Marketing

La précision du pipeline CRM est-elle fiable ?

09/10/2026

Priorités d’analyse pour une activité Web Analytics, Data Engineering, automatisation IA et développement web. Elles constituent mon appréciation professionnelle, pas un classement officiel de l’Union européenne.

Le premier chantier est clairement celui de la mesure d’audience. Mais l’intérêt de cette réforme ne se limite pas à une éventuelle réduction du nombre de bannières cookies. Elle remet sur la table une distinction technique que je considère fondamentale : mesurer un service n’est pas nécessairement suivre les individus qui l’utilisent.

1. Cookies et mesure d’audience : la réforme qui pourrait changer notre façon de faire de l’Analytics

C’est, à mon sens, le point le plus important de ce mandat pour les professionnels du marketing digital et les entreprises qui exploitent des sites web ou des applications.

Une exemption de consentement explicitement prévue pour certaines mesures d’audience

Le Conseil propose de modifier l’article 5, paragraphe 3, de la directive ePrivacy 2002/58/CE.

Le nouvel article prévoit plusieurs finalités pour lesquelles l’accès ou le stockage d’informations dans le terminal pourrait être autorisé sans consentement.

Data Marketing

Comment réussir son planning CMO 2027 ?

10/09/2026

Parmi elles figure la création d’informations agrégées anonymes destinées à mesurer l’audience du service.

Les conditions sont précises : la mesure doit être effectuée par le fournisseur du service, ou par un tiers agissant pour son compte. Les données collectées à cette fin ne doivent pas être réutilisées pour une autre finalité, partagées avec des tiers ni combinées avec des données provenant de tiers.

Référence : document 14756/26, article 5, point 2, proposition de nouvel article 5(3)(c) de la directive ePrivacy, pages 156-157. Les considérants 44d et 44e, pages 46-47, expliquent les objectifs de la mesure.

Pourquoi c’est important pour le Web Analytics

Aujourd’hui, il existe déjà en France une exemption de consentement pour certains outils de mesure d’audience. La CNIL l’encadre notamment dans sa doctrine relative à l’article 82 de la loi Informatique et Libertés.

Cette exemption est limitée à certaines finalités, notamment :

• La mesure de fréquentation d’un site ou d’une application.
• L’analyse des contenus consultés.
• La détection de problèmes de navigation.
• L’optimisation de l’ergonomie et des performances techniques.
• L’estimation des besoins en capacité des serveurs.

La mesure doit notamment être réalisée pour le compte exclusif de l’éditeur, et l’outil doit respecter les autres conditions définies par la CNIL. CNIL

La nouveauté européenne ne consiste donc pas à inventer le concept de mesure d’audience sans consentement. Il existe déjà.

Ce qui change potentiellement, c’est son inscription plus explicite dans le cadre européen, avec des conditions qui devront être articulées avec la réglementation française.

Le point décisif : les données ne doivent pas servir au suivi individuel

La formulation retenue par le Conseil est intéressante.

Elle autorise, sous conditions, la création d’informations agrégées anonymes sur l’utilisation d’un service. Elle ne constitue pas une autorisation générale de suivre individuellement chaque utilisateur.

Prenons un exemple concret, celui d’un site e-commerce.

Deux mesures très différentes

Audience agrégée

1 850 consultations d’une fiche produit, 320 clics sur le bouton d’ajout au panier, 24 erreurs techniques sur une journée.Des indicateurs globaux, sans analyse individualisée du parcours.

Suivi individuel

L’utilisateur X consulte un produit, revient trois jours plus tard, ajoute un article au panier puis achète après une publicité.Un parcours rattaché à un même utilisateur dans le temps.

Le premier cas peut correspondre à la finalité de mesure d’audience prévue par le projet, si l’ensemble de ses conditions est respecté.

Le second implique une mesure individuelle et éventuellement une exploitation publicitaire. Il ne bénéficie pas automatiquement de cette exemption.

C’est là que se situe une partie du travail de conception d’une architecture Analytics : séparer les traitements au lieu de les regrouper dans un même système en espérant qu’ils relèvent tous du même régime.

Quelles conséquences pour GA4, Matomo et Piano Analytics ?

Il faut éviter un raccourci : le projet ne déclare aucun outil Analytics conforme ou exempté de consentement.

Ce qui compte, ce n’est pas seulement le logiciel utilisé. C’est l’implémentation réelle : données collectées, finalités, identifiants, destinataires, conservation, rapprochement entre services et usages ultérieurs.

La CNIL demande déjà aux éditeurs de vérifier que les solutions utilisées remplissent effectivement ses critères et de disposer d’éléments permettant de le justifier. CNIL

Mon analyse est simple : une architecture de mesure strictement agrégée, correctement isolée du suivi marketing, mérite d’être étudiée. Mais ce serait une erreur de présenter cette réforme comme une autorisation de déclencher toutes les balises Analytics sans consentement.

Et le tracking server-side ?

Le passage d’un tracking côté navigateur à une architecture server-side ne modifie pas, à lui seul, la finalité ni la qualification juridique du traitement.

C’est particulièrement important pour Google Tag Manager Server-Side.

Un conteneur serveur peut recevoir des événements, les transformer puis les transmettre à plusieurs destinations. Mais un même événement peut parfaitement servir à des traitements différents :

• Mesurer le nombre total de pages consultées.
• Alimenter un reporting commercial.
• Reconstituer les parcours d’utilisateurs.
• Envoyer des événements de conversion à une plateforme publicitaire.

Ces finalités ne sont pas équivalentes.

Je recommande donc de raisonner en termes de flux de données et de finalités, plutôt qu’en termes de balises côté navigateur ou côté serveur.

Une architecture server-side permet d’appliquer des contrôles techniques sur les informations transmises. Elle ne transforme pas automatiquement un traitement soumis au consentement en traitement exempté.

2. Publicité contextuelle : de nouvelles possibilités de mesure sans profilage

Deuxième nouveauté particulièrement intéressante pour les annonceurs, les médias et les e-commerçants : la proposition d’exemption concernant certaines mesures de performance publicitaire.

Le nouvel article 5(3)(f) vise la mesure de l’affichage et de la performance des publicités fondées uniquement sur le contexte immédiat de consultation.

Ce contexte peut correspondre au contenu affiché sur une page web ou à une requête de recherche ponctuelle.

La proposition exige notamment que la mesure ne repose pas sur le profilage, ni sur l’activité passée ou future de l’utilisateur, y compris entre plusieurs sites ou services. Les données collectées doivent être pseudonymisées après collecte et ne pas être exploitées pour une autre finalité.

Référence : document 14756/26, article 5, point 2, nouvel article 5(3)(f), page 157 ; considérant 44g, page 48.

Exemple : mesurer une publicité liée au contenu d’une page

Imaginons un site spécialisé dans le jardinage.

Un internaute consulte un article consacré aux tondeuses électriques. Le site affiche une publicité pour une tondeuse en fonction du contenu de l’article, sans utiliser son historique de navigation.

Le site souhaite mesurer le nombre d’affichages et de clics.

Schéma de principe d’une mesure contextuelle correspondant à la finalité visée par la proposition, sous réserve des autres conditions.

Ce dispositif est différent d’une campagne de retargeting consistant à retrouver un utilisateur précédemment exposé à un produit.

Le premier repose sur le contenu. Le second repose sur le comportement antérieur d’une personne.

La proposition ne dispense donc pas automatiquement de consentement :

• Le remarketing publicitaire.
• Le suivi des conversions entre plusieurs sites.
• La constitution d’audiences comportementales.
• Le profilage multi-appareils.
• L’exploitation d’identifiants publicitaires pour des finalités distinctes.

Les impacts pour la mesure du ROAS et de l’attribution

Le ROAS, ou retour sur dépenses publicitaires, rapproche les revenus attribués aux campagnes de leur coût.

Certaines méthodes de calcul s’appuient sur la reconnaissance des utilisateurs, des identifiants publicitaires et des informations de conversion.

L’exemption envisagée pour la publicité contextuelle ne permet pas de conclure que l’ensemble de ces traitements deviendrait autorisé sans consentement.

On peut néanmoins envisager des dispositifs de reporting plus segmentés : d’un côté les performances agrégées de campagnes contextuelles, de l’autre les dispositifs d’attribution comportementale soumis à leurs propres conditions.

C’est une orientation technique intéressante, pas une promesse d’attribution publicitaire complète sans consentement.

3. CMP : le refus des cookies pourrait devoir être respecté pendant au moins quatre mois

Le Conseil propose également de limiter les demandes répétées de consentement.

Le texte prévoit que lorsqu’un utilisateur refuse une demande, le fournisseur ne doit pas solliciter un nouveau consentement pour la même finalité pendant une période d’au moins quatre mois.

Il prévoit aussi que le refus puisse être exprimé simplement, au moyen d’un bouton accessible en un clic ou d’un mécanisme équivalent.

Référence : document 14756/26, article 5, proposition de nouvel article 5(3), page 158.

Ce délai est important à vérifier : il s’agit bien de quatre mois dans la position du Conseil. La proposition initiale comportait une autre architecture juridique, et le mandat présente encore les suppressions et ajouts dans le texte de négociation.

Que faudra-t-il vérifier dans les CMP ?

Pour les entreprises qui utilisent Didomi, OneTrust, Axeptio, Cookiebot ou une CMP développée en interne, plusieurs points techniques seront à examiner si ces dispositions sont adoptées.

Il ne faut pas non plus confondre la durée pendant laquelle une préférence doit être respectée avec la durée pendant laquelle un cookie peut être conservé.

Le principe de limitation de la conservation reste pertinent et doit être apprécié au regard de la réglementation applicable.

Le projet pourrait-il obliger les entreprises à remplacer leur CMP ?

Non. Le texte ne désigne ni n’impose une nouvelle plateforme de gestion du consentement.

Il modifierait certaines obligations que ces plateformes doivent permettre aux sites de respecter. La nécessité d’un remplacement dépendrait des capacités de chaque solution et de sa mise à jour.

4. Navigateurs et consentement automatisé : vers des choix transmis directement aux sites ?

C’est une autre évolution à suivre pour les développeurs et spécialistes du tag management.

Le projet envisage que les choix des internautes puissent être exprimés au moyen de signaux automatisés et lisibles par machine, notamment via des mécanismes intégrés aux navigateurs.

L’objectif est qu’un utilisateur n’ait pas nécessairement à répéter une décision sur chaque interface de consentement.

Le texte du Conseil traite cependant cette question dans une disposition distincte du RGPD initialement envisagée par la Commission : le mandat maintient les règles relatives aux terminaux au sein de la directive ePrivacy.

Références : document 14756/26, considérant 46, page 50 ; article 5, pages 156-158. Les passages relatifs aux nouveaux articles 88a et 88b du RGPD, pages 143-145, doivent être lus avec les marques de suppression du mandat.

Les conséquences techniques pour Google Tag Manager

Pour une implémentation GTM, le sujet est la provenance et l’exploitation des préférences.

Aujourd’hui, une CMP peut communiquer aux balises Google les choix des utilisateurs, notamment à travers Consent Mode.

Dans un environnement intégrant demain des signaux normalisés émis par les navigateurs, il faudrait examiner leur prise en charge par les CMP et leur traduction dans les différents systèmes de tracking.

Ce que j’attendrais d’une architecture robuste :

1. Une source de préférence clairement identifiée.
2. Une gestion cohérente des finalités et des choix.
3. Une communication fiable de l’état du consentement avant l’exécution des traitements concernés.
4. Une prise en compte des modifications ou retraits de consentement.
5. Des tests permettant de vérifier le comportement réel des balises, et pas seulement l’affichage d’une bannière.

Il serait toutefois prématuré d’affirmer que le mandat impose dès maintenant un protocole particulier, ou que Google Consent Mode devra être remplacé.

Les spécifications techniques, l’adoption finale et les modalités de transposition restent déterminantes.

5. Données pseudonymisées : une clarification importante pour les architectures Data

Au-delà des cookies, le Digital Omnibus touche à une question essentielle pour les entreprises qui centralisent leurs données dans BigQuery, Snowflake, PostgreSQL ou d’autres entrepôts de données.

Quand une donnée pseudonymisée reste-t-elle une donnée personnelle ?

La question est moins simple qu’il n’y paraît.

La définition des données personnelles n’est pas supprimée

Le Conseil précise explicitement qu’il souhaite conserver la définition actuelle des données personnelles et introduire une disposition supplémentaire consacrée à la pseudonymisation et à l’identification d’une personne.

C’est une différence importante par rapport à une lecture trop générale de la réforme.

Une donnée pseudonymisée n’est pas automatiquement une donnée anonyme. La possibilité d’identifier une personne dépend notamment des moyens raisonnablement susceptibles d’être utilisés pour y parvenir, du contexte du traitement, des informations disponibles et des protections techniques ou juridiques.

Le considérant 27b indique que les capacités de réidentification peuvent différer selon les acteurs qui disposent des données.

Le projet maintient expressément la qualification de données personnelles pour un sous-traitant traitant des données pour le compte d’un responsable de traitement lorsque celui-ci peut identifier la personne.

Références : document 14756/26, considérants 27 à 27c, pages 24-27 ; proposition d’article 25a du RGPD, pages 139-141. Le Conseil confirme le maintien de la définition actuelle dans son communiqué du 21 octobre 2026.

Exemple : des identifiants clients dans BigQuery

Une entreprise exploite les données de son application métier. Son entrepôt contient les commandes, les montants, les dates d’achat et un identifiant client pseudonymisé.

L’équipe Data doit produire des analyses commerciales sans accéder aux noms ni aux adresses des clients.

Deux scénarios sont possibles.

Scénario A — Le destinataire possède une clé de correspondance

Il peut relier l’identifiant pseudonymisé à un client identifiable. Les données restent personnelles pour cet acteur.

Scénario B — Un tiers reçoit un jeu de données protégé

Il ne possède pas la clé, ne peut pas raisonnablement l’obtenir et les mesures empêchant la réidentification sont effectives. La qualification des données peut être différente pour ce destinataire, selon les circonstances.

Le second scénario ne devient pas automatiquement hors RGPD au seul motif que la clé n’est pas transmise. Les propriétés du jeu de données lui-même, les informations auxiliaires disponibles et les relations contractuelles comptent également.

Pourquoi cette clarification intéresse les Data Engineers

Dans les projets Data, on cherche régulièrement à réduire la circulation des données directement identifiantes.

Cela passe notamment par la séparation des identifiants, la limitation des permissions, le contrôle des exports ou l’utilisation de statistiques agrégées.

Ces pratiques conservent leur intérêt, quelle que soit l’issue de la réforme.

En revanche, le projet pourrait apporter davantage de précisions sur les circonstances dans lesquelles un destinataire ne dispose pas de moyens raisonnables de réidentifier une personne.

Le Conseil prévoit également un avis du Comité européen de la protection des données (CEPD/EDPB) consacré à la pseudonymisation et à l’anonymisation.

Je vois ici une raison supplémentaire de documenter les architectures Data avec précision : qui reçoit quelles données, peut accéder à quelles informations complémentaires et dispose de quels moyens de réidentification ?

C’est plus utile qu’une déclaration générique indiquant que les données sont « anonymisées » alors qu’elles sont simplement associées à un identifiant différent.

6. Intelligence artificielle : l’intérêt légitime est clarifié, pas transformé en autorisation générale

La proposition aborde directement les traitements de données personnelles nécessaires au développement et au fonctionnement des systèmes et modèles d’intelligence artificielle.

C’est un sujet central pour les entreprises qui développent des agents IA, connectent des LLM à leurs données métier ou automatisent des processus internes.

Ce que prévoit réellement le Conseil

Le nouveau dispositif envisagé rappelle que l’intérêt légitime prévu par l’article 6(1)(f) du RGPD peut, selon les circonstances, constituer une base légale pour traiter des données personnelles dans le cadre du développement ou de l’exploitation d’un système ou modèle d’IA.

Mais le texte ajoute une précision essentielle : le développement ou l’exploitation de l’IA ne constitue pas, en soi, un intérêt légitime.

L’analyse doit porter sur la finalité réelle du traitement, sa nécessité et les droits des personnes concernées.

Le traitement reste soumis aux autres exigences du RGPD. Le projet prévoit également des mesures organisationnelles et techniques adaptées, notamment en matière de minimisation et de protection des droits des personnes.

Références : document 14756/26, considérants 30, 31 et 33a, pages 29-32 ; proposition d’article 88c, pages 145-146.

Exemple : un agent IA connecté à un CRM

Prenons une entreprise qui développe un agent IA chargé d’aider ses commerciaux.

L’agent consulte les fiches clients et les opportunités commerciales, prépare des synthèses et propose des actions de suivi.

Trois situations doivent être distinguées.

Le Digital Omnibus n’apporte pas une réponse positive automatique à ces trois questions.

Une entreprise ne peut pas simplement déclarer « nous utilisons l’intérêt légitime pour l’IA » et considérer que les conditions du RGPD sont remplies.

Les catégories particulières de données : une dérogation très encadrée

Le mandat traite aussi de la présence accidentelle de données sensibles dans les jeux de données utilisés pour développer ou exploiter des systèmes d’IA.

Il envisage une dérogation limitée pour les données de catégories particulières présentes de manière incidente et résiduelle.

Le texte exige notamment que des mesures soient prises pour éviter leur traitement et pour les effacer lorsqu’elles sont identifiées. Lorsque l’effacement s’avère techniquement impossible ou manifestement disproportionné, des mesures de protection doivent empêcher leur réutilisation, leur divulgation ou leur exploitation.

Ce mécanisme ne couvre pas une collecte délibérée de données sensibles nécessaires à la finalité du traitement.

Référence : document 14756/26, considérant 33, pages 31-32 et dispositions relatives à l’article 9 du RGPD.

Pour un projet RAG — Retrieval-Augmented Generation, c’est-à-dire un système où un modèle consulte des documents ou des bases de données avant de répondre — la conséquence est concrète.

Il faut maîtriser les données accessibles au moteur de recherche, les informations envoyées au LLM, les journaux techniques et les possibilités de restitution d’informations sensibles.

Les autorités européennes restent vigilantes

Dans leur avis conjoint du 10 février 2026 sur le Digital Omnibus, le CEPD et le Contrôleur européen de la protection des données reconnaissent l’objectif de simplification, tout en soulevant des réserves sur plusieurs modifications.

Ils demandent notamment que les adaptations du RGPD ne conduisent pas à affaiblir les garanties existantes. European Data Protection Supervisor+1

Cette réaction doit être prise en compte. Un texte destiné à encourager l’innovation ne supprime pas pour autant les exigences relatives à la licéité, à la nécessité, à la proportionnalité et à la protection des personnes.

Attention à ne pas confondre les deux volets du Digital Omnibus

Le paquet Digital Omnibus comporte deux propositions législatives distinctes.

Le volet consacré à la simplification de la mise en œuvre de l’AI Act a déjà fait l’objet d’un règlement adopté, référencé (UE) 2026/1744, entré en vigueur le 27 juillet 2026 selon la Commission.

Le document 14756/26 étudié ici concerne l’autre volet : la simplification du cadre législatif numérique, comprenant notamment le RGPD, ePrivacy, le Data Act et les obligations de notification des incidents. Il reste en procédure législative.

Ces deux textes doivent être distingués, même s’ils participent à la même politique de simplification. European Commission

7. Cybersécurité : quatre jours pour notifier certaines violations de données

Autre évolution concrète pour les entreprises et les prestataires qui hébergent des applications, gèrent des données clients ou exploitent des infrastructures cloud.

Le Conseil soutient une modification de l’article 33 du RGPD concernant la notification des violations de données personnelles.

Deux changements sont particulièrement importants.

Un nouveau seuil de notification

Dans le texte actuellement applicable, une violation de données personnelles doit être notifiée à l’autorité compétente sauf si elle n’est pas susceptible d’engendrer un risque pour les droits et libertés des personnes physiques.

Le projet propose de réserver cette notification obligatoire aux violations susceptibles d’engendrer un risque élevé.

Il prévoit aussi que l’incident reste documenté, même lorsqu’il n’atteint pas le seuil de notification.

Un délai maximal envisagé de 96 heures

Le texte propose également un délai de 96 heures, lorsque cela est possible, après la prise de connaissance de la violation, au lieu de 72 heures dans le RGPD actuel.

Références : RGPD, article 33 ; document 14756/26, considérant 39, pages 40-41 ; proposition de modification de l’article 33, pages 137-138.

Conséquence pour mes projets applicatifs

Prenons une application métier qui exploite Supabase ou PostgreSQL et utilise n8n pour automatiser certains traitements.

Une mauvaise configuration des permissions peut exposer des données. Un workflow n8n peut également transmettre des informations au mauvais destinataire.

Dans les deux cas, les procédures doivent permettre de déterminer rapidement ce qui s’est passé, quelles données sont concernées, qui a pu y accéder et quelles conséquences sont possibles.

Même si la notification devenait obligatoire dans moins de situations, il resterait nécessaire de détecter, qualifier et documenter les incidents.

Le projet ne justifie donc pas une réduction des moyens de surveillance ou de journalisation.

Un point d’entrée national pour plusieurs obligations de notification

La proposition initiale prévoyait un point d’entrée unique au niveau européen.

Le Conseil privilégie désormais la création d’un point d’entrée national dans chaque État membre, avec un dispositif européen d’information destiné à orienter les organisations.

L’objectif est de faciliter la notification d’incidents relevant de différents textes, notamment le RGPD, NIS2, DORA et d’autres instruments sectoriels.

Cela ne signifie pas que toutes les obligations de notification deviennent identiques.

Les conditions, les destinataires et les délais propres à chaque dispositif doivent toujours être pris en compte.

Références : document 14756/26, considérants 49 à 57, pages 52-57 ; communiqué du Conseil du 21 octobre 2026. Consilium

8. Data Act : quelles conséquences pour les projets cloud, les API et les plateformes de données ?

La réforme ne se limite pas au RGPD.

Une partie importante du texte concerne le Data Act, le règlement européen 2023/2854 sur l’accès équitable aux données et leur utilisation.

Le Conseil propose notamment d’y regrouper des règles aujourd’hui réparties entre plusieurs instruments législatifs.

Les textes concernés comprennent notamment le Data Governance Act, la directive relative aux données ouvertes et le règlement sur la libre circulation des données non personnelles.

Simplifier la réutilisation des données publiques

Pour les entreprises qui développent des applications exploitant des données publiques, la consolidation des règles pourrait faciliter la compréhension des régimes applicables.

Le mandat distingue toujours les données ouvertes de certaines catégories de données protégées.

Il précise que les États membres peuvent organiser la réutilisation de données protégées, mais que toutes les données détenues par un organisme public ne deviennent pas automatiquement réutilisables.

Références : document 14756/26, considérants 21 à 26, pages 15-22 ; proposition de chapitre VIIc du Data Act.

Pour un Data Engineer, les questions restent donc opérationnelles : quelles données sont effectivement disponibles, sous quelle licence, à quelle fréquence, avec quelles restrictions et selon quelles modalités techniques ?

Services cloud et réversibilité

Le Conseil apporte aussi des précisions concernant certaines catégories de services de traitement de données personnalisés et les contrats conclus avant ou au 12 septembre 2025.

Il envisage des régimes particuliers pour certains services autres que l’IaaS, notamment lorsque leurs fonctionnalités ont été largement adaptées aux besoins d’un client.

Le projet permet également certaines pénalités proportionnées de résiliation anticipée pour les contrats à durée déterminée, à condition de ne pas constituer un obstacle au changement de fournisseur.

Les obligations relatives aux frais de changement et de sortie des données ne sont pas pour autant abandonnées.

Références : document 14756/26, considérants 17-18, pages 12-13 ; proposition de modification de l’article 31 du Data Act, pages 79-80.

Pour les projets qui utilisent plusieurs fournisseurs cloud ou des services de données managés, la bonne pratique reste de maîtriser les possibilités d’export et de migration.

Le texte ne dispense pas d’examiner les conditions contractuelles spécifiques des services réellement utilisés.

Secrets d’affaires et transferts de données

Le mandat renforce également les possibilités de refuser certaines communications de données lorsque des secrets d’affaires risquent d’être illicitement obtenus, utilisés ou divulgués dans des juridictions qui ne procurent pas une protection équivalente.

Ces refus doivent être fondés sur des circonstances précises et justifiés. Ils ne constituent pas une possibilité de bloquer systématiquement tout partage de données avec un pays tiers.

Références : document 14756/26, considérants 10 à 14a, pages 7-9 ; propositions de modification des articles 4 et 5 du Data Act, pages 69-71.

Pour les entreprises qui utilisent des fournisseurs externes, des API ou des prestataires implantés hors de l’Union européenne, ce sujet renforce l’intérêt d’une cartographie précise des flux de données et des engagements contractuels.

9. Web performance : la mesure technique pourrait bénéficier d’un cadre plus clair

La performance web mérite une attention particulière, même si le Digital Omnibus ne propose pas de modification directe des Core Web Vitals.

Les indicateurs LCP (Largest Contentful Paint), INP (Interaction to Next Paint) et CLS (Cumulative Layout Shift) servent à évaluer différents aspects de l’expérience utilisateur.

Le sujet réglementaire concerne la manière dont on collecte ces données et les finalités pour lesquelles elles sont exploitées.

La CNIL inclut déjà l’optimisation des performances techniques et la détection des problèmes de navigation parmi les finalités susceptibles de relever de son exemption de mesure d’audience, lorsque les conditions sont réunies. CNIL

Avec le Digital Omnibus, une entreprise pourrait disposer d’un cadre européen plus explicite pour certaines mesures agrégées de l’utilisation et des performances de son service.

Exemple : un dispositif de Real User Monitoring

Un dispositif de RUM (Real User Monitoring) collecte des mesures techniques issues des visites réelles pour comprendre le comportement d’un site.

Il peut notamment enregistrer la valeur du LCP, le type d’appareil ou la page concernée.

Mais certains outils de RUM collectent également des identifiants de session, des événements de navigation détaillés ou des informations permettant de suivre une personne.

L’analyse de conformité dépend donc de la nature exacte des données et de l’ensemble de leurs utilisations.

Je retiens surtout une orientation : la collecte de métriques techniques nécessaires à l’amélioration du service peut être conçue indépendamment des mécanismes de suivi marketing.

Cela ne garantit pas qu’un outil de RUM donné puisse être activé sans consentement. La conformité dépend de son fonctionnement réel.

10. Ce que je recommande aux entreprises dès maintenant

Le texte n’est pas définitif. Je ne recommande donc pas de modifier immédiatement les configurations de consentement sur la seule base de ce mandat.

En revanche, plusieurs travaux sont utiles dès aujourd’hui. Ils améliorent la qualité des implémentations et faciliteront leur adaptation si la réforme est adoptée.

Ne pas confondre adaptation réglementaire et optimisation du tracking

Une nouvelle exemption de consentement ne signifie pas automatiquement une meilleure qualité des données.

La qualité d’une mesure dépend aussi de l’exactitude du plan de collecte, du comportement des outils, de la déduplication, de la gestion des identifiants et des traitements effectués ensuite.

Un événement collecté sans consentement, lorsqu’une exemption s’applique, peut parfaitement être mal configuré.

Une architecture conforme peut également produire des indicateurs incorrects.

C’est précisément la raison pour laquelle je distingue les audits de conformité, les audits de qualité Analytics et les audits de performance technique.

Ces sujets se recoupent, mais ne répondent pas aux mêmes questions.

11. À quelle date ces changements pourraient-ils s’appliquer ?

Le mandat adopté par le Conseil constitue une étape du processus législatif.

Le Parlement européen doit arrêter sa position et les institutions doivent parvenir à un accord sur le texte définitif.

Ce n’est qu’après l’adoption et la publication du règlement que ses dispositions entreront en vigueur, éventuellement avec des calendriers d’application différents.

Le projet comporte déjà des dispositions transitoires, mais elles ne doivent pas être assimilées à des dates d’application définitivement acquises.

1. 19 novembre 2025 — Proposition de la CommissionPublication du projet Digital Omnibus, procédure 2025/0360 (COD).
2. 10 février 2026 — Avis conjoint des autorités de protection des donnéesLe CEPD et le Contrôleur européen de la protection des données présentent leurs observations sur le projet.
3. 21 octobre 2026 — Mandat du ConseilLes représentants des États membres arrêtent leur position de négociation. Le texte est transmis le 22 octobre.
4. Prochaine étape — Négociations avec le Parlement européenLe calendrier de finalisation et le contenu des dispositions restent à confirmer.

Sources : Commission européenne, Conseil de l’Union européenne et CEPD. publications.europa.eu+2

12. Les points qui restent incertains

Malgré ses 179 pages, le document ne permet pas de répondre définitivement à toutes les questions opérationnelles.

Je surveillerais particulièrement les éléments suivants :

• Le périmètre exact de l’exemption de mesure d’audience, notamment les modalités de collecte temporaire des données avant agrégation.
• L’articulation avec la doctrine de la CNIL, qui encadre déjà les solutions de mesure d’audience exemptées de consentement.
• La standardisation des choix automatisés, pour déterminer comment navigateurs, CMP et fournisseurs de balises pourront communiquer.
• Les critères techniques de pseudonymisation, afin de mieux apprécier la capacité de réidentification des différents destinataires.
• Les conditions du recours à l’intérêt légitime pour l’IA, ainsi que les garanties devant accompagner les traitements.
• Les modalités nationales de notification des incidents, dont les infrastructures et procédures devront être précisées.

La première erreur serait de considérer ces points comme définitivement résolus.

La seconde serait d’attendre l’adoption finale pour commencer à comprendre les traitements déjà réalisés dans son système d’information.

13. Mon analyse : la vraie opportunité se situe dans l’architecture des données

Ce qui me paraît intéressant dans ce Digital Omnibus, au-delà de la simplification administrative annoncée, c’est la nécessité de mieux distinguer les usages des données.

Dans beaucoup de projets, on centralise les données dans une même infrastructure, puis on multiplie les traitements : reporting, analyse marketing, personnalisation, automatisations, intelligence artificielle.

Cette approche peut être techniquement efficace. Mais elle rend plus complexe l’identification des finalités et des obligations qui s’appliquent à chacune.

La réforme renforce, à mon sens, l’intérêt d’une architecture où les flux sont explicitement documentés et contrôlés.

Un système de mesure d’audience n’a pas nécessairement besoin de connaître l’identité d’un visiteur. Un tableau de bord commercial n’a pas nécessairement besoin d’accéder à l’ensemble des informations d’un CRM. Un agent IA n’a pas nécessairement besoin de recevoir toutes les données présentes dans une application.

Ce ne sont pas des nouveautés réglementaires. Ce sont des principes de conception qui prennent encore plus de valeur dans un environnement juridique en évolution.

Pour mes clients, j’identifie trois bénéfices potentiels : disposer de mesures adaptées à leurs besoins réels, limiter la circulation inutile de données et conserver une meilleure maîtrise de leurs outils.

Le Digital Omnibus ne dispense pas les entreprises de cette discipline technique. Il pourrait rendre certaines architectures plus intéressantes, mais seulement lorsque les conditions légales seront effectivement réunies.

Références officielles

Les documents ci-dessous permettent de retrouver les textes et de vérifier les principaux changements présentés dans cet article.

Single market: Member states scale back ambitions set out in the integration roadmap • Table.Briefings

Conseil de l’Union européenne — Mandat du 22 octobre 2026

Document 14756/26, procédure 2025/0360 (COD), 179 pages. Source principale de cette analyse.Communiqué officiel et accès au mandat

BELGIUM-EU-POLITICS-DIGITAL

Commission européenne — Proposition initiale

COM(2025) 837 final, 19 novembre 2025. Permet de comparer le mandat du Conseil avec la version proposée par la Commission.Consulter la proposition

Guidelines 07/2020 on the concepts of controller and processor in the GDPR – Formiventos

CEPD et Contrôleur européen de la protection des données

Avis conjoint du 10 février 2026 sur le Digital Omnibus : analyse des effets possibles sur les droits et garanties.Lire l’avis conjoint

CNIL – Atelier RGPD | Les Bases du numérique d’intérêt général

CNIL — Cookies et mesure d’audience

Doctrine française relative aux solutions de mesure d’audience pouvant bénéficier d’une exemption de consentement, publiée le 4 juillet 2025.Consulter les critères de la CNIL

Le mandat du 21 octobre 2026 marque une évolution importante dans la manière dont l’Union européenne envisage la réglementation numérique. L’idée n’est pas de supprimer toute protection, mais de clarifier certaines obligations, de réduire les démarches répétitives et de mieux définir les conditions d’utilisation des données.

Pour le Web Analytics, la question centrale reste celle de la distinction entre mesure agrégée et suivi individuel. Pour la Data et l’IA, elle concerne la maîtrise des données, de leurs destinataires et de leurs finalités.

Mon conseil est de ne pas attendre une nouvelle réglementation pour concevoir des systèmes plus lisibles, contrôlables et documentés. Les entreprises qui connaissent précisément leurs flux de données seront les mieux placées pour évaluer les changements et adapter leurs implémentations lorsque le texte définitif sera publié.

Franck Scandolera

Dev d’applications métier · Data Engineer · Automatisation IA

Clients : Logis Hôtels, Yelloh Village, BazarChic, FFF, Texdecor…

• Apps & agents IA : Node.js, Python, API, RAG, OpenAI, Mistral, Claude
• Data & Analytics Engineering : GCP, BigQuery, Snowflake, PostgreSQL, ClickHouse, dbt, Airflow, Dataform, Looker, Power BI, Metabase
• Automatisation IA : n8n, Apps Script, scraping, API, LLM
• Tracking & perf Web : GA4, GTM server, Matomo, Piano, Tealium, CAPI, Core Web Vitals