Chaque transaction programmatic repose sur une hypothèse simple : le vendeur qui propose l’impression est bel et bien autorisé à la vendre. Pendant la majeure partie de l’histoire du secteur, les acheteurs n’avaient aucun moyen fiable de vérifier cette hypothèse avant d’engager leurs budgets. Le domain spoofing, qui consiste pour des vendeurs frauduleux à usurper l’identité d’éditeurs premium, coûtait aux annonceurs des budgets bien réels, sans aucune possibilité de le détecter en temps réel.
Trois fichiers ont comblé cette lacune : ads.txt, app-ads.txt et sellers.json. Ensemble, ils permettent à un acheteur, ou au DSP qui enchérit pour son compte, de confirmer qu’un vendeur donné est autorisé à vendre l’inventaire d’un éditeur donné avant même de placer la moindre enchère. Aucun d’eux n’est compliqué une fois les éléments clairement posés, mais la terminologie se recoupe suffisamment pour que les propriétaires de DSP et les media buyers emploient souvent ces noms de manière interchangeable, alors que chaque fichier répond à une question différente.
Ce guide explique ce qu’est réellement chaque fichier, comment ils fonctionnent ensemble via l’objet supply chain d’OpenRTB, comment un propriétaire de DSP devrait les vérifier en pratique, et ce qui arrive aux campagnes qui font l’impasse sur cette vérification.
Qu’est-ce que ads.txt et pourquoi ce fichier existe-t-il ?
ads.txt signifie Authorized Digital Sellers (vendeurs numériques autorisés). Il s’agit d’un fichier texte brut qu’un éditeur de site web héberge à un emplacement fixe et prévisible : example.com/ads.txt. Le fichier répertorie toutes les entreprises autorisées à vendre l’inventaire publicitaire de cet éditeur en programmatic, à raison d’une ligne par vendeur autorisé.
L’IAB Tech Lab a lancé ads.txt en 2017 précisément pour mettre fin au domain spoofing, pratique par laquelle un vendeur frauduleux prétendait revendre l’inventaire d’un éditeur reconnu qui ne l’avait en réalité jamais autorisé. Avant ads.txt, un DSP n’avait aucun moyen indépendant de vérifier cette affirmation : soit il faisait confiance au SSP qui transmettait la bid request, soit il ne lui faisait pas confiance. ads.txt a offert aux acheteurs une source de vérité publique, contrôlée par l’éditeur, à laquelle se référer.
Chaque ligne d’un fichier ads.txt suit un format fixe : le domaine du SSP, l’identifiant du compte vendeur de l’éditeur chez ce SSP, un type de relation (DIRECT ou RESELLER) et, en option, l’identifiant d’une autorité de certification. DIRECT signifie que l’éditeur dispose d’un compte direct auprès de ce SSP. RESELLER signifie que le SSP est autorisé à revendre l’inventaire pour le compte d’un autre intermédiaire, ce qui est courant dans les configurations impliquant des ad networks et des agrégateurs.
app-ads.txt : le même principe pour les applications mobiles
ads.txt a été conçu pour les sites web, qui disposent d’un domaine sur lequel héberger le fichier. Les applications mobiles n’ont pas de domaine au même sens du terme ; l’IAB Tech Lab a donc publié app-ads.txt en 2019 afin de combler la même lacune pour l’inventaire in-app.
Plutôt que d’être hébergé sur l’application elle-même, le fichier app-ads.txt se trouve sur le domaine indiqué comme site web du développeur dans la fiche de l’application sur le store, à l’adresse developer-domain.com/app-ads.txt. Il utilise exactement le même format de ligne qu’ads.txt : domaine du SSP, identifiant du compte vendeur, DIRECT ou RESELLER, et un identifiant de certification facultatif. Pour vérifier une bid request in-app, un DSP récupère le site web déclaré par le développeur dans la fiche store référencée dans la bid request, puis consulte le fichier app-ads.txt de ce domaine pour y rechercher le SSP à l’origine de la requête.
sellers.json et l’objet Supply Chain : compléter le tableau
ads.txt et app-ads.txt répondent à une seule question : ce SSP est-il autorisé à vendre l’inventaire de cet éditeur ? À eux seuls, ils n’apprennent rien à l’acheteur sur les SSP et les intermédiaires situés entre l’éditeur et le DSP lorsqu’une chaîne de revendeurs entre en jeu. C’est précisément le rôle de sellers.json et de l’objet OpenRTB SupplyChain, souvent abrégé en schain.
sellers.json est un fichier que chaque SSP ou exchange publie sur son propre domaine. Il répertorie tous les comptes vendeurs pour lesquels il opère, avec le type de chaque vendeur (éditeur, intermédiaire ou les deux) et, en option, le nom et le domaine du vendeur. L’objet schain, lui, est transmis au sein même de la bid request et liste, dans l’ordre, chaque intermédiaire par lequel l’impression est passée entre l’éditeur et le DSP. En croisant les nœuds du schain avec le fichier sellers.json de chaque SSP, l’acheteur peut confirmer que chaque maillon de la chaîne correspond à une partie déclarée et identifiable, et non à un simple relais anonyme.
| Fichier | Hébergé par | Confirme |
| ads.txt | L’éditeur du site web, sur son propre domaine | Quels SSP sont autorisés à vendre l’inventaire de ce site |
| app-ads.txt | Le développeur de l’application, sur le domaine de son site web déclaré | Quels SSP sont autorisés à vendre l’inventaire de cette application |
| sellers.json | Chaque SSP ou exchange, sur son propre domaine | Quels comptes vendeurs ce SSP gère ou représente |
| Objet SupplyChain (schain) | Transmis par le SSP au sein de la bid request | Le parcours complet des intermédiaires par lesquels une impression est passée |
Utilisés ensemble, ces quatre éléments permettent à la logique d’achat d’un DSP de confirmer, sur chaque bid request, que l’inventaire proposé provient d’un parcours autorisé par l’éditeur, et non d’un parcours non vérifié ou usurpé.
Comment vérifier concrètement les autorisations ads.txt et sellers.json
La vérification des autorisations de la supply chain n’est pas une tâche de configuration ponctuelle. Elle s’exécute en continu, idéalement sous forme d’étape automatisée dans le pipeline d’enchères plutôt que d’audit manuel. Un processus de vérification pragmatique se présente ainsi :
- Récupérer et mettre en cache les fichiers ads.txt / app-ads.txt des éditeurs et applications qui envoient du trafic, en rafraîchissant le cache à intervalles réguliers, car les éditeurs modifient ces fichiers sans préavis.
- Comparer le domaine éditeur ou le bundle de l’application figurant dans la bid request entrante avec le fichier en cache, en confirmant que le SSP émetteur y figure avec le bon type de relation.
- Récupérer et mettre en cache les fichiers sellers.json de chaque SSP connecté, là encore en les rafraîchissant périodiquement et pas uniquement au moment de l’intégration.
- Analyser l’objet schain de chaque bid request et confirmer que chaque nœud correspond à un compte vendeur répertorié dans le fichier sellers.json correspondant.
- Signaler ou rejeter les bid requests pour lesquelles le SSP est totalement absent du fichier ads.txt, y figure avec un mauvais type de relation, ou dont un nœud du schain ne peut pas être rapproché de sellers.json.
- Journaliser les échecs d’autorisation par SSP, afin qu’une série d’échecs répétés provenant d’une même source, et non un incident isolé, déclenche une revue manuelle de la connexion.
Cette vérification fait partie de la checklist technique à suivre avant de connecter un nouveau SSP à un DSP, et elle doit être relancée périodiquement une fois la connexion active, pas seulement lors de l’onboarding. Les sources d’inventaire évoluent dans ce qu’elles représentent au fil du temps, et une connexion saine lors de sa mise en place n’a aucune garantie de le rester.
Ce qui se passe lorsque ces fichiers sont absents ou ignorés
Un éditeur sans fichier ads.txt, ou un SSP sans fichier sellers.json, n’est pas automatiquement frauduleux. De nombreux éditeurs plus petits ou plus récents n’ont tout simplement pas encore mis ces fichiers en place. Mais du point de vue de l’acheteur, un inventaire invérifiable présente un profil de risque plus proche de celui d’un inventaire non vérifié que de celui d’un inventaire ayant passé un contrôle.
Les DSP qui font totalement l’impasse sur cette vérification, ou qui ne la réalisent qu’une seule fois lors de l’intégration, se heurtent généralement aux mêmes problèmes : un budget dépensé sur un inventaire victime de domain spoofing qui n’atteint jamais l’audience réelle qu’il prétend toucher ; un schain comportant des intermédiaires non résolus ou anonymes, ce qui empêche de savoir combien d’acteurs prélèvent une part des dépenses média entre l’éditeur et le DSP ; et des incidents de brand safety, lorsqu’un annonceur découvre après coup que ses publicités ont transité par un circuit de revente que personne côté achat n’avait réellement vérifié.
Aucune de ces conséquences n’implique une quelconque mauvaise foi côté achat. C’est simplement ce qui se produit par défaut lorsqu’une étape de vérification qui pourrait s’exécuter automatiquement est absente du pipeline.
Les erreurs courantes des acheteurs programmatic en matière de vérification de l’inventaire
- Vérifier ads.txt une seule fois lors de l’onboarding du SSP sans jamais rafraîchir le fichier en cache par la suite, passant ainsi à côté des modifications ultérieures des éditeurs.
- Traiter une ligne RESELLER comme une ligne DIRECT sans vérifier si la chaîne de revente est correctement déclarée dans sellers.json.
- Ignorer les contrôles app-ads.txt sur le trafic in-app parce que le workflow a été conçu à l’origine pour un inventaire exclusivement web.
- Journaliser les échecs d’autorisation sans jamais les examiner, si bien qu’une connexion SSP en échec répété passe inaperçue pendant des mois.
- Partir du principe qu’un SSP important et reconnu ne nécessite pas le même niveau de contrôle qu’un plus petit, alors que l’autorisation peut échouer au niveau de chaque compte vendeur, quelle que soit la taille globale du SSP.
Ce type de vérification de l’inventaire s’inscrit aux côtés d’une discipline plus large, la supply path optimization, qui vise à acheminer chaque impression par le parcours le plus propre possible lorsque plusieurs sources se chevauchent. La vérification confirme qu’un parcours est légitime ; l’optimisation détermine quel parcours légitime mérite d’être utilisé. Un DSP a besoin des deux, et aucune ne remplace l’autre.
Pourquoi c’est plus important pour les propriétaires de DSP que pour les acheteurs passant par une plateforme managée
Les annonceurs qui achètent via un DSP tiers en mode managé font généralement confiance à cette plateforme pour effectuer ces contrôles à leur place, sans grande visibilité sur leur rigueur. Un propriétaire de DSP ne bénéficie pas de cette couche d’abstraction. Soit le pipeline de vérification est intégré à la logique d’enchères de la plateforme, soit il ne l’est pas, et dans ce dernier cas, chaque campagne qui transite par la plateforme hérite de cette lacune.
C’est l’une des raisons concrètes pour lesquelles les propriétaires de plateformes qui optent pour la voie White Label, licence ou acquisition avec une plateforme intégrant déjà la vérification ads.txt, app-ads.txt et sellers.json dans son pipeline d’enchères partent d’une position sensiblement différente de ceux qui développent la logique de contrôle de zéro. Les plateformes d’AdTech Europe effectuent ces contrôles sur les plus de 1 000 intégrations SSP préconnectées, et le même processus d’onboarding de l’inventaire qui intègre un nouveau SSP à la plateforme inclut la confirmation que son fichier sellers.json est bien en place avant que le trafic ne commence à circuler.
Prêt à acheter de l’inventaire programmatic via des supply paths vérifiés ?
AdTech Europe aide les agences, les ad networks et les équipes d’achat média à posséder leur propre DSP plutôt qu’à louer un accès à celui d’un autre, avec une vérification de la supply chain via ads.txt, app-ads.txt et sellers.json intégrée au pipeline d’enchères de la plateforme dès le premier jour. Que l’objectif soit une plateforme white-label entièrement managée, un DSP sous licence ou l’acquisition complète du code source, la grille tarifaire de chaque modèle de propriété est publiée et régulièrement mise à jour.
Pour découvrir comment la vérification de la supply chain fonctionne au sein de la plateforme, ou pour échanger sur une configuration de brand safety et de prévention de la fraude adaptée à votre cas d’usage, planifiez un rendez-vous stratégique programmatic avec l’équipe AdTech Europe.
FAQ
Quelle est la différence entre ads.txt et sellers.json ?
ads.txt est publié par un éditeur et répertorie les SSP autorisés à vendre son inventaire. sellers.json est publié par un SSP et répertorie les comptes vendeurs que ce SSP gère ou représente. Un acheteur vérifie généralement les deux, conjointement avec l’objet schain, pour valider l’intégralité du parcours d’une transaction.
app-ads.txt est-il obligatoire pour l’inventaire des applications mobiles ?
Il n’est pas légalement obligatoire, mais il constitue le standard du secteur pour vérifier les vendeurs autorisés de l’inventaire in-app, et la plupart des grands SSP et DSP considèrent le trafic applicatif dépourvu d’entrée app-ads.txt valide comme non vérifié.
Que signifient DIRECT et RESELLER dans un fichier ads.txt ?
DIRECT signifie que l’éditeur entretient une relation de compte directe avec ce SSP. RESELLER signifie que le SSP est autorisé à revendre l’inventaire pour le compte d’un autre intermédiaire, ce qui est courant lorsque l’inventaire transite par un ad network ou un agrégateur avant d’atteindre le SSP.
Qu’est-ce que l’objet SupplyChain (schain) ?
L’objet schain est un champ de la bid request OpenRTB qui liste, dans l’ordre, chaque intermédiaire par lequel une impression est passée entre l’éditeur et le SSP qui envoie la bid request, afin que l’acheteur puisse retracer l’intégralité du supply path et pas uniquement le dernier maillon.
La présence d’un fichier ads.txt garantit-elle un trafic exempt de fraude ?
Non. ads.txt confirme l’autorisation, pas la qualité du trafic. Un vendeur dûment autorisé peut tout de même envoyer du trafic de faible qualité ou invalide. C’est pourquoi la vérification de la supply chain est généralement associée à des mesures distinctes de contrôle de la qualité du trafic et de détection de la fraude, sans s’y substituer.
Qui est responsable de la vérification d’ads.txt et de sellers.json : le DSP ou le SSP ?
En pratique, cette responsabilité incombe au côté achat, puisque c’est le DSP qui décide d’enchérir ou non. Certains SSP effectuent leurs propres contrôles avant de transmettre les bid requests, mais un DSP qui s’en remet exclusivement au filtrage du SSP ne dispose d’aucune vérification indépendante.
