Journal des modifications

Jalons produits de l’écosystème V.A.D. IIoT, version après version — nouveaux modules de la plateforme, intégrations, langues et travail sur la fiabilité.

v3.2.0 En développement

Supervision, rôles et nouveaux modes de raccordement

Trois chantiers en parallèle : un service de supervision avec un registre partagé de détecteurs et une table d’événements unique, un modèle d’autorisation bâti sur des objets-politiques, et de nouveaux moyens d’intégrer un appareil ou une région — mode proxy et pack de conformité régional.

  1. Nouveau

    Registre partagé de détecteurs et table unique d’événements

    Les événements problématiques proviennent de plusieurs sources : démon de collecte, module d’ingestion, contrôles planifiés, analyse IA. Le service les ramène à deux entités — un référentiel de détecteurs qui dit ce qui compte comme problème et de quel service et groupe d’astreinte il relève, et une table d’événements dans laquelle écrit chaque source. Tableaux de bord, filtres et rapports la lisent directement : le décompte des problèmes est le même partout.

    En savoir plus
  2. Fiabilité

    Marqueurs de sessions problématiques posés à l’ingestion

    Une session est évaluée au moment de son écriture en base. Les règles sont des seuils : contact plus de 15 minutes en avance sur le planning, chute de tension de la batterie de télémétrie supérieure à 0,1 V par rapport à la session précédente, de la batterie de métrologie supérieure à 0,05 V, durée de connexion anormale. La session reçoit un marqueur et le récapitulatif quotidien se construit à partir des marqueurs plutôt qu’en reparcourant l’archive — le coût du contrôle ne croît pas avec le parc.

  3. Sécurité

    Règles d’accès portées par des objets-politiques

    Le modèle d’accès repose sur des objets-politiques : une classe par ressource, des méthodes ordinaires plutôt qu’un DSL. Un rôle se décrit par un ensemble de capacités nommées avec des indicateurs d’activité et d’activation par défaut ; la composition des droits se configure donc par déploiement sans livrer de build. Une politique reste un objet ordinaire, couvert par des tests unitaires plutôt que par un parcours de bout en bout dans le web.

    En savoir plus
  4. Intégration

    Contrôleurs et vues de l’API déplacés dans l’espace de noms v3

    Le contrat public reçoit son propre espace de noms : contrôleurs et représentations passent en v3, tandis que v1 reste gelé comme point d’entrée compatible. Les ruptures n’ont lieu que dans le nouvel espace, si bien que l’API peut évoluer sans négocier avec chaque intégrateur. Les réponses sont localisées — référentiels et descriptions textuelles reviennent dans la langue de l’utilisateur appelant.

    En savoir plus
  5. Intégration

    Un troisième mode de travail avec l’appareil : le proxy

    Un appareil fonctionne avec deux serveurs : un principal, un de secours. Un troisième mode ajoute le proxy — le démon de collecte accepte la connexion et transmet les données, tout en restant transparent pour l’appareil. Cela couvre les sites sans route directe vers la plateforme. Le mode apparaît côté serveur de collecte et dans l’interface : lors de l’analyse d’une liaison, on voit par quel chemin les données sont arrivées.

    En savoir plus
  6. Performance

    Dernière session et modèle de compteur en cache dans la télémétrie

    La dernière session de communication et une référence au modèle de compteur sont mises en cache à côté de la fiche de télémétrie — tension de batterie, code d’état de session, unités de mesure. Les listes et filtres à l’échelle du parc sont servis par une seule requête au lieu d’aller chercher dans l’archive à chaque écran : le temps de réponse reste indépendant de la profondeur de l’historique. Le cache est rafraîchi à l’ingestion, son retard est donc borné par la session de communication et non par une fenêtre de recalcul planifié.

  7. Nouveau

    MENA Compliance Pack

    Les exigences des pays de la région divergent mais se recoupent dans un socle : règles IoT, cybersécurité, protection des données personnelles, contraintes d’hébergement cloud, exploitation industrielle. Le pack fige ce socle commun et renvoie les écarts dans des annexes par pays, la configuration de déploiement pointant vers l’annexe voulue. Le document répond à la question de l’applicabilité avant le lancement d’un pilote — il s’adresse aux clients, partenaires locaux, intégrateurs et organismes publics.

