La distribution d'hydrocarbures dans l'ensemble de l'Hexagone est assurée par cinq oléoducs qui traversent la France de part en part. Quatre de ces pipelines appartiennent à Trapil, une entreprise parisienne. La gestion au quotidien et l'entretien de ces tuyaux ne sont pas une mince affaire. Pas question de se tromper sur la nature des produits à faire transiter (essence, gazole, carburant-réacteur, etc.). Trapil achemine 35 millions de tonnes de produits raffinés chaque année, dont 20 millions pour la seule région parisienne.

« Il faut régler les flux, entretenir les tuyaux, s'assurer de la bonne qualité de l'hydrocarbure. Nous contrôlons même la couleur des produits avec des colorimètres pour nous assurer de la composition des mélanges en entrée et en sortie », explique Sylvain Luce, responsable du service informatique de gestion de Trapil. Le système d'information de l'entreprise est organisé en conséquence, avec deux sous-parties distinctes. La première est consacrée au pilotage des pipelines et des stations-relais ainsi qu'aux opérations d'ouverture-fermeture des vannes.

La seconde, totalement indépendante de la première pour des raisons de sécurité, est destinée à la gestion de l'entreprise. La paye repose sur le progiciel Pléiades de Sopra Group, la comptabilité sur Coda-Financials et la GMAO (gestion de maintenance assistée par ordinateur) sur MP5 de Datastream. Mais l'activité de Trapil l'a poussé à développer des logiciels spécifiques. Notamment en matière de gestion des achats, qui inclut la gestion budgétaire. « Nous n'avons pas choisi un intégré. Nous avons des contraintes métier très diverses et les PGI manquent de souplesse. Chez nous, par exemple, une ligne de commandes est divisée en plusieurs postes ou imputations budgétaires. Nous avons construit notre propre outil à l'aide de Natural et d'Adabas, le langage de développement et la base de données de Software AG. »

L'application la plus critique reste cependant la gestion du temps de travail, construite elle aussi sur mesure au début des années quatre-vingt-dix. « Impossible de faire entrer toutes nos rubriques dans un des progiciels du marché. Nous devions prendre en compte des règles complexes, comme les repos, les dépassements, le travail discontinu sur plusieurs tranches horaires. Cette application Unix se compose de 300 programmes et sous-programmes. Avec 50 utilisateurs simultanés, il n'est pas rare qu'un ordre déclenche la lecture de 1000 lignes de la base, sans compter les transferts en batch la nuit, pour exporter les données vers la paie et la comptabilité. » Après quelques années, les utilisateurs se plaignaient du maniement compliqué du logiciel et de l'interface en mode caractères peu ergonomique. « C'était la seule solution à l'époque, reconnaît Sylvain Luce. Nous devions relier des sites distants avec des liaisons à très faible débit. »

Dès 2003, Trapil décide donc de changer l'application de gestion du temps de travail et consulte l'offre des éditeurs. « Nous désirions une interface de type Web et les logiciels de l'époque étaient en cours de portage sur Internet. Ils étaient, de plus, très orientés pointage et difficiles à paramétrer, se souvient Sylvain Luce. Nous avons choisi une solution radicale : garder le socle applicatif original et passer les écrans utilisateurs en mode Web. » Le projet a demandé huit mois, dont quatre de prestations assurées par les techniciens de Software AG. Ces derniers ont éclaté le socle en soixante services applicatifs. « L'un gère la saisie au quotidien, un autre au mois, d'autres calculent les congés payés... Nous avons ensuite recodé les transactions pour les rendre compatibles avec EntireX, le middleware de Software AG, mais aussi pour qu'elles soient transmises en mode asynchrone au serveur d'applications WebSphere. Celui-ci abrite les écrans utilisateurs. Nous avons choisi IBM WebSphere en fonction de notre historique Notes. Les deux plates-formes vont se rapprocher de plus en plus. »

Cette transformation, qui est probablement l'un des projets français les plus aboutis en matière d'architecture orientée services (AOS, ou SAO en anglais), a été l'objet d'une concertation continue entre utilisateurs et service informatique. La définition des besoins a pris peu de temps, à peine deux mois, les règles métier étant déjà précisément définies, et le groupe de travail s'est vite focalisé sur les écrans utilisateurs. Lors des premiers tests, le débogage a été difficile : « Dans une application client-serveur, il est facile de localiser un bug, c'est plus difficile dans une architecture à plusieurs niveaux. Nous avons dû travailler dur pour trouver l'origine des erreurs HTTP que nous rencontrions. C'est inévitable lorsque l'on fait appel à des bases de données, à un progiciel réécrit ou à des serveurs Apache et WebSphere. »

Les travaux ont contribué à ressouder l'équipe informatique. « Un fossé se creusait entre les plus anciens habitués au langage Natural et les jeunes, formés à Java. Nous avons fait travailler tout le monde ensemble. Cela a permis aux plus vieux de se former à Java. Autre avantage, ce découpage nous a permis d'obtenir des objets et des services réutilisables que nous emploierons dans notre futur outil de planning. » Les utilisateurs eux aussi sont satisfaits. La saisie des informations est devenue plus facile, même si les temps de réponse de l'application se sont allongés. « Nous avons des mécanismes de cache, mais envoyer toutes les informations dans une page HTML demande du temps. Nous passons de 2 à 12 secondes sur des liaisons à 64 kbit/s. Des débits difficiles à améliorer car certaines de nos stations-relais sont situées dans des zones hors de portée de l'ADSL », conclut Sylvain Luce.