La plupart des media buyers font leurs débuts sur l’open web. Le modèle mental qui va avec (une URL de page, un cookie, un referrer, un domaine que l’on peut ajouter à une whitelist) y fonctionne plutôt bien. Puis ce même acheteur active l’inventaire des applications mobiles, et la moitié de ces signaux disparaissent sans bruit. Il n’y a pas d’URL. Il n’y a pas de cookie tiers. Le champ du domaine est vide, et à la place arrive un bundle ID qui ressemble à une suite de mots inversés.
Il ne s’agit pas d’une version réduite de l’achat web. L’inventaire in-app transite par une autre supply chain, porte d’autres identifiants, utilise des formats publicitaires qui n’ont jamais existé sur le web et se vérifie avec un autre fichier. Un DSP qui traite une impression in-app comme une impression web achètera les mauvaises choses, interprétera mal ses propres rapports et dépensera de l’argent sur des emplacements qu’il ne peut pas voir.
Ce guide explique le fonctionnement réel de la publicité programmatique in-app : ce que contient une bid request d’application, comment la couche SDK et médiation s’intercale entre un éditeur et votre plateforme, quels formats un DSP doit prendre en charge, comment l’identité et la mesure ont évolué depuis que les plateformes mobiles ont renforcé la protection de la vie privée, et ce que le propriétaire d’une plateforme doit configurer avant d’acheter du trafic applicatif à grande échelle.
Qu’est-ce que la publicité programmatique in-app ?
La publicité programmatique in-app désigne l’achat automatisé d’emplacements publicitaires au sein d’applications mobiles (jeux, applications d’actualité, utilitaires, applications de streaming) via des enchères en temps réel plutôt que par des ordres d’insertion directs. Les mécanismes sont les mêmes que partout ailleurs en programmatic : un emplacement devient disponible, une bid request le décrit, les acheteurs connectés répondent avec un prix, et l’enchère éligible la plus élevée remporte l’impression.
Ce qui change, c’est l’environnement. Une application mobile n’est pas un navigateur. Elle n’a ni stockage de cookies partagé, ni barre d’adresse, ni modèle objet de document (DOM) qu’une publicité pourrait inspecter. Tout ce dont la publicité a besoin (rendu, mesure, gestion des clics) doit être fourni par du code que l’éditeur a compilé dans l’application elle-même. C’est pourquoi le kit de développement logiciel (SDK) est la caractéristique déterminante de ce canal.
L’enchère sous-jacente suit toujours la même séquence que celle décrite dans notre guide sur le fonctionnement du real-time bidding. Si vous comprenez une enchère OpenRTB sur le web, vous comprenez déjà quatre-vingt-dix pour cent de l’enchère in-app. La part restante fait l’objet de cet article.
En quoi une bid request in-app diffère d’une bid request web
Dans OpenRTB, une bid request décrit son inventaire à l’aide soit d’un objet site, soit d’un objet app. Elle ne doit jamais contenir les deux. C’est cette seule bifurcation qui indique à votre bidder dans quel univers il achète, et presque toutes les différences pratiques en découlent.
L’objet app identifie l’application par son bundle ID (le nom de package sur Android ou l’identifiant numérique App Store sur iOS), complété par une URL de store, un nom d’application et un bloc éditeur. À la place d’une URL de page et d’un referrer, votre logique de ciblage et de blocage doit s’appuyer sur le bundle. À la place d’un cookie, l’appareil est identifié par un identifiant publicitaire réinitialisable transmis dans l’objet device, lorsque l’utilisateur l’a autorisé.
| Signal | Requête open web | Requête in-app |
| Objet d’inventaire | site | app |
| Identifiant principal | Domaine et URL de page | Bundle ID et URL de store |
| Identifiant utilisateur | Cookie ou identifiant first-party | Identifiant publicitaire (IFA), lorsqu’il est autorisé |
| Qualité de la localisation | Généralement déduite de l’IP | Peut provenir de l’appareil, avec consentement |
| Couche de rendu | Navigateur | SDK de l’éditeur et conteneur MRAID |
| Fichier de vérification des vendeurs | ads.txt sur le domaine | app-ads.txt sur le site du développeur |
| Formats courants | Display, vidéo, native | Interstitiel, rewarded, playable, native, bannière |
Côté achat, deux champs méritent une attention particulière. Le premier est device.lmt, l’indicateur de limitation du suivi publicitaire : lorsqu’il est activé, l’utilisateur a refusé la publicité personnalisée, et tout segment d’audience associé à cet appareil doit être ignoré, et non discrètement réutilisé. Le second est app.bundle, car un bundle mal formé ou incohérent est le signal le plus fréquent d’un trafic applicatif falsifié.
La supply chain in-app : SDK, médiation et exchange
Sur le web, un éditeur peut ajouter un partenaire de demande en collant un tag. Dans une application, ajouter de la demande impliquait historiquement d’intégrer un SDK supplémentaire et de publier une nouvelle version de l’application après validation par le store. Cette friction a façonné tout le canal, et c’est pourquoi une couche intermédiaire, la médiation, s’est imposée comme standard.
Une plateforme de médiation est intégrée à l’application sous la forme d’un seul SDK et gère toutes les sources de demande connectées derrière elle. Les premières solutions de médiation fonctionnaient en waterfall hiérarchisé, en appelant les réseaux un par un selon leur prix moyen historique. Les configurations modernes utilisent désormais l’in-app bidding, qui sollicite simultanément toutes les sources connectées pour qu’elles enchérissent sur la même impression. C’est la même évolution structurelle que celle décrite dans notre comparatif header bidding vs waterfall.
Du point de vue de votre DSP, la conséquence pratique est la distance. Entre l’application et votre bidder, il peut y avoir une plateforme de médiation, une supply-side platform et un ou plusieurs revendeurs, chacun prélevant une commission et chacun pouvant ajouter ou perdre du signal en cours de route. Raccourcir et auditer cette chaîne est toute la raison d’être de la supply path optimization, et c’est encore plus important en in-app que sur le web, car la chaîne y est généralement plus longue.
La supply chain détermine aussi ce que vous pouvez imposer. Une connexion directe à un SSP vous permet de négocier un flux propre au niveau du bundle et de tenir quelqu’un responsable de sa qualité. Un flux revendu au quatrième intermédiaire vous offre rarement l’un ou l’autre. Notre checklist sur la connexion de SSP à votre DSP s’applique ici intégralement, avec un ajout : demandez explicitement si le flux provient d’un inventaire applicatif direct ou agrégé.
Les formats publicitaires in-app qu’un DSP doit prendre en charge
L’inventaire applicatif est guidé par les formats, bien plus que le display web. Les jeux, en particulier, se monétisent grâce à des emplacements plein écran et à récompense, et une plateforme qui ne diffuse que des bannières se retrouvera exclue de la majeure partie de l’inventaire à forte valeur avant même que l’enchère ne commence.
- Bannière. Petits emplacements fixes ancrés en haut ou en bas de l’écran. Coût faible, volume élevé, et rendu via le conteneur MRAID plutôt que dans une simple iframe.
- Interstitiel. Une unité plein écran affichée lors d’une pause naturelle, par exemple entre deux niveaux d’un jeu ou après un article. Attention plus forte, prix plus élevé et exigences créatives plus strictes.
- Vidéo rewarded. L’utilisateur choisit de regarder une vidéo en échange de monnaie virtuelle ou d’une vie supplémentaire. Les taux de complétion sont élevés car l’échange est explicite, et le format est dominé par l’inventaire gaming.
- Native. Une publicité affichée avec la mise en page et le style propres à l’application, assemblée à partir d’éléments distincts (titre, image, call-to-action) plutôt que d’une créa fixe unique.
- Playable. Une courte démo interactive, le plus souvent utilisée pour les campagnes d’installation d’applications, diffusée sous la forme d’une créa interactive autonome.
Deux standards techniques portent l’essentiel de ces formats. MRAID définit la manière dont une créa rich media communique avec le SDK hôte : comment elle s’étend, se ferme ou ouvre un lien de redirection. VAST définit la manière dont une créa vidéo et ses événements de tracking sont décrits. Un DSP qui achète de l’inventaire applicatif a besoin des deux, ainsi que de la structure des éléments native, faute de quoi une grande partie de ses réponses sera tout simplement rejetée pour incompatibilité.
La prise en charge des formats change aussi la lecture des performances. Une complétion de vidéo rewarded n’est pas comparable à une vue de bannière, et en faire la moyenne dans un chiffre global masque le format qui fonctionne réellement. Ventiler le win rate, le CPM et les conversions par format constitue le découpage minimal utile pour le reporting des campagnes in-app.
Identité et mesure dans les applications
Les applications n’ont jamais utilisé de cookies tiers. Elles s’appuyaient sur un identifiant publicitaire fourni par la plateforme : l’IDFA sur iOS et le Google Advertising ID sur Android. Tous deux sont réinitialisables par l’utilisateur et sont liés à l’appareil plutôt qu’au navigateur, ce qui rendait historiquement le ciblage in-app plus stable que le ciblage web, et non l’inverse.
Tout a changé avec App Tracking Transparency. Depuis iOS 14.5, une application doit demander l’autorisation de l’utilisateur avant d’accéder à l’IDFA pour le suivi inter-applications, et sans cette autorisation, l’identifiant n’est pas disponible. Android a évolué dans une direction similaire avec son propre mécanisme de désactivation et ses travaux sur la Privacy Sandbox. Résultat : un volume important de trafic applicatif est réellement anonyme au niveau de l’appareil.
La mesure s’est adaptée grâce à des frameworks d’attribution gérés par les plateformes (SKAdNetwork d’Apple, puis son successeur AdAttributionKit), qui remontent les conversions d’installation sous une forme agrégée et différée au lieu d’exposer un parcours clic-installation au niveau de l’utilisateur. Pour un acheteur, cela signifie que les données de performance des campagnes d’installation arrivent plus tard et sont moins granulaires que les données de conversion web, et que le pacing des campagnes doit tolérer ce décalage.
La réponse pratique ne consiste pas à courir après l’identifiant manquant, mais à s’appuyer sur les signaux qui subsistent : le bundle, l’emplacement, le format, la zone géographique, l’heure de la journée et vos propres données de conversion first-party. L’optimisation contextuelle et au niveau de l’inventaire fait désormais l’essentiel du travail en in-app, et c’est l’une des raisons pour lesquelles maîtriser la logique d’enchère est essentiel : vous pouvez pondérer vous-même ces signaux au lieu d’accepter le modèle figé d’un fournisseur.
Vérifier l’inventaire applicatif : app-ads.txt et hygiène des bundles
L’inventaire applicatif présente un schéma de fraude spécifique : l’usurpation de bundle ID. Une application de faible valeur, voire inexistante, se fait passer pour une application populaire, et l’acheteur qui cible cette application populaire paie un prix premium pour une impression qui n’a jamais eu lieu là où elle le prétendait. Comme l’acheteur ne peut pas ouvrir une URL pour consulter la page, la supercherie est plus difficile à repérer manuellement que sur le web.
La réponse du secteur est app-ads.txt. Le développeur publie un fichier de vendeurs autorisés sur le domaine indiqué dans la fiche de l’application sur le store, et tout acheteur peut récupérer ce fichier pour confirmer que le vendeur qui propose l’impression est bien autorisé à la vendre. Le fonctionnement de ce fichier, ainsi que celui du fichier sellers.json qui complète la chaîne dans l’autre sens, est détaillé dans notre article sur ads.txt, app-ads.txt et sellers.json.
Au-delà du fichier, quelques vérifications permettent de détecter l’essentiel du reste. Confirmez que le bundle existe bien dans le store concerné. Comparez le nom d’application déclaré avec le bundle. Surveillez un même bundle qui apparaîtrait chez un nombre invraisemblable de vendeurs sans lien entre eux. Et considérez les requêtes dont le bundle est absent ou mal formé comme non achetables, plutôt que comme du trafic mobile générique.
Ce qu’il faut configurer avant d’acheter du trafic applicatif à grande échelle
Activer l’inventaire applicatif relève d’un travail de configuration, pas d’un simple interrupteur. La liste ci-dessous suit l’ordre qui génère généralement le moins de mauvaises surprises.
- Séparez les campagnes in-app et web. Formats différents, identifiants différents, benchmarks différents. Les mélanger rend les deux illisibles.
- Activez les formats que vous pouvez réellement diffuser. Vérifiez de bout en bout la prise en charge de MRAID, de VAST et des éléments native avant d’enchérir sur ces emplacements, et non après.
- Activez la vérification app-ads.txt. Faites-en une condition d’enchère, et non un rapport post-campagne.
- Commencez par une allowlist de bundles. Achetez d’abord un ensemble d’applications connues, identifiez ce qui performe, puis élargissez. Un ciblage ouvert sur tout l’inventaire applicatif est la manière la plus coûteuse de constituer une blocklist.
- Définissez des plafonds de fréquence par appareil, et non par cookie. La logique de fréquence in-app repose sur l’identifiant publicitaire, et elle doit se dégrader proprement lorsque cet identifiant est absent.
- Accordez aux campagnes d’installation une fenêtre de mesure plus longue. L’attribution agrégée remonte tardivement ; juger un premier jour sur les données du jour même vous induira en erreur.
- Ventilez vos rapports par bundle et par supply path. Le bundle vous indique ce que vous avez acheté ; le path vous indique ce que vous avez payé pour l’obtenir.
Chaque point de cette liste est plus simple à mettre en œuvre lorsque la plateforme vous appartient. Sur un seat loué, la prise en charge des formats, les règles de vérification et la logique d’enchère se limitent à ce que le fournisseur a décidé de rendre accessible. Sur une plateforme en propre, ce sont des paramètres que vous maîtrisez, et l’achat in-app est précisément le canal où ces paramètres déterminent si vos dépenses portent leurs fruits.
Prêt à acheter de l’inventaire applicatif sur votre propre DSP ?
AdTech Europe fournit la technologie de demand-side platform utilisée par des agences, des ad networks et des équipes d’achat média qui préfèrent posséder leur infrastructure plutôt que louer un accès à celle d’un autre. Toutes les offres incluent une montée en charge du QPS illimitée, une personnalisation en marque blanche et l’accès à plus de 1 000 intégrations SSP couvrant le web, les applications et les canaux émergents : l’inventaire applicatif fait donc partie intégrante de la plateforme, et non d’une option à négocier séparément.
En septembre 2026, le White Label DSP est proposé à 500 $ par mois, sans frais d’installation et avec un contrat sans engagement de durée, mensuel, déployé en 24 heures. Une DSP License coûte 25 000 $ en paiement unique, et une DSP Acquisition avec propriété complète du code source coûte 50 000 $ en paiement unique ; les deux sont payables en cinq mensualités et déployées en cinq à sept jours ouvrés. Les informations à jour sont toujours disponibles sur la page tarifs.
Si vous prévoyez d’intégrer l’inventaire applicatif à votre mix d’achat et souhaitez passer en revue les formats, la vérification de l’inventaire et la configuration du bidder au regard de vos propres campagnes, vous pouvez planifier un rendez-vous de stratégie programmatique avec l’équipe.
FAQ
Qu’est-ce que la publicité programmatique in-app ?
La publicité programmatique in-app désigne l’achat automatisé d’emplacements publicitaires au sein d’applications mobiles via des enchères en temps réel. Les mécanismes d’enchère sont identiques au reste du programmatic, mais l’inventaire est décrit par le bundle ID de l’application au lieu d’une URL de page, et la publicité est affichée par un SDK intégré à l’application plutôt que par un navigateur.
En quoi une bid request in-app diffère-t-elle d’une bid request web ?
Une requête in-app contient un objet app OpenRTB au lieu d’un objet site. Concrètement, cela signifie un bundle ID et une URL de store à la place d’un domaine et d’une URL de page, un identifiant publicitaire de l’appareil à la place d’un cookie, et des signaux de format pour les unités interstitielles, rewarded ou playable que l’open web n’utilise pas.
Qu’est-ce qu’app-ads.txt et pourquoi est-ce important pour l’achat in-app ?
App-ads.txt est un fichier publié sur le site web du développeur de l’application, qui liste les vendeurs autorisés à commercialiser l’inventaire de cette application. Les acheteurs l’utilisent pour confirmer que celui qui propose une impression in-app a bien le droit de la vendre, ce qui constitue la principale protection contre l’usurpation de bundle ID.
Peut-on encore cibler des audiences dans les applications depuis App Tracking Transparency ?
Le ciblage d’audience au niveau de l’appareil ne fonctionne que si l’utilisateur a donné son autorisation et que l’identifiant publicitaire figure dans la requête. Pour le reste du trafic applicatif, le ciblage repose sur des signaux contextuels et liés à l’inventaire, comme le bundle, l’emplacement, le format, la zone géographique et l’horaire, complétés par vos propres données de conversion first-party.
Pourquoi un DSP doit-il prendre en charge MRAID et VAST pour l’inventaire applicatif ?
MRAID définit la manière dont une créa rich media interagit avec le SDK de l’éditeur, et VAST définit la manière dont les créas vidéo et leurs événements de tracking sont décrits. Sans ces deux standards, une grande partie des emplacements in-app rejetteront ou ignoreront votre créa, et ces bid responses ne se transformeront jamais en impressions diffusées.
Qu’est-ce que la médiation dans la publicité sur applications mobiles ?
La médiation est une couche intégrée à l’application qui gère plusieurs sources de demande via un seul SDK, ce qui évite à l’éditeur d’intégrer chaque partenaire séparément. Les anciennes solutions de médiation fonctionnaient en waterfall hiérarchisé ; l’in-app bidding moderne sollicite toutes les sources connectées pour qu’elles enchérissent simultanément sur la même impression.
Faut-il posséder son propre DSP pour acheter de l’inventaire in-app ?
Non, mais en être propriétaire change ce que vous pouvez maîtriser. Sur une plateforme en propre, vous définissez vous-même la prise en charge des formats, les règles de vérification de l’inventaire, les allowlists de bundles et la logique d’enchère, au lieu de composer avec la configuration qu’un seat loué veut bien vous proposer.
