Ad server pour éditeurs et places de marché : utiliser Google Ad Manager, prendre une licence ou construire le vôtre

Un ad server est le logiciel qui décide quelle publicité remplit un espace sur votre site ou votre application, puis compte le résultat. Vous pouvez utiliser Google Ad Manager, payer pour un ad server hébergé comme AdButler ou Kevel, exploiter un logiciel open source comme Revive Adserver, ou construire le vôtre. Le choix dépend surtout de qui fixe les règles de sélection de la publicité et de qui détient les données brutes de ce qui a été diffusé. Google modifie aussi, à partir du 17 février 2027, la façon dont Ad Manager compte les bannières : les éditeurs qui l'utilisent doivent donc vérifier leurs contrats fondés sur les impressions avant cette date.

À quoi sert un ad server ?

Chaque fois qu'une page ou une application a un espace publicitaire à remplir, elle demande à l'ad server quoi afficher. L'ad server écarte les publicités qui ne respectent pas leur ciblage ou qui ont atteint leur plafond de fréquence, et en choisit une parmi les autres selon la priorité et le prix. Il enregistre ensuite l'impression, c'est-à-dire une publicité comptée comme diffusée une fois. Cet enregistrement devient le rapport qu'un éditeur envoie aux annonceurs, et souvent la base de la facture.

Google Ad Manager donne à chaque type de line item (une réservation à l'intérieur de l'ad server) un numéro de priorité, et sa page d'aide dit « Plus le numéro est bas, plus la priorité est élevée. » Un line item Sponsorship, vendu comme une part du trafic, se situe à 4. Les line items Standard, vendus comme un nombre fixe d'impressions, reçoivent 6, 8 ou 10, et les line items House, qui portent vos propres promotions, reçoivent 16. Toutes les sources de cet article ont été ouvertes le 9 novembre 2026.

En quoi un ad server diffère-t-il d'une SSP ou d'une DSP ?

Une demand-side platform (DSP) achète de l'espace publicitaire pour les annonceurs, et une supply-side platform (SSP) propose l'espace publicitaire d'un éditeur à de nombreux acheteurs à la fois. L'ad server se situe au plus près de l'éditeur et, dans la plupart des configurations, a le dernier mot sur un espace donné, y compris sur les accords que vos propres commerciaux ont signés avec des annonceurs.

Dans le header bidding, la page demande des enchères à plusieurs SSP puis appelle l'ad server. Prebid.org, qui publie un logiciel de header bidding gratuit, dit qu'il est « le plus souvent utilisé comme bibliothèque de header bidding », et décrit ainsi cette configuration : « Prebid collecte les enchères avant l'appel à l'ad server, et l'ad server prend la décision finale. » Il ajoute que Prebid peut aussi servir de couche de décision sur la page et choisir lui-même la publicité gagnante. Ad Manager permet aux acheteurs des enchères propres à Google de concurrencer vos autres réservations sur le CPM, le prix pour mille impressions. Sa page d'aide dit qu'Ad Exchange ou AdSense « ne diffuseront que s'ils peuvent offrir un CPM supérieur à vos autres line items Ad Manager ».

Les annonceurs exploitent souvent un second ad server qui leur est propre pour suivre où leurs publicités ont été diffusées, si bien qu'une même campagne produit en général deux séries de chiffres. Un exemple est Campaign Manager 360 de Google, que sa page d'aide décrit comme « un système de gestion publicitaire en ligne destiné aux annonceurs et aux agences. »

À quoi servent le ciblage, les plafonds de fréquence et le pacing ?

• Le ciblage décide qui peut voir une publicité. Les règles utilisent en général le pays, l'appareil et la rubrique du site, ainsi que les listes d'audience que vous détenez. Une place de marché peut cibler par terme de recherche ou par catégorie de produit.
• Les plafonds de fréquence limitent le nombre de fois qu'une même personne voit une publicité. La page d'aide d'Ad Manager dit : « Si un plafond temporel est défini sans identifiant disponible, le line item n'est pas éligible à la diffusion. » Elle « applique aussi par défaut les plafonds de fréquence en fonction du code diffusé », c'est-à-dire au moment où le code publicitaire part, que la publicité soit apparue ou non.
• Dans l'UE, les plafonds dépendent aussi du consentement. La documentation de Kevel dit : « Sous le RGPD, le capping de fréquence n'est pas activé pour les spectateurs de publicités de l'Union européenne, sauf si le consentement au suivi est transmis dans la requête. »
• Le pacing répartit une réservation sur ses dates. Ad Manager « détermine le rythme de diffusion du line item pour garantir qu'il atteint son objectif ». Son réglage Evenly applique un paramètre de 5 %, de sorte qu'un objectif de 1 000 impressions par jour vise 1 050 le premier jour.
• Quand un plafond ou un objectif de pacing se comporte de façon étrange, il vous faut les événements bruts pour comprendre pourquoi : demandez donc ce qui est enregistré pour chaque impression et pendant combien de temps.

