Sylvain Travers (Hubvisor) "Hubvisor veut redonner le contrôle aux éditeurs sur leur monétisation"

L'ancien directeur des activités programmatique de Webedia explique comment il veut permettre aux éditeurs d'optimiser leurs revenus en multipliant les sources de demande et les formats.

JDN. Vous avez quitté Webedia pour lancer Hubvisor. Quelle est l'ambition de votre nouveau projet ?

Sylvain Travers Hubvisor. Hubvisor veut mettre à disposition des éditeurs un socle technologique qui leur permettra d'optimiser leurs revenus publicitaires en concentrant un maximum de sources de demande au sein d'une même plateforme, de manière complètement agnostique.

Ce socle technologique sera très évolutif et basé sur le la librairie prebid.js aujourd'hui disponible en open-source. L'objectif, c'est de faire en sorte que le header bidding devienne plus intelligible et facile à intégrer qu'il ne l'est actuellement, via un wrapper enrichi et autonome.

Mais notre plateforme ne se cantonnera pas au seul programmatique. Il s'agira de mettre en compétition toutes les sources d'achat : les deals obtenus par la régie, les deals proposés par des réseaux tiers et, bien sûr, les offres obtenues depuis les ad-exchanges. Car une part importante de l'écosystème publicitaire transite encore via des ordres d'insertion ou contractualisations directes. 

Avez-vous déjà une cible en tête ?

La cible première c'est l'éditeur et, plus directement, son directeur de la monétisation ou chief revenue officer, un poste qui a vocation à prendre de l'ampleur au fil des années. Certains éditeurs ont un vrai besoin d'accompagnement sur ce sujet, faute de temps ou de ressources humaines. Je pense notamment aux éditeurs de taille moyenne ou réduite qui basculent progressivement leur inventaire en programmatique au détriment de leur régie. Si les outils qui facilitent le travail des acheteurs ne manquent pas, les éditeurs sont eux plus démunis lorsqu'il s'agit d'optimiser la gestion de leur inventaire pub.

On parle beaucoup de header bidding dans la presse spécialisée mais les éditeurs français qui le pratiquent et le maîtrisent sont encore rares…

Il faut dire que le sujet est aussi chronophage que complexe. Avec parfois même des résultats plutôt décevants si la solution est mal implémentée et pilotée. Il y a un vrai problème organisationnel. C'est le plus souvent le CTO et son équipe IT qui se retrouvent à la baguette car l'outil n'est pas proposé en "managed services". Mais ces équipes sont souvent coupées de la régie et le sujet est rarement en haut de leurs priorités. J'ai moi-même connu ces contraintes-là dans mes expériences passées.

Quels sont vos associés dans Hubvisor ?

Mon premier associé endosse la casquette de CTO. Il s'agit de Jérémie Girault, ancien lead developper de Snips et d'Ad4Screen. Un profil très pointu donc sur le sujet des SDK mobile. Un second va me rejoindre pour gérer l'opérationnel. Nous avons fait un premier tour d'investissement auprès d'acteurs issus du marché. Leur mise de départ nous assure de pouvoir démarrer en toute sérénité avec l'équipe nécessaire. Nous envisageons un tour de table dans un an lorsque le chiffre d'affaires se sera développé.

On imagine que votre objectif est aussi de les aider à monétiser leur inventaire mobile, aujourd'hui plutôt décevant…

"Nous sommes en test avec plusieurs éditeurs pilotes sur notre version beta avant le lancement définitif courant octobre"

Une partie significative de nos efforts va effectivement se porter là-dessus. Sur le web mobile, le header bidding n'en est encore qu'à ses balbutiements. Quant au monde applicatif, les défis sont nombreux avec notamment cette contrainte d'installer un SDK pour chaque nouveau réseau partenaire. Nous  sommes en mesure d'apporter une solution.

Hubvisor a vocation à raccrocher l'éditeur à un maximum d'acheteurs, mais pas seulement. Vous voulez également apporter plus de transparence sur ce sujet.

Nous allons effectivement mettre l'accent sur l'interface utilisateur, qui devra être la plus transparente et intuitive possible. Nous voulons permettre à l'éditeur de s'appuyer sur les données brutes remontées par l'outil de header bidding, lui octroyant la compréhension et le libre-arbitre sur sa monétisation au travers des formats, des emplacements mais aussi des articles qui marchent le mieux. L'éditeur aura ainsi accès dans son interface de reporting à un RPM (revenu pour mille impressions, ndlr) par page qui lui permettra d'identifier les contenus qui monétisent le mieux et aiguiller sa ligne éditoriale en conséquence.

Votre solution de header bidding sera donc "client side", la solution "server-to-server" ne permettant pas d'accéder à un tel niveau d'information ?

C'est juste. Nous sommes partisans de la transparence et pousserons donc en faveur de la technologie "client side".

Quel va être votre business model ?

Nous allons nous rémunérer via un partage de revenus sur le chiffre d'affaire additionnel généré grâce à notre solution. Nous allons également réfléchir à une offre de consulting et de formation s'il s'avère que les éditeurs en ont besoin. Enfin, pourquoi ne pas proposer une licence annuelle pour permettre aux régies de commercialiser certains des formats publicitaires que nous comptons développer.

Vous évoquez des nouveaux formats publicitaires ?

"Aucun intérêt à booster les sources d'achat si c'est pour proposer des mauvais formats pubs"

Je pense qu'il n'y a aucun intérêt à booster les sources d'achat si c'est pour proposer derrière des formats publicitaires qui nuisent à l'expérience publicitaire ou qui ne génèrent tout simplement pas de bonnes performances. Nous allons donc également travailler sur cette dimension-là, en nous inspirant notamment de ce qui se fait du côté du Web social où on trouve de vrais formats natifs. C'est d'ailleurs là où vont la majorité des budgets, tout simplement car ce sont les formats les plus efficaces.

Où en êtes-vous du développement commercial ?

Nous sommes en test avec plusieurs éditeurs pilotes sur notre version beta avant le lancement définitif courant octobre.