Médiation publicitaire mobile pour vos applications ou votre ad network : utiliser une plateforme de médiation, en prendre une sous licence ou construire la vôtre

La médiation publicitaire est du code intégré à une application qui demande une publicité à plusieurs sources publicitaires chaque fois que l'application a un emplacement à remplir. Elle cherche ensuite à afficher celle qui rapporte le plus. Une source publicitaire est tout ad network ou ad exchange capable de fournir des publicités. Un éditeur d'applications ou un ad network in-app peut utiliser une plateforme prête à l'emploi comme Google AdMob, AppLovin MAX ou Unity LevelPlay. Il peut aussi prendre sous licence le produit d'un fournisseur et l'exploiter sous sa propre marque (marque blanche), ou construire sa propre couche de médiation. Le choix dépend surtout de ce que vous avez besoin de posséder. Il dépend aussi de la capacité de votre équipe à tenir à jour, dans chaque application, un SDK, le paquet de code qui affiche les publicités.

Que fait la médiation à l'intérieur d'une application ?

Une application affiche des publicités au moyen d'un SDK (software development kit, kit de développement logiciel), un paquet de code que les développeurs ajoutent à l'application. Avec la médiation, un seul SDK pilote l'ensemble. Il appelle plusieurs sources publicitaires via des adaptateurs, de petits morceaux de code qui le relient au SDK propre à chaque réseau.

Le centre d'aide AdMob de Google le formule ainsi : « La médiation vous permet de gérer en un seul endroit les sources publicitaires utilisées pour diffuser des publicités dans vos applications. » Unity présente LevelPlay comme « une solution de monétisation qui permet aux développeurs d'applications de gérer et d'optimiser plusieurs ad networks avec un seul SDK. » Toutes les sources de cet article ont été consultées le 6 novembre 2026.

En quoi le waterfall et l'in-app bidding diffèrent-ils ?

Le waterfall (ou cascade) est la méthode la plus ancienne. L'éditeur classe les sources publicitaires par eCPM, le revenu pour mille publicités affichées, et le SDK les interroge l'une après l'autre jusqu'à ce que l'une d'elles renvoie une publicité. Le guide d'AdMob indique : « La médiation en waterfall appelle les sources publicitaires une par une en fonction de l'eCPM moyen que vous définissez, et non de ce que la source publicitaire est prête à payer. »

L'in-app bidding interroge toutes les sources d'enchères au même moment, et chacune propose un prix pour cette publicité précise. Le même guide indique : « Les sources d'enchères placent des offres en temps réel et s'affrontent dans une enchère unique, tandis que les sources du waterfall sont appelées une par une dans l'ordre de leur eCPM, que vous fixez vous-même. »

Beaucoup de configurations combinent les deux. Dans la configuration hybride d'AdMob, l'offre gagnante prend place dans le waterfall « en fonction de la valeur de l'eCPM », et les sources du waterfall classées au-dessus d'elle sont appelées en premier.

AppLovin qualifie l'enchère de MAX d'enchère « au premier prix », ce qui signifie que le gagnant paie le montant de son offre. Les offres arrivent « via le protocole OpenRTB 2.5 ». OpenRTB est le standard de bid request de l'IAB Tech Lab, l'organisme à but non lucratif qui rédige les standards techniques de la publicité numérique. Les offres doivent arriver dans un délai appelé tmax, et le « serveur d'enchères MAX les fusionne avec les sources de demande hors enchères du waterfall de l'éditeur. »

Quelles sont les trois façons de mettre en place la médiation ?

• Utiliser une plateforme de médiation prête à l'emploi. Vous ajoutez à vos applications son SDK et un adaptateur pour chaque source publicitaire, et vous configurez le waterfall et les enchères dans son tableau de bord. C'est la plateforme qui organise l'enchère.
• Prendre sous licence un produit en marque blanche. Un fournisseur vous concède sous licence son SDK de médiation et le serveur qui va avec, à votre marque. Les éditeurs installent le SDK sous votre nom, et le fournisseur maintient le code.
• Construire votre propre couche. Votre équipe, ou une société que vous engagez, écrit le SDK, les adaptateurs et le serveur d'enchères, en général sur des standards ouverts comme OpenRTB. Le code vous appartient, et c'est vous qui l'exploitez.

