Votre propre SSP : quand Prebid Server ou un SSP loué suffit, et qui peut en construire un

Un SSP, ou supply-side platform, est le logiciel qui propose l'espace publicitaire d'un éditeur à de nombreux acheteurs à la fois et paie l'éditeur pour ce qui se vend. Un éditeur qui ne vend de l'espace publicitaire que sur ses propres sites ou applications a rarement besoin d'en construire un. Il peut vendre via des SSP existants et organiser sa propre enchère entre eux avec Prebid Server, un programme open source. Avoir votre propre SSP a du sens quand vendre l'espace publicitaire d'autres éditeurs est votre métier. Même dans ce cas, un SSP loué peut suffire jusqu'à ce que votre volume rende ses frais trop élevés ou que vos éditeurs aient besoin de quelque chose qu'il ne sait pas faire. Si vous construisez, faites appel à une société qui vous remet le code et installe le SSP sous le domaine et le nom de votre société.

Que fait un SSP pour un éditeur ?

La page ou l'application d'un éditeur envoie une demande publicitaire chaque fois qu'elle a un espace à remplir. Le SSP transforme cette demande en bid requests destinées aux demand-side platforms (DSP), les logiciels qu'utilisent les annonceurs pour acheter de l'espace publicitaire. Il recueille leurs offres, désigne le gagnant et enregistre la vente, pour pouvoir payer l'éditeur plus tard. L'éditeur fixe aussi des règles dans le SSP, comme le prix le plus bas qu'il accepte, appelé prix plancher (floor), et les types de publicités qu'il refuse.

Chaque enchère a une échéance. L'IAB Tech Lab, un organisme à but non lucratif qui rédige des standards techniques pour la publicité numérique, publie OpenRTB, un standard pour les bid requests. La version 2.6, consultée le 23 octobre 2026, définit le champ tmax comme le « temps maximal, en millisecondes, que l'ad exchange accorde pour la réception des offres, latence d'Internet comprise, afin d'éviter un timeout ». Une offre qui arrive plus tard équivaut à une absence d'offre.

Le SSP gère aussi l'argent. Il compte les publicités affichées et facture les acheteurs, puis verse à chaque éditeur sa part. Quand ces décomptes ne concordent pas avec ceux d'un acheteur, quelqu'un doit trouver pourquoi avant l'envoi des factures.

Prebid Server suffit-il à un éditeur ?

Prebid Server peut suffire à un éditeur qui ne vend que son propre espace publicitaire, si l'équipe de l'éditeur ou un hébergeur l'exploite. Prebid Server est conçu pour le header bidding. Avec le header bidding, un éditeur demande des offres à plusieurs SSP et ad exchanges à la fois, avant que son ad server ne décide quelle publicité afficher. Un ad exchange organise des enchères pour de l'espace publicitaire à peu près comme un SSP.

La page de présentation de Prebid.org, consultée le même jour, indique : « Prebid Server est une solution open source pour le header bidding server-to-server. » La page fait état de « 230+ adaptateurs d'enchères côté serveur », des connexions prêtes à l'emploi vers des sources d'offres comme les SSP et les ad exchanges.

Selon la même page, Prebid Server vérifie chaque requête entrante, applique les règles de confidentialité et appelle les adaptateurs d'enchères. Une fois qu'ils ont répondu, ou que « le délai de timeout a expiré », il renvoie sa réponse à l'émetteur de la requête, comme une page web ou une application.

Avec Prebid Server, l'éditeur organise l'enchère entre les SSP et les ad exchanges avec lesquels il travaille, généralement sans contrats propres avec des DSP. Chaque SSP continue de payer l'éditeur pour l'espace publicitaire qu'il vend, et la plupart des connexions aux DSP restent du côté des SSP.

La page de présentation décrit deux scénarios courants : « Éditeurs à l'aise avec la technique » et « Fournisseurs de services managés : pour tous les autres ». Elle indique : « Aucun outil de configuration n'est fourni par la communauté open source. » Elle prévient aussi que l'installation de Prebid Server « est loin d'être aussi simple que Prebid.js », le code de header bidding de Prebid qui s'exécute dans le navigateur du visiteur.

Le code de prebid-server sur GitHub, consulté le même jour, est publié sous l'Apache License 2.0, une licence open source. Elle permet à chacun d'utiliser et de modifier le code, y compris à des fins commerciales. Un éditeur peut le faire tourner sur ses propres serveurs ou passer par un fournisseur qui l'héberge. La page de présentation indique que les hébergeurs « proposent aussi des outils pour gérer les stored requests ».

Quand devrions-nous construire notre propre SSP ?

Votre propre SSP convient à une activité qui vend de l'espace publicitaire pour d'autres éditeurs. Les ad networks, les sociétés de monétisation d'applications et les groupements d'éditeurs qui vendent leur espace ensemble en sont des exemples. Pour eux, l'enchère et ses frais sont le produit, et un logiciel loué limite les changements sur l'un comme sur l'autre.

