Un projet ERP qui dérape n’est presque jamais un problème purement technique. C’est ce que démontre, de façon spectaculaire, le cas de Lidl : sept ans de développement, plus de 500 millions d’euros investis, et un projet finalement abandonné.
Voici ce qui s’est réellement passé — et les trois leçons qu’on peut en tirer avant de lancer son propre projet.
Le problème central : un choix de valorisation des stocks
Lidl, comme la plupart des enseignes de hard discount, valorise historiquement ses stocks au prix d’achat. C’est une pratique comptable simple, cohérente avec son modèle économique low-cost.
Le problème : SAP, l’ERP retenu pour le projet, fonctionne nativement au prix de vente. Une différence qui peut sembler anecdotique sur le papier, mais qui touche au cœur de la mécanique comptable et logistique de l’entreprise.
Plutôt que d’adapter son process à ce standard, Lidl a choisi la voie inverse : faire développer des modules spécifiques pour adapter SAP à sa méthode de valorisation. Résultat : un système hybride, de plus en plus lourd à maintenir, de plus en plus difficile à faire évoluer.
Le piège de l’escalade d’engagement
Ce mécanisme porte un nom bien connu en gestion de projet : le piège de l’escalade. Plus une organisation investit dans un projet, plus il devient psychologiquement et politiquement difficile de dire stop — même quand les signaux d’alerte s’accumulent.
Chaque développement spécifique supplémentaire renforce la dépendance au système sur-mesure, et éloigne un peu plus la possibilité de revenir à un standard plus simple à maintenir. Après sept ans et un demi-milliard d’euros investis, l’abandon du projet a nécessité un courage rare : reconnaître que continuer coûterait plus cher que d’arrêter.
Trois leçons pour votre propre projet ERP
1. Un ERP est un projet de transformation, pas un projet informatique. Le déploiement d’un ERP touche les process métier, la comptabilité, la logistique, parfois l’organisation elle-même. Le traiter comme un simple projet IT — à confier uniquement à la DSI — est l’une des causes les plus fréquentes d’échec.
2. Les développements spécifiques sont une dette, pas une solution. Chaque adaptation sur-mesure éloigne l’entreprise du standard éditeur, complique les montées de version, et augmente le coût de maintenance sur le long terme. Un développement spécifique doit être une exception documentée et justifiée — jamais un réflexe par défaut.
3. Savoir quand s’arrêter est une compétence de pilotage à part entière. Un comité de pilotage efficace doit pouvoir remettre en question la trajectoire d’un projet à mi-parcours, sans attendre que les pertes deviennent catastrophiques. Cela suppose des indicateurs clairs, des jalons de décision, et la volonté politique de les respecter.
Ce que cela signifie concrètement avant de lancer votre projet
Avant de choisir un ERP ou un WMS, la vraie question à se poser n’est pas « quel outil est le meilleur du marché ? » mais : « Mon process est-il compatible avec le standard de cet outil — et si non, suis-je prêt à faire évoluer mon process plutôt que l’outil ? »
C’est exactement la question qui s’est posée pour Lidl : est-ce le problème de l’outil, ou le problème du process ?
Dans la grande majorité des cas, quand un outil qui fait tourner des milliers d’entreprises ne convient pas à votre organisation, ce n’est pas l’outil qu’il faut remettre en cause en premier.
Vous préparez un projet ERP ou WMS et voulez éviter ce type de dérive ? J’accompagne les entreprises dans le cadrage, le choix de solution et le pilotage de leurs projets de transformation logistique (Reflex WMS, Odoo, SAP). Discutons de votre contexte →