Un extranet invendus mis en service il y a cinq ou six ans remplit encore sa fonction de base : diffuser des lots de fins de séries à un réseau de repreneurs. Le problème ne vient pas de ce qu’il fait, mais de ce qu’il ne trace pas.
Avec l’entrée en application du règlement européen ESPR (UE 2024/1781) et le durcissement de la loi AGEC, la question pour 2026 n’est plus seulement commerciale. Elle porte sur la capacité de l’outil à prouver ce que l’entreprise a fait de ses invendus, lot par lot.
A découvrir également : Prix de LA licence taxi en 2026 : guide stratégique pour futurs chauffeurs
Extranet invendus et conformité ESPR : ce qui change au 19 juillet 2026
La plupart des extranets d’invendus ont été conçus comme des vitrines de déstockage. Catalogue produit, prix remisé, panier, validation de commande. Le flux est commercial, pas réglementaire.
Le règlement ESPR impose pourtant aux grandes entreprises de l’UE (250 salariés ou plus) une interdiction de détruire les vêtements, accessoires vestimentaires et chaussures invendus à compter du 19 juillet 2026. Chaque exception (produit dangereux, contrefaçon, article non réparable) doit être documentée et conservée plusieurs années.
A lire également : AXA courtage extranet : les nouveautés à surveiller en 2026 pour les courtiers
Pour une entreprise qui gère ses invendus via un extranet, cela signifie que l’outil doit désormais produire une preuve de destination : don, réemploi, revente à un soldeur, recyclage matière. Un simple historique de commandes ne suffit plus. Il faut un registre horodaté par lot, avec le statut final de chaque référence.
Comparatif : extranet de déstockage classique et extranet conforme 2026
| Fonction | Extranet classique (pré-2024) | Extranet adapté réglementation 2026 |
|---|---|---|
| Catalogue invendus | Oui | Oui |
| Suivi de commande repreneur | Oui | Oui |
| Traçabilité lot par lot (destination finale) | Non | Oui, avec horodatage |
| Registre des exceptions (destruction autorisée) | Non | Oui, documenté et archivé |
| Export conformité AGEC / ESPR | Non | Oui, format exploitable par un auditeur |
| Gestion des canaux de réemploi (don, recyclage) | Rarement | Oui, avec preuve de transfert |
| Durée de conservation des données | Variable (souvent purgée) | Plusieurs années, selon le règlement |
L’écart entre les deux colonnes révèle le vrai sujet : l’extranet ancien n’a pas été pensé pour la conformité. Il manque la couche de traçabilité, pas la couche commerciale.
Modernisation ciblée d’un extranet invendus : les modules à greffer en priorité
Reconstruire l’ensemble de l’extranet pour ajouter une fonction de registre serait disproportionné. La base (authentification, catalogue, gestion des commandes) fonctionne. Ce qui manque, ce sont des briques spécifiques.
- Module de traçabilité par lot : chaque référence invendue reçoit un statut final (revendu, donné, recyclé, détruit avec justification). Le statut est horodaté et lié à un document de preuve (bon de cession, attestation de don, certificat de recyclage).
- Module d’export réglementaire : génération d’un fichier consolidé par période, lisible par un auditeur ou un contrôleur. Le format doit pouvoir alimenter un rapport AGEC ou une déclaration ESPR sans retraitement manuel.
- Module de gestion des exceptions : quand la destruction est autorisée (produit dangereux, contrefaçon saisie), l’extranet enregistre le motif, la date et la quantité. Ce registre d’exceptions est la pièce la plus sensible en cas de contrôle.
- Archivage longue durée : les données de l’extranet classique étaient souvent purgées après un ou deux ans. Le règlement ESPR exige une conservation sur plusieurs années. Un stockage séparé, en base froide, évite de surcharger l’application principale.
Ces quatre modules peuvent être développés indépendamment du socle existant, à condition que l’extranet expose un minimum d’interfaces (API ou accès base de données).
Extranet invendus sans API : identifier le verrou technique avant de planifier
Les extranets développés entre 2015 et 2020 reposent souvent sur des frameworks PHP ou des CMS personnalisés dont la couche d’interface est limitée. Avant de lancer un chantier de modernisation, un point technique tranche la faisabilité : l’extranet expose-t-il une API ou un accès structuré à sa base de données ?
Si oui, les modules de traçabilité peuvent s’y connecter sans toucher au code historique. L’ajout se fait en périphérie, comme une extension qui lit et écrit dans les mêmes tables.
Si non, deux options se présentent. La première consiste à créer une couche API minimale au-dessus de la base existante, ce qui demande un accès au schéma de données et une documentation (même partielle) du modèle. La seconde option passe par un micro-service autonome qui reçoit les données par import fichier (CSV, flux FTP) plutôt que par connexion directe. Cette approche est plus lente mais ne requiert aucune modification du code source.
Dans les deux cas, le coût de modernisation reste une fraction du coût d’une reconstruction complète.
Loi AGEC et ESPR : l’extranet comme registre de preuve, pas comme vitrine
La loi AGEC imposait déjà depuis 2022 une interdiction de destruction des invendus non alimentaires pour certaines catégories de produits. Le règlement ESPR élargit le périmètre et durcit les obligations de documentation au niveau européen.
Un extranet invendus modernisé devient alors un registre de conformité exploitable en cas d’audit. Chaque lot tracé, chaque exception documentée, chaque preuve de réemploi archivée constitue un élément opposable. Les entreprises qui continuent à gérer leurs invendus sur un tableur ou un extranet sans traçabilité prennent un risque de non-conformité mesurable.
Les micro et petites entreprises sont exemptées de l’interdiction de destruction et de l’obligation de transparence associée, selon le règlement ESPR. Pour les structures de plus de 250 salariés, la mise en conformité de l’extranet n’est pas un projet d’amélioration continue. C’est une obligation réglementaire avec une date butoir.
Le chantier le plus rentable pour 2026 n’est pas une refonte graphique ni une migration de CMS. C’est l’ajout d’une couche de traçabilité réglementaire sur un outil qui, pour le reste, fait déjà son travail.