v3.1.0 Stable (actuelle)

Des données d’appareil fiables et lisibles

Les données de l’appareil sont analysées selon la spécification du protocole : les masques de bits sont décodés bit à bit, les codes s’affichent en hexadécimal et les descriptions d’archive partent de l’état de l’équipement. L’archive accumulée a été recalculée avec la même logique.

  1. Fiabilité

    Décodage bit à bit des masques d’état dans les journaux

    Les champs d’état d’événement et d’alarme du protocole Type-M sont des masques de 16 bits : le bit 1 signale une batterie faible, le bit 2 un signal GSM faible, le bit 15 (32768) un redémarrage de l’appareil. Le décodage parcourt les bits et les confronte aux seuils du firmware : l’événement batterie faible s’arme sous 11,7 V et se lève au-dessus de 12,0 V, avec 300 mV d’hystérésis. Les descriptions du journal sont construites à partir des bits décodés, et l’archive accumulée a été recalculée avec la même logique — 7 872 enregistrements mis à jour, 112 924 ajoutés.

  2. Amélioré

    Libellés d’onglets et descriptions d’événements réécrits dans les archives

    Les textes des onglets d’archive partent de l’état de l’équipement plutôt que des champs du paquet : une description dit ce qui est arrivé à l’appareil. Les libellés d’onglets ne répètent pas le nom de la section, et la colonne d’état s’appelle « Indicateurs », au plus près de son contenu. Les valeurs s’affichent en police à chasse fixe : la largeur de colonne ne dépend pas de la longueur d’une valeur.

    En savoir plus
  3. Amélioré

    Codes d’alarme et d’événement affichés en hexadécimal

    Les codes d’alarme et d’événement s’affichent en hexadécimal : 0x8000, 0x0001, 0x0000 — complétés par des zéros de tête sur quatre chiffres. Une police à chasse fixe aligne les chiffres verticalement d’une ligne à l’autre : le bit armé saute aux yeux et se compare à la spécification du protocole sans conversion depuis le décimal.

  4. Amélioré

    État des tableaux : taille de page, unités et codes de reprise

    Les tableaux de données conservent leur état d’une page à l’autre : la taille de page choisie est mémorisée. L’unité est passée de l’en-tête de colonne à la valeur elle-même — l’en-tête reste court et l’unité se trouve là où est le nombre. Le compteur de reprises affiche le nombre de tentatives et le code du motif : la qualité du lien se lit directement dans le tableau.

  5. Performance

    Profilage de la file d’ingestion dans le serveur de tâches

    Le pipeline d’ingestion en arrière-plan a été profilé étape par étape et rééquilibré entre les workers. Les relevés arrivent dans l’archive juste après la session de communication, et la file tient le rythme à mesure que le parc grandit — les tâches sont traitées plus vite qu’elles n’arrivent, et la marge de débit se voit dans le journal d’ingestion.

    En savoir plus
v3.0.0 Stable

Exploitation industrielle

