Arnaud Chain, Remedy: "Notre coeur de métier est le service client"

Fondée en 1990 sur le sol californien, Remedy a démarré ses activités en tant qu'éditeur de solutions ITSM (gestion des services informatiques) avant de s'orienter en parallèle vers la gestion de la relation client. Pour l'année 2000, la société a déclaré un chiffre d'affaires de 288,5 millions de dollars, en hausse de 26 %. Sur un effectif de plus de 1 000 employés au niveau mondial, 200 sont européens, dont 50 français. Implantée dans 80 pays différents, Remedy y sert les intérêts de près de 10 000 clients qui représentent un parc installé de plus de 2 millions d'utilisateurs. Parmi les clients français figurent notamment Alcatel CIT, la Banque de France, EDF-GDF, Bouygues Telecom, Bull, Esso, la RATP, Renault et La Poste. Les derniers contrats signés incluent Casino et le PMU. Arnaud Chain, le directeur général Europe du Sud de Remedy, .


JDNet Solutions : Vous êtes à la fois éditeur dans le domaine du CRM et d'outils de helpdesk. Pourquoi ce double positionnement ?
Arnaud Chain : Nous considérons le client presque de la même façon lorsqu'il est interne ou externe à l'entreprise. Traditionnellement, le service client interne est appelé helpdesk, et l'externe repose sur des solutions de type hotline qui font partie du CRM. Or, notre coeur de métier est le service client, et nous sommes leader sur cette partie.
Nous proposons donc deux offres distinctes. La première s'adresse au service client interne et couvre notamment la gestion des incidents, des problèmes réseaux et la gestion de parc. La seconde est une solution de gestion des interactions client, qui intègre aussi bien les aspects d'automatisation des forces de vente que de gestion des campagnes marketing. De ce côté-là, nous venons aussi de lancer une nouvelle offre dédiée à la personnalisation des sites web.


Proposez-vous un même noyau technologique de base dans vos deux lignes de progiciels ?
ARS, notre moteur de workflow, est appliqué à l'ensemble de nos solutions. Il s'agit de notre technologie de base, que nous avons commencé à élaboré dans nos premiers outils sortis en 1990-1991. Au départ, notre objectif consistait à fournir un outil de développement d'applications gérant les processus, avec l'ensemble des composants nécessaires pour construire un workflow. Le premier domaine d'application de cette technologie s'est avéré être le helpdesk.
A l'époque, ces applications n'étaient pas réalisables avec un environnement de type PowerBuilder. Les L4G, les langages de quatrième génération pour les applications transactionnelles, comprennent des langages spécifiques au workflow comme ARS (Action Request System). Dans le contexte des L4G, une tâche est divisée en sous-tâches, lesquelles vont se subdiviser en plusieurs étapes, ce qui permet par exemple d'engager des processus d'escalade.


En quoi ARS est-il différent d'un autre L4G ?
ARS est un langage de développement consacré au workflow sur les bases de données standards du marché. Dans ce cadre, nous nous focalisons sur l'écriture des règles de workflow, alors que les autres L4G s'intéressent d'abord à la structure de données. Notre démarche est donc inverse, car ce n'est qu'après avoir défini le workflow que nous créons la structure de données.


Pourquoi procédez-vous de la sorte ?
Les applications de front-office présentent des modèles de données qui évoluent très rapidement. Dans les faits, la personne qui déclenche le processus est le plus souvent extérieure à l'entreprise. Et le commercial qui veut se tenir au courant des derniers changements a besoin d'une communication suivie et non par étapes. Or, pour que cela soit possible, il faut soit créer une vue consolidée, soit actionner son propre workflow physiquement en appelant les personnes concernées au téléphone.
Dans le domaine du front-office, qui intègre notamment la gestion de la relation client, l'intérêt du workflow est que chaque personne concernée peut obtenir en même temps les mêmes réponses. Dans les applications de back-office, en revanche, le workflow est simplissime car les processus ne nécessitent pas vraiment d'intervention humaine.


Allez-vous proposer un portail d'entreprise personnalisé pour permettre aux utilisateurs de bénéficier justement d'une vue consolidée ?
Nous sommes en train de le construire et sa commercialisation est prévue pour le deuxième trimestre 2001. Pour l'instant, nous avons déjà toutes les technologies qui permettent de le faire tourner, mais nous n'avons pas encore défini l'interface. Nous allons y inclure un principe de notification avec la mise à disposition d'informations de façon proactive. Par exemple, si le support technique d'une société de services a rencontré un problème dans l'implémentation d'un logiciel chez un client, le service commercial le sait automatiquement.


