Changer de logiciel dans une entreprise de recyclage, c'est une décision qui ne se prend pas à la légère. Les données accumulées sur des années — historiques de pesées, contrats clients, référentiels codes déchets, données BSD, tarifs fournisseurs — représentent un patrimoine informationnel irremplaçable. Une migration ratée peut se traduire par des mois de données perdues, une facturation impossible à reconstituer, ou des anomalies dans les déclarations réglementaires. Pourtant, avec une méthode rigoureuse et les bons outils, la migration vers un ERP recyclage dédié est une opération maîtrisable qui peut se dérouler sans interruption de l'activité.
Audit préalable : cartographier ce que vous avez vraiment
Avant de migrer quoi que ce soit, il faut savoir exactement ce que contient votre système actuel. Cet audit de l'existant est souvent la phase la plus révélatrice — et parfois la plus désagréable — du projet de migration. Dans beaucoup d'entreprises du secteur, les données sont réparties entre plusieurs silos : un logiciel de bascule propriétaire qui stocke les pesées dans une base de données locale, un ou plusieurs classeurs Excel pour les contrats et les tarifs, un logiciel de facturation généraliste, et parfois un ERP tiers pour la comptabilité.
La cartographie des données existantes doit répondre à ces questions : Quels sont les formats de stockage ? Les données de pesée sont-elles dans une base SQL, un fichier DBF propriétaire, un export CSV régulier ? Les contrats clients sont-ils formalisés dans le logiciel ou seulement dans des documents PDF ? Quelle est la profondeur historique nécessaire — avez-vous besoin de récupérer cinq ans d'historique de pesées, ou six mois suffisent ? Quels sont les référentiels essentiels — clients, fournisseurs, véhicules, codes déchets — et quelle est leur qualité ?
Cette dernière question sur la qualité des données est cruciale. Il est fréquent de découvrir lors d'un audit de migration que le référentiel clients contient des doublons (un même client sous trois orthographes différentes), que certains codes déchets utilisés ne correspondent à aucun code officiel, ou que des champs obligatoires dans le futur ERP sont vides dans l'ancien système. Nettoyer ces données avant la migration est infiniment plus efficace que d'essayer de corriger des données corrompues après le passage.
Formats d'import : ce que les ERP recyclage acceptent
Un ERP recyclage moderne dispose d'outils d'import standardisés pour les données les plus courantes. Les formats les plus fréquemment supportés sont le CSV avec séparateur paramétrable, l'Excel (XLSX), et parfois les connexions directes à des bases SQL pour les volumes importants.
Pour chaque type de données, les contraintes d'import sont différentes. Les données clients et fournisseurs sont généralement les plus simples à importer : SIREN, raison sociale, adresse, coordonnées bancaires — ces champs sont standardisés et peu problématiques. Les référentiels véhicules (immatriculation, type, tare, PTAC) sont également simples.
Les données les plus complexes à migrer sont les historiques de pesées et les contrats tarifaires. Pour les pesées, il faut que chaque enregistrement puisse être rattaché à un client identifié dans le nouveau référentiel, un code déchet valide, un véhicule connu. Si ces rattachements ne peuvent pas être reconstitués automatiquement, les pesées historiques ne sont importables qu'à titre de consultation — sans lien avec les contrats et les factures. Pour les tarifs contractuels, la structure de l'ancien système peut être très différente de celle du nouvel ERP, ce qui peut nécessiter une transformation significative des données avant import.
C'est ici que l'éditeur de l'ERP joue un rôle clé. Un bon accompagnement à la migration inclut des scripts d'import personnalisés capables de lire les formats propriétaires des principaux logiciels de bascule du marché, et de faire la correspondance automatique entre les identifiants de l'ancien système et ceux du nouveau.
Reprise des historiques : ce qui est vraiment nécessaire
Une question revient systématiquement lors des projets de migration : combien d'historique faut-il reprendre ? La réponse dépend de plusieurs facteurs réglementaires et opérationnels.
Du côté réglementaire, le registre des déchets doit être conservé trois ans pour les déchets non dangereux et cinq ans pour les déchets dangereux. Si votre ancien système contient ces données, il est recommandé de les reprendre dans le nouvel ERP pour avoir un historique consolidé. Les BSD et les données Trackdéchets doivent être conservés au minimum cinq ans — mais ceux-ci sont stockés chez Trackdéchets lui-même et restent accessibles indépendamment de votre changement de logiciel.
Du côté opérationnel, l'historique de pesées par client est précieux pour les négociations commerciales et le suivi des engagements de volume. Avoir deux à trois ans d'historique dans le nouvel ERP permet de comparer les performances actuelles aux périodes précédentes, de détecter les tendances et de préparer les révisions tarifaires avec des données fiables. Au-delà de trois ans, la valeur marginale de l'historique diminue — sauf cas particulier (litige long, contrat pluriannuel).
Une approche pragmatique consiste à reprendre douze à vingt-quatre mois d'historique de pesées dans le nouvel ERP, et à archiver les données plus anciennes dans un format lisible (PDF, CSV) accessible en cas de besoin.
La période de parallèle : le filet de sécurité indispensable
Quelle que soit la qualité de la préparation, une migration vers un nouvel ERP comporte toujours une part d'inconnu. La meilleure façon de gérer ce risque est d'organiser une période de fonctionnement en parallèle, pendant laquelle les deux systèmes tournent simultanément et les résultats sont comparés.
La durée recommandée pour cette période de parallèle est d'un cycle de facturation complet — généralement un mois. Pendant ce mois, chaque pesée est enregistrée dans les deux systèmes, et la facturation est générée dans les deux. On compare ensuite les factures : les écarts identifiés permettent de détecter les paramétrisations incorrectes dans le nouvel ERP avant qu'elles ne causent de vrais problèmes.
Cette période de parallèle est contraignante — elle double la charge de travail des équipes pendant un mois — mais elle est quasi-indispensable pour les entreprises ayant des volumes de facturation importants ou des structures tarifaires complexes. Pour les structures plus petites avec une tarification simple, un parallèle sur deux semaines peut suffire.
Le cut-over : planifier le passage en production
Le cut-over, c'est le moment où l'ancien système est définitivement abandonné et le nouveau prend le relais. Ce moment doit être planifié avec soin pour minimiser les perturbations opérationnelles.
Le choix de la date est important : évitez les périodes de forte activité, les fins de mois (période de facturation) et les périodes de déclarations réglementaires (clôture de registre, déclarations ICPE). Un début de mois, après avoir finalisé et envoyé toutes les factures du mois précédent dans l'ancien système, est généralement le moment le plus propice.
La veille du cut-over, effectuez un export final de toutes les données de l'ancien système et archivez-les. Le lendemain matin, démarrez sur le nouveau système. Prévoyez une équipe de support dédiée pour les premiers jours — les questions seront nombreuses, et il est normal que les opérateurs aient besoin d'accompagnement pour les premières pesées, les premiers BSD, les premiers devis. Avec une bonne formation en amont et un support réactif, la période d'adaptation est généralement courte : une à deux semaines pour retrouver une vitesse de croisière normale.
Les pièges classiques et comment les éviter
Plusieurs écueils reviennent régulièrement dans les projets de migration ERP dans le secteur du recyclage. Le premier est de sous-estimer le nettoyage des données : importer des doublons ou des données incorrectes dans le nouveau système, c'est transférer les problèmes plutôt que les résoudre. Investissez du temps dans la qualité des données avant la migration.
Le deuxième piège est de vouloir migrer trop d'historique. Reprendre dix ans de pesées dans un nouveau système peut prendre des semaines de travail pour un bénéfice limité. Soyez pragmatique sur la profondeur historique nécessaire.
Le troisième est de négliger la formation. Un ERP métier comme Okapia OSa une logique de fonctionnement différente d'un logiciel de bascule traditionnel. Les opérateurs doivent comprendre pourquoi ils saisissent certaines informations — le code déchet, le motif de la mission, la référence contrat — et pas seulement comment. Une formation qui explique le sens des opérations, pas seulement les clics, produit des utilisateurs bien plus efficaces et des données bien meilleures.
Enfin, choisissez un éditeur qui a déjà réalisé des migrations depuis les logiciels que vous utilisez actuellement. L'expérience des migrations précédentes est un gage de fiabilité : un éditeur qui a déjà migré cinquante entreprises depuis le même logiciel de bascule saura anticiper les problèmes spécifiques à ce format de données et vous faire économiser des semaines de travail.