INTERVIEW 
 
Olivier Maréchal
DSI
Expedia
Olivier Maréchal
"Notre moteur de gestion de commandes est associé à une interface multicanal"
Comment sont aujourd'hui traitées les commandes émises depuis le site d'Expedia ? Quels traitements suivent les offres de tour opérateurs proposées ? Réponses avec Olivier Maréchal, DSI du groupe.
31/01/2006
 
JDN Solutions. Quelles sont les attributions de la direction informatique France d'Expedia ?
  En savoir plus
Dossier Réaliser, maintenir et faire évoluer ses sites Web pro
Olivier Maréchal. Notre statut est un peu particulier. En fait, nous sommes la résurgence de la DSI d'Anyway.com, intégrée depuis dans le groupe Expedia. La mission standard d'une DSI, qui consiste à s'occuper des postes de premier niveau, d'assurer le support aux utilisateurs, ne s'inscrit pas dans notre cadre d'activité. Nous fournissons simplement des outils au groupe, soit pour le marché français, soit pour le marché européen.

Dans ce cadre, nous gérons tous les outils relatifs aux packages ou séjours tiers, c'est-à-dire des offres clés en main fournies par des tour-opérateurs. Nous gérons aussi la partie calculateur aérien pour les tarifs Nett et Charters. Nous gérons enfin l'ensemble des outils nécessaires à la réalisation des vols - IATA, Netts et Charters.

Qui gère la partie Web des sites d'Expedia ?

Le cœur de la plate-forme Web est géré aux Etats-Unis, sauf pour la partie package où la totalité des opérations est gérée sur une infrastructure locale.

Quelle infrastructure pour la partie Web ?
Nous disposons pour la partie gérée en France, de 12 serveurs Web frontaux sous Windows reliés entre eux par un système de répartition de charge. L'affichage Web utilise l'ASP et le serveur Web IIS. Il était plus facile pour nous de démarrer sur ces technologies en raison des compétences internes et des technologies utilisées sur le marché.

Derrière les frontaux Web, un gros serveur de base de données sous SQL server pour le suivi des transactions. Ce serveur est "backupé" en temps réel sur un second serveur SQL à partir d'un mécanisme de log-shipping.

La base de données ne gère que l'accès aux informations"
Toutes les requêtes relatives aux offres package sont transmises à six serveurs dédiés au travers d'un répartiteur de charges. Ces serveurs sont des machines Linux Red Hat avec du code C derrière. Nous avons développé un protocole propriétaire pour assurer le dialogue entre ces machines et n'importe quelle interface d'affichage, pas simplement le Web. Ce système a été utilisé au début avec du minitel ou des terminaux 3270.

Pourquoi avoir séparé l'accès aux données du traitement des requêtes ?
La volonté de départ est d'avoir une infrastructure modulaire dans laquelle nous pouvons releaser [ndlr : faire monter de version] un composant unitairement. D'autre part, la recherche de l'offre est complexe et consommatrice de CPU.

Elle ne pouvait tout simplement pas s'écrire en SQL, nous l'avons donc réalisée en C sous un environnement Linux. Le Web se charge juste de la partie présentation. Le choix de Linux s'explique lui par l'historique de la partie package. En effet, pour la développer, nous sommes partis sur les premières versions d'un calculateur aérien qui fonctionnait sous Linux. L'environnement était fiable, pas très cher et nous étions capable de modéliser des éléments compliqués dessus et, surtout, de réutiliser pas mal de librairies.

Comment dialoguez-vous avec l'informatique de vos partenaires ?
Sur la partie package, les données de nos partenaires sont en fait ressaisies dans notre propre base. Nous n'allons pas piocher à droite à gauche pour proposer une offre aux internautes, le résultat de la requête est simplement calculé à partir de notre base.

Ce système nous oblige à saisir l'offre des tour-opérateurs et peut éventuellement poser un problème de fraîcheur des informations si le partenaire ne nous informe d'un changement de prix que deux jours plus tard.

Pourquoi, dans ce cas, ne pas avoir opté pour une connexion directe et automatique avec leur système d'information ?
Contrairement aux GDS, le travail avec les tour opérateurs exige encore souvent un travail à la main"
D'abord parce que les tour-opérateurs ne sont pas toujours à même d'offrir des mises à jour régulières et automatiques et qu'il faudrait poser autant de questions que de tour-operateur référencé.

Ensuite, parce que nous n'avons pas trouvé d'interface unique capable de récupérer l'offre d'un nombre illimité de tour-opérateurs, et cela dans des temps de réponse corrects.

Contrairement à l'aérien, qui dispose des GDS, le système des tour-opérateurs exige encore souvent un travail à la main. Sur le marché allemand, des personnes ont réalisé une sorte de GDS appliqué aux tour-opérateurs.

