L’informatique de la chaîne d’approvisionnement sans souveraineté des données

Les systèmes logistiques signalent un statut sans que la propriété des données et leur qualité ne soient clarifiées tout au long de la chaîne d’approvisionnement. Pour les DSI et les CDO, cela devient une question de pilotage et de responsabilité qui dépasse les interfaces et implique les fournisseurs ainsi que les prestataires logistiques tiers (3PL). Qui contrôle les données de statut contrôle également les risques opérationnels, la capacité d’audit et la fiabilité des processus de planification et de prévision.

À lire aussiRèglement européen sur les données : sécuriser la maîtrise des données et les processus  /  Géopolitique et rupture des chaînes d’approvisionnement : les DSI sous pression

Où la maîtrise des données se brise dans la chaîne logistique

La maîtrise des données se brise là où la propriété et la responsabilité des systèmes divergent. L’expéditeur pilote la commande, le transporteur le statut de transport, l’entrepôt le stock et le destinataire la réception des marchandises. Chacun génère un statut, souvent sans définition commune de qui détient le jeu de données principal et qui peut valider les corrections.

Les ruptures surviennent aux points de transfert entre systèmes internes et externes. Dès qu’un 3PL, un transporteur ou un portail fournisseur définit un statut, l’information quitte l’espace de contrôle interne. La DSI observe alors des événements pertinents sur le plan opérationnel, mais dont l’origine, la logique de modification et les règles de suppression échappent à sa gouvernance.

Sans propriété claire des données, la gestion parallèle s’installe. Les services métiers créent des listes Excel, des canaux de messagerie et des vues de suivi parallèles, car le système principal ne reflète pas de manière fiable le statut. Résultat : trois vérités différentes. L’ERP affiche un statut, la logistique en utilise un autre et le contrôle de gestion en calcule un troisième.

Données de référence, données d’événements et limites des systèmes

Les services informatiques et les métiers doivent distinguer les données de référence des données d’événements. Les données de base concernant les matériaux, les partenaires, les sites et les emballages forment le cadre de référence stable. Les données d’événements décrivent les mouvements et les changements d’état le long de la chaîne. Qui les mélange sans limites de domaine claires transforme les corrections de statut en problèmes de données de référence et vice versa.

Les limites des systèmes ne suivent que rarement les responsabilités organisationnelles. Un système de gestion d’entrepôt peut gérer les stocks, tandis que les événements de transport et de suivi proviennent des portails des transporteurs et la commande reste dans l’ERP. Sans modèle d’objet canonique pour l’expédition, l’unité de manutention et les étapes clés, il reste flou quel système définit le statut principal en cas de conflit.

Les normes sectorielles pour les événements de la chaîne logistique favorisent l’interopérabilité, mais ne remplacent pas la propriété des données. La norme GS1 EPCIS 2.0 (Electronic Product Code Information Services, ratifiée en juin 2022) définit les événements de visibilité avec les dimensions What, When, Where, Why et How, ainsi que des types d’événements comme ObjectEvent, AggregationEvent, TransformationEvent, TransactionEvent et AssociationEvent. Le vocabulaire métier de base (CBV) 2.0 qui l’accompagne fournit des valeurs uniformes pour les étapes commerciales et les dispositions. La directive d’implémentation EPCIS et CBV 2.0 de GS1 (mars 2023) sépare clairement les données d’événements de visibilité des données de référence et des données de transaction. Qui utilise des modèles d’événements proches d’EPCIS gagne en comparabilité entre partenaires. Reste ouverte la question de savoir qui vérifie la qualité des événements, qui élimine les doublons et qui déclenche le processus de correction en cas de statut contradictoire.

Les intégrations échouent souvent en raison d’hypothèses implicites concernant les horodatages, les fuseaux horaires, les codes de lieu et les codes de statut. Un « livré » d’un transporteur n’est pas équivalent à une réception de marchandises enregistrée dans l’ERP. Sans règles de mappage et sans propriété sémantique, toute indication de statut devient une question d’interprétation plutôt qu’une base de pilotage.

Contrats : qui est responsable des données de statut erronées ?

Des données de statut erronées ouvrent une brèche contractuelle et concernent autant les achats, le service juridique que l’informatique. Les accords de niveau de service (SLA) régissent souvent les délais, les créneaux de collecte et les cas de dommages, mais rarement la qualité et la fiabilité des messages de statut. Si un système indique « livré » alors que la marchandise est absente, la question de la responsabilité, de la preuve et de l’obligation de correction se pose immédiatement.

Les contrats avec les fournisseurs et les 3PL nécessitent une clause dédiée aux données avec des rôles définis. Il convient de préciser le système principal par objet, les champs obligatoires, la fréquence de mise à jour, les délais de correction et les voies d’escalade. Sont également pertinents l’archivage, les droits d’accès aux informations et l’obligation de consigner les changements de statut avec leur cause et leur horodatage de manière traçable.

