Tags : mise à jour du concept et de la terminologie

Nous mettons progressivement à jour le concept et la terminologie utilisés dans Tags, la solution GPS-Trace de suivi d’actifs. Cette mise à jour introduit une structure plus claire pour travailler avec les passerelles, les capteurs et les actifs physiques.

L’accès à Tags est géré via des utilisateurs GPS-Trace Console enregistrés.

Auparavant, Tags reposait sur deux entités principales : les passerelles et les actifs. En pratique, ce modèle ne reflétait pas toujours la façon dont les utilisateurs travaillent avec des objets physiques.
Par exemple, une balise BLE (Bluetooth Low Energy) fixée à un outil et l’outil lui-même ne sont pas la même chose. La balise peut être déplacée, remplacée ou réutilisée, tandis que l’outil reste un actif distinct avec son propre historique.

Pour rendre cette logique plus claire, Tags utilisera désormais trois entités clés :

  1. Passerelle
  2. Capteur
  3. Actif

Passerelle

Une passerelle est un appareil qui collecte des données et les envoie vers la plateforme.

Dans la plupart des cas, il s’agit d’un traceur GPS capable de recevoir des données provenant :

  • de tags et balises BLE ;
  • de capteurs filaires connectés à la passerelle ;
  • des paramètres propres de la passerelle.

La passerelle reste le point d’entrée technique par lequel les données sont envoyées vers Tags.

Les passerelles peuvent fonctionner différemment selon la technologie utilisée :

  • Avec la technologie Mobile , un traceur GPS agit comme une passerelle mobile. Il collecte les données des capteurs BLE à proximité et envoie ces données à la plateforme GPS-Trace вместе avec ses propres coordonnées GPS.
  • Avec la technologie Mesh , les passerelles font partie d’une infrastructure stationnaire composée de passerelles et d’ancres.

Capteur

Un capteur est une source de données qui peut être liée à un actif.

Un capteur peut être :

  • un tag ou une balise BLE ;
  • un capteur filaire connecté à une passerelle ;
  • un paramètre de passerelle, comme le niveau de carburant, la température ou l’état d’allumage ;
  • plusieurs paramètres de passerelle regroupés en une seule entité.

Dans le modèle mis à jour, de nombreuses entités qui étaient auparavant appelées actifs seront désormais appelées capteurs.

Par exemple :

  • un tag BLE fixé à un défibrillateur d’hôpital est un capteur ;
  • un paramètre de température reçu d’une passerelle peut être créé comme un capteur distinct ;
  • un groupe de paramètres de passerelle sélectionnés par l’utilisateur peut également être créé en tant que capteur.

Actif

Un actif est l’objet physique qui a de la valeur pour l’utilisateur et qui doit être suivi.

Un actif peut être :

  • un conteneur ;
  • une remorque ;
  • un outil ;
  • un équipement ;
  • une cargaison ;
  • des bagages ;
  • un autre objet physique.

Un capteur peut être lié à un actif afin de fournir des données sur sa localisation, son état ou des paramètres sélectionnés.

Un changement important est qu’un actif peut exister sans capteur lié. Cela signifie que les utilisateurs peuvent créer des actifs à l’avance et les lier à des capteurs plus tard, lorsque l’objet physique est prêt à être utilisé.

Par exemple, une entreprise peut créer des fiches pour 100 conteneurs avant que des tags BLE ne leur soient attachés. Plus tard, lorsque les conteneurs sont prêts, l’utilisateur peut lier chaque conteneur au capteur approprié.

Key Entities in Tags

Pourquoi le modèle change

L’objectif principal de cette mise à jour est de séparer les objets physiques des sources de données utilisées pour les suivre.

Auparavant, un actif signifiait souvent « un tag attaché à un objet ». Or, dans de nombreux scénarios réels, le tag et l’objet ont des rôles différents.

Par exemple, dans un hôpital :

  • les brancards sont des actifs ;
  • les tags BLE fixés aux brancards sont des capteurs ;
  • les appareils qui collectent les données des tags BLE sont des passerelles.

Si un brancard est mis hors service, le tag BLE peut être retiré et fixé à un autre brancard. Avec le modèle mis à jour, l’utilisateur n’a pas besoin de tout recréer depuis le début. Il peut dissocier le capteur d’un actif et l’associer à un autre.

Cela permet de conserver l’historique lié à l’actif physique, et pas uniquement au tag. Les utilisateurs voient un enregistrement plus précis pour chaque actif, même si le capteur lié change au fil du temps.

Cette approche est utile lorsque :

  • des capteurs sont réutilisés pour différents actifs ;
  • des actifs sont créés à l’avance et liés à des capteurs plus tard ;
  • certains actifs ne sont temporairement pas utilisés ;
  • un capteur est remplacé, mais l’historique de l’actif doit rester lié à l’objet physique ;
  • les utilisateurs doivent conserver des enregistrements séparés pour les objets physiques et les appareils techniques.

Exemples supplémentaires

Exemple 1 : Outils de location

Une entreprise de location travaille avec des perceuses, des générateurs et d’autres outils.

  • Chaque outil est un actif.
  • Un tag BLE fixé à l’outil est un capteur.
  • Un traceur installé dans un véhicule de service ou une zone de stockage peut fonctionner comme une passerelle.

