UBA — Réservation Maritime Mobile

Contexte

L’Union des Bateliers Arcachonnais est une compagnie maritime fondée en 1954 qui exploite 35 bateaux et dessert le Bassin d’Arcachon depuis sept points d’embarquement. Elle génère plus d’un million de visites annuelles sur son site web, historiquement non transactionnel pour les excursions à horaire fixe. Product Designer aux côtés d’un second designer et d’un chargé de projet, avec une mission claire : concevoir la première application mobile iOS de la compagnie.

Problème

En 2023, la billetterie UBA reposait sur deux canaux : un site web et un réseau de guichets physiques aux abords des embarcadères. La réservation en ligne existait, mais le tunnel était fastidieux, nombreuses étapes, ergonomie inadaptée au mobile, dépendance à une bonne connexion et beaucoup d’utilisateurs abandonnaient en cours de route. Un touriste découvrant une croisière vers l’île aux Oiseaux depuis son téléphone se rabattait alors sur le guichet : il devait se déplacer sur place, patienter, puis espérer une disponibilité. Côté opérations, chaque départ générait une file d’attente, une vérification papier et une saisie manuelle. Un million de visites web par an, sans application mobile dédiée, résumait l’écart à combler : capter la demande là où elle naît, jusqu’au billet scanné à la borne d’embarquement.

Challenge 01 — Cartographier le parcours du visiteur du Bassin

Le défi : comprendre comment un touriste décide de monter à bord, sur quel support, à quel moment, avec quelles informations; avant de dessiner un écran.

Mon approche : en ouverture de projet, nous avons mené des entretiens avec des voyageurs récents et des agents des guichets UBA. Deux usages sont ressortis avec force, la réservation anticipée (la veille, depuis un hôtel) et la décision impulsive (sur la jetée, dix minutes avant le départ). Ces scénarios imposaient des contraintes opposées : l’un accepte la lecture détaillée, l’autre exige une décision en trois taps. Les wireframes basse fidélité ont servi à arbitrer cette tension sans se perdre dans les détails visuels.

Challenge 02 — Stabiliser une tab bar iOS à cinq entrées

Le défi : donner un point d’entrée permanent aux deux flux critiques sans surcharger la navigation.

Mon approche : j’ai arbitré l’architecture de l’information sur cinq onglets : Accueil, Recherche, Billet, Carte, Compte. Billet est le non-négociable : un utilisateur qui a réservé doit atteindre son QR depuis n’importe où dans l’application, en un seul tap. Carte matérialise les sept points d’embarquement sur le Bassin, réponse directe au besoin d’orientation remonté en entretiens. Recherche et Compte ont été maintenus comme entrées standalone plutôt que masqués dans un menu, pour respecter les heuristiques iOS.

Challenge 03 — Livrer un billet QR scannable sans friction

Le défi : un billet qui échoue à se charger à l’embarquement, c’est une réservation perdue et un client redirigé vers le guichet. La tolérance à l’erreur est nulle.

Mon approche : j’ai traité l’écran Billet comme un composant autonome, conçu pour une contrainte unique, être lisible par un scanner de borne en quelques secondes, sur un téléphone à luminosité variable. Le QR est centré, à contraste maximal, sans éléments décoratifs. Les métadonnées du trajet (horaire, embarcadère, nombre de passagers) sont reléguées sous le code. L’accès au billet reste disponible sans connexion une fois la réservation confirmée, une contrainte non négociable en zone littorale à couverture inégale.

Itérations et décisions de design

La V1 avait placé l’onglet Billet sous Compte, logique côté architecture (un billet appartient à un compte), mais lourde côté usage : deux taps de plus sous la pression de l’embarquement. La V2 l’a promu au rang d’onglet racine. Sur le tunnel de paiement, j’ai testé en V0 une version compactée fusionnant choix du créneau et coordonnées passager sur un seul écran ; les retours ont signalé une perte de lisibilité sur l’état de la réservation (« est-ce que j’ai payé ? »). La version finale scinde à nouveau ces étapes pour préserver la clarté du statut, un retour en arrière assumé après test.

Résultats et impact

• 2 flux critiques livrés en maquettes haute fidélité, réservation complète et accès au billet QR.
• Tab bar iOS à cinq entrées stabilisée et validée par revue UX interne.
• 7 points d’embarquement intégrés à la carte interactive de l’application.

Apprentissages

Le tunnel de paiement a été, de loin, le défi le plus complexe du projet. Concevoir quatre écrans qui se tiennent, créneau, passagers, paiement, confirmation, en maintenant un état de réservation lisible à chaque étape, c’était moins un problème d’écran que de grammaire. J’ai sous-estimé au départ la charge mentale d’un tunnel transactionnel sur mobile : chaque arbitrage de hiérarchie sur un seul écran produit un effet en cascade sur la confiance ressentie face au paiement.

Ce qui a été difficile : maintenir la cohérence entre les états en cours, validé et échoué sans démultiplier les écrans. La tentation est d’ajouter des variantes ; la discipline consiste à les compresser sans perdre de lisibilité. Plus généralement, un tunnel de paiement mobile concentre à lui seul les contraintes du produit, passerelle technique, obligations légales, clavier natif, erreurs de saisie, et chacune doit être réconciliée dans un flux unique.

Ce que je ferais différemment aujourd’hui : tester le tunnel en conditions de stress utilisateur dès la V0, pas en laboratoire, mais sur la jetée, à dix minutes d’un départ. Les décisions prises depuis un prototype Figma en salle calme ne survivent pas toujours à la réalité d’un 15 août sur le Bassin. Les heuristiques iOS m’ont donné un cadre ; la pratique terrain m’aurait donné les bons arbitrages plus tôt.