AdTech
Programmatique pour un réseau d'écrans d'affichage numérique hors domicile : vendre via un SSP DOOH, opter pour une solution en marque blanche ou construire votre propre plateforme
Ce qui change quand un réseau d'écrans d'affichage numérique hors domicile vend ses écrans en programmatique, et comment choisir entre un SSP DOOH, une solution en marque blanche et votre propre plateforme.
Par amBrainLecture 10 min
Dans cet article
La vente programmatique signifie qu'un logiciel vend votre espace publicitaire. Chaque fois qu'un créneau se libère, les systèmes d'achat des annonceurs font des offres pour l'obtenir dans une enchère automatique. Un réseau d'affichage numérique hors domicile (DOOH) dispose d'écrans dans des lieux comme les centres commerciaux, les gares, les salles de sport et les bureaux. Il peut les vendre en programmatique via une supply-side platform (SSP) DOOH, qui propose aux acheteurs les écrans de nombreux réseaux. Il peut aussi exploiter le logiciel d'un fournisseur sous sa propre marque (une solution en marque blanche) ou construire sa propre plateforme. Le choix dépend de la part de la vente que vous voulez maîtriser et de qui fera tourner la technologie au quotidien.
La réponse courte : si vous voulez des revenus programmatiques rapidement et n'avez pas d'ingénieurs disponibles, vendez via un ou deux SSP DOOH. Optez pour une solution en marque blanche quand les agences doivent acheter auprès de votre marque, mais que vous ne voulez ni écrire ni exploiter le code. Construisez votre propre plateforme quand elle fait partie de ce que vous vendez, ou quand les frais coûtent plus cher que ne le ferait une équipe. Sur chaque voie, les données des écrans, les chiffres d'audience, les règles de validation et les relevés de diffusion restent du ressort de votre équipe.
Qu'est-ce qui change quand un réseau d'écrans vend en programmatique ?
Certains acheteurs se mettent à enchérir sur des diffusions à l'unité via un logiciel, au lieu de réserver des campagnes auprès de votre équipe commerciale. Dans une vente directe, cette équipe convient avec un annonceur des dates, des écrans et d'un prix. Quelqu'un charge ensuite les publicités dans votre système de gestion de contenu (CMS), le logiciel qui décide ce que chaque écran diffuse et à quel moment.
Les offres programmatiques viennent d'une demand-side platform (DSP), le système qu'utilisent les annonceurs et les agences pour acheter de la publicité. Les systèmes des acheteurs et des vendeurs échangent généralement ces offres en OpenRTB, un format de message commun. L'IAB Tech Lab, qui rédige des normes techniques pour la publicité numérique, en assure la maintenance et a ajouté la prise en charge des écrans à OpenRTB 2.6 en novembre 2022.
Cet article s'appuie sur cette spécification et sur les notes d'implémentation que l'IAB Tech Lab lui consacre. Il utilise aussi la taxonomie des lieux OpenOOH, une liste partagée de types de lieux, et les normes du Media Rating Council (MRC) pour la mesure hors domicile. Toutes les sources ont été consultées le 4 novembre 2026.
Commencez par votre CMS ou votre player, l'appareil ou le logiciel qui fait fonctionner chaque écran. Une boucle est une séquence de contenus et de publicités d'une durée fixe, diffusée en continu. Si vos écrans diffusent une boucle, certains de ses créneaux doivent rester ouverts au programmatique. Le player doit aller chercher des publicités pour ces créneaux et signaler ce qui a été diffusé. Quand aucune publicité n'arrive, il lui faut autre chose à afficher.
L'enchère peut avoir lieu bien avant la diffusion. Les notes de l'IAB Tech Lab expliquent que la plupart des écrans se connectent via les réseaux mobiles, qui peuvent subir des coupures aux heures de pointe. Certains réseaux d'écrans vont donc chercher les publicités à l'avance. Les notes indiquent : « Le délai actuellement admis par le secteur entre la “confirmation de l'offre” et l'“affichage” peut aller jusqu'à 1 à 2 heures. »
Comment une seule diffusion sur un écran devient-elle plusieurs impressions ?
Chaque bid request, le message qui invite les DSP à enchérir, indique combien d'impressions vaut la diffusion. Sur un site web, une impression correspond à une publicité montrée à une personne. Selon les notes de l'IAB Tech Lab, une diffusion sur un écran est « visible par toutes les personnes qui se trouvent à proximité de la publicité affichée ».
Ce chiffre est le multiplicateur d'impressions, c'est-à-dire l'audience comptée pour chaque diffusion. OpenRTB 2.6 le définit comme « la quantité d'événements facturables qui seront réputés avoir eu lieu si cet élément est acheté. » En termes simples, c'est ce que l'acheteur paie.
Le multiplicateur peut être inférieur à un, comme il pourrait l'être sur un écran peu fréquenté la nuit. Les notes indiquent que « les valeurs fractionnaires (par exemple 0,32 impression par affichage publicitaire) sont courantes ». Elles ajoutent que ce chiffre peut changer d'heure en heure ou provenir de « données de capteurs en temps réel ».
Les prix restent exprimés en CPM, le prix pour mille impressions. Les notes donnent un exemple chiffré, et non un prix de marché : si une offre à un CPM de 2,50 $ remporte une diffusion qui vaut 30,3 impressions, la facture s'élève à 0,07575 $. Elles préviennent aussi que multiplier par des décimales « peut entraîner des écarts lorsque le “côté achat” et le “côté vente” tronquent les décimales. » Convenez de l'arrondi avec chaque SSP et chaque acheteur avant la première campagne.
D'où vient le chiffre d'audience ?
La bid request peut aussi indiquer qui a fourni ce chiffre. La spécification AdCOM de l'IAB Tech Lab désigne trois sources : un prestataire de mesure, l'éditeur (vous) ou l'exchange (le SSP).
Les acheteurs demanderont ce que mesure ce chiffre. Le MRC est un organisme professionnel américain qui audite et accrédite la mesure des médias. Ses normes de mesure hors domicile, dont la version finale date de décembre 2025, définissent une échelle qui va du trafic d'un lieu jusqu'à l'audience susceptible d'avoir vu la publicité. Chaque échelon ajoute des conditions, et les normes notent que « les impressions brutes reflètent l'estimation d'audience potentielle la plus élevée ».
Comment prouver qu'une publicité a été diffusée ?
La preuve de diffusion est un log du player de l'écran qui indique quelle publicité a été diffusée, sur quel écran et à quel moment. Les normes du MRC précisent : « Il doit exister des preuves solides de diffusion (proof-of-play, PoP) pour étayer la déclaration d'impressions brutes ou d'estimations d'audience ».
Pour les écrans numériques, les normes acceptent une technologie qui enregistre l'activité du player, à condition qu'elle soit testée avant le lancement et « surveillée périodiquement ». Elles couvrent aussi la preuve, apportée par le vendeur, qu'une publicité a été diffusée, comme les logs de diffusion. Son contenu, précisent-elles, « devrait être convenu entre l'acheteur et le vendeur avant le lancement de la campagne publicitaire ».
OpenRTB prévoit une notification de facturation, le message qui indique à l'acheteur qu'une impression peut être facturée. La notification de gain, un message distinct, indique seulement qu'une offre a gagné. Les notes de l'IAB Tech Lab recommandent vivement de séparer les deux et d'envoyer la notification de facturation lorsque « la création s'est affichée à l'écran et que les impression[s] sont facturables ». La création, c'est le fichier publicitaire lui-même.
Quelles sont les trois façons de vendre nos écrans en programmatique ?
- Vendre via un SSP DOOH. Vous connectez votre CMS ou vos players au SSP et y chargez vos écrans et vos chiffres d'audience. Le SSP les propose aux DSP avec lesquels il travaille, organise l'enchère et vous reverse ce qui reste après déduction de ses frais.
- Opter pour une solution en marque blanche. Un fournisseur vous concède sous licence son ad server et le logiciel qui vend aux DSP. L'ad server est le système qui choisit quelle publicité est diffusée et la comptabilise. La plateforme porte votre marque, et le fournisseur maintient le code.
- Construire votre propre plateforme. Votre équipe, ou une société que vous engagez, construit l'ad server, la liaison avec les DSP et les rapports. Le code et chacune de ses règles vous appartiennent, et c'est vous qui l'exploitez.
Vous pouvez combiner les voies : par exemple, exploiter votre propre ad server pour les campagnes directes et vendre les diffusions invendues via des SSP.
Quand vendre via un SSP DOOH suffit-il ?
Passez par un SSP quand la plupart de ces conditions sont réunies :
- Vous voulez savoir si les acheteurs programmatiques paieront pour vos écrans avant d'investir dans la technologie
- Votre CMS ou vos players fonctionnent déjà avec le SSP, ou le SSP vous aidera à les connecter
- Le programmatique remplira les créneaux que votre équipe commerciale ne vend pas
- Vous n'avez pas d'ingénieurs pour exploiter une plateforme publicitaire jour et nuit
La difficulté, c'est le contrôle. Les acheteurs trouvent vos écrans sur la marketplace du SSP, à côté de ceux d'autres réseaux, et les prix et les accords fonctionnent comme son logiciel le permet.
Quand une solution en marque blanche est-elle pertinente ?
Optez pour cette solution quand :
- Les agences doivent acheter auprès de votre marque et de votre équipe commerciale, et non sur une marketplace
- Vous voulez vos propres règles pour les prix, les accords et les publicités autorisées dans chaque lieu
- Vous pouvez constituer une équipe pour gérer des campagnes, mais pas une équipe qui écrit et exploite un logiciel publicitaire
Le code est loué. Les nouvelles fonctionnalités arrivent au rythme du fournisseur, et les frais de licence peuvent augmenter avec votre volume. Si vous partez, vous devrez peut-être recréer ailleurs vos écrans, vos accords et vos comptes acheteurs.
Quand construire notre propre plateforme en vaut-il la peine ?
Construire est rentable dans les cas suivants :
- Le programmatique représente une part importante de votre chiffre d'affaires, et les frais coûtent plus cher que de payer une équipe pour faire tourner votre propre système
- Vos écrans ont besoin de règles que les fournisseurs consultés ne savent pas gérer, comme des publicités qui changent selon les horaires des trains dans une gare
- Vous vendez aussi les écrans d'autres réseaux, si bien que la plateforme fait partie de ce que vous vendez
- Les données d'audience de vos lieux doivent rester dans vos propres systèmes
Sur cette voie, chaque DSP doit en général accepter de se connecter à votre plateforme et de tester vos bid requests avant que ses acheteurs puissent voir vos écrans. Quelqu'un doit surveiller le système et régler avec les acheteurs les écarts entre les rapports. OpenRTB évolue aussi en permanence : l'IAB Tech Lab a publié sept mises à jour de la version 2.6 depuis qu'il y a ajouté les écrans. Si vous n'avez personne dans votre équipe pour prendre ce travail en charge, commencez par un SSP ou une solution en marque blanche.
Quel travail reste à la charge de notre équipe, quelle que soit la voie ?
Votre équipe décide et tient à jour les éléments suivants :
- Données sur les écrans et les lieux : un identifiant, un emplacement, une taille, des horaires et un type de lieu pour chaque écran. Une taxonomie des lieux est une liste partagée de types de lieux, pour qu'une salle de sport signifie la même chose pour tous les acheteurs. OpenRTB 2.6 utilise par défaut l'OpenOOH Venue Taxonomy, sauf si la requête en désigne une autre. Cette taxonomie classe les lieux par niveaux, comme « Retail » puis « Retail / Malls ».
- Estimations d'audience et leur source : l'échelon de l'échelle du MRC que mesure votre chiffre, qui l'a mesuré et à quelle fréquence il change
- Validation des créations et règles de contenu : les notes de l'IAB Tech Lab indiquent que les publicités des grands réseaux commerciaux « doivent être pré-approuvées manuellement », dans certains cas aussi par les bailleurs des lieux. Elles préviennent qu'une seule publicité malvenue montrée « à des milliers de personnes dans un lieu public » met en péril le « contrat/l'autorisation de diffuser des publicités » du réseau. Tenez une liste écrite de ce que chaque propriétaire de lieu autorise.
- Logs de diffusion et rapprochement : conservez vos propres logs de preuve de diffusion, même quand un SSP les collecte. Les écrans se déconnectent et les décimales sont arrondies différemment, si bien que quelqu'un doit comparer chaque mois vos logs avec le rapport de chaque acheteur.
- Prix planchers et accords directs : un prix plancher est l'offre la plus basse que vous acceptez, exprimée en CPM comme les offres elles-mêmes. Un accord de private marketplace est une enchère ouverte aux seuls acheteurs que vous invitez. La bid request le signale par un code appelé deal ID. Décidez laquelle l'emporte quand une campagne directe et une offre programmatique visent le même créneau.
Que vérifier avant de signer avec un SSP ou un fournisseur en marque blanche ?
- À qui appartiennent la liste des écrans, les données sur les lieux et les chiffres d'audience que nous chargeons, et pouvons-nous les exporter à tout moment ?
- De qui provient le chiffre d'audience inscrit dans chaque bid request, et comment sa source y est-elle signalée ?
- Quelle part de chaque vente conservez-vous, et nos rapports indiquent-ils à la fois le montant brut et le montant net ?
- Quels DSP sont connectés aujourd'hui, et lesquels ont acheté des diffusions DOOH au cours des trois derniers mois ?
- Pouvons-nous continuer à vendre des campagnes en direct et utiliser d'autres SSP en même temps ?
- Qui valide chaque création, et pouvons-nous bloquer une publicité pour un seul lieu ?
- Que se passe-t-il si nous partons : quelle est la durée du préavis, et quels accords, comptes, logs et rapports pouvons-nous emporter ?
À qui appartiennent le code, les données et les relations avec les acheteurs ?
Un SSP est propriétaire de sa plateforme et de ses contrats avec les DSP. Vos données d'écrans et d'audience doivent rester les vôtres, et le contrat doit le préciser. Les accords mis en place dans un SSP ne vous suivront pas forcément.
Un fournisseur en marque blanche est propriétaire du code, tandis que la marque est la vôtre. Vérifiez si les comptes acheteurs et les connexions aux DSP sont au nom de votre entreprise ou à celui du fournisseur.
Si vous construisez votre propre plateforme, vous pouvez posséder le code source et engager n'importe quelle équipe pour le modifier. Demandez à la société qui la construit de nommer dans le contrat les éléments qu'elle conserve, ainsi que la licence qui vous permet de les utiliser.
Quel que soit votre choix, faites préciser par écrit que vos données ne peuvent servir qu'à vendre vos écrans, et que les logs et les rapports peuvent être exportés à tout moment.
Que demander à une société qui construirait notre plateforme d'écrans ?
- Comment la plateforme se connectera-t-elle à notre CMS et à nos players, et qu'est-ce qui est diffusé quand aucune publicité n'arrive à temps ?
- Comment chaque bid request transmettra-t-elle l'emplacement de l'écran, le type de lieu, l'audience par diffusion et la source de ce chiffre ?
- Comment la preuve de diffusion sera-t-elle enregistrée et rapprochée des rapports des acheteurs ?
- Les acheteurs enverront-ils les créations pour validation via l'Ad Management API de l'IAB Tech Lab, un standard que ses notes qualifient de « vivement recommandé » pour le DOOH ?
- Comment les prix planchers et les accords de private marketplace seront-ils fixés pour chaque écran, chaque lieu et chaque heure ?
- Quels DSP connecterez-vous en premier, et qui mène les discussions avec eux ?
- Pouvez-vous montrer cela en action dans un système qui fonctionne aujourd'hui ?
Où se situe amBrain ?
amBrain publie ce blog. Trois de ses propres déclarations décrivent des systèmes qu'un réseau construit sur la troisième voie. L'une indique : « amBrain construit des supply-side platforms (SSP) pour les éditeurs. » Une autre : « amBrain construit des ad servers : ciblage, capping de fréquence et reporting. » Une troisième : « amBrain construit des pipelines d'analytique d'événements pour l'ad tech : collecte, traitement et reporting des événements d'impression et de clic. » Une quatrième, côté achat, indique : « RTBBidder, une demand-side platform que nous avons construite pour un client. »
amBrain développe des logiciels depuis 2019. Sur sa façon de travailler avec ses clients, elle dit : « Trois formats : livraison complète, équipe dédiée ou ingénieurs intégrés à votre équipe. » Sur la propriété, sa formule est : « Le client conserve la pleine propriété du produit et du code, à l'exception de nos composants réutilisables. » Demandez la liste nominative de ces composants avant de signer.
Cet article n'est pas une étude de cas. Hormis la mention de RTBBidder, il ne décrit aucun travail client. Il n'affirme pas qu'amBrain a construit une plateforme DOOH, connecté un réseau d'écrans à un SSP ou mesuré des audiences pour un client. Il ne donne pas non plus de prix ni de délais d'amBrain. Les citations de l'IAB Tech Lab, de la taxonomie OpenOOH et du MRC proviennent de leurs documents publiés, et l'article n'affirme aucune relation entre amBrain et l'un d'eux.
Ce n'est pas non plus un conseil juridique. Faites relire les contrats avec les SSP, les fournisseurs et les lieux par un avocat avant de signer. Si vos comptages d'audience proviennent de caméras ou d'autres capteurs, demandez comment le droit de la protection des données s'y applique. Si amBrain figure sur votre liste restreinte, posez-lui les mêmes questions qu'à n'importe quelle autre société.
Thèmes
- Affichage numérique hors domicile
- Programmatique
- SSP
- Construire ou acheter