L’entreprise peut créer des fiches d’actifs pour les nouveaux outils avant de leur attribuer des tags BLE. Lorsque les outils sont prêts à être utilisés, les capteurs peuvent être liés aux bons actifs.

Exemple 2 : Conteneurs et cargaisons

Une entreprise logistique suit des conteneurs et des cargaisons.

  • Un conteneur est un actif.
  • Un tag ou une balise BLE fixé(e) au conteneur est un capteur.
  • Un traceur installé dans un véhicule ou sur un site peut être une passerelle.

Si un tag BLE est retiré d’un conteneur et fixé à un autre, l’utilisateur n’a qu’à mettre à jour le lien entre le capteur et l’actif.

Exemple 3 : Paramètres de passerelle comme capteurs

Un utilisateur peut avoir besoin de rapports basés sur des données reçues directement d’une passerelle, par exemple :

  • niveau de carburant ;
  • température ;
  • heures moteur ;
  • un autre paramètre sélectionné.

Dans ce cas, l’utilisateur peut créer un capteur basé sur un ou plusieurs paramètres de passerelle. Ce capteur peut ensuite être utilisé pour l’historique et les rapports.

Mises à jour de l’interface

En raison de la terminologie et de la logique mises à jour, l’interface de Tags changera également progressivement.

De nouveaux éléments d’interface et des éléments mis à jour seront introduits pour :

  • gérer les passerelles, les capteurs et les actifs ;
  • lier et dissocier les capteurs et les actifs ;
  • consulter l’historique et les rapports des capteurs/actifs ;

Historique, rapports et suivi en temps réel

Dans le concept mis à jour, l’historique, les rapports et les fonctionnalités liées au suivi seront disponibles pour les capteurs et les actifs.

Cela inclut :

  • l’historique des déplacements ;
  • les rapports ;
  • les événements liés aux objets suivis ;
  • les changements d’état basés sur les capteurs liés.

Dans de futures mises à jour, Tags sera également enrichi d’outils de suivi supplémentaires pour les capteurs et les actifs, tels que les trajets, les notifications basées sur des paramètres et d’autres fonctionnalités qui aident les utilisateurs à suivre les déplacements, les états et les événements.

Les passerelles resteront des entités techniques principalement utilisées pour la collecte et la transmission des données. Si un utilisateur a besoin de suivre une passerelle elle-même, d’obtenir un historique, des rapports ou d’autres fonctionnalités de suivi, il peut créer un capteur basé sur les paramètres de passerelle nécessaires. Ensuite, ce capteur pourra être utilisé dans Tags de la même manière que les autres capteurs.

Cela sépare la facturation de la collecte de données de la facturation des fonctionnalités liées au suivi. Les passerelles restent peu coûteuses lorsqu’elles sont utilisées uniquement pour la collecte et la transmission des données, tandis que les fonctionnalités avancées de suivi ne sont facturées que lorsque l’utilisateur décide de créer un capteur basé sur les paramètres de passerelle.

Changements de tarification

La tarification sera également alignée sur la terminologie mise à jour.

La facturation sera basée sur deux entités :

  • les passerelles ;
  • les capteurs.

Les actifs ne seront pas facturés.

En pratique, la logique de facturation reste proche du modèle actuel. Le principal changement est que les entités seront désormais nommées de manière plus précise.

Le prix d’une passerelle reste inchangé :

  • 1 passerelle — 0,1 EUR par passerelle / par mois.

Le prix d’un capteur reste également inchangé :

  • 1 capteur — de 0,1 EUR à 0,5 EUR par capteur et par mois, selon le forfait sélectionné

Un capteur est l’entité qui était auparavant souvent appelée un actif.

Ce modèle permet aux utilisateurs de gérer séparément les objets physiques et les appareils / sources de données utilisés pour les suivre, sans modifier l’approche de tarification de base.

Limites mises à jour

Les limites pour un compte Tags seront également mises à jour.

Les limites maximales seront :

  • 500 passerelles
  • 500 capteurs

Pour que l’interface reste pratique et que l’application soit stable dans les scénarios de suivi en temps réel, les passerelles et les capteurs ont besoin de limites claires au niveau du compte.

Dans le même temps, les actifs sont désormais séparés des capteurs. Cela signifie que les utilisateurs peuvent créer des fiches d’actifs pour des objets physiques indépendamment du nombre de passerelles et de capteurs utilisés pour collecter des données.

Si un utilisateur a besoin de travailler avec un plus grand nombre de passerelles ou de capteurs, il peut utiliser plusieurs comptes Tags et basculer rapidement entre eux.

Quand les changements commencent

Les mises à jour globales commenceront le 10 juin 2026.

Dès le début du processus de mise à jour, les informations sur la nouvelle terminologie, les limites, l’interface et les fonctionnalités de Tags seront progressivement mises à jour sur les ressources GPS-Trace sur une période d’environ deux semaines.

Le modèle Tags mis à jour facilitera la description des processus réels de suivi d’actifs, la gestion des liens entre objets physiques et capteurs, ainsi que la conservation d’un historique lié aux actifs qui comptent pour les utilisateurs.