Journal du Net > Solutions >  Elie Kanaan, Mercury: "La gestion de performance est un métier d'assurance risques"
Article
 
04/05/2001

Elie Kanaan, Mercury: "La gestion de performance est un métier d'assurance risques"

  Envoyer Imprimer  

Retrouvez ici tous les articles du dossier consacré à la mesure de la performance Web

Fondée en 1989 simultanément aux Etats-Unis et en Israël, où se trouve sa première cellule de R&D, Mercury Interactive a évolué de son activité initiale, les tests en environnement client/serveur, vers la mesure de la performance des sites web à partir de 1996. Aujourd'hui, la vente de ses solutions liées à la surveillance web représente près de 75 % de son chiffre d'affaires, évalué à près de 307 millions de dollars en 2000. L'éditeur emploie environ 1 700 employés dans le monde dont une cinquantaine en France. Parmi ses offres en rapport avec la qualité de service des sites web, Topaz, et son pendant ASP (en location sur Internet) ActiveWatch, permettent de mesurer en temps réel la disponibilité et la performance. En parallèle, LoadRunner effectue des tests de montée en charge, et se décline en mode ASP derrière le nom ActiveTest. Elie Kanaan, le directeur marketing Europe de Mercury Interactive, revient sur les problématiques de la QoS (qualité de service) et vante les mérites de son positionnement.


JDNet Solutions : quelles sont les principales problématiques liées à la mesure de la qualité de service des sites web ?
Elie Kanaan : Aujourd'hui, la principale problématique se résume ainsi : les sociétés doivent être capables de mesurer l'expérience réelle de l'utilisateur lorsque celui-ci se connecte à leurs services en ligne. Et cette expérience soulève cinq questions. Les produits sont-ils accessibles de façon rapide et conviviale ? Le site inspire-t-il suffisamment confiance à l'internaute pour qu'il achète en ligne ? Le service est-il disponible lorsqu'il cherche à se connecter ? Est-il fiable et renvoie-t-il les informations attendues ? Et enfin, ce processus est-il rapide ?
Or, avec les outils classiques de mesure de la performance, nous obtenons le point de vue système et non celui de l'utilisateur.
La seconde problématique, une fois que le point de vue de l'utilisateur est connu, est qu'il faut pouvoir fournir les mesures nécessaires au diagnostic. Et ceci, à travers toutes les couches matérielles et logicielles qui composent le site en commençant par le navigateur de l'internaute jusqu'à la base de données. Sur notre site, nous disposons d'un livre blanc qui aggrège toutes les statistiques que nous avons acquises en près d'un millier de tests. Nous observons ainsi que 30 % des problèmes de performance sont dûs au réseau Internet lui-même. Ensuite, 20 % proviennent du serveur web, 20 % du serveur d'applications et les derniers 20 % de la base de données. Dans ce contexte, nous devons fournir un produit et des services qui mesurent la performance constatée par l'internaute lui-même. Et en cas de problème, nous devons approfondir dans le détail et isoler celui-ci avant qu'il ne devienne public.


Les 30 % dus à Internet peuvent-ils également être parés efficacement ?
Nous pouvons citer un grand nombre de cas où ces problèmes sont gérables. Prenons l'exemple réel d'un de nos clients, à qui son ISP a vendu un contrat lié à la fourniture de 1 Gbps de bande passante. A plusieurs reprises, nous nous sommes rendus compte de l'existence au sein du réseau d'un goulot d'étranglement. D'une manière générale avant le diagnostic, ce problème précis soulève plusieurs hypothèses. Soit l'ISP ne fournit pas la bande passante que demande le client. Soit l'un de ses routeurs est mal configuré. Ou alors, un tronçon du réseau peut aussi ne pas être disponible. Mais dans tous les cas, nous pouvons trouver la cause du problème et apporter des solutions palliatives. De façon proactive, l'ISP doit prévoir des routes alternatives afin qu'aucun incident ne survienne de ce côté-là.
Maintenant, il est évident que nous réduisons les risques mais nous ne les éliminons pas totalement. Le métier de la gestion de performance est un métier d'assurance risques. Nous pouvons aller jusqu'à 98-99 % et constater une amélioration importante. Lorsqu'il s'agit d'un gain de 15 %, l'impact est énorme.