Les voies peuvent se combiner. Prebid Mobile, que Prebid.org présente comme « une bibliothèque open source pour iOS et Android », cite AdMob et MAX parmi les plateformes de médiation qu'il prend en charge. Il obtient ses offres d'un Prebid Server, que présente l'article sur la construction de votre propre supply-side platform (SSP). Un SSP est le système qui propose l'espace publicitaire d'un éditeur aux acheteurs.

Quand une plateforme de médiation prête à l'emploi suffit-elle ?

Utilisez une plateforme prête à l'emploi quand la plupart de ces conditions sont remplies :

• Vous publiez vos propres applications, et le revenu publicitaire compte davantage pour vous que la propriété d'une technologie publicitaire
• Personne dans votre équipe ne peut maintenir un SDK au fil des nouvelles versions d'iOS et d'Android
• Les ad networks que vous voulez ont déjà des adaptateurs pour la plateforme

En contrepartie, vous acceptez les règles de la plateforme. C'est elle qui décide du fonctionnement de l'enchère et des bidders qui peuvent y participer, et son SDK évolue selon son propre calendrier. La société qui organise l'enchère peut aussi y vendre des publicités. Le 6 novembre 2026, la page MAX d'AppLovin indiquait : « Chaque réseau, AppLovin compris, est en concurrence à armes égales dans l'enchère unifiée. » Confrontez cette affirmation du fournisseur à vos propres données de revenus par source publicitaire.

Un ad network peut malgré tout atteindre les éditeurs qui passent par une plateforme : AdMob propose des événements personnalisés (custom events), qui permettent à un éditeur d'ajouter « une source publicitaire que la médiation AdMob ne prend pas en charge ».

Quand un produit sous licence ou en marque blanche est-il pertinent ?

Les SDK de médiation en marque blanche s'adressent aux sociétés qui exploitent une plateforme publicitaire, comme un ad network in-app ou un SSP qui veut que les éditeurs lui envoient directement leurs demandes publicitaires. Optez pour cette solution quand :

• Les éditeurs doivent installer un SDK portant votre nom, pour que leurs demandes publicitaires arrivent d'abord sur votre plateforme
• Vous avez du personnel pour recruter et accompagner des éditeurs, mais pas d'ingénieurs pour écrire et maintenir un SDK

Teqblaze, un fournisseur ad tech, montre comment ces produits sont présentés. Sa page SDK décrit l'offre comme « un kit de développement logiciel à votre marque » et la dit « conçue pour les entreprises qui veulent maîtriser la monétisation publicitaire mobile sans développer un SDK de zéro. » Un billet de son blog, publié en juin 2024, indique que les éditeurs peuvent « envoyer des requêtes directement à la plateforme de la solution en marque blanche ». La page SDK n'affiche aucun prix. Ce sont les affirmations du fournisseur lui-même.

La marque est à vous, mais le code reste celui du fournisseur. Xcode est l'outil d'Apple pour construire des applications. Quand une application adopte une nouvelle version d'un SDK tiers, Xcode vérifie « qu'elle a été signée par le même développeur » : demandez donc qui signe votre SDK. Si le fournisseur cesse de mettre à jour le SDK, chaque éditeur doit publier une mise à jour de son application pour s'en détacher.

Quand construire votre propre couche de médiation en vaut-il la peine ?

Construisez la vôtre quand au moins l'une de ces conditions est remplie :

• La médiation est ce que vous vendez, par exemple en tant qu'ad network qui organise des enchères dans les applications de nombreux éditeurs
• Il vous faut des règles que les plateformes testées ne savent pas appliquer, comme vos propres prix planchers pour chaque groupe d'utilisateurs. Un prix plancher est l'offre la plus basse que vous acceptez.
• Les frais et les partages de revenus coûtent désormais plus cher que ne coûterait une équipe qui exploite votre propre système
• Les données brutes de chaque impression (une publicité affichée une fois) doivent rester dans vos propres systèmes

