La TV connectée dans votre DSP ou SSP : ce qui change et ce qu'il faut construire vous-même

Les publicités sur TV connectée (CTV) sont des publicités vidéo diffusées sur des téléviseurs connectés à Internet, généralement dans une coupure de plusieurs publicités à l'intérieur d'une application de streaming. Un DSP ou un SSP conçu pour les bannières web et in-app doit changer à quatre endroits pour les prendre en charge. La bid request décrit une coupure publicitaire entière au lieu d'un seul emplacement. La publicité arrive sous forme de réponse VAST, un document XML qui pointe vers les fichiers vidéo. Beaucoup d'applications TV ne peuvent ni demander ni suivre les publicités comme le fait un navigateur, si bien qu'un service de stitching insère la publicité dans le flux. Ce service envoie alors les demandes de publicité, et souvent aussi les appels de suivi, pour le compte du téléviseur : vous devez donc identifier les appareils et compter les impressions autrement. Les enchères sur les coupures publicitaires et la prise en charge de VAST valent la peine d'être construites dans votre propre plateforme. Le stitching revient à l'éditeur ou à un service conçu pour ce travail.

Qu'est-ce qui distingue les publicités sur TV connectée ?

Sur un site web, une demande de publicité porte généralement sur une publicité pour un emplacement, et le navigateur charge cette publicité et signale l'impression. Sur un téléviseur, le spectateur regarde un programme dans une application de streaming, et les publicités arrivent par coupures, comme à la télévision traditionnelle. L'IAB Tech Lab, l'organisme qui maintient le protocole d'enchères OpenRTB, appelle une telle coupure un ad pod : une ou plusieurs publicités qui « sont diffusées les unes à la suite des autres dans un flux de contenu vidéo ou audio ».

La spécification OpenRTB 2.6 de l'IAB Tech Lab présente la version 2.6 comme celle qui « introduit les ad pods pour les transactions CTV ». Cet article s'appuie sur cette spécification et sur les notes d'implémentation que l'IAB Tech Lab lui consacre, consultées le 2 novembre 2026 comme les autres sources citées ici.

Comment une coupure publicitaire arrive-t-elle dans une bid request ?

Dans OpenRTB 2.6, une coupure arrive sous forme d'un ou de plusieurs objets impression dans la bid request, et les objets impression qui partagent le même podid appartiennent à la même coupure. Les notes d'implémentation décrivent trois types de coupure :

• Structurée : le vendeur fixe à l'avance le nombre d'emplacements, leur ordre et la durée de chacun, et chaque emplacement est un objet impression distinct
• Dynamique : le vendeur fixe la durée totale et le nombre maximal de publicités, mais pas le nombre ni la durée de chaque publicité, et toute la coupure peut arriver sous forme d'un seul objet impression
• Hybride : une partie de la coupure est fixe et une partie est dynamique

La plupart des plateformes de bannières n'ont jamais eu à lire les champs suivants :

• poddur, le nombre total de secondes que les annonceurs peuvent remplir dans une coupure dynamique, et maxseq, le nombre maximal de publicités qu'elle peut contenir
• rqddurs, une liste de durées publicitaires exactes. La spécification indique qu'il est destiné à la TV en direct, « où des durées publicitaires non exactes entraîneraient des “blancs à l'antenne” indésirables »
• slotinpod, qui indique si le vendeur peut garantir le premier ou le dernier emplacement, et podseq, la position de la coupure dans le programme
• mincpmpersec, un prix plancher par seconde de temps publicitaire pour la partie dynamique d'une coupure

Chaque bid indique la durée de sa publicité dans le champ dur. Les notes d'implémentation précisent aussi que les acheteurs « devraient s'attendre à ce que la composition finale du pod soit faite par le vendeur ». Si vous envoyez plusieurs bids pour une même coupure, le vendeur peut en utiliser un nombre quelconque, d'aucun à tous, et les mêler aux publicités d'autres acheteurs.

Envoyez le domaine de l'annonceur (adomain) et l'identifiant de la création (crid) avec chaque bid. La spécification range les deux parmi les attributs utilisés « pour les contrôles de qualité publicitaire ou l'application des restrictions de l'éditeur ».

