Prebid.js ou Prebid Server : lequel choisir pour votre site ?

Le header bidding consiste à mettre plusieurs acheteurs en concurrence sur chaque emplacement publicitaire, avant l’appel à votre serveur publicitaire, pour que chaque impression parte au meilleur prix. Dans l’écosystème open source Prebid, deux options s’offrent à vous : mener ces enchères dans le navigateur du lecteur avec Prebid.js, ou les déporter sur un serveur avec Prebid Server. Le choix pèse sur vos revenus, sur la vitesse de vos pages et sur la charge de votre équipe. Ce guide explique le fonctionnement de chaque solution, les compare point par point et vous donne une méthode pour décider… et pour vérifier que vous avez bien décidé.

Comment fonctionne Prebid.js

Prebid.js est une bibliothèque JavaScript chargée dans vos pages. Au chargement, elle envoie en parallèle une requête d’enchère à chaque partenaire configuré (SSP, places de marché, réseaux) grâce à un adaptateur propre à chacun : il existe plusieurs centaines d’adaptateurs maintenus par la communauté et par les partenaires eux-mêmes. Les réponses reçues avant la fin du délai imparti (le timeout) sont comparées, puis Prebid.js transmet les meilleures offres à Google Ad Manager sous forme de clés-valeurs posées sur chaque emplacement :

• hb_pb : le prix de l’offre, arrondi selon la granularité de prix que vous avez choisie ;
• hb_bidder : le partenaire qui a fait l’offre ;
• hb_adid et hb_size : l’identifiant et le format de la création.

Dans Google Ad Manager, des éléments de campagne ciblent ces valeurs : l’offre Prebid entre alors en concurrence avec vos campagnes directes et avec la demande de Google. Si elle l’emporte, la création est affichée dans l’emplacement.

Les forces de Prebid.js

• La synchronisation des identifiants se fait dans le navigateur. Chaque partenaire peut reconnaître le visiteur dans son propre contexte, ce qui lui permet d’enchérir en connaissance de cause. La correspondance des identifiants est souvent meilleure qu’en mode serveur, et les offres souvent plus élevées.
• La maturité. Prebid.js est déployé chez un très grand nombre d’éditeurs, bien documenté, et la plupart des partenaires proposent un adaptateur client.
• La transparence. Toute l’enchère est visible dans la page : on peut suivre chaque requête, chaque réponse et chaque timeout dans les outils du navigateur.

Les limites de Prebid.js

• Le poids du JavaScript. Chaque adaptateur ajoute du code à télécharger, à analyser et à exécuter.
• Le nombre de requêtes. Chaque bidder déclenche ses propres appels réseau, en plus des synchronisations d’identifiants.
• Le thread principal. Ce travail s’exécute sur le même fil que votre page : il peut retarder les réactions aux clics et aux saisies, et donc dégrader l’INP.
• Le mobile. Sur un téléphone d’entrée de gamme avec une connexion moyenne, ces coûts se cumulent et les timeouts deviennent plus fréquents.

Comment fonctionne Prebid Server

Prebid Server est un serveur open source, disponible en deux implémentations, l’une en Go, l’autre en Java. Vous pouvez l’héberger vous-même ou passer par une société qui l’exploite pour le compte de ses clients. Le principe : le navigateur, ou l’application, envoie une seule requête à Prebid Server, qui interroge à son tour les partenaires de serveur à serveur, collecte leurs réponses et renvoie les meilleures offres. Sur le web, c’est toujours Prebid.js qui envoie cette requête et qui transmet ensuite les clés-valeurs à Google Ad Manager.

Les forces de Prebid Server

• Un navigateur allégé. Moins de code d’adaptateurs, moins de connexions ouvertes : la page travaille moins.
• Les applications mobiles. Les SDK Prebid Mobile pour iOS et Android s’appuient sur Prebid Server : c’est la voie naturelle pour le header bidding dans une application.
• AMP et CTV. Les pages AMP ne peuvent pas exécuter Prebid.js ; elles passent par Prebid Server. La vidéo sur téléviseurs connectés (CTV) et d’autres environnements sans navigateur en dépendent aussi.
• Un point de contrôle central. Règles, prix planchers et configuration des partenaires peuvent être gérés côté serveur, sans redéployer le code des pages.

Les limites de Prebid Server

• Une correspondance d’identifiants plus faible. Les partenaires ne voient plus directement le navigateur. La synchronisation passe par le domaine du serveur Prebid, ce que les navigateurs qui bloquent les cookies tiers limitent. Les modules d’identifiants de Prebid.js atténuent l’écart, sans toujours le combler.
• Un coût et une exploitation. Héberger Prebid Server, c’est des serveurs à dimensionner pour vos pics de trafic, une supervision, des mises à jour régulières et une astreinte. Passer par un hébergeur supprime cette charge, mais pas la facture.
• Des adaptateurs disponibles. Tous les partenaires n’ont pas d’adaptateur serveur, et les listes diffèrent entre les versions Go et Java. Vérifiez vos partenaires clés avant de choisir.

Le comparatif

Le tableau ne donne pas de gagnant : il montre des compromis. Un site de presse très mobile avec quinze bidders ne tranchera pas comme un site B2B avec trois partenaires et une audience majoritairement sur ordinateur.

L’approche hybride