Quelles sont les quatre façons d'obtenir un ad server ?

• Google Ad Manager. Google exploite le logiciel, et vous configurez les espaces publicitaires et les réservations dans son interface.
• Un ad server hébergé. Un prestataire tel qu'AdButler, Kevel, Broadstreet ou Equativ exploite le logiciel et facture un abonnement mensuel, selon les requêtes publicitaires ou dans le cadre d'un contrat.
• Un ad server open source. Vous installez un logiciel tel que Revive Adserver sur vos propres serveurs et vous le maintenez en service.
• Votre propre ad server. Vos développeurs, ou une société que vous engagez, écrivent le système qui prend la décision et compte le résultat.

Google Ad Manager est-il gratuit, et à quoi renonçons-nous en l'utilisant ?

La version gratuite d'Ad Manager ne coûte rien jusqu'à une limite mensuelle fixée selon le lieu où se trouve l'éditeur, et elle réunit les accords directs et la demande publicitaire propre à Google dans une seule décision. La page de facturation de Google indique 90 millions d'impressions hors vidéo pour les éditeurs situés aux États-Unis, au Canada, en Australie et en Nouvelle-Zélande. Le chiffre est de 200 millions dans une longue liste de pays qui comprend le Royaume-Uni, l'Allemagne et l'Inde, et de 150 millions ailleurs. Les blocs publicitaires vidéo ont « une limite de 800 000 impressions par mois quel que soit le lieu ». Hors inventaire d'applications et de vidéo, lorsque vous utilisez Google Publisher Tag, « Ad Manager facture à la fois les impressions remplies et non remplies », et Google précise que laisser Ad Exchange ou AdSense entrer en concurrence peut « garantir que les impressions monétisées par Ad Exchange ou AdSense ne sont pas facturées. »

Au-delà de ces seuils, Google exige que les éditeurs « concluent un contrat payant ». Selon la page de facturation, un éditeur qui continue de dépasser les limites sans ajouter de moyen de paiement peut être passé en mode lecture seule. Il peut ensuite être suspendu, « moment où la diffusion de vos publicités peut cesser. » Google indique que la section Facturation de votre compte Ad Manager affiche les grilles tarifaires de votre région : lisez-les avant de franchir la limite.

Vous renoncez aussi à une part de contrôle :

• Les données brutes coûtent en plus et expirent. Les fichiers Data Transfer d'Ad Manager « fournissent des données non agrégées, au niveau de l'événement, issues de vos campagnes publicitaires ». Ils « sont facturés en supplément », et « les fichiers Data Transfer de plus de 60 jours sont purgés d'Ad Manager. » Copiez-les régulièrement dans votre propre stockage.
• Google fixe les règles de sélection et de comptage des publicités. Le type et la priorité ne sont « qu'un facteur dans la sélection des publicités », et le système de Google décide du reste. La méthode de comptage change en février 2027.
• Partir demande du travail. Vos réservations et vos espaces publicitaires vivent dans Ad Manager et doivent être reconfigurés ailleurs, et le code publicitaire de vos pages doit être remplacé.

Que changent les procédures antitrust contre Google pour les éditeurs ?

Pour un éditeur qui choisit un ad server, la question pratique est de savoir si, et quand, les ad servers concurrents reçoivent des enchères d'AdX, la place de marché publicitaire de Google. Le communiqué de presse de la Commission européenne du 5 septembre 2025 annonçait une amende de 2,95 milliards d'euros contre Google, en citant « Favoriser sa propre place de marché AdX dans le processus de sélection des publicités géré par son ad server éditeur dominant DFP ». Google a déclaré le 14 novembre 2025 qu'il n'est pas d'accord avec la décision et qu'il « fera appel ». AdExchanger décrit DFP et AdX comme regroupés dans Google Ad Manager. Le ministère américain de la Justice a indiqué le 17 avril 2025 qu'un tribunal fédéral avait jugé que Google avait « violé le droit de la concurrence en monopolisant les marchés de la publicité numérique du web ouvert ».

