Démonstration : une méthode, déployée.

Pour comprendre concrètement ce que nous installons, prenons un exemple de déploiement type — sans nom de site, sans détail confidentiel : l'architecture, les écrans, les flux de données, les modes dégradés. Tout ce que vous retrouveriez sur votre site, à l'identique sur la forme, à votre image sur le fond.

Le cas type

Un site industriel de production cyclique avec utilité gaz.

Imaginons un site qui exploite plusieurs équipements de production fonctionnant par cycles, alimentés en énergie gaz, avec un automate de pilotage par équipement et une supervision centrale en place. La problématique : la supervision existante donne des moyennes, mais ne révèle pas les dérives entre cycles. C'est exactement le terrain naturel de la méthode SMARTENSITY.

Objectif du déploiement : faire émerger l'IPE par cycle plutôt que par journée. Identifier les cycles déviants, les corréler à la phase machine (chauffe, production, refroidissement), et déclencher l'action corrective au bon moment — sans noyer la maintenance d'alertes.
Architecture technique

Quatre couches, une circulation propre de la donnée.

L'architecture de déploiement repose sur des protocoles standards industriels. Aucune dépendance constructeur exclusive : la chaîne fonctionne avec les automates et les compteurs déjà en place sur votre site, dans la majorité des cas.

