Logique de trajets personnalisée dans Navixy : configurez des règles par flotte

Configurez les paramètres standard de trajet de Navixy pour qu'ils correspondent à la façon dont une flotte spécifique fonctionne, sans construire un pipeline de données séparé. Lisez l'article complet pour découvrir comment ajuster les règles de trajet, valider le résultat, versionner la logique et la réutiliser sur différentes implémentations clients.

La plupart des logiciels de télématique proposent une entité de trajet déjà prête. La plateforme décide quand le mouvement commence, combien de temps un arrêt peut durer, quand un trajet devient deux, et quels mouvements sont trop courts pour compter. Pour une flotte routière standard, ces réglages par défaut fonctionnent généralement assez bien. Le défi apparaît lorsqu'une flotte opère différemment.

• Les engins de chantier peuvent ne se déplacer que de 50 mètres entre deux zones de travail.
• Une tournée de coursier peut comporter plusieurs arrêts de six minutes qui devraient tout de même appartenir à une seule course de livraison.
• Un autre client peut se soucier bien davantage du trajet de l'Entrepôt A au Client B que des coordonnées exactes de début et de fin du trajet.

C'est ici que la logique de trajets configurable devient utile. Avec IoT Query, la plateforme d'analyse de Navixy, les TSP et intégrateurs de systèmes peuvent reprendre la transformation de trajets existante et adapter la façon dont la télémétrie brute est agrégée en trajets. Le workflow peut être maintenu en YAML, versionné, réutilisé sur plusieurs implémentations, et ajusté sans reconstruire un pipeline de données séparé pour chaque client.

Pour illustrer le workflow de manière plus claire et transparente, nous utilisons Transformation Builder, un outil visuel de conception de workflows de transformation de données. Il permet de voir comment chaque étape se connecte à la suivante, où des règles spécifiques s'appliquent, et comment les données de trajet finales sont produites.

Comment Navixy transforme la télémétrie brute en trajets personnalisés

Un traceur GPS envoie des coordonnées, une vitesse, des horodatages, des états d'appareil et d'autres données de télémétrie. Un trajet n'apparaît qu'après que la plateforme applique un ensemble de règles à ces données. Cette distinction compte, car c'est précisément là que se joue la personnalisation.

Sous une forme simplifiée :

Télémétrie brute → Détection du mouvement → Limites du trajet → Validation du trajet → Contexte métier

IoT Query part de la télémétrie dans la couche de données brutes. La transformation standard des trajets convertit ensuite ces points en enregistrements de trajet structurés, avec limites, durée, distance et autres métriques calculées. La transformation standard a donc besoin d'un ensemble de règles par défaut.

Par exemple, elle utilise un seuil de stationnement de cinq minutes, un délai de 20 minutes pour les interruptions de données, ainsi que des critères minimaux de vitesse et de distance pour distinguer un vrai mouvement du bruit GPS. Ce sont des hypothèses raisonnables pour de nombreuses flottes, mais elles ne sont pas universelles.

Si la définition opérationnelle du trajet diffère chez le client, vous pouvez conserver la transformation existante et ne modifier que la logique qui ne convient plus. Le modèle qui en résulte reste simple :

Télémétrie brute → Logique de transformation configurable → Jeu de données analytique personnalisé

Le workflow modifié peut écrire le résultat dans processed_custom_data, tandis que la transformation standard de Navixy continue de s'exécuter séparément.

Cela rend aussi les tests plus sûrs : il n'est pas nécessaire de remplacer le jeu de données de trajets standard pour valider une autre définition.

Trois cas d'usage de la logique de trajets personnalisée dans Navixy via IoT Query

La façon la plus simple de voir où la logique de trajets personnalisée devient utile consiste à examiner les opérations où les hypothèses standard pour flottes routières ne tiennent plus.

Détecter des trajets courts de 50 mètres pour des engins lourds

Les flottes de chantier et les engins lourds sont un bon exemple, car les limites des hypothèses standard pour flottes routières deviennent vite visibles. Imaginez des engins se déplaçant sur un chantier. Une chargeuse peut se déplacer de 50 à 80 mètres entre deux zones de travail, à faible vitesse.