Le chiffre de 99,9 % avancé par beaucoup d'hébergeurs est-il une réponse viable ? Existe-t-il des standards en matière de QoS ?
Pas vraiment, mais il existe néanmoins quelques chiffres qui peuvent servir. A l'époque où seule comptait la notion d'accessibilité au système, le chiffre établi disait que celui-ci devait être disponible 99,99 % du temps. Or, ceci reste valable pour les sites web, de type Yahoo ou Amazon, dont l'activité en ligne est critique. Pour ceux-ci, le manque à gagner est évident en cas de panne toutes les 20 minutes. Dans ce cadre, la société doit investir une somme à la hauteur de ses objectifs définis en matière de disponibilité.
Aujourd'hui, un autre chiffre important est celui de la performance, c'est à dire le temps de réponse vu par l'internaute. Il y a un an et demi, tout le monde parlait de la règle des 8 secondes pour l'affichage d'une page web. A présent, les Américains discutent de la règle des 4 secondes, mais je crois qu'en France, nous pouvons toujours en rester aux 8 secondes.


Quelle méthodologie proposez-vous à vos clients pour mesurer efficacement la QoS ?
Nous employons trois méthodes différentes qui sont à la fois nécessaires et complémentaires. D'une part, le module Topaz Active Agent, qui est utilisé par notre service en ligne ActiveWatch, s'appuie sur une centaine de points dans le monde - 20 en Europe - qui sont fixes et qui nous appartiennent. En outre, nous pouvons aussi ouvrir 500 points à la demande, voire d'autres à l'intérieur même de l'infrastructure du client. Chaque point de mesure se compose d'agents sur un PC connecté à un ISP, et envoie des transactions types sur le site web. Une transaction peut aussi bien être l'achat d'un produit, qu'un login ou une recherche. Si le client nous demande d'effectuer des mesures sur tel ou tel ISP à partir d'une ville ou d'un pays donné, nous plaçons les agents selon ses désirs et les tests s'effectuent en standard toutes les 15 minutes. Ceci dit, la programmation des transactions et les intervalles de mesure peuvent aussi varier en fonction de la demande du client.


Et les deux autres façons de mesurer ?
La seconde méthode se retrouve dans le module Topaz Prism. Ce produit, qui s'installe juste derrière le firewall du client, capte tout le trafic en provenance des internautes et au départ du site. Après analyse, il en dégage des temps de réponse en retraçant les routes employées par les paquets IP. De cette manière, nous mesurons un pseudo-utilisateur en observant tout le trafic réel des internautes sur le site. Et nous pouvons aller jusqu'à savoir quel ISP est en cause et combien de personnes sont touchées par le problème de performance.
Enfin, nous fournissons le module Topaz Observer aux clients VIP. Supposons qu'un constructeur automobile ait mis en place un extranet permettant à ses agences et concessionnaires, de tailles et d'importances variables, de suivre la disponibilité des pièces détachées. Avec cet outil, nous pouvons déterminer quel serveur plante chez l'un des grands concessionnaires qui connaît un problème de performance. Nous pouvons installer un agent sur un PC de l'utilisateur afin de mesurer toute la chaîne jusqu'au site et en déduire ce qui se passe réellement.


Qui sont vos clients et quels sont ceux qui demandent le plus ?
Aujourd'hui, nous travaillons surtout avec les grandes entreprises qui déploient leurs sites web. Mais si le site n'est pas critique pour leur business ou leur image de marque, ces sociétés ne vont pas dépenser beaucoup d'argent. Donc, il faut que le site soit critique et pas seulement en terme de revenus. Parmi nos clients, nous pouvons citer par exemple Alcatel et Europ@Web. Après les .fr et les .com, la tendance actuelle est celle des "dotcorps", les entreprises du "Fortune 2000". Or nous sommes historiquement positionnés sur ce segment.
Quant aux exigences de ces clients, nous en sommes aux débuts de ce marché et elles évoluent en même temps que les produits. En général, le client exprime son besoin de la façon suivante : "nous recevons beaucoup de plaintes sur le fait que notre site est un peu lent, et quand nous regardons les indicateurs, nous nous apercevons que cela fonctionne bien malgré les plaintes". Cela signifie que le département informatique ne possède pas les outils appropriés, et c'est pourquoi il fait appel à Mercury. De fait, nous arrivons et nous procédons à une démonstration qui correspond à environ 90 % de son besoin. Et plus le client entrevoit les possibilités du produit, plus il nous communique des idées d'exigences, ce qui est normal car le marché démarre. A partir de là, nous prenons les bonnes idées parmi celles-ci et nous les implémentons dans la version suivante du produit, qui est renouvellé à peu près tous les 6 mois.


