Logiciel d'opérations ferry : planification dynamique, yield et reprise après incident

De tous les segments regroupés sous l'étiquette du maritime commercial, les opérations ferry sont les plus éloignées du manuel. Un porte-conteneurs navigue pendant des semaines ; son cycle commercial se mesure en contrats trimestriels et couvertures FFA. Un pétrolier passe des jours dans les ports de chargement et de déchargement ; le rythme y est dicté par les clauses de laytime. Un ferry passager, à l'inverse, peut boucler un cycle commercial complet entre quatre et douze fois par jour, avec des rotations de trente minutes, des attentes passagers de niveau retail, un inventaire périssable sous la forme de sièges vides et de mètres linéaires invendus, et un risque météo concentré sur des fenêtres saisonnières étroites. La physique opérationnelle est différente, et le logiciel qui la soutient doit l'être aussi.

Cet article examine ce que doit réellement faire un logiciel d'opérations ferry — planification, yield, planification réglementaire du chargement, reprise après incident — et pourquoi les plateformes génériques, portées depuis des contextes conteneur ou tanker, échouent face à une vraie journée de ferry.

L'anatomie d'une journée ferry

Une journée type sur une route côtière ou short-sea peut commencer à 04h30 avec la prise de quart de l'équipage, la coordination du soutage avec la gabare de port, la préparation du garage et la revue finale des registres nocturnes de bruit et d'émissions. À 06h15, les premiers piétons font la queue ; à 06h45, le garage est chargé selon un plan d'arrimage qui prend déjà en compte le poids des semi-remorques, la ségrégation des marchandises dangereuses et les priorités commerciales de l'opérateur — voyageurs fréquents, transporteurs sous contrat, drive-up de dernière minute. Le navire appareille à 07h00, revient à 09h30 et doit repartir à 10h00. Une rotation de trente minutes, répétée cinq à dix fois par jour.

Dans cette fenêtre, l'équipe d'opérations doit concilier :

• Le débarquement et la libération du garage face à la disponibilité du linkspan ;
• L'embarquement des piétons, des passagers à mobilité réduite et du trafic véhiculé, souvent par des accès distincts ;
• Les rotations d'équipage régies par les heures de repos de la MLC 2006 ;
• Le soutage et la réception des déchets selon MARPOL Annexes I, IV, V et VI ;
• La réconciliation des créneaux portuaires, puisque la plupart des terminaux short-sea allouent des fenêtres à quai qui ne peuvent glisser sans effets en cascade ;
• La communication passager en temps réel : changements de porte, retards, correspondances train ou car manquées ;
• Les briefings de sécurité, la clôture du manifeste et les contrôles finaux de stabilité SOLAS avant l'autorisation d'appareiller.

Aucune de ces activités n'est exotique en soi. La difficulté est qu'elles sont toutes interdépendantes, toutes sur l'horloge des trente minutes, et qu'elles se reproduisent à chaque port de chaque rotation, chaque jour.

Capacité et yield : deux inventaires sur une seule coque

Un ferry passager vend deux produits fondamentalement différents sur le même appareillage. Le pont passager est un produit retail : sièges, cabines, salons, parfois restaurants et boutiques. Le garage est un produit logistique : mètres linéaires pour voitures, motos, fourgons, autocars et, de plus en plus important, semi-remorques de fret. Les deux ont des recettes par mètre cube différentes, des élasticités prix différentes, des courbes de réservation différentes et des comportements d'annulation différents. Les réservations véhicules se figent plus tôt et sont rarement no-show ; les réservations passagers, surtout en loisir, peuvent bouger fortement dans les 72 dernières heures.

Le yield management conçu pour les compagnies aériennes ou les hôtels traite l'inventaire comme un pool homogène. Le yield ferry ne le peut pas. Un moteur moderne modélise les inventaires passagers et véhicules séparément, puis conjointement, parce qu'ils interagissent : un fret lourd réduit les mètres linéaires restants pour les voitures, ce qui contraint le prix de la prochaine voiture, qui revient ensuite dans la surface d'offre montrée au loisir. Certains opérateurs ajoutent l'inventaire cabines comme troisième axe sur les traversées de nuit — et les cabines, contrairement aux sièges, se comportent davantage comme des chambres d'hôtel que comme des sièges aériens, avec un floor same-day très ferme.

