OpenX

Qu'est-ce qu'OpenX ?

OpenX est une Supply Side Platform (SSP) et un ad exchange exploités par OpenX Software Ltd., siège à Pasadena, Californie. Fondée en 2008 et l'une des plus grandes SSP indépendantes mondiales, OpenX exécute des enchères temps réel côté serveur pour exposer l'inventaire publicitaire des éditeurs aux DSP, trading desks d'agences et ad networks. Les éditeurs intègrent OpenX via les wrappers header bidding Prebid.js, le tag RTB OpenX ou le header bidding server side (Prebid Server). OpenX est vendeur IAB Europe TCF v2.2 (ID 69).

Quelles données OpenX traite-t-il ?

Pour chaque ad request, OpenX reçoit l'IP du visiteur, le user agent, l'URL de page, le referrer, le type d'appareil, le viewport, le fuseau horaire, la langue, la chaîne IAB TCF v2.2 et tous les user IDs propagés par l'éditeur (Unified ID 2.0, ID5, LiveRamp ATS, etc.). OpenX dépose les cookies i (OpenX visitor ID, durée 1 an), mt_mop (capping multi touch), OX_u (segments audience graph) et OX_sd (mapping sous domaines) sur openx.net et op-mobile-ads.com. Le payload complet de la bid request est diffusé à des dizaines de DSP simultanément, élargissant considérablement l'audience des données personnelles.

Implications RGPD et ePrivacy

Parce qu'OpenX dépose des cookies persistants et traite des données pour la publicité, l'art. 5(3) ePrivacy exige un consentement préalable et éclairé avant l'exécution du tag. Au titre du RGPD, le consentement de l'art. 6(1)(a) est la base appropriée. Les éditeurs doivent s'appuyer sur une CMP TCF v2.2 qui gate le vendeur 69 derrière les finalités accordées, et configurer le workflow de bidding pour qu'aucune bid request ne parte avant consentement. La décision de l'APD belge sur IAB Europe TCF s'applique à OpenX par extension.

Identity graph cross site

OpenX maintient un graphe d'audience qui lie l'OpenX cookie ID à des identifiants DSP et DMP tiers, permettant retargeting cross site et extension d'audience. Le graphe est traité principalement sur infrastructure US. Les éditeurs UE doivent traiter cela comme un traitement à haut risque, avec le mécanisme de transfert adéquat (DPF ou CCT) et une analyse d'impact des transferts au regard de Schrems II. Les alternatives cookieless comme Google Topics API et le ciblage purement contextuel gagnent du terrain mais ne sont pas le défaut chez OpenX.

Choix d'architecture header bidding

Le header bidding client side via Prebid.js charge les tags OpenX directement dans le navigateur. Le header bidding server side via Prebid Server déplace la logique de bid au backend de l'opérateur, réduisant la dépendance aux cookies client mais sans éliminer le partage de données personnelles avec OpenX (IP, contexte de page, identifiants). Les deux modes exigent un consentement. Les opérateurs choisissent le mode qui équilibre revenu, latence et risque privacy.

Mise en pratique

Configurer la CMP éditeur pour qu'OpenX (TCF vendeur 69) ne se déclenche qu'avec les finalités accordées. Signer le DPA et les CCT OpenX. Réaliser une analyse d'impact des transferts traitant l'exposition au CLOUD Act US et au FISA 702. Inscrire OpenX au registre des traitements, avec cookies, données de bid request, base légale et mécanisme de transfert. Lister les cookies OpenX dans la politique cookies sous marketing/publicité. Utiliser le server side header bidding si l'architecture le permet, et réduire progressivement la dépendance aux identifiants user au profit de signaux contextuels.