Parkings aéroport · B2B SaaS
Cinq canaux de réservation, une seule file d'attente.
Un exploitant de parking aéroport vend par Parkos, par AlloPark, par son propre site, par e-mail et par API. Cela fait cinq sources de vérité qui se contredisent le matin d'un départ chargé. ParkAgenda les ramène à une seule, puis fait tourner l'exploitation par-dessus.
Voir le système en productionLe problème
Un exploitant qui gère entre un et cinquante sites vend rarement par un seul canal. Les places partent chez des revendeurs comme Parkos et AlloPark, sur son propre site, par e-mail, et parfois par une API cliente. Chaque canal a son format, son délai et sa façon d'annuler.
Tant que ces flux restent séparés, personne ne sait combien de voitures arrivent réellement demain matin. Le comptoir recompte à la main, le planning des chauffeurs se fait au jugé, et la surréservation se découvre sur le parking plutôt que sur un écran.
Le problème n'est pas le volume. C'est que la réservation, l'arrivée, la navette, la remise du véhicule et l'encaissement vivent dans cinq outils différents, souvent un tableur parmi eux.
Ce que nous avons fait
Nous avons construit une ingestion unique qui normalise chaque canal vers le même objet réservation, quelle que soit sa provenance. Les revendeurs, le site direct, l'e-mail et l'API arrivent dans la même file, avec les mêmes règles d'annulation et de modification.
L'exploitation se pose ensuite dessus : affectation des navettes et suivi temps réel, planning des chauffeurs, dispatchers et agents de comptoir, état des lieux du véhicule avec photos et signature, encaissement sur site et réconciliation de caisse.
Le socle technique est un .NET 8 sur Azure Functions en isolated worker, EF Core sur SQL Server, des Storage Queues pour découpler l'ingestion du traitement, et Application Insights pour la supervision. Le découpage Domain, Application, Infrastructure est tenu strictement, parce qu'un objet réservation qui vient de cinq sources différentes devient ingérable dès que la règle métier se disperse dans les contrôleurs.
L'application tourne dans le navigateur, sans installation, sur poste, sur tablette au comptoir et sur écran mural en salle d'exploitation.
Où cela en est
ParkAgenda est en production. Le site public affiche le volume de réservations traitées dans la journée, donc l'activité réelle est vérifiable sans nous demander quoi que ce soit.
Les exploitants disposent d'une occupation en temps réel, d'un reporting de commissions par canal et d'exports CSV et PDF pour la comptabilité.
Nous ne publions pas de gain chiffré côté client. Aucun chiffre d'exploitation ne nous a été communiqué pour publication, et nous préférons une page sans pourcentage à un pourcentage que personne ne peut recouper.
- .NET 8
- Azure Functions (isolated worker)
- EF Core
- SQL Server
- Azure Storage Queues
- Application Insights
Le même socle .NET et Azure que Comparkly. Deux produits différents, une seule discipline d'ingénierie, ce qui veut dire que l'équipe qui a livré l'un connaît déjà la structure de l'autre.
Questions fréquentes
- ParkAgenda est-il un produit JADEV ou un projet client ?
- C'est un produit que nous détenons et exploitons, pas une prestation livrée puis quittée. Nous le citons comme preuve d'ingénierie, pas comme recommandation d'un client. La distinction compte et nous la maintenons partout sur ce site.
- Pouvez-vous construire la même ingestion multicanal pour nous ?
- Oui, et c'est le motif qui revient le plus souvent : plusieurs sources de commandes, de stock ou de réservations qui doivent devenir une seule file fiable. Le domaine change, le problème de normalisation et d'idempotence reste le même.
- Qui détient le code sur un projet équivalent ?
- Vous. Sur une mission client, le dépôt et les comptes cloud sont les vôtres du premier jour. ParkAgenda est l'exception parce que c'est notre propre produit.
Plusieurs sources, une seule vérité ?
Décrivez vos canaux et ce qui se désynchronise aujourd'hui, sans code confidentiel ni données personnelles. Nous cadrons le périmètre avant toute proposition.
Décrire mon besoin- Dette technique : la comprendre, la chiffrer, la traiterLa moitié de ce qu'on appelle dette technique n'en est pas. Comment distinguer un emprunt assumé d'un simple désordre, comment rendre le coût lisible à un dirigeant, et pourquoi une partie de cette dette ne mérite pas d'être remboursée.
- Plateforme de réservation sur mesure : le budget réelCinq blocs techniques, une grille publiée de 150 à 450 EUR par jour et des exemples chiffrés issus de plateformes de réservation que nous opérons en production.
- Idempotence des paiements iDEAL et BancontactUn webhook rejoué suffit à débiter deux fois le même voyageur. Nous expliquons la clé d'idempotence qui rend ce scénario impossible, vécue en production sur des plateformes de réservation avec iDEAL et Bancontact.
- Ingestion de données machines vers Azure : le motifLe motif qui rend la remontée des données machines vers Azure fiable en conditions d'usine : une file d'attente entre l'atelier et le cloud, chiffrée en jours d'ingénierie sur notre grille publique.
- AutoMotoMarket.be · Marketplace véhicules d'occasionIngestion des stocks AutoScout et mobile.de, import CSV et XML, vendeurs vérifiés, trois langues, offre professionnelle par abonnement.
- Pavimmo · Migration CRM sans interruption d'activitéDes années d'historique client nettoyées, mappées et réconciliées, avec le système source en production du premier au dernier jour.