Le Live Blog

Les bases sont posées : le backend Node.js tourne, Socket.io diffuse en temps réel, et deux protocoles sont déjà connectés, Modbus TCP (port 502) et Siemens S7 (ISO-TSAP, port 102). Avant de pouvoir afficher quoi que ce soit, il faut nommer les données : chaque registre automate à lire ou écrire doit être déclaré avec son adresse, son protocole, son type et sa vitesse de polling.

La page Settings, un cockpit protégé

Je commence par la page Settings qui doit être protégée par un code PIN. Elle centralise toute la configuration du système en sections qui permettent d'adresser les éléments à lire/écrire, où et comment le faire : automates, appareils réseau, tags système. Puis, peu de temps après, le reste s'impose : les visual tags pour définir comment afficher les tags sur le poste, des tendances pour suivre l'évolution des valeurs, des recettes qui me permettront d'ajouter des fonctions "par lot" au module de création des tags, des grafcets et enfin des alarmes. Toute l'infrastructure se configure ici avant d'aller construire les pages de supervision.

La table de tags système

Chaque tag déclare son PLC d'appartenance, son type de registre (MW, MF, MD, M, I, Q, DB pour S7…), son adresse, son label affiché et son cycle de polling. Une case à cocher "Mode Réactif" force le tag dans le cycle à 150 ms, utile pour les boutons et sorties directes. Un bouton Test Lecture permet de vérifier immédiatement la valeur lue sur l'automate depuis le formulaire.

Les Visual Tags, première couche de représentation graphique

Un Visual Tag est une couche de présentation posée au-dessus d'un tag système : on lui choisit un type graphique, et il affiche la valeur en temps réel. La logique de détection est automatique selon le type de registre :

Un visual tag se configure en Settings, nom, tag source, type graphique, unité, décimales, couleurs. Une fois créé, il apparaît dans la sidebar de l'éditeur de pages du dashboard, prêt à être glissé-déposé sur n'importe quelle page de supervision.

Architecture des données en temps réel

Le cœur du runtime devra reposer sur un polling cyclique côté backend, couplé à Socket.io pour pousser les valeurs vers tous les clients connectés simultanément.

La gestion des pages et du routage

LivePLC est une SPA (Single Page Application). Les pages de supervision sont stockées en base de données, chaque page a un identifiant, un département associé, une liste de widgets avec leurs positions et configurations. Le frontend charge la configuration via l'API, instancie les widgets, et commence à consommer les données via Socket.io.

Départements, services et appareils autorisés

Assez tôt, j'ai réalisé qu'une usine ne peut pas avoir un seul écran de supervision partagé par tout le monde. Il fallait une notion de département, une zone logique regroupant des pages, des utilisateurs et des droits.

Chaque département peut être protégé par un code PIN. Les appareils (tablettes, PC opérateurs) sont enregistrés avec un UUID unique et se voient assigner un département et une page d'accueil. Quand une tablette est reconnue, elle accède directement à son contexte.

Les alarmes intégrées au runtime

Le moteur d'alarmes évalue en permanence des conditions sur les tags (seuils, fronts, combinaisons logiques). Quand une alarme se déclenche, elle apparaît dans la barre d'alarmes en haut, avec son niveau de criticité et un son configurable. L'acquittement est tracé dans un journal.

Les premiers prototypes de LivePLC étaient entièrement pensés pour une lecture verticale sur petit écran. Les pages s'affichaient comme une liste de widgets empilés les uns sous les autres, en défilement vertical, exactement comme une page web mobile. Simple, efficace, et accessible depuis n'importe quel téléphone sur le réseau wifi de l'usine.

Prototype v1, supervision Zone Moussage (séquence de démarrage), janvier 2026

Tôle sup, circuits électriques en temps réel. URL 192.168.2.70:5173 visible : c'est en production, sur le réseau de l'usine.

Le runtime, c'est le mode principal d'utilisation de LivePLC : l'écran que voit l'opérateur en atelier. Il affiche les valeurs des capteurs, les états des machines, les alarmes actives. Contrairement au mode création, le runtime est en lecture-écriture contrôlée, on peut envoyer des commandes aux automates, mais on ne peut pas modifier la mise en page.

📝

Édition, Un mois plus tard, première comparaison terrain

Un mois après les premières lignes de code, LivePLC est testé sur le réseau de l'usine.