La première version de production de la troisième génération : un opérateur y exploite intégralement son parc de comptage en service — collecte, stockage, interface web, API et analytique. Le Centre des opérations tourne par-dessus, et les paramètres de session ont migré vers l’entrepôt d’archives partagé.

  1. Nouveau

    Version 3.0 : le premier environnement industriel de production

    La troisième génération quitte la préversion : un opérateur industriel y exploite son parc de comptage en service. Démon de collecte, stockage, interface web, API publique et analytique fonctionnent dans un même environnement. La période de transition où les deux générations coexistaient est close.

    En savoir plus
  2. Nouveau

    Centre des opérations (OHM)

    Un flux d’alarmes brutes devient un ensemble de problèmes opérationnels maîtrisés. Détecteurs et canons regroupent les événements répétés en un seul problème, la corrélation y rattache les preuves, l’évaluation de la santé des actifs classe le parc par risque, priorités et SLA fixent le délai de réaction, et la file de travail retient la tâche jusqu’à la clôture. Les incidents massifs — une panne qui déclenche des centaines d’alarmes — sont traités à part. Une couche AI propose l’étape suivante à partir de l’historique accumulé de cas semblables.

    En savoir plus
  3. Amélioré

    Stockage et affichage du signal GSM sur une échelle dBm unique

    Le niveau de signal GSM est conservé sur une échelle dBm unique, quelle que soit l’unité transmise par le protocole de l’appareil — pourcentage, unités relatives ou dBm directement. La conversion est placée dans les pilotes d’ingestion et s’exécute à l’entrée, non à l’affichage, si bien que la valeur est identique dans l’interface, dans l’API et dans les rapports. Les données accumulées sont ramenées à la même échelle et la tendance de couverture se lit sur tout l’historique du parc.

  4. Fiabilité

    Conversion des sessions de communication historiques vers le schéma v3

    Des commandes de migration transposent l’historique des sessions de communication dans le schéma de troisième génération. Le transfert se fait par étapes : d’abord les canaux de session propres à l’appareil, puis les canaux communs du bloc de télémétrie, puis l’alignement sur le schéma des paramètres. Les commandes se lancent serveur par serveur et travaillent par lots, si bien que la collecte se poursuit et que graphiques et rapports couvrent toute l’histoire de l’appareil.

  5. Performance

    Paramètres des sessions de communication déplacés dans la table d’archive commune

    Les en-têtes de session restent dans leur propre table, tandis que les paramètres de session s’écrivent dans la table d’archive commune — là où vont aussi les relevés. C’est le protocole qui déclare la composition des paramètres : Type-M a un jeu de canaux, Type-J un autre, MQTT un troisième. Un nouveau type d’appareil se crée par des entrées dans le référentiel de canaux, sans migration du schéma de base de données.

    En savoir plus
v3.0.0-rc.1 RC

Capteurs de pression et de température : le parcours complet

