EUDR et données fournisseurs : structurer la collecte dans l'ERP

Ce guide traite la question concrète des équipes SI, Data/Master Data, Achats, Qualité et Supply Chain : comment structurer la collecte des données fournisseurs EUDR dans l'ERP et dans les référentiels qui l'entourent, sans reconstituer un fichier Excel par acheteur. Vous y trouverez où vit chaque donnée aujourd'hui, pourquoi l'ERP seul ne suffit pas, un modèle de données minimal, le rattachement d'une DDS (Due Diligence Statement, déclaration de diligence raisonnable) à un lot et à une réception, la gestion des versions, l'apport de l'IA (intelligence artificielle), la gouvernance et une checklist opérationnelle.

En bref

De la parcelle au lot, et retour. Le lot existe dans l'ERP, l'origine chez le fournisseur : par défaut, rien ne les relie. Ces trois clés font le lien.

Les données EUDR à collecter et où elles vivent aujourd'hui

L'article 9 du règlement fixe la liste des informations et pièces justificatives à réunir pour chaque produit concerné, et la Commission européenne détaille ce que recouvre la diligence raisonnable. Ramenée à un projet SI, cette liste se traduit en huit blocs de données - qui, dans la plupart des industriels, vivent dans cinq endroits différents.

Le point commun de ces huit blocs : aucun n'est un champ réglementaire nouveau à créer de zéro. Ce sont des attributs d'objets existants - fournisseur, site, article, lot, document - auxquels s'ajoutent deux objets réellement neufs : la géolocalisation et la DDS.

« […] les opérateurs recueillent, organisent et conservent pendant cinq ans à compter de la date de la mise sur le marché des produits en cause, ou de leur exportation, les informations suivantes, accompagnées d’éléments probants, relatives à chaque produit en cause […] »Règlement (UE) 2023/1115, article 9, paragraphe 1 · texte consolidé, EUR-Lex

Pourquoi l'ERP seul ne suffit pas, et ce qu'il faut lui ajouter

L'ERP (Enterprise Resource Planning, progiciel de gestion intégré) est indispensable, mais il a été conçu pour piloter des flux transactionnels : commandes, réceptions, stocks, factures. La conformité EUDR exige autre chose.

Cinq briques doivent donc venir se brancher sur l'ERP, chacune avec un propriétaire et un identifiant clair :

1. Un référentiel d'origine (site et parcelle), capable de stocker des points et des polygones en GeoJSON (RFC 7946) et de les restituer au format attendu par le système d'information EUDR.
2. Un identifiant de matière première EUDR rattaché à l'article, distinct du code NC mais relié à lui, pour dire sans ambiguïté « cet article contient du cacao » ou « cet article est hors périmètre ».
3. Une base documentaire versionnée, avec type de document, émetteur, date d'émission, date d'expiration, statut et responsable.
4. Un référentiel de conformité qui porte la référence de DDS, l'opérateur déclarant et les produits couverts.
5. Un point d'exposition API vers le système d'information EUDR, pour l'envoi et la récupération des références - en sachant que l'API opérateur décrite par la Commission est un service SOAP, donc un objet d'intégration à cadrer avec la DSI.

Pour voir comment une plateforme de données fournisseurs se branche sur l'ERP, lisez Tracklab et votre ERP : le guide de l'intégration.

Modèle de données minimal : six entités et leurs relations

Vous n'avez pas besoin d'un modèle exhaustif pour démarrer. Six entités suffisent à couvrir les exigences de l'article 9 et à rendre le dossier opposable en cas de contrôle.

Trois relations portent tout le dispositif :

• lot ↔ parcelle : c'est la relation qui transforme une donnée d'origine en preuve. Un lot peut couvrir plusieurs parcelles (mélange), une parcelle peut alimenter plusieurs lots.
• lot → document : les preuves de légalité et les attestations sont rattachées à l'objet qu'elles couvrent, pas à un dossier partagé.
• lot → DDS : chaque lot entrant doit pouvoir pointer vers la référence de déclaration qui couvre son origine, à la date d'entrée.

Le socle de données EUDR : trois référentiels, trois objets de flux, deux clés, et la DDS au-dessus. Après le point, le système maître de chaque objet.

Le piège classique consiste à stocker la géolocalisation en pièce jointe d'une fiche fournisseur. Une géométrie n'est pas un document : elle doit être un objet interrogeable, rattachable à des lots, avec une version.

Rattacher une DDS à un lot et à une réception

C'est l'opération la plus mal traitée en pratique : la DDS arrive en PDF, elle est archivée, et personne ne sait plus quels lots elle couvre six mois plus tard. Quatre étapes suffisent.

1. Enregistrer la DDS comme objet. Numéro de référence, opérateur déclarant, date de dépôt, liste des codes NC et des produits couverts, pays d'origine. Le PDF est une pièce jointe de cet objet, pas l'objet.
2. Rattacher la DDS aux lignes produits, c'est-à-dire aux articles de l'ERP et à leur code NC, puis aux lots concernés. Une DDS peut couvrir plusieurs lots et plusieurs livraisons ; un lot entrant ne doit pointer que vers la déclaration en vigueur à sa date d'entrée.
3. Rattacher le lot aux réceptions et aux mouvements. C'est le lien ERP : quelle réception, quelle quantité, quelle unité, quelle date, quel entrepôt.
4. Contrôler la cohérence des quantités. La quantité cumulée des lots rattachés à une DDS ne peut pas dépasser ce que la déclaration couvre, sauf traçabilité de masse documentée.

