Publicité et OSINT : suivre l’argent derrière les sites web

25 Jun, 2026

Lors d'investigations OSINT portant sur des sites web, les réflexes sont bien connus : WHOIS, DNS, infrastructure, code source. Mais une question reste souvent sous-exploitée : où va réellement l’argent ? Derrière beaucoup de sites web se cache une logique de monétisation qui, elle aussi, laisse des traces techniques exploitables.

Ces traces ne sont pas toujours visibles à l’œil nu. Elles se trouvent dans des standards industriels discrets, conçus à l’origine pour sécuriser l’écosystème publicitaire. Parmi eux, un fichier se révèle particulièrement utile pour l’investigation : ads.txt.

Ads.txt : une transparence conçue pour les machines

Ads.txt, pour “Authorized Digital Sellers”, est un simple fichier texte placé à la racine d’un site. Son objectif initial est de lutter contre la fraude publicitaire en listant les acteurs autorisés à vendre l’inventaire d’un éditeur. (À noter que ce standard se décline également pour les applications mobiles sous le nom de app-ads.txt, avec un fonctionnement strictement identique).

Chaque ligne contient des informations clés : le domaine du vendeur, un identifiant de compte et le type de relation, DIRECT ou RESELLER.

Pour bien comprendre cette distinction :

• DIRECT : l'éditeur contrôle directement le compte identifié chez la plateforme publicitaire. Il entretient donc une relation commerciale directe avec celle-ci.
• RESELLER (revendeur) : l'éditeur autorise un intermédiaire à vendre son inventaire publicitaire. Le compte identifié appartient alors à cet intermédiaire plutôt qu'à l'éditeur lui-même.

En pratique, cette distinction est utile pour comprendre la structure de commercialisation d'un site, mais elle ne permet pas à elle seule de déduire l'ensemble des relations contractuelles ou techniques impliquées dans la vente des espaces publicitaires.

Pour l'analyste, les entrées RESELLER peuvent parfois révéler l'existence d'un prestataire commun à plusieurs sites, constituant ainsi un pivot d'investigation intéressant.

Exemple fichier ads.txt. L’identifiant f08c47fec0942fa0 correspond à un identifiant technique de validation utilisé par Google dans le cadre de l’écosystème publicitaire (signature de vérification côté ads.txt), permettant de confirmer la légitimité du compte éditeur associé.

Les pivots d'attribution directe

Introduites dans les versions récentes du standard, certaines variables optionnelles comme ownerdomain ou managerdomain sont parfois présentes dans les fichiers ads.txt. Lorsqu'elles sont renseignées, elles constituent des points de pivot particulièrement utiles pour l'investigation.

Selon la spécification de l'IAB :

• ownerdomain : indique le domaine commercial de l'entité qui possède le domaine sur lequel le fichier ads.txt est hébergé.
• managerdomain : indique le domaine commercial du partenaire de monétisation principal ou exclusif de l'éditeur.

Dans cet exemple, la séparation entre domaine propriétaire et domaine de monétisation illustre une structure classique de délégation publicitaire entre éditeur et plateforme..

Pour un analyste OSINT, ces informations peuvent permettre d'identifier rapidement une société mère, un groupe média ou un prestataire de monétisation commun à plusieurs sites. Elles restent toutefois facultatives et demeurent relativement peu répandues dans la pratique.

Pour un enquêteur OSINT, ce fichier constitue une source d'information souvent négligée. Un identifiant vendeur réutilisé sur plusieurs domaines peut révéler un réseau de sites gérés par une même entité, même lorsque les protections WHOIS ou les CDN masquent l’infrastructure.

Mais cette transparence a ses limites : ads.txt ne prouve pas une propriété légale. Il expose des relations commerciales déclarées, pas des structures juridiques certifiées.

Comprendre la mécanique publicitaire

Pour exploiter ads.txt efficacement, il faut comprendre l’écosystème dans lequel il s’inscrit. La publicité programmatique repose sur un système automatisé où l’offre (les espaces publicitaires des éditeurs) rencontre la demande (les annonceurs) en quelques millisecondes.

Dans les environnements de publicité programmatique reposant sur des échanges inter-opérateurs, OpenRTB (Open Real-Time Bidding) est utilisé pour structurer les requêtes et réponses d'enchères (bid request/response). Il est toutefois crucial de garder à l'esprit que de nombreuses infrastructures techniques (stacks) actuelles sont hybrides. On y retrouve des wrappers comme Prebid, des serveurs publicitaires comme Google Ad Manager (GAM), des enchères traitées côté serveur (S2S bidding) ou encore des écosystèmes fermés dits « walled gardens » (Meta, etc.).

