=Cinquin.Livre Page 233 Mercredi, 9.

janvier 2002 3:09 15

Chapitre 13

Étude de cas no1 :

l’agence de voyages
B2B

Le contexte

Contexte général
La vente de voyages est un secteur très concurrentiel qui a tout naturellement
investi Internet où les sites de voyagistes naissent et meurent très rapidement.
Parmi ces acteurs virtuels, seuls survivent ceux qui apportent un réel service et
qui ont une capacité de croissance significative.
Depuis l’an passé, on assiste à un important mouvement de concentration.
On peut citer des rapprochements récents, comme la prise de participation
de Vivendi dans le capital de l’agence de voyages Expedia ou le rachat de
Dégriftour par LastMinute.com. Ce secteur s’appuie largement sur les four-
nisseurs de services de réservations, les Global Distribution Services (GDS).
Les GDS ont longtemps misé sur le marché grand public, délaissant le
marché interentreprises (Entreprise Travel Management ou gestion des voyages
d’affaires). Amadeus a acheté un grand site du voyage d’affaires pour entrer
de plain-pied dans les échanges B2B. Ces concentrations se révèlent plutôt
bénéfiques et le tourisme online affiche une santé remarquable, en termes de
parts de marché sur le secteur du tourisme. D’une part, le commerce de biens
immatériels se prête bien aux spécificités d’Internet, d’autre part, le volume
et la fréquence d’achats garantissent aux sites Web un chiffre d’affaires élevé.
Pour le cabinet d’études Forrester, ce secteur d’activité est l’un des plus
prometteurs de l’eCommerce. Il devrait générer le chiffre d’affaires le plus
important d’ici 2003 (35 milliards de dollars aux États-Unis), avec une crois-
sance de 73 % d’ici à cinq ans, selon le cabinet IDC. De son côté, Mc Kinsey y
voit une opportunité forte pour le développement de l’infomédiation.

233
=Cinquin.Livre Page 234 Mercredi, 9. janvier 2002 3:09 15

Le projet eCRM

Remarque
Un infomédiaire est acteur capable de fournir des données spécialisées dans l’intérêt
des producteurs de biens ou services et de leurs clients potentiels. Ce terme est une
contraction de information et intermédiaire.

La proposition de valeur des voyagistes sur Internet se situe à deux niveaux :

• Une offre qui agrège des prestations élémentaires sur la base de préférences
individuelles déclarées par les clients.
• Une relation de confiance pour fidéliser le client et faciliter l’acte d’achat.
L’exploitation pertinente de ses préférences tend à reproduire la relation
qu’il aurait avec un conseiller dans une agence.

L’agence de voyages B2B

La présente étude de cas porte sur une agence de voyages dont le réseau de
distribution se résume à la mise à disposition d’un service à destination des
entreprises sur le Web. Nous l’appellerons MesVoy@gesPro.

La cible
L’agence s’adresse à une clientèle d’entreprises dont le volume d’affaires n’atteint
pas les seuils qui permettent de négocier les tarifs en direct avec les fournisseurs,
par exemple avec Air France. Les PME/PMI de moins de 500 employés, avec des
localisations géographiques multiples et éloignées, sont les premières entre-
prises cibles de MesVoy@gesPro.
Dans notre exemple, l’entreprise A, cliente de MesVoy@gesPro, a son siège social
à New York (40 personnes), possède un site de production à Gennevilliers dans le
nord de Paris, et sous-traite une partie de sa production à une usine de Gatwick,
en banlieue londonienne. Elle dispose aussi d’un bureau de vente européen avec
15 personnes à Bruxelles, en Belgique. Les cadres de cette entreprise font
régulièrement des allers et retours New York-Paris, ou New York-Londres, ainsi
que des voyages intra-européens, dans le périmètre Londres-Paris-Bruxelles.
La figure 13-1 illustre les différents voyages des cadres de l’entreprise A.
Exerçant une activité internationale, l’entreprise A gère des clients sur les cinq
continents, où elle envoie ses cadres ponctuellement.

Le Business Model
Comme toutes les agences de voyages, MesVoy@gesPro prélève une commission
sur les prestations vendues. Toutes les négociations se déroulent donc en deux
temps : d’abord entre MesVoy@gesPro et les différentes compagnies aériennes,
hôtelières, etc., puis avec les entreprises clientes pour des remises individualisées.
Le modèle est résolument B2B, plus précisément dans la vente de services de
réservation de voyages aux professionnels. MesVoy@gesPro n’a pas vocation à
proposer des prestations de loisir touristique. Son métier consiste à agréger
aussi efficacement que possible trois types de prestations :
• transport : réservation de billets d’avion et de train essentiellement ;
• hébergement : réservation de chambres d’hôtel ;
• location de voiture.

234
=Cinquin.Livre Page 235 Mercredi, 9. janvier 2002 3:09 15

Chapitre 13 – Étude de cas no 1 : l’agence de voyages B2B

Figure 13-1.
Voyages des cadres
de l’entreprise

Usine de Gatwick

Siège social de New York

Clients
Usine de Gennevilliers

Le « Business Model » peut se schématiser comme dans le figure 13-2.

Figure 13-2. Business model de MesVoy@gesPro

235
=Cinquin.Livre Page 236 Mercredi, 9. janvier 2002 3:09 15

Le projet eCRM

Les négociations sur les prix

