Les obligations de chaîne d’approvisionnement nécessitent une architecture de données

La conformité des chaînes d’approvisionnement ne échoue rarement à cause d’un manque de volonté. Elle échoue parce que les entreprises ne gèrent pas leurs fournisseurs, sites et preuves comme une base de données cohérente.

Le cadre juridique modifie les priorités, pas la tâche des données

La directive européenne sur les chaînes d’approvisionnement (CSDDD) a été considérablement simplifiée en 2026. Selon la version actuelle, elle concerne dans un premier temps les entreprises comptant plus de 5 000 salariés et réalisant plus de 1,5 milliard d’euros de chiffre d’affaires net. Son application débutera le 26 juillet 2029, les États membres devant transposer les dispositions d’ici juillet 2028. Cela réduit temporairement la pression sur de nombreux programmes, mais ne résout aucun problème de données.

En Allemagne, la loi sur le devoir de diligence dans les chaînes d’approvisionnement (Lieferkettensorgfaltspflichtengesetz) reste en vigueur jusqu’à ce que la réglementation européenne soit transposée en droit national. L’obligation de reporting a été politiquement réduite et le BAFA n’accepte actuellement aucun rapport via son portail. Cependant, les analyses de risques, la prévention, les mesures correctives, les mécanismes de réclamation et la documentation restent au cœur des obligations de diligence. Ceux qui n’y voient qu’un projet de reporting construisent une réponse à court terme à un problème de gestion permanent.

Pour de nombreux fournisseurs de taille moyenne, la pression ne provient d’ailleurs pas directement du champ d’application légal. Les grands clients exigent des informations sur la provenance, des évaluations des risques, des certificats et des preuves fiables tout au long de leur propre chaîne d’approvisionnement. Ainsi, la capacité à fournir rapidement et de manière cohérente ces données devient une condition commerciale.

Ceux qui n’y voient qu’un projet de reporting construisent une réponse à court terme à un problème de gestion permanent.

L’écart se situe entre le fichier fournisseurs et la chaîne d’approvisionnement

Un système ERP connaît le fournisseur. Il connaît les factures, les conditions de paiement et souvent l’entité juridique. Cela ne suffit pas pour les obligations de diligence. Sont également pertinents les sites de production, les structures de groupe, les flux de marchandises, les matériaux utilisés, les sous-traitants, les zones à risque et la validité des certificats. Ces informations se trouvent souvent dans les services achats, gestion de la qualité, conformité, durabilité et sur des portails externes. Elles suivent différents identifiants et cycles de mise à jour.

La première décision architecturale est donc la suivante : quelle est l’identité canonique d’un fournisseur ? Un simple numéro de fournisseur joue rarement ce rôle. Un modèle de données doit représenter séparément l’entité juridique, le groupe économique, le site et la relation commerciale. Un groupe peut produire dans plusieurs pays. Un site peut livrer à différentes sociétés clientes. Si ces niveaux sont mélangés, les risques ne peuvent être ni attribués avec précision ni évalués de manière traçable.

Les DSI ne devraient pas créer un fichier parallèle supplémentaire en dehors de l’ERP. Il est plus judicieux de mettre en place un objet fournisseur principal avec un identifiant stable et des relations claires avec l’ERP, les achats, les données produits et les sources de risques. Les données n’ont pas besoin d’être physiquement dans un seul système. L’essentiel est que chaque application référence la même entité et que les modifications soient reprises de manière traçable.

La traçabilité commence par les relations entre les données

L’exigence de transparence jusqu’aux niveaux inférieurs de la chaîne d’approvisionnement incite à adopter un objectif irréaliste : représenter intégralement chaque niveau de sous-traitance. Ni la CSDDD ni le LkSG n’exigent une cartographie exhaustive de toutes les relations commerciales. Le critère est la diligence fondée sur les risques. L’architecture doit donc pouvoir montrer quelles données sont disponibles, quelles hypothèses s’appliquent et pourquoi une entreprise approfondit son examen à un endroit donné.

Pour cela, il faut un modèle relationnel plutôt qu’une simple liste de fournisseurs. Un composant renvoie à des groupes de matériaux. Les groupes de matériaux renvoient à des régions d’origine ou à des sites de production. Les sites sont en relation avec des fournisseurs et des évaluations de risques. S’ajoutent les références temporelles : un certificat était valide au moment de la validation, mais peut aujourd’hui être expiré. Sans date d’effet et versioning, un audit ne produit qu’une collection de fichiers plausibles, mais pas une chaîne de décision prouvable.