Comment se passe le processus d'une commande dans votre back-office ?
Une fois l'acceptation du client donnée, nous procédons aux réservations en alertant le tour-opérateur, puis nous encaissons l'argent et effectuons le suivi des factures de nos fournisseurs de manière à générer tous les mouvements comptables nécessaires. Ces procédures sont traitées par deux applications différentes écrites en Visual Basic .Net.

La première se charge de la gestion de la commande, la seconde de la partie post-validation des commandes et suit l'ensemble des flux comptables clients - ventes, avoirs, encaissements, remboursements - et fournisseurs - provisions, réception des factures, paiements.

Pour l'instant, alerter le tour-opérateur d'une réservation implique soit de l'appeler au téléphone, soit de se connecter à un site B-to-B. Pour certains, nous disposons d'un accès direct à leur système, mais il n'y a pas vraiment de règle. La partie encaissement client est confiée à la solution Paybox pour laquelle nous avons une connexion. Enfin, les écritures comptables sont envoyées sous la forme d'un fichier pour intégration dans notre système comptable, PeopleSoft.

Sur la partie vol, quels ont été les travaux réalisés ?
L'émission des billets passe par le langage de script de notre GDS"
Nous récupérons directement les réservations opérées par la plate-forme gérées par les Etats-Unis. Ensuite, nous procédons à l'émission puis à l'envoi des billets. Et enfin à la réconciliation des données BSP avec celles de notre système.

Nous avons écrit le script d'émission à partir des outils de scripting fournis par le GDS WorldSpan Il existe aussi des batchs annexes pour récupérer les états de caisse ou bien les messages comptables et mettre à jour notre base SQL. Les nouveaux batchs sont écrits en VB .NET, les anciens en VB 6. Nous portons d'une version à l'autre uniquement si des modifications fonctionnelles sont nécessaires.

Pourquoi ne pas avoir centralisé cette application aux Etats-Unis ?
Pour les vols, la partie vente est globale. La partie "fulfillment" est locale, car - notamment - l'émission des billets nécessite une licence et des autorisations nationales.

A quoi servent les tarifs négociés pour la partie vol ?
Pour les tarifs dit négociés, valables uniquement pour Expedia, la technologie a également été développée par notre équipe. Il faut revenir dix ans en arrière pour comprendre sa création. A l'époque, la société - qui s'appelait Brokair - distribuait ses tarifs négociés auprès des agences au travers de disquettes qui présentaient un simple index et des fiches textes.

Elle souhaitait les diffuser avec un moteur permettant de rechercher les offres applicables et de calculer automatiquement les tarifs en tenant compte de toutes les règles - jours de rotation, embargo, suppléments haute saison, classe de réservation, open-jaw, etc. Une première version a été réalisée sous Foxpro. Finalement, seulement un prototype en est sorti.

Puis une seconde version en C sous Linux. Puis une autre version avec une connexion GDS pour vérifier les disponibilités. Jusqu'à une version qui allait depuis la recherche / tarification / vérification des disponibilités jusqu'à la réservation dans le GDS et qui a été utilisé pour les premières réservations on-line via Minitel puis pour le Web www.anyway.com.

Quels sont vos prochains projets informatique ?
A court terme, par exemple, nous travaillons sur la connectivité avec les tour-opérateurs. Nous avons quasiment finalisé une interface complète - disponibilité et booking - avec un tour-opérateur et avons un plan de marche ambitieux pour 2006. Toujours sur les packages, nous voulons donner au client plus d'informations sur son compte et ses réservations.

La DT d'Expedia
 Les solutions technologiques 
Langage de développement
.Net, ASP
Bases de données
SQL Server
Systèmes d'exploitation
Windows / Linux
Serveur Web
IIS
Hébergement
Interne
Scripts
Visual Basic
Moteur de recherche
Développé en C
 
Propos recueillis par Yves DROTHIER, JDN Solutions

PARCOURS
 
 
Olivier Maréchal est titulaire d'un DUT Mesures Physiques à l'Université d'Orsay (1984). Il a été DSI d'Anyway d'octobre 2004 à janvier 2005, intégré depuis dans le groupe Expedia.

Son parcours :
- Technicien chez Multilog (éditeur de bases de données)
- Rédaction d'un livre 'Pratique de Multilog"
- Conception et réalisation de logiciels dans deux SSII (Alphamega et Marben Consulting Finance).
- Associé de la société Etceteris

   
 
  Nouvelles offres d'emploi   sur Emploi Center
Auralog - Tellmemore | Publicis Modem | L'Internaute / Journal du Net / Copainsdavant | Isobar | MEDIASTAY
 
 


Voir un exemple

Voir un exemple

Voir un exemple

Voir un exemple

Voir un exemple

Toutes nos newsletters