Open data à Pau : quelles applications utiles peut-on réellement construire ?

L’open data donne parfois l’impression qu’une application locale pourrait être créée simplement en branchant quelques API sur une carte. Les données existent effectivement autour de Pau, notamment sur la mobilité, l’immobilier, les équipements, les entreprises et le découpage territorial. Elles sont toutefois réparties entre plusieurs producteurs, publiées à des rythmes différents et rarement prêtes à répondre directement à une question métier.

Cette dispersion ne rend pas les projets impossibles. Elle explique plutôt pourquoi deux applications utilisant les mêmes fichiers peuvent avoir une valeur très différente. La première affiche des points sur un fond de carte ; la seconde nettoie les données, rapproche les bons territoires, explique la fraîcheur des sources et transforme l’ensemble en une information réellement utilisable.

À Pau comme ailleurs, l’enjeu n’est donc pas de prouver que des données sont disponibles. Il consiste à identifier ce qu’elles permettent d’observer sans exagération, puis à construire une interface adaptée à une décision concrète : comprendre l’accès à un service, comparer des secteurs, suivre une évolution ou piloter une action.

Quelles données sont réellement disponibles autour de Pau ?

La première difficulté vient du catalogue lui-même. Les données qui concernent Pau ne sont pas toutes publiées par la Ville ou la Communauté d’agglomération sous une bannière unique. Une recherche sérieuse passe par data.gouv.fr, ses portails thématiques, les organismes nationaux comme l’INSEE ou la DGFiP et les producteurs locaux spécialisés.

Sur data.gouv.fr, le principal ensemble local directement exploitable est actuellement publié par Pau Béarn Pyrénées Mobilités. L’organisation référence une vingtaine de jeux portant sur le réseau IDELIS, les arrêts, les lignes, les horaires, les parkings relais, les communes desservies, les stations IdeCycle et le réseau scolaire. Plusieurs ressources ont été actualisées en juillet 2026, ce qui permet d’envisager des usages bien plus concrets qu’une simple archive statistique.

Le réseau urbain IDELIS est diffusé au format GTFS pour l’offre théorique et via une API SIRI pour les informations de passage en temps réel. Le GTFS décrit notamment les lignes, arrêts, horaires et calendriers de circulation. Le temps réel permet d’aller plus loin, mais ajoute des contraintes de disponibilité, d’authentification et de surveillance du service.

Les vélos en libre-service disposent également d’un flux au standard GBFS. Ce format peut exposer les stations, leur capacité et la disponibilité des vélos ou emplacements. Il devient ainsi possible de distinguer une carte statique des stations d’un outil qui aide à comprendre l’état du service à un moment donné.

Pour l’immobilier et l’aménagement, les sources sont davantage nationales. Les Demandes de valeurs foncières recensent les mutations enregistrées par la DGFiP, tandis que le Plan cadastral informatisé décrit les parcelles et certains éléments bâtis. Ces données peuvent être filtrées sur Pau et les communes voisines, mais leur exploitation demande un véritable travail géographique et méthodologique.

L’INSEE publie la Base permanente des équipements, qui décrit les services et équipements accessibles à la population, souvent jusqu’au niveau communal ou IRIS. La base Sirene permet quant à elle d’étudier les établissements et activités économiques, avec les précautions nécessaires sur le statut de diffusion, la géolocalisation et l’interprétation des créations ou cessations.

Le constat est donc nuancé. Pau ne dispose pas d’un catalogue local exhaustif couvrant toutes les politiques publiques avec des métadonnées uniformes. Le territoire bénéficie néanmoins de sources suffisamment riches pour construire des produits utiles, à condition d’accepter que la collecte soit multi-source et qu’une partie du travail porte sur les identifiants, les dates et les niveaux géographiques.

Ce que ces données peuvent permettre de comprendre

Une donnée brute répond rarement à une question à elle seule. Une liste d’arrêts décrit un réseau, mais ne mesure pas l’accessibilité réelle d’un quartier. Une vente immobilière indique une transaction, mais ne définit pas automatiquement le prix d’un secteur. Un établissement Sirene signale une unité administrative ou économique, sans raconter à lui seul la vitalité commerciale d’une rue.

La valeur apparaît lorsque plusieurs sources sont rapprochées autour d’une définition claire. Ce rapprochement doit rester explicable : quel périmètre, quelle période, quelle unité de mesure et quelles exclusions ont été retenus ? Sans ces précisions, une visualisation élégante peut donner une impression de certitude supérieure à la qualité réelle de la donnée.

