Projet IT

Neptune Port : comment le Grand Port de Marseille a refondu son système avec Capgemini

Le 1er port français a développé en collaboration avec Capgemini un système central baptisé Neptune Port, bâti sur une architecture SOA pour orchestrer les multiples interconnexions tous les prestataires et corps de métier.

Cyrille Chausson
par
Publié le: 30 mai 2016

Le Grand Port Maritime de Marseille, le 1er port français en termes de trafic, a décidé de remplacer son ancien système de gestion portuaire EscaleV2 par une nouvelle application baptisée Neptune Port entièrement bâtie sur une architecture orientée services. L’institution portuaire a fait appel à Capgemini pour l’accompagner dans sa démarche. L’application est en service depuis le 29 novembre 2015.

Le grand port de Marseille est une plaque-tournante du transport maritime et fluviale. Le port accueille toutes formes de transports maritimes ainsi que du fluviale (barges et péniches qui arrivent directement du Rhône et rentrent dans le port). Au total, quelque 80 millions de tonnes de marchandises et 1,5 million de passagers transitent chaque année par le site – également le second européen.

Dans ce contexte, le système de gestion portuaire fait office de chef d’orchestre de l’ensemble du trafic et des opérations qui ont lieu sur le site. Grosso modo, il s’agit de faire « rentrer et sortir des navires et de leur permettre de réaliser leurs opérations commerciales, tels que le chargement et le déchargement », résumé Bernard Caumeil, Chef du Département Systèmes d'Information du Grand Port Maritime de Marseille Fos.

Comme pour un aéroport, le port fait aussi office d’autorité de régulation. « Nous validons les entrées et sorties des navires pour que cela soit effectué dans de bonnes conditions techniques. On s’assure par exemple que deux navires ne se croisent pas au même  moment, que les navires arrivent à quai, en tenant compte des conditions météo. Nous assurons également la gestion de la logistique et de son bon fonctionnement. Nous sommes aussi garant  de réglementation : un navire ne peut pas rentrer s’il n’a pas rempli certaines obligations administratives. Nous sommes ainsi un guichet unique en centralisant un ensemble de documents que l’on doit valider, et d’autres que l’on reçoit comme ceux  par exemple de la Police de l’Air et des frontières, d’organismes européens – comme la gestion des déchets », poursuit-il.

Depuis 1992, ces besoins métier très spécifiques étaient orchestrés par un logiciel tournant sur un mainframe, développé dans le langage Natural, un dérivé de Cobol. « Cette application était déjà novatrice mais dans un cercle très restreint. (…) On ne trouvait plus de sociétés pour assurer la maintenance, elle était trop restrictive sur certains aspects, comme la communication. Même si elle remplissait encore bien sa fonction », explique Bernard Caumeil.

 Surtout, l’idée était de bâtir une nouvelle application davantage adaptée aux besoins métiers qui ont depuis fortement évolué et se sont enrichis, résume-t-il. L’ensemble de ces procédures étaient partiellement pris en compte par l’ancien logiciel, comme la dématérialisation de l’ensemble de procédure.

« Si cela correspondait à une vision de la circulation des informations de cette époque, côté opérationnel et documentaire, il est nécessaire de dématérialiser complétement toutes les informations. D’autant que ces informations sont détenues dans différents systèmes. »  Comme la liste des passagers stockée dans les systèmes de réservations de chaque compagnie, par exemple. «  Il est plus facile pour eux de nous l’envoyer numériquement, et nous de l’intégrer directement. »

Une étape intermédiaire

Une première de transformation a ainsi eu lieu il y a une quinzaine d’années. Une version Windows de l’application a été développée, via un convertisseur de code mainframe vers Windows (de Software AG), pour « éviter de se trouver piéger avec la disparition du mainframe », explique le Chef du département SI. Mais cela constituait surtout une réponse temporaire avant une re-écriture complète de l’application.

« Nous savions qu’il fallait nous lancer dans un nouveau système d’information parce qu’il nous fallait intégrer des fonctions plus riches, être plus communiquant, pouvoir davantage pousser l’information ».

Java et SOA pour un système central qui doit coordonner

Démarre alors un vaste projet de refonte qui passera par une nouvelle architecture de l’application. « Le modèle d’architecture orientée services a été proposé par le port, car nous avions déjà une expérience en matière de nouvelles technologies, comme Java et JBoss.  Notre service de développement (en interne) avait déjà créé des applications dans ce domaine. Depuis 10 ans, on savait  ce qui pouvait être utilisé ou pas », explique Bernard Caumeil. Le port de Marseille s’est ainsi doté de compétences en interne (un architecte, un ingénieur en génie logiciel) qui, grâce à leur connaissance métier ont pu établir l’architecture. L’architecture de base et ses pré-requis ont ensuite été validés par Capgemini. La SSII a pu apporter son expertise au projet dès 2013.

Pour Bernard Caumeil, l’architecture SOA et les Web Services suivaient la logique même des processus du port. « Un système portuaire est un lieu d’échanges. On donne de l’information et on en reçoit, et ce, en permanence. » Toutes les opérations déclaratives des navires impliquent que 15 métiers différents reçoivent l’information. « Quand un navire arrive, il faut que tout le monde sache à quel heure doit monter le pilote, à quelle heure le remorquage doit agir, à quel moment on doit faire le ravitaillement, les réparations, à quel moment les manutentionnaires doivent charger et décharger,  … », explique-t-il.

Une succession d’opérations, qui ne s’arrête jamais, et fonctionne en 24/7.   « Lors de l’arrivée d’un navire, une série de prestations et de sociétés sont impliquées. « Le logiciel est donc là pour donner ces informations. » A cela s’ajoute, le caractère sans cesse changeant de l’information – les arrivées des navires ne sont jamais identiques, tout comme la logistique.