Pour un DSP, les coupures publicitaires changent la logique d'enchère. Un bidder pour bannières fixe le prix d'une impression à la fois. Un bidder CTV doit choisir lesquelles de ses publicités tiennent dans le temps restant de la coupure et fixer leur prix à la seconde, et il ne peut pas contrôler celles que le vendeur conserve.

Que doit contenir la réponse VAST ?

Les publicités vidéo sont livrées avec VAST, que l'IAB Tech Lab décrit comme « un schéma XML universel pour diffuser des publicités dans les lecteurs vidéo numériques ». Sa page VAST, mise à jour pour la dernière fois en juillet 2024, présente VAST 4.3, de décembre 2022, comme la version la plus récente. Le dépôt VAST 4.x de l'IAB Tech Lab sur GitHub contient aussi VAST 4.4, qu'une note d'un mainteneur y décrit comme publiée le 22 juillet 2026. VAST 4.4 ajoute des formats CTV comme les publicités à la pause et en économiseur d'écran. Les citations ci-dessous proviennent de VAST 4.3.

En juillet 2024, l'IAB Tech Lab a aussi publié un addendum CTV qui apporte l'identifiant de création et le fichier mezzanine de VAST 4 aux versions plus anciennes VAST 2 et 3. L'addendum indique que ces versions antérieures « dominent encore le marché aujourd'hui ».

Deux éléments de VAST comptent le plus à la télévision :

• Un fichier mezzanine, « le fichier vidéo brut de haute qualité » à partir duquel les systèmes de l'éditeur produisent une version pour chaque écran. VAST 4.3 indique qu'un fichier mezzanine « est requis dans les diffusions en ad stitching », et qu'un service de stitching peut rejeter une réponse qui n'en contient pas
• Un UniversalAdId, un identifiant qui accompagne la création d'un système à l'autre. VAST 4.3 l'exige pour les publicités linéaires, celles qui sont diffusées à l'intérieur du programme, et l'addendum l'ajoute à VAST 2 et 3 sous forme d'extension. Les services de stitching s'en servent pour savoir s'ils ont déjà converti une création

Dans le processus de stitching que décrit VAST 4.3, une création que le service n'a jamais vue doit être convertie avant de pouvoir être diffusée : la coupure diffuse donc une autre publicité à sa place. VAST 4.3 note que le premier téléchargement d'un fichier mezzanine « peut prendre plusieurs heures ». AWS décrit la même règle pour MediaTailor, son service cloud qui insère les publicités dans les flux : « Si une publicité n'a pas encore été transcodée pour correspondre au contenu, MediaTailor ne l'insère pas », et la publicité est préparée pour la requête suivante.

Une nouvelle création peut donc manquer ses premières occasions d'être diffusée sur chaque service de stitching. VAST 4.3 indique qu'une création modifiée de quelque façon que ce soit devrait recevoir un nouvel identifiant. Ne changez pas l'identifiant tant que la création elle-même ne change pas, afin que chaque service de stitching ne la convertisse qu'une seule fois.

Pour le code de vérification, VAST 4.3 recommande Open Measurement (OMID) et se prononce « fortement contre l'utilisation de VPAID », l'ancienne façon d'exécuter du code dans une publicité vidéo. Il désigne SIMID comme le remplaçant de VPAID pour les publicités interactives. VAST 4.3 sépare le code interactif du fichier vidéo pour que les lecteurs qui fonctionnent avec un service de stitching puissent quand même lire la vidéo lorsqu'ils ne peuvent pas exécuter le code. Assurez-vous que chaque création TV fonctionne comme une simple vidéo.

Qu'est-ce qui change quand un serveur insère la publicité dans le flux ?

Beaucoup d'applications TV ne peuvent ni demander ni suivre les publicités comme le fait un navigateur. VAST 4.3 décrit l'alternative, appelée insertion publicitaire côté serveur (SSAI) ou ad stitching. L'application demande le flux à un service de stitching, le service demande des publicités à l'ad server, et les publicités sont insérées dans le contenu afin que le spectateur reçoive « un flux continu unique ».

