Développement sur mesure

SaaS de suivi de la consommation carburant d'une flotte

Développement d'une application PWA pour RBS Transports : les chauffeurs saisissent leur relevé quotidien, la direction pilote la consommation de carburant croisée au kilométrage sur un tableau de bord.

Client
RBS Transports
Période
févr. 2025 — mars 2025
Mon rôle
Développeur fullstack — cadrage métier, conception, développement, mise en production
Visuel à venir

Le problème

Chaque jour, les chauffeurs envoyaient sur WhatsApp leur kilométrage parcouru et leur consommation de carburant, en litres et en euros. Le dirigeant reprenait ensuite chaque message pour ressaisir les données à la main dans un fichier Excel. Une friction quotidienne, chronophage, et propice autant aux oublis qu'aux erreurs de recopie — avec au bout une visibilité approximative sur le poste de dépense le plus lourd de l'activité.

Mon apport

J'ai développé une PWA à deux rôles. Le chauffeur saisit son relevé quotidien — kilométrage, consommation en litres et en euros, véhicule utilisé — et consulte son propre historique. Le responsable dispose d'un tableau de bord qui croise consommation et kilométrage sur sept jours, gère la flotte et les équipes, et peut corriger un relevé erroné. La suppression d'un relevé lui est volontairement réservée.

SuppriméeRessaisie WhatsApp vers Excel
7 jours glissantsSuivi consommation / kilométrage

Le contexte

RBS Transports exploite une flotte de véhicules pour son activité de transport. Le carburant y représente un poste de dépense majeur, et pourtant le moins bien suivi.

Une dizaine de chauffeurs étaient concernés par le suivi quotidien, chacun rattaché à un véhicule de la flotte. Le besoin exprimé au premier échange était direct et précis : le dirigeant savait exactement ce qui lui coûtait du temps et ce qu'il voulait voir disparaître.

Le problème à résoudre

Le processus en place tenait entièrement sur WhatsApp et Excel.

Chaque chauffeur envoyait, en fin de journée, un message avec son kilométrage parcouru et sa consommation de carburant — litres et montant en euros. Le dirigeant ouvrait la conversation, lisait les messages un par un, et ressaisissait manuellement chaque ligne dans un fichier Excel.

Trois conséquences :

  • Du temps perdu tous les jours, sur une tâche à zéro valeur ajoutée.
  • Des erreurs et des oublis : un message noyé dans une conversation, une virgule mal placée, un chauffeur qui oublie de déclarer.
  • Un pilotage à l'aveugle sur le premier poste de coût variable de l'entreprise, alors même que la donnée existait — elle était juste inexploitable en l'état.

Sur une dizaine de chauffeurs qui déclarent chaque jour, la recopie représentait au moins une demi-journée cumulée par semaine — du temps de dirigeant entièrement absorbé par une tâche de saisie, alors que la donnée existait déjà, écrite noir sur blanc dans une conversation WhatsApp.

Ce que j'ai mis en place

Une application web installable en PWA, pour que les chauffeurs l'utilisent depuis leur téléphone comme une application native, sans passer par un store et sans friction d'installation.

Le rôle chauffeur

Volontairement minimal, parce qu'il est utilisé tous les jours en fin de tournée, souvent debout, souvent pressé :

  • saisie du relevé quotidien : kilométrage parcouru, consommation en litres, montant en euros ;
  • sélection du véhicule utilisé ce jour-là, ce qui permet de rattacher la consommation au bon camion ;
  • consultation de son propre historique.

Le chauffeur ne peut pas supprimer un relevé. C'est un choix de conception assumé : la donnée saisie est une donnée comptable, elle se corrige mais ne disparaît pas.

Le rôle responsable

Le tableau de bord affiche les indicateurs qui comptent réellement pour piloter une flotte :

  • la consommation aux 100 km ;
  • le coût au kilomètre et le coût aux 100 km ;
  • une vue sur sept jours, avec un graphique croisant les kilomètres parcourus et les euros dépensés.

C'est ce croisement qui fait le travail. La consommation brute ne dit rien — un camion qui consomme beaucoup parce qu'il roule beaucoup est normal. Rapportée au kilométrage, l'anomalie devient visible.

S'y ajoutent :

  • la gestion de la flotte : ajout, modification et suppression des camions et véhicules légers ;
  • la gestion des équipes ;
  • la correction des relevés saisis par les chauffeurs en cas d'erreur.

Les choix techniques

Supabase pour la base de données et l'authentification, Nuxt pour l'application, distribuée en PWA.

Ce choix répond à la nature du besoin : un budget de PME, un périmètre fonctionnel clair dès le départ, et deux rôles à distinguer strictement — chauffeur et responsable. Supabase apporte l'authentification et la gestion des permissions directement au niveau de la base, ce qui évite de coder à la main toute une couche d'autorisations pour un projet de cette taille. Le résultat va plus vite en développement, sans sacrifier la rigueur : un chauffeur qui n'a pas le droit de supprimer un relevé ne l'a pas, parce que la règle est posée sur la donnée elle-même, pas seulement dans l'interface.

La PWA reste le bon calibre pour un usage terrain : un chauffeur qui termine sa tournée n'a ni le temps ni l'envie de passer par un store pour installer une application, il veut ouvrir un lien et saisir son relevé en quelques secondes.

Les résultats

La mission a été livrée en un mois, signe d'un besoin bien cadré dès le départ. Le retour du dirigeant a été positif : la ressaisie manuelle a disparu, remplacée par une saisie directe des chauffeurs qui alimente immédiatement le tableau de bord. Depuis la livraison, la mission n'a fait l'objet d'aucune nouvelle demande d'évolution — l'outil couvre le besoin tel qu'il a été exprimé, et le suivi se limite désormais à une vérification annuelle et à la mise à jour du serveur.

Ce que j'en retiens

La donnée n'a jamais manqué dans cette entreprise : elle circulait déjà, tous les jours, sur WhatsApp. Le problème n'était donc pas d'en produire davantage, mais de lui faire prendre le bon chemin — de la main du chauffeur directement au tableau de bord, sans passer par un dirigeant qui recopie.

C'est une catégorie de mission que je retrouve souvent chez les PME : le retard n'est pas un manque de données, c'est un manque de circuit. Une fois le bon circuit posé, l'outil peut rester volontairement stable, sans qu'il soit nécessaire d'y revenir sans cesse — ce qui est aussi une manière de mesurer qu'il a été bien pensé du premier coup.

Dans la même catégorie

© 2026 Yassin Abdulla. Tous droits réservés.