Le digital twin est présenté comme le graal de l'industrie 4.0. Pourtant la majorité des projets de jumeau numérique déçoivent, non pas par manque de technologie, mais par manque de données produit fiables. Au cœur du problème : une Bill of Materials fragmentée entre PLM, ERP, MES et fichiers Excel.
Digital twin : rappel express
Inutile de refaire la pédagogie du jumeau numérique : réplique virtuelle d'un produit, d'un processus ou d'un système, synchronisée avec son homologue physique tout au long du cycle de vie. Le concept, formalisé en 2002 par Michael Grieves dans un contexte PLM et baptisé par John Vickers de la NASA, est aujourd'hui un marché de masse : environ 24,5 milliards de dollars en 2025, avec près de 385 milliards projetés d'ici 2034 (Fortune Business Insights).
Les promesses sont connues : maintenance prédictive (environ 31 % du marché), validation virtuelle, accès instantané aux configurations as-built et as-maintained, boucle de retour terrain vers le bureau d'études, support à l'après-vente. Ce qui mérite l'attention, c'est moins la liste de ces cas d'usage que leur dénominateur commun : tous supposent de connaître avec certitude la composition exacte du produit physique.
La valeur d'un digital twin ne se joue ni dans le moteur de simulation, ni dans la couche de visualisation, mais dans la donnée de structure produit qui l'alimente : la BoM.
La BoM, colonne vertébrale du jumeau numérique
La nomenclature produit est la liste structurée et hiérarchisée de tous les composants, sous-ensembles et matières qui constituent un produit. C'est le squelette informationnel sur lequel viennent se greffer toutes les autres données : géométrie CAO, exigences, données de fabrication, historique de maintenance, données capteurs.
Mais parler de « la » BoM au singulier est déjà une simplification trompeuse. Dans la réalité industrielle, un même produit est décrit par plusieurs nomenclatures, chacune portée par un système et un métier différents.
Un jumeau digne de ce nom doit pouvoir naviguer entre ces vues et les réconcilier : partir d'une alerte capteur sur un composant en exploitation, remonter à sa référence dans la sBOM, identifier la définition d'ingénierie correspondante dans l'eBOM, retrouver le lot de fabrication dans la mBOM. C'est ce qu'on appelle la continuité numérique, le digital thread. Et c'est exactement là que le bât blesse.
Une donnée produit éclatée entre quatre mondes
Demandez à n'importe quel directeur industriel, responsable PLM ou responsable méthodes : la fragmentation des données produit est le problème quotidien de toutes les entreprises industrielles, quelle que soit leur taille.
Chacun de ces systèmes a été conçu pour un métier, avec son modèle de données, sa granularité et son cycle de vie. Aucun n'a été conçu pour offrir une vue unifiée du produit.
Les symptômes que tout industriel reconnaîtra
Le même composant existe sous trois références différentes selon le système. La mBOM a divergé de l'eBOM au fil des modifications, sans que personne ne sache exactement où. La configuration réelle d'un exemplaire livré il y a cinq ans n'est reconstituable qu'en croisant manuellement l'ERP, des rapports de production et les souvenirs d'un ancien de l'atelier. Une analyse d'impact du type « quels produits livrés contiennent ce composant défectueux ? » mobilise trois personnes pendant deux semaines.
Les ingénieurs consacrent environ un tiers de leur temps à des tâches sans valeur ajoutée, dont 20 % passés à travailler sur des informations obsolètes, avec les reprises et les retards que cela implique (Tech-Clarity).
Le McKinsey Global Institute estimait déjà en 2012 que les travailleurs du savoir passent près de 20 % de leur temps, soit une journée par semaine, à chercher et rassembler de l'information. C'est ce coût diffus et rarement mesuré que la fragmentation des nomenclatures fait peser sur toute l'organisation.
Pourquoi un digital twin sans BoM fiable est aveugle
Un jumeau qui ne reflète pas la réalité
Alimenté par l'eBOM du PLM, le jumeau représente le produit tel que conçu, pas tel que fabriqué, encore moins tel qu'il existe aujourd'hui après dix ans de maintenance et de rétrofits. L'écart entre le modèle virtuel et la réalité physique s'appelle le drift de configuration, et il rend le jumeau progressivement inutilisable. Un jumeau qui affiche un composant qui n'est plus monté sur la machine réelle ne vaut guère mieux qu'un plan périmé.
Une maintenance prédictive qui prédit sur du sable
L'algorithme croise des données capteurs avec les caractéristiques des composants : durée de vie théorique, seuils de tolérance, historique de défaillance de la référence. Si la BoM as-maintained est fausse, parce qu'une substitution de pièce lors d'une intervention n'a jamais été enregistrée, l'algorithme raisonne sur le mauvais composant. Les prédictions deviennent au mieux du bruit, au pire des recommandations dangereuses.
Des analyses d'impact impossibles
« Si ce fournisseur fait défaut, quels produits sont touchés ? », « Cette non-conformité concerne quels numéros de série livrés ? », « Quelle est l'empreinte carbone de cette variante ? ». Ces questions exigent de traverser les nomenclatures, de l'article fournisseur dans l'ERP jusqu'aux exemplaires en exploitation. Si les liens entre eBOM, mBOM et sBOM n'existent pas, ou seulement dans des tableaux maintenus à la main, le jumeau est incapable d'y répondre : il voit chaque silo, pas les connexions entre eux.
Un retour sur investissement qui s'évapore
Selon les analyses du secteur, jusqu'à 70 % des projets de digital twin rencontrent des difficultés majeures, la qualité des données, la complexité d'intégration et les lacunes de gouvernance étant citées comme premiers obstacles (Informatica). Le constat dépasse le seul jumeau numérique : Gartner prédit que 60 % des projets d'IA qui ne s'appuient pas sur des données « AI-ready » seront abandonnés d'ici 2026.
Le digital twin sans continuité de la BoM n'est pas un jumeau : c'est un portrait, figé au moment de la conception.
Trois illustrations sectorielles
Trois secteurs, un même verdict : la valeur du jumeau numérique est plafonnée par la qualité du maillon le plus faible de la chaîne de nomenclatures.
Connecter les BoM : l'approche par graphe de connaissances
La tentation historique est le grand projet de migration : tout centraliser dans un PLM unique, ou tout redescendre dans l'ERP. Ces programmes pharaoniques échouent, car ils supposent d'imposer un modèle de données unique à des métiers dont les besoins sont structurellement différents. L'eBOM et la mBOM ne divergent jamais « par erreur » : elles divergent par nature, parce qu'elles décrivent des réalités différentes.
Une approche plus pragmatique gagne du terrain : connecter les nomenclatures là où elles vivent, plutôt que les déplacer. Un graphe de connaissances représente les données sous forme de nœuds (articles, composants, numéros de série, documents, exigences, fournisseurs) et de relations (est composé de, remplace, est fabriqué selon, est monté sur). Contrairement à une base relationnelle classique, il est nativement conçu pour modéliser et parcourir des structures hiérarchiques et des liens transverses, soit exactement la nature d'une BoM.
Couplé à une ontologie, le modèle sémantique qui définit formellement les concepts métier et leurs relations, le graphe réconcilie des référentiels hétérogènes sans les uniformiser : la référence PLM, le code article ERP et la désignation MES d'un même composant deviennent trois attributs d'un même nœud, reliés à leurs contextes respectifs.
- +Une vue produit unifiée sans migration. Le graphe se superpose aux systèmes existants et les fédère, au lieu de les remplacer.
- +Des traversées de BoM instantanées. Remonter d'un numéro de série à son eBOM d'origine, ou descendre d'un composant à tous les exemplaires livrés qui le contiennent, devient une requête de quelques secondes.
- +Une continuité numérique auditable. Chaque lien entre les vues eBOM, mBOM et sBOM est explicite, versionné et traçable, un prérequis dans les industries réglementées.
- +Un socle prêt pour l'IA. Les approches de type Graph-RAG permettent d'interroger la donnée produit en langage naturel avec un contexte relationnel fiable, là où un LLM branché sur des documents non structurés hallucine faute de connaître la structure réelle du produit.
Par où commencer
Inutile de viser d'emblée le jumeau complet de toute la gamme. Les démarches qui réussissent partent d'un cas d'usage douloureux et mesurable : réconcilier eBOM et mBOM sur une ligne de produits, reconstituer les configurations as-built d'une flotte, automatiser les analyses d'impact fournisseur. Le graphe se construit incrémentalement, cas d'usage après cas d'usage, et chaque étape délivre de la valeur sans attendre la fin du programme.
Tant que les nomenclatures restent fragmentées entre PLM, ERP, MES et Excel, le jumeau numérique reste aveugle : il simule un produit qui n'existe pas tout à fait, prédit des pannes sur des composants qui ne sont plus montés, et échoue à répondre aux questions transverses qui justifiaient son existence. Avant d'investir dans le prochain jumeau, posez-vous la seule question qui compte : votre BoM est-elle prête à lui ouvrir les yeux ?
Sources
- Grieves, M. (2016), Origins of the Digital Twin Concept, Florida Institute of Technology.
- Fortune Business Insights (2026), Digital Twin Market Size, Share & Growth Report 2026-2034.
- Informatica, Digital Twins Explained: Data Foundation Guide.
- Gartner (2024), enquête sur la préparation des données pour l'IA.
- Tech-Clarity, Reducing Non-Value Added Work in Engineering.
- McKinsey Global Institute (2012), The Social Economy: Unlocking Value and Productivity Through Social Technologies.