La négociation avec les entreprises clientes se fonde sur les prix publics des
vols. Bien qu’elles n’aient pas de levier de négociation face aux compagnies
aériennes, elles peuvent discuter annuellement de tarifs préférentiels avec
MesVoy@gesPro, en fonction du volume de l’année précédente, ou sur l’année
en cours. Les prix pourront être fixés pour les destinations régulières, par
exemple pour les déplacements de Paris vers l’usine de Gatwick, ou de Paris
vers le siège social de New York. Des conditions préférentielles peuvent
également être consenties en déterminant les chaînes d’hôtels ainsi que les
compagnies de location de voitures par défaut. L’ensemble des prestations
négociées sera géré au travers de contrats.

L’utilisation des données privées dans la sphère professionnelle

Comme nous l’avons vu, le site MesVoy@gesPro s’adresse à des collaborateurs
de l’entreprise qui peuvent préparer leurs voyages d’affaires à distance. Pour
leur proposer des offres pertinentes et innovantes, MesVoy@gesPro va
exploiter les données professionnelles et personnelles de ses clients. Il est
important de cerner ici les incursions de MesVoy@gesPro dans la sphère privée :
• Un système de fidélisation à base de points, utilisables à titre personnel
pour des réductions sur d’autres voyages.
• Des prestations de transport/hébergement/location de voiture, proposées à
titre privé (par exemple, l’organisation de vacances en famille, avec des
services similaires à ceux que l’employé se verrait proposer par une agence
de voyages traditionnelle).
• Des offres promotionnelles incitant à prolonger les voyages d’affaires par
des week-ends sur place, avec des conditions préférentielles pour le
conjoint. Il s’agit là d’une approche marketing de type cross et up-selling.
Par exemple, si le siège de la société est à New York et si le voyage de
l’employé se termine en fin de semaine, son conjoint le rejoindra, ils passe-
ront le week-end ensemble et ils repartiront le dimanche soir.
MesVoy@gesPro ne doit pas devenir trop intrusif par rapport à ses entreprises
clientes, et la pression commerciale ne doit surtout pas être contre-productive
pour leur personnel. Cela implique donc un marketing soigné, sans incitation
franche aux activités extra-professionnelles. Par exemple, l’envoi d’e-mails non
sollicités pour des promotions de voyages exotiques est à exclure.

Les enjeux opérationnels

Les enjeux opérationnels découlent de besoins de nature différente qui sont
listés dans la suite de cette étude.

La gestion des unités de structures des clients

Dans un souci de décentralisation de la gestion des comptes à des fins de flexi-
bilité, les utilisateurs de chaque entreprise cliente de MesVoy@gesPro sont
répartis en trois catégories (voir figure 13-3) :

236
=Cinquin.Livre Page 237 Mercredi, 9. janvier 2002 3:09 15

Chapitre 13 – Étude de cas no 1 : l’agence de voyages B2B

• Les administrateurs ont la possibilité de créer des utilisateurs au sein même

de l’entreprise, ainsi que d’en définir les niveaux d’habilitations.
• Les utilisateurs, classés en deux groupes disctincts :
– Les utilisateurs de niveau 1 qui ne peuvent pas excéder une limite de
commande de 3000 euros.
– Les utilisateurs de niveau 2 qui sont habilités à effectuer des commandes
supérieures à cette limite.

Figure 13-3. Éléments de structure

L’activité et le mode de fonctionnement de MesVoy@gesPro doivent refléter

ces deux types de clientèles. Toutefois, MesVoy@gesPro n’a pas vocation à faire
de l’eProcurement. Cela exclut donc une réflexion poussée sur des logiques
d’habilitations complexes avec des notions de workflow de validation, de
délégation, de groupes d’utilisateurs sous dépendance hiérarchique.

La gestion des profils utilisateurs

Chaque entreprise et chaque utilisateur donnent des informations relatives à
leur environnement qui vont constituer des profils. L’utilisateur transmet des
informations sur son profil de voyageur professionnel. Le profil utilisateur sera

237
=Cinquin.Livre Page 238 Mercredi, 9. janvier 2002 3:09 15

Le projet eCRM

à la base du mécanisme de personnalisation des offres proposées par

MesVoy@gesPro.
Données de l’utilisateur
L’utilisateur de l’entreprise cliente donnera les informations suivantes :
• ses compagnies préférées pour chaque type de prestation dans la liste
établie par l’entreprise : avion, hôtel, location de voiture ;
• les différentes cartes de fidélité dont il est titulaire (par exemple, celle du
programme Fréquence Plus d’Air France, la carte Europcar, celle des hôtels
Hilton, etc.) ;
• son aéroport habituel de départ ;
• ses voyages récurrents, mais à des prix non négociés : par exemple, des
préconfigurations de déplacements vers les nouveaux clients, les voyages à
Bruxelles dans la journée, deux jours de réunion à Londres (une liste de
souhaits générique).
Données de l’entreprise
Certaines informations de profil sont fixées par l’entreprise cliente : pour les
utilisateurs de niveau 2, les vols se font en classe affaires. Ces éléments simpli-
fient le processus de commande lors de prestations ultérieures.
On peut pousser plus loin l’intégration de ces informations de profil : par
exemple, quand l’utilisateur réserve une nuit d’hôtel via MesVoy@gesPro, ses
préférences sont également communiquées aux partenaires : repas végétarien,
lit « king size », prise réseau, etc.

