Un modèle de maturité du jumeau numérique vous donne un langage commun pour situer une initiative de jumeau et savoir ce qu'il faut pour avancer. Ce guide définit six niveaux pratiques, du modèle statique au pilotage autonome en boucle fermée, et liste pour chacun les capacités, l'infrastructure de données et les patterns MQTT nécessaires. Utilisez l'auto-évaluation en fin d'article pour positionner votre projet et planifier l'étape suivante.
Pour les fondamentaux, consultez le guide de la technologie du jumeau numérique.
Pourquoi utiliser un modèle de maturité
Les projets de jumeau s'enlisent souvent parce que les parties prenantes imaginent des points d'arrivée différents. L'exploitation attend un tableau de bord en temps réel, la direction attend de la maintenance prédictive, l'ingénierie attend de l'optimisation automatisée. Un modèle de maturité rend ces différences explicites et les transforme en une séquence. Il évite aussi l'erreur la plus coûteuse : vouloir construire de l'analytique de niveau 4 sur des données de niveau 1.
Plusieurs cadres publiés existent, avec des nombres de niveaux et des noms différents. La version ci-dessous est volontairement pragmatique : chaque niveau est défini par ce que le jumeau sait faire et par l'infrastructure qu'il requiert, pour que vous puissiez la confronter à votre propre système.
Les six niveaux
| Niveau | Nom | Ce que fait le jumeau | Question à laquelle il répond |
|---|---|---|---|
| 0 | Modèle numérique | Représentation statique (CAO, documentation, données nominales) | Qu'est-ce qui a été conçu ? |
| 1 | Descriptif | Affiche l'état en temps réel des actifs | Que se passe-t-il maintenant ? |
| 2 | Diagnostique | Ajoute historique, alertes et contexte | Pourquoi est-ce arrivé ? |
| 3 | Prédictif | Prévoit le comportement à partir de données et de modèles | Que va-t-il se passer ? |
| 4 | Prescriptif | Recommande des actions avec leurs effets attendus | Que devons-nous faire ? |
| 5 | Autonome | Agit sur l'actif dans un cadre défini | Le système peut-il s'en charger seul ? |
Niveau 0 : modèle numérique
Vous disposez de géométries, de plans, de fiches techniques et peut-être de modèles de simulation, mais rien ne les relie à l'actif en fonctionnement. C'est une fondation, pas un échec : le modèle fournit la structure (noms des actifs, hiérarchie, valeurs nominales) à laquelle les niveaux suivants rattacheront les données.
Infrastructure : gestion documentaire et CAO. Étape suivante : s'accorder sur une hiérarchie d'actifs, idéalement selon les niveaux ISA-95, car elle deviendra votre structure de topics.
Niveau 1 : jumeau descriptif
Les données en temps réel remontent automatiquement des actifs vers le jumeau, qui affiche l'état actuel : en marche ou à l'arrêt, valeurs clés, alarmes. Il s'agit souvent d'une vue 3D ou d'un tableau de bord que les gens consultent réellement.
Infrastructure : des passerelles edge qui lisent les automates ou les capteurs, un broker MQTT et un visualiseur. Les patterns MQTT essentiels sont :
- Une hiérarchie de topics cohérente, par exemple
site/area/line/cell/asset/state. - Des messages d'état retained, pour que les visualiseurs affichent les valeurs actuelles dès leur connexion.
- Des messages Last Will, pour que le jumeau sache quand une passerelle se déconnecte.
# La passerelle enregistre un Last Will retained pour que le jumeau sache quand elle se déconnecte
mosquitto_sub -h broker.connectmq.com -p 1883 -i dtm-6r2-gw \
--will-topic "connectmq/demo/dtm-6r2/site1/line1/status" --will-payload offline \
--will-retain --will-qos 1 -t "connectmq/demo/dtm-6r2/site1/line1/cmd/#"
Vous pouvez prototyper ce niveau sur le serveur MQTT public gratuit avec des données de démonstration, jamais avec des données de production. Le jumeau numérique de bras robotisé est un exemple complet de niveau 1 avec une vue 3D.
Niveau 2 : jumeau diagnostique
Le jumeau a désormais de la mémoire. L'historique en séries temporelles permet aux ingénieurs de remonter au moment d'une panne, de corréler des signaux et de comparer des équipes. Des alertes à seuil préviennent les personnes concernées lorsque des valeurs sortent de leur plage normale, et un contexte tel que l'ordre de fabrication, la recette ou l'opérateur est rattaché aux données.
Infrastructure : un historian ou une base de séries temporelles alimentée par un abonné MQTT, des règles d'alerte, et du contexte issu du MES ou de l'ERP publié dans le même namespace. La qualité des données commence à compter : horodatage à la source, unités dans les payloads et détection des données périmées.
Voici un petit abonné qui écrit chaque message d'état dans un fichier SQLite local à des fins de diagnostic. En production, vous utiliseriez une véritable base de séries temporelles, mais le pattern est identique.
import json
import sqlite3
import time
import paho.mqtt.client as mqtt
ROOT = "connectmq/demo/dtm-6r2"
db = sqlite3.connect("history.db", check_same_thread=False)
db.execute("CREATE TABLE IF NOT EXISTS samples (ts REAL, topic TEXT, payload TEXT)")
def on_connect(client, userdata, flags, reason_code, properties):
client.subscribe(f"{ROOT}/#", qos=1)
def on_message(client, userdata, msg):
try:
json.loads(msg.payload)
except ValueError:
return # ignorer les messages non JSON, comme les chaînes de statut
db.execute("INSERT INTO samples VALUES (?, ?, ?)",
(time.time(), msg.topic, msg.payload.decode()))
db.commit()
client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id="dtm-6r2-historian")
client.on_connect = on_connect
client.on_message = on_message
client.connect("broker.connectmq.com", 1883)
client.loop_forever()
Pour les alertes à ce niveau, vous n'aurez peut-être besoin d'aucun code : le portail ConnectMQ inclut des règles d'alerte à seuil et un journal des alertes, ce qui couvre le besoin courant « préviens-moi quand la température dépasse X » pendant les premiers déploiements.
Niveau 3 : jumeau prédictif
Avec suffisamment d'historique propre, le jumeau fait des prévisions : durée de vie résiduelle d'un composant, dérives qualité probables, demande énergétique pour la prochaine équipe. Les modèles peuvent être physiques, fondés sur les données ou hybrides.
Infrastructure : extraction de caractéristiques à l'edge pour les signaux à haute fréquence, une plateforme de données où les modèles sont entraînés, et un service d'inférence qui s'abonne aux données en temps réel et republie les prédictions dans le namespace sur leurs propres topics, par exemple .../pump104/predictions/rul. Garder les prédictions sur des topics séparés évite toute confusion avec les mesures. Le guide de la maintenance prédictive par jumeau numérique approfondit le choix des modèles.
C'est à ce niveau que les lacunes de données font le plus mal. Les modèles entraînés sur un historique comportant des intervalles manquants ou des unités incohérentes donnent de mauvais résultats ; c'est pourquoi la rigueur du niveau 2 est payante.
Niveau 4 : jumeau prescriptif
Le jumeau recommande des actions et estime leur effet : ralentir la ligne d'une valeur donnée pour préserver un roulement usé jusqu'à l'arrêt planifié, modifier une consigne pour réduire les rebuts, replanifier un ordre. Les humains continuent d'approuver et d'exécuter.
Infrastructure : une simulation de scénarios pilotée par l'état en temps réel, une logique d'optimisation et un workflow de recommandations et d'approbations. En termes MQTT, les recommandations sont publiées sur des topics auxquels une interface opérateur s'abonne, et les approbations produisent des commandes, ce qui mène naturellement au niveau 5.
Niveau 5 : jumeau autonome
Le jumeau agit directement sur l'actif dans des limites définies, ce qui ferme la boucle. Le périmètre typique est étroit et bien maîtrisé : ajuster une consigne dans une plage, séquencer des pompes pour l'efficacité énergétique, répartir le travail entre des machines en parallèle.
Infrastructure : des topics de commande consommés par des passerelles qui valident chaque requête par rapport aux limites et aux verrouillages, des acquittements qui indiquent ce qui a réellement été appliqué, l'expiration des messages pour que les commandes tardives soient écartées, et une journalisation d'audit complète. Les fonctions de sécurité restent toujours dans l'automate et le système de sécurité, jamais dans le jumeau.
{
"id": "cmd-2026-10-16-0042",
"issued_by": "energy-optimizer",
"target": "site1/utilities/cooling/pump104",
"setpoint": { "rpm": 1350 },
"valid_for_s": 30,
"reason": "chiller load low, reduce pump speed within approved band"
}
MQTT 5 aide ici avec l'expiration des messages, les response topics et les correlation data pour le request/response ; le guide des fonctionnalités MQTT 5 les explique.
Infrastructure par niveau
| Capacité | N1 | N2 | N3 | N4 | N5 |
|---|---|---|---|---|---|
| Hiérarchie de topics et état retained | Requis | Requis | Requis | Requis | Requis |
| TLS et identifiants par client | Recommandé | Requis | Requis | Requis | Requis |
| Historique en séries temporelles | Optionnel | Requis | Requis | Requis | Requis |
| Alertes et données de contexte | Optionnel | Requis | Requis | Requis | Requis |
| Extraction de caractéristiques à l'edge | Optionnel | Optionnel | Souvent requis | Souvent requis | Souvent requis |
| Services de prédiction et de simulation | Non | Non | Requis | Requis | Requis |
| Topics de commande avec acquittements | Non | Non | Non | Pour les actions approuvées | Requis |
| Journalisation d'audit des commandes | Non | Non | Non | Requis | Requis |
Grille d'auto-évaluation
Comptez un point pour chaque affirmation vraie aujourd'hui :
- Chaque actif du périmètre possède un identifiant unique et hiérarchique utilisé dans les topics.
- L'état en temps réel parvient automatiquement au jumeau et est retained pour les nouveaux visualiseurs.
- Le jumeau indique quand des données sont périmées ou qu'une passerelle est hors ligne.
- Au moins trois mois d'historique propre sont stockés avec horodatage à la source et unités.
- Les alertes parviennent aux bonnes personnes et sont journalisées.
- Les prédictions sont publiées séparément des mesures et confrontées à la réalité.
- Les recommandations incluent leur effet attendu et une trace d'approbation.
- Les commandes sont validées, acquittées, expirent si elles arrivent en retard et sont entièrement auditées.
De zéro à deux points, vous êtes au niveau 1 ; de trois à cinq, au niveau 2 ; six, au niveau 3 ; sept, au niveau 4 ; les huit, vous êtes prêt pour des cas d'usage ciblés de niveau 5. Progressez d'un niveau à la fois, et seulement pour des cas d'usage à la valeur claire. Le guide du ROI du jumeau numérique aide à choisir lesquels.
La colonne vertébrale à chaque niveau
Chaque niveau à partir du niveau 1 repose sur la même colonne vertébrale de messagerie, et ses exigences augmentent à mesure que vous montez : plus de clients, une sécurité plus stricte, des commandes qui ne doivent pas être perdues. Commencez sur un broker MQTT managé pour que la colonne vertébrale soit prête pour la rigueur du niveau 5 alors même que vous êtes au niveau 1. ConnectMQ prend en charge les fonctionnalités MQTT 5 comme l'expiration des messages et les response topics, des endpoints TLS et Secure WebSocket, des identifiants liés aux client IDs, et une vue des appareils ISA-95 qui rend visible dans le portail la hiérarchie définie au niveau 0.
Gravissez l'échelle de maturité avec ConnectMQ
Faites fonctionner le niveau 1 sur un broker solide et chaque niveau suivant devient un ajout, pas une reconstruction. Commencez gratuitement sur ConnectMQ avec l'offre Serverless, sans carte bancaire.
Questions fréquentes
Qu'est-ce qu'un modèle de maturité du jumeau numérique ?
C'est un cadre qui décrit les étapes des capacités d'un jumeau, des modèles statiques au pilotage autonome en passant par la supervision en temps réel et la prédiction, ainsi que ce que chaque étape exige.
Quel niveau de maturité viser ?
Visez le niveau le plus bas qui apporte la valeur dont vous avez besoin. Beaucoup d'organisations tirent l'essentiel du bénéfice des niveaux 1 et 2, puis ajoutent la prédiction pour certains actifs critiques.
Peut-on sauter des niveaux ?
Rarement. Les jumeaux prédictifs et prescriptifs dépendent des données en temps réel propres et de l'historique construits aux niveaux 1 et 2 ; sauter des niveaux oblige généralement à reconstruire plus tard.
Le pilotage autonome est-il sûr ?
Il peut l'être lorsque le périmètre est étroit, que les actions sont bornées par des limites validées, que les commandes sont acquittées et auditées, et que les fonctions de sécurité restent dans l'automate et le système de sécurité.
