Comment créer un rapport d'éco-conduite dans IoT Query pour le suivi des comportements de flotte

Quand vous gérez des centaines de véhicules, les « scores de sécurité standards » ne racontent pas toute l'histoire. Les opérations surveillent les pertes de carburant, la conformité nécessite des audits, et les finances veulent des chiffres défendables. Découvrez comment notre client en Amérique latine a construit dans Navixy IoT Query un rapport personnalisé de comportement conducteur qui répondait à leurs besoins métier et a livré des résultats mesurables.

Points clés à retenir

• Transformez la télématique en preuves métier. Corrélez le comportement des conducteurs avec les coûts, la maintenance et les KPI d'assurance en utilisant des données auditables et prêtes pour SQL.
• Construisez une logique d'éco-conduite personnalisée. Définissez des seuils et des formules de notation qui correspondent à vos objectifs.
• Livrez l'analytique plus rapidement. Diffusez les données télématiques directement vers les outils de BI.
• Engagez les conducteurs avec un retour transparent. Utilisez une notation équitable pour réduire les coûts de carburant, d'accidents et de maintenance.

Étude de cas : comment une flotte logistique a transformé ses données télématiques en moteur d'amélioration des conducteurs

Soyons honnêtes — la plupart des rapports d'éco-conduite sont ennuyeux. Ils répertorient les infractions, attribuent quelques points arbitraires, et c'est tout. Mais quand vous gérez 1 200 camions qui consomment des milliers de litres de diesel par semaine, ce type de rapport ne fait pas la différence. Vous avez besoin d'analyses qui expliquent les comportements, pas seulement qui les sanctionnent.

C'est la révélation qu'a eue un prestataire logistique régional opérant en Amérique latine. Son équipe de direction souhaitait disposer d'un système qui lie directement les performances des conducteurs aux coûts de carburant, aux plannings de maintenance et à l'exposition aux risques d'assurance.

Le point de départ : Trop de données, pas assez de clarté

Comme la plupart des grandes flottes, ce prestataire logistique disposait de plus de données qu'il ne pourrait jamais en exploiter — signaux GPS, métriques CAN-bus, journaux de température et identifiants conducteurs. Pourtant, leurs outils d'analyse parvenaient à peine à répondre à ces questions :

• Quels conducteurs dépassent régulièrement les seuils de vitesse en zones urbaines ?
• Comment les événements de freinage brusque sont-ils corrélés à l'augmentation des coûts de maintenance ?
• Et la question cruciale — nos « scores d'éco-conduite » sont-ils réellement liés aux économies, ou ne sont-ils que des chiffres sur un tableau de bord ?

L'équipe informatique tentait de reconstituer le puzzle via des API et des exports CSV. Le résultat : des marathons Excel nocturnes, des seuils incohérents et des tableaux de bord qui se cassaient à chaque mise à jour de la plateforme télématique.

« Nous avions cinq rapports 'officiels' différents pour l'économie de carburant, et aucun ne concordait », a reconnu leur directeur des opérations. « Notre responsable BI devenait un traducteur. »

Découvrez Navixy IoT Query : une base de données pour une véritable analytique

En connectant les flux télématiques à Navixy IoT Query, l'équipe a obtenu un accès SQL direct à l'ensemble de son jeu de données (vitesse, régime moteur, cap et horodatage), le tout organisé dans une couche Bronze IoT Query structurée. Fini les API, les scripts d'interrogation et les tâches de traitement nocturnes.

Cette nouvelle base de données leur a permis de construire un modèle d'éco-conduite personnalisé qui reflétait leurs priorités d'entreprise :

• Les seuils d'excès de vitesse variaient selon la région et le type de route.
• Les coefficients de pénalité étaient basés sur l'impact des coûts, non sur des approximations.
• Les scores étaient normalisés par tranche de 100 km, permettant une comparaison équitable entre conducteurs courte et longue distance.