Une nouvelle classe d’appareils menée du protocole jusqu’à sa fiche dans l’interface : pilote, modèle de données, ingestion des archives, référentiels de types de capteurs, unités de mesure. À côté, les liens du modèle de données dont dépendent rapports, filtres et règles d’accès.

  1. Nouveau

    Capteurs de pression et de température : pilote, modèle, archives, fiche

    Une nouvelle classe d’appareils est prise en charge sur tout le trajet. Dans le démon de collecte, un pilote de protocole : paquet d’identification du bloc autonome, valeurs courantes, archives, configuration. Dans l’application, le modèle de données et l’enregistrement : pression et température courantes, coupes d’archive, paramètres de session de communication, instantané de configuration. Sur le web, l’appareil dispose d’une fiche propre dont la composition des champs est taillée pour un capteur.

    En savoir plus
  2. Amélioré

    Référentiel des types de capteur et coefficients d’étalonnage

    Le type de capteur provient d’un référentiel de plages — pression absolue 0…160 kPa, 0…400 kPa, 0…600 kPa, 0…1,0 MPa, 0…1,6 MPa, 0…2,5 MPa et au-delà selon la spécification —, relié au modèle d’équipement en troisième forme normale. Le pilote d’enregistrement détermine le type lors de l’identification de l’appareil : la plage et les unités sont donc connues du système, et pas seulement de l’installateur. L’onglet des paramètres affiche les coefficients d’étalonnage du capteur installé.

    En savoir plus
  3. Amélioré

    Les unités de mesure choisies dans toutes les vues d’une valeur

    L’unité de mesure choisie s’applique au niveau de la présentation et vaut dans toutes les vues de la valeur — tuile de pression courante, graphique, journal de données, journal d’alarmes. La conversion de la pression absolue en pression relative relève de la même couche : un indicateur l’active, et elle ne concerne que les capteurs à mesure absolue. La précision se déduit du capteur — température avec une décimale, millimètres de mercure sans partie décimale.

  4. Fiabilité

    Contrôle d’exhaustivité de l’archive de configuration avant écriture en base

    La liaison avec un appareil peut se rompre au milieu d’un transfert, aussi l’archive de configuration est-elle contrôlée en exhaustivité et en intégrité avant l’écriture en base. Un instantané collecté en partie ne prend pas la place de l’état en vigueur. L’archive d’événements est enregistrée à côté des relevés. Une session de communication interrompue laisse ainsi elle aussi une trace exploitable.

  5. Amélioré

    Filtre par date et export dans le journal des données transmises

    Le journal des données transmises reçoit la même barre d’outils que les autres onglets d’archive. On y trouve un filtre par période et un export sous forme de fichier. Une sélection sur l’intervalle voulu se remet aux équipes voisines directement depuis l’interface, sans requête en base.

    En savoir plus
  6. Amélioré

    Les tuiles du tableau de bord comme points d’entrée

    Les tuiles et les éléments de widget du tableau de bord font office de points d’entrée. Un nœud favori, un statut ou un compteur ouvre l’unité de comptage ou l’appareil correspondant. Le tableau de bord sert d’entrée dans le poste de travail, et pas seulement de synthèse.

    En savoir plus
  7. Fiabilité

    Position de vanne synchronisée avec les capteurs de fin de course

    Les positions « fermée » et « ouverte » sont établies sans ambiguïté par les capteurs de fin de course de l’actionneur. L’interface affiche exactement la position qu’ils confirment et garde la commande active. L’état est réconcilié après la première mise sous tension, après une manœuvre manuelle et après une intervention de maintenance : l’opérateur voit la position réelle sur le terrain.

v3.0.0-beta.1 Beta

Recette externe et cœur de données reconstruit