PPC Land rapporte que le 2 septembre 2026 le juge américain a décidé que Google « ne sera pas tenu de vendre sa place de marché AdX ni son ad server éditeur DFP ». AdExchanger a rapporté le 16 septembre 2026 que « AdX doit aussi soumettre des enchères en temps réel aux ad servers éditeurs concurrents aux mêmes conditions que celles qu'il accorde à DFP ». Le 2 octobre 2026, les deux parties ont déposé un projet de jugement final où leurs désaccords restent signalés. AdExchanger a rapporté le 5 octobre 2026 que le ministère de la Justice veut le lien avec les ad servers concurrents dans les six mois suivant l'entrée en vigueur de l'ordonnance et que Google en veut douze, et qu'une fois le juge signataire, « un délai de 60 jours courra avant que quoi que ce soit ne prenne effet ». Une copie publique du registre du tribunal, mise à jour pour la dernière fois le 29 octobre 2026, ne liste aucun dépôt ultérieur. Digiday rapporte que Google entend contester la décision sur la responsabilité.

Quand un ad server hébergé convient-il mieux ?

Un ad server hébergé convient mieux lorsque le produit de Google dépasse ce dont une petite équipe commerciale a besoin, ou lorsque vos développeurs veulent placer les publicités par une API. Pour les petits éditeurs, la page d'accueil de Broadstreet parle de « The Ad Manager for Small Publishers », et sa page de tarifs indique un prix de départ de 299 $ par mois. Demandez à voir un rapport que vous enverriez réellement à un annonceur.

Comparez les prix options comprises. La page de tarifs d'AdButler dimensionne les offres selon les requêtes publicitaires et vend plusieurs fonctions séparément. Le ciblage figure comme option à partir de 275 $ par mois plus 0,005 $ de CPM, et Log Level Data, « des données granulaires sur chaque requête publicitaire », à partir de 1 100 $ par mois plus 0,01 $ de CPM.

Kevel fonctionne autrement. Elle est vendue sous forme d'API, c'est-à-dire un moyen pour votre propre logiciel d'appeler celui d'une autre entreprise : vos développeurs l'appellent donc depuis vos pages et vos applications. Sa page d'accueil dit « Kevel est fondé sur une API : tout est donc entièrement flexible pour s'adapter à votre expérience utilisateur. » La même page cite Kevel Console, qui, selon elle, « permet aux annonceurs de planifier, d'acheter et de gérer facilement leurs propres campagnes » : demandez donc quels écrans sont fournis avec le produit et lesquels votre équipe doit construire.

Kevel se présente comme une « plateforme de commerce media » et a des rubriques pour les détaillants, les places de marché, les fintechs, les marques de voyage et les applications de livraison : un éditeur de presse ou de contenus doit donc se demander si elle lui convient. Aucun prix n'apparaît sur cette page, attendez-vous à un échange commercial.

Un prestataire peut aussi exploiter une SSP à côté de l'ad server. La page éditeurs d'Equativ présente les deux ensemble dans son produit de télévision connectée. Demandez comment ils sont séparés, et confrontez la réponse à vos propres chiffres.

Quand un ad server open source se justifie-t-il ?

Un ad server open source se justifie lorsque vous avez déjà du personnel capable de l'entretenir. La page d'accueil de Revive Adserver indique « Téléchargement gratuit, utilisation gratuite. » Son dépôt GitHub affiche la « licence GPL-2.0 ».

La page de sécurité de Revive liste trois avis de sécurité en 2026 à ce jour, le dernier daté du 25 juin 2026. Quelqu'un doit appliquer chaque mise à jour et maintenir les serveurs en service pendant les pics de trafic. Si personne de votre côté ne le fera, le site de Revive propose une édition Hosted « à partir de 10 $ par mois ». Les prestataires hébergés ci-dessus sont l'autre choix.

Devrions-nous construire notre propre ad server ?

Oui, si la décision publicitaire fait partie de votre produit, comme dans une place de marché qui affiche des annonces sponsorisées dans les résultats de recherche. L'annonce et le résultat organique y sont classés ensemble : la décision doit donc utiliser vos propres données de pertinence. L'un quelconque de ces cas peut aussi justifier un développement :

• Votre espace publicitaire est inhabituel, par exemple des écrans dans vos propres lieux ou des emplacements dans un parcours de réservation, et les produits que vous avez testés ne savent pas le compter comme vos annonceurs en ont besoin
• Des contrats ou des règles sur les données gardent l'information qui sous-tend chaque décision à l'intérieur de vos propres systèmes
• Pour les publicités à l'intérieur de votre propre produit, les frais au volume que vous attendez dans deux ans coûteraient plus cher qu'une équipe pour exploiter votre propre système, astreintes et rapports audités compris