C'est le moment de mettre les deux côte à côte : la supervision propriétaire installée depuis des années, et ma version embarquée sur smartphone.

La vidéo est cliquable, cliquez dessus !

Supervision propriétaire, compilée, exclusivement sous Windows, impossible à personnaliser

LivePLC, un navigateur Android suffit. Même page, mêmes données, depuis le smartphone en atelier

Dès les premières semaines, le layout de LivePLC était entièrement basé sur un système de grille verticale à 12 colonnes, inspiré de Bootstrap. L'idée était simple et cohérente avec le projet initial : les pages s'éditent depuis un PC, mais elles sont conçues pour être lues sur un smartphone. Donc on compose verticalement, et tout s'adapte automatiquement. C'est ce modèle qui a tenu pendant les premières semaines, avant que les limites sur écran PC ne se fassent sentir.

Objectif du jour : concevoir un layout adapté au smartphone du technicien, éditable confortablement depuis un PC

Le principe : React-Grid-Layout sur 12 colonnes

J'ai utilisé React-Grid-Layout (RGL), une librairie de drag & drop sur grille. La surface d'édition est découpée en 12 colonnes. Chaque widget occupe une largeur exprimée en nombre de colonnes (w) et une hauteur en unités de grille (h). La position est définie par x (colonne de départ) et y (ligne).

Un widget "pleine largeur" a w: 12. Un demi-écran, w: 6. Et surtout : quand on ajoute un widget en mode portable, il est automatiquement initialisé à w: 12, pleine largeur, pour s'adapter au petit écran sans configuration supplémentaire. RGL gère l'empilement automatique des widgets vers le bas (y: Infinity).

Comment on édite une page mobile depuis un PC

Une subtilité importante : on crée les pages depuis un écran PC, mais on pré-visualise le résultat sur smartphone. L'éditeur affiche donc la grille dans un conteneur dont la largeur simule un smartphone (environ 390px). On glisse les widgets, on les redimensionne, et on voit en direct comment ça va se présenter sur le téléphone de l'opérateur.

RGL calcule les positions en unités relatives (colonnes/lignes). Quand l'application s'ouvre sur un vrai smartphone, les colonnes se redimensionnent proportionnellement à la largeur réelle de l'écran. Un widget w: 6 occupe exactement la moitié de n'importe quel téléphone, qu'il soit en 360px ou 430px de large.

Les limites qui sont apparues très vite

Le système fonctionne très bien pour son usage prévu : la visualisation mobile. Mais très rapidement, je me suis dit qu'on pourrait utiliser LivePLC également sur des écrans fixes de supervision en salle de contrôle, des moniteurs 24 ou 27 pouces en Full HD.

Et là, le layout grille vertical montre ses limites. Sur un écran 1920×1080, avoir tous les widgets en colonne unique pleine largeur, c'est une catastrophe ergonomique. L'espace horizontal est gaspillé, on doit scroller verticalement pour voir toutes les informations, et on perd complètement la vue synoptique qu'on peut avoir avec un vrai SCADA.

La conclusion s'est imposée : il fallait deux modes de layout distincts et équivalents. Et il fallait qu'une même page puisse avoir les deux simultanément, avec conversion automatique dans les deux sens. Mais avant cela, j'ai déjà une liste TODO qui s'agrandit d'heure en heure. J'y reviendrai donc plus tard avec le basculement Mode Fixe ↔ Mode Portable.

Les deux modes de layout n'existaient pas encore à cette étape, le pivot est arrivé quelques semaines plus tard. Le versioning et le Resource Monitor ont été les ajouts majeurs de cette session. L'objectif du versioning : que chaque widget soit une unité autonome qui se décrit elle-même, et que l'éditeur n'ait jamais à connaître les propriétés spécifiques de chaque composant. L'enjeu derrière était plus profond : que le code du Dashboard ne serve plus qu'à implémenter ses propres fonctionnalités d'édition, qu'il devienne générique, que sa charge soit minimisée pour rester réactif à mesure que la bibliothèque de widgets grossit. Sans cette architecture, chaque nouveau widget aurait alourdi le composant central. Avec elle, le Dashboard peut embarquer n'importe quel widget futur sans en avoir connaissance à l'avance.

Objectif du jour : rendre le Dashboard générique en découplant la définition des widgets de l'éditeur, et mesurer l'impact des pages sur les performances du navigateur

