Dès qu’un passeport numérique de produit se concrétise, le service informatique pose une question avant toutes les autres : quels sont les systèmes auxquels la plateforme doit avoir accès ? C’est la bonne question, car elle implique des identifiants d’accès, des autorisations de pare-feu et un dispositif de sécurité dont quelqu’un doit assumer la responsabilité.
Notre réponse est concise : aucun. Tous les systèmes qui fournissent des données au passeport se trouvent du côté source et y restent. Transpareo est exclusivement un destinataire en bout de chaîne ; les flux de données convergent unidirectionnellement vers la plateforme. Cet article retrace ces flux : ce que chaque système fournit, quelles règles s’appliquent à chaque flux et ce qui est renvoyé en guise de confirmation.
Ce que chaque système apporte au passeport
Les données d’un passeport proviennent rarement d’un seul système. Dans la pratique, elles se répartissent entre une poignée de catégories de systèmes, dont chacune ne contribue qu’à quelques champs :
- ERP: identité de l’article, matériaux, fournisseurs et origine, référence à la commande et au lot, quantités. Des données de base stables qui changent rarement.
- MES: historique de production, attribution de série et de lot, certificats de qualité, traçabilité. Données d’événements, liées à un moment précis.
- APS: moments de production et affectation des ressources. Rarement directement pertinentes pour le passeport ; les informations essentielles proviennent généralement du MES.
- PLM: composition, nomenclatures, réparabilité, pièces de rechange, états d’avancement de la conception. Au regard des exigences du règlement sur l’écoconception, il s’agit de la source la plus complète.
- PIM - Descriptions, images, consignes d’entretien et d’utilisation, versions linguistiques. Les contenus destinés aux consommateurs.
- IoT - Données d’état et d’utilisation issues de la phase d’utilisation. Ne concernent que certains groupes de produits, comme les batteries.
- CRM - Historique des services et des réparations de chaque client. Il s’agit en principe de données à caractère personnel, qui n’ont donc pas leur place dans un passeport public.
La coque d’administration se situe au-dessus des systèmes, et non à leurs côtés
Une distinction est plus importante que toutes les autres : l’Asset Administration Shell ne se situe pas ## à côté del’ERP,## duMES et du PIM, mais au-dessus d’eux. Elle ne génère pas de données, mais encapsule les données existantes dans des sous-modèles interopérables. Pour la connexion à Transpareo, cela signifie : Une AAS est un format de livraison pratique, mais non indispensable. Ceux qui l’utilisent dérivent le paquet de données de leurs sous-modèles ; ceux qui ne l’utilisent pas fournissent les mêmes champs par d’autres moyens. Les raisons pour lesquelles nous considérons néanmoins l’Asset Administration Shell comme une excellente base sont exposées dans l’article consacré à l’AAS.
Cinq règles qui s’appliquent à chaque flux
Direction. Toutes les flèches pointent vers la plateforme. Aucun système source n’est interrogé par Transpareo, et Transpareo ne dispose d’aucun identifiant d’accès aux systèmes ERP, MES, PIM ou PLM.
Il n’y a aucune connexion vers vos systèmes qu’il faudrait sécuriser, car elle n’existe tout simplement pas.
Déclencheur. La transmission est toujours déclenchée côté source - par le fabricant lui-même, son middleware ou un prestataire mandaté. La plateforme attend ; elle ne va pas chercher les données.
Limitation de l’utilisation. Seul le sous-ensemble nécessaire au « Pass » est transmis, et non l’ensemble des données du système source. Le « Pass » n’a besoin que de quelques champs de chaque système ; tout le reste reste où il est.
Validation. Le choix, le volume et le moment de chaque envoi sont déterminés par le côté source. Transpareo ne peut pas recevoir plus que ce qui lui a été fourni.
Autorisations. Les actions autorisées sur la plateforme avec les données fournies sont régies par des justificatifs d’accès désignés : des droits minimaux, et tout ce qui n’est pas expressément autorisé reste interdit. Ces règles s’appliquent au niveau de la plateforme, jamais de manière rétroactive sur la source.
Seuls les accusés de réception sont renvoyés
Un canal de ## retourest indispensable, mais il ne transporte pas de données, seulement des réponses : l’URL DPP ou le lien numérique GS1, l’identifiant de version, le statut de publication et les messages de validation. Pour la page source, ces retours d’information sont précieux, car la référence de validation peut être enregistrée directement dans l’ERP ou le PIM, au niveau de l’article. Il ne s’agit pas d’un accès. Ce sont les accusés de réception d’une livraison reçue.
Trois modèles qui ont fait leurs preuves dans la pratique
- Directement depuis le système principal. L’ERP ou le PLM effectue une transmission via un connecteur. Une solution simple et pertinente lorsqu’une source de données domine clairement.
- Via une couche d’agrégation. Un middleware ou une plateforme iPaaS rassemble les champs ERP, MES et PIM et fournit un ensemble de données. C’est le cas de figure habituel dès lors que plusieurs sources sont impliquées.
- Via des sous-modèles AAS. La couche d’administration est déjà en service, et le paquet est dérivé de ses sous-modèles. Avantageux dans les environnements Industrie 4.0.
Nous avons détaillé dans le guide pratique consacré à l’interfaçage ERP quel modèle convient à quel environnement système et comment mener à bien un tel projet en deux semaines au lieu de trois mois.
Ce que Transpareo n’est délibérément pas
Ce n’est pas un deuxième « système d’enregistrement ». La plateforme conserve l’enregistrement du passeport et son historique de versions inaltérable, et non les données d’exploitation du fabricant. Les corrections apportées dans l’ERP sont répercutées dans le Pass via une nouvelle livraison - sous la forme d’une nouvelle version traçable, et non d’une modification silencieuse du stock. Pour savoir comment cette chaîne de versions est signée et devient vérifiable par tous, consultez l’article consacré aux signatures et aux certificats.
Il ne vous reste donc que peu d’éléments à vérifier dans le cadre de votre dispositif de sécurité, et c’est précisément le but recherché. Vous n’avez aucun identifiant d’accès à communiquer, aucune ouverture de pare-feu vers l’intérieur et aucun système tiers disposant de droits de lecture dans votre ERP.
Le véritable travail du projet se concentre désormais sur ce qui est essentiel : décider quels champs doivent figurer dans le passeport, et non déterminer qui est autorisé à se connecter où.
Questions concernant cet article
Transpareo a-t-il besoin d'accéder à notre ERP ou à un autre système ?
Non. Chaque système qui fournit des données se trouve côté source et y reste, et Transpareo ne dispose d’aucun identifiant d’accès à l’ERP, au MES, au PIM ou au PLM. Il n’y a aucune connexion à vos systèmes qu’il faudrait sécuriser, car elle n’existe tout simplement pas. Pour votre stratégie de sécurité, il n’est donc pas nécessaire de communiquer des identifiants d’accès, de créer une ouverture vers l’intérieur ni de vérifier qu’un système tiers dispose de droits de lecture dans votre ERP.
Qui déclenche une livraison, et à quelle fréquence ?
Toujours la source. La transmission est déclenchée par le fabricant lui-même, son middleware ou un prestataire mandaté ; la plateforme n’attend jamais et ne va jamais chercher les données. C’est la source qui détermine le choix, le contenu et le moment de chaque envoi, raison pour laquelle Transpareo ne peut pas recevoir plus que ce qui lui a été transmis. C’est vous qui déterminez la fréquence de vos livraisons : les données de base stables changent rarement, tandis que les événements de production surviennent au fur et à mesure qu’ils se présentent.
Avez-vous besoin d'un « shell » d'administration pour cela ?
Non. La « coque administrative » ne vient pas s’ajouter à l’ERP, au MES et au PIM, mais les chapeaute ; elle ne génère pas de données propres, mais encapsule les données existantes dans des sous-modèles interopérables. Il s’agit donc d’un format de livraison pratique, mais non indispensable. Ceux qui l’utilisent dérivent le paquet de données à partir de ses sous-modèles. Ceux qui ne l’utilisent pas fournissent les mêmes champs par un autre moyen, soit directement depuis le système maître, soit via une couche d’agrégation.
Par quel système allons-nous commencer ?
Au regard des exigences du règlement sur l’écoconception, le PLM constitue la source unique la plus complète : c’est là que se trouvent la composition, les nomenclatures, la réparabilité, les pièces de rechange et les versions de conception. L’ERP gère l’identité des articles, les matériaux, les fournisseurs et l’origine ; le PIM, les textes et images destinés aux consommateurs ; et le MES, les événements liés à la production et à la traçabilité. La plupart des fiches techniques ne nécessitent que quelques champs de chaque système. Commencez par les champs obligatoires les plus nombreux, puis complétez le reste progressivement.
Les données clients issues du CRM sont-elles enregistrées dans le passeport ?
Non. L’historique des interventions et des réparations de chaque client est, par nature, à caractère personnel et n’a donc pas sa place dans un passeport public. Le CRM est la seule catégorie de système de cette liste qui en soit totalement exclue. Les événements liés aux réparations et au cycle de vie peuvent néanmoins être consignés, mais en tant qu’événements associés au produit, et non à une personne identifiée.
Quelles sont les informations renvoyées par la plateforme ?
Des accusés de réception, pas des données. Le canal de retour transmet l’adresse DPP ou le GS1 Digital Link, l’identifiant de version, le statut de publication et les messages de validation. Il est utile de conserver ces retours d’information, car la référence Pass peut ensuite être associée directement à l’article dans le système ERP ou PIM. Il ne s’agit pas d’un accès, mais de l’accusé de réception d’une livraison reçue.
Que se passe-t-il lorsqu'une valeur est corrigée dans l'ERP ?
La correction est intégrée au Pass via une nouvelle livraison et donne lieu à une nouvelle version traçable, et non à une modification silencieuse au sein du stock. Chaque version antérieure reste accessible et vérifiable, et c’est précisément ce qui rend l’historique précieux pour un audit. La manière dont cette chaîne de versions est signée et devient vérifiable par tous est décrite dans la section « Signatures et certificats » du DPP.
Transpareo va-t-il devenir un deuxième « système de référence » ?
Non, et c’est tout à fait intentionnel. La plateforme conserve l’ensemble des données du Pass et l’historique de ses versions, qui ne peut être modifié, mais pas vos données d’exploitation ; vos systèmes restent la référence pour tout ce qui leur appartient. Ainsi, le travail sur le projet reste là où il doit être : il s’agit de décider quels champs doivent figurer dans le « Pass », plutôt que de se demander qui est autorisé à se connecter où.