Rien n’oblige à choisir l’un ou l’autre. Prebid.js peut envoyer une partie des bidders à Prebid Server et garder les autres dans le navigateur, grâce à la configuration s2sConfig :

pbjs.setConfig({
  s2sConfig: [{
    accountId: 'votre-compte',
    enabled: true,
    adapter: 'prebidServer',
    bidders: ['partenaireA', 'partenaireB'],
    endpoint: 'https://pbs.example.com/openrtb2/auction',
    syncEndpoint: 'https://pbs.example.com/cookie_sync',
    timeout: 500
  }]
});

Les bidders listés dans bidders passent par le serveur ; les autres restent côté client. La répartition la plus courante :

• dans le navigateur, les partenaires à forte valeur, ceux pour qui la reconnaissance de l’utilisateur pèse le plus sur les prix ;
• sur le serveur, la longue traîne : les partenaires qui gagnent rarement mais apportent de la concurrence.

Vous gardez l’essentiel de la valeur des identifiants tout en retirant du navigateur une bonne partie des requêtes. La répartition se revoit ensuite régulièrement, à partir des données de chaque partenaire. La documentation de Prebid précise un point à retenir : un même bidder ne peut pas figurer dans deux configurations serveur à la fois.

Et le consentement ?

Côté navigateur comme côté serveur, le signal de consentement recueilli par votre CMP doit accompagner chaque requête. Le module de gestion du consentement de Prebid.js lit ce signal, conforme à la version en vigueur du TCF de l’IAB Europe, et le transmet aux adaptateurs comme à Prebid Server, qui l’applique à son tour aux enchères et aux synchronisations d’identifiants. Lors d’une migration, vérifiez que chaque partenaire reçoit bien le même signal qu’avant : une chaîne de consentement perdue en route coûte des enchères et expose l’éditeur.

Comment décider

Cinq critères suffisent le plus souvent à orienter le choix.

1. La part du trafic mobile. Plus elle est forte, plus le coût de Prebid.js dans le navigateur se fait sentir. Si vous avez aussi des applications ou des pages AMP, Prebid Server devient incontournable pour ces supports.
2. Le nombre de bidders. Avec trois ou quatre partenaires, Prebid.js seul reste souvent raisonnable. Au-delà, déporter la longue traîne sur le serveur devient intéressant.
3. Vos Core Web Vitals actuels. Si vos pages sont déjà dans le vert et que la publicité n’y pèse pas, rien ne presse. Si l’INP se dégrade dès que les enchères démarrent, c’est un signal fort. Notre article sur le header bidding et les Core Web Vitals détaille les autres leviers, à activer souvent avant toute migration.
4. Votre équipe. Exploiter un serveur Prebid demande des compétences d’infrastructure et une astreinte. Sans elles, un hébergeur spécialisé est plus sûr.
5. Le budget d’hébergement. Le coût du serveur doit rester nettement inférieur au gain attendu, et ce gain se mesure, il ne se suppose pas.

Trois profils types illustrent ces critères :

• Un site B2B avec peu de partenaires, surtout consulté sur ordinateur : Prebid.js seul, avec un build limité aux adaptateurs utiles, suffit généralement.
• Un site de presse à forte audience mobile, avec une dizaine de bidders ou plus : l’hybride s’impose souvent, en commençant par déporter les partenaires qui gagnent le moins.
• Un éditeur présent sur le web, en application et en AMP : Prebid Server est de toute façon nécessaire pour les applications et l’AMP ; autant le mutualiser avec le web.

Mesurer avant et après

Une migration vers Prebid Server, totale ou partielle, se juge sur des chiffres. Avant tout changement, fixez les indicateurs :

• le revenu par session et par page vue, plus fiable que le CPM moyen, qui peut monter pendant que le volume baisse ;
• le taux d’enchères et le taux de victoire par partenaire ;
• le taux de timeouts et la latence des enchères ;
• les Core Web Vitals mesurés sur le terrain, en particulier l’INP et le LCP.

Puis testez en A/B : une partie des visiteurs garde l’ancienne configuration, l’autre reçoit la nouvelle. Comptez souvent deux à quatre semaines, selon votre trafic, pour que l’écart soit fiable et couvre les variations d’un jour à l’autre. Ne généralisez que si le revenu progresse sans dégrader l’expérience de lecture.

Conclusion

Prebid.js reste la base du header bidding sur le web : simple à faire évoluer, transparent, avec souvent les meilleurs taux de correspondance. Prebid Server allège les pages, ouvre les applications, l’AMP et la CTV, au prix d’une infrastructure à exploiter. Pour la plupart des éditeurs, la bonne réponse est hybride : les partenaires qui comptent dans le navigateur, la longue traîne sur le serveur, et des mesures pour arbitrer.

Le choix d’architecture n’est qu’une partie de la monétisation d’un site de contenu : notre offre pour les éditeurs et médias la relie au SEO technique et à l’UX de lecture. Si vous hésitez entre ces options ou voulez faire auditer votre configuration actuelle, découvrez notre expertise AdTech et monétisation ou parlons de votre projet.

Pour aller plus loin

• Prebid.js : présentation (documentation Prebid)
• Prebid Server : présentation (documentation Prebid)
• Module Prebid Server et s2sConfig (documentation Prebid)
• Liste des adaptateurs de bidders (documentation Prebid)