Enfin, ils ont cessé d'adapter leur activité au logiciel pour faire en sorte que le logiciel s'adapte à leur activité. Le premier tableau de bord en temps réel a été mis en ligne en une semaine. En un mois, ils disposaient des tendances de performance pour l'ensemble de leurs 1 200 conducteurs — pas seulement des alertes, mais du contexte : quels itinéraires, horaires ou conditions déclenchaient les comportements à risque.

L'impact commercial multidimensionnel

Le plus grand succès n'était pas seulement la réduction de la consommation de carburant (bien qu'ils aient réussi à diminuer la consommation de 11% au cours des trois premiers mois). Le véritable changement est venu de l'engagement des conducteurs. Lorsque les conducteurs ont constaté que la logique de notation était cohérente et que les pénalités reflétaient les risques et coûts réels, ils ont commencé à rivaliser pour s'améliorer.

En termes de chiffres, les coûts de maintenance ont chuté de 8%, les déclarations de sinistres ont diminué de 15%, et leur assureur l'a remarqué. L'entreprise négocie maintenant avec sa compagnie d'assurance un modèle de prime basé sur l'utilisation, construit sur ces mêmes scores d'éco-conduite.

---

Liste d'actions concrètes d'un prestataire logistique latino-américain

Voici l'algorithme exact que le client Navixy, prestataire logistique en Amérique latine, a suivi pour tirer le meilleur parti de son rapport d'éco-conduite et transformer la surveillance du comportement des conducteurs en amélioration commerciale mesurable :

1. Identifiez le KPI principal : contrôle des coûts de carburant, réduction des risques ou conformité.
2. Élaborez les seuils de violation et les coefficients de pénalité avec les équipes opérationnelles et financières.
3. Développez le SQL de détection d'événements pour les excès de vitesse, les freinages/accélérations brusques et les virages serrés.
4. Normalisez les scores (par 100 km/heure) pour comparer des éléments comparables.
5. Publiez les tableaux détaillés et de synthèse ; connectez-les à un outil de BI via PostgreSQL.
6. Planifiez des révisions ; ajustez les coefficients au fur et à mesure que les politiques et les réseaux évoluent.

Utilisez cette liste comme modèle de départ pour construire votre propre rapport de surveillance du comportement des conducteurs qui reflète vos données, vos priorités et la réalité opérationnelle de votre flotte.

---

Guide pratique : comment créer un rapport d'éco-conduite personnalisé dans Navixy IoT Query

Avec Navixy IoT Query, créer un rapport d'éco-conduite ne consiste pas à remplir un modèle prédéfini. Il s'agit de définir votre propre logique sans limitations d'API ni exports nocturnes. Voyons comment cela fonctionne en pratique.

Étape 1. Définir les données d'entrée

Les données brutes proviennent directement des dispositifs télématiques : vitesse, localisation, cap et horodatage.

Étape 2. Configurez les seuils et les pénalités

Définissez des seuils spécifiques à votre entreprise et des pondérations de pénalités pour les infractions de conduite :

• Excès de vitesse : points pour des tranches comme +0–20 km/h, +20–40 km/h, etc. (peuvent être segmentées par type de route/région)
• Freinage brusque : décélération au-delà d'un seuil défini.
• Accélération brusque : accélération rapide au-dessus d'une limite choisie.
• Virages serrés : changements de cap soudains à vitesse élevée.

Chaque événement peut se voir attribuer un score de pénalité qui reflète les priorités de l'entreprise. Par exemple, un assureur peut appliquer des pénalités plus lourdes aux excès de vitesse, tandis qu'un gestionnaire de flotte peut se concentrer davantage sur les freinages brusques qui augmentent les coûts de maintenance. Les pondérations de pénalités reflètent l'impact en termes de coût ou de risque. Les équipes finance et opérations peuvent co-gérer le tableau des pénalités afin qu'il s'aligne sur les budgets et les politiques.

Étape 3. Logique de détection d'événements (sous le capot)

Une fois les zones et leurs seuils correspondants définis, créez la logique qui sera appliquée. Transformer ces données en informations exploitables nécessite deux couches de traitement : la détection d'événements et l'agrégation.

