Le screen-scraping, une solution provisoire pour une industrie en pleine mutation

06 fév. 2010 | Posté par Julia Kowalczyk

Qu’est ce que le screen-scraping ? D’où vient ce nom barbare ? A quoi cela sert-il ? Pourquoi est-il actuellement massivement utilisé ? Et surtout pourquoi peut-on prédire la fin de son utilisation ?

Ce n’est plus à démontrer, l’arrivée d’internet à bouleversé l’industrie du tourisme : les connexions entre les acteurs se sont multipliées, les modes de consommation et d’accès aux produits ont évolué et la plupart des acteurs ne peuvent plus envisager leur distribution autrement que multi-canal. Pour le client final tout semble formidable, les prix sont plus compétitifs, les produits se diversifient… et la masse d’information grandissante qui naît du web est de mieux en mieux organisée. Quand aux acteurs de l’industrie, quelque soit leur cœur de métier initial, ils voient leurs business modèles évoluer. Avec ces évolutions, de nouveaux acteurs apparaissent ainsi qu’une nouvelle terminologie : méta-moteur, marque blanche, affiliation, flux xml, API, screen-scraping… et c’est d’ailleurs ce dernier que nous allons tenter d’éclairer.

Qu’est ce que le screen-scraping ?

Les techniques de screen-scraping apparaissent dans les années 1999-2000 lorsque internet commence à se développer. Elles seront en plein boom vers 2003, période où le contenu internet ne cesse de croître et où de nombreux comparateurs fond leur apparition. Elle sera également très utilisée chez les GNE et les agences on-line pour ce qui concerne l’e-tourisme.

Concrètement, le screen-scraping consiste à scanner le contenu d’un site afin de pouvoir le réutiliser sur un autre site. Pour faire cela, les screen-scrapper (sites qui utilisent le screen-scraping) se servent de robots identiques à ceux des moteurs de recherche (tels Googlebots ou Yahoo! Slurps). La seule différence étant que ces moteurs sont spécialisés dans les sites de e-commerce et qu’ils ont donc été « entraînés » à reconnaître certaines informations telles les prix ou les caractéristiques d’un produits… Un site marchand est constitué à partir d’un catalogue produits ou d’une base de données, ces robots ne peuvent pas y avoir accès, ainsi à partir de la lecture du code HTML des pages du site ils essaient de reconstituer au mieux le catalogue source ou la base de données.

Business modèle des screen-scrapeur

Parmi ces comparateurs, on va retrouver plusieurs business modèles. La majorité d’entre eux fonctionnent au coût par clic (CPC) ou au coût par action (CPA) et l’internaute sera systématiquement redirigé chez le marchand pour effectuer son achat. Le problème de ce modèle est que pour fonctionner l’acteur doit passer des accords aux préalables avec les sites marchands pour fixer sa rémunération. Ce modèle économique pose donc un problème de neutralité. D’autant plus que pour l’internaute ces accords commerciaux ne sont pas visibles, ainsi la plupart pensent que les résultats des comparateurs permettent de trouver les meilleurs prix du web.

En 2007, 11 des 12 comparateurs français contrôlés par la DGCCRT (Direction générale de la consommation, de la concurrence et de la répression des fraudes) ont été rappelés à l’ordre.

D’autres ont fait le choix d’un business modèle calqué sur celui de Google. C’est-à-dire qu’ils proposent des résultats dits « naturels » censés représenter le maximum de ce qui se trouve sur le web et parallèlement à ces résultats ont trouvera des liens commerciaux sous forme de texte (ex Wego) ou de bannières (ex : Sprice).