La plateforme a subi une recette externe : les scénarios ont été déroulés par des spécialistes extérieurs et leurs constats traités avant la version candidate. En parallèle, le cœur de données a été découplé — un consommateur peut être desservi par plusieurs fournisseurs, et le module de télémétrie se décrit indépendamment de l’IMEI.

  1. Nouveau

    Refonte du cœur de données : consommateur et canal de télémétrie

    Le cœur de données est reconstruit pour les besoins de la troisième génération : un consommateur peut être desservi par plusieurs fournisseurs, et un module de télémétrie se décrit indépendamment de l’IMEI. Les deux découplages sont réalisés au niveau du schéma, avant que le reste des fonctionnalités ne s’y appuie. La troisième génération dispose ainsi de son propre modèle de données, conçu pour le changement de fournisseur et pour plusieurs ressources énergétiques chez un même consommateur.

    En savoir plus
  2. Intégration

    Module de télémétrie : type de canal et identifiant

    Un module de télémétrie se décrit par deux champs : le type de canal — GSM, Ethernet, MQTT, concentrateur de données, LoRaWAN — et un identifiant du type correspondant : IMEI, IP, MAC, client_id, DevEUI. Les contrôleurs, les rapports, les exports, les services et l’API suivent le modèle étendu. Un nouveau transport s’ajoute donc comme valeur de référentiel, en un seul point du schéma.

    En savoir plus
  3. Fiabilité

    Une vague de recette externe

    La plateforme a suivi une recette externe sur un environnement de démonstration : les scénarios ont été déroulés par des spécialistes extérieurs, et non par l’équipe de développement. Les remarques sur l’assistant de création d’objet, les formulaires, les filtres à facettes, les plannings et la localisation des notifications ont été traitées et closes avant la version candidate. La recette externe est inscrite dans le cycle comme une étape obligatoire avant toute livraison.

  4. Amélioré

    Modification des intervalles de fonctionnement de l’unité de commande

    Les intervalles de fonctionnement de l’unité de commande de l’actionneur se modifient depuis l’interface. Le temps de préouverture se règle de 1 à 30 s, la pause de stabilisation de pression de 30 à 600 s, et le temps de course complète suit la spécification de l’actionneur. Les valeurs sont saisies en secondes avec une décimale et vérifiées par rapport à ces plages : l’unité et la précision du formulaire correspondent ainsi à la fiche technique de l’équipement.

    En savoir plus
  5. Amélioré

    Détachement d’un appareil d’une unité de comptage sans perte d’historique

    Un appareil se détache de l’unité de comptage et reste dans le système avec ses propres données. Remplacement, déplacement et retour de réparation sont consignés comme des événements de gestion. L’historique de l’unité de comptage et celui de l’appareil restent ainsi continus et distincts.

    En savoir plus
  6. Sécurité

    Analyse statique de sécurité du code source

    Le code source passe par une analyse statique portant sur les vulnérabilités classiques des applications web. Chaque remontée est examinée à la main : l’outil ne voit pas le contexte, une partie est donc écartée comme faux positif et le reste est clos avant la publication. Le passage est intégré à la procédure de publication et se répète à chaque build.

    En savoir plus
  7. Langues

    Plateforme et appareils en 13 langues

    La documentation de la plateforme v3, la gamme d’appareils IIoT et l’ensemble de l’interface du portail paraissent en 13 langues. L’arabe et le persan sont intégrés en écriture de droite à gauche : c’est toute la mise en page qui est mise en miroir, et pas seulement le sens du texte. Une page encore dans la file de traduction est rendue en anglais sur son URL localisée et marquée noindex, si bien que le changement de langue mène toujours vers une page existante.

    En savoir plus
  8. Intégration

    Auto-enregistrement de troisième génération pour toute la gamme prise en charge

    L’auto-enregistrement de troisième génération couvre toute la gamme prise en charge, y compris les organes de coupure pilotés en MQTT. Un appareil mis sous tension sur site crée lui-même son unité de comptage et devient aussitôt disponible en lecture et en commande. L’identifiant voyage dans la trame de l’appareil, si bien que la pose se passe de toute saisie manuelle côté plateforme.

    En savoir plus
v3.0.0-alpha.3 Alpha

La pile V3 en environnement industriel

