MaritimeFlow est un projet réalisé dans le cadre de mon PFA chez OCP Group, entre août et septembre 2026. L'objectif était de relier quatre niveaux de décision: transformer des positions AIS brutes en trajets exploitables, estimer les heures d'arrivée, optimiser l'allocation et le routage d'une flotte, puis mesurer l'effet de la politique obtenue par simulation.
Le problème business: le retard coûte plus qu'une ETA imprécise
Pour l'export de phosphate par voie maritime, la performance ne se résume pas à la distance parcourue. Un navire retardé peut générer des frais de démurrage, notamment lorsque le temps prévu pour les opérations portuaires est dépassé. Une prédiction d'ETA est donc utile pour anticiper un retard, mais elle ne décide pas quel navire affecter à quelle commande ni comment arbitrer plusieurs demandes concurrentes.
La question opérationnelle devient: quelle politique de flotte réduit le coût total des retards tout en respectant les capacités, les disponibilités et les contraintes de routage?
Du signal AIS à une matrice de trajets
Le pipeline commence avec des positions GPS AIS. Le volume brut représentait environ 19 à 40 millions de positions par mois. Le nettoyage a supprimé les points incohérents, les doublons et les séquences inutilisables avant la segmentation des trajectoires. Cette étape a permis d'obtenir environ 27 000 trajets candidats.
Les ports n'étaient pas supposés connus à partir des seules coordonnées. Un clustering DBSCAN a identifié environ 500 clusters de ports candidats, ensuite confrontés au World Port Index. Les trajets ont alors été convertis en couples origine-destination. Après validation, la matrice OD retenait 15 671 trajets valides et 1 472 relations inter-ports.
Cette représentation est importante: le modèle d'optimisation ne travaille pas sur des millions de points GPS, mais sur des unités de transport, des temps et des relations entre ports.
Modèle ETA: utile, mais pas suffisant
Pour estimer les temps d'arrivée, j'ai entraîné un modèle LightGBM. Après filtrage des valeurs aberrantes, l'entraînement portait sur 1 130 trajets. Sur l'ensemble de test, le modèle obtenait une MAE de 34,5 heures et un R² de 0,72.
Ces métriques donnent une information exploitable sur l'incertitude des arrivées, mais elles ne constituent pas une politique de décision. Même une bonne ETA ne choisit pas seule une affectation optimale. Elle devient une donnée d'entrée du modèle de flotte.
MILP et ALNS pour l'allocation et le routage
Le problème d'allocation et de routage a été formulé comme un programme linéaire en nombres entiers mixtes (MILP). La formulation encode les décisions d'affectation, les séquences de trajets et les contraintes opérationnelles. Pour explorer plus rapidement des solutions sur un espace combinatoire, elle a été complétée par une métaheuristique ALNS (Adaptive Large Neighborhood Search).
ALNS alterne des opérations de destruction et de réparation: une partie d'une solution est retirée, puis reconstruite selon plusieurs stratégies. Cette approche permet de chercher des politiques compétitives sans exiger que chaque instance soit résolue exactement.
Validation par simulation
La comparaison finale a été réalisée avec une simulation à événements discrets sous SimPy sur 200 jours. Deux politiques ont été comparées: la politique optimisée par ALNS et une politique naïve FCFS (First Come, First Served).
La politique ALNS livrait légèrement moins de commandes, mais elle réduisait suffisamment les retards coûteux pour générer environ 400 000 dollars d'économies en pénalités de démurrage sur la période simulée. Ce résultat rappelle qu'un indicateur unique, comme le nombre de commandes livrées, peut conduire à une conclusion erronée si le coût des retards n'est pas intégré.
Ce qui est transférable à un cas réel
Les données utilisées pour ce projet sont synthétiques et fictives. Elles ne sont pas des données de production réelles d'OCP et les économies simulées ne constituent pas une estimation financière opérationnelle. En revanche, la méthodologie est directement transférable à un cas réel: pipeline data, contrôle qualité, modèle ML, formulation d'optimisation et simulation de politiques.
La leçon d'ingénierie est simple: le modèle ETA n'est qu'un composant. La valeur vient de la chaîne complète, de la qualité des données jusqu'à la mesure du coût d'une décision dans un environnement simulé.