COUCHE 1 — TERRAINAutomates et compteurs
Les équipements de pilotage déjà installés sur site (automates industriels, compteurs gaz et électriques communicants, capteurs additionnels posés à l'audit) exposent leurs registres via Modbus TCP, OPC-UA ou compteur à impulsions.
COUCHE 2 — COLLECTEPasserelle locale
Une passerelle dédiée installée sur site interroge les équipements à fréquence régulière (typiquement 1 Hz), normalise les valeurs (facteurs d'échelle, signes), horodate, et alimente un serveur de pilotage local.
COUCHE 3 — SERVEURPilotage et persistance
Le serveur local héberge le dashboard, expose une API REST documentée, persiste les seuils paramétrés, le journal des événements, les compteurs de maintenance, l'historique des courbes et les archives CSV. Tout reste local — l'envoi cloud est optionnel.
COUCHE 4 — ACCÈSDashboard et accès distant
Les utilisateurs accèdent au dashboard depuis le réseau local (poste de production, mobile, tablette) ou à distance via un tunnel chiffré. Trois profils d'écran natifs — direction, production, maintenance — chacun avec ses indicateurs.
Dashboard déployé — exemple d'écrans

Trois profils, trois angles de pilotage.

Les écrans ci-dessous sont des reconstitutions à but pédagogique — pas des captures de site client réel. Ils illustrent la structure des vues que nous mettons en service et le principe de séparation par profil utilisateur.

Profil — Direction d'usine

Conso gaz mois
42 318 Nm³
Vs même mois N-1
−4,2 %
IPE site mois
8,1 kWh/u
Empreinte CO₂ mois
85 t

Vue mensuelle agrégée pour la direction. Les chiffres proviennent d'un cas type de chaudière vapeur 8 MW + ligne de production cyclique. Aucune valeur de coût en euros ni engagement de performance ne figure ici — le pilotage budgétaire reste à votre main, l'outil fournit la donnée énergétique vérifiable.

Profil — Direction de production

Cycle en cours
#847
Cycles depuis 00 h
36
Durée moy. cycle
14 min 20
Cycles hors cible
3

Vue production temps réel : créneaux représentant les phases successives (chauffe, production, refroidissement) des cycles machine. Chaque cycle est isolable, ses indicateurs métier sont comparés à la cible — les trois cycles hors cible ouvrent un ticket d'analyse pour la maintenance.

Profil — Responsable maintenance

Alertes ouvertes
2
MTBF 30 j
142 h
Heures brûleur
12 480 h
Entretien pompe
82 %
Journal — derniers événements
[14:08:23] Conductivité eau — seuil haut 2 540 µS/cm — durée : 4 min — retour normal
[11:42:09] Pression vapeur — alerte haute 12,4 bar — temporisation 5 s — retour normal
[09:17:55] Cycle #842 hors cible (IPE 9,8 vs 8,2) — ticket #T-2026-0517-03 ouvert
[07:30:12] Démarrage brûleur — séquence normale — mot de vie OK

Le journal système conserve l'horodatage de chaque seuil franchi, sa durée et son retour à la normale — entièrement exploitable pour audit de maintenance et démonstration de conformité ICPE.

Exemple chiffré — Cas type

Un déploiement type sur chaudière vapeur + équipement de process.

Pour ancrer concrètement la méthode, voici un exemple de déploiement type. Le site combine une chaufferie vapeur centrale et un équipement de process cyclique (qui peut être indifféremment un séchoir, un autoclave, un four, un mélangeur, une cabine, un réacteur — la logique s'adapte à toutes les activités de production cyclique).

Note de lecture importante : les chiffres présentés ci-dessous sont issus d'un cas type pédagogique. Ils ne constituent ni un engagement de performance, ni un chiffrage économique, et ne préjugent en rien des valeurs réelles que votre site présenterait. Aucun euro n'apparaît dans cette démonstration — l'objet est uniquement d'illustrer ce que l'outil affiche, mesure et journalise.
A

Vue chaudière vapeur — pilotage thermique

Chaudière vapeur gaz, puissance nominale 8 MW, régulation via automate constructeur. L'outil interroge l'automate à 1 Hz et expose en continu les paramètres de combustion, de rendement, et l'état de la chaîne eau-vapeur.

Pression vapeur
11,2 bar
Consigne 11,0 bar · OK
Niveau eau
62 %
Plage 15–95 % · OK
Conductivité eau
1 840 µS/cm
Seuil 2 500 · OK
Débit gaz
87 Nm³/h
Brûleur 68 % charge
Rendement combustion
92,4 %
Calcul NF EN 12952
Excès d'air
18 %
Cible 15–20 %
Perte Siegert
6,8 %
↑ à surveiller
Mot de vie
OK
Communication temps réel
Lecture métier : tous les indicateurs principaux sont dans leur plage. La perte Siegert à 6,8 % se rapproche du seuil d'alerte (typiquement 7,5 %), signe d'une légère dérive d'encrassement à surveiller — typiquement résolu par un ramonage planifié ou un ajustement de l'excès d'air. C'est exactement le type de signal faible que les agrégats journaliers d'un dashboard générique ne révèlent pas.
B

Vue équipement de process — pilotage par cycle

Équipement de production cyclique (séchoir, autoclave, four, réacteur, cabine, mélangeur — peu importe la fonction). Cinq phases successives sont automatiquement détectées par la passerelle à partir des signaux d'état remontés par l'automate, et chaque cycle est isolé, chiffré, et comparé à la cible métier.

Phase 1
Chargement
Phase 2
Chauffe / montée
EN COURS
Phase 3
Production
Phase 4
Refroidissement
Phase 5
Déchargement
Cycle en cours
#847
Démarré à 14 h 12
Temps en phase
06 : 42
Phase 3 / 5
Cycles depuis 00 h
36
Cible jour : 42
Compteur cycles total
12 547
Depuis mise en service
Durée moy. cycle 30 j
14 : 20
Stable vs N-1
IPE métier cycle
8,4 kWh/u
Cible 8,2 · proche
Cycles hors cible 24 h
3
Tickets à analyser
Heures moteur
8 950 h
Entretien à 10 000 h
Lecture métier : 36 cycles complétés depuis le début de la journée pour une cible de 42 — léger retard sur la cadence. Surtout, 3 cycles sortent de la plage IPE cible : l'outil ouvre automatiquement un ticket d'analyse par cycle déviant et corrèle avec la phase machine concernée. C'est ce niveau de granularité qui rend possible une action corrective ciblée, à la place d'un constat global flou.
C

Journal système — extrait des dernières 24 h

Tout événement (franchissement de seuil, ouverture/fermeture d'alarme, démarrage/arrêt, cycle déviant, intervention) est horodaté à la seconde, qualifié par sa nature, sa durée et sa résolution. Le journal est persistant, exportable en CSV, et entièrement exploitable pour audit qualité, audit énergétique réglementaire ou démonstration de conformité ICPE.

// Journal /api/journal?from=2026-05-17T00:00:00&n=10
[15:24:08] CYCLE #847 phase 2→3 (chauffe → production) · durée chauffe 4 min 18 s
[14:42:51] WARN   Perte Siegert 7,1 % (seuil avert. 7,5 %) · pas d'escalade
[14:18:33] CYCLE #846 IPE 8,3 kWh/u · cible respectée
[14:08:23] WARN   Conductivité eau 2 540 µS/cm (seuil 2 500) · durée 4 min · retour normal
[13:52:09] CYCLE #845 IPE 8,4 kWh/u · cible respectée
[13:37:14] ALARM Cycle #844 IPE 9,8 kWh/u (cible 8,2) · ticket T-2026-0517-03 ouvert
[12:08:45] INFO  Démarrage brûleur · séquence normale · mot de vie OK
[11:42:09] WARN   Pression vapeur 12,4 bar (alerte haute 12,0) · temporisation 5 s · retour normal
[09:17:22] SEUIL Modification seuil conductivité haute : 2 400 → 2 500 µS/cm · auteur : maintenance
[07:30:12] INFO  Bilan 24 h envoyé · 142 cycles · 0 alarme critique · MTBF 142 h
D

Ce que cette vue rend possible (et que les autres ne rendent pas)

Corréler une dérive énergie à une phase précise

Le cycle #844 est sorti de la cible IPE. Sans la granularité par cycle, l'écart serait noyé dans la moyenne journalière (qui resterait acceptable). Avec elle, on identifie immédiatement la phase machine concernée et on déclenche l'analyse.

Distinguer signal faible et faux positif

La pression vapeur a touché l'alerte haute 12,4 bar — mais la temporisation anti-rebond (5 s) a confirmé la transitoire et évité une fausse alarme. Le franchissement est tracé, sans pollution opérationnelle.

Construire un dossier réglementaire défendable

Le journal horodaté constitue, à 6 ans d'horizon, un dossier de preuve exploitable pour audit qualité, audit énergétique réglementaire et contrôle ICPE 2910-A. La traçabilité ne se construit pas après coup — elle est native.

L'outil exposé par API

Une API REST documentée, pour ne jamais être prisonnier.

Vos données restent les vôtres. L'outil expose un ensemble d'endpoints REST documentés qui permettent l'intégration directe dans vos propres systèmes — supervision existante, outils de reporting, plateforme RSE, archivage long terme.

GET/api/liveDonnées temps réel
GET/api/streamFlux serveur-événement (SSE)
GET/api/trendHistorique des courbes
GET/api/alarmesAlarmes actives en temps réel
GET/api/journalJournal horodaté des événements
GET/api/faultsHistorique des défauts avec durée
GET/api/archivesListe et téléchargement CSV
GET/api/diagnosticSanté serveur et communication
POST/api/seuilsConfiguration des alertes
GET/api/configLecture configuration site
# Exemple — récupération de l'état temps réel GET /api/live HTTP/1.1 Host: votre-site.local { "horodatage": "2026-05-17T14:23:45Z", "comm_ok": true, "phase_cycle": "sechage", "cycle_n": 847, "indicateurs": { "ipe_metier": // défini avec vous, "phase_courante": "production", "alarmes_actives": 0 } }
Alertes et seuils paramétrables

Quatre niveaux par variable, avec temporisation anti-rebond.

L'outil propose nativement une configuration fine des seuils pour chaque variable surveillée. L'objectif : éviter la fatigue de surveillance qui finit par faire ignorer les alertes — l'écueil classique des dashboards génériques.

Alarme basse

Seuil de criticité maximale en franchissement bas. Notification immédiate, escalade automatique. Exemple : niveau d'eau chaudière critique.

Alerte basse

Seuil d'avertissement bas. Affichage dans le journal, pas de notification systématique. Exemple : conductivité qui descend trop vite.

Alerte haute

Seuil d'avertissement haut, anti-rebond paramétrable. Permet de détecter une dérive en cours avant qu'elle ne devienne critique.

Alarme haute

Seuil maximal — déclenche les notifications opérationnelles (SMS, email, intégration GMAO). Horodatage et durée tracés.

Pourquoi une temporisation anti-rebond ? Une variable physique oscille naturellement autour de sa consigne. Sans temporisation, l'outil génère des dizaines d'alertes pour une variation transitoire de quelques secondes. La temporisation (typiquement 3 à 10 secondes selon la variable) impose qu'un seuil soit franchi durablement avant déclenchement — l'alerte devient pertinente, pas bruyante.
Résilience opérationnelle

Pensé pour survivre aux coupures.

Un site industriel ne tolère pas de coupure de pilotage. L'outil intègre par défaut plusieurs niveaux de continuité de service — chaque niveau prend le relais automatiquement si le précédent défaille.

🌐

Coupure Internet

L'outil continue de fonctionner localement — collecte, dashboard, journal, alarmes. La perte de connectivité externe ne perturbe pas le pilotage sur site. Synchronisation différée au retour du réseau.

📡

Mode WiFi de secours

Si la connexion réseau d'entreprise tombe, la passerelle expose automatiquement un point d'accès WiFi local. Les équipes accèdent au dashboard depuis un téléphone ou une tablette — sans dépendance externe.

💾

Persistance locale

Seuils paramétrés, journal système, archives CSV, configuration site — tout est persisté localement. Une mise à jour logicielle ne réécrase jamais les configurations calibrées de votre site.

Surveillance de la surveillance

Un watchdog réseau qui s'auto-vérifie.

Surveiller une installation, c'est bien. Garantir que la surveillance fonctionne, c'est mieux. Le watchdog réseau intégré teste en continu la chaîne de bout en bout — automate, passerelle, serveur, accès distant — et alerte si un maillon défaille.

Ce que le watchdog vérifie.

  • Mot de vie de l'automate de pilotage (heartbeat)
  • Réponse Modbus / OPC-UA sur les registres clés
  • Connectivité Internet vers le réseau opérateur
  • Disponibilité du tunnel d'accès distant sécurisé
  • Espace disque, température processeur, charge serveur

Ce qu'il déclenche en cas d'écart.

  • Alerte instantanée dans le journal du dashboard
  • Notification email / SMS aux personnes habilitées
  • Bascule automatique en mode WiFi de secours si pertinent
  • Trace horodatée pour analyse a posteriori
  • Diagnostic accessible via endpoint API dédié
Mise en place sur site

De la commande au pilotage opérationnel.

Après signature, la mise en place s'organise en cinq phases distinctes. Chaque phase fait l'objet d'un suivi conjoint avec votre équipe de production et de maintenance — pas de boîte noire technique.

Phase A — Préparation matériel et configuration usine

Préparation de la passerelle locale, configuration logicielle initiale, paramétrage des seuils par défaut sur la base du plan de mesurage validé à l'audit. Aucune intervention sur votre site à ce stade.

Phase B — Installation terrain et raccordement

Pose de l'instrumentation complémentaire si nécessaire, raccordement de la passerelle au réseau local, configuration de l'accès distant sécurisé. Intervention coordonnée avec votre maintenance.

Phase C — Mise en service et calage

Validation des remontées en conditions réelles, calage des seuils sur les premières journées d'exploitation, suppression des fausses alertes, ajustement des indicateurs métier avec vos équipes.

Phase D — Formation et transmission

Formation des trois profils utilisateurs (direction, production, maintenance) à la lecture du dashboard, à l'interprétation des alertes et à l'usage de l'API si pertinent. Remise de la documentation.

Phase E — Suivi mensuel les premiers mois

Suivi rapproché les six premiers mois : ajustement des seuils, ajout d'indicateurs complémentaires, intervention sur les premières dérives détectées. Ensuite passage en rythme trimestriel.

Pourquoi cette architecture fonctionne

Une chaîne de bout en bout, sans dépendance critique.

L'efficacité de la méthode tient à un principe simple : la chaîne complète, du capteur jusqu'au dashboard, doit pouvoir fonctionner sans dépendance externe critique. Cloud en panne, opérateur télécom indisponible, supervision constructeur déconnectée — votre pilotage reste opérationnel.

Autonomie locale

Le serveur de pilotage fonctionne en autonomie sur site. Internet n'est requis que pour l'accès distant et la synchronisation cloud — pas pour le pilotage de base.

Protocoles ouverts

Modbus TCP, OPC-UA, LoRaWAN — aucun protocole propriétaire imposé. Vous pouvez changer de prestataire sans réinvestir dans l'infrastructure.

Données souveraines

Hébergement en France. Aucun transfert vers des juridictions tierces. Conformité RGPD native. Vos données ne servent à entraîner aucun modèle externe.

Voir en vrai

Une démonstration personnalisée
en visioconférence — 30 minutes.

Nous vous projetons un dashboard en fonctionnement, sur un cas anonymisé. Vous voyez les écrans, l'API, les modes dégradés. Vous posez vos questions techniques.