Ads.txt : quelle est la fonction de ce fichier ?

Beaucoup de sites Web sont financés par le biais des campagnes pu­bli­ci­taires. Grâce à elles, les Web­mas­ters génèrent des rentrées d’argent et mettent ainsi gra­tui­te­ment à dis­po­si­tion des visiteurs du site Web du contenu mé­dia­tique. Ainsi, un grand marché s’est créé pour les achats pro­gram­ma­tiques (l’achat et la vente au­to­ma­tique d’espace pu­bli­ci­taire en ligne) et parfois, des sommes con­si­dé­rables sont en jeu. Il n’est donc pas étonnant que quelques moutons noirs ba­ti­fo­lent également dans ce domaine et essayent d’obtenir, sans réelle per­for­mance, une part du gâteau marketing. L’IAB (In­te­rac­tive Ad­ver­ti­sing Bureau), une as­so­cia­tion créée en 1998 dont la mission est de struc­tu­rer le marché de la com­mu­ni­ca­tion sur Internet, favoriser son usage et optimiser son ef­fi­ca­cité, souhaite lutter contre la fraude pu­bli­ci­taire au moyen de l’ini­tia­tive ads.txt. La fraude pu­bli­ci­taire est la pré­ten­tion d’un service pu­bli­ci­taire qui n’est pas du tout fourni ou seulement dans une mesure in­suf­fi­sante.

L’IAB est une as­so­cia­tion in­ter­na­tio­nale de la branche de l’online marketing. Son but est de renforcer la branche, dé­ve­lop­per des standards et améliorer con­ti­nuel­le­ment l’offre pu­bli­ci­taire en ligne. Dans ce cadre, l’as­so­cia­tion s’efforce de détecter et éviter les arnaques au sein de la branche. Cela concerne par­ti­cu­liè­re­ment les fraudes pu­bli­ci­taires, res­pon­sables chaque année de pertes d’argent as­tro­no­miques. Aussi bien les ex­ploi­tants pu­bli­ci­taires que les éditeurs sont concernés par ce type d’arnaque : alors que les agences pu­bli­ci­taires in­ves­tis­sent leur argent dans des es­cro­que­ries, sans pouvoir obtenir une con­tre­par­tie, les Web­mas­ters perdent quant-à-eux d’im­por­tantes rentrées d’argent au profit des cy­ber­cri­mi­nels.

Beaucoup de choses fonc­tion­nent de manière au­to­ma­tique dans l’achat pro­gram­ma­tique : les éditeurs offrent de l’espace pu­bli­ci­taire sur leurs pages (par exemple sur des magazines en ligne ou des blogs) et des an­non­ceurs achètent ou en­ché­ris­sent pour ces em­pla­ce­ments. La plupart du temps, l’achat ou la mise aux enchères se fait par le biais d’un in­ter­mé­diaire, en règle générale via une pla­te­forme sur laquelle se déroulent des ventes ou des ventes aux enchères. Dans cet en­vi­ron­ne­ment, les cy­ber­cri­mi­nels ont souvent recours à l’usur­pa­tion du nom de domaine : les an­non­ceurs croient ainsi acheter un em­pla­ce­ment pu­bli­ci­taire d’un éditeur renommé (par exemple le site Internet d’un journal de renommée in­ter­na­tio­nale) alors que les pu­bli­ci­tés seront en fait affichées plus tard sur une toute autre page.

La pla­te­forme sur laquelle se trouve la fraude pu­bli­ci­taire ne doit pas être dénoncée comme escroc, car, souvent, les gérants ne savent pas du tout qu’il y a des arnaque en ligne sur leur site Web. Les cy­ber­cri­mi­nels feignent, via la fraude pu­bli­ci­taire, que le site Web sur lequel vous voulez faire de la publicité est un site différent, beaucoup plus renommée. En d’autres termes, ils cachent l’identité de leur présence sur le Web. On parle aussi dans ce cas d’oc­cul­ta­tion de site Web. Le site Web réel­le­ment utilisé a gé­né­ra­le­ment peu de trafic et souvent une mauvaise ré­pu­ta­tion, ce qui pourrait porter atteinte à l’annonceur même. Le fichier ads.txt est destiné à prévenir de telles es­cro­que­ries.

IAB utilise « Ads » comme acronyme pour « Au­tho­ri­zed Digital Sellers ». Cependant, « Ad » est aussi connu par beaucoup de personnes comme une abré­via­tion d’ « Ad­ver­ti­sing » (publicité). Dans ce texte de fichier simple, les éditeurs doivent dresser la liste de tous les four­nis­seurs autorisés à vendre leur in­ven­taire pu­bli­ci­taire (c’est-à-dire l’ensemble des espaces pu­bli­ci­taires dis­po­nibles à la vente à une moment donné, pour une période donnée et un support pu­bli­ci­taire donné). Le fichier permet aux éditeurs d’avoir davantage leur mot à dire dans le commerce de l’espace pu­bli­ci­taire. Pa­ral­lè­le­ment, le fichier garantit une plus grande trans­pa­rence, car il précise exac­te­ment avec quels four­nis­seurs il faut coopérer.