Lorsqu'un internaute charge une page, une requête d'enchère est envoyée aux acteurs du marché afin de déterminer quelle publicité sera affichée. Les standards comme ads.txt, sellers.json ou schain ont été conçus pour apporter davantage de transparence et de confiance à cet écosystème automatisé.

Trois types d’acteurs structurent ce marché :

• Les éditeurs, qui mettent à disposition des espaces publicitaires.
• Les annonceurs, qui cherchent à diffuser leurs campagnes.
• Les intermédiaires techniques, qui orchestrent les transactions.

Parmi ces intermédiaires, deux rôles sont essentiels, souvent reliés par des ad exchanges :

• Une DSP (Demand-Side Platform) aide les acheteurs à cibler des audiences et à enchérir sur des impressions.
• Une SSP (Supply-Side Platform) aide les éditeurs à vendre leurs espaces publicitaires et à optimiser leurs revenus.

Le terme « régie publicitaire » est souvent employé de façon large, mais dans un contexte d’OSINT et de publicité programmatique, il est plus précis de l’utiliser pour les acteurs qui commercialisent ou monétisent l’inventaire côté éditeur (sphère supply-side, SSP ou intermédiaire). Ads.txt s’inscrit de ce côté de la barrière : chez les éditeurs et les SSP, dans la chaîne de vente de l’inventaire.

Sellers.json : mettre un nom derrière les identifiants

Si ads.txt indique qui est autorisé à vendre, il ne dit pas toujours qui se cache derrière un identifiant. C’est là qu’intervient sellers.json.

Publié par les plateformes publicitaires, ce fichier associe des Seller IDs à des informations plus explicites : nom de l’entreprise, domaine, rôle (PUBLISHER, INTERMEDIARY, etc.).

Le principe est simple :

• ads.txt donne des identifiants.
• sellers.json permet de les interpréter.

En pratique, ce croisement est puissant, mais imparfait. Certaines entrées sont marquées “confidential”, masquant volontairement l’identité du vendeur. D’autres sont obsolètes ou incomplètes. Là encore, il s’agit d’un signal, pas d’une preuve.

Exemple de fichier sellers.json publié par une plateforme publicitaire, en configuration “confidential” (opacité structurelle des identités).

Exemple de sellers.json en configuration transparente, où les identités des vendeurs sont explicitement exposées..

OSINT appliqué : détecter des réseaux de sites

L’intérêt opérationnel apparaît lorsqu’on croise ces données à grande échelle. Plusieurs approches sont possibles.

Workflow 1 : Le pivot par identifiant de monétisation

• Un identifiant AdSense partagé entre plusieurs domaines peut indiquer une centralisation des revenus.
• Des configurations ads.txt similaires peuvent révéler un prestataire commun.
• Des vendeurs identiques sur des sites thématiquement proches peuvent suggérer un réseau éditorial.

Workflow 2 : Le pivot par domaine déclaré

Lorsqu'elles sont présentes, les variables ownerdomain et managerdomain offrent un raccourci particulièrement intéressant pour l'investigation. Elles constituent un point d'entrée potentiel vers une entité déclarée, permettant ensuite de poursuivre l'analyse via les données WHOIS, les registres du commerce, les infrastructures techniques ou les autres sites associés à ces domaines.

Outils utiles :

