Le jour où un chiffre de stock n’est plus le même selon l’outil, la réunion ou la personne qui le sort, le problème n’est plus organisationnel : il est structurel. C’est généralement à ce moment-là qu’un projet ERP est lancé.
Sur le terrain, on voit des ERP démarrer avec une mauvaise question : quel logiciel choisir ?Alors que la vraie difficulté arrive bien avant :
- savoir quels processus doivent réellement être standardisés ;
- lesquels doivent rester spécifiques ;
- et jusqu’où l’entreprise est prête à se discipliner.
Mettre en place un ERP, ce n’est pas déployer un outil transverse. C’est transformer des pratiques implicites en règles explicites. Et accepter que certaines façons de faire ne survivront pas au projet.
👉 Dans cet article, on détaille comment se déroule concrètement une mise en place d’ERP, ce que chaque étape engage, et pourquoi la majorité des blocages arrivent avant même la première ligne de paramétrage.
Avant l’outil : cadrer les usages, pas le catalogue de fonctionnalités
Un projet ERP qui démarre par une démo éditeur est déjà mal engagé.
Sur le terrain, les projets qui dérapent ont presque tous le même point commun : on a choisi un outil avant d’avoir compris comment l’entreprise fonctionne réellement.
Un ERP ne corrige pas des usages flous. Il les fige.
Partir du travail réel, pas des process théoriques
La première étape n’est pas de lister des fonctionnalités, mais d’observer ce qui se passe vraiment :
- comment une commande est créée, modifiée, validée ;
- où la donnée est ressaisie (et pourquoi) ;
- quelles exceptions sont gérées “à la main” ;
- quels fichiers Excel sont critiques… même s’ils ne devraient pas l’être.
Ce travail est souvent inconfortable. Il révèle des contournements, des règles implicites, des dépendances à certaines personnes.
Mais sans cette cartographie terrain, l’ERP ne fera que reproduire le chaos existant dans un outil plus rigide.
Distinguer l’essentiel du spécifique
Tout n’a pas vocation à être standardisé. C’est même l’erreur la plus coûteuse.
À ce stade, on doit trancher clairement :
- ce qui doit être commun à toute l’organisation ;
- ce qui peut rester spécifique à un métier ou une équipe ;
- ce qui relève d’un vrai besoin… et ce qui est juste une habitude.
👉 Un ERP efficace n’est pas celui qui couvre 100 % des cas.
C’est celui qui couvre les bons 80 %, sans créer d’usine à gaz pour les 20 % restants.
Formaliser avant d’outiller
Avant de parler solution, tout doit être écrit noir sur blanc :
- flux cibles ;
- responsabilités ;
- données de référence ;
- points de contrôle.
Ce cadrage sert ensuite de filtre objectif pour comparer les ERP.
Sans lui, on choisit un outil complet. Avec lui, on choisit un outil adapté.
⚠️ Warning
Si vous n’êtes pas capables d’expliquer vos usages sans parler de l’outil, il est trop tôt pour lancer un projet ERP.
Le vrai déroulé d’une mise en place d’ERP (terrain, pas PowerPoint)
Sur le papier, une mise en place d’ERP suit toujours la même chronologie.
Sur le terrain, ce n’est jamais linéaire. Mais il y a un enchaînement réaliste, et quand on le respecte, le projet tient. Quand on le brûle, il dérape.
1. Cadrage fonctionnel sérieux (pas un atelier vitrine)
C’est la phase la plus sous-estimée… et la plus déterminante.
On ne parle pas encore d’écrans, mais de règles métier :
- quelles données font foi ;
- qui peut modifier quoi, et à quel moment ;
- quels contrôles sont bloquants ;
- quelles exceptions sont tolérées (et lesquelles ne le sont plus).
Sur les projets qui échouent, ce cadrage est soit trop vague, soit bâclé pour aller vite.
Les décisions sont repoussées… puis subies au moment du paramétrage.
2. Paramétrage et adaptations (là où les choix deviennent irréversibles)
Une fois dans l’ERP, chaque décision prise au cadrage devient concrète.
Et c’est là que les tensions apparaissent :
- demandes de champs en plus ;
- workflows spécifiques pour un cas marginal ;
- règles métiers contradictoires entre équipes.
👉 C’est ici que la gouvernance fait la différence.
Sans arbitrage clair, l’ERP se transforme en patchwork de compromis.
Sur un projet ERP industriel, le paramétrage a commencé à dériver très vite : chaque équipe arrivait avec ses “cas particuliers”. On n’a pas cherché à tout trancher fonction par fonction. On a posé une règle simple : toute adaptation devait améliorer le process global, pas résoudre un irritant local. En deux ateliers, plus de la moitié des demandes ont été abandonnées. Le projet a arrêté de négocier en permanence et a recommencé à avancer.
— Camille, Product Manager @ Yield Studio
3. Reprise de données : le moment de vérité
C’est souvent là que la réalité rattrape le projet. Données incomplètes, incohérentes, jamais nettoyées : l’ERP ne pardonne rien.
Un bon projet prévoit :
- un nettoyage en amont ;
- des règles de transformation claires ;
- plusieurs itérations de reprise, pas une seule pour le go-live.
👉 Si la donnée est mauvaise, l’ERP ne l’améliorera pas. Il la rendra visible.
4. Tests et montée en compétence (pas juste une recette)
Tester un ERP, ce n’est pas valider que “ça marche”. C’est vérifier que les équipes savent travailler avec.
Les projets solides incluent :
- des tests sur des cas réels ;
- des utilisateurs clés impliqués tôt ;
- une formation orientée usage, pas fonctionnalités.
5. Mise en production et ajustements
Le go-live n’est pas la fin du projet. C’est le début de l’usage réel. Les premières semaines servent à ajuster, corriger, clarifier - pas à refaire ce qui n’a pas été décidé avant.
📌 À retenir
Un ERP ne se met pas en place par étapes techniques, mais par décisions assumées.
Chaque choix évité au départ ressortira… en production.
Intégration, spécifique, dette : là où les projets ERP explosent
Un projet ERP ne déraille presque jamais à cause du cœur de l’outil. Il déraille à cause de ce qu’on branche autour… et de ce qu’on accepte de contourner.
L’intégration : sous-estimée, sur-sollicitée
Un ERP vit rarement seul. Il échange avec :
- des outils métiers existants ;
- des CRM, WMS, TMS, outils comptables ;
- des solutions historiques que personne n’ose retirer.
Chaque interface est un point de fragilité.
Sur le terrain, on voit souvent des intégrations construites vite, mal documentées, sans stratégie de long terme. Elles fonctionnent… jusqu’au premier changement de version, ou jusqu’à ce qu’un flux se bloque en production.
👉 Plus il y a d’intégrations non maîtrisées, plus l’ERP devient dépendant de son environnement.
Le spécifique : l’ennemi discret
Le spécifique est rarement présenté comme tel. Il arrive sous des formes acceptables : “petite adaptation”, “logique métier indispensable”, “cas très particulier”.
Pris isolément, chaque développement semble légitime.
Accumulez-les, et vous obtenez :
- un ERP difficile à maintenir ;
- des montées de version coûteuses ;
- une dépendance forte à l’intégrateur ou à l’équipe initiale.
“Sur un ERP retail, aucun développement spécifique n’a été décidé comme un vrai choix structurant. Ils ont été ajoutés un par un, pour répondre à des cas ponctuels, sans vision d’ensemble. Trois ans plus tard, l’ERP était devenu trop risqué à faire évoluer : trop de règles cachées, trop de dépendances non maîtrisées. Personne n’osait lancer une montée de version.”
— Julien, Engineering Manager @ Yield Studio
La dette ERP : invisible… jusqu’au prochain projet
La dette ne se voit pas le jour du go-live.
Elle apparaît quand il faut :
- ajouter un nouveau flux ;
- intégrer un nouvel outil ;
- faire évoluer un process métier.
Chaque contournement non documenté devient un frein.
Chaque règle implicite devient un risque.
⚠️ Warning
Un ERP sur-spécifié ne crée pas de valeur durable.
Il fige des problèmes que l’entreprise devra repayer plus tard - souvent au pire moment.
La conduite du changement : le facteur n°1 de succès (et le plus négligé)
Sur le terrain, un ERP qui ne prend pas n’est presque jamais un problème d’outil.
C’est un problème d’appropriation. Les équipes continuent à travailler comme avant… autour de l’ERP, pas avec lui.
La conduite du changement n’est pas une phase à part.
C’est ce qui conditionne l’usage réel du système dès le premier jour.
L’erreur classique : communiquer trop tard
Beaucoup de projets ERP communiquent au moment du go-live.
C’est déjà trop tard.
Les utilisateurs découvrent alors :
- des règles qu’ils n’ont pas comprises ;
- des processus qu’ils n’ont pas contribué à définir ;
- un outil perçu comme imposé, pas utile.
👉 Contournements, fichiers parallèles, rejet passif.
Impliquer tôt les bons relais
Les projets qui tiennent dans la durée s’appuient sur :
- des utilisateurs clés identifiés dès le cadrage ;
- impliqués dans les tests, pas juste dans la recette finale ;
- capables d’expliquer le “pourquoi”, pas seulement le “comment”.
👉 Un ERP est accepté quand il est compris. Et il est compris quand les décisions ont été partagées, pas seulement annoncées.
Former à l’usage, pas au logiciel
Former sur des écrans ne suffit pas.
Ce qui fonctionne :
- des cas réels ;
- des scénarios métier ;
- des erreurs volontaires pour apprendre à les gérer.
📌 À retenir
Si les équipes n’ont pas confiance dans l’ERP, elles recréeront leurs propres règles - avec ou sans vous.
Conclusion - Un projet ERP se gagne avant le go-live
Un ERP ne sauve pas une organisation mal alignée.
Il la met face à ses incohérences, sans filtre.
Quand un projet ERP échoue, ce n’est presque jamais parce que l’outil était mauvais.
C’est parce que les usages n’étaient pas clairs, les arbitrages repoussés, et les exceptions trop nombreuses pour être assumées.
Sur le terrain, les ERP qui tiennent dans le temps ont trois points communs :
- un périmètre fonctionnel réellement cadré avant le choix de l’outil ;
- peu de spécifique, mais assumé ;
- une équipe capable de dire non quand le cadre est menacé.
Un ERP réussi n’est pas confortable. Il impose une discipline. Et c’est précisément pour ça qu’il crée de la valeur.
👉 Chez Yield Studio, on intervient sur des projets ERP quand il faut structurer, intégrer et faire tenir le système dans la durée, pas juste implémenter une solution. Si vous êtes au début d’un projet ERP (ou coincés au milieu) mieux vaut poser les bons arbitrages maintenant que les subir plus tard.