OpenRTB 2.6 ajoute à l'objet impression un champ ssai qui indique quelle part du stitching et du suivi se fait sur un serveur. Ses valeurs vont d'« entièrement côté client » à « entièrement côté serveur ». Dans le cas intermédiaire, la vidéo est insérée sur le serveur et les pixels de suivi sont déclenchés par l'appareil. La valeur par défaut, 0, signifie que le statut est inconnu : une requête sans ce champ ne vous apprend donc rien, ni dans un sens ni dans l'autre.

Quand les demandes de publicité et les appels de suivi viennent d'un serveur, de nombreux spectateurs semblent partager une même adresse IP. VAST 4.3 avertit : « Pour un ad server qui reçoit des informations de suivi, les rapports ressemblent à du trafic invalide. » Il précise que les fournisseurs de stitching doivent envoyer l'adresse IP et le user agent de l'appareil dans deux en-têtes, X-Device-IP et X-Device-User-Agent, avec leurs requêtes de suivi, et que ces valeurs doivent correspondre à celles de la demande de publicité d'origine.

Pour votre plateforme, cela signifie :

• Quand le trafic passe par un service de stitching, prenez les informations sur l'appareil dans ces en-têtes et dans la bid request. L'adresse IP qui se connecte à vous appartient alors au service de stitching : ne l'utilisez donc pas pour l'appareil
• Interrogez le vendeur sur tout trafic côté serveur qui arrive sans les en-têtes X-Device
• Vérifiez que le vendeur figure dans le fichier app-ads.txt de l'éditeur. La spécification de l'IAB Tech Lab étend ads.txt aux applications issues des « boutiques d'applications de télévision connectée »
• Fondez les plafonds de fréquence et les audiences sur les identifiants d'appareil. VAST 4.3 note qu'un service de stitching « ne peut pas accéder aux cookies ». Dans OpenRTB 2.6, le champ ifa porte un identifiant publicitaire censé provenir du système d'exploitation de l'appareil, et le champ lmt indique quand le suivi doit être limité

Comment les impressions sont-elles comptées et facturées ?

Les notes d'implémentation d'OpenRTB comparent les façons de compter les événements facturables. Pour l'audio et la vidéo, elles recommandent l'événement impression de VAST. L'URL de notification de facturation (burl), qui fonctionne bien pour les bannières, est « non recommandée pour l'audio/la vidéo ».

Les notes conseillent aussi aux bidders de suivre le délai entre l'enchère et la notification de facturation, car les objectifs de dépense, les plafonds de fréquence et le pacing en dépendent. Dans leur tableau des délais raisonnables, la ligne pour l'audio ou la vidéo avec stitching côté serveur indique « Très long ou inconnu ».

Avec le champ exp, le vendeur indique dans la requête combien de secondes peuvent s'écouler entre l'enchère et l'impression, et l'acheteur indique dans le bid combien de secondes il est prêt à attendre. Les deux valeurs sont indicatives. Les notes recommandent aux bidders de ne pas supposer qu'une notification de facturation arrivée après l'exp de leur bid ne sera pas facturée, car cela relève du contrat avec l'ad exchange.

Le stitching côté serveur n'a pas changé les règles de comptage. VAST 4.3 cite les lignes directrices de mesure de l'IAB élaborées avec le Media Rating Council (MRC) : « Les lignes directrices de mesure exigent que le comptage des publicités repose sur une approche initiée par le client ». Le même passage autorise le comptage sur un serveur « à condition qu'il soit déclenché à partir d'événements et d'éléments de mesure côté client ». Il rejette le comptage qu'un serveur lance de lui-même, car c'est celui qui est « le plus éloigné de l'utilisateur qui voit réellement la publicité ». Demandez à chaque vendeur quel événement déclenche son comptage des impressions quand un serveur insère la publicité.

Que faut-il construire vous-même, et que gèrent déjà les partenaires ?

Certaines parties d'un dispositif CTV reviennent à l'éditeur ou à des services conçus pour les éditeurs. Le stitching lui-même en fait partie. MediaTailor, par exemple, envoie les informations du spectateur au serveur de décision publicitaire, reçoit les publicités choisies dans la réponse de l'ad server et les insère dans le flux. La conversion des fichiers vidéo au format de chaque éditeur fait partie du même travail.

