Interview de Geric Bouchenoire

Déjà venu à TeknSEO parler de scraping de données, Geric Bouchenoire revient cette année pour un atelier sur cette même thématique. L’occasion pour ceux qui ne l’ont pas encore écouté de parfaire ses connaissances dans le sujet et pour les autres de réviser et de découvrir les évolutions depuis son dernier passage. Il nous présente son atelier dans cette interview.

Peux-tu te présenter en quelques mots ?

Pour les plus jeunes, je suis développeur depuis 14 ans (voir plus si on compte les années d’études et les « loisirs »), j’ai passé 7 ans dans une web agency en tant que développeur puis SEO avant de créer RDDZ en 2012.
J’ai embarqué mon {associé|binôme|bro} Olivier avec moi dans cette aventure et c’est comme ça que nous sommes revenus aux sources et que nous nous sommes lancés dans le web scraping. Comme beaucoup de projets, RDDZ Scraper est née car il n’existait pas d’outil permettant de réaliser des scraps « sur mesure ». Nous avons voulu rendre le web scraping plus accessible !!

Cela fait maintenant de nombreuses années que tu utilises le scraping, quelles sont pour toi les évolutions que tu as pu constater ?

C’est une question à double réponse 😉 On peut évoquer les deux points suivants : évolutions techniques côté client et protection côté serveur !!

Commençons par les évolutions côté client. Pour scraper un site, la meilleur façon de procéder est de s’approcher au maximum du comportement d’un internaute. Pour cela il faut pouvoir gérer beaucoup de paramètres côté client, et une bonne partie est liée aux en-têtes HTTP. Quand nous nous sommes lancés en 2012, les browsers headless étaient déjà présents mais assez peu utilisés (et moins évolués que maintenant). L’avantage de ces browsers, c’est que l’on peut simuler un comportement utilisateur mais leur inconvénient est qu’ils sont très souvent « lourds » (utilisation RAM et/ou processeur) et cela limite donc leur utilisation en concurrence (multi-threading pour les intimes).

Le seul moyen de scraper à l’époque, c’était l’utilisation de scripts « homemade ». Et le problème de ces scripts c’est qu’ils ne sont pas forcément à la portée de tout le monde et que très souvent ils ne sont pas facilement évolutifs (pensés pour un besoin spécifique).

Beaucoup de projets liés au web scraping ont vu le jour, avec plus ou moins de succès. Pour en citer quelques uns, il y a scrapy, phantomjs (dont le dev a été arrêté suite à l’annonce du browser chrome en mode headless), Selenium, RDDZ Scraper (un peu d’auto-promo au passage :D), …

Au niveau des protections côté serveur, on pourrait citer par exemple :

  • affichage du contenu en ajax (donc utilisation d’un headless browser obligatoire)
  • gestion des sessions et/ou des cookies
  • limitation du nombre de requêtes par IP et/ou par sessions (cloudflare)
  • affichage du contenu en fonction de la géolocalisation
  • detection des proxies qui ne sont pas « élites » (anonymat complet ou transmettant des en-têtes X-Forwarded-for)

Un autre point que l’on pourrait évoquer en terme d’évolution serait les évolutions légales. En effet, on voit de plus en plus de jugements pour des affaires liées au scraping. Le web scraping n’est pas illégal en soit, l’utilisation des données récoltées et la manière de les récolter en l’occurence peut l’être !!

Le web tend petit à petit à être mieux scructuré (XHTML, Schema.org…). Est-ce que cela ouvre des possibilités pour le scraping ?

C’est encore mieux qu’ouvrir des possibilités, c’est tout simplement une aubaine pour les scrapeur !! Bien que loin d’être un standard aujourd’hui, le fait de structurer et d’utiliser des balises sémantiques permet au niveau du scrap d’être bien plus efficient. En effet, admettons que tous les sites web utilisent les données structurées à l’aide de schema.org, il serait alors très simple de récupérer des données précises sur ces sites, comme un prix, une marque, un descriptif, un email, un téléphone, … Nous n’aurions plus besoin de nous baser sur une structure à proprement parler, mais il suffirait tout simplement de récupérer le contenu d’une balise ayant un attribut spécifique (itemprop pour ne pas le citer). Ce n’est malheureusement pas encore le cas, mais espérons que cela se démocratise 😉

Peux tu nous présenter un projet qui exploite largement le scraping et qui est un succès grâce à cette technique ?

Il existe un « directory » très connu aux états-unis qui utilise presque uniquement le scraping. Les grandes enseignes qui proposent d’effectuer nos courses en ligne l’utilise quotidiennement (et ne s’en cachent pas forcément).

Nous avons également des clients qui ont des besoins très spécifiques et auxquels on ne pense pas forcément qui utilisent aussi uniquement le scraping !! Mais pour des raisons évidentes, je ne peux pas dire dans quels secteurs c’est utilisé. Je suppose que presque tout le monde à déjà entendu parler de growth hacking … et bien il faut savoir que le scraping est une stratégie largement utilisée dans ce domaine également !!

Quelles sont aujourd’hui les limitations ou freins techniques pour aller plus loin dans le scraping ?

Il n’existe pas vraiment de frein technique à partir du moment où il est tout à fait possible d’avoir un comportement utilisateur pour scraper. Dans ce cas précis, le temps et l’argent pourront être des contraintes.
Il faudra une armée de proxies et beaucoup de clients pour simuler une grande quantités de visiteurs sur un site sans déclencher un flag côté serveur.
La vraie limitation sera donc plutôt côté serveur (donc la cible) puisque avec une bonne configuration serveur, il est assez simple de se prémunir de 90% des scrapeurs (pour des raisons que j’évoquerai justement pendant ma présentation).