Etes-vous confrontés à des exigences qui dépassent l'entendement ?
En général, contrairement à l'idée reçue, les clients sont assez raisonnables. Pour eux, une réponse à 90 % des problèmes est énorme. Un jour, nous arriverons à 100 % de réponse aux exigences, mais 90 % est déjà bien en combinant nos trois offres. Et les 5 ou 10 % restants laissent la dicussion vivante pour améliorer le produit.


Adoptez-vous dans le contexte de vos offres ASP ?
Dans le cadre de nos services hébergés ActiveWatch et ActiveTest, le client nous soumet via web ou mail ses desideratas quant au niveau de performance qu'il souhaite atteindre, et les processus de transactions qu'il désire améliorer. Après, nous effectuons tout à distance. Le client reçoit les mesures quotidiennes et se débrouille pour les analyser de son côté. S'il souhaite que nous effectuions des préconisations, nous pouvons le faire. Notre ambition est de fournir toutes les mesures, mais aussi d'analyser avec lui ces données et de lui fournir un conseil valable sur les améliorations. Souvent, ce qui lui manque sont des experts de la chaîne du web qui connaîssent les remèdes à apporter, et ce service est rarement apporté par nos concurrents.


Quel est le rôle d'une démarche de conseil en amont ?
La démarche consiste à définir quels indicateurs utiliser et quel seuil établir avant de déclarer que ceux-ci sont inutilisables. Ce sont les deux domaines où nous intervenons en accord avec le client, en lui apportant notre expérience en rapport avec ses spécificités. En ce qui concerne le seuil à établir, nous disposons d'un avantage car nous intervenons en phase amont au niveau des tests lorsque le produit est en développement, ce qui nous permet de dégager les temps de réponse fournis par l'application. Ces informations deviennent ensuite les seuils des indicateurs en phase de production.


Comment voyez-vous évoluer le marché ?
Au risque de me répéter, le marché est en plein balbutiement. A l'heure actuelle, personne ne dispose de chiffres exacts. Il s'agit pour l'instant d'un sous-ensemble du marché de la gestion de la performance en général. Ceci dit, à mon avis, le marché va exploser dans les années à venir sur le plan commercial. Car actuellement, nous observons beaucoup plus de demande que d'offre.
Quant à la segmentation du côté des acteurs, nous observons deux tendances différentes. D'une part, il y a les sociétés, comme nous, ou même Witbe et Keynote, qui ont développé une offre spécifique pour la gestion de la performance des sites web. D'autres part, les éditeurs comme BMC Software et Compuware essaient aussi de développer des offres pour le Web. Mais l'histoire nous montre que les leaders d'hier sont rarement les leaders de demain. Ceux-ci restent des acteurs importants, mais le marché devrait évoluer en faveur de structures comme la nôtre qui font preuve d'une inertie moindre.


Avant de rejoindre Mercury Interactive, Elie Kanaan a occupé divers postes chez Sybase EMEA (Europe, Moyen-Orient, Afrique). Jusqu'en 1998, il assumait les fonctions de directeur en charge des produits et solutions. Il occupait auparavant, au sein de cette même société, les postes de directeur en charge du Data Warehousing (1995-1997) et d'ingénieur technico-commercial (1990-1992). Il a débuté sa carrière chez Oracle aux Etats-Unis, en tant qu'ingénieur de développement au département Advanced Services. Diplômé de l'Ecole Centrale des Arts et Manufactures de Paris, il est également titulaire d'un mastère en informatique de l'université de Stanford.


JDN Solutions Envoyer Imprimer Haut de page

Sondage

Votre entreprise évolue-t-elle vers une informatique bimodale ?

Tous les sondages