Le WIDGET_REGISTRY, source de vérité unique

Chaque widget est enregistré dans WIDGET_REGISTRY, un dictionnaire central. Une entrée associe un type ("GaugeWidget") à : son composant React, sa version, ses valeurs par défaut, sa liste de propriétés configurables.

WIDGET_REGISTRY = {
  "GaugeWidget": {
    component: GaugeWidget,
    version: "2.1",
    defaultConfig: { min: 0, max: 100, unit: "" },
    defaultW: 3, defaultH: 3,
    definition: {
      properties: [
        { key: "min", type: "number", label: "Minimum" },
        { key: "max", type: "number", label: "Maximum" },
        { key: "unit", type: "string", label: "Unité" },
      ]
    }
  }
}

Quand LivePLC charge une page, si la version stockée en base est inférieure à la version du registry, une migration automatique est proposée, les nouvelles propriétés reçoivent alors leurs valeurs par défaut. Objectif : un ancien projet doit rester compatible avec toutes les versions de LivePLC et des widgets pour permettre des migrations et améliorations en douceur.

Le panneau de propriétés auto-généré

Le panneau de propriétés côté éditeur est généré dynamiquement depuis la liste definition.properties du widget sélectionné. Les types de propriétés gérés :

• tag, sélecteur avec autocomplétion sur les tags disponibles
• number, champ numérique avec validation
• string, texte libre
• color, color picker avec palette industrielle
• boolean, toggle on/off
• select, liste déroulante
• tagList, multi-sélection de tags (graphiques multi-courbes)

Les modifications sont visibles en live preview immédiatement, sans sauvegarder. C'est un détail d'UX qui change complètement le rythme de travail.

Les modèles de widgets

Un modèle c'est une configuration de widget sauvegardée avec un nom. On le crée depuis n'importe quel widget configuré. Les modèles apparaissent dans la barre d'outils dans une section dédiée. Glisser un modèle sur la page instancie le widget avec toutes ses propriétés prêtes, y compris en mode fixe avec les dimensions appropriées.

La fonctionnalité "Importer depuis l'autre mode", qui sera expliquée dans le prochain article, s'appuie aussi sur ce système : les widgets importés conservent leur configuration (couleurs, seuils, tags associés), seules les positions changent.

Une multitude de modèles pour un seul composant :

Mais aussi la possibilité de créer des blocs personnalisés en sélectionnant les widgets dans le layout, pratique pour les réutiliser sur d'autres pages :

Le Resource Monitor, s'assurer que les pages restent réactives

L'un des problèmes que je voulais explicitement éviter avec LivePLC, c'est la latence. Pas la latence réseau vers les automates, ça, c'est gérable, mais la latence d'affichage, ce gel d'une seconde où l'interface décroche quand on navigue entre pages. C'est exactement ce qu'on ressent avec beaucoup de logiciels de supervision existants, et c'est souvent ce qui pousse les opérateurs à râler, et pour de bonnes raisons.

Pour mesurer ça objectivement, j'ai développé le Performances Monitor en parallèle du versioning. Accessible via le bouton "Stats Système" dans la barre de navigation, il s'affiche en superposition sur n'importe quelle page visualisée sans la perturber :

Le bouton "Stats Système" dans la barre de navigation, accessible en mode édition, invisible en mode runtime

Panneau principal sur une page active : 13 FPS, 39 widgets, 1099 nœuds DOM, 28 tags PLC, 4 ms de ping, 6.99 Ko/payload, ici on voit le problème : 13 FPS, page un peu trop chargée pour le hardware qui l'exécute, ou peut-être quelques optimisations à prévoir...

Vue "Évolution dans le temps", 34 points loggués. RAM max 96 Mo, FPS max 60, DOM max 1181 nœuds. Dernière page : "Suivi des débits"

Le DOM : le point de tension inattendu

Le panneau affiche en temps réel six indicateurs clés pour la page ouverte :

Le DOM : le point de tension inattendu

En développant cet outil, j'ai mis le doigt sur quelque chose que je ne mesurais pas jusqu'ici : dans un navigateur, chaque élément HTML visible est un nœud dans le DOM (Document Object Model). Plus une page a de nœuds, plus le moteur de rendu travaille à chaque mise à jour, même si les nœuds qui changent sont peu nombreux. Sur la capture ci-dessus, on voit 1062 nœuds DOM pour une page de supervision en production : un chiffre à surveiller, car au-delà d'un certain seuil les animations et les mises à jour commencent à saccader.