Surtout pour les fournisseurs indirects, l’IT doit distinguer les faits confirmés, les déclarations des fournisseurs, les indices externes et les évaluations de risques dérivées. Cette origine de l’information doit figurer dans le modèle de données. Elle détermine si un indicateur peut être considéré comme une preuve fiable ou comme une simple affirmation.

La preuve nécessite un fil de décision inaltérable

Les équipes conformité ne se demandent pas seulement quel risque était connu. Elles doivent montrer qui l’a évalué, quand, quelle mesure a été décidée et si son efficacité a été vérifiée. Cette chaîne ne peut être reconstituée de manière fiable à partir d’e-mails, de présentations et de fichiers dans des lecteurs partagés. Elle nécessite un processus numérique avec une référence claire au fournisseur, au risque, à la décision, aux responsables et aux justificatifs.

Une bonne conception sépare ici les systèmes opérationnels de la logique de preuve. L’ERP reste responsable des commandes et des validations de livraison. Le système d’achat gère les appels d’offres et les contrats. Une plateforme de conformité ou de données rassemble les événements de risque, les contrôles, les mesures et les preuves. Les interfaces ne transmettent que les attributs nécessaires. Cela réduit les erreurs de copie et empêche que des informations sensibles ne se retrouvent de manière incontrôlée dans des listes d’achats ou des outils d’analyse.

L’automatisation est particulièrement utile pour les contrôles récurrents : certificats expirés, champs obligatoires manquants, modifications des données d’entreprise, nouveaux risques par pays ou groupes de produits, et mesures en retard. Elle ne remplace pas l’évaluation. Elle permet aux services métiers de consacrer leur temps aux cas réellement pertinents. Chaque règle automatique doit avoir un propriétaire, une source de données et une procédure documentée pour les fausses alertes.

De nombreux projets échouent en raison d’une mauvaise répartition des responsabilités

L’idée reçue la plus répandue est que la conformité définit les exigences et que l’IT fournit un outil. En réalité, c’est le modèle opérationnel qui détermine la qualité des données. Les achats sont responsables de nombreuses données sources, les services métiers connaissent les produits et les relations avec les fournisseurs, la durabilité évalue les contenus, le juridique définit le cadre, et l’IT est responsable de l’intégration, de l’accès et de la traçabilité. Sans cette répartition, des champs obligatoires sont créés, mais ne sont pas entretenus.

Une deuxième erreur consiste à tenter de nettoyer toutes les données avant le lancement. La qualité des données de référence s’améliore rarement grâce à un projet ponctuel de grande envergure. Il est préférable de prioriser en fonction du risque et du volume d’achat. Pour les relations fournisseurs les plus critiques, des identités contraignantes, des responsables de données et des règles de qualité doivent d’abord être définis. Les modèles obtenus peuvent ensuite être appliqués à d’autres groupes.

Les 90 prochains jours devraient donc produire trois résultats : un modèle de données contraignant pour le fournisseur, le site, la relation et la preuve, une cartographie des systèmes principaux ainsi qu’un pilote pour une catégorie de produits à risque. Le pilote révèle rapidement quelles informations sont réalistement disponibles chez les fournisseurs et où les clauses contractuelles ou les processus doivent être adaptés.

Des données de conformité à un système d’alerte opérationnel précoce

La base de données peut aller au-delà des obligations réglementaires. En reliant de manière cohérente les relations avec les fournisseurs, les sites, les groupes de matériaux et les preuves, les dépendances sont détectées plus tôt. Une panne de production, un risque régional ou un certificat arrivant à expiration sont alors associés à un achat spécifique, une ligne de produits et une responsabilité concrète. Cela améliore les échanges entre les achats, la production et la gestion des risques.

Cependant, l’utilité opérationnelle n’apparaît que si l’architecture est intégrée aux processus de décision. Une évaluation des risques qui disparaît dans un portail séparé après la signature du contrat ne protège ni la capacité d’approvisionnement ni la réputation. Un signal de risque doit atteindre les autorisations d’achat, le développement des fournisseurs et les escalades. L’architecture des données devient ainsi l’élément fédérateur entre la conformité et la gestion.

La simplification réglementaire de 2026 n’est donc pas une raison de reporter la tâche. Elle offre du temps pour une meilleure mise en œuvre. Les DSI devraient en profiter pour transformer des documents épars en une chaîne de données vérifiable. Ceux qui ne commencent qu’en cas de demande client ou d’audit paieront le prix de cette architecture manquante sous la pression du temps.

Foire aux questions

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

Plus d’articles du réseau MBF Media