Pont Roman de Bédarrides : l'application qui dit si le pont est ouvert

Création de l'application Pont Roman, une PWA qui répond à la question que se posent les habitants de Bédarrides à chaque épisode pluvieux : le pont est-il encore ouvert ?

Je l'ai développée de ma propre initiative, pour la commune où je vis. Il faut le dire d'emblée : ce n'est pas un service officiel de la mairie. L'application est une aide à la décision, elle ne remplace ni la signalisation sur place ni les consignes des autorités.

Une donnée qui existe, mais qui n'arrive pas

Le Pont Roman est un point de passage structurant, et sa fermeture dépend directement du débit de l'Ouvèze. Cette donnée n'a rien de confidentiel : elle est mesurée en continu par les stations hydrométriques publiques et diffusée en open data.

Le problème n'est donc pas la donnée. C'est la distance entre la donnée brute et l'habitant qui doit décider s'il part maintenant ou s'il fait le détour.

Consulter une station hydrométrique suppose de savoir laquelle regarder, de lire un débit exprimé en mètres cubes par seconde, et de connaître le seuil à partir duquel la circulation est coupée. Trois obstacles qui suffisent à rendre l'information inutilisable dans la vraie vie.

Ce que l'application affiche, et rien d'autre

Trois choses, sur un seul écran :

Un statut lisible immédiatement — pont ouvert, vigilance, pont fermé — avec son code couleur. Le débit actuel et sa tendance, en hausse, stable ou en baisse. Et une projection à une, trois, six et douze heures, pour anticiper plutôt que subir.

Pas de menu, pas de compte à créer, pas de publicité. C'est une PWA (Progressive Web App) : elle s'ouvre comme un site, mais s'installe sur l'écran d'accueil du téléphone comme une application, sans passer par un magasin d'applications.

De la donnée publique à une décision

L'application interroge l'API Hubeau, le portail open data d'Eau France, sur la station hydrométrique de référence pour l'Ouvèze. Les mesures sont rafraîchies toutes les cinq minutes, nettoyées, puis comparées à des seuils inscrits dans un fichier de configuration : vigilance à partir de 80 m³/s, fermeture au-delà de 100 m³/s. La tendance est calculée par régression linéaire sur les dernières mesures disponibles, ce qui permet de projeter l'évolution sur les heures suivantes.

Un point d'honnêteté, assumé dans l'interface : il s'agit d'une projection de tendance, pas d'une prévision hydrologique officielle. L'application affiche systématiquement l'heure de la dernière mesure et un lien vers la source. Une information locale ne vaut que si l'on sait d'où elle vient.

Les fermetures qui ne se lisent pas dans le débit

Un pont ne ferme pas qu'à cause de l'eau : travaux, inspection technique, manifestation, décision de sécurité. J'ai donc ajouté un système de fermeture programmée — un simple fichier de configuration où l'on déclare une plage horaire, un motif et une note. L'application affiche alors une bannière dédiée pendant la fermeture, mais aussi jusqu'à sept jours avant, pour prévenir en amont.

Aucun back-office, aucune base de données à administrer. C'est un choix délibéré : le projet doit rester gratuit à faire tourner et simple à maintenir dans la durée. Un service bénévole qui coûte cher est un service qui s'arrête.

Conçue pour le pire moment

Le contexte d'usage de cette application est exactement celui où tout se dégrade : mauvais réseau, batterie faible, urgence. L'architecture en tient compte.

Un service worker met l'interface en cache : l'application s'ouvre même sans connexion, avec la dernière valeur connue. La stratégie est « réseau d'abord » sur les données critiques, avec repli automatique sur le cache en cas d'échec. Les délais d'expiration sont courts — mieux vaut afficher une donnée horodatée qu'un écran de chargement infini.

L'ensemble pèse une trentaine de kilo-octets, sans aucun framework. La page se charge en une fraction de seconde, y compris sur un réseau dégradé. Côté technique, une fonction serverless relaie l'appel à l'API publique : elle règle les restrictions CORS et garde la clé d'accès hors du navigateur.

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

Il n'a ni tableau de bord, ni authentification, ni tunnel de conversion. Il fait une chose, bien, pour des gens qui n'ont pas trois minutes à y consacrer. C'est la logique que j'applique aux projets clients.

Partir de l'usage réel, pas de la liste de fonctionnalités. Exploiter l'open data existant plutôt que reconstruire une donnée déjà produite. Choisir la PWA quand l'application doit être accessible sans friction d'installation ni double développement iOS et Android. Et concevoir pour la dégradation : réseau absent, API en panne, donnée manquante — l'interface doit rester utile.

Collectivités, syndicats de rivière, offices de tourisme, gestionnaires d'équipements : vous disposez souvent de données précieuses qui restent invisibles pour vos administrés. Le travail utile consiste rarement à produire une donnée de plus. Il consiste à la rendre lisible au moment où elle compte.

Questions fréquentes

Le Pont Roman de Bédarrides est-il fermé en ce moment ? L'application affiche le statut à partir du débit mesuré de l'Ouvèze. C'est une aide à la décision : elle ne remplace ni la signalisation sur place, ni les consignes des autorités compétentes.

À partir de quel débit le pont est-il fermé ? L'application applique un seuil de vigilance à 80 m³/s et un seuil de fermeture à 100 m³/s, tous deux paramétrables. La décision officielle relève des autorités locales.

D'où proviennent les données ? De l'API publique Hubeau, éditée par Eau France et alimentée par les stations hydrométriques du réseau Vigicrues. La source et l'heure de la dernière mesure sont affichées dans l'application.

Qu'est-ce qu'une PWA ? Une application web progressive : un site qui s'installe sur l'écran d'accueil, fonctionne hors ligne et se comporte comme une application, sans téléchargement depuis un magasin d'applications.