Concrètement : une page avec 40 widgets bien conçus peut être plus légère qu'une page avec 15 widgets mal optimisés, si ces 15 widgets génèrent chacun une centaine de nœuds imbriqués. Le Performances Monitor rend ce phénomène visible et mesurable sans quitter l'interface.

C'est pourquoi j'ai choisi de le fournir directement dans LivePLC, pas dans une console de développeur. La personne qui construit les pages de supervision doit pouvoir vérifier que ce qu'elle crée ne va pas ralentir le système en production. La réactivité d'une page n'est pas seulement une question d'infrastructure : c'est aussi une question de conception.

Dans la toute première version de LivePLC, les widgets affichaient les données telles quelles : une adresse Modbus, une valeur brute, un label générique. Du genre %MF4294 = 30745.08. Utile pour déboguer, mais inutilisable pour un opérateur qui ne connaît pas les adresses mémoire de son automate.

Avant les tags visuels, la liste des variables avec leurs adresses PLC brutes (%MF4304, %MW4276:3…)

Après, les mêmes données, mais avec des labels lisibles, des unités et une plage de valeurs

Idée du jour : créer une couche d'abstraction entre les adresses PLC brutes et l'affichage opérateur, que l'interface ne parle plus en registres, mais en valeurs métier

Ce qu'est un tag visuel

Un tag visuel lie une adresse PLC à un affichage compréhensible. Il contient : un nom lisible ("Niveau cuve polyol 1"), une unité (kg, °C, %, V…), une plage min/max pour le scaling, des seuils colorés (vert normal, orange avertissement, rouge alarme), et le nombre de décimales à afficher.

Mais ce qui en fait un concept fondateur, c'est l'effet multiplicateur : une fois le tag visuel configuré, je peux l'utiliser dans n'importe quel widget. Une jauge, un thermomètre, un afficheur numérique, un mini-trend, tous liront exactement la même définition. Si je corrige l'unité ou les seuils, tous les widgets se mettent à jour automatiquement, sur toutes les pages, dans les deux modes de layout.

Les deux captures ci-dessus montrent concrètement la différence : à gauche, la liste des variables brutes avec leurs adresses Modbus, c'est ce que voit un développeur. À droite, les mêmes données après la couche de tags visuels, c'est ce que voit un opérateur ou un technicien.

Afficher des valeurs sous forme de liste, c'est utile, ça m'a servi pendant les premières semaines. Mais une interface de supervision devrait montrer les choses, pas juste les lister. Quand un opérateur regarde la temperature d'un four de préchauffage, il devrait voir "60°C sur une jauge rouge" et comprendre immédiatement que c'est en zone normale, pas lire "60.3" et chercher mentalement si c'est bien ou non.

Ce jour-là, j'ai construit les premiers widgets vraiment visuels : la jauge circulaire, le thermomètre, la barre de niveau et la cuve animée.

Préchauffage tôle, deux thermomètres en temps réel (60.3°C et 40.9°C). Ce sont des données réelles, lues depuis l'automate.

Niveaux cuves polyol, barres de remplissage avec valeur en kg. Une cuve sélectionnée pour production (ON), l'autre non.

Objectif du jour : passer des listes de valeurs brutes aux représentations visuelles, une interface de supervision doit montrer, pas seulement lister

La jauge circulaire

C'est le widget de référence pour les mesures analogiques. L'arc de cercle se colore selon les zones configurées : vert pour la plage normale, orange pour les avertissements, rouge pour les alarmes. Les seuils sont définis dans le tag visuel, pas dans le widget lui-même, ce qui veut dire qu'une jauge créée à partir d'un tag bien configuré est prête à l'emploi sans réglage supplémentaire.

Le thermomètre et la cuve

Le thermomètre est une variante verticale avec une représentation plus intuitive pour les températures. La cuve (TankWidget) mérite un mot particulier : elle a une animation de vague légère qui rend la lecture du niveau plus naturelle, on "voit" le liquide plutôt que de lire un pourcentage.

Les modèles de widgets