Les opérateurs cités à titre de contexte industriel — DFDS, Stena Line, Brittany Ferries, Grimaldi, GNV, Moby, Trasmediterránea, Baleària — ont passé des années à calibrer leur logique yield à leurs mix de routes. Le motif commun est un modèle en couches : une price ladder stratégique par route et saison, une couche tactique qui réagit au rythme de réservation, et un floor temps réel qui empêche la cannibalisation du fret sous contrat.

Planification dynamique et reprise du calendrier

L'horaire publié est, en pratique, une aspiration. Un COO sait que tout jour donné, une fraction des appareillages sera touchée par quelque chose : une prévision de force huit, une alarme servomoteur, une fermeture de port pour escale croisière, un débarquement médical. La question n'est pas de savoir si l'incident surviendra ; c'est de savoir avec quelle vitesse l'opération est restabilisée.

Le logiciel de planification dynamique doit couvrir trois horizons distincts :

1. La conception stratégique, où les horaires annuels ou saisonniers sont construits face aux prévisions de demande, aux créneaux portuaires, aux tableaux d'équipage et aux fenêtres de maintenance ;
2. La replanification tactique, dans la fenêtre 24-72 heures avant départ, où des données de vent prévues, des défauts mécaniques ou des réservations commerciales peuvent justifier d'annuler, de fusionner ou de réviser des appareillages ;
3. La reprise temps réel, lorsqu'un appareillage a déjà été perturbé et que l'opérateur doit reprotéger les passagers, dérouter le fret, repositionner les équipages et rattraper l'horaire le jour même ou le lendemain.

Le plus difficile est la reprise temps réel. Elle exige que la plateforme tienne une photographie vivante de l'état de toute la flotte — soutage, ballastage, heures équipage, autorisations portuaires, manifestes passagers et véhicules — et génère des plans réalisables en minutes, pas en heures. Le logiciel porté du shipping conteneurs, où un navire en retard est simplement reframé sur la prochaine fenêtre portuaire, n'a pas de notion native de cela ; là-bas, la reprise se mesure en jours, pas en minutes.

Optimisation du load factor sans casser la stabilité

Tout opérateur commercial veut remplir le deadweight résiduel. Sur un ferry, la contrainte qui cède en dernier n'est pas commerciale : elle est réglementaire. La SOLAS Chapitre II-1 régit la stabilité après avarie des navires à passagers, et son cadre probabiliste post-2009 — couplé au Stockholm Agreement pour les ferries RoRo passagers du nord-ouest européen — pose des limites dures sur la façon dont les garages peuvent être chargés par rapport aux compartiments passagers et au cloisonnement étanche. Une assiette commercialement attrayante peut être opérationnellement illégale.

Un bon logiciel de planification de chargement ferry ne se contente pas d'optimiser l'arrimage par centre de gravité et assiette. Il encode la documentation réelle de stabilité après avarie du navire, traite le loading computer comme source de vérité et refuse de publier des plans d'arrimage qui sortent de l'enveloppe approuvée. Il ajoute par-dessus la logique commerciale : ségrégation des marchandises dangereuses selon IMDG, charges à risque sur ponts weather, animaux vivants sur ponts ventilés, planification des prises pour reefers et affectation des couloirs minimisant les manœuvres de shunting au débarquement.

Pour les ferries propulsés au GNL, l'IGF Code ajoute une couche supplémentaire : contrôles de compatibilité de soutage, zones de détection gaz autour du manifold et limites opérationnelles sur soutage simultané à l'embarquement passagers. Rien de tout cela n'est capturé par un logiciel pensé pour stocker des box sur un porte-conteneurs de 12 000 EVP.

MARPOL, EEXI et CII : pressions spécifiques aux ferries

Les ferries sont exposés sur le plan environnemental autrement que les flottes hauturières. Leur intensité port-à-port fait qu'une part élevée de la consommation totale de combustible se produit en manœuvre, à quai et en transition cold ironing. La fréquence de leurs escales engendre une exposition disproportionnée à la régulation locale de la qualité de l'air dans les villes portuaires — Gênes, Barcelone, Marseille, Douvres, Helsinki — où la pression municipale sur les émissions est plus dure que la régulation hauturière.

L'EEXI s'applique une seule fois. Le CII s'applique annuellement, et les bandes de notation sont sévères pour les opérateurs short-sea dont le dénominateur en distance est faible. Les opérateurs répondent par cold ironing, hybridation batterie, slow steaming sur les jambes flexibles et gains d'efficacité opérationnelle qui dépendent de données voyage détaillées : état de mer, dérive, précision ETA, temps d'attente. Le logiciel doit les capturer par jambe, les attribuer correctement et les alimenter à la fois dans le reporting réglementaire (EU MRV, IMO DCS) et dans la logique commerciale — parce qu'un déclassement de bande CII peut changer le business case d'une route entière.