Les éditeurs en­re­gistrent le fichier ads dans le ré­per­toire racine qui est le ré­per­toire supérieur du site Web. Ici s’y trouve également le fichier robots.txt qui fournit les in­for­ma­tions pour les crawlers des moteurs de recherche. L’ads.txt peut également être traité par des crawlers. Le fichier de texte est ou­ver­te­ment ac­ces­sible et peut être aussi bien lu par des machines que par des humains.

Puisque le fichier se trouve dans le ré­per­toire racine et doit im­pé­ra­ti­ve­ment s’appeler ads.txt (example.com/ads.txt), il peut être trouvé fa­ci­le­ment et ra­pi­de­ment. Les an­non­ceurs et les pla­te­formes peuvent ainsi vérifier si la vente par le com­mer­çant cor­res­pon­dant est autorisée. Lorsqu’un éditeur est listé sur une place de marché pu­bli­ci­taire et que le fichier d’annonces cor­res­pon­dant peut être vérifié par toutes les parties con­cer­nées, alors les risques d’es­cro­que­ries diminuent fortement. Il devient en effet plus difficile aux ar­na­queurs de simuler une fausse identité qui n’est pas listée par ads.txt.

Grâce au fichier ads.txt, il est main­te­nant possible de vérifier s’il s’agit d’une offre véridique ou non. Quelques places de marché pu­bli­ci­taires, comme par exemple Google, ont déjà mis en œuvre cette norme sur leur propre pla­te­forme. Si un éditeur vient à mettre son in­ven­taire à dis­po­si­tion, alors l’ads.txt est au­to­ma­ti­que­ment crawlé. Si l’éditeur n’a pas mentionné sa place de marché pu­bli­ci­taire dans son fichier ads.txt, aucune tran­sac­tion ne pourra alors avoir lieu.

Puisque l’ads.txt n’est qu’un simple fichier de texte, il peut être aussi créé avec un simple éditeur de texte. Seules trois in­di­ca­tions sont né­ces­saires par vendeur autorisé, la quatrième est op­tion­nelle.

• Le nom de domaine du vendeur : sous quel domaine est en­re­gis­tré l’en­tre­prise qui est autorisée à vendre l’in­ven­taire pu­bli­ci­taire. Le nom correct peut souvent être vérifié di­rec­te­ment ou bien il faut contacter le four­nis­seur pour connaître le nom de domaine exact. Pour des offres Google, par exemple, le nom correct est toujours google.com.
• L’iden­ti­fiant du compte : si quelqu’un est en­re­gis­tré comme éditeur auprès d’un four­nis­seur, alors il dispose d’une iden­ti­fi­ca­tion de compte. Le même iden­ti­fiant est également spécifié lors d’une tran­sac­tion.
• Relation avec le four­nis­seur : il est possible d’y entrer deux valeurs dif­fé­rentes. En entrant DIRECT, cela signifie que l’éditeur prend lui-même la gestion de son in­ven­taire sur la pla­te­forme (sous l’ID qui a été entrée dans le second champ). L’entrée RESELLER indique que l’éditeur a légué la gestion à un tiers.
• ID auprès d’un organisme de cer­ti­fi­ca­tion (optionnel) : lorsque le système pu­bli­ci­taire est ré­per­to­rié auprès d’un organisme de cer­ti­fi­ca­tion, l’ID cor­res­pon­dant peut être donné. L’un de ces or­ga­nismes est par exemple le Tru­th­wor­thy Ac­coun­ta­bi­lity Group (TAG). TAGID serait alors entré lors d’une ins­crip­tion.