Les annonces sponsorisées ont aussi une voie intermédiaire. La documentation de Kevel décrit un modèle qu'elle appelle Auction-as-a-Service, « où vous déterminez quels produits ou annonces peuvent être affichés, et Kevel exécute l'enchère, le pacing, la gestion du budget, le capping de fréquence et le suivi sur cet ensemble. » L'article sur les retail media networks traite de cette configuration.

Évitez de construire pour économiser des frais de licence sur la publicité display et vidéo ordinaire d'un site web. Vous réécririez le flux de vente directe, le pacing, les prévisions et les rapports que les annonceurs contestent, et il vous faudrait encore un moyen d'atteindre les ad exchanges. Un litige de comptage est aussi une mauvaise raison, puisqu'un nouveau système ajoute un chiffre de plus à comparer. Les évolutions des navigateurs et de la protection de la vie privée continuent en outre d'arriver après le lancement, et chacune demande quelqu'un de votre côté pour la traiter.

Pourquoi les comptages d'impressions diffèrent-ils entre ad servers ?

Deux sociétés comptent la même campagne avec des systèmes différents, à des moments différents. Le point de référence est constitué des Desktop Display Impression Measurement Guidelines de l'Interactive Advertising Bureau (IAB) et du Media Rating Council (MRC), version 7.1 d'octobre 2017. Elles disent : « La publicité doit être chargée et au minimum commencer à s'afficher pour être comptée comme une impression publicitaire valide. » Compter au moment où la page est servie est « inacceptable pour compter les impressions publicitaires ».

Ces lignes directrices ne disent pas si quelqu'un aurait pu voir la publicité, et elles précisent que le begin-to-render « n'exige pas qu'une partie de la publicité soit visible ou affichée à l'écran ».

La visibilité (viewability) est une mesure distincte. Les Viewable Ad Impression Measurement Guidelines du MRC pour le desktop, version 2.0 d'août 2015, comptent une publicité display comme visible lorsqu'au moins 50 % de ses pixels sont à l'écran pendant une seconde continue, ou 30 % pour les publicités display de 242 500 pixels ou plus. Une publicité vidéo exige 50 % à l'écran pendant deux secondes continues. Le MRC a des lignes directrices distinctes pour le mobile. Convenez de laquelle des deux votre contrat vend.

La page d'aide de Google sur les écarts de reporting énumère des causes courantes, et elles valent quelle que soit la voie :

• Les règles de comptage diffèrent. « Les ad servers ont des méthodes différentes pour compter les impressions et filtrer les impressions invalides. » Les impressions invalides viennent de bots et d'autre trafic qui ne devrait pas être facturé.
• La création, c'est-à-dire le fichier de la publicité lui-même, met du temps à apparaître. « Le décalage entre une première requête de line item et l'apparition de la création peut conduire à des comptages différents. »
• Les bloqueurs de publicité peuvent arrêter une publicité « après qu'Ad Manager a déjà compté une impression. »
• Les rapports doivent couvrir les mêmes dates et le même fuseau horaire avant d'être comparés.
• Sur une petite campagne, quelques impressions peuvent ressembler à un écart important. « Un petit écart numérique peut donner un écart en pourcentage élevé si le line item a livré peu d'impressions au total. »

La même page dit que lorsqu'un ad server livre des line items hébergés par un tiers, « des écarts de campagne allant jusqu'à 20 % sont courants ». Avec le type de création à balise Campaign Manager 360, elle dit « Ad Manager coordonne le comptage des impressions pour réduire les écarts à moins de 2 %. » La page d'aide de Campaign Manager 360 donne la même fourchette : « Des écarts allant jusqu'à 20 pour cent sont considérés comme normaux. »

Que change le passage de Google au begin-to-render en février 2027 ?

À partir du 17 février 2027, la mesure des impressions de l'inventaire display dans Ad Manager et AdSense « passera de la méthodologie count-on-download (COD) à la méthodologie begin-to-render (BTR) », selon la page d'aide de Google. Le count-on-download enregistre une impression lorsqu'une publicité commence à se télécharger. Le begin-to-render attend que la création soit chargée et ait commencé à s'afficher. Les inventaires natif, application et vidéo sont déjà conformes : le changement concerne donc les bannières sur le web, le web mobile et la télévision connectée.

Google prévient : « vous pouvez constater une baisse du total des impressions display ». Le même trafic vous donnera alors moins d'impressions à vendre. Une réservation pour un nombre fixe d'impressions utilisera une plus grande part de votre trafic pour atteindre son objectif, et elle peut rester en deçà là où l'espace est limité. Avant de renouveler un contrat fondé sur les impressions, lancez le rapport que Google suggère, qui compare les impressions de votre ad server aux impressions begin-to-render, à partir du 12 août 2026.