Enfin le dernier modèle se retrouve surtout chez les agences de voyages on-line, en effet celles-ci de par leur positionnement d’agence ne peuvent pas se permettre de rediriger l’internaute sur le site d’une compagnie pour effectuer la réservation. Dans certain cas elles ont développé des connexions directes avec les fournisseurs, mais il existe aussi des cas ou faute d’accords ou de technologie elles ne peuvent s’y relier. Ainsi on trouve une forme de screen-scraping plus avancée qui en plus de scanner les prix des produits à également reproduits le moteur de réservation sur son propre site. Ce moteur permet à l’internaute de réserver sur le site de l’agence, il fonctionne comme un moteur en marque blanche à la seule différence qu’il n’a pas été fournit par le producteur mais créé par l’agence. Celle-ci pouvant ce rémunérer en ajoutant sa propre marge au prix du producteur. On retrouvera cette technique chez Govoyages, Lastminute, Edream, Atrapalo, ou encore Ebookers. Cette technique est l’une des plus controversée, car elle s’utilise le plus souvent sans le consentement du producteur.

Problèmes posés par le screen-scraping

Bien que massivement utilisée le screen-scraping pose des problèmes d’ordre technique (le passage d’un robot sur un site ralentit son fonctionnement), qualitatif (un robot mal paramétré peut être sources de nombreuses imprécisions voire d’erreur) et éthique (le screen-scraping fonctionne sans accords préalables et peut être source de dérive). Ce dernier point est d’ailleurs une source de conflits récurrente dans notre secteur :

* 2003 : FareChase vs AA
* 2004 : FareChase vs SouthWest Airlines
* 2008 : Ryanair vs Agences en ligne
* 2008 : EasyJet vs Expédia

D’ailleurs, si l’on regarde le secteur du e-commerce en général, tous les comparateurs de produits autre que voyage ont laissé tomber le screen-scraping. A l’exception de Twenga, ils fonctionnent tous (Kelkoo, LeGuide, Achetezfacile.com…) avec l’envoi de catalogues aux formats XML.

Dans l’industrie du leisure travel, de part la complexité de l’offre, la tendance est plutôt au développement des API. Celles-ci permettent une connexion directe et fiable aux stocks d’un acteur et elles permettent également de sortir des standards imposés par les GDS (cf : cas Air Canada).