Territoire et mobilité

Les données IDELIS permettent d’abord de représenter l’offre théorique : emplacement des arrêts, lignes qui les desservent, horaires et correspondances possibles. Croisées avec le découpage communal, les équipements ou la population, elles peuvent aider à examiner la proximité entre certains services et le réseau de transport.

Une application pourrait par exemple montrer quels établissements de santé, sites universitaires ou zones d’activité sont accessibles depuis une commune avec un nombre limité de correspondances. Le résultat ne serait pas une vérité absolue sur la mobilité. Il dépendrait des horaires retenus, des temps de marche, des jours de fonctionnement et de l’accessibilité effective des parcours.

Le temps réel ouvre d’autres usages. Une interface peut afficher les prochains passages, signaler une perturbation ou comparer ponctualité théorique et observations collectées. Ce type de produit demande toutefois une infrastructure plus robuste qu’une carte statique : les flux doivent être interrogés régulièrement, les indisponibilités gérées et les données conservées si l’on souhaite analyser l’historique.

Les stations IdeCycle et les parkings relais peuvent compléter cette lecture. Leur simple localisation aide déjà à comprendre l’intermodalité. L’ajout de la disponibilité en temps réel permet d’envisager une aide au déplacement, mais seulement si la fraîcheur du flux est connue et affichée à l’utilisateur.

Immobilier et aménagement

Les données DVF permettent d’observer les ventes réellement enregistrées, leur nature, leur valeur et leur localisation lorsque le rapprochement cadastral est possible. Elles sont particulièrement utiles pour comparer des volumes, des médianes ou des répartitions sur plusieurs années. Elles ne constituent pas une estimation instantanée de chaque logement et ne reflètent pas les prix actuellement demandés dans les annonces.

Le cadastre apporte une lecture parcellaire et bâtie. Il peut servir à situer une transaction, comprendre la forme d’un terrain ou construire une interface autour de l’aménagement. Il ne contient pas pour autant toutes les informations utiles sur les propriétaires, l’état des bâtiments, les règles d’urbanisme ou les projets futurs. Certaines données restent fermées, protégées ou publiées dans d’autres systèmes.

La réalisation Pau Data Immo illustre ce travail de transformation : les ventes DVF sont nettoyées, géolocalisées et présentées avec des filtres et indicateurs locaux. Le projet distingue aussi les transactions enregistrées des annonces actives, car ces deux sources ne mesurent pas la même réalité. Cette séparation méthodologique compte davantage que le nombre de graphiques affichés.

D’autres applications pourraient étudier la disponibilité des équipements autour d’un secteur, les distances aux transports ou l’évolution des mutations dans certaines communes. Elles doivent éviter de transformer une corrélation spatiale en causalité : la présence d’un arrêt ou d’un commerce à proximité ne suffit pas à expliquer une différence de prix.

Services publics et activité économique

La Base permanente des équipements permet de cartographier des services comme les établissements d’enseignement, les structures de santé, les commerces ou les équipements sportifs. Elle peut alimenter une lecture de l’accessibilité territoriale, à condition de respecter sa nomenclature et son millésime. Un équipement recensé n’indique pas toujours sa capacité, ses horaires ou la qualité du service rendu.

Sirene apporte une autre perspective. En filtrant les établissements actifs sur un périmètre et des codes d’activité, il devient possible de décrire la composition économique d’une zone, de repérer des concentrations ou de suivre des évolutions. Il faut néanmoins distinguer unités légales et établissements, créations administratives et ouvertures réellement visibles, sièges sociaux et sites d’exploitation.

Ces sources peuvent soutenir une étude d’implantation, un annuaire sectoriel ou un outil de connaissance économique. Elles gagnent souvent à être croisées avec des données internes : demandes reçues par une structure, fréquentation d’un service, disponibilités réelles ou retours des usagers. L’open data fournit le contexte ; les données métier apportent généralement la capacité d’agir.

Des données brutes à un véritable outil métier

Télécharger un CSV constitue le début du travail, pas son aboutissement. Les formats, noms de colonnes et identifiants diffèrent d’un producteur à l’autre. Une commune peut être désignée par son nom, son code INSEE ou un périmètre géographique ; une date peut correspondre à l’événement, à la publication ou à la dernière modification du fichier.

