Des adaptateurs avant les abstractions
Les particularités des sources restent dans les connecteurs ; le reste du système utilise une représentation commune.
Produit d’ingénierie personnel · en production
Données de stationnement en Suisse
J’ai transformé une recherche de parking fragmentée en findparking.ch : un produit public qui réunit disponibilité en direct, contexte historique et prévisions à court terme dans plusieurs villes suisses. J’ai conçu, développé et déployé l’ensemble du système, que je continue d’exploiter.
Responsabilité technique
Je prends en charge tout le cycle technique et produit.
5villes en ligne
~90parkings
Depuis sept. 2025observations historiques
< 10 CHF/moishébergement VPS
01 — Genèse
Un vrai problème au volant, pas un récit de start-up.
Lorsque je me rendais à Zurich en voiture, vérifier la disponibilité des parkings était inutilement fragmenté. L’information existait, mais comparer plusieurs parkings pertinents obligeait à consulter leurs sources séparément.
La première idée produit était volontairement simple : réunir plusieurs parkings pour qu’un conducteur compare immédiatement leur disponibilité actuelle.
Une seconde question est apparue très tôt. Si je pars dans 30 à 60 minutes, le chiffre actuel ne suffit pas : le parking sera-t-il probablement plus plein ou plus vide ? Il fallait pour cela créer un historique que les sites sources ne fournissaient pas.
02 — Évolution du produit
D’abord utile, puis progressivement plus capable.
- 01
Fin 2025 · MVP en tableaux
La première version publique reposait principalement sur des tableaux de disponibilité. Elle résolvait le problème de comparaison et commençait à collecter des observations sans attendre une interface sophistiquée.
- 02
Constitution de l’historique
Des instantanés planifiés ont transformé des valeurs publiques éphémères en séries temporelles. L’historique de production remonte aujourd’hui approximativement à septembre 2025.
- 03
Vers juin 2026 · essais de prévision
Zurich a servi de premier cas de développement et de test pour la prévision à court terme, avant la comparaison systématique de plusieurs approches.
- 04
Architecture multi-ville
Une fois la chaîne commune créée, les nouvelles villes ont pu réutiliser stockage, évaluation et présentation en n’ajoutant qu’un adaptateur d’ingestion propre à leur source.
- 05
Produit actuel
Le MVP en tableaux est devenu une interface publique responsive et soignée, combinant cartes comparables et carte géographique interactive.
L’ordre compte : le produit était déjà utile pendant que la donnée historique et les fonctions plus expérimentales continuaient de se construire.
03 — Architecture
Contenir la complexité propre aux sources à la frontière.
Les villes et exploitants suisses publient les données de stationnement via des formats et des endpoints hétérogènes, notamment XML et JSON. Le produit ne repose pas sur une API suisse standardisée unique.
Chaque ville dispose donc de son propre connecteur de récupération et d’adaptation. Après normalisation vers une représentation interne commune, le stockage PostgreSQL, les prévisions et leur évaluation, l’application Flask et l’interface sont partagés.
Architecture de production
Sources publiques hétérogènes
XML · JSON · autres endpoints
↓XML · JSON · autres endpoints
Adaptateurs par ville
↓Représentation commune et validation
↓Observations historiques
PostgreSQL sur le VPS
PostgreSQL sur le VPS
Prévision et évaluation
~8 approches · MAE
~8 approches · MAE
Contrôles opérationnels
fraîcheur · échecs · alertes
fraîcheur · échecs · alertes
↓
Application Python + Flask
↓Liste responsive + Leaflet / OpenStreetMap
04 — Chaîne de données
D’une mise à jour éphémère à une prévision évaluée.
- 01
Récupérer
Un connecteur appelle la source publique de la ville et traite son format particulier.
- 02
Adapter
Les champs et états propres à la ville sont traduits vers la structure interne commune.
- 03
Valider et stocker
Les observations exploitables sont enregistrées dans PostgreSQL avec leur horodatage au lieu d’écraser l’état précédent.
- 04
Produire les prévisions
Des tâches planifiées génèrent des estimations à court terme lorsque l’historique et les données fraîches sont suffisants.
- 05
Évaluer
Les prévisions sont comparées aux disponibilités observées ensuite et l’erreur des modèles est suivie, notamment avec la MAE.
- 06
Présenter et surveiller
Flask sert les cartes et la carte publique ; des vues privées exposent fraîcheur, état des tâches et problèmes détectés.
Des tâches cron conventionnelles suffisent à cette échelle : ingestion environ toutes les 5 minutes, prévisions toutes les 15 minutes et sauvegardes quotidiennes. Ces cadences différentes évitent de recalculer les prévisions après chaque observation brute.
05 — Décisions produit et techniques
Maîtriser délibérément la complexité.
L’historique avant la prévision
Collecter tôt les instantanés a créé la matière nécessaire aux prévisions, sans imposer cette fonction à un historique insuffisant.
Cron avant une infrastructure d’orchestration
Des planifications distinctes restent explicites et simples à exploiter sur un serveur modeste. Plus d’infrastructure n’apporterait pas encore une valeur proportionnée.
Détecter sans prétendre tout autoréparer
La surveillance distingue les échecs de l’application des données amont absentes, périmées ou modifiées. La résolution exige encore un diagnostic et parfois l’adaptation d’un connecteur.
06 — Données historiques
Le jeu de données manquant devait se construire avec le temps.
Les observations de production remontent approximativement à septembre 2025. Aucun nombre de lignes, volume de base ou performance de requête n’est publié, faute de valeur vérifiée ici.
Chaque mise à jour conservée transforme la disponibilité en série temporelle observable plutôt qu’en chiffre jetable. PostgreSQL sur le VPS sert l’application en direct, les comparaisons historiques et la chaîne de prévision et d’évaluation.
La valeur se construit progressivement. Une nouvelle ville ne peut rejoindre le cadre de prévision commun qu’après ingestion d’une source publique compatible et accumulation d’un historique suffisant ; l’architecture ne peut pas compenser des données qu’un exploitant ne publie pas.
Comment l’historique transforme le produitSource à un instant donné
↓Disponibilité actuelle
findparking.ch dans le temps
Disponibilité actuelle
+ Comparaison à une heure
+ Observations historiques
+ Estimations à court terme
+ Évaluation des prévisions
07 — Expérimentation de prévisions
Comparer les approches avant de choisir la meilleure.
Le système actuel est en phase d’expérimentation et d’évaluation, et non une plateforme de machine learning aboutie. Environ huit approches de prévision sont comparées plutôt que de présenter prématurément un modèle comme le meilleur.
Les prévisions sont stockées puis comparées à la disponibilité réellement observée. Le tableau de bord opérationnel privé suit la performance avec des mesures dont l’erreur absolue moyenne (MAE), afin de fonder la sélection sur des résultats.
L’interface publique expose actuellement des estimations à une heure et trois heures lorsque les données sont fraîches, la capacité connue et un modèle à jour disponible. Elles sont clairement présentées comme des estimations, jamais comme des garanties.
08 — Produit public actuel
Une interface moderne pour une décision prise en déplacement.
L’utilisateur peut parcourir des cartes de parking responsive ou passer à une vue géographique. Chaque carte affiche les places libres et la capacité connue, un état coloré, l’évolution et la disponibilité environ une heure plus tôt, la fraîcheur des données et, lorsqu’elles sont valides, les estimations à court terme.
La carte utilise Leaflet avec OpenStreetMap et présente géographiquement le même contexte essentiel. L’expérience actuelle a largement dépassé le MVP en tableaux, tout en restant centrée sur la comparaison pratique.
Consultez la disponibilité actuelle et les estimations à court terme dans les villes suisses prises en charge.
Aller sur findparking.ch ↗09 — Exploitation en production
Le déploiement a marqué le début du travail de fiabilité.
Un tableau de bord interne protégé par mot de passe couvre l’état des ingestions, la fraîcheur des données, les tâches de prévision, les problèmes détectés et les comparaisons de modèles basées sur la MAE. L’authentification protège cette vue opérationnelle ; il ne s’agit pas d’un système de comptes grand public.
De vrais échecs de tâches planifiées et problèmes de données amont ont motivé la surveillance et les alertes. Certains incidents viennent de l’application ; d’autres d’un exploitant qui cesse de publier, renvoie des données périmées ou inutilisables, ou modifie sa source. La réponse reste pragmatique : détecter, diagnostiquer et adapter, sans promettre disponibilité parfaite ni réparation automatique.
10 — Amélioration continue
Garder un produit utile tout en apprenant dans un système réaliste.
Deux objectifs parallèles
Le développement continue à la fois pour améliorer le produit réel et pour disposer d’un environnement crédible d’expérimentation technique.
Chaque complexité doit se justifier
Un écosystème complet de comptes, des notifications étendues, les paiements et l’infrastructure commerciale restent volontairement hors du produit actuel.
Séparer expérimentation et production
Azure et Snowflake sont explorés et prototypés pour acquérir une expérience pratique ; ils ne sont pas présentés comme des dépendances critiques de la production.
Une petite exploitation reste une vraie exploitation
Un VPS modeste et cron suffisent pour apprendre des incidents réels sans construire une infrastructure dont le produit n’a pas besoin.
11 — État actuel
Un produit public, de vraies données et un périmètre volontairement modeste.
Le résultat professionnel tient au cycle complet, pas à une traction commerciale : idée, MVP en tableaux, collecte continue, essais de prévision, interface responsive, production, surveillance, maintenance et feuille de route composent un même produit.
Le site est public, mais l’acquisition d’utilisateurs n’est pas un objectif actuel. J’en suis le principal utilisateur régulier, avec un usage occasionnel par des amis et d’autres personnes ayant reçu le lien ; aucune mesure significative de MAU, DAU ou trafic n’est disponible.
12 — Responsabilité de bout en bout
Je prends en charge tout le cycle technique et produit.
J’ai identifié le problème, cadré et livré la première version utile, conçu la frontière des connecteurs et l’historique PostgreSQL, développé l’application Flask et son interface responsive, introduit l’évaluation des prévisions et déployé le produit sur un VPS Linux.
Je l’exploite également : planification des tâches, sauvegardes, surveillance de la fraîcheur et de la performance des modèles, réponse aux échecs applicatifs ou amont, et choix des améliorations qui méritent réellement d’être ajoutées.
Positionnement : il s’agit d’un projet personnel d’ingénierie et de produit, développé hors de mon emploi. Aucun client, processus de parties prenantes d’entreprise, rôle de chef d’équipe ou récit de traction commerciale ne le sous-tend. Sa valeur est de prouver directement ma capacité à mener un produit technique d’un problème personnel à l’exploitation en production et à son amélioration continue.
13 — Feuille de route à long terme
Le mobile est la suite produit naturelle, pas une fonction actuelle.
La disponibilité des parkings est un cas d’usage mobile et temps réel. Une application native est une direction future, et non une livraison engagée ni une fonction déjà en développement.
Vue personnalisée en direct
Des comptes et favoris pourraient offrir des vues persistantes centrées sur les parkings réellement utilisés.
Notifications plus riches
Le suivi de parkings choisis pourrait rendre les changements plus actionnables sans transformer chaque mise à jour en bruit.
Expérience mobile native
Une application pensée pour le téléphone pourrait accélérer la comparaison avant et pendant le trajet.
Éventuelle couche commerciale
Paiements ou autres fonctions commerciales ne seraient envisagés que si le produit évolue réellement dans cette direction.