N'existe-t-il pas d'autres façons, plus simples, d'arriver aux mêmes résultats ?
L'objectif est de générer la structure de données en temps réel. Prenons l'exemple d'une société de trading en ligne, dont les règles changent tout le temps. Le modèle de données doit savoir évoluer très vite, et ne doit donc pas être bâti sur du rigide. En fait, les outils eux-mêmes doivent être adaptables très rapidement. Car parfois, il suffit d'entrer un nouveau produit dans la base pour qu'intervienne toute une chaîne d'incidents.
Dans le cadre d'un rachat, il faut intégrer la nouvelle structure dans la société existante. Cela sous-entend la mise en place d'un circuit différent car la structure née de la fusion est différente d'auparavant. De fait, l'une des principales forces de nos applications réside dans le fait qu'elles sont construites sur la base d'un langage où le workflow est présent au premier plan. Dans le contexte d'un L4G classique, il faut rentrer dans la complexité de l'application, ce qui rend difficile les modifications. Comme il s'agit de code compilé avec des triggers et des procédures stockées dans la base, les applications de back-office deviennent rigides. En ce qui nous concerne, nous déterminons quels sont les invariants et nous menons une réflexion de type "qu'est ce qui ne va pas changer ?".


En ce qui concerne la gestion de la relation client, qu'est ce qui différencie votre offre de celles d'acteurs majeurs comme Siebel ou Vantive ?
Nous pouvons répondre à un besoin rapide, comme celui des sociétés de trading en ligne. Par exemple, nous fournissons une application permettant de suivre les interactions clients dans les centres de contacts. Grâce à notre architecture, nos partenaires peuvent mettre en place le centre de contacts en trois mois là où la plupart des produits concurrents réclament entre 6 et 9 mois pour l'implémentation.
D'une part, cela vient du fait qu'ARS s'interface rapidement avec l'ensemble du système d'information. Il faut pouvoir se coupler à la gestion de fax, des e-mails, etc., et les développeurs reconnaissent tous la facilité d'interfaçage des produits Remedy.


En matière de helpdesk, quelle est votre cible ?
Notre approche est davantage tactique que liée aux contrats produits. L'e-business a passé les étapes de la maturité pour en arriver aujourd'hui au stade des grands projets. Avec notre technologie ARS, nous savons nous adresser aux grands comptes.
Du côté de la gestion des services informatiques, les grandes entreprises sont clairement notre cible, en particulier sur des projets de consolidation. Très souvent, l'informatique interne s'est développée service par service, mais dans les grands comptes la problématique est plus globale. Il ne suffit pas de gérer les incidents et les changements, mais aussi les ressources informatiques. Cela suppose donc une gestion de parc et un helpdesk avec un mode réactif. Enfin, deux éléments plus intelligents sont aussi devenus indispensables. Il s'agit de la gestion des contrats de service avec la définition d'un niveau de qualité minimal, et de la gestion des changements en amont. Car si la veille de la mise à jour d'un logiciel, le routeur a changé, des problèmes importants risquent de se poser. Dans ce cadre, nous nous couplons à des applications comme HP OpenView qui assurent la supervision des réseaux.
Enfin, les PME ne constituent pas, pour nous, la priorité actuelle. Notre offre commerciale est aujourd'hui mal adaptée, d'un point de vue tarifaire notamment, pour opérer avec succès sur ce secteur. Par ailleurs, d'autres fournisseurs concurrents, disposant d'offres plus appropriées ont plus de pertinence sur ce marché.


Avant d'intégrer l'équipe de direction de l'éditeur américain Remedy en 1999, Arnaud Chain a occupé différents postes à responsabilités commerciales et marketing, aussi bien chez Gemplus où il a assumé la fonction de directeur marketing de 1990 à 1992, que chez Oracle France entre 1992 et 1999. Il rejoint alors Remedy, où il passe 18 mois au poste de directeur marketing Europe avant d'être nommé directeur général Europe du Sud . A 39 ans, sa mission consiste aujourd'hui à développer et asseoir la présence de l'éditeur sur la partie sud du vieux continent, en particulier dans les grandes entreprises et sur le marché de la gestion de la relation client.