Le travail continue après le lancement. Chaque réseau met régulièrement à jour son SDK, et l'adaptateur doit suivre. AdMob publie un nouvel adaptateur pour chaque nouvelle version du SDK d'un réseau, « après l'avoir testé avec ce nouveau SDK ». Avec votre propre couche, c'est votre équipe qui fait ces tests, et chaque réseau doit accepter de travailler avec vous dans le cadre de son propre contrat.

Que possédons-nous sur chaque voie ?

Vérifiez quatre points avant de signer ou de commencer à construire.

• Les données d'impressions et de revenus. Les trois plateformes remontent le revenu de chaque impression, et deux d'entre elles ne le conservent que pendant une durée limitée. Le SDK d'AdMob le transmet « lorsqu'une impression se produit », et un commentaire dans l'exemple de code de Google recommande de l'envoyer « directement à votre serveur d'analyse préféré, dans ce callback. » La User-Level Ad Revenue API d'AppLovin, son interface pour extraire ces données, « a une fenêtre de requête de 45 jours. » Unity garde les données de LevelPlay au niveau de l'impression, pour chaque date, « disponibles pendant 14 jours seulement. » Copiez-les chaque jour dans votre propre stockage. Avec un fournisseur en marque blanche, obtenez par écrit que les logs bruts sont à vous et exportables à tout moment.
• Les relations avec les sources publicitaires. La page de configuration de Unity indique : « Vous devez avoir un compte actif auprès de ce réseau pour diffuser son inventaire publicitaire dans votre application. » Dans MAX, les bidders envoient leurs offres au serveur d'enchères d'AppLovin. Demandez à chaque plateforme quelles connexions restent les vôtres si vous partez. Avec un produit en marque blanche, vérifiez au nom de qui sont signés les contrats avec les acheteurs. Avec votre propre développement, c'est vous qui signez chacun d'eux.
• Le SDK dans vos applications. Une plateforme est propriétaire de son SDK et de ses mises à jour, et un fournisseur en marque blanche est propriétaire de son code. Si vous construisez, le code peut vous appartenir, tout comme chaque mise à jour et chaque fichier de confidentialité.
• Le coût d'un changement. Les règles de validation de l'App Store (App Review Guidelines) interdisent aux applications de « télécharger, installer ou exécuter du code qui introduit ou modifie des fonctionnalités de l'application ». Le règlement de Google Play précise qu'une application « ne peut pas se modifier, se remplacer ou se mettre à jour par une autre méthode que le mécanisme de mise à jour de Google Play. » Un nouveau SDK de médiation n'atteint les utilisateurs qu'avec une nouvelle version de l'application, et ceux qui ne font pas la mise à jour gardent l'ancien.

Certains changements ne demandent aucune mise à jour de l'application. L'ordre du waterfall et les réglages des enchères se trouvent dans le tableau de bord de la plateforme. Le fichier app-ads.txt, qui liste toutes les sociétés autorisées à vendre l'espace publicitaire d'un éditeur, se trouve sur le site web du développeur. AdMob le rappelle aux éditeurs : « Si vous utilisez un autre ad network, pensez à ajouter ce réseau à votre fichier app-ads.txt. »

Quelles obligations envers les stores et en matière de confidentialité accompagnent tout SDK publicitaire ?

Ces obligations s'appliquent quelle que soit la voie. Apple indique : « Les développeurs sont responsables de tout le code inclus dans leurs applications. » Voici ce que disent les propres pages d'Apple et de Google :