Le démon de collecte et le stockage de troisième génération ont été déployés chez le premier client industriel et ont commencé à recevoir des relevés réels. L’API publique a été vérifiée sur le nouveau modèle de données, et le portail de documentation a ouvert.

  1. Nouveau

    AI Analytics : 22 rapports, méthodologie et formules publiées

    Le module d’analytique AI : 22 rapports portant sur les nœuds individuels et sur l’ensemble du parc — bilans, anomalies de pression, prévision de la durée de vie des batteries, détection des contournements de comptage, atlas des défauts. La méthodologie et les formules de chaque rapport sont publiées : on voit sur quels champs et quelles hypothèses repose une conclusion, et la valeur peut être recalculée à la main. Le rapport se prête ainsi à une revue avec le client et à son versement dans la documentation réglementaire.

    En savoir plus
  2. Nouveau

    Guide utilisateur illustré de captures réelles dans les deux thèmes

    Un guide pas à pas du travail avec la plateforme, bâti sur de véritables captures de l’interface en thème clair et en thème sombre. Les deux séries sont prises depuis un seul et même état des données, pour que les étapes coïncident d’un thème à l’autre. Les données des captures sont anonymisées, ce qui permet de remettre le guide à l’extérieur sans validation séparée.

    En savoir plus
  3. Nouveau

    Plateforme IIoT v3 : architecture, mise à l’échelle et conformité UE

    Une version majeure de la documentation : l’architecture, la montée en charge et la conformité aux directives de l’UE y sont décrites pour la troisième génération. La version 3 est la version courante, et les redirections racines y mènent. La deuxième génération reste accessible par liens directs et via le sélecteur de versions.

    En savoir plus
  4. Performance

    Registre des unités de comptage : tableau, filtres cascadés, sélections enregistrées

    Le registre des unités de comptage est dimensionné pour un parc de plusieurs milliers d’enregistrements : tableau paginé avec barre d’actions, filtres à facettes en cascade et filtres utilisateur enregistrés. Choisir une valeur dans une facette recalcule les valeurs admissibles dans les autres, de sorte qu’aucune combinaison n’aboutit à une sélection vide. La page d’une unité est elle-même composée de deux panneaux à onglets et à fiches.

    En savoir plus
  5. Amélioré

    Portail unifié de documentation : plateforme, API et appareils IIoT

    La documentation de la plateforme, de l’API et des appareils IIoT est réunie dans un seul portail : build statique, glossaire commun et assistant AI sur le contenu. La recherche plein texte s’exécute côté client, sans service externe ni clés. Chaque page est également servie sous forme de markdown source — pour ceux qui la lisent avec un outil plutôt qu’avec les yeux.

  6. Nouveau

    API REST publique pour unités de comptage, archives et sessions

    La plateforme expose une API REST publique sur les unités de comptage et leurs caractéristiques, les archives de relevés, les événements et messages des appareils, les sessions de communication et les référentiels. La documentation est organisée point de terminaison par point de terminaison : méthode, paramètres, format de réponse, codes d’erreur. Un intégrateur construit tout le raccordement depuis la page elle-même, sans accompagnement de notre part.

    En savoir plus
  7. Intégration

    Vérification de l’API publique sur le modèle de données V3

    Chaque point de terminaison de l’API publique est vérifié un à un sur le modèle de données de troisième génération. L’emplacement et le contrat restent là où l’intégrateur les attend, si bien que les intégrations existantes tournent sans retouche. La réponse de l’archive de configuration porte les paramètres métrologiques consolidés — débit minimal et maximal, date de vérification, numéro de série — qu’il faudrait autrement assembler en plusieurs requêtes.

    En savoir plus
  8. Nouveau

    Pilote du protocole des capteurs pression-température dans le démon de collecte

    Le démon de collecte reçoit un pilote pour un nouveau protocole : le paquet d’identification d’un bloc autonome, les valeurs courantes de pression et de température, les archives et un instantané de configuration. Il se place à côté du traitement des organes de coupure, dans la même famille de protocoles, et réemploie son analyse de la partie session. Un mois plus tard, le module complet repose sur cette base — du modèle de données jusqu’à la fiche de l’appareil.

    En savoir plus
  9. Amélioré

    Rapports AI à chaque niveau de la hiérarchie des sociétés

    L’intégration des rapports est câblée à tous les niveaux de l’arbre des sociétés : la maison mère, une agence et une subdivision ouvrent chacune leur propre jeu de rapports analytiques. Chaque nœud rend compte de son propre périmètre, quelle que soit sa profondeur dans l’arbre. Le bloc intégré ne porte pas de titre propre : le nom de la section figure déjà dans la navigation.

    En savoir plus
  10. Fiabilité

    Décalage de fuseau horaire dans les journaux du démon de collecte

    Les démons de collecte tournent dans différents pays et fuseaux horaires : chaque ligne de journal porte donc un décalage explicite, au format 2026-05-27 14:43:43 +03:00. Les enregistrements de sites distincts s’alignent sur une échelle unique dès qu’on les met côte à côte. Lors de la reconstitution d’un incident, l’ordre des événements sur l’ensemble du parc est sans ambiguïté.

    En savoir plus
  11. Intégration

    Pile de la vanne MQTT sur le serveur de collecte V3

    La pile de la vanne de coupure pilotée par MQTT tourne sur le serveur de collecte de troisième génération : échange, remise des commandes, stockage des données et module d’auto-enregistrement adapté à l’algorithme V3. Une vanne raccordée sur site s’enregistre elle-même : elle crée son unité de comptage et accepte les commandes aussitôt. Un seul serveur porte ainsi tout le parc d’actionneurs aux côtés des appareils de comptage.

    En savoir plus
  12. Nouveau

    Pile de collecte et stockage V3 chez le premier client industriel

    Le démon de collecte et le système de collecte et de stockage de troisième génération sont déployés en configuration complète chez le premier client industriel et reçoivent des relevés réels. À partir de là, le développement se fait sur un flux réel : archives, référentiels et volumes correspondent à une exploitation industrielle. L’analytique se vérifie sur des données de terrain véritables, et non sur un instantané de test.

    En savoir plus