La responsabilité ne s’applique que si les erreurs sont mesurables et attribuables. Sans métriques de qualité convenues, un « statut erroné » reste une question d’opinion. Les modèles de contrats types spécifiques à la qualité des données de statut dans les partenariats logistiques sont rarement disponibles auprès des associations sectorielles. Pour orienter les responsabilités et l’utilisation des données, les conditions contractuelles types non contraignantes (Model Contractual Terms) de la Commission européenne dans le projet de recommandation de novembre 2025 sur l’Acte sur les données, notamment pour le partage volontaire de données entre entreprises, peuvent servir de référence. Les partenaires doivent néanmoins définir au cas par cas les métriques de qualité pour les événements erronés, les mises à jour tardives et les statuts contradictoires dans les SLA et les clauses dédiées aux données.

Sur le plan juridique et opérationnel, la charge de la preuve et l’accès aux systèmes divergent souvent. Le donneur d’ordre assume le risque de pilotage, tandis que le partenaire détient les données brutes. C’est pourquoi les DSI et les CDO doivent clarifier avec les achats et le service juridique quels droits sur les données s’appliquent en cas de perturbation et qui obtient un accès d’audit aux historiques d’événements.

Exigences minimales pour l’architecture d’intégration

L’architecture d’intégration doit garantir la propriété technique et aller au-delà de la simple mise à disposition d’interfaces. Il est indispensable de disposer au minimum d’un modèle de domaine canonique pour les commandes, les expéditions, les stocks et les événements, ainsi que d’un système de référence clair pour chaque objet. S’y ajoutent l’idempotence, la traçabilité et la possibilité de corriger les statuts sous forme de nouveaux événements plutôt que par des écrasements silencieux.

Les connexions partenaires nécessitent des contrats d’interface contraignants. Les spécifications API ou EDI doivent définir les codes de statut, les attributs obligatoires, les codes d’erreur et la logique de répétition. La directive d’implémentation GS1 relative à EPCIS et CBV (version 2.0, mars 2023) décrit comment les systèmes de visibilité s’intègrent dans des paysages IT typiques, quels modèles de chorégraphie régissent l’échange d’événements et quelles étapes de validation garantissent l’interopérabilité. La recommandation VDA 4998 (juin 2021) complète les processus EDI établis par un modèle de données et des API REST pour le suivi des transports dans la chaîne logistique automobile. Sans versionnage et sans processus de recette, chaque intégration partenaire reste un cas particulier.

L’observabilité fait partie de l’équipement minimal. Les événements doivent pouvoir être vérifiés en termes de complétude, d’ordre, de latence et de cohérence. Les alertes ne doivent pas intervenir uniquement lorsque le client se plaint. Un moniteur d’intégration qui met en évidence les jalons manquants et les sauts de statut constitue à la fois un outil de pilotage et une protection juridique.

La classification des données et la protection des accès font partie intégrante de l’architecture et sont conçues dès le départ. Les données de statut contiennent souvent des informations sensibles sur les partenaires, les quantités et les emplacements, dont l’importance est cruciale pour la conformité et la compétitivité. Les rôles, la finalité d’utilisation et la journalisation doivent être définis avant la mise en production de l’interface.

Ensemble de KPI à partager entre achats et IT

Le pilotage ne fonctionne que si les services achats et IT partagent les mêmes indicateurs. Les valeurs de disponibilité purement techniques ne suffisent pas, pas plus que la ponctualité de livraison commerciale. Il est nécessaire de disposer d’un ensemble commun intégrant la qualité des données, l’impact sur les processus et le respect des contrats.

Au niveau des données, comptent la complétude des champs obligatoires, le taux d’incohérences de statut, le taux de corrections et la latence des événements jusqu’à leur visibilité dans le système principal. Au niveau des processus, comptent la planification des réceptions de marchandises, les interventions manuelles et les cas d’escalade dus aux lacunes de statut. Au niveau contractuel, comptent le respect des obligations de mise à jour et les temps de correction vérifiables des partenaires.

La gouvernance doit garantir la propriété au quotidien. Un comité commun réunissant IT, achats, logistique et juridique définit les seuils, décide des validations partenaires et évalue les erreurs de données récurrentes comme un risque fournisseur. La qualité des statuts devient ainsi un élément de l’évaluation des partenaires et du plan d’intégration.

Pour le DSI et le CDO, la conclusion est claire : une IT de la supply chain sans maîtrise des données reste une visibilité coûteuse sans capacité de pilotage. Quiconque ne traite pas l’ownership, les contrats, les normes minimales d’architecture et les KPI partagés comme un programme unique finance des intégrations qui se contentent de signaler des statuts tout en laissant les responsabilités en suspens.

Foire aux questions

Source de l’image : générée par IA (juillet 2026)

Traduit de l’original allemand par intelligence artificielle. La version allemande fait foi.