Le cas GPMM (Grand Port Maritime de Marseille)
Le client
Le Grand Port Maritime de Marseille (GPMM) est le premier port de France et un hub majeur de l'espace euro-méditerranéen. Au cœur de ses opérations, Neptune est le « Port Community System » du port : créé en 2015, ce logiciel constitue la colonne vertébrale de la gestion du trafic maritime. Il permet de suivre l'intégralité de la documentation des escales, de coordonner les intervenants pour l'accueil des navires et de garantir le respect des exigences réglementaires, opérationnelles et de sécurité. Une application critique, dont dépend la fluidité de milliers d'escales.
Le défi
Neptune remplissait sa mission, mais son socle technique était devenu un frein. Écrite dans un langage historique, l'application était de plus en plus coûteuse à maintenir et difficile à faire évoluer face aux nouveaux enjeux du trafic maritime : augmentation des flux, complexité croissante des chaînes logistiques, attentes de nouveaux services.
L'enjeu du GPMM n'était pas de remplacer Neptune par un outil du marché, mais de re-développer l'existant sur des fondations modernes, maintenables et évolutives — sans perdre la richesse fonctionnelle accumulée depuis 2015, et sans interrompre un service dont l'indisponibilité aurait des conséquences opérationnelles directes. La difficulté centrale : traduire fidèlement une logique métier portuaire complexe d'un langage vers un autre, tout en garantissant l'iso-fonctionnalité.
La solution
L'intervention a pris la forme d'une prestation d'expertise en migration applicative, structurée pour sécuriser la fidélité fonctionnelle à chaque étape.
Traduction du code vers une stack moderne. Le cœur du travail a consisté à ré-écrire Neptune d'un langage historique vers une stack pérenne : Python en back-end, JavaScript (React) en front-end web et mobile. L'objectif n'était pas seulement de changer de langage, mais de rendre l'application à nouveau lisible, testable et évolutive pour les équipes du port.
Une architecture modulaire. Le re-développement s'est appuyé sur une architecture découplée — un noyau back-end exposant une API, des applications front-end distinctes — pensée pour la maintenabilité et l'ajout futur de fonctionnalités, plutôt que de reconduire un bloc monolithique.
Une méthode itérative pour maîtriser le risque. Le projet a été conduit en Agile (Scrum), avec des livraisons par itérations successives plutôt qu'un « effet tunnel » de livraison unique en fin de parcours. Cette cadence a permis de valider la fidélité fonctionnelle au fil de l'eau, avec les équipes métier et techniques du GPMM, et d'ajuster le périmètre d'un commun accord.