Architecture

    Headless Telematics : un cœur prêt, votre interface

    Headless Telematics est une approche d’architecture où les fonctions du backend de télématique sont accessibles via des API documentées et où l’interface du fournisseur est optionnelle : l’équipe construit sa propre interface sur un cœur prêt. Interface web ou mobile, scénario intégré au processus métier, intégration à un système de gestion des opérations — le choix vous appartient, et le backend reste le même.

    Consulter la documentation Aller à Composable Telematics
    API documentéesIoT Query — accès en lectureL’interface, votre contrôle
    Requête · SQL
    SELECT device_id, device_time, lat, lng
    FROM raw_telematics_data.tracking_data_core
    WHERE device_id = 104
    ORDER BY device_time DESC
    LIMIT 1;
    Réponse · ligne de résultat
    { "device_id": 104,
    "device_time": "2026-07-21T14:02:11Z",
    "lat": 43.238, "lng": 76.889 }
    200 · raw_telematics_data · accès en lecture
    Définition

    Qu’est-ce que Headless Telematics

    Headless Telematics sépare le produit en deux parties : un backend de télématique — les données et la logique — exposé via des API documentées, et une interface conçue par l’équipe qui construit le produit. Le cœur reste unique, et l’on peut bâtir n’importe quelle interface par-dessus. Navixy fonctionne selon ce principe : les fonctions du backend de télématique sont accessibles via des API documentées, et la liste précise des opérations pour chaque scénario est décrite dans la documentation.

    • Construisez un portail, une application mobile, un scénario intégré au processus métier ou une intégration à un système de gestion des opérations : le choix de l’interface ne se réduit pas à une seule option.
    • L’expérience utilisateur, l’accessibilité, la sécurité applicative, le support et les mises en production de votre interface relèvent de votre équipe.
    • Les API documentées sont le socle de l’architecture : un même contrat sert le web, le mobile et le scénario intégré — et, demain, l’agent via MCP. Navixy MCP
    Le chemin de la télématique

    Headless — l’échelon entre la marque blanche et Composable Telematics

    La télématique suit un chemin de l’interface prête à la plateforme composable en passant par l’architecture headless — et plus loin, vers une infrastructure agent-ready où les données et la logique servent non seulement les humains, mais aussi les agents d’IA. Headless est l’échelon où le backend est déjà exposé via des API, et où l’interface devient votre terrain de différenciation.

    • Marque blanche et Headless sont des échelons voisins et équivalents : choisissez l’interface prête là où elle est rentable, et l’interface propre là où elle devient votre avantage.
    • Headless vous donne déjà une interface propre sur un backend documenté — l’étape vers Composable Telematics se franchit à part, quand l’indépendance des données et de la logique devient nécessaire. Composable Telematics
    Comment cela fonctionne

    La couche applicative relie votre interface au backend de télématique

    Garanti par le backend de télématique

    Des API documentées et un schéma de données stable — par exemple la table raw_telematics_data.tracking_data_core dans IoT Query.

    Schéma de données
    À la charge de votre interface

    La couche applicative appelle les opérations et ne prend que les champs nécessaires ; le navigateur ne se connecte jamais directement au backend.

    Garanti par le backend de télématique

    L’accès en lecture à la télémétrie via la connexion compatible PostgreSQL d’IoT Query.

    Configuration de la connexion
    À la charge de votre interface

    L’identification des utilisateurs, la conservation des secrets et les limites de requête relèvent de votre solution.

    Garanti par le backend de télématique

    Des identifiants de connexion par instance — l’isolation des tenants au niveau du backend.

    À la charge de votre interface

    L’association de l’utilisateur au tenant et la rotation des clés se conviennent avec Navixy avant le lancement.

    Garanti par le backend de télématique

    La logique opérationnelle dans IoT Logic : ingestion des données, transformations, actions et routage.

    Opérations de la logique
    À la charge de votre interface

    L’interface, l’accessibilité, le traitement des erreurs et le support des utilisateurs sont votre domaine de responsabilité.

    Entre l’interface et le backend opère la couche applicative de votre équipe : elle appelle les opérations documentées, porte la logique métier et garde les identifiants du fournisseur sur le serveur, pas dans le navigateur.

    • La couche applicative vérifie les droits d’accès, tient compte du contexte du tenant et met en cache les requêtes vers le backend.
    • Les journaux, les identifiants de requête et les contrôles de version relient les couches — un incident se diagnostique en quelques minutes.

    Trois opérations qui définissent votre architecture headless

    Chacune se vérifie séparément : lecture de la télémétrie, identification du tenant et cycle de vie des mises en production.

    SQL sur les données en direct

    Configuration de la connexionSchéma de données
    01SELECT *
    02FROM raw_telematics_data.tracking_data_core
    03LIMIT 10;
    raw_business_dataraw_telematics_data
    tracking_data_core

    Un accès documenté, compatible PostgreSQL, à la table raw_telematics_data.tracking_data_core — vous lisez directement les champs nécessaires.

    La logique applicative — ingestion des données, transformations JEXL et routage — c’est IoT Logic sur la couche applicative, pas le contrat du backend. Opérations de logique

      Consulter la documentation
      Redistribution des responsabilités

      Vous obtenez votre interface — et la responsabilité qui va avec

      Ce compromis est avantageux quand l’interface distingue votre produit sur le marché et que l’équipe est prête à l’exploiter : authentification, mises en production, incidents, support client. Si les différences d’interface ne créent pas de valeur visible pour les clients, la marque blanche reste un choix rapide et économique — équivalent, non pas un repli.

      • Votre équipe conçoit l’interaction et répond de l’accessibilité, de la sécurité du frontend, des mises en production et du support client.
      • Les propriétaires du backend et de l’application fixent l’authentification, l’autorisation, les limites de requête, le versionnement et l’ordre d’escalade avant le lancement.
      • Un scénario utilisateur se parcourt intégralement — refus d’accès, données obsolètes, défaillance partielle, évolution de l’API côté fournisseur : c’est ainsi qu’on vérifie la limite de responsabilité, pas une seule requête réussie.
      • La marque blanche reste un choix rapide et économique si l’interface propre ne crée pas de valeur visible pour le client. White-label
      Limites du backend
      Votre équipe répond de
      • L’authentification des utilisateurs du portail et les sessions
      • L’affichage des données, l’accessibilité, le traitement des erreurs
      La plateforme fournit
      • Les API documentées du backend de télématique
      • Les identifiants de connexion par instance
      Vérification sur un seul scénario

      Parcourez un scénario — de la connexion au support

      C’est ainsi que la limite de responsabilité devient tangible, avant même la première ligne d’interface.

      1. 01Identification de l’utilisateur
      2. 02Connexion selon la documentation
      3. 03Requête sur la table de données
      4. 04Affichage et support
      5. 05Supervision et évolutions
      Consulter la documentation
      Questions d’architecture

      Questions sur Headless Telematics

      Qu’est-ce que Headless Telematics ?
      C’est une approche d’architecture où le backend est exposé via des API documentées et où l’interface du fournisseur est optionnelle. Les fonctions du backend de télématique sont accessibles via des API documentées, et l’équipe construit sa propre interface sur un cœur prêt. Un boîtier, une caméra, une TCU ou un véhicule sans écran relèvent d’un tout autre sujet, matériel ; ce terme ne les concerne pas.
      Cela signifie-t-il que chaque fonction du backend est accessible via l’API ?
      Pas automatiquement. La liste des opérations et des droits disponibles varie selon la surface produit — vérifiez-la dans la documentation à jour pour chaque scénario avant de concevoir l’interface.
      Qui répond de la sécurité dans le modèle Headless Telematics ?
      La responsabilité se partage à la limite du backend. Navixy répond de la protection du backend de télématique dans les limites convenues ; votre équipe répond de sa propre interface, des sessions, des intégrations et des processus opérationnels qui l’entourent.
      Quand vaut-il mieux choisir la marque blanche plutôt que Headless ?
      Quand une interface propre ne crée pas de valeur visible pour les clients. Une interface prête à votre marque se lance sans développement frontend. Marque blanche et Headless sont des échelons équivalents : choisissez selon l’endroit où la différence d’interface compte vraiment sur le marché. White-label
      Le navigateur doit-il s’adresser directement à l’API de télématique ?
      Il est généralement plus sûr de passer par une couche applicative gérée par votre équipe. La couche applicative centralise l’autorisation, le contexte du tenant, les secrets, les limites de requête et le traitement des évolutions côté fournisseur — une seule fois, plutôt que dans chaque application cliente séparément.
      Comment vérifier une architecture headless avant le lancement ?
      Parcourez intégralement un vrai scénario utilisateur. Pour le scénario de lecture des dernières coordonnées, vérifiez non seulement la requête réussie, mais aussi le refus d’accès, les données obsolètes ou absentes, les délais d’attente, la défaillance partielle, l’évolution du schéma et le chemin d’escalade vers le support. Configuration de la connexionSchéma de données
      Peut-on garder une interface prête en solution de repli à côté d’une solution headless ?
      Oui, si le produit et les conditions commerciales le permettent. Headless Telematics rend l’interface du fournisseur optionnelle, pas obligatoire — les scénarios prêts et propres compatibles avec votre mode de déploiement se définissent avec Navixy séparément. White-label
      À partir de quand Headless Telematics devient-il rentable ?
      Quand un processus métier important pour le client justifie le développement d’une interface propre. Le délai dépend de la maturité des interfaces, de la conception de l’identification et des tenants, du développement de l’application, des tests d’intégration, de la revue de sécurité, de l’observabilité et de l’ampleur de la migration — il n’existe pas de délai unique valable pour tous les scénarios.
      Un agent d’IA ou un outil de développeur peut-il travailler avec un backend headless ?
      Oui, via le même accès documenté qu’une intégration classique. Navixy publie un MCP pour les comptes utilisateur et Admin Panel, ainsi qu’un MCP public sur la documentation. L’agent passe la même authentification et opère dans les mêmes limites d’accès que n’importe quelle application. Navixy MCP

      Construisez votre interface sur le backend documenté de Navixy

      Commencez par un seul scénario utilisateur : déterminez les opérations du backend nécessaires, les zones de responsabilité et le cycle de vie — avant que l’équipe n’écrive la première ligne d’interface.

      Consulter la documentation Aller à Composable Telematics

      Headless Telematics ouvre le backend via des API — vérifiez la liste des opérations pour votre scénario dans la documentation.