La personnalisation du site
Animation commerciale du site
Dans une zone de l’interface prévue à cet effet, le site suggère d’autres possibi-
lités par rapport au voyage projeté. Cette fonctionnalité sera présentée comme
la zone « conseiller ». Par exemple, pour un trajet Paris-Bruxelles, si l’utilisa-
teur a choisi l’avion, le conseiller peut lui signaler que le Thalys est moins cher,
voire plus rapide de porte à porte (ne pas oublier les temps d’attente aux aéro-
ports, souvent situés en lointaine banlieue ! voir figure 13-4). D’autres cas
peuvent être considérés, comme la prolongation du voyage d’affaires dans un
week-end « plaisir ».

Règles métiers et services d’optimisation

Un certain nombre de règles métiers peuvent être imaginées afin de valoriser
le service rendu au client. Par exemple :
• Règle no1 : s’il n’y pas de vol disponible aux horaires demandés, tôt le matin,
par exemple, le site proposera un vol prévu la veille en exploitant une
promotion hôtelière ;
• Règle no2 : s’il n’y a plus de voiture disponible en catégorie H chez Avis, le
site conseillera une catégorie F, ou alors passera dans une catégorie équiva-
lente chez Europcar. Cela permet de faire bénéficier les clients des programmes
de fidélisation des fournisseurs.

238
=Cinquin.Livre Page 239 Mercredi, 9. janvier 2002 3:09 15

Chapitre 13 – Étude de cas no 1 : l’agence de voyages B2B

Figure 13-4. Scénario de commande d’un vol et zone « conseiller »

La gestion des contrats

L’agence MesVoy@gesPro établit avec chaque entreprise cliente des relations
contractuelles qui régissent des politiques tarifaires particulières. Nous envi-
sageons ici deux types de contrats :
• Chaque année, l’entreprise cliente et MesVoy@gesPro négocient une remise
globale en pourcentage sur l’ensemble des prestations vendues pour
l’année à venir sur la base du volume d’affaires généré l’année précédente ;
• L’agence propose des packages prédéfinis (une semaine au siège social à New
York, avec avion en première classe, voiture et hôtel catégorie 1 – dates non
définies) pour une sélection de destinations convenue. Elle négocie elle-même
ces tarifs réduits avec les compagnies aériennes. Une remise supplémentaire –
une offre spéciale – est accordée aux entreprises clientes sur certaines
prestations. Par exemple, sur tous les séjours d’une semaine à New York.
Voici comment procéder à la création d’un package prédéfini :
• Destination : de A à B, classe « Eco », « Affaires », ou selon utilisateur
(1 ou 2) , compagnies ;
• Hôtels (trois ou quatre étoiles, ou encore au choix de l’utilisateur) : liste
d’hôtels en accord avec l’entreprise ;
• Voitures : nombre de kilomètres et classe en accord avec l’entreprise.

239
=Cinquin.Livre Page 240 Mercredi, 9. janvier 2002 3:09 15

Le projet eCRM

Les enjeux techniques

À ces besoins fonctionnels s’ajoute une dimension technique. L’ensemble des
prestations offertes par MesVoy@gesPro sera obtenu à partir d’une inter-
connexion à un réseau de « Global Distribution Service » (GDS ). Il s’agira
d’Amadeus dans notre cas.
Les requêtes vers le GDS sont simples : la demande porte sur un type de trans-
port, à des dates possibles, dans certaines conditions de confort. Dès que le
type de transport ou de prestation change, une nouvelle requête au système de
réservation est lancée. Il est donc nécessaire de disposer d’un système en
frontal capable de traduire les demandes des utilisateurs en requêtes compré-
hensibles par le GDS, de les sérialiser, et enfin de consolider les résultats sous
forme d’offres cohérentes, intelligibles pour le client.
L’autre enjeu technique va être d’offrir une interface technique suffisamment
flexible pour accueillir de nouveaux entrants comme de nouveaux GDS.

La solution mise en place

L’architecture de MesVoy@gesPro
Le choix de l’architecture globale de MesVoy@gesPro passe par celui d’une
plateforme transactionnelle dont les fonctionnalités d’eCRM sont riches, pour
les besoins de la personnalisation. Le site Web fonctionne comme un portail
personnalisé pour toutes les entreprises qui s’y connecteront, positionnant la
gestion des profils (entreprises, utilisateurs) au cœur de la plateforme.
Un GDS sera connecté à cette plateforme Web via une passerelle où toutes les
requêtes seront effectuées. L’agrégation des services rendus se situe au niveau
du site Web.

Le choix d’une solution

Pour répondre aux besoins fonctionnels de MesVoy@gesPro, il convient de
choisir entre deux stratégies :
• construire MesVoy@gesPro de toutes pièces sur la base d’une infrastructure
de type serveur d’applications ;
• opter pour un progiciel du marché.
Le recours à un progiciel paraît judicieux. Le marché des plateformes eCRM
offre en effet des solutions qui couvrent correctement le besoin initial.
Mais il ne faut pas trop en demander à un progiciel. L’implémentation se
traduit par des arbitrages permanents entre le besoin fonctionnel et les possi-
bilités de l’outil, quitte à adapter le premier pour respecter la logique du progi-
ciel. À trop vouloir détourner l’utilisation d’une solution de haut niveau, on
finit par en perdre le bénéfice. S’il se révèle malgré tout indispensable de
« tordre » le progiciel, c’est sans doute que la solution n’était pas adaptée… ou
que le véritable enjeu fonctionnel a été mal identifié.