3.1. Collecte des bons signaux

Depuis la couche Bronze de Navixy IoT Query, extrayez :

• La vitesse (pour détecter les excès de vitesse et calculer les accélérations).
• Les horodatages (pour mesurer l'évolution dans le temps).
• Le cap (pour la détection des virages serrés).
• La distance (pour la normalisation du score par 100 km).

3.2. Détection des événements de conduite

Chaque type d'infraction est identifié en comparant les valeurs en temps réel avec les seuils définis par l'entreprise. Implémentez les règles de détection avec SQL (ou des notebooks Python qui lisent depuis SQL) :

Détection des excès de vitesse
Lors du parcours de la série temporelle, dès que la vitesse > limite de base, nous ouvrons (ou continuons) un « événement » d'excès de vitesse. Quand la vitesse redescend à la limite/en dessous, nous fermons l'événement et calculons :

• La durée (les pics courts ≤ 60 secondes sont ignorés comme période de grâce),
• Le pic de dépassement durant l'événement.

La pénalité pour cet événement est un montant fixe basé uniquement sur l'ampleur du dépassement de limite par le conducteur :

• 0–20 km/h → points speed_range1
• 20–40 km/h → points speed_range2
• 40–60 km/h → points speed_range3
• 60 km/h → points speed_range4

def speeding_points(max_over, penalties):
if max_over < 20: return penalties['speed_range1']
if max_over < 40: return penalties['speed_range2']
if max_over < 60: return penalties['speed_range3']
return penalties['speed_range4']

Pourquoi le pic et non la durée ? Cela simplifie la politique et facilite l'examen : une pénalité claire par incident, au lieu de calculs « par minute ».

Détection des manœuvres brusques (à partir de l'accélération)

Estimez l'accélération en comparant les vitesses consécutives :

• Convertissez les km/h en m/s et divisez le changement par le temps entre les points.
• Si la décélération est en dessous du seuil de freinage (par ex., −3,5 m/s²) et que le véhicule était en mouvement (≥ 10 km/h), ajoutez des points harsh_brake.
• Si l'accélération est au-dessus du seuil d'accélération (par ex., +3,0 m/s²) et que la vitesse était ≥ 10 km/h, ajoutez des points harsh_accel.

def mps(kmh):
    return kmh / 3.6

def detect_harsh_maneuvers(speeds, timestamps, decel_threshold=-3.5, accel_threshold=3.0, min_speed=10):
    points = {'harsh_brake': 0, 'harsh_accel': 0}
    for i in range(1, len(speeds)):
        prev_speed, curr_speed = speeds[i-1], speeds[i]
        dt_seconds = timestamps[i] - timestamps[i-1]

        # ignorer si l'écart de temps est trop petit ou la vitesse trop faible
        if dt_seconds <= 0.1 or prev_speed < min_speed:
            continue

        acc = (mps(curr_speed) - mps(prev_speed)) / dt_seconds

        if acc < decel_threshold:
            points['harsh_brake'] += 1
        elif acc > accel_threshold:
            points['harsh_accel'] += 1

    return points

Détecter les virages serrés (à partir des changements de cap)

Si vous disposez de deux points GPS consécutifs, nous estimons le relèvement (cap). Un virage serré se produit lorsque le changement de cap entre les étapes dépasse votre seuil (par exemple, 150°) et que le véhicule se déplace à une vitesse minimale (par exemple, 30 km/h). Chaque détection ajoute des points harsh_turn.

from math import sin, cos, radians, atan2, degrees

def bearing_deg(lat1, lon1, lat2, lon2):
    phi1, phi2 = radians(lat1), radians(lat2)
    d_lon = radians(lon2 - lon1)
    y = sin(d_lon) * cos(phi2)
    x = cos(phi1) * sin(phi2) - sin(phi1) * cos(phi2) * cos(d_lon)
    return (degrees(atan2(y, x)) + 360) % 360

def delta_heading(h1, h2):
    return abs((h2 - h1 + 180) % 360 - 180)

def detect_sharp_turns(gps_points, speed_threshold=30, heading_threshold=150):
    sharp_turns = []
    for i in range(1, len(gps_points)):
        lat1, lon1, t1 = gps_points[i-1]
        lat2, lon2, t2 = gps_points[i]
        h1 = bearing_deg(lat1, lon1, lat2, lon2)
        if i < len(gps_points) - 1:
            lat3, lon3, t3 = gps_points[i+1]
            h2 = bearing_deg(lat2, lon2, lat3, lon3)
            delta_h = delta_heading(h1, h2)
            speed = calculate_speed(lat1, lon1, lat2, lon2, t1, t2)  # implement this
            if delta_h > heading_threshold and speed >= speed_threshold:
                sharp_turns.append((lat2, lon2, t2, delta_h))
    return sharp_turns

3.3. Agrégation en scores

Un seul événement de freinage brusque ne signifie pas grand-chose en soi. Mais lorsqu'il est agrégé dans le temps, la distance ou les conducteurs, il révèle des tendances :

• Par conducteur : pour comparer les performances et identifier les besoins de formation.
• Par flotte : pour évaluer l'exposition aux risques et les coûts d'exploitation.
• Pour 100 km : pour normaliser selon les différents niveaux d'utilisation des véhicules.

Formule de score :

points_par_norme = (total_points / distance_km) * distance_norme # par ex., pour 100 km 
score = max(0, score_max - points_par_norme) # plafonner à zéro

Exemple :
Si un camion a parcouru 250 km et accumulé 8 points, avec distance_norme = 100 et score_max = 100, alors points_par_norme = (8/250)*100 = 3,2 → score = 96,8. Si un camion a parcouru 250 km et accumulé 8 points, avec distance_norme = 100 et score_max = 100, alors points_par_norme = (8/250)*100 = 3,2 → score = 96,8.

Le moteur de rapport résume toutes les infractions dans un modèle de notation. Par exemple, un conducteur peut accumuler 45 points de pénalité pour 100 km, tandis qu'un autre n'en totalise que 12 en moyenne. Ces résultats alimentent directement les KPI métier : modèles de risque d'assurance, prévisions de maintenance ou objectifs de durabilité.

Étape 4. Générer le rapport

Agrégez les pénalités par conducteur/véhicule/itinéraire et normalisez les données pour permettre une comparaison équitable entre les cycles de service. Le système produit deux niveaux de résultats :

• Tableau de synthèse : total des infractions par type, points de pénalité cumulés et scores normalisés (par exemple, points pour 100 km).
• Tableau détaillé : chaque infraction avec son horodatage, son type et sa pénalité. Ce tableau peut être utilisé pour la traçabilité, puis visualisé dans votre outil de BI de choix via des connecteurs PostgreSQL.

Cette double vue permet à la fois une surveillance tactique (qui a fait quoi, et quand) et une vision stratégique (scores agrégés par véhicule ou période).

En résumé : transformer la surveillance du comportement des conducteurs en stratégie de données

L'éco-conduite est souvent traitée comme un module complémentaire, une fonctionnalité que l'on coche sur une liste. Mais comme vous l'avez appris grâce à l'étude de cas, lorsque vous contrôlez la logique des données à l'aide de Navixy IoT Query, cela devient un outil stratégique. Cela ne transformera pas tous les conducteurs en saints du jour au lendemain. Mais lorsque les données sont précises, transparentes et alignées sur les objectifs métier, l'amélioration cesse d'être un sermon pour devenir une culture. C'est ce que le partenaire de Navixy en Amérique latine a découvert, et tout a commencé par une idée claire de ce qui comptait vraiment.

Vous souhaitez explorer la différence entre les tableaux de bord prêts à l'emploi et l'analytique orientée décision ? Contactez l'équipe commerciale pour activer les capacités de Navixy IoT Query pour votre entreprise.