DriveInsight : télémétrie et gestion d'une flotte de véhicules
Plateforme web de réservation de véhicules avec une télémétrie embarquée simulée (GPS, capteurs) et un tableau de bord d'administration.
- L'objectif
- Remplacer la gestion d'un parc de véhicules au tableur par une plateforme web, couplée à une télémétrie embarquée.
- Ma solution
- Application PHP et SQLite (réservation côté client, tableau de bord admin) prévue pour recevoir la télémétrie d'un module embarqué.
- Ce que j'en retiens
- La plateforme web fonctionne ; le module embarqué est resté au stade du firmware, testé en simulant les envois de données.
Contexte
La gestion d'un parc automobile de location repose encore, dans de nombreuses structures malgaches, sur des tableurs, des registres papier et des appels téléphoniques pour vérifier la disponibilité d'un véhicule.
DriveInsight est une plateforme web de réservation et de gestion d'un parc de véhicules, conçue pour recevoir la télémétrie d'un module embarqué par véhicule : position GPS, niveau de carburant, niveau d'huile et tension de la batterie.
La plateforme web fonctionne. Le module embarqué, lui, est resté au stade du firmware : je l'ai écrit pour un Particle Boron, mais il n'a jamais tourné sur une vraie carte. Pour tester la chaîne côté serveur, j'ai envoyé à la main des coordonnées GPS et des valeurs de capteurs aux endpoints de l'API, sans la carte.
Projet réalisé de juillet à septembre 2024 dans le cadre du DTSS Génie des Systèmes Automatisés (grade licence) à l'IST-T d'Antananarivo.
Architecture
Couche web, interface client

Le calendrier de disponibilité (Flatpickr) grise automatiquement les dates réservées. La sélection d'une plage déclenche le calcul du tarif et la réservation se finalise via une modale, sans changement de page.
La disponibilité est vérifiée à deux niveaux, côté client par Flatpickr, côté serveur avant insertion, avec la logique de chevauchement d'intervalles :
date_debut_existante < date_fin_demandée
AND date_fin_existante > date_debut_demandéeCouche web, tableau de bord admin


Le dashboard sépare les données en trois requêtes indépendantes : véhicules en location, réservations à venir, véhicules disponibles. Un même véhicule peut apparaître dans plusieurs sections sans ambiguïté, contrairement à un LEFT JOIN … LIMIT 1 qui masquait silencieusement les réservations futures.
L'administrateur peut supprimer une réservation, ajouter un véhicule au parc, et consulter la télémétrie de chaque véhicule : position GPS sur une carte interactive et état des capteurs. Sur les captures, ces données sont simulées.
Module embarqué : le firmware
Le firmware (firmware/GPSandSensorData.ino) cible un Particle Boron connecté au réseau cellulaire Telma Madagascar (APN: telmanet). Il prévoit trois flux :
- Position GPS, trames NMEA décodées par TinyGPS++, envoyées toutes les 10 secondes
- Niveaux de carburant et d'huile, lus sur l'ADC 12 bits (0 à 4095) et convertis en pourcentage
- Tension de la batterie, convertie de 0 à 15 V, envoyée toutes les 5 secondes avec les niveaux
Ce que j'ai corrigé dans le firmware
Quatre erreurs ont été corrigées dans le code, et chacune est commentée dans le fichier :
- l'APN Telma est configuré avant
Particle.connect(), et non après ; - le code de retour HTTP se lit dans
response.status, pasresponse.status_code; - les noms des paramètres envoyés (
distance1,distance2,distance3) correspondent maintenant à ceux qu'attend l'endpoint PHP ; - les lectures ADC (0 à 4095) sont converties en unités utiles avec
map().
Côté serveur, les données reçues en HTTP GET sont écrites dans des fichiers JSON, et l'interface admin les relit par polling JavaScript, sans WebSocket ni broker MQTT.
Limites et perspectives
C'est un prototype académique, avec des limites connues :
- Le module embarqué n'a pas été testé sur une vraie carte : la télémétrie affichée dans l'admin provient de données simulées
- Authentification admin basique (pas de bcrypt, pas de tokens de session)
- Pas de paiement réel, la réservation est déclarative
- Données IoT stockées en JSON plats (pas de requêtes temporelles)
- Serveur PHP mono-thread (
php -S), non adapté à un déploiement multi-utilisateurs
Évolution prévue : passer par le bus CAN via OBD-II. Tout véhicule moderne dispose d'un port OBD-II donnant accès au bus CAN interne. Via un transceiver MCP2515 (SPI) + TJA1050, le Boron pourrait lire directement les PIDs SAE J1979 :
Cela remplacerait les trois capteurs câblés manuellement par un seul connecteur standardisé, exposant régime moteur, température, codes défauts DTC, kilométrage réel, sans modification physique du véhicule.
Stack
| Couche | Technologie |
|---|---|
| Backend | PHP 8.3 · SQLite 3 (PDO) |
| Frontend | HTML5 · CSS3 · JavaScript · Flatpickr |
| Cartographie | MapTiler SDK v2 |
| Embarqué | Firmware Particle pour Boron, TinyGPS++, HttpClient (non testé sur carte) |
| Réseau IoT | Cellulaire, Telma Madagascar (telmanet) |
| Capteurs | ADC analogique, carburant, huile, batterie (12 bits) |
| Évolution prévue | Bus CAN via OBD-II, MCP2515 + TJA1050 + PIDs SAE J1979 |
Projets proches
Analyse et injection sur bus CAN automobile
Reverse engineering des trames CAN d'une maquette véhicule, cartographie des bus, décodage des signaux moteur/éclairage/confort, base DBC et DLL d'injection en C simulant un système ADAS.
2026Bus CANReverse EngineeringAutomotiveMuxTrace
Conception numérique en VHDL, de la simulation au FPGA Basys 3
En licence, une boîte à musique et le jeu de la vie décrits en VHDL et simulés sous ModelSim. En master, le passage sur FPGA Xilinx avec Vivado et une carte Basys 3, jusqu'à la conception complète d'un processeur 16 bits.
2026VHDLFPGAVivadoBasys 3
Distribution Linux embarquée avec Yocto pour une box domotique
Construction d'une distribution Linux sur mesure avec Yocto (Poky) pour la carte STM32MP135F-DK, avec une layer dédiée, une recette image systemd, un SDK et une application C qui lit un capteur I²C.
2026YoctoPokyBitBakeLinux embarqué