240
=Cinquin.Livre Page 241 Mercredi, 9. janvier 2002 3:09 15

Chapitre 13 – Étude de cas no 1 : l’agence de voyages B2B

La solution retenue
L’offre eCRM de BroadVision répond bien au besoin métier MesVoy@gesPro. La
solution de base propose un site évolué qui s’appuie sur un framework métier, et
une configuration de connexion au GDS Amadeus. La proposition de valeur de
l’offre Travel Commerce de BroadVision (développée conjointement avec
Amadeus) est importante, car elle fonde son modèle métier sur celui d’une
agence de voyages en ligne dont les fonctions verticales élémentaires sont bien
présentes. De plus, l’offre Travel Commerce propose un jeu de fonctions de haut
niveau qui permettent de réaliser les requêtes vers le GDS, ainsi que de procéder
à la récupération des résultats. L’agrégation des résultats de requêtes au GDS se
situe au niveau de la plateforme eCRM. Cela permet d’effectuer des traitements
qualitatifs et quantitatifs importants, tant pour les règles métiers qu’en matière
de présentation des résultats. L’offre Travel Commerce de BroadVision repose
sur le socle technique One-to-One qu’elle étend dans deux directions :
• avec un modèle de données métier (méta-schéma) orienté prestations de
voyages ;
• avec des fonctionnalités spécifiques telles que la connexion à Amadeus.
L’apport fonctionnel dans le contexte est riche, mais il ne couvre pas l’inté-
gralité des besoins exprimés, notamment pour la gestion des contrats et
l’administration déléguée (ou téléadministration), absentes de l’offre Travel
Commerce. L’offre Business Commerce, déclinée par BroadVision sur le même
socle technique, propose en standard d’enrichir cette solution en apportant de
nouvelles fonctionnalités. Les deux offres (Travel Commerce et Business
Commerce) disposent d’un modèle de données commun, ce qui permet de les
combiner, chacune apportant les spécificités dont l’autre ne dispose pas.

MesVoy@gesPro Outils retenus

Infrastructure technique BroadVision One-to-One 6.0
Solutions Métiers BroadVision Travel Commerce
BroadVision Business Commerce
Gestion de contenu BroadVision Publishing Center

Les fondations techniques

Au moment de la rédaction de ces lignes, l’intégration des deux offres
distinctes sur un socle technique unique n’est pas un exercice aisé. L’édition
Business Commerce s’appuie sur le socle technique de BroadVision 6.0,
conforme aux normes J2EE et qui inclut un moteur de JSP (Java Server Pages).
L’offre Travel Commerce est encore construite sur le socle BroadVision 5.5
utilisant la technologie Server Side JavaScript.
Cependant, l’ensemble des composants de Travel Commerce sont disponibles,
aussi bien pour des accès depuis des pages en Server Side JavaScript que depuis
des JSP classiques. Le modèle d’implémentation retenu peut ainsi être celui
d’une application J2EE. Il permet de se fonder sur la version 6.0 de BroadVision.

241
=Cinquin.Livre Page 242 Mercredi, 9. janvier 2002 3:09 15

Le projet eCRM

Les outils de développement

Les différents modules et interfaces que nous allons utiliser pour implémenter
MesVoy@gesPro dans l’outil sont les suivantes :
• Le Schema Center est l’outil qui permettra de visionner et de modifier le
modèle de données BroadVision. Toutes les phases de création (en parti-
culier les nouvelles entrées dans le méta-schéma) sont générées au travers
d’assistants, qui simplifient grandement la tâche. Cet outil est un client
développé en Java ;
• L’atelier de développement : l’utilisation d’une solution de type progiciel ne
dispense pas de développer les pages de présentation du site. Pour cela,
l’outil de création des JSP est laissé à l’initiative de l’équipe projet. Il en est
de même pour le développement de classes Java supplémentaires.

Les interfaces de paramétrage et de pilotage

Le Command Center, destiné à des non-techniciens, est le principal outil de
gestion du site MesVoy@gesPro. Il permet de développer et modifier les règles
métiers actives sur le site Web, de gérer les offres promotionnelles, les profils
d’entreprises et d’utilisateurs par le biais de communautés, ainsi que les
contrats. Comme pour le Schema Center, toutes ces étapes sont prises en
charge via des assistants de création. Cet outil peut être utilisé depuis un client
Windows qui accède à la plateforme via le protocole IIOP, ou depuis un client
léger Web.
Le Command Center est également accessible dans sa version Web. Cette
dernière permet notamment de modifier les habilitations des entreprises
clientes, de visualiser les caractéristiques des contrats et de créer des règles
simples.
De plus, l’interface Web du Publishing Center permet une gestion simplifiée
des contenus, et plus particulièrement ceux des offres promotionnelles.

L’architecture de l’outil
• L’architecture de BroadVision One-to-One Enterprise 6.0 se décline sur le
modèle d’architecture à trois niveaux des serveurs d’applications. Le
support du standard J2EE par la plateforme BroadVision permet l’utilisation
des technologies Java et de ses modèles d’architecture pour l’écriture de
code spécifique (voir figure 13-5).
Nous invitons le lecteur à consulter la fiche produits dans le panorama des
acteurs du marché pour la description complète de la gamme BroadVision.

242
=Cinquin.Livre Page 243 Mercredi, 9. janvier 2002 3:09 15

Chapitre 13 – Étude de cas no 1 : l’agence de voyages B2B