• Des outils comme BuiltWith, DNSlytics ou PublicWWW permettent de pivoter à partir de ces identifiants et de cartographier des relations invisibles autrement.
• Des plateformes comme Urlscan.io permettent de rechercher ces identifiants directement dans le code source (à condition que l'identifiant y soit présent) ou les requêtes HTTP de millions de sites scannés.
• L'historique d'Internet Archive (Wayback Machine) est souvent utile pour retrouver un fichier ads.txt qui aurait été effacé ou modifié.
• Le service well-known.dev constitue une source complémentaire intéressante pour l’analyse des configurations publicitaires et techniques. Une fonctionnalité particulièrement utile, accessible après authentification, permet de consulter l’historique des fichiers ads.txt observés sur un même domaine. Cette capacité d’archivage est précieuse en OSINT, car elle permet de reconstituer l’évolution des partenaires de monétisation dans le temps, et donc de détecter des changements de régie, des ajouts de revendeurs ou des restructurations de chaîne publicitaire. Sa base de données, relativement étendue, en fait un outil complémentaire aux approches classiques (BuiltWith, Urlscan, DNSlytics), notamment pour les analyses longitudinales et les pivots historiques.

Résultats d’une requête de corrélation ads.txt via well-known.dev — illustration de la propagation d’un identifiant publicitaire (Google AdSense pub-ID) à travers plusieurs domaines éditoriaux.

Exemple simple : deux sites sans lien apparent partagent un même Seller ID dans ads.txt et utilisent les mêmes scripts publicitaires. En croisant ces éléments avec leur historique DNS, on peut formuler une hypothèse solide de gestion commune.

L'analyse dynamique : Schain et Prebid

Pour les investigations avancées, les objets schain (Supply Chain Object) et les logs Prebid permettent parfois d'observer les intermédiaires impliqués dans la vente d'une impression (lorsqu'ils sont exposés par les acteurs concernés). Contrairement aux déclarations statiques, ils tentent de retracer dynamiquement la chaîne de valeur.

Il est cependant impératif de nuancer leur portée : la visibilité de la chaîne schain est bien souvent partielle. De même, Prebid reposant fréquemment sur un fonctionnement hybride (alliant client-side et server-side), l'observabilité réelle de ces données varie considérablement d'un environnement à l'autre.

Observation rapide dans le navigateur

Dans certains environnements, l’analyse de la chaîne publicitaire ne se limite pas aux fichiers statiques comme ads.txt ou sellers.json. Des informations complémentaires peuvent être observées directement côté navigateur, lorsque les implémentations techniques le permettent.

Les objets SupplyChain Object (schain) peuvent parfois être présents dans les requêtes publicitaires envoyées via OpenRTB. Lorsqu’ils sont correctement renseignés par les intermédiaires, ils permettent de documenter la succession des acteurs impliqués dans la vente d’une impression.

De manière complémentaire, certaines implémentations de Prebid.js exposent des informations exploitables côté client. Celles-ci peuvent être observées via les outils de développement du navigateur (onglet Network ou Console), ou via des extensions spécialisées permettant de visualiser les enchères et la configuration du wrapper publicitaire.

Dans certains cas spécifiques, des paramètres de requête ou options de débogage (par exemple pbjs_debug=true) peuvent enrichir les informations affichées. Il faut néanmoins préciser que ce paramètre ne constitue pas un standard Prebid officiel et universel. Il s'agit le plus souvent d'une implémentation sur mesure (custom), d'un wrapper maison ou d'une couche de débogage propre à l'équipe technique.

Ces éléments dépendent donc fortement des choix d’implémentation de l’éditeur et de la configuration technique du navigateur.

Capture de la console navigateur (Chrome DevTools) montrant l’exécution de Prebid.js et la séquence d’événements d’enchères côté client. Ces logs illustrent la couche observable de la publicité programmatique.

Biais d’observation dans l’OSINT publicitaire

Il est essentiel de comprendre que l’observation des mécanismes publicitaires côté navigateur est fortement dépendante du contexte technique dans lequel elle est effectuée. Contrairement aux fichiers déclaratifs comme ads.txt ou sellers.json, les données issues de Prebid, OpenRTB ou des objets schain ne constituent pas une vision stable de l’écosystème, mais une capture partielle et conditionnelle de son exécution.

Plusieurs facteurs influencent directement ce que l’analyste peut observer :

• Navigateur utilisé (Chrome vs Firefox) : certaines implémentations JavaScript, modules publicitaires ou comportements de debugging peuvent différer, entraînant des niveaux de verbosité variables dans la console ou le réseau.
• Extensions et bloqueurs de publicité : un adblocker peut empêcher l’exécution de Prebid, bloquer les requêtes SSP ou supprimer totalement les objets window.pbjs, rendant l’analyse incomplète ou invisible.
• CMP / consentement (TCF) : la présence d’un Consent Management Platform peut modifier la chaîne d’enchères en amont, voire désactiver certains bidders si le consentement n’est pas accordé.
• Header bidding server-side (S2S) : une partie des enchères peut être déplacée côté serveur, ce qui rend invisibles les échanges normalement observables dans le navigateur.
• Prebid Server : dans certaines architectures hybrides, le navigateur ne voit qu’une partie du processus, le reste étant orchestré en backend.

Dans ce contexte, deux navigateurs ouverts sur la même page peuvent produire des observations radicalement différentes, sans que cela reflète une différence réelle de monétisation, mais simplement une différence de conditions d’observation.

Rapport généré par un bookmarklet OSINT personnalisé : extraction à la volée des données Prebid.js révélant la chaîne d'approvisionnement (Schain), les modules d'identité et les enchères gagnantes directement depuis le navigateur.

Il est donc important de considérer ces sources comme opportunistes et contextuelles, contrairement aux standards déclaratifs comme ads.txt ou sellers.json, qui offrent une base plus stable et systématique d’analyse.

Pour résumer cette dynamique fondamentale, l’OSINT publicitaire ne voit pas la publicité, il voit son interface observable. Concrètement, ads.txt s’apparente à une déclaration, sellers.json fournit un mapping dépendant de la plateforme, le navigateur offre une observation partielle, et les mécanismes server-side (S2S) introduisent une invisibilité technique.

Externalisation et faux négatifs

L’absence d’ads.txt est un piège classique. Elle ne signifie pas forcément absence de monétisation.

Certaines implémentations utilisent également des mécanismes de délégation ou de découverte s'appuyant sur des ressources du répertoire /.well-known/. Le fichier peut aussi être externalisé. Certains éditeurs délèguent entièrement leur gestion publicitaire à des prestataires tiers, via des redirections vers des services tiers spécialisés ou des plateformes de gestion externalisée.

Dans ces cas, la piste ne disparaît pas : elle se déplace. L’analyse de la redirection peut révéler un fournisseur commun à plusieurs sites, ouvrant un nouveau pivot d’investigation.

Limites et précautions

L’erreur la plus fréquente consiste à surinterpréter les données.

• Un lien dans ads.txt n’est pas une preuve de propriété.
• Un statut DIRECT ne garantit pas l’absence d’intermédiaire.
• Un vendeur RESELLER n’est pas nécessairement suspect.

De même, sellers.json dépend de la qualité des données fournies par les plateformes. Certaines informations peuvent être inexactes ou volontairement masquées. En pratique, ces fichiers doivent être intégrés dans une approche plus large, incluant WHOIS, DNS, mentions légales, code source et analyse temporelle.

Méthode d’analyse recommandée

Une démarche simple et robuste consiste à :

1. Identifier et récupérer ads.txt.
2. Extraire les vendeurs, identifiants, relations, et lire les éventuels commentaires ("#").
3. Relever les éventuelles variables déclaratives ownerdomain et managerdomain, qui peuvent fournir un point d'entrée potentiel vers une entité déclarée ou un partenaire de monétisation.
4. Croiser avec les fichiers sellers.json correspondants.
5. Rechercher des corrélations et fouiller l'historique via des outils OSINT (Wayback Machine, Urlscan, etc.).
6. Valider les hypothèses avec des sources complémentaires avant toute conclusion d'attribution.

L’analyse dans le temps est particulièrement utile pour détecter des changements de stratégie ou des bascules de prestataires.

Conclusion

Ads.txt, app-ads.txt et sellers.json offrent une porte d’entrée souvent sous-estimée en OSINT : celle des flux de monétisation. Ils ne remplacent pas les méthodes classiques, mais les complètent en révélant des relations économiques souvent invisibles.

Ces mécanismes ne décrivent pas l’écosystème publicitaire, ils décrivent des fragments d’écosystème exposés à l’observation.

Leur véritable valeur ne réside pas dans une lecture isolée, mais dans leur intégration dans une analyse croisée et critique. Suivre l’argent reste une approche puissante — à condition de ne jamais confondre signal technique et preuve formelle.

Références et ressources techniques

Standards publicitaires

• IAB Tech Lab (Interactive Advertising Bureau) — Organisation responsable de nombreux standards de l’écosystème publicitaire programmatique (ads.txt, sellers.json, schain, etc.).
• OpenRTB Specification — Protocole standard utilisé pour structurer les échanges d’enchères en temps réel dans la publicité programmatique.

Environnements et standards techniques

• Prebid.js documentation — Framework open-source de header bidding largement utilisé dans l’écosystème publicitaire.
• TCF (Transparency & Consent Framework) — Cadre de gestion du consentement utilisateur dans la publicité programmatique (RGPD).