Reprise après incident et communication passager

Le passager ferry de 2026 attend ce qu'il reçoit du train et du court-courrier aérien : information d'incident en temps réel, reprotections automatiques, remboursements sans appels téléphoniques, et réacheminement attentif à l'accessibilité. Les standards ATOC au Royaume-Uni et le Règlement UE 1177/2010 sur les droits des passagers maritimes fixent le plancher légal ; la réputation commerciale en fixe un plus haut.

Le problème est que l'incident ferry est rarement net. Un train annulé ne part simplement pas ; un appareillage ferry annulé laisse des semi-remorques à quai, des piétons sans correspondance et des véhicules dont les conducteurs ont déjà payé un hôtel à destination. La reprise exige que la plateforme :

• Reprotège les passagers entre les appareillages affectés en respectant l'allocation cabines et les besoins d'accessibilité ;
• Repositionne véhicules et semi-remorques fret, avec gestion explicite des marchandises dangereuses et des reefers ;
• Coordonne avec autorités portuaires, opérateurs de linkspan et fournisseurs de transport onward ;
• Génère automatiquement les dossiers de compensation Règlement 1177, et non comme tâche manuelle de back office trois semaines plus tard ;
• Communique de manière proactive, dans la langue et le canal choisis par le passager, avec un contenu substantiel — pas des modèles génériques d'excuses.

Bien fait, cela transforme un cas de force majeure en une histoire commerciale défendable. Mal fait, cela produit les incidents sur les réseaux sociaux que les opérateurs craignent aujourd'hui plus que le régulateur.

Ce que fait un bon logiciel ferry et que les logiciels adaptés du conteneur ne font pas

Le motif est désormais visible. Le logiciel originellement conçu pour les flottes conteneur ou tanker, puis vendu aux opérateurs ferry avec un module passager greffé, échoue sur cinq fronts récurrents :

• Horizon temporel : il suppose des cycles commerciaux mesurés en jours ou semaines, pas en rotations de trente minutes ;
• Modèle d'inventaire : il traite la capacité comme homogène, et non comme une surface yield combinée passagers + véhicules + cabines ;
• Stabilité et sécurité : il n'a pas de modèle natif de stabilité après avarie SOLAS, de zones gaz IGF ou d'affectation de couloirs RoRo sous ségrégation IMDG ;
• Incidents : il manque les primitives de reprise d'horaire temps réel dont un COO ferry a besoin à 06h00 d'une matinée de force huit ;
• Expérience passager : il n'a pas de notion native d'accessibilité, de compensation Règlement 1177 ou de communication multilingue.

Le logiciel ferry purpose-built part de l'hypothèse opposée : la journée ferry est l'unité atomique, le passager et le semi-remorque partagent la coque mais pas la logique commerciale, et la reprise après incident n'est pas une voie d'exception mais une capacité centrale.

De l'outillage au système d'exploitation

Les opérateurs ferry les plus solides que nous observons en Europe et en Méditerranée dépassent l'ère des outils séparés de scheduling, yield et reprise reliés par des feuilles de calcul et des calendriers partagés. Ils consolident sur un système opérationnel d'enregistrement unique, depuis lequel travaillent COO, route managers, port operations managers, revenue et customer service. L'avantage n'est pas un dashboard unique. C'est que les mêmes données — manifeste, arrimage, heures équipage, soutage, météo, créneaux — pilotent chaque décision, de sorte qu'un re-routing tactique de 11h00 et un ajustement yield de 14h00 ne se contredisent pas à 17h00.

Atteindre ce point est un programme pluriannuel, pas un achat de logiciel. Mais le retour est mesurable : load factors plus élevés à risque yield égal, reprise plus rapide, moindre exposition réglementaire, et une expérience passager qui tient sous pression.

Le module Ferry de SupaMaritime est conçu spécifiquement pour ce segment — opérateurs passagers et RoRo sur routes côtières, short-sea et méditerranéennes — et s'intègre aux modules SupaMaritime plus larges pour l'agence et les flottes merchant. Les points d'accès localisés sont aussi disponibles sur /ferry, /it/ferry, /es/ferry et /de/ferry. Pour les opérateurs qui évaluent par où commencer, le premier pas pratique est rarement un remplacement total de plateforme ; c'est une revue ciblée des points où le toolchain actuel cède lors d'une vraie journée perturbée, et une roadmap qui corrige d'abord les modes d'échec les plus coûteux.