Tous les champs sont listés les uns après les autres à l’intérieur d’une ligne, les champs in­di­vi­duels sont séparés par une virgule. Si vous voulez inclure des ex­pli­ca­tions dans le fichier que les robots ne devraient pas prendre en compte, vous devez les exclure avec le signe dièse (#). Tout ce qui se trouve après le dièse sera ignoré. Si le signe se trouve au tout début d’une ligne, alors la ligne complète ne sera pas prise en compte.

En plus des entrées des vendeurs et les com­men­taires, la norme permet d’indiquer deux autres in­for­ma­tions : CONTACT et SOUS-DOMAINE. Ces deux valeurs seront entrées dans le fichier sous le format Variable=Valeur. Par exemple : CONTACT=example.com/notre_histoire. Alors que la première in­di­ca­tion spécifie une seule option de contact, la deuxième in­di­ca­tion se réfère à un fichier ads.txt dans un sous-domaine. Sans la mention sur ce deuxième fichier texte, les bots l’ig­no­re­raient parce que, fon­da­men­ta­le­ment, seul le ré­per­toire racine du domaine principal est crawlé.

Que vous sou­hai­tiez créer vous-même un fichier ads ou le faire créer par un tiers, vous devez tra­vail­ler en col­la­bo­ra­tion avec beaucoup d’autres pla­te­formes. L’effort n’est pas par­ti­cu­liè­re­ment important. Si vous êtes vous-même éditeur et voulez à l’avenir protéger votre in­ven­taire pu­bli­ci­taire d’arnaques, vous pourrez créer le fichier de texte né­ces­saire en seulement quelques étapes. Pour cela, ouvrez un éditeur de texte (par exemple un éditeur sous Windows ou TextEdit sous Mac) et entrez les pa­ra­mètres requis pour les vendeurs avec lesquels vous tra­vail­lez. Dans notre exemple, il s’agit d’un par­te­na­riat com­mer­cial entre Google et notre blog fictif sur lequel nous proposons des espaces pu­bli­ci­taires.

Par la présente, nous attestons avoir deux comptes dif­fé­rents sur Google. Les iden­ti­fiants de compte Google suivent toujours le même schéma : pub- (pour Publisher donc éditeur en français) est suivi d’une séquence de 16 numéros. Quelques éditeurs ont plusieurs comptes sur les pla­te­formes, même lorsque vous êtes, comme dans notre exemple, connecté à AdSense et Ad Exchange. Nous gérons nous-même notre in­ven­taire dans les deux comptes et puisque Google dispose d’un TAGID unique, nous l’incluons également.

Pour améliorer la clarté et fournir plus d’in­for­ma­tions aux in­té­res­sés, nous pré­ci­sions sous forme de com­men­taires de quel type de comptes il s’agit exac­te­ment. Enfin, nous four­nis­sons également une adresse e-mail, sous laquelle nous pouvons être contacté.

Alors que l’ordre des pa­ra­mètres in­di­vi­duels est so­li­de­ment défini, vous pouvez choisir librement l’ordre des pla­te­formes de vente au­to­ri­sées. Quelques éditeurs divisent, par exemple, votre liste de cette manière, de telle sorte que toutes les entrées DIRECT viennent en premier, puis toutes les entrées RESELLER. Cependant, il ne doit y avoir aucun espace vide, aucune ta­bu­la­tion ou virgule dans les pa­ra­mètres in­di­vi­duels. Si cela est né­ces­saire, parce qu’un espace vide peut ap­par­te­nir à un ID par exemple, il faut utiliser l’encodage URL : cette méthode, également connue sous le nom de codage en pour­cen­tage, utilise le code hexa­dé­ci­mal du caractère dans le jeu de ca­rac­tères ASCII et le place di­rec­te­ment après un signe en pour­cen­tage. Par exemple, un espace est re­pré­senté par la chaîne de ca­rac­tères %20.

Lors de la sau­ve­garde de votre fichier, veillez à ce que celui-ci soit vraiment sau­ve­gardé comme fichier .txt avec le nom ads. Té­lé­char­gez main­te­nant l’ads.txt dans le ré­per­toire racine de votre serveur. Cela est par exemple possible avec un programme FTP. Le ré­per­toire racine est le ré­per­toire le plus élevé hié­rar­chi­que­ment parlant. Main­te­nant, vous pouvez appeler le fichier via example.com/ads.txt.

Lorsque l’on travaille avec beaucoup de pla­te­formes, l’uti­li­sa­tion d’un gé­né­ra­teur en ligne peut valoir la peine.  Quelques-uns d’entre eux proposent le service en échange de votre adresse e-mail. D’autres, comme par exemple le gé­né­ra­teur dans le réseau DFP Google n’ajoutent que les entrées de votre propre place de marché dans le fichier de texte.

Avec un va­li­da­teur ads.txt, vous pouvez vérifier si votre fichier d’au­to­ri­sa­tion a été créé cor­rec­te­ment qu’aucune erreur ne s’y est glissée. En règle générale, pour la plupart des va­li­da­teurs, il suffit d’entrer l’URL dans le masque de saisie. Quelques services Web offrent aussi la pos­si­bi­lité de té­lé­char­ger di­rec­te­ment le fichier et de le vérifier sur votre propre espace Web avant de le rendre public. Le va­li­da­teur ads.txt d’AppNexus, un four­nis­seur de la pla­te­forme de publicité pro­gram­ma­tique permet même aux uti­li­sa­teurs d’exécuter des mo­di­fi­ca­tions du fichier di­rec­te­ment dans la boîte à outils, de le faire vérifier im­mé­dia­te­ment et de té­lé­char­ger le nouveau fichier. Bien entendu, vous devez vous-même trans­fé­rer le fichier ads.txt modifié sur votre serveur.

En effet, un va­li­da­teur ads.txt vérifie seulement que la syntaxe des entrées est correcte. Les outils en ligne ne vérifient pas si les in­di­ca­tions cor­res­pon­dent à la réalité. Cela est surtout important pour les an­non­ceurs : avec un va­li­da­teur, vous ne pouvez pas encore vérifier si l’éditeur travaille réel­le­ment avec ladite pla­te­forme.

Comme beaucoup de normes, le fichier ads.txt n’a pas pu s’imposer dès le début. Une raison pour cette uti­li­sa­tion en demi-teinte dans la branche con­cer­nait cer­tai­ne­ment l’in­cer­ti­tude : comment le fichier pourrait-il influer sur le propre business ? Ce n’est que lorsque le poids lourd Google a soutenu l’ini­tia­tive et a annoncé d’insister dès à présent sur l’uti­li­sa­tion du fichier qu’ads.txt a pro­gres­si­ve­ment prévalu.

Un point qui a créé de l’in­cer­ti­tude au sein de l’industrie est qu’il est difficile de revendre les in­ven­taires.  Les four­nis­seurs achètent l’espace pu­bli­ci­taire à partir d’une pla­te­forme et le revendent par leurs propres moyens. Il ne se cache pas toujours derrière cela une action cri­mi­nelle, mais ads.txt empêche un tel com­por­te­ment. Les éditeurs n’ont aucun lien direct avec ces re­ven­deurs et ne savent souvent rien de ces processus. C’est pourquoi les four­nis­seurs n’ap­pa­rais­sent pas dans le fichier ads.txt. Quelques-uns de ces re­ven­deurs ont donc ciblé les éditeurs, ce qui a suscité beaucoup de dis­cus­sions au sein de l’industrie et a été perçu par beaucoup comme une tentative de fraude.

Un point critique que rencontre beaucoup de vendeurs concerne la création manuelle du fichier : il n’est pas garanti qu’il n’y ait pas d’erreurs de frappe. Une erreur a vite fait de se glisser dans le nom de domaine et l’in­ven­taire de l’éditeur ne peut donc plus être négocié sur la pla­te­forme. Aussi bien les four­nis­seurs que les éditeurs peuvent perdre de fortes sommes d’argent. Cependant, l’uti­li­sa­tion d’un va­li­da­teur ads.txt diminue sen­si­ble­ment le risque d’erreurs ty­po­gra­phiques : un tel va­li­da­teur vérifie également s’il y a un marché pu­bli­ci­taire pro­gram­ma­tique derrière le domaine. Enfin, les erreurs de frappe peuvent également être évitées grâce à une procédure mi­nu­tieuse.

Un autre dé­sa­van­tage du fichier ads.txt concerne l’absence d’iden­ti­fi­ca­tion du type d’in­ven­taire convenu : les éditeurs ne peuvent pas signaler via le fichier texte si le com­mer­çant peut vendre des pu­bli­ci­tés d’affichage, des pu­bli­ci­tés vidéo ou les deux. Les pla­te­formes peuvent ainsi continuer à prétendre que les pu­bli­ci­tés d’affichage sont en fait des espaces pu­bli­ci­taires pour les pu­bli­ci­tés vidéos et obtenir ainsi des com­mis­sions sup­plé­men­taires. Le fait qu’un com­mer­çant ap­pa­raisse dans l’ads.txt ne suffit pas à affirmer avec sûreté que celui-ci ne fait pas partie des moutons noirs. La res­pon­sa­bi­lité de ne conclure aucune affaire avec des ar­na­queurs repose encore sur les éditeurs.

Il faut aussi savoir que le fichier ads.txt n’est pas une solution mul­ti­fonc­tion : certes, il est possible d‘être mieux protégé contre les usur­pa­tions de domaine mais les autres formes de fraudes pu­bli­ci­taires restent cependant in­chan­gées. Cette louable ini­tia­tive ne peut mettre un terme à l’es­cro­que­rie de fraude à l’im­pres­sion pu­bli­ci­taire et fraude au clic qui re­pré­sen­tent encore une grosse perte du budget pu­bli­ci­taire des an­non­ceurs.

Malgré ses points faibles, l’ini­tia­tive a largement été acceptée dans la branche et in­fluen­cera encore à l‘avenir le marché pu­bli­ci­taire. Grâce au soutien de puissants acteurs du marché comme Google ou des éditeurs bien connus, il est possible de mettre un terme à la fraude pu­bli­ci­taire. Les autres con­cur­rents doivent faire de même avec l’im­plé­men­ta­tion du fichier ads.txt ou ils auront de mauvaises cartes lorsqu’ils feront du commerce avec des em­pla­ce­ments pu­bli­ci­taires en ligne.