Ce changement devrait réduire les écarts avec les acheteurs, puisque Google dit qu'il « est conçu pour réduire les écarts avec les impressions comptées par vos partenaires annonceurs et par les fournisseurs de mesure tiers ». Si vous utilisez un autre ad server, demandez à son prestataire quelle méthode il applique aujourd'hui.

Quel chiffre fait foi pour la facture ?

Le contrat tranche. L'IAB a publié de nouvelles conditions pour les achats publicitaires directs en mai 2026, et son Direct Buy Addendum version 1.0 dit que les parties « désignent la Controlling Measurement dans l'Ordre ». Si un ordre n'en nomme aucune, « l'ad server ou le système de mesure qui affiche la publicité fait office de Controlling Measurement pour la réconciliation et la facturation », sauf accord écrit contraire des parties.

Les anciennes Standard Terms and Conditions de la 4A's et de l'IAB, version 3.0 de 2010, sont toujours en ligne et couvrent les achats média d'un an ou moins. La section XIII de ce modèle donne la « Controlling Measurement » à un ad server certifié conforme aux lignes directrices de mesure du secteur. Si les deux sont conformes, c'est l'ad server tiers de l'annonceur qui fait foi, à condition qu'il fournisse à l'éditeur une « interface de reporting quotidienne automatisée ». Si aucun n'est conforme, ou si cette condition ne peut pas être remplie, c'est l'ad server de l'éditeur qui fait foi, sauf accord écrit contraire des parties.

Les deux modèles déclenchent une réconciliation lorsque les comptages diffèrent de plus de 10 % sur la période de facturation et que le comptage de référence est le plus bas. Ils divergent sur la suite. Dans la version 3.0, si la réconciliation échoue, l'agence peut traiter l'écart comme une sous-livraison ou payer sur le comptage de référence « plus un ajustement à la hausse de 10 % de la livraison. » L'addendum de 2026 ne fixe aucun chiffre : les parties peuvent convenir d'un ajustement, utiliser l'autre comptage ou traiter l'écart comme une sous-livraison. Votre propre contrat peut dire autre chose : nommez donc le comptage de référence dans chaque ordre et vérifiez que l'ad server que vous choisissez peut produire les rapports qu'il attend.

Que devons-nous demander à un prestataire ou à une société qui le construirait ?

• À quel moment votre système compte-t-il une impression, et cela suit-il les lignes directrices de l'IAB et du MRC pour chaque format que nous vendons ?
• Un organisme extérieur a-t-il audité votre comptage, et pouvons-nous voir le rapport actuel ?
• Pouvons-nous exporter les enregistrements au niveau de l'événement, à quel coût, et combien de temps les conservez-vous ?
• Que fait un plafond de fréquence lorsqu'une personne n'a pas d'identifiant ou n'a pas donné son consentement ?
• Comment filtrez-vous le trafic invalide, et comment verrions-nous ce qui a été retiré ?
• Si vous exploitez aussi une SSP ou vendez de la demande publicitaire, comment empêchez-vous cette activité d'influencer la publicité qui l'emporte ?
• Pouvez-vous nous montrer cela fonctionner aujourd'hui sur un site ou une application en production ?

Où se situe amBrain ?

amBrain publie ce blog et propose ce type de travail. Dans ses propres termes : « amBrain construit des ad servers : ciblage, capping de fréquence et reporting. » Une seconde ligne concerne le comptage : « amBrain construit des pipelines d'analytics d'événements pour l'ad tech : collecte, traitement et reporting des événements d'impression et de clic. »

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 et ne décrit aucun travail pour un client. Les lignes ci-dessus ne nomment aucun client, et rien ici n'indique qu'amBrain ait construit un ad server pour une société. L'article ne donne aucun prix ni délai d'amBrain et ne revendique aucune relation avec les prestataires qu'il cite. Google, Prebid.org, Equativ, Broadstreet, AdButler, Kevel, Revive Adserver, l'IAB, le MRC, la 4A's, la Commission européenne et le ministère américain de la Justice sont cités à partir de leurs propres pages, le dépôt judiciaire à partir d'une copie publique du registre du tribunal, et PPC Land, AdExchanger et Digiday comme articles de presse.

Ce n'est pas non plus un conseil juridique. Faites lire les contrats des prestataires et les conditions publicitaires par un avocat, et vérifiez où en sont les procédures contre Google, avant de signer. Si amBrain figure sur votre liste, posez-lui les mêmes questions qu'à n'importe quelle autre société.