Direct Energie déploie sa suite SOA dans l'urgence

Vincent Berdot

01 Informatique

le 05/03/2009 à 00h00

envoyer
par mail

imprimer
l'article

En matière de projets informatiques, le fournisseur d'électricité Direct Energie connaît bien les avantages et les inconvénients de toute jeune entreprise positionnée sur un secteur ultraconcurrentiel et très changeant : d'un côté, peu de contraintes pèsent sur l'existant ; de l'autre, les chantiers informatiques doivent être achevés dans des laps de temps records.

C'est exactement ce qui s'est passé pour son projet d'activation de clients. Déployé il y a quelques semaines, le processus en question a requis l'installation d'un socle JavaEE, associé à un moteur d'orchestration de service. Direct Energie est l'un des premiers clients en France à avoir opté pour SOA Suite, l'offre middleware d'Oracle, avant que celui-ci ne rachète BEA.

Le besoin : un socle d'intégration pour le PGI

“ En 2007, lorsque nous avons lancé ce projet, la facturation et la gestion de la relation client étaient encore sous Cegid. Le PGI convenait parfaitement pour les 50 000 clients que nous avions. Mais avec l'ouverture du marché de l'électricité aux particuliers, nous tablions sur plusieurs millions de clients. Il nous fallait un progiciel plus robuste ”, se souvient Emmanuel Decologne, le DSI du fournisseur.

Le choix est arrêté sur SAP. Direct Energie s'attaque alors à un double chantier : migrer vers le PGI allemand tout en déployant l'infrastructure logicielle grâce à laquelle il échangera avec le reste du système d'information. Avec, en ligne de mire, un processus particulier : l'activation client. Aujourd'hui, celle-ci est déclenchée par un flux XML généré par le gestionnaire de réseau (EDF/ERDF), lequel crée un client dans SAP et sollicite des modules Java développés en interne.

Le choix : des connecteurs SAP natifs

Dans un premier temps, l'entreprise a misé sur la plate-forme open source de Mulesource. Un choix qui se mène rapidement à une impasse. Car ce middleware ne dispose pas de connecteurs vers SAP, “ qui expose ses services métier via un protocole propriétaire et les développe en interne sans se préoccuper du client qui va les consommer. Nous voulions donc passer par un outil de médiation pour les exposer sous un protocole standard ”, explique Jean-Pierre Rio, chef de projet middleware.

Le choix se fixe sur SOA Suite, d'Oracle, principalement retenu en raison de connecteurs SAP natifs. Un choix fait par élimination : SAP proposait à l'époque une offre trop fermée, BEA était en pleine phase d'acquisition, IBM n'a même pas été étudié. A noter que l'entreprise disposait déjà d'existants Oracle : les bases de données du PGI et ODI, un ETL issu de l'acquisition de Sunopsis. “ Compte tenu de notre croissance exponentielle, nous n'avions absolument pas le temps de mener un appel d'offres complet et de comparer les différentes propositions du marché de façon pointue, confesse Emmanuel Decologne. Il nous fallait prendre des décisions très vite en restant pragmatiques et efficaces. ”

La mise en œuvre : d'abord modéliser le processus

Des différentes briques de la SOA Suite, le BPM est celle qui a mobilisé le plus d'attention. Car si les déploiements du serveur d'applications d'Oracle et de son ESB (utilisé pour de rares appels synchrones avec SAP) se sont faits dans la foulée, la modélisation des processus a nécessité plusieurs étapes et deux environnements différents. L'un, à destination des métiers, a servi à cartographier les flux. Il a été effectué avec Objecteering, un atelier de génie logiciel UML choisi par l'intégrateur du projet, EasyTeam. L'autre, “ JDeveloper d'Oracle, très technique, nous a permis de modéliser le processus BPEL avec les appels de services associés ”, détaille Luca D'Auria, directeur de projet SOA chez Easy Team. A termes, le modeleur métier sera remplacé par celui d'Aris (revendu par Oracle) qui offre quelques ponts avec JDeveloper.

Les difficultés : définir les périmètres des services

“ Nous n'étions pas familiers avec la modélisation de processus. Nous avons dû faire de nombreux allers-retours avec les métiers et modifier le processus ”, reconnaît Jean-Pierre Rio. Autre travail délicat auquel Direct Energie a dû se livrer : le design des services, avec leur périmètre. Ceux livrés sur étagère par SAP ne correspondaient pas aux besoins spécifiques de l'entreprise (vérification de compteur ou détection de client déjà existant dans la base…). Certaines Bapi (objets exposés avec le protocole propriétaire de SAP) ont été réécrites pour les mettre en adéquation avec les besoins. “ Nous nous sommes appuyés sur les objets métier de SAP, mais les signatures des services ne correspondent pas forcément exactement à notre métier ”, poursuit-il. Toute la difficulté était là. Car, pris dans l'urgence, Direct Energie n'a pas fait de la réutilisabilité des services une priorité. Elle compte affiner le tir dans le temps.

Demain : faire fructifier le socle BEA

La plate-forme de services de Direct Energie ne demande qu'à être enrichie avec les modules issus de BEA. L'entreprise s'équipera ainsi de son ESB, Aqualogic Service Bus, supérieur à celui d'Oracle. Elle déploiera aussi le référentiel de service du même éditeur. “ Nous pourrons alors documenter nos services, le rechercher facilement et accéder à leur contrat ”, prédit Emmanuel Decologne. Mais plus important encore, d'ici à 2010, tous les processus automatisables seront orchestrés par le moteur BPEL d'Oracle. Et pour cela, Direct Energie devra associer les métiers avec plus de conviction encore qu'il ne l'a fait avec le processus d'activation client.