Une fonctionnalité ajoutée ce même jour : les modèles. Un modèle est une configuration de widget sauvegardée avec un nom. Une fois le thermomètre bien configuré pour les températures de préchauffage (plage 0-150°C, vert 20-90°C, alarme à 100°C), je le sauvegarde comme modèle. Sur la prochaine page, je glisse le modèle et le widget est prêt, je n'ai qu'à changer le tag source.

Visualiser, c'est la moitié du travail d'une supervision. L'autre moitié, c'est agir : démarrer un moteur, changer une consigne, ouvrir une vanne. Ce jour-là j'ai ajouté les premiers widgets de commande, dont le slider de consigne, et c'est à ce moment que j'ai réalisé que l'écriture vers un PLC depuis un navigateur méritait d'être traitée avec soin.

Objectif du jour : permettre à l'opérateur d'agir sur les automates depuis l'interface, avec les mécanismes de sécurité adaptés à un contexte industriel

La logique d'écriture

Quand un opérateur déplace un slider, une valeur doit partir vers l'automate. Côté backend, le tag doit être déclaré en mode RW (lecture-écriture) ou W (écriture seule). La route POST /api/write reçoit la valeur, appelle writeTag() sur le handler du bon protocole, et l'automate reçoit la consigne en quelques millisecondes.

Les écritures ne suivent pas les cycles de polling. Elles sont événementielles, déclenchées par l'interaction de l'utilisateur, pas par une boucle. La seule limite de vitesse est la latence réseau entre le serveur Node.js et l'automate.

Le slider : écrire sur relâchement, pas en continu

Pour une consigne de température ou de vitesse, envoyer la valeur à chaque pixel de déplacement du slider serait contre-productif. J'ai configuré le slider pour écrire uniquement au relâchement, quand l'opérateur lâche le curseur, la valeur part une seule fois. Pendant le glissement, un affichage local montre la valeur visée sans rien envoyer à l'automate.

Ce détail est important en contexte industriel : une consigne qui change 50 fois par seconde pendant un glissement de souris peut déclencher des oscillations sur le système de régulation. L'écriture sur relâchement supprime ce risque.

La confirmation double-appui pour les commandes critiques

Le bouton momentané envoie 1 pendant l'appui et 0 au relâchement, comme un bouton-poussoir câblé. Pour les commandes critiques (démarrage moteur, ouverture vanne process), une boîte de confirmation en deux étapes s'intercale entre le clic et l'envoi.

Sur smartphone, ce mécanisme est essentiel : un faux contact tactile sur un bouton "Démarrer" en mode portable est bien plus probable que sur une souris. La confirmation double-appui rend ce risque négligeable.

Une fois le WIDGET_REGISTRY en place et le panneau de propriétés auto-généré, créer un nouveau widget devient une affaire de quelques heures. La base est solide : chaque composant sait se configurer, se versionner, se migrer. Il n'y a plus qu'à construire dessus.

Les semaines suivantes voient défiler les nouveaux composants à un rythme soutenu :

📝

TextWidget 13/02

Texte statique avec templates de mise en forme, idéal pour les étiquettes et titres de zones.

🛢️

TankWidget + ClockWidget 15/02

Cuve/niveau animée avec remplissage liquide. Horloge synchronisée sur l'heure atelier.

🎚️

SliderWidget 15/02 v2

Curseur linéaire, rotatif ou arc 180°/270°. Écriture tag PLC en temps réel au relâchement.

⚙️

PumpWidget + ValveWidget 17/02 v3

Pompe animée (rotation, débit) et vanne (ouverte/fermée/en cours), liées à des tags d'état. Pipes automatiques entre composants.

🔔

AlarmWidget 03-04/03

Alarmes local/global, 3 sévérités (info/warning/critical), multi-conditions AND/OR. Moteur d'évaluation côté backend.

📷

WebcamWidget 05-06/03

Flux MJPEG/HLS (caméras Axis), enregistrement vidéo, archive consultable avec timeline scrollable.

Très tôt dans le développement, un problème s'est posé : comment gérer plusieurs appareils différents dans la même usine, un PC opérateur fixe, des tablettes de maintenance, des écrans de supervision sur les lignes, avec des droits et des pages d'accueil différents pour chacun ?

La solution habituelle serait un système de comptes utilisateurs. J'ai préféré une approche différente, plus adaptée au contexte industriel : l'authentification par appareil.