D'autres parties déterminent ce que gagne votre plateforme, et celles-là, il vaut la peine de les construire vous-même :

• Pour un DSP : choisir quelles publicités tiennent dans une coupure et fixer leur prix à la seconde
• Pour un DSP : le pacing des budgets quand les notifications de facturation arrivent en retard
• Pour un DSP : diffuser des créations avec un fichier mezzanine et un identifiant de création qui ne change que si la création change, dans l'élément UniversalAdId de VAST 4 ou dans l'extension de l'addendum pour VAST 2 et 3
• Pour un SSP : composer chaque coupure à partir des bids de plusieurs acheteurs et appliquer les règles de l'éditeur sur les annonceurs autorisés à y apparaître
• Pour un SSP : transmettre les champs de pod et la valeur ssai à chaque acheteur
• Pour les deux : lire les informations sur l'appareil dans les en-têtes X-Device et filtrer le trafic invalide côté serveur
• Pour les deux : compter les impressions d'une façon que les acheteurs et les auditeurs acceptent

Un DSP qui veut seulement vérifier si ses annonceurs veulent de la CTV peut commencer avec un ou deux SSP qui vendent déjà de la CTV, et enchérir d'abord sur les coupures structurées. Demandez à ces SSP quelle part de leur inventaire CTV arrive sous forme de coupures dynamiques, car les notes d'implémentation encouragent les vendeurs à proposer des pods dynamiques quand c'est possible. La TV en direct, avec ses durées publicitaires exactes, peut attendre que les premières campagnes montrent que les annonceurs la veulent.

Construisez tout ce qui figure dans la liste ci-dessus quand la CTV devient une part durable de votre chiffre d'affaires. Il en va de même si vous concluez vos propres accords avec des éditeurs TV, ou si la façon dont un partenaire gère les coupures continue de décider lesquels de vos bids sont diffusés.

Que demander à une société qui ajoute la CTV à notre plateforme ?

• Quels champs de pod d'OpenRTB 2.6 le système lira-t-il, et comment choisit-il les publicités pour une coupure dynamique ?
• Comment le système fixe-t-il le prix des bids à la seconde, et respecte-t-il mincpmpersec ?
• Quelles versions de VAST nos créations utiliseront-elles, et d'où viennent les fichiers mezzanine ?
• Nos créations porteront-elles des UniversalAdId enregistrés, ou la valeur par défaut « unknown » ?
• Comment le système gère-t-il le trafic côté serveur, et d'où tire-t-il l'adresse IP et le user agent de l'appareil ?
• Comment les impressions sont-elles comptées pour chaque vendeur ?
• Comment le pacing reste-t-il précis quand les notifications de facturation arrivent très en retard ?
• Avec quels partenaires ferons-nous les premiers tests, et quelles fonctionnalités peuvent attendre ?

Où se situe amBrain ?

En AdTech, amBrain travaille sur le développement de DSP, les plateformes d'enchères en temps réel et l'ingénierie d'ad exchange. Deux lignes de sa liste de services indiquent : « amBrain construit des supply-side platforms (SSP) pour les éditeurs. » et « amBrain construit des ad servers : ciblage, capping de fréquence et reporting. » RTBBidder est une demand-side platform qu'amBrain a construite pour un client.

amBrain développe des logiciels depuis 2019. Elle travaille en trois formats : la prestation complète, une équipe dédiée ou des 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. »

Cet article n'est pas une étude de cas. Hormis la mention de RTBBidder, il ne décrit aucun travail pour un client : il ne dit pas qu'amBrain a ajouté la TV connectée à une quelconque plateforme, et il ne donne aucun chiffre sur RTBBidder, ni prix ni délais d'amBrain. L'IAB Tech Lab et AWS sont cités d'après leurs propres documents, et l'article n'affirme aucune relation entre amBrain et l'un ou l'autre. Si amBrain figure sur votre liste restreinte, posez-lui les mêmes questions qu'à n'importe quelle autre société.