Figure 13-5. Architecture de la solution BroadVision Travel Commerce

L’implémentation dans l’outil

Le déroulement séquentiel des étapes d’implémentation décrit la construction

du site jusqu’à son déploiement.

L’extension du méta-schéma
Le méta-schéma décrit la structure du référentiel des données de l’application
(voir figure 13-6).
L’offre Travel Commerce propose son propre méta-schéma métier. Il est aisé-
ment extensible pour répondre à des besoins additionnels. Cette opération est
réalisée au travers de l’interface Schema Center.

243
=Cinquin.Livre Page 244 Mercredi, 9. janvier 2002 3:09 15

Le projet eCRM

Figure 13-6. Extension du méta-schéma de BroadVision

Dans l’exemple précédent, nous réalisons l’extension du modèle de données

de l’édition Travel en rajoutant un attribut au sein du Schema Center.
Une telle manipulation génère en fait des scripts SQL, qui seront appliqués au
modèle de données sur lequel se basent les différents services BroadVision.

L’interaction avec les données du référentiel

Cette interaction est possible au niveau du Command Center ou au travers
d’une interface Web.

Interactions au travers des interfaces de gestion : la création

d’une communauté d’utilisateurs
Une communauté se définit comme un ensemble d’utilisateurs qui ont des
caractéristiques identiques : par exemple, les « Voyageurs privilèges », qui
auront accumulé plus de 10 000 euros de commandes.
C’est au travers d’une interface client léger ou Windows que nous allons
pouvoir créer une communauté. Dans l’écran suivant, la communauté est définie
sur la base de valeurs prises par certains attributs des utilisateurs :
Preferred Air Class = First Class et Total Amount Purchase > 10 000 euros.

244
=Cinquin.Livre Page 245 Mercredi, 9. janvier 2002 3:09 15

Chapitre 13 – Étude de cas no 1 : l’agence de voyages B2B

La figure 13-7 présente l’interface Windows.

Figure 13-7. Création d’une communauté dans le Command Center

Interaction avec les données du référentiel dans les pages JSP

Les interfaces de gestion permettent de configurer l’organisation et les règles
métiers qui régissent le site. En revanche, elles ne permettent pas de gérer, par
exemple, les données relatives aux utilisateurs. Cela est pris en charge par
l’application. En effet, BroadVision propose une couche de persistance sur la
base du méta-schéma. La manipulation de requêtes SQL et la gestion manuelle
de la persistance des données sont ainsi épargnées.
L’extrait de code suivant permet d’interagir avec des données présentes dans
le référentiel. Pour en donner une meilleure compréhension, nous l’avons
commenté :
// import des composants Java de BroadVision
import com.BroadVision.components.builtin.*;
import com.BroadVision.components.bv.visitor.*;
try {
// récupération du visiteur courant via le framework BV
BVI_Visitor visitor = bean_common.getVisitor();
// déclaration des variables
String name = "Jean Philippe MARTIN;
String email = "jpmartin@octo.com";
long age_range = 30;

245
=Cinquin.Livre Page 246 Mercredi, 9. janvier 2002 3:09 15

Le projet eCRM

// affectation des propriétés de l'utilisateur courant

visitor.setStringProperty("NAME", name);
visitor.setStringProperty("EMAIL", email);
visitor.setLongProperty("AGE_RANGE", age_range);
//lecture des propriétés de l'utilisateur courant
name = visitor.getStringProperty("NAME");
email = visitor.getStringProperty("EMAIL");
age_range = getLongProperty("AGE_RANGE");
} catch (Exception ex) {} // fixe les erreurs de compil.
}

La création de package de destinations favorites

Création d’une offre spéciale
Comme nous l’avons vu, la gestion de catalogues de destinations est pro-
blématique en raison du caractère immatériel des prestations proposées.
BroadVision contourne cette difficulté en proposant de créer des offres spé-
ciales qui pourront être cataloguées sur le site Web à partir de la définition de
vols, d’hôtels, de dates ou de périodes spécifiques.
Prenons l’exemple de l’offre d’un week-end prolongeant une semaine de
voyage d’affaires à Londres au départ de Paris.
Toujours dans le Command Center, on définit ce que l’on souhaite faire inter-
venir dans l’offre : le nom de l’offre, son état de publication ( online ou offline), les
dates de début et de fin de l’offre… Il est possible de « précontraindre » un
certain nombre de valeurs et de laisser libre des champs comme les dates
d’aller et de retour, la compagnie aérienne préférée (voir figure 13-8).
Ces éléments étant maintenant des constantes, seules les dates de départ et
de retour seront les variables (toutes les configurations avec voiture de loca-
tion peuvent être imaginées, nous laissons ici le soin au lecteur de les extra-
poler). Cela va grandement faciliter le passage de la commande, car les
utilisateurs n’auront plus qu’à fixer les dates de leur voyage. De plus, les prix
de ces packages auront été négociés par l’entreprise auprès de MesVoy@gesPro.
Dans notre exemple, nous allons définir trois types d’offres spéciales que sont
les voyages :
• au départ de Paris vers Bruxelles ;
• au départ de Paris vers Gatwick ;
• au départ de Paris vers New York.
La phase de création de ces offres spéciales par l’administrateur de
MesVoy@gesPro est prise en charge par un assistant de création au sein du
Command Center. Nous avons fourni les paramètres définis plus haut pour
chacune des trois offres qui sont liées à l’entreprise A. Nous pouvons définir,
selon le profil de l’utilisateur (de niveau 1 ou 2), le type de confort par défaut
qui sera choisi. La vue synthétique du Command Center nous permet d’apprécier
les offres ainsi rendues disponibles (voir figure 13-9).