• App Tracking Transparency (ATT). Sur iOS, Apple indique que « vous devez obtenir l'autorisation de l'utilisateur via le framework App Tracking Transparency (ATT) pour le suivre ou accéder à l'identifiant publicitaire de son appareil. » Apple définit le suivi comme le fait de relier des données de votre application à des données issues d'applications, de sites web ou de propriétés hors ligne d'autres sociétés « à des fins de publicité ciblée ou de mesure publicitaire ». Partager des données d'utilisateurs ou d'appareils avec des courtiers en données compte aussi comme du suivi.
• AdAttributionKit et SKAdNetwork. Ces frameworks d'Apple indiquent quelles publicités ont mené à des installations. La page d'Apple consacrée à SKAdNetwork indique désormais : « Utilisez AdAttributionKit pour les campagnes publicitaires d'applications sur l'App Store et sur les places de marché alternatives. » Les ad networks « s'enregistrent auprès d'Apple pour obtenir un identifiant d'ad network ». Apple précise aussi : « Seules les publicités des ad networks qui ont une entrée dans l'Information Property List de l'application peuvent faire l'objet d'une validation d'installation. » Cette liste est livrée dans l'application : un nouveau réseau implique donc une nouvelle version de l'application.
• Manifestes de confidentialité et signatures. Un manifeste de confidentialité (privacy manifest) est un fichier dans lequel une application ou un SDK déclare quelles données il collecte et pourquoi. Apple désigne nommément certains SDK. Quand vous soumettez une application qui contient l'un d'eux, vous devez inclure son manifeste de confidentialité. Si le SDK est ajouté sous forme de fichier binaire (du code déjà compilé plutôt que du code source), vous devez aussi inclure sa signature. Pour les autres SDK, Apple demande à leurs développeurs d'inclure un manifeste si, entre autres cas, le SDK « collecte des données sur la personne qui utilise des applications intégrant le SDK tiers » ou « contacte des domaines de suivi ».
• Les formulaires de confidentialité des stores. Apple demande vos pratiques en matière de confidentialité, « y compris les pratiques des partenaires tiers dont vous intégrez le code dans votre application », et cite les réseaux publicitaires parmi ces partenaires. Google indique que « tous les développeurs qui ont une application publiée sur Google Play doivent remplir le formulaire Sécurité des données (Data safety) ». Ce formulaire couvre les données « collectées et traitées via des bibliothèques ou des SDK tiers utilisés dans leurs applications. »
• Applications pour enfants. Google Play indique : « Si vous diffusez des publicités dans votre application et que votre audience cible n'inclut que des enfants, vous devez utiliser exclusivement des versions de SDK publicitaires autocertifiées pour les familles. » Les applications destinées à la fois aux enfants et à des utilisateurs plus âgés doivent filtrer par âge, par exemple avec un écran de saisie de l'âge neutre, qui demande l'âge sans suggérer de réponse. Ces applications ne peuvent montrer aux enfants que des publicités issues de versions de SDK publicitaires autocertifiées. Google exige que « les SDK publicitaires et les plateformes de médiation certifient eux-mêmes qu'ils sont adaptés aux enfants ». AdMob précise que ses sources d'enchères « ne prennent pas en charge la diffusion de publicités pour les applications ou les demandes publicitaires destinées aux enfants. » Apple indique que les applications de la catégorie Enfants « ne doivent pas inclure d'outils d'analyse tiers ni de publicité tierce ». Elle ajoute que la publicité contextuelle de tiers, c'est-à-dire des publicités choisies en fonction de ce que l'application affiche plutôt que de données sur l'utilisateur, « peut également être autorisée dans des cas limités ».

Les règles des stores changent, et le droit de la protection des données varie d'un pays à l'autre. Faites confirmer ces points par un avocat avant d'ajouter ou de changer un SDK publicitaire, en particulier dans les applications qu'utilisent des enfants.

Comment vérifier la visibilité et le trafic invalide ?

La visibilité indique si une publicité est apparue à l'écran à un endroit où une personne pouvait la voir. L'Open Measurement SDK (OM SDK) de l'IAB Tech Lab permet à des sociétés de mesure externes de contrôler les publicités dans les applications. L'IAB Tech Lab indique qu'il « confirme quand les publicités apparaissent à l'écran, quel pourcentage est visible et pendant combien de temps » et qu'il « facilite la vérification par des tiers du trafic invalide et des exigences des marques ».

Sur une plateforme, demandez lesquelles de vos sources publicitaires prennent en charge l'OM SDK. Sur votre propre SDK, c'est vous qui l'intégrez, et l'IAB Tech Lab propose une certification qui « vérifie que votre implémentation de l'OM SDK fonctionne avec les fournisseurs de mesure. »