Un filtre de trajets standard peut raisonnablement considérer cela comme du bruit GPS. Pour cette opération, cependant, il s'agit d'un mouvement réel que le client peut vouloir analyser. Il ne suffit pas d'abaisser simplement le seuil de distance final. Les points sous-jacents doivent d'abord être classés comme du mouvement.

Par exemple, la logique Moving Status peut être ajustée d'un seuil de 3 km/h à 1 km/h, et autoriser des variations de distance plus courtes :

version: 2
name: Generate Trips (no zones)

cte_nodes:
  - id: custom_5
    type: custom
    label: Moving Status
    sources: [filter_1]
    params:
      custom_sql: |-
        SELECT *,
          CASE
            WHEN speed >= 1
              AND (distance_meters > 10 OR is_moving = 1)
              THEN 'moving'
            ELSE 'stopped'
          END AS moving_status
        FROM filter_1

Il s'agit d'un extrait du workflow plutôt que d'une configuration complète, mais cela illustre l'idée de base : le comportement du trajet est contrôlé par une configuration lisible et une logique SQL.

Les critères de validation finale doivent alors suivre la même définition :

HAVING COUNT(*) >= 2
   AND MAX(w.speed) >= 1
   AND ROUND(ST_Length(...)) >= 30

Ici, la vitesse minimale passe de 3 km/h à 1 km/h, tandis que la distance minimale de trajet passe de 100 mètres à 30. La télémétrie entrante n'a pas changé ; c'est son interprétation qui a changé.

Il existe toutefois un compromis important : une fois les seuils de mouvement abaissés, la dérive GPS a plus de chances d'être classée comme un trajet réel. Avant de programmer le workflow en production, comparez les résultats à un ensemble de mouvements d'engins déjà connus. En pratique, cette validation est plus utile que de chercher un seuil théoriquement « correct ».

Regrouper les arrêts de coursier au sein d'un même trajet

Les opérations de coursier posent un défi différent. Une tournée de livraison peut comporter des dizaines d'arrêts courts. Si une livraison prend six minutes au lieu de quatre, un seuil de stationnement de sept minutes peut scinder en deux trajets ce que l'entreprise considère comme une seule tournée. Dans ce cas, il n'y a aucune raison de repenser le workflow.

Augmenter le seuil de stationnement de 300 à 600 secondes peut suffire à garder ces arrêts dans le même trajet. Si des interruptions de connectivité fragmentent également la tournée, le seuil d'interruption de données peut être ajusté de la même façon.

Une règle utile ici consiste à partir du workflow existant et à modifier le plus petit nombre d'hypothèses possible. Cela facilite la validation et la maintenance du résultat. Cela facilite aussi, plus tard, l'explication de la configuration lorsque quelqu'un demande pourquoi les trajets de ce client se comportent différemment du modèle standard.

Ajouter du contexte métier aux trajets

Les seuils ne sont qu'un type de personnalisation parmi d'autres. Les coordonnées elles-mêmes sont rarement ce qu'un répartiteur, un analyste ou un client souhaite finalement voir.

Un enregistrement tel que 55.7558, 37.6173 → 55.7412, 37.6231 est précis, mais la question opérationnelle est plutôt : le camion est-il allé de l'entrepôt au site du client ?

Un workflow personnalisé peut comparer les coordonnées de début et de fin de trajet à des géorepérages dans processed_common_data.zones_geom, et ajouter des champs tels que :

Champ	Signification
start_zone	Géorepérage contenant le début du trajet
end_zone	Géorepérage contenant la fin du trajet

Le trajet obtenu peut désormais indiquer : Entrepôt → Site du client, sans nécessiter qu'un autre outil de BI ou une autre application reconstruise ce contexte plus tard.

À ce stade, le workflow fait plus qu'ajuster la détection de trajets : il façonne l'entité analytique en fonction de la manière dont l'opération du client fonctionne réellement.

Cette même approche peut être étendue avec des informations sur le conducteur, des états de capteurs, des zones opérationnelles ou d'autres données métier disponibles dans l'implémentation.

Pourquoi gérer les workflows de trajets personnalisés en YAML

Le graphe visuel est utile pour comprendre le workflow. Le YAML devient utile lorsqu'il faut gérer ce workflow comme un actif d'ingénierie.