246
=Cinquin.Livre Page 247 Mercredi, 9. janvier 2002 3:09 15

Chapitre 13 – Étude de cas no 1 : l’agence de voyages B2B

Figure 13-8. Visualisation d’une offre spéciale « prolongation de week-end à Londres »

Figure 13-9. Vue récapitulative des Special Offers pour l’entreprise A

La vue du client
Le client s’authentifiera sur le site MesVoy@gesPro, puis ira sur l’onglet Special
Offers pour visualiser la liste des offres spéciales disponibles pour son entre-
prise. Dans notre cas, le client appartient à la catégorie « Utilisateur de
niveau 2 ». Il peut donc, rappelons-le, voyager en classe affaires et commander
des voyages dont le montant est supérieur à 3000 euros. Si c’est un voyage
Paris-New York qu’il souhaite, il l’organisera ainsi via cette interface (voir figure
13-10).
On remarque que le voyage est conforme à l’offre spéciale, de Paris à New York,
en première classe sur Air France, dates ouvertes.

247
=Cinquin.Livre Page 248 Mercredi, 9. janvier 2002 3:09 15

Le projet eCRM

Figure 13-10. Interface Web de commande d’une offre spéciale

La gestion des contrats

Dans le modèle métier de BroadVision, les contrats sont définis comme une
sélection d’un produit spécifique et d’un prix associé. Les dénominations au
sein de l’outil sont le Product Program (une vue « customizable » sur le catalogue)
et le Pricing Program (voir figure 13-11).
Il convient donc de définir :
1. le Product Program (qui contient les Products terms) ;
2. le Pricing Program ;
3. le contrat qui associera ces deux éléments.

248
=Cinquin.Livre Page 249 Mercredi, 9. janvier 2002 3:09 15

Chapitre 13 – Étude de cas no 1 : l’agence de voyages B2B

Figure 13-11.
Schéma de dépendance
fonctionnelle
Co
de l’élément Contrat ntr
ats

Pr Pr
od
uc ram ici
ng ram
t Pr
og og
Pr

Pr
od
uc
t Term

!
Avertissement

Of e
fre ial
éc
sp

Définition du Product Program

Le Product Program permet de sélectionner les offres spéciales en fonction des
entreprises clientes, par exemple, « voyage de Paris au siège à New York en
semaine» et « voyage de Paris à Londres » (voir figure 13-12).

Figure 13-12.
Définition
du Product Program

249
=Cinquin.Livre Page 250 Mercredi, 9. janvier 2002 3:09 15

Le projet eCRM

Définition du Pricing Program

Le Pricing Program, quant à lui, définit une politique de prix, par exemple (voir
figure 13-13) :
• « Simple », soit une réduction de 10 % sans lien avec le volume d’affaires ;
• « par paliers », soit 10 % de réduction pour une commande de une à
dix unités, 20 % entre onze et quinze...
• et enfin un autre mode « Tiers », plus flexible : pour une commande de 1 à
10 unités, 10 % de réduction, de 11 à 25, 15 %, etc.

Figure 13-13 :
Validation via un écran
récapitulatif

Création du contrat
Un contrat s’applique à une société ; il associe une formule de Pricing Terms
avec un ou plusieurs Product Programs. L’appel de l’assistant de la création du
contrat permet de réaliser l’ensemble de ces tâches (voir figure 13-14).
Notre contrat apparaît maintenant dans le Command Center, parmi les autres
contrats déjà existants. Cette facette du Command Center sera l’outil privilégié
du responsable de compte MesVoy@gesPro pour créer/ gérer les contrats en
cours. Lorsqu’il faudra opérationnellement gérer les contrats, assigner des
rôles, saisir les informations de contact, la déclinaison Web du Command
Center sera plus adaptée (voir figure 13-15).

250
=Cinquin.Livre Page 251 Mercredi, 9. janvier 2002 3:09 15

Chapitre 13 – Étude de cas no 1 : l’agence de voyages B2B

Figure 13-14. Sélection des offres spéciales

Figure 13-15. Vue récapitulative de l’ensemble des contrats via le Command Center

L’implémentation de la zone d’animation commerciale

Il nous faut disposer d’une zone de conseil en ligne, appelée « Conseiller », qui
proposera au visiteur des contenus en rapport avec leur commande.
Une zone du site sera prévue pour l’affichage de ces contenus. Le comporte-
ment de cette zone sera régi par des règles de personnalisation, regroupées
dans un containeur à règle (RuleSet) dédié.
Pour que le résultat du RuleSet soit affiché dans la zone prévue, il faut qu’il soit
ancré dans le code de la page qui accueille la zone.

251
=Cinquin.Livre Page 252 Mercredi, 9. janvier 2002 3:09 15

Le projet eCRM

Cette opération nécessite l’écriture de code Java. Elle est réalisée une seule fois
au cours du développement du site Web. En revanche, l’ajout ou la modifica-
tion de règles pour la zone « conseiller » pourront être réalisés à tout moment
par un responsable opérationnel au travers du Command Center.
Les stratégies et possibilités de création de règles sont très nombreuses.
Dans cette sous-partie, nous allons créer la règle qui va permettre de proposer
une extension du voyage d’affaires au week-end, si le retour de ce voyage est le
vendredi. Si la règle est vérifiée, un contenu éditorial s’affichera alors sur une
zone « Conseiller » au moment de la commande.