La première étape technique consiste à conserver la source brute et sa provenance. Chaque import doit pouvoir être relié à une URL, une date de collecte, une version et une licence. Cette traçabilité permet de comprendre pourquoi un indicateur a changé et de rejouer le traitement lorsque le producteur corrige ses données.

Vient ensuite la normalisation. Les communes sont rattachées à des identifiants stables, les catégories sont harmonisées et les géométries converties dans un système cohérent. Les doublons ou valeurs impossibles ne doivent pas être supprimés silencieusement : ils sont signalés, corrigés selon une règle documentée ou exclus du calcul avec une justification.

Ce travail rejoint les principes décrits pour concevoir la base de données d’une application web de PME. La structure doit représenter les objets réellement utilisés : sources, versions, territoires, équipements, observations, indicateurs et éventuellement utilisateurs. Un seul tableau géant facilite rarement les évolutions ou les contrôles.

L’outil métier commence lorsque les données sont reliées à un parcours. Un chargé d’étude veut comparer deux communes ; un responsable mobilité cherche les arrêts mal reliés à un équipement ; un commerçant examine un secteur ; un service interne suit l’évolution d’un indicateur. L’interface, les filtres et les calculs doivent servir ce besoin précis.

L’automatisation intervient après cette clarification. Une collecte quotidienne n’a pas d’intérêt si personne ne sait quelle décision dépend de la mise à jour. À l’inverse, une source réellement opérationnelle peut justifier une ingestion fréquente, des alertes en cas d’échec et un historique permettant de revenir sur les valeurs précédentes.

Quels produits numériques peut-on imaginer ?

Les mêmes sources peuvent alimenter plusieurs formes de produit. Le choix dépend moins de la technologie que de la question posée et du rythme auquel les données doivent être consultées. Une carte publique, un observatoire éditorial et un dashboard interne ne répondent pas au même usage, même lorsqu’ils partagent une base géographique commune.

Observatoire local

Un observatoire suit un phénomène dans le temps et rend sa méthode compréhensible. Il peut porter sur l’immobilier, la mobilité, l’activité économique, l’accès aux services ou la transition d’un territoire. Sa valeur repose sur la stabilité des définitions : une série ne doit pas changer de sens en cours de route sans que l’utilisateur en soit informé.

L’historisation est donc centrale. Il faut conserver les millésimes, recalculer les indicateurs de manière reproductible et distinguer les corrections de source des évolutions réelles. Un observatoire sérieux affiche aussi les volumes derrière une moyenne ou une médiane, car un résultat calculé sur quelques observations n’a pas la même solidité qu’une tendance établie sur plusieurs centaines de cas.

Ce format convient lorsque l’objectif est de rendre un sujet local lisible à plusieurs publics. Il demande un travail éditorial en plus du développement : définitions, notes méthodologiques, commentaires et explication des ruptures de série.

Carte interactive

La carte répond à la question « où ? ». Elle devient utile lorsque la position apporte une information que la liste seule ne montre pas : proximité, concentration, couverture, distance ou relation entre plusieurs couches. Une carte des arrêts, équipements et stations de vélos peut ainsi aider à explorer un quartier ou préparer un déplacement.

L’interface doit limiter la densité visuelle. Afficher simultanément chaque vente, entreprise, arrêt et équipement autour de Pau produit rapidement un nuage illisible. Les filtres, regroupements, niveaux de zoom et choix de couches sont des décisions de produit, pas de simples options graphiques.

La performance compte également. Plusieurs dizaines de milliers de géométries ne doivent pas être envoyées intégralement au navigateur à chaque ouverture. Selon le volume, l’application utilise des tuiles, des agrégations, une API spatiale ou des requêtes limitées à la zone visible.

Dashboard d’aide à la décision

Le dashboard se concentre sur quelques indicateurs liés à une action. Il peut suivre la disponibilité d’un service, comparer des zones, repérer une variation ou mesurer l’effet d’une politique. Sa principale difficulté n’est pas de dessiner des graphiques, mais de définir ce que chaque chiffre signifie et à quel moment il devient actionnable.

Pour une collectivité ou une entreprise, l’open data peut enrichir des données internes. Un réseau commercial rapproche ses implantations de la population et des établissements ; un service de mobilité compare son activité avec l’offre théorique ; une structure immobilière confronte son portefeuille au marché enregistré. Le produit devient alors hybride, avec des droits d’accès et des niveaux de confidentialité distincts.

