Le RTB (real-time bidding) est le protocole d'enchères sous-jacent à la publicité programmatique. Chaque impression est mise aux enchères en 50 à 150 millisecondes — le SSP envoie une demande d'enchère, plusieurs DSP évaluent et répondent avec des enchères, l'enchère se résout et le créatif gagnant s'affiche. La spécification OpenRTB (gérée par l'IAB Tech Lab) définit le protocole : à quoi ressemblent les demandes d'enchère, quels champs elles contiennent, ce que les enchères doivent retourner.
La chronologie d'enchère de 50-150 ms
- 0 ms — l'utilisateur ouvre l'app / la page de l'éditeur. L'app / la page envoie la demande publicitaire au SDK.
- 5-20 ms — le SSP reçoit la demande, l'enrichit avec des données d'audience, la diffuse aux ad exchanges.
- 20-100 ms — l'ad exchange diffuse la demande d'enchère aux DSP connectés. Chaque DSP évalue la demande par rapport aux règles de ciblage des annonceurs, calcule un prix d'enchère, répond.
- 100-130 ms — l'exchange collecte les enchères, lance l'enchère, sélectionne le gagnant.
- 130-150 ms — l'URL du créatif gagnant est retournée, l'annonce s'affiche.
Un délai supérieur à ~150 ms entraîne l'abandon de l'emplacement publicitaire (l'impression expire et affiche une annonce de remplacement). Les enchérisseurs qui répondent lentement sont pénalisés — les exchanges excluent les DSP lents de l'enchère.
Types d'enchères
- Enchère au premier prix : le gagnant paie son prix d'enchère. Standard industriel en 2026 — Google AdX et la plupart des grands SSP ont basculé du deuxième au premier prix entre 2017 et 2019. Oblige les annonceurs à enchérir de façon plus stratégique (vous payez ce que vous enchérissez, pas ce que vous auriez eu à payer pour gagner).
- Enchère au deuxième prix : le gagnant paie un centime au-dessus de l'enchère du deuxième. Mécanisme classique de type eBay, largement utilisé en programmatique jusqu'au basculement de la fin des années 2010. Théoriquement favorise des enchères sincères (vous pouvez enchérir à votre maximum sans surpayer) ; en pratique, les mécaniques opaques + le header bidding l'ont rendu instable.
RTB dans les apps mobiles
- Via SDK : un SDK dans l'app (typiquement le SDK de médiation de l'éditeur — AppLovin MAX, ironSource LevelPlay, Google Admob) gère la demande d'enchère localement. Le SDK envoie la demande, reçoit l'enchère, affiche le créatif gagnant.
- Serveur à serveur (s2s) : le backend de l'éditeur gère la demande d'enchère, l'adressant aux exchanges depuis le serveur. Utilisé pour les enchères de type header-bidding où l'éditeur veut plus de contrôle sur la logique d'enchère.
Le payload de la demande d'enchère dans le mobile inclut l'ID de l'app, le format publicitaire, les signaux utilisateur (quand disponibles), les signaux de l'appareil, la géolocalisation (avec permission), le contexte de contenu. Post-ATT sur iOS, les signaux au niveau utilisateur sont fortement réduits — la demande d'enchère est bien moins riche que sur Android ou iOS pré-ATT.
Pièges courants du RTB
- Timeout d'enchère : les DSP qui répondent lentement sont exclus des enchères. Maintenez des temps de réponse inférieurs à 100 ms.
- Données d'audience périmées : enchérir sur des signaux d'audience frais il y a 5 minutes et périmés maintenant. Les mises à jour d'audience en temps réel sont importantes.
- Collusion d'enchères : quand plusieurs enchérisseurs partagent des sources de données, les enchères peuvent se corréler de façon suspecte. Les DSP matures intègrent des analyses anti-collusion.
- Bid shading : dans les enchères au premier prix, les DSP sophistiqués « ombrent » leurs enchères à la baisse en se basant sur les prix de clôture historiques — ils enchérissent ce qu'ils espèrent gagner, pas leur maximum. Les enchères naïves surpayent.