Portail SIG portuaire

Le contexte

Un site portuaire ouvert au public, avec huit établissements de restauration, une clientèle mélangée — visiteurs et clients des restaurants, plaisanciers et propriétaires de bateaux, touristes de passage — et le personnel des établissements eux-mêmes.

Avant ce projet, rien n’était structuré. Il n’existait aucune source centralisée décrivant les établissements, leurs cartes, leurs prix ou leur emplacement. Un visiteur ne pouvait pas savoir ce qui l’attendait à cent mètres, et un gérant qui changeait ses prix n’avait aucun moyen de le faire savoir ailleurs que sur sa propre devanture.

La commande : une borne tactile de 55 pouces en libre-service, en français, arabe et anglais, montrant une carte interactive du site et l’offre complète de chaque établissement.

Les contraintes

• Utilisable au doigt, sans clavier, par un public non technique et pressé
• Trois langues, dont une écrite de droite à gauche, sur une interface entièrement tactile
• Contenu tenu à jour par les exploitants eux-mêmes, sans intervention d’un développeur
• Fonctionnement sur un poste isolé, avec une connexion réseau qui n’est pas garantie
• Niveau de fiabilité attendu d’une installation officielle : rien ne doit se perdre

La décision d’architecture

La première version reposait sur un front-end seul, avec les données dans des fichiers et dans le stockage du navigateur. Deux raisons ont imposé de tout reprendre autour d’une base de données relationnelle avec une API serveur :

Les données ne persistaient pas de façon fiable. Un stockage navigateur effacé est une donnée perdue, sans sauvegarde possible et sans moyen de savoir ce qui a disparu. Pour un contenu que huit établissements alimentent, c’était un risque inacceptable.

Le niveau d’exigence d’un système officiel. Sauvegardes, traçabilité, journalisation : une installation institutionnelle ne peut pas reposer sur un état local non répliqué.

La base a été normalisée autour de ~27 tables : les points d’intérêt et leurs traductions, les catégories de menu et leurs libellés (68 catégories traduites), les articles, un historique des prix conservé dans le temps plutôt qu’écrasé, les comptes et leurs permissions, les réservations, les avis et les réclamations.

Ce qui a été le plus difficile

La migration et la normalisation. Passer d’un stockage plat à un modèle relationnel sans perdre de données demande de reconstruire les relations qui n’existaient nulle part explicitement — quel article appartient à quelle catégorie, de quel établissement, dans quelle langue.

Le contrôle d’accès et l’isolation entre établissements. Chaque gérant ne doit voir et modifier que son propre établissement. La difficulté n’est pas d’écrire la règle : c’est de garantir qu’aucune route ne l’oublie. Une vérification faite dans la couche d’affichage mais absente de la couche d’accès aux données laisse passer un accès direct par identifiant. Le filtrage par périmètre du compte a été ramené au niveau des requêtes, pas des vues.

La cartographie. Éditeur de couches sur fond GeoJSON, import de fonds de plan KML/KMZ, et affectation automatique des points d’intérêt à une zone par requête spatiale : le système détermine lui-même à quelle zone appartient un établissement selon sa position, au lieu de demander à un humain de le saisir — donc sans risque d’incohérence entre la carte et la base.

Le multilingue avec l’arabe. Retourner une interface tactile en écriture droite-à-gauche ne casse pas le texte : ça casse les marges, les icônes, les flèches et tout ce qui a été positionné en pensant « gauche » et « droite ». Le traitement passe par des propriétés logiques plutôt que directionnelles, décidées dès le départ plutôt que corrigées après coup.

Le résultat

Le système tourne sans intervention technique. C’est le résultat que nous retenons, parce que c’est celui qui compte pour le client :

• une base de données unique qui fait autorité, alimentée par les exploitants eux-mêmes
• des comptes avec des droits différenciés, chaque gérant limité à son établissement
• des sessions qui n’expirent pas au milieu d’une saisie sur une borne en libre-service
• les erreurs serveur journalisées en base, consultables sans accéder à la machine
• des sauvegardes, et un historique des prix conservé plutôt qu’écrasé

Le système est livré et son déploiement sur site est en cours.

Ce que ce projet dit de la façon de travailler

Plusieurs failles ont été trouvées et corrigées en cours de route : un accès inter-comptes permettant à un gérant de voir les brouillons d’un autre, un paramètre exposant des données inactives à des requêtes non authentifiées, un partage de session entre onglets provoquant une divergence d’identité. Elles sont mentionnées ici volontairement.

Un projet sans faille trouvée n’est pas un projet sûr : c’est un projet qu’on n’a pas regardé. Ce qui compte, c’est qu’elles aient été cherchées, trouvées, corrigées et documentées avant la mise en service.