« On doit mettre en musique tout cela. Et pour synchroniser toutes ces personnes, il faut échanger avec elles. » D’où une approche liée aux Web Services : l’interconnexion entre applications et systèmes est pour le port de Marseille une nécessité. A cela s’ajoute des systèmes internes : « Nous disposons aussi d’applications internes qui dialoguent entre elles, comme le système lié aux marchandises dangereuses qui doit être en phase avec toutes les informations », ajoute Bernard Caumeil. En clair, l’ensemble des opérations et des corps de métier se coordonnent grâce au système d’information, et ce en temps réel. Au total, Neptune Port est utilisée ce jour par 720 personnes, issues de 160 sociétés différentes, privées ou publiques.

Java, JBoss, Talent et BIRT

Techniquement, décrypte Agnès Arlac, directrice de projet chez Capgemini, l’application a été développée autour du framework Java et un serveur d’application JBoss 7 déployé en cluster (pour la haute disponibilité). La persistance des données est quant à elle assurée par Hibernate sur une base Oracle. La partie  développement Web côté client s’appuie sur le kit de développement Google Web Toolkit (GWT).

Capgemini a également dû récupérer 10 ans d’historiques de données de l’ancienne application (EscaleV2). Cela a été réalisé via l’ETL de Talend. L’édition de rapports pour contrôler les exports est quant à elle gérée par l’outil BIRT.

Un chantier d’un an a été nécessaire pour améliorer la qualité des données et les rendre fiables, ajoute Bernard Caumeil. Des tables de transcodage ont été mises en place pour être cohérent avec le schéma de données du nouveau système.

« Une longue série de tests de migration a aussi été effectué pour s’assurer que le scénario fonctionne et de vérifier que les informations reçues sont bien exploitable dans la nouvelle logique métier, et ce sans interruption de système. « Ce qui était en cours dans l’ancien système devait continuer vivre dans le nouveau », résume à son tour Agnès Arlac.

Mais pas de gestion de règles

Pour autant, même si de chef d’orchestre il s’agit, Neptune Port ne s’appuie pas sur un outil de gestion de règles. « Il y a tellement d’aléas et d’intervenants que mettre en place un tel outil aurait été une contrainte et un blocage du système. Seuls quelques-uns de nos processus sont linéaires, explique Bernard Caumeil. Il faut que le système soit suffisamment souple pour gérer toutes les opérations, car « les événements ne sont pas prédictibles ».

Et d’illustrer le fonctionnement global du système : « Notre système s’appuie plutôt sur une forme de dossier. Au fur et à mesure, l’ensemble des intervenants désignés pour interagir autour du navire va enrichir le système et un dossier se constitue ainsi, par ajout, jusqu’à la sortie du navire. Chaque intervenant ajoute des informations », illustre-t-il. Des contrôles de cohérence sont effectués tout au long des opérations. Ils permettent de corriger une situation donnée, si bloquante. « Il s’agit d’un échange de tous les acteurs autour du logiciel.  Cet outil est un outil d’aide à la décision pour que les personnes puissent se coordonner de façon que tout se passe correctement. »  Tant en matière de logistique que réglementaire.

L’autre gain de ce découplage : la flexibilité apportée par la standardisation. « Comme on doit dialoguer avec d’autres systèmes tant internes qu’externes, cela nous permettra de pouvoir s’adapter et développer de nouveaux services. »

Développer une application portable

Mais, et c’est un point intéressant, la configuration multi-trafic du grand port de Marseille lui a permis de développer une application standard, qui peut aussi s’adapter à n’importe quel autre port. « Il s’agit un marché de niche dans lequel peu d’éditeurs peuvent se lancer dans  l’aventure », souglien Bernard Caumeil. Toutefois, il existe un socle commun, précise-t-il. « Le découpage fonctionnel et l’exposition sous la forme de service nous permis de conserver cette partie commune, et tout ce qui est spécifique a été séparé, géré à part mais relié par des Web Services », rappelle-t-il. Mais, ajoute-t-il, « le système a été conçu pour répondre à une norme et des obligations internationales. La partie cœur du système est commune à tous les ports du monde ».

Une approche que Capgemini pourrait bien exploiter. Si « la volonté de Capgemini d’avoir une offre maritime est en phase embryonnaire », explique Agnès Arlac, la SSII travaille avec le port de Marseille pour voir comment l’application Neptune Port pourrait être commercialisée pour d’autres ports. Mais, pour le moment, Capgemini étudie le marché, et essaie d’évaluer « comment capitaliser » sur le projet mené avec Marseille.

Vers des services d’enrichissement

En trois ans, ce projet Nepture Port aura couté 3 millions d’euros. Mais ce n’est qu’un début, lance  Bernard Caumeil, car d’autres investissements devraient suivre. Il évoque par exemple la mobilité. « Aujourd’hui l’essentiel a été posé. Nous sommes désormais dans une phase d’enrichissement. » La représentation cartographique de l’activité portuaire fait aussi partie des travaux en cours.

Mais pour lui, l’objectif est bien d’accentuer les capacités de l’application – et donc du port - à communiquer avec d’autres systèmes. « L’un des prochains enjeux est de rendre le port communicant avec les systèmes terrestres pour que les marchandises puissent être acheminées en temps et en heure », lance-t-il. « Nous sommes un maillon de la chaîne logistique d’acheminement d’une marchandise du producteur au consommateur. »

Pour approfondir sur Architectures logicielles et SOA