Le trafic invalide désigne les affichages et les clics publicitaires qui ne proviennent pas d'un intérêt réel des utilisateurs. Le centre d'aide AdMob indique qu'il « couvre aussi bien le trafic intentionnellement frauduleux que les clics accidentels. » Deux articles précédents expliquent comment une plateforme publicitaire le filtre et pourquoi deux séries de rapports finissent par diverger.

Combien coûte chaque voie ?

Les prix dépendent du fournisseur et de votre volume. Comparez donc la façon dont chaque voie est facturée :

• Plateforme prête à l'emploi : vérifiez comment la plateforme gagne de l'argent. Le 6 novembre 2026, la page MAX d'AppLovin indiquait : « La médiation MAX est gratuite pour les éditeurs. Les réseaux qui participent aux enchères versent à AppLovin une commission sur le revenu publicitaire généré. » Elle ne précisait pas le montant de cette commission, et les pages d'AdMob et de LevelPlay consultées pour cet article ne mentionnaient pas de frais de médiation. Demandez ce qui est prélevé entre l'offre de l'annonceur et votre reversement, et par qui.
• Produit en marque blanche : des frais de mise en place ou de licence, un abonnement mensuel, un partage de revenus, ou une combinaison de ces formules. Demandez sur quelle base ce partage est calculé.
• Développement sur mesure : des ingénieurs pour le SDK, les adaptateurs et le serveur d'enchères. Après le lancement viennent les serveurs et le trafic, qui augmentent avec les demandes publicitaires, les personnes d'astreinte, la certification OM SDK et les mises à jour des adaptateurs.
• Quelle que soit la voie : le temps des développeurs pour tester chaque mise à jour de SDK avant la sortie d'une version de l'application, et la relecture juridique de vos déclarations en matière de confidentialité.

Un développement sur mesure coûte surtout avant l'affichage de la première publicité, alors que les partages de revenus grossissent avec chaque publicité que vous vendez.

Que demander à une société qui construirait ou intégrerait la médiation pour nous ?

• Comment les données brutes de revenus de chaque impression arriveront-elles dans notre propre stockage, et comment les rapprocherez-vous des rapports de chaque réseau ?
• Quels ad networks auront des adaptateurs au lancement, et qui met à jour chaque adaptateur quand un réseau publie un nouveau SDK ?
• Comment le SDK se comportera-t-il sur iOS quand une personne refuse le suivi, et que déclarera son manifeste de confidentialité ?
• Qui signe le SDK, et sous quel nom les éditeurs et les stores d'applications le verront-ils ?
• Le SDK prendra-t-il en charge l'OM SDK, et qui le mènera jusqu'à la certification de l'IAB Tech Lab ?
• Comment les publicités destinées aux enfants et aux utilisateurs d'âge inconnu respecteront-elles le règlement Familles de Google Play ?
• Pouvez-vous montrer cela en action dans une application disponible aujourd'hui sur les stores ?

Où se situe amBrain ?

amBrain publie ce blog. Trois de ses propres déclarations touchent au côté serveur des voies décrites ici. L'une indique : « amBrain construit des supply-side platforms (SSP) pour les éditeurs. » Une autre : « amBrain construit des ad servers : ciblage, capping de fréquence et reporting. » Une troisième : « amBrain construit des pipelines d'analytique 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 client. Les lignes d'amBrain citées plus haut ne mentionnent ni plateforme de médiation, ni SDK publicitaire mobile, ni adaptateur pour un quelconque ad network. L'article ne donne pas non plus de prix ni de délais d'amBrain. Google, AppLovin, Unity, Teqblaze, Prebid.org, Apple et l'IAB Tech Lab sont cités d'après leurs propres pages. L'article ne recommande aucun d'entre eux et n'affirme aucune relation avec l'un d'eux.

Ce n'est pas non plus un conseil juridique. Faites relire par un avocat les contrats avec les plateformes et les fournisseurs, ainsi que vos déclarations en matière de confidentialité, avant de signer ou de publier une mise à jour. Si amBrain figure sur votre liste restreinte, posez-lui les mêmes questions qu'à n'importe quelle autre société.