3 commentaires sur “Le screen-scraping, une solution provisoire pour une industrie en pleine mutation”

  • Marie NOËL dit :

    Hello J et A,
    Sympa le site, une mine d’infos et j’ai bien apprécié ce petit article.
    Concernant le screen-scraping (ou bien encore screen-scratching, updating, etc.), on le rencontre également particulièrement dans le domaine de la distribution hôtelière.
    Les acteurs appelés updaters font ainsi remonter les stocks de leurs chaînes ou hôtels clients sur les innombrables sites de distribution. L’avantage de cette solution, c’est une communication facile auprès des hôtels puisqu’ils peuvent leur promettent l’interface avec tous les sites de distribution immaginables (pas besoin de specs techniques du côté distributeur, ni même de son accord…) Cela engendre tous les problèmes techniques que vous énoncez + la redescente dans les stocks hôtels pour la décrémentation et la coordination des stocks avec les différents canaux de distribution.
    Comme vous le mentionnez, ces acteurs du screen-scraping passent de plus en plus à la connexion xml avec les distributeurs et prennent l’appellation de Channel Mangager… le souci, c’est de connaître la proportion exacte de leurs interfaces qui sont réellement en xml et s’il s’agit bien de xml « two-ways » avec cette fois-ci la décrémentation des stocks intégrée dans la solution, en lieu et place d’un e-mail d’information envoyé à l’hôtel à chaque réservation pour une solution « sous-automatisée »…
    Je m’interroge toujours sur la coordination des stocks entre les différents canaux de distribution avec ce type de solutions…
    Si vous avez d’autres infos là dessus, je suis preneuse !
    A +

  • Salut M,
    Ravie de te voir ici.
    C’est vraie que je n’ai pas vraiment abordé ce problème de re-descente des réservations pour les décrémenter du stock.

    Trois solutions se profilent:
    – soit l’hôtelier scinde ses stocks manuellement entre les différents canaux et il peut ainsi assurer la disponibilité immédiate de ses chambres à plusieurs distributeurs mais il perd surement de nombreuses ventes (à noter que les updaters peuvent apporter une solution partielle à ce niveau)

    – soit, dans le cas des compagnies low-cost, les agences en ligne ont développé des moteurs de réservation capables d’aller chercher directement dans les stocks de la compagnie via son site web (en screen-scraping). Cela c’est développé pour les low-costs car les agences rêvaient de pouvoir les vendre. Mais la solution n’est pas viable au vu des altercations entre distributeurs et compagnies. De plus, il faudrait déjà que l’hôtelier dispose d’un moteur de réservation sur son site web synchronisé avec son PMS.

    – enfin la dernière solution, c’est celle d’une automatisation à double sens entre les stocks de l’hôtelier (son PMS) et les différents canaux de distribution. Mais là on va surement rencontrer de nombreux problèmes de compatibilités qu’un hôtel indépendant, et même un petite chaîne ne peut pas gérer à son niveau.

    Je suis tout à fait d’accord que pour un fonctionnement véritablement automatisé, ce fonctionnement en « two-ways » s’impose (la 3ème solution). Mais pour cela, un intermédiaire technologique s’impose également. ReservIT le fait, non ?

    Après, pour ce qui est de la part des vraies solutions synchronisées par rapport à l’ensemble des acteurs sur ce créneau, je n’en ai aucune idée.

    Enfin, pour ceux qui voudraient quelques éclaircissements, notamment sur les termes utilisés, je vous recommande cet article: http://www.lhotellerie-restaur.....-donne.htm

  • Aurélie Krau dit :

    Hello M. ^^
    J’ajouterais également ma petite touche :)

    Dans la majorité des CRS qui sont développés de nos jours, ce type de cas de figure est prévu. Je m’explique. Les exploitants, hôteliers ou tous types d’hébergeurs entrent la totalité de leur stock dans leur CRS, et à partir de là le scindent en anticipant leurs différents canaux de distribution, et en considérant l’ensemble de leurs partenaires.

    Nous nous retrouvons donc avec des stocks dédiés :

    - aux TO, CE et autres partenaires sous forme d’allotements fermes et payés en avance. L’engagement est fort et le paiement est effectif, même si la totalité du stock n’est pas vendu.

    - à ces mêmes partenaires (TO, CE…) sous forme d’allotement plus flexible avec les délais de rétrocessions. Le « solde » du stock restitué à l’hébergeur sera donc redistribué soit en direct (voir le prochain tiret) soit via d’autres partenaires, brokers et spécialistes de la dernière minute par exemple.

    - aux ventes individuelles sur le web ou bien via les centrales de resa téléphoniques, que je qualifierais de stock au « coup par coup ». C’est dans cette segmentation que j’imagine que le stock remonté via screen scraping (avec un réel accord en amont ou non) sont piochés. Car dans le cas où un accord est au préalable fait avec un marchand pratiquant le screen scrapping ou agrégeant via techniques XML et WS, il rentrerait dans la catégorie « partenaires définis » correspondant soit au 1er soit au 2ème point.
    De cette manière, on peut dire qu’on est dans une configuration s’apparentant à du « two-ways ». Qu’en pensez-vous ?

    - et également via un scindement du stock que je qualifierais de « non bloquant » et qui serait partagé entre les différents partenaires et canaux de distribution : sites web, TO….. c’est à dire que le premier qui resa se sert et prend le stock. Cela ne nécessite aucun accord « ferme » au préalable.

    Après ces constats, en effet une réelle synchronisation aboutie des stocks est toujours très complexe. Car dans les cas de figure que j’évoque, cela sous-entend évidemment une connexion entre partenaires. Sinon, comme tu l’évoques M., nous restons au bon vieux mail envoyé et à l’enregistrement de la resa en manuel dans le CRS.

    Cela dit, étant donné que les CRS « nouvelle génération » sont en grande majorité full web et basés sur un accès en mode SaaS, les problèmes de connectivité devraient être atténués. Il s’agit davantage de problèmes de compatibilité et de passerelles.

  • Publier un nouveau commentaire

    Nom

    Email (ne sera pas publié)

    Site Web (facultatif)