Objectif du jour : gérer des dizaines d'appareils hétérogènes en atelier avec des droits différents, sans système de comptes complexe

JWT par appareil, identification persistante

Quand un appareil se connecte pour la première fois à LivePLC, il génère un device_id unique (UUID) stocké en localStorage, et demande un accès au serveur. L'administrateur valide l'appareil depuis Settings, en lui attribuant un nom de poste, un département et une page de démarrage. Le serveur émet un JWT signé, stocké lui aussi en localStorage.

À chaque reconnexion, le JWT est vérifié côté serveur. Si valide : l'appareil retrouve directement son contexte (département, page d'accueil), sans aucune saisie de mot de passe. Si le JWT est expiré ou révoqué, l'appareil repasse par le cycle d'approbation.

QRCodePage, accès temporaire kiosque

Le QRCodePageWidget génère un QR code qui pointe vers une page spécifique de LivePLC. Quand un appareil non enregistré scanne ce QR, il ouvre la page en mode kiosque, lecture seule, durée limitée (configurable sur le widget), sans accès au reste de l'application.

Un bandeau "Mode Kiosque, Lecture Seule" s'affiche sur le smartphone connecté sur le même réseau wifi que le réseau LivePLC, avec un compte à rebours visible. À l'expiration, l'accès est révoqué et l'utilisateur est redirigé vers un écran "Session terminée". Si le navigateur est fermé avant l'expiration, la session kiosque est annulée (sessionStorage et non localStorage, expiration à la fermeture du navigateur, par design).

Ici l'écran des caméras est partagé pendant 10 min grâce au QR code. Une fois le QR code scanné, il a été consommé et un nouveau doit être généré afin d'autoriser un nouveau poste visiteur ou enregistré à accéder directement à cette page.

QR codes équipement, le hub documentaire de l'atelier

Le système QR codes va plus loin que la simple consultation d'une page. Chaque équipement de l'usine peut recevoir un QR code imprimé et collé dessus. Le scan ouvre une page dédiée à cet équipement, avec plusieurs types de contenus configurables :

• Documents : PDFs, images, liens web, manuels techniques.
• Page dashboard : lien direct vers une page de supervision LivePLC.
• Pointage : formulaire d'entrée/sortie pour les pauses ou interventions.
• Contrôle qualité : formulaire complet avec photo, signature et statut de conformité.

Les documents sont filtrés selon les services autorisés, Maintenance, Production, Qualité, Sécurité. Un technicien de maintenance ne voit pas les documents réservés au service Qualité, et vice-versa.

Le contrôle qualité intégré

Le contrôle qualité est directement intégré dans le hub équipement, accessible en un scan. Le formulaire propose cinq options :

Chaque contrôle est horodaté et stocké en base de données, photo en base64, signature vectorielle, statut, nom du contrôleur. L'historique est consultable depuis n'importe quel appareil autorisé.

Une des critiques récurrentes des outils de supervision web, c'est leur dépendance à des passerelles propriétaires pour communiquer avec les automates. Soit ils ne parlent que OPC UA, soit ils nécessitent un middleware tiers coûteux pour brancher du Modbus.