Création du RuleSet
Le RuleSet est un containeur qui permet de regrouper les règles qui s’ap-
pliquent à une zone donnée. Dans le cas présent, le RuleSet « Zone Conseiller »
contiendra les règles de personnalisation de la zone « Conseiller ».
La première étape de la création du RuleSet s’effectue au travers du Command
Center par l’appel à l’assistant de création. La première information à rensei-
gner est le « matching type », à savoir le type de donnée qui doit être retournée
dans la zone « Conseiller ». Dans notre cas, il s’agit d’un contenu éditorial (voir
figure 13-16).

Figure 13-16.
Création du RuleSet

Pour finir cette séquence, il faudra nommer ce RuleSet. Nous l’appellerons

« Zone Conseiller » (voir figure 13-17).
L’ancrage du RuleSet consiste à effectuer l’appel du déclenchement des règles.
L’appel du RuleSet est donc réalisé par écriture de code Java dans la JSP qui
contiendra la zone « Conseiller ». Cette indirection permet au responsable
opérationnel de créer ou modifier les règles à tout moment, au travers de l’outil
de définition des règles (Command Center). Le code Java spécifie l’exécution
du RuleSet et l’affichage des contenus retournés par ce dernier.

252
=Cinquin.Livre Page 253 Mercredi, 9. janvier 2002 3:09 15

Chapitre 13 – Étude de cas no 1 : l’agence de voyages B2B

Figure 13-17.
Écran récapitulatif et
ancrage du RuleSet

La méthode « matchContent( ) » de l’API permet d’exécuter un RuleSet et d’obtenir

en retour les contenus à afficher. Les paramètres d’entrée sont les suivants :
• Collection : nom du RuleSet dans le Command Center ;
• Service : instance de catalogue ;
• ContentType : type de contenu à renvoyer (publicité, contenu éditorial…) ;
• Visitor : instance de l’objet « visiteur » en cours ;
• SessionProfile : objet modélisant le comportement de l’utilisateur au cours
de sa session ;
• Count : nombre maximal de contenus en retour.
Ce qui se traduit par :
// instanciation du Matching agent
BVI_MatchingAgent myMatchingAgent = new
BVI_MatchingAgent();
// instanciation de l’objet qui recevra la liste de contenu
BVI_ContentList myContentList = null;
try {
myContentList = myMatchingAgent.matchContent
("Zone Conseiller", // Nom du RuleSet
"MesVoy@gesPro", // Service
"EDITORIAL", // Type de contenu
visitor, // Visiteur courant
session.getSessionProfile(), // Contexte de session
10); // Nombre maximum d'items
} catch (Exception e) {}
[...]
// instanciation de l Observation Manager = module d'obser-
vation métier

253
=Cinquin.Livre Page 254 Mercredi, 9. janvier 2002 3:09 15

Le projet eCRM

BVI_ObservationManager myObservationManager = new

BVI_ObservationManager();
int len = myContentList.getLength();
// boucle sur la liste de contenus éditoriaux
for (int i=0; i < len; i++ ) {
//positionnement sur le ieme contenu
myContentList.setCursor(i);
// récupération du nom du contenu
name = myContentList.getStringProperty("NAME");
[...] // affichage de ce contenu
// notification d'une action à l'utilisateur
// action de type visualisation
myObservationManager.logContent(OBSLOG_SEE,
// contexte de session
session.getSessionProfile(),
// objet contenu
myContentList.get(i)
);
}

Création de la règle
La création de la règle de personnalisation s’effectue au travers du Command
Center. Une règle de personnalisation est une règle conditionnelle du type
« si »/ « alors ». Par exemple, « SI le voyage par avion est au départ de Paris ET
à destination de Bruxelles, ALORS retourner un contenu informatif sur
Thalys ».
La définition de la condition « SI le voyage par avion est au départ de Paris ET
à destination de Bruxelles » constitue la première étape (voir figure 13-18).
La seconde étape consiste à choisir l’algorithme qui déterminera le contenu à
renvoyer si la règle est vérifiée. Dans la figure 13-19, nous choisissons « cate-
gory matching », qui requiert que l’on retourne un ou plusieurs contenus
définis par l’utilisateur.
L’assistant propose alors de valider l’ensemble de la règle via un écran
récapitulatif (voir figure 13-20).
Ces interfaces de définition de règles sont d’une très grande richesse. Leur
structuration est très bien pensée, qui permet de réutiliser des règles définies
au travers de ces très nombreux adressages.

254
=Cinquin.Livre Page 255 Mercredi, 9. janvier 2002 3:09 15

Chapitre 13 – Étude de cas no 1 : l’agence de voyages B2B

Figure 13-18. Création de la règle, écran de sélection du contenu éditorial

Figure 13-19.
Écran d’association
de catégories

255
=Cinquin.Livre Page 256 Mercredi, 9. janvier 2002 3:09 15

Le projet eCRM

Figure 13-20.
Création de la règle,
écran récapitulatif

