Avec Fillzz, nous concevons et développons une application qui accompagne une décision concrète : choisir une station adaptée à son véhicule et à son trajet, puis s’y rendre. Derrière cette expérience, notre travail relie le traitement des données stations, la recherche géographique, la navigation et la conversion des nouveaux utilisateurs.
Fillzz est un produit propre de Klaapp. Nous portons donc aussi les questions qui suivent le développement : comment rendre la valeur de l’app compréhensible, où les utilisateurs abandonnent-ils et quelles évolutions méritent le temps investi ? Voici les choix de conception et les mécanismes techniques sur lesquels nous travaillons.
Fillzz en chiffres : la donnée à l’échelle du produit
400 000+ stations référencées dans la couverture de Fillzz.
20+ pays couverts au sein d’une même application.
100 000 utilisateurs pour lesquels nous concevons et faisons évoluer le produit.
Chiffres de référence communiqués par l’équipe Fillzz en septembre 2026.
Cette échelle donne une autre dimension au travail. Chaque station peut porter plusieurs carburants, des prix successifs, des horaires, des services et des informations de localisation. Le volume à traiter dépasse donc largement le seul nombre de points affichés sur une carte. Il faut actualiser ces données en continu et les rendre consultables par une base de 100 000 utilisateurs, chacun avec sa zone, son véhicule et son trajet.
Notre enjeu technique est de relier ces deux flux : absorber les mises à jour des sources et servir rapidement la donnée utile à chaque utilisateur. La normalisation, la reprise des imports, les recherches géographiques et la maîtrise des données envoyées au mobile font partie d’une même conception.
Partir du plein à effectuer pour concevoir le parcours
Notre point de départ produit est le contexte de l’automobiliste. Une station intéressante dépend du carburant recherché, du prix disponible, de sa fraîcheur et de la localisation. Lorsqu’une personne prépare un déplacement, la zone qu’elle consulte peut aussi être différente de sa position actuelle.
Nous distinguons donc le lieu de recherche de la position de l’utilisateur. Le conducteur peut examiner une autre ville ; les coordonnées qui décrivent cette recherche ne doivent pas être confondues avec celles utilisées pour situer son départ. C’est une décision produit qui se retrouve dans le contrat de l’API.
La carte, la liste et la fiche station répondent ensuite à des moments différents. La carte aide à se repérer, la liste à comparer, la fiche à décider. Nous concevons leur continuité autour d’un même objet station : une sélection doit garder son sens quand l’utilisateur passe d’une vue à l’autre.
Le travail derrière les stations : transformer des sources en données utilisables
Le traitement des stations est une part structurante de Fillzz. Un flux externe fournit des informations dans son propre format. L’application a besoin d’un modèle stable pour rechercher, filtrer, comparer et afficher ces informations sur mobile.
Nous séparons notamment l’identité de la station, sa localisation, les carburants proposés, les prix horodatés, les ruptures et les services. Cette séparation permet de mettre à jour un prix sans recréer la station et de traiter une rupture sans faire disparaître tout le point de vente.
Normaliser avant d’afficher
Les connecteurs de données doivent traduire les formats des sources vers ce modèle commun. Un exemple très concret concerne les coordonnées : le flux français publie des valeurs à remettre à l’échelle avant de les utiliser sur une carte. La documentation des données publiques des prix des carburants précise ce format, ainsi que les informations de prix, de services et de ruptures disponibles.
Notre chaîne de traitement gère cette conversion, vérifie les coordonnées et rapproche les informations de la station. Elle associe aussi chaque observation de prix à son carburant, sa date, son unité et sa devise. Ces détails conditionnent la justesse de la comparaison : deux valeurs numériques ne deviennent comparables qu’une fois leur signification établie.
Reprendre les mises à jour sans dupliquer l’historique
Un import peut être relancé après une interruption ou recevoir de nouveau une information déjà traitée. Nous utilisons des clés de rapprochement et des règles de conflit pour éviter de multiplier les mêmes observations de prix. Les écritures d’historique sont également découpées en lots pour maîtriser la taille des opérations en base.
Ce travail est peu visible dans une maquette, mais il permet de faire évoluer les sources et les traitements sans reporter toute leur complexité sur l’application. Il donne aussi un cadre pour distinguer une donnée absente d’une donnée ancienne ou d’une rupture de carburant.
| Complexité | Choix dans la conception de Fillzz | Intérêt pour le produit |
|---|---|---|
| Des sources avec leurs propres formats | Connecteurs et normalisation vers des objets communs | Une interface cohérente malgré des données d’origine différentes. |
| Des prix qui évoluent | Observations datées, liées au carburant et à la station | Afficher le prix avec son contexte de fraîcheur. |
| Des synchronisations répétées | Rapprochement des identifiants et gestion des doublons | Reprendre le traitement sans multiplier l’historique. |
| Des stations réparties sur un territoire | Requêtes géographiques et résultats limités au besoin | Fournir une sélection pertinente au téléphone. |
Actualiser la base tout en servant les conducteurs
Les mises à jour ne reposent pas sur le rechargement manuel d’un catalogue. Nous faisons évoluer la base au fil des synchronisations, selon la disponibilité et la cadence des sources de chaque pays. La date d’une observation reste liée au prix : une actualisation continue du système ne signifie pas que toutes les stations publient une nouvelle donnée au même instant.
Nous séparons le travail d’import des requêtes de consultation. Lorsqu’un conducteur déplace la carte, l’API interroge les données préparées dans notre base ; elle ne relance pas la collecte de toutes les sources. Les synchronisations utilisent des verrous pour éviter les exécutions concurrentes d’un même traitement, et les écritures par lots limitent la taille des opérations.
Côté lecture, les requêtes spatiales ciblent une zone et un nombre de résultats. Nous évitons ainsi d’envoyer le catalogue mondial au téléphone pour une recherche locale. Cette répartition permet de travailler ensemble la fraîcheur des informations, le temps de réponse, le volume transféré et la charge côté mobile.
C’est une compétence que nous apportons aussi aux projets de nos clients : concevoir une chaîne de données qui alimente un usage réel, depuis les sources externes jusqu’à l’écran, en tenant compte de la croissance du catalogue et du nombre d’utilisateurs.
Une carte lisible demande aussi des choix de performance
Dans Fillzz, nous répartissons le travail entre la recherche côté serveur et l’affichage côté mobile. L’API recherche les stations dans une zone géographique, applique les critères et limite les résultats. Le téléphone organise ensuite ces résultats pour que l’utilisateur puisse les lire et les manipuler.
Lorsque plusieurs stations sont proches à l’écran, nous les regroupons en ensembles qui se déploient avec le zoom. Nous préservons aussi la station sélectionnée et son voisinage dans l’affichage individuel. L’utilisateur garde ainsi son point de repère pendant qu’il compare les options autour de lui.
Les calculs de regroupement et de distance réutilisent des résultats lorsque les données concernées n’ont pas changé. Cette optimisation a une finalité d’usage : laisser la carte répondre aux gestes, sans refaire inutilement tout le travail à chaque interaction.
C’est le type d’arbitrage que nous cherchons dans une application géolocalisée. Le nombre de points supportés compte, mais la stabilité d’une sélection, la compréhension des filtres et la fluidité du déplacement comptent tout autant dans l’expérience.
Relier le choix d’une station à la navigation
Nous avons conçu le parcours pour prolonger la comparaison jusqu’au trajet. Fillzz propose un guidage intégré et un passage vers une application de navigation externe selon le choix de l’utilisateur. La destination doit rester la station sélectionnée, avec un départ et un mode de navigation cohérents.
Le guidage ajoute un autre contexte d’utilisation : une carte en mouvement, une prochaine instruction à rendre lisible et des informations de trajet à hiérarchiser. Le travail d’interface et les intégrations de navigation doivent être pensés ensemble. Une vue de comparaison de stations ne peut pas simplement être réutilisée telle quelle pendant le déplacement.
Nous distinguons aussi dans le suivi produit la sélection d’une station, l’ouverture de sa fiche et l’action de partir vers elle. Ce dernier signal rapproche la mesure de la valeur recherchée par l’utilisateur. Il décrit une intention de trajet, sans permettre à lui seul d’affirmer que la personne a effectué son plein.
Concevoir l’onboarding pour rendre la valeur de Fillzz concrète
L’onboarding de Fillzz relie les premiers écrans à l’usage du conducteur : pays, profil de conduite, véhicule, carburant et habitudes de déplacement. Ces informations servent à construire une expérience et une présentation de valeur adaptées à son contexte.
Chaque question a cependant un coût dans le parcours. Nous devons arbitrer entre la personnalisation qu’elle permet et l’effort demandé avant d’accéder au produit. Le bon critère est l’utilité de la réponse pour l’étape suivante, avec une attention particulière aux questions qui peuvent être simplifiées ou reportées.
Techniquement, les étapes et les réponses sont organisées dans un parcours à états, avec une progression conservée. Nous pouvons faire varier certaines séquences et reprendre un parcours sans demander systématiquement à l’utilisateur de recommencer. Le changement d’une étape implique ainsi de traiter la reprise et les réponses existantes, au-delà du seul écran à dessiner.
Cette conception associe nos deux regards chez Klaapp : Valentin travaille le cadrage, l’IHM et la compréhension du parcours ; je porte les mécanismes techniques et les données qui permettent de le faire évoluer.
Optimiser la conversion avec un funnel exploitable
Nous avons instrumenté les étapes d’onboarding, la consultation des offres, le démarrage du paiement et ses différentes issues. Ce suivi permet de poser des questions précises : l’utilisateur quitte-t-il le parcours pendant la personnalisation, ferme-t-il l’offre ou rencontre-t-il un échec après avoir décidé d’acheter ?
Un funnel, ou entonnoir de conversion, décrit la progression entre des événements définis. Dans notre travail sur Fillzz, nous séparons l’entrée dans le produit, l’usage de la carte et la souscription : une fin d’onboarding, une intention de navigation et un achat correspondent à des objectifs différents.
| Signal observé | Question produit à examiner | Travail à envisager |
|---|---|---|
| Sortie pendant une étape de personnalisation | L’utilité de la question est-elle comprise ? | Clarifier, simplifier ou reporter cette étape. |
| Offre consultée puis fermée | La valeur et les conditions de l’offre sont-elles lisibles ? | Revoir la présentation et le moment d’exposition. |
| Paiement commencé puis échoué | Le frein est-il technique ou lié au moyen de paiement ? | Examiner les erreurs et les possibilités de reprise. |
| Station sélectionnée sans départ vers celle-ci | L’information permet-elle de décider et l’action est-elle visible ? | Vérifier la fiche, le prix et l’accès à la navigation. |
Ce tableau est une grille de diagnostic, pas un relevé des performances de Fillzz. Une sortie du parcours ne prouve pas, à elle seule, la cause d’un abandon. Les analyses de funnels de PostHog permettent notamment d’examiner la progression et les segments ; l’interprétation doit ensuite être reliée au parcours réel.
L’application prévoit également des variantes d’expérience et une attribution qui relie l’offre présentée à son contexte. Nous conservons la variante pendant un même parcours d’onboarding pour éviter qu’un utilisateur change d’expérience en cours de route. Cela permet de préparer des comparaisons interprétables, plutôt que d’accumuler des changements dont les effets deviennent impossibles à distinguer.
L’objectif est d’améliorer la conversion tout en suivant l’activation et le retour à l’usage. Nous présentons ici les dispositifs conçus pour ce travail ; nous ne leur attribuons pas de hausse chiffrée sans comparaison mesurée.
Ce que Fillzz démontre de notre accompagnement
Fillzz réunit plusieurs compétences dans un même produit : intégration et traitement de données, recherche géographique, interfaces mobiles, navigation, instrumentation et parcours de souscription. La cohérence entre ces briques est au centre de notre travail. Une amélioration du moteur de recherche doit servir la comparaison ; une nouvelle étape d’onboarding doit justifier l’effort demandé.
Chez Klaapp, nous accompagnons la création d’applications et de logiciels sur mesure avec cette même lecture produit et technique. Pour une application géolocalisée, une marketplace ou un service mobile par abonnement, nous pouvons cadrer le parcours, qualifier les données, développer les intégrations et préparer la mesure dès la conception.
Parlons de votre application : nous partirons d’un parcours utilisateur concret pour identifier les dépendances techniques, les points de friction et le périmètre d’une première version exploitable.
Questions fréquentes
Combien de stations et de pays Fillzz couvre-t-il ?
Fillzz présente une couverture de plus de 400 000 stations dans plus de 20 pays dans son application en septembre 2026. Les informations disponibles et la fréquence de mise à jour varient selon les sources et les territoires. Notre travail consiste à les réunir dans un modèle commun pour la recherche, la comparaison et la navigation.
Qu’est-ce qui rend complexe le développement d’une application comme Fillzz ?
La difficulté vient des liens entre les données, la carte, les filtres et l’action finale. Il faut normaliser les sources, maintenir des prix datés, rechercher une zone et conserver une expérience lisible sur téléphone. Le guidage et la souscription ajoutent leurs propres parcours et intégrations.
Comment Klaapp aborde-t-il l’optimisation d’un onboarding ?
Nous examinons la valeur de chaque étape, les informations nécessaires et les sorties du parcours. Nous définissons ensuite des modifications observables : une question reportée, une explication revue ou un autre moment de présentation de l’offre. La mesure doit distinguer progression, achat et usage effectif du produit.
Peut-on travailler la conversion d’une application existante ?
Oui. Il faut d’abord vérifier le parcours et la qualité du suivi disponible, puis choisir une hypothèse à tester. Une refonte ciblée peut porter sur l’onboarding, la fiche produit ou le paiement, en conservant les parties qui fonctionnent déjà.
Cas de conception revu en septembre 2026. Thomas R., cofondateur de Klaapp, intervient sur la technique, le développement et l’IA appliquée. Découvrir le studio · Découvrir Fillzz.