Un projet d’application web et de dashboard doit aussi prévoir les exports, les rôles, l’historique et les alertes. Le tableau de bord n’est pas nécessairement public, même lorsque certaines de ses sources le sont. Les calculs internes, commentaires ou données opérationnelles peuvent rester réservés aux équipes.

Les limites techniques et méthodologiques de l’open data

La fraîcheur constitue la limite la plus visible. Les flux de mobilité peuvent être actualisés quotidiennement ou en temps réel, tandis que les statistiques et données foncières arrivent avec un décalage. Mélanger ces temporalités dans un même écran sans les expliquer crée une fausse impression de simultanéité.

La couverture varie également. Un jeu peut être complet à l’échelle communale mais trop grossier pour un quartier. Une géolocalisation peut correspondre à une adresse administrative plutôt qu’au lieu réel d’activité. Certains équipements sont recensés sans information sur leurs capacités, leur accessibilité ou leur ouverture effective.

Les jointures géographiques introduisent leurs propres erreurs. Un point situé à quelques mètres d’une limite peut changer de quartier selon la géométrie utilisée. Les codes communes évoluent, les IRIS peuvent être redécoupés et les adresses ne se géocodent pas toutes avec la même précision. Un résultat local doit donc conserver une notion de confiance ou au moins documenter son mode de rattachement.

Les licences autorisent souvent la réutilisation, y compris commerciale, mais elles imposent des conditions d’attribution ou de partage selon les cas. Le projet doit conserver cette information dès l’ingestion. Une ressource récupérée sur un portail public ne devient pas automatiquement libre de toute obligation.

Les données personnelles demandent une vigilance supplémentaire. Sirene contient des informations diffusibles sur des entreprises et parfois des entrepreneurs individuels, mais leur disponibilité ne dispense pas d’un usage proportionné. Croiser plusieurs sources pour profiler des personnes ou publier des informations sensibles peut créer un risque juridique et éthique absent de chaque fichier pris séparément.

Enfin, l’absence de données est elle-même une limite. Une question intéressante peut nécessiter une information qui n’est pas publiée, n’existe pas sous forme structurée ou appartient à un acteur privé. Il faut alors réduire l’ambition, organiser une collecte complémentaire ou reconnaître que l’indicateur ne peut pas être produit de manière fiable.

Comment démarrer un projet data sans construire une usine à gaz

Un bon projet commence par une question formulée sans référence à la technologie. « Où les usagers rencontrent-ils une rupture entre transport et service ? » est plus utile que « nous voulons une carte open data ». La question permet d’identifier l’utilisateur, la décision attendue et le niveau de précision réellement nécessaire.

Le premier périmètre peut se limiter à deux ou trois sources. Pour une lecture de la mobilité, le GTFS IDELIS, les équipements INSEE et les limites communales offrent déjà beaucoup de matière. Pour l’immobilier, DVF, cadastre et découpage territorial suffisent à construire une première analyse, sans ajouter immédiatement des dizaines de jeux annexes.

Une phase exploratoire doit tester la qualité avant de concevoir tous les écrans. Quelques imports permettent de mesurer les valeurs manquantes, les incohérences, les volumes et les difficultés de jointure. Cette étape produit un dictionnaire des données et une première note méthodologique, deux livrables souvent plus utiles qu’une maquette spectaculaire construite sur des hypothèses fragiles.

Le prototype vient ensuite. Il répond à un parcours principal avec un nombre limité de filtres et d’indicateurs. Des utilisateurs réels peuvent alors dire si l’information les aide, ce qui manque et ce qu’ils interprètent mal. Les évolutions sont décidées à partir de ces retours, pas selon la quantité de données encore disponibles dans le catalogue.

La mise en production ajoute enfin les sujets que la démonstration masque : surveillance des sources, reprise après erreur, coûts de cartographie, sauvegardes, performance, accessibilité et documentation. Un produit open data reste un logiciel à maintenir. Ses données sont publiques, mais sa fiabilité dépend d’un travail continu.

À Pau, la matière permet déjà de construire des cartes, observatoires et outils d’aide à la décision crédibles. La bonne approche ne consiste pas à tout agréger, mais à choisir un problème local précis, établir une méthode que l’on peut expliquer et enrichir le produit seulement lorsque la première lecture apporte réellement quelque chose.