Ce niveau de détail n'est pas décoratif : c'est ce qui permet à un opérateur en aval de récupérer la référence de DDS et de la conserver, comme le prévoit la logique issue de la modification de 2025. L'identification du lot par l'association GTIN + numéro de lot est une convention éprouvée, décrite par les standards de traçabilité GS1.

Versions et historique documentaire : ce qui doit être historisé

Un dossier de conformité est jugé sur une date : celle de la mise sur le marché. Il faut donc pouvoir démontrer ce que vous saviez à cette date-là. Un fichier écrasé sans historique ne le permet pas.

Trois règles simples rendent cet historique exploitable : jamais d'écrasement (une correction crée une version), une date de validité de début et de fin, un auteur identifié. La conservation attendue est de cinq ans pour la déclaration et les justificatifs. Les preuves à présenter en cas de contrôle sont détaillées dans notre checklist audit EUDR.

Le rôle de l'IA dans l'extraction des données fournisseurs

L'essentiel des données EUDR arrive sous forme de documents non structurés : attestations de non-déforestation, permis, titres fonciers, tableaux de parcelles en PDF ou Excel, certificats avec numéros de lots. L'IA intervient là, et pas ailleurs : transformer ces documents en champs structurés, avec leur provenance et un niveau de confiance.

Trois garde-fous sont non négociables. D'abord, la traçabilité de la source : pour chaque champ extrait, il faut pouvoir remonter au document et à sa page. Ensuite, la validation humaine sur les données qui alimentent une déclaration réglementaire - le règlement (UE) 2024/1689 sur l'IA impose par ailleurs, pour certains usages, des obligations de transparence et de supervision humaine. Enfin, le contrôle à l'écriture : aucune donnée extraite ne doit entrer dans le référentiel sans passer les règles de validation du modèle.

Gouvernance : qui met à jour quoi, à quelle fréquence, avec quels contrôles

Le projet échoue rarement sur la technologie : il échoue sur la propriété des données. Une donnée de conformité sans propriétaire n'est jamais à jour. Voici une répartition qui fonctionne, à adapter à votre organisation.

La discipline qui structure tout cela porte un nom : le MDM (Master Data Management, gestion des données de référence), c'est-à-dire l'ensemble des règles qui définissent qui crée, valide et corrige une donnée partagée. Pour la partie échange, la norme ISO 8000-110:2021 donne un cadre utile sur la qualité des données de référence échangées entre systèmes.

Quatre contrôles, automatisables, suffisent à couvrir l'essentiel : complétude (tous les champs de l'article 9 sont-ils là ?), cohérence (quantités, unités, pays, dates), fraîcheur (documents expirés ou manquants) et unicité (pas de doublon de fournisseur ou de lot d'origine).

Les erreurs fréquentes

1. Traiter l'EUDR comme un projet juridique. Le service Réglementaire rédige la procédure, personne ne crée les champs en ERP, et la collecte reste manuelle.
2. Créer un fichier Excel « EUDR ». Il double le référentiel, diverge en trois mois et ne se rattache à aucun lot.
3. Stocker la géolocalisation en pièce jointe. Une géométrie doit être un objet interrogeable, pas un PDF dans une fiche.
4. Rattacher la DDS au fournisseur plutôt qu'au lot. On ne sait alors quelle déclaration couvre quelle livraison.
5. Laisser les codes NC au niveau HS6. Le classement douanier détermine l'inclusion ; un code incomplet fausse tout le périmètre.
6. Écraser les versions. Sans historique, impossible de démontrer ce qui était valide à la date de mise sur le marché.
7. Automatiser sans validation humaine. Des données extraites par IA non contrôlées finissent dans une déclaration réglementaire.
8. Ne pas nommer de propriétaire de données. Chaque champ doit avoir un owner, un système maître et une fréquence de mise à jour.

Checklist opérationnelle

• Cadrage du modèle
• Les six entités (fournisseur, site, parcelle, lot, document, DDS) sont définies avec leurs identifiants clés.
• Le système maître de chaque champ est arbitré et documenté.
• L'article ERP porte un identifiant de matière première EUDR relié à un code NC complet.

• Collecte et rattachement
• Les fournisseurs critiques sont segmentés et la campagne de collecte passe par un canal dédié.
• Le format géographique attendu (GeoJSON, longitude/latitude, précision des coordonnées) est imposé et contrôlé automatiquement.
• Chaque lot entrant pointe vers ses parcelles d'origine et vers une référence de DDS en vigueur.

• Documents et versions
• La base documentaire gère type, version, émetteur, date d'expiration et statut.
• Aucune donnée n'est écrasée : toute correction crée une version avec auteur et motif.
• La conservation de cinq ans est configurée.

• Extraction et gouvernance
• Les champs extraits par IA sont tracés jusqu'à leur document source.
• Un seuil de confiance déclenche la validation humaine.
• Les quatre contrôles (complétude, cohérence, fraîcheur, unicité) tournent régulièrement.

Pour aller plus loin

Le règlement EUDR ne se joue ni dans le texte ni dans le calendrier, mais dans la capacité à faire tenir ensemble la donnée fournisseur, la donnée produit et la preuve documentaire. Pour le cadre réglementaire complet - périmètre produits, échéances, géolocalisation et évaluation du risque - notre guide pilier « EUDR : le guide complet pour mettre votre supply chain en conformité » prolonge directement ce satellite.