Construire peut aussi se justifier quand un SSP loué facture chaque requête ou chaque vente et que votre volume ne cesse d'augmenter. Une troisième raison est une règle d'enchère ou un format publicitaire dont vos éditeurs ont besoin et qu'aucun des produits loués que vous avez essayés ne prend en charge.

Un SSP ne gagne rien tant que des DSP n'ont pas accepté de recevoir ses bid requests, et chaque connexion à un DSP est une intégration, un test et un contrat à part. Avant de construire, notez quels DSP ont accepté de se connecter à votre SSP et quels éditeurs apporteront leur espace publicitaire au lancement.

Que nous apporte la location d'un SSP, et que garde le fournisseur ?

Louer signifie que le fournisseur exploite le logiciel et que vous l'utilisez dans le cadre d'un contrat, parfois sous votre propre marque. Epom, un fournisseur d'ad servers, vend son module SSP en option de ses formules d'ad server. Sa page de tarifs, consultée le même jour, fait démarrer les formules à 250 $ par mois et fixe le prix du « SSP module » à « 0,001 $ pour 1 000 ext.reqs ». Le module permet de « connecter des endpoints DSP personnalisés ». Une autre option, une « White-label solution » à 250 $ par mois, propose : « Utilisez le nom, le logo et le domaine de votre entreprise au lieu de ceux par défaut. »

Un produit loué à votre marque appartient toujours au fournisseur. Les Epom Server Terms and Conditions, consultées le même jour, stipulent : « Le présent Contrat ne constitue pas une vente et ne confère aucun droit de propriété sur le Logiciel. » Les mêmes conditions précisent que le client est propriétaire de ses « Données de compte » (Account Data), c'est-à-dire les informations d'utilisation et les profils de trafic issus de son utilisation du logiciel, et que « toutes les Données de compte seront effacées du Logiciel dans un délai de trente (30) jours suivant le non-renouvellement ou la résiliation anticipée ». Prévoyez l'export de vos données avant la fin d'un contrat.

D'autres fournisseurs rédigent leurs contrats autrement : lisez donc la section sur la propriété avant de comparer les prix. Les prix à la requête dépendent de ce que le fournisseur compte comme une requête, et la page d'Epom ne définit pas « ext.reqs ». Demandez cette définition par écrit, ainsi que le domaine que vos éditeurs indiqueront comme vendeur de leur espace publicitaire.

Quels fichiers indiquent aux acheteurs qui vend l'espace publicitaire ?

Les acheteurs vérifient d'où vient l'espace publicitaire avant d'enchérir. Un éditeur liste chaque système autorisé à vendre son espace dans un fichier appelé ads.txt, sur son propre site. Les applications utilisent un fichier compagnon, app-ads.txt. La version 1.1 de la spécification ads.txt, consultée le même jour, définit le premier champ de chaque ligne comme « le nom de domaine canonique du système (SSP, ad exchange, header wrapper, etc.) auquel se connectent les bidders ».

Le troisième champ d'une ligne ads.txt indique si l'éditeur travaille directement avec ce système. La spécification précise que « DIRECT » signifie que l'éditeur « contrôle directement le compte » nommé dans la ligne. Elle ajoute que cela « signifie en général un contrat commercial direct entre l'éditeur et le système publicitaire ».

Le SSP publie un fichier appelé sellers.json, qui nomme chaque vendeur dont il vend l'espace publicitaire. La version 1.0 de la spécification sellers.json, datée de juillet 2019 et consultée le même jour, indique : « Les systèmes publicitaires devraient publier le fichier sellers.json sur leur domaine racine et, au besoin, sur leurs sous-domaines. »

Le fichier doit lister tous les vendeurs : « Tous les vendeurs doivent être inclus, même s'ils sont confidentiels. » Chaque identifiant de vendeur correspond à une seule société. Selon les termes de la spécification, « chaque seller_id ne doit correspondre qu'à une seule entité, payée pour l'inventaire vendu sous ce seller_id ».

Le domaine du SSP peut aussi apparaître dans les bid requests. OpenRTB 2.6 recommande un objet SupplyChain dans chaque bid request : une liste des sociétés qui participent à la vente de l'espace publicitaire et sont payées en chemin, liste qui peut être marquée comme incomplète. Son champ asi est défini dans les mêmes termes que le premier champ d'une ligne ads.txt : le domaine du système auquel se connectent les bidders.

Pour l'espace publicitaire montré à des personnes dans l'UE, il faut tenir compte d'un cadre de plus. IAB Europe, une organisation professionnelle du secteur publicitaire, gère le Transparency and Consent Framework (TCF), qui transmet les choix de chaque personne en matière de vie privée, comme son consentement, depuis le site ou l'application de l'éditeur jusqu'aux entreprises ad tech. IAB Europe qualifie le TCF de « standard volontaire ». Sa page destinée aux fournisseurs (vendors), consultée le même jour, indique que les fournisseurs « peuvent être des ad servers, des fournisseurs de mesure, des agences de publicité, des DSP, des SSP, et plus encore ». La page ajoute : « Les fournisseurs doivent s'enregistrer pour participer au TCF. »