LivePLC intègre les drivers directement dans son backend Node.js. Actuellement : 4 protocoles actifs (prêts à l'emploi) et 13 stubs (architecturés, activables en installant le package npm correspondant et quelques tests en production pour tester tout cela).

Objectif du jour : ne pas être limité à un seul fabricant d'automates, architecturer un système multi-protocoles extensible sur n'importe quel parc machine

Les 4 protocoles actifs

Les 13 stubs, activer en 4 fichiers

L'architecture est conçue pour que l'ajout d'un protocole ne soit qu'une affaire de configuration. Chaque protocole expose la même interface (connect, disconnect, readTags, writeTag) et est référencé dans un PROTOCOL_REGISTRY central.

Activer un nouveau protocole se fait en 4 étapes : créer le fichier driver dans backend/protocols/, l'enregistrer dans index.js, ajouter ses colonnes spécifiques dans database.js, et ajouter l'option dans Settings.jsx.

Pourquoi avoir architecturé les stubs si tôt

La décision d'architecturer les stubs dès le début plutôt que d'attendre les demandes clients vient d'une conviction simple : dans l'industrie, le parc d'automates est hétérogène. Une usine a rarement qu'un seul fabricant d'automates. Une ligne Schneider côtoie un convoyeur Siemens, des drives Mitsubishi, et des capteurs avec sorties Modbus.

Proposer un outil qui ne parle qu'à Siemens ou qu'à Modbus, c'est fermer la porte à la moitié des projets. Avoir les stubs architecturés permet de dire : "OPC UA ? Prêt. Allen-Bradley ? 20 minutes pour activer EtherNet/IP. BACnet pour le bâtiment ? Disponible."

En développant le système de QR codes équipements dans LivePLC, j'ai progressivement construit quelque chose qui n'avait plus grand-chose à voir avec la supervision industrielle. Des formulaires, de la gestion documentaire, des historiques d'interventions, utile, mais étranger à la vocation première d'un SCADA.

La conclusion s'est imposée : cette partie méritait sa propre application. Qwipment est né de ce constat.

L'idée : les QR codes de LivePLC avaient tellement grandi qu'ils méritaient leur propre application

Le nom

Qwipment est une déformation stylistique d'"Equipment". Le "Q" initial fait un clin d'œil au QR code sans le dire explicitement. La prononciation est "Kwipment". Domaines réservés : qwipment.fr et qwipment.com.

Slogan : "Scan. Connect. Know.", le même workflow que LivePLC, mais appliqué à la gestion d'équipements plutôt qu'à la supervision de process.

Ce que fait Qwipment

Qwipment est un gestionnaire de QR codes industriels. Chaque équipement reçoit un QR code unique. Le scan ouvre une page dédiée à l'équipement, avec :

• Ses documents (manuels, fiches techniques, procédures)
• Ses formulaires (présence, contrôle qualité, check-list, personnalisés)
• Des pages de supervision LivePLC si l'équipement est connecté à un automate
• Des actions HATALINE si une GMAO est en place (vérification périodique, bon de travaux...)

L'idée clé : le Suite Connector

C'est le concept qui différencie Qwipment d'un simple gestionnaire documentaire. Qwipment n'est pas un silo, c'est un hub qui agrège les contenus de toute la suite logicielle.

Chaque application de la suite expose un endpoint standard :

GET /suite-connector/contents?uid={equipment_uid}

// Réponse LivePLC :
[{ "app": "LivePLC",  "type": "supervision_page",
   "label": "Page Ligne 1", "icon": "monitor" }]

// Réponse HATALINE :
[{ "app": "Hataline", "type": "form",
   "label": "Vérification périodique", "icon": "clipboard-check" }]

Qwipment interroge tous les connecteurs configurés et affiche les résultats groupés par application, avec les couleurs de chaque app. Un seul scan QR → documents Qwipment + page de supervision LivePLC + actions maintenance HATALINE, selon ce que le service de l'utilisateur est autorisé à voir.

Un QR code, des expériences différentes selon le rôle

C'est là où le connecteur de suite révèle toute sa puissance. Chaque responsable de service configure ses propres règles d'accès via la même interface Qwipment. Un seul QR code par équipement, mais le contenu affiché est entièrement personnalisé selon le profil de la personne qui scanne.

Tout ceci est configurable de manière autonome par chaque responsable de service, via la même interface, dans la même application, avec le même QR code pour chaque équipement. Le technicien, le responsable qualité et le visiteur scannent le même code : chacun voit ce que son profil lui autorise.

Depuis le premier commit de LivePLC en janvier 2026, je tiens une liste de toutes les idées qui me passent par la tête : fonctionnalités à ajouter, optimisations à réaliser, bugs à corriger, pistes à explorer. Elle vit dans mon application todo personnelle, et elle ne fait qu'augmenter au fil des sessions de développement et de mon quotidien sur le terrain. Chaque problème résolu en génère deux nouveaux, chaque nouvelle fonctionnalité révèle trois usages auxquels je n'avais pas pensé.

Voici un état des lieux complet, trié par catégorie: ce qui a été fait, ce qui reste à faire, et surtout ce qui me semble le plus prometteur à court terme.

Cette liste est mon carnet de bord autant que ma feuille de route. Certains items attendent depuis des mois, d'autres émergent d'une conversation ou d'un problème rencontré en usine le matin même. Ce qui est certain : les modules d'apprentissage et de prédiction représentent le vrai saut qualitatif à venir : passer d'une supervision qui affiche à une supervision qui prédit.