La connexion à Amadeus
Comment tirer profit de la passerelle d’accès au service Amadeus au travers de
l’envoi de données de réservation d’un horaire d’avion ?
Les requêtes vers Amadeus sont émises au moyen de scripts qui utilisent les
API spécifiques à l’édition Travel. L’objet prend en paramètres d’entrée des
attributs définis dans la session en cours (dates d’aller et de retour, aéro-
port…), ainsi que d’autres, spécifiques au profil (par exemple, la compagnie
aérienne préférée). Le script va instancier un objet métier BroadVision (BVTJ),
qui, à partir des éléments récupérés dans la session, va créer la requête à
Amadeus. L’objet envoie cette requête à la passerelle 1A-RES via la méthode
TR_HTTP_POST. La sémantique des requêtes est donc transparente (voir
figure 13-21).
Pour récupérer et afficher les données, l’objet s’approprie la feuille de style
XSL, nécessaire à la transformation des résultats reçus en XML par Amadeus.
Ce message XML contient les informations de disponibilités des vols. Il est
alors transformé en HTML, sur le schéma imposé par la feuille XSL précé-
demment appelée. Les résultats sont ensuite directement affichés dans la
page Web.
Ce mode de communication présente les avantages suivants :
• Les feuilles XSL préservent la cohérence de présentation sur le site Web,
ainsi qu’un formatage parfait des données XML reçues d’Amadeus ;
• L’API de haut niveau de requêtage est prête à l’emploi. Il suffit d’exécuter le
script qui prend en charge ce traitement.

256
=Cinquin.Livre Page 257 Mercredi, 9. janvier 2002 3:09 15

Chapitre 13 – Étude de cas no 1 : l’agence de voyages B2B

Figure 13-21. Traitement de la requête vers Amadeus

La gestion de contenu
La gestion de contenu est assurée par les responsables opérationnels au
travers du Publishing Center. Simple à manier, l’outil contient les fonctionna-
lités essentielles à la gestion de contenu et répond aux besoins de création et
de publication sur le site Web. À ces fonctions est adossée une gestion très
simple du workflow de validation du contenu. L’administrateur peut assigner
certains rôles, comme celui de validateur ou de relecteur, à certains employés,
et notifier les tâches par e-mail. L’éditeur de contenus sert en particulier ici à
la création et à la mise à jour des informations publiés dans la zone
« Conseiller ».
L’utilisation se fait au travers d’un navigateur Web.

Les interfaces clientes mises à disposition

Gestion des comptes clients
La gestion opérationnelle des comptes clients s’effectue via une interface Web.
En réponse à notre besoin de gestion décentralisée des utilisateurs, cette
interface permet à l’administrateur de MesVoy@gesPro de définir la structure

257
=Cinquin.Livre Page 258 Mercredi, 9. janvier 2002 3:09 15

Le projet eCRM

organisationnelle de l’entreprise A et de désigner un ou plusieurs adminis-

trateurs délégués à l’intérieur de l’entreprise cliente. Un login et un mot de
passe leur permettront de s’identifier à distance afin qu’ils puissent éditer
eux-mêmes les rôles, limites et moyens de paiement des utilisateurs (voir
figure 13-22).
L’administrateur délégué de l’entreprise A (ici Daniel Smith) autorisera
certains employés de l’entreprise A à utiliser MesVoy@gesPro.

Figure 13-22. Interface Web de l’administration des comptes

En cliquant sur le bouton « New », l’administrateur peut saisir les informations

relatives à un nouvel acheteur :
• nom, prénom, adresse de facturation, numéros de téléphones ;
• département ;
• catégorie d’utilisateurs ;
• modes de paiement, etc.

Gestion des contrats et du profil de l’entreprise

Tous les utilisateurs et administrateurs délégués de l’entreprise A ont accès à une
vue sur le profil de l’entreprise, au travers de l’interface Web. Ils peuvent aussi
visualiser les contrats en cours sans droit de modification (voir figure 13-23).

258
=Cinquin.Livre Page 259 Mercredi, 9. janvier 2002 3:09 15

Chapitre 13 – Étude de cas no 1 : l’agence de voyages B2B

Figure 13-23. Écran de vue sur un contrat de l’entreprise A

L’interface d’administration permet également de définir les méthodes de

paiement de l’entreprise. Un administrateur délégué de l’entreprise A peut
ensuite assigner une ou plusieurs méthodes de paiement à un employé donné
(voir figure 13-24).

Figure 13-24. Écran d’assignation des autorisations pour un moyen de paiement défini

259
=Cinquin.Livre Page 260 Mercredi, 9. janvier 2002 3:09 15

Le projet eCRM

Conclusion

Comme nous l’avons vu, la solution de BroadVision permet l’implémentation

rapide d’un site de voyagiste. Le couplage des offres Travel Commerce et Business
Commerce autorise une riche pré-configuration d’un point de vue fonctionnel.
Néanmoins, l’enrichissement des fonctionnalités standards du site implique
un arbitrage permanent entre l’utilisation des composants métiers fournis et
un développement spécifique. Face à cette alternative, il importe de bien
mesurer les risques et restrictions. Les choix d’implémentation qui résultent
de l’analyse des besoins doivent être mûrement réfléchis. Il sera parfois néces-
saire de les adapter afin de coller au mode de fonctionnement du progiciel.
Pour doter l’application de fonctionnalités plus riches sortant du cadre standard,
des développements spécifiques seront nécessaires.
En tout état de cause, l’existence de fondations techniques solides et d’un
modèle d’architecture bien conçu sera la garantie d’une bonne visibilité sur les
possibilités d’évolution.

260