v3.0.0-alpha.2 Alpha

La télémétrie au-delà du GSM

Le parc a accueilli des appareils que la plateforme ne fait pas que lire, mais commande aussi : des vannes de coupure MQTT. Le registre des unités de comptage a été reconstruit autour des statuts et de géodonnées exploitables pour la carte et les équipes terrain.

  1. Intégration

    Pilote MQTT pour vannes de coupure télécommandées

    La première classe d’appareils que la plateforme ne se contente pas de lire : elle les commande. Le pilote couvre l’échange MQTT, l’acheminement des commandes et l’enregistrement des données propres à la vanne. La chaîne de commande s’exécute sur la même pile que le comptage : les actionneurs n’ont besoin d’aucun sous-système dédié.

    En savoir plus
  2. Amélioré

    Un format unique de géocoordonnées pour tout le parc

    Les géocoordonnées du parc sont ramenées à un format unique : plus de huit cents unités de comptage, dont 761 traitées par programme et 48 à la main, là où les libellés demandaient une vérification. La table principale a ensuite été passée en revue : cinq unités sans coordonnées, dont trois de test. Le registre se prête à la carte, au regroupement et au calcul des tournées des équipes terrain.

  3. Amélioré

    Quatre statuts de travail de l’unité de comptage

    Une unité de comptage porte quatre statuts de travail : en service, déconnectée, nouvelle, en réparation. Chacun correspond à une action précise de l’exploitant. Sur le tableau de bord, ces statuts sont regroupés : la synthèse du parc se lit sans déplier la liste complète.

    En savoir plus
v3.0.0-alpha.1 Alpha

La coque de la nouvelle interface

Le point de départ de la troisième génération : un modèle de page unique, une recherche globale opérationnelle, un gestionnaire de thèmes et un tableau de bord sur le modèle de données de production. La localisation est intégrée aux composants dès le premier jour, non ajoutée après coup.

  1. Langues

    Localisation intégrée aux composants de la nouvelle coque

    La localisation est posée dans les fondations de la nouvelle interface : chaque composant de la coque arrive avec ses chaînes extraites, et non avec du texte dans le balisage. Le jeu de langues d’un serveur se déclare au déploiement par des variables d’environnement — schéma de localisation et liste des locales. Une installation destinée à un autre marché se passe ainsi de toute reconstruction de l’image.

  2. Nouveau

    Tableau de bord sur le modèle de données de production

    Les widgets du tableau de bord sont branchés sur le modèle de données de production : couverture du parc, santé des sessions de communication et états des appareils sur un seul écran. C’est la première épreuve de la nouvelle coque face aux volumes réels et à la vraie dispersion des données de terrain. La mise en page et les requêtes s’exécutent sur un jeu industriel, non sur des fixtures.

    En savoir plus
  3. Nouveau

    Coque d’interface : modèle de page, panneaux, gestionnaire de thèmes

    Le front end est assemblé sur un modèle de page unique : en-tête et pied de page, panneaux gauche et droit, gestionnaire de thèmes en apparence claire et sombre. La recherche globale couvre les objets, les équipements et les consommateurs, avec accès direct à l’enregistrement trouvé. Toutes les sections de la troisième génération se construisent à partir de ce modèle, ce qui unifie le comportement de la navigation et des états.

    En savoir plus