Les cinq pièges les plus fréquents de l'intégration ERP

Une part importante des projets d'intégration ERP entre en production plus tard que prévu. Non pas par manque de code, mais à cause de pièges négligés au démarrage. Cet article les passe en revue — et explique comment les éviter.

01. Piège 1 : repousser la décision sur l'enregistrement de référence

Si l'on ne détermine pas dès le départ quel système fait référence pour quelle donnée, l'intégration revient à laisser les deux systèmes s'annuler mutuellement. Cette décision doit être écrite dès la première semaine du projet et validée par toute l'équipe.

02. Piège 2 : fuseaux horaires et décalages

L'ERP conserve les horodatages en UTC et le B2B les affiche en heure locale — ou l'inverse. Si les deux systèmes n'ont pas la même conception du temps, les dates de commande peuvent glisser de plusieurs heures. Un standard unique doit être fixé dès le début, de préférence l'UTC au niveau système.

03. Piège 3 : ne pas tester la tolérance aux coupures

L'ERP est en maintenance pendant une minute. Les 12 commandes arrivées dans cette minute sont-elles perdues ? Si la réponse est oui, l'intégration est incomplète. Une intégration sans mécanisme de mise en file (RabbitMQ, Azure Service Bus, etc.) ne doit pas partir en production.

04. Piège 4 : une correspondance des champs non documentée

Au démarrage, on note dans un seul fichier Excel quel champ va vers quel champ. Six mois plus tard, l'équipe a changé et plus personne ne s'en souvient. Le document de correspondance doit être versionné et chaque modification tracée.

05. Piège 5 : une bascule sans phase parallèle

« Aujourd'hui l'ancien système, demain le nouveau. » Cette approche s'effondre en une semaine en production. Une transition saine passe par deux à quatre semaines de fonctionnement en parallèle : les mêmes données entrent dans les deux systèmes et les écarts sont suivis quotidiennement. L'ancien système ne s'éteint qu'après deux semaines consécutives sans écart.