Le jumeau numérique est souvent présenté comme une superbe usine en 3D. Les machines changent de couleur en temps réel et tout semble synchronisé à la seconde. Ma première question comme directeur TI est plus simple : quelle décision est-ce que cette représentation aide à prendre?

Un jumeau utile relie quatre choses : une identité d’actif, des observations datées, un modèle de comportement et une décision. Les capteurs transmettent par une passerelle ou un broker. Un service valide l’unité, l’heure et la qualité, puis stocke la série temporelle. Le modèle courant associe chaque mesure au bon équipement et estime ce qui n’est pas directement observable.

capteurs/ERP → passerelle → file d'événements → validation
             → historique temporel → état courant → modèle/simulation
             → scénario comparé → décision → changement terrain
                                      ↑            ↓
                                      └── mesure du résultat

Prenons un entrepôt fictif qui veut réduire les déplacements pendant la préparation. Le modèle n’a pas besoin de reproduire la couleur des murs. Il lui faut emplacements, dimensions, commandes, temps de prise, vitesse des chariots et files aux zones d’emballage. Une simulation à événements discrets avance d’un événement au suivant : arrivée d’une commande, fin d’un déplacement, début d’une file.

à chaque événement le plus proche
    avancer l'horloge simulée
    mettre à jour l'état de la ressource
    planifier les prochains déplacements ou fins de tâche
    mesurer distance, attente et débit

Je compare le plan actuel à deux nouvelles dispositions sur les mêmes commandes historiques, puis je répète avec des pointes et absences. Le résultat est une distribution : médiane et pire journée raisonnable, pas un temps unique. Avant de déplacer une étagère, le modèle doit reproduire assez bien une semaine réelle; sinon ses paramètres sont recalibrés.

Le lien avec le terrain vieillit

Un capteur peut cesser de transmettre, changer d’unité ou être installé sur le mauvais actif. Une opération manuelle hors workflow ne remonte pas. L’état courant conserve donc pour chaque valeur :

Champ	Exemple
actif	CHARIOT-17
valeur	38,4 °C
heure de mesure	10:14:03
heure de réception	10:14:06
qualité	valide / estimée / périmée
source/version	capteur-T2 / calibration-4

Une règle refuse une donnée impossible, mais ne la remplace pas silencieusement par zéro. Si la température est vieille de deux jours, l’écran affiche périmée et la simulation utilise une hypothèse identifiée. Les horloges sont synchronisées; un événement arrivé en retard s’insère dans l’historique sans faire revenir la machine à un ancien état.

La sécurité mérite une frontière entre observation et commande. Un compte de capteur peut publier pour son actif, pas arrêter toute la ligne. Une modification du modèle ou une commande vers le terrain exige authentification, autorisation, validation de limites et journal. La simulation ne doit jamais pousser automatiquement un paramètre dangereux simplement parce qu’elle prévoit un meilleur débit.

La reprise inclut la file et les paramètres du modèle. Après une panne, le système rejoue les événements par identifiant, reconstruit l’état et vérifie le dernier checkpoint. Un doublon ne doit pas compter deux commandes. La 3D, si elle existe, est une vue de cet état et peut être régénérée; elle n’est pas la source de vérité.

Je commencerais avec une décision mensuelle, un tableau et un modèle calibré, puis j’ajouterais une fréquence ou une visualisation seulement si elle améliore le choix. La pratique est d’afficher fraîcheur, incertitude et version avec chaque résultat. Un jumeau devient utile lorsqu’on peut expliquer où il diffère du terrain et comment cette différence limite la décision.