Que devons-nous posséder une fois le SSP construit ?

Chaque fichier et chaque enregistrement mentionnés plus haut désignent un domaine ou une société. Vérifiez que chacun des éléments ci-dessous revient bien à votre société :

• Le domaine qui figure dans les lignes ads.txt de vos éditeurs et dans le champ asi, enregistré au nom de votre société
• Le fichier sellers.json sur ce domaine, et les identifiants de vendeurs qui y figurent
• Les contrats avec chaque DSP, signés par votre société et non par le prestataire
• Un enregistrement de fournisseur TCF au nom de votre société, si votre SSP participe au TCF
• Les dépôts de code, les scripts de build et les comptes cloud ouverts au nom de votre société
• Les logs et les rapports, avec un moyen testé de les exporter

Le domaine est généralement l'élément le plus difficile à changer après coup. Un nouveau domaine implique une nouvelle ligne dans le fichier ads.txt de chaque éditeur. Tant qu'un éditeur n'a pas ajouté cette ligne, les acheteurs qui vérifient ads.txt peuvent considérer les ventes de son espace via votre SSP comme non autorisées.

Demandez au prestataire de nommer chaque partie de son propre code ou de code tiers qui reste hors de votre propriété, avec la licence de chacune. Le code open source intégré au SSP, comme Prebid Server, conserve sa propre licence. L'article sur la vérification d'une équipe dédiée et la façon de garder la propriété du code traite de la rédaction des contrats en général.

Comment vérifier une société qui propose de construire notre SSP ?

Les vérifications générales valables pour tout prestataire ad tech figurent dans l'article sur la construction, la licence ou la location d'un DSP ou d'un ad exchange. Construire un SSP soulève six questions de plus :

• Quel SSP ou ad exchange que vous avez construit est en production aujourd'hui ? Quels DSP achètent par son intermédiaire ?
• Pouvez-vous nous montrer une bid request envoyée par votre système, avec l'objet SupplyChain renseigné ?
• Que devient une offre qui arrive après tmax, et comment un éditeur voit-il combien d'offres sont arrivées trop tard ?
• Comment rapprochez-vous votre décompte des publicités affichées de celui de chaque DSP avant que quiconque ne soit facturé ?
• Qui ajoute un nouvel éditeur dans sellers.json, et combien de temps prend la modification ?
• Quels composants restent les vôtres après la passation ?

Une société qui a déjà exploité un SSP peut répondre à la plupart de ces questions en montrant des fichiers, des logs et des rapports. Si un accord de confidentialité empêche de nommer un client, demandez plutôt à la société d'organiser un appel avec ce client.

Consacrez le plus de temps aux questions de décompte, car les éditeurs sont payés sur la base des chiffres du SSP. L'article sur les rapports qui ne concordent pas avec les logs du bidder explique où deux séries de décomptes divergent.

Combien coûtera la construction ou la location d'un SSP ?

Construire commence par un coût ponctuel pour la première version : l'enchère, les connexions aux éditeurs et aux DSP, les fichiers évoqués plus haut, le reporting et les reversements. Après le lancement, les coûts d'exploitation couvrent les serveurs, le trafic réseau, la supervision, les personnes d'astreinte et des frais comme la cotisation annuelle de fournisseur TCF.

Le trafic réseau d'un SSP augmente avec le nombre de DSP autant qu'avec le nombre de demandes publicitaires. Pour chaque demande publicitaire, le SSP envoie une bid request distincte à chaque DSP qu'il sollicite : chaque nouveau DSP ajoute donc des requêtes, du trafic et des serveurs.

La location transforme l'essentiel de ces coûts en frais versés au fournisseur, comme l'abonnement à la formule d'Epom et son tarif pour 1 000 « ext.reqs ». Comparez les deux options au volume que vous attendez dans deux ans. Comptez aussi le coût d'un départ, par exemple de nouvelles lignes ads.txt chez chaque éditeur si le domaine appartient au fournisseur.

Où se situe amBrain ?

La liste des services d'amBrain comprend cette ligne : « amBrain construit des supply-side platforms (SSP) pour les éditeurs. » En AdTech, amBrain travaille aussi sur le développement de DSP, les plateformes d'enchères en temps réel et l'ingénierie d'ad exchange. 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. » Si amBrain figure sur votre liste restreinte, posez-lui les mêmes questions qu'à n'importe quelle autre société, y compris sur les composants réutilisables qu'elle entend par là.

Cet article n'est pas une étude de cas et ne décrit aucun travail pour un client. RTBBidder n'est cité que comme un DSP qu'amBrain a construit, et l'article ne donne aucun chiffre à son sujet.

Prebid.org, l'IAB Tech Lab, IAB Europe et Epom sont cités à titre d'exemples, d'après leurs propres pages, et l'article n'affirme aucune relation entre amBrain et l'un d'eux. Il ne donne ni prix ni délais d'amBrain. Il ne constitue pas non plus un conseil juridique : les règles sur le consentement et les données varient selon les pays, vérifiez-les donc auprès d'un avocat.