Chaque workflow de transformation peut être exporté en YAML. La configuration décrit les nœuds, les paramètres, les connexions et la planification derrière la transformation. Pour les équipes qui construisent des solutions similaires de manière répétée, cela offre quatre avantages pratiques :

1. Versionner la logique. Plutôt que quelqu'un change 300 en 600 dans une interface et que personne ne se souvienne pourquoi trois mois plus tard, le YAML peut vivre dans Git. Le changement devient un diff normal, avec historique et revue.
2. Réutiliser une implémentation validée. Si vous avez déjà construit la logique de trajets pour un type de flotte de chantier, vous disposez d'un point de départ bien plus solide pour le prochain client aux opérations similaires.
3. Déplacer des workflows entre implémentations. La même configuration peut être importée dans un autre compte Navixy plutôt que reconstruite nœud par nœud.
4. Travailler avec la configuration de manière programmatique. Comme le workflow est du texte structuré, des scripts et des outils d'IA peuvent l'inspecter et le modifier directement. Cette option devient particulièrement utile pour les intégrateurs de systèmes.

Comment les outils d'IA peuvent travailler avec des configurations de trajet en YAML

Une fois que la transformation existe sous forme de texte structuré, l'utilisation de l'IA devient beaucoup plus directe. Plutôt que d'essayer d'expliquer un workflow visuel à un assistant, vous pouvez lui fournir le YAML exporté ainsi qu'un besoin opérationnel concret.

Par exemple : Voici notre workflow Trips actuel. Ce client exploite des engins de chantier qui se déplacent régulièrement de 30 à 80 mètres à 1–2 km/h. Quels nœuds et seuils empêchent actuellement ces mouvements d'être classés comme des trajets ?

Un assistant IA peut identifier les nœuds pertinents et suggérer des modifications.

Un générateur de workflow peut aller plus loin et renvoyer un fichier YAML mis à jour.

Un agent autonome pourrait potentiellement prendre en charge une plus grande partie de la boucle : lire la configuration, la modifier, exécuter le workflow, et comparer le résultat à un ensemble de trajets déjà connu.

Il existe une limite importante. Le YAML explique comment le workflow fonctionne. Il n'explique pas comment fonctionne l'opération du client. Avant de demander à un outil d'IA de modifier la logique de trajets, donnez-lui le contexte opérationnel dont il a besoin.

Sans ce contexte, un outil d'IA peut produire un YAML parfaitement valide qui encode malgré tout une logique métier erronée.

C'est pourquoi l'IA est surtout utile ici comme un moyen d'accélérer le travail de configuration, et non comme un substitut à la compréhension de l'opération de la flotte.

Pour un parcours plus technique de ces cas d'usage, incluant les nœuds et paramètres exacts concernés, les risques de validation, les considérations de planification, les modèles d'édition YAML et des recommandations pour les assistants et agents IA, consultez Analystes de données → Cas d'usage dans la documentation Navixy.

Comment réutiliser la logique de trajets personnalisée entre plusieurs clients

Pour un TSP ou un intégrateur de systèmes, la logique de trajets personnalisée devient particulièrement précieuse lorsque différents clients opèrent dans des conditions très différentes. Les données de télématique sous-jacentes peuvent être les mêmes ; la définition analytique, elle, n'a pas à l'être. Vous n'avez pas non plus besoin de reconstruire la pile analytique pour chaque implémentation.

Partez d'une transformation existante. Modifiez les hypothèses qui comptent. Validez le résultat au regard du comportement réel de la flotte. Conservez le YAML obtenu sous contrôle de version. Réutilisez-le lorsque la prochaine implémentation présente un besoin similaire.

Les trajets sont un exemple pratique, mais le même principe s'applique aux agrégations de capteurs, aux événements conducteur, aux métriques véhicule et à d'autres entités analytiques. L'opportunité plus large consiste à maîtriser la façon dont les données de télématique brutes deviennent des données que l'opération de votre client peut réellement utiliser.

Vous avez un cas d'usage client qui ne correspond pas à la logique de trajets standard ? Contactez-nous pour discuter de la manière de construire et de maintenir une transformation personnalisée dans IoT Query.