L'ERP, la décision qu'on repousse toujours

Le paradoxe que vivent toutes les PME

Si vous demandez à dix dirigeants de PME ce qu'ils pensent de leur ERP, neuf vous diront probablement la même chose : "il ne suit plus, on devrait en changer".

Si vous demandez à ces mêmes neuf dirigeants quand ils comptent le faire, la réponse sera presque toujours : "on en parlera l'année prochaine".

Cette série a démarré sur le cas d'un client (EP1) qui se trouvait exactement dans cette situation. Son ERP, choisi cinq ans plus tôt, ne suivait plus l'évolution de l'entreprise. On a posé un SaaS en pansement pour soulager l'opérationnel. Mais ça n'a jamais été conçu comme une solution finale. La vraie décision, celle de repenser l'ERP en profondeur, restait à prendre.

Pendant des mois, elle a été repoussée. Comme partout.

Ce qui m'a poussé à écrire cet épisode, c'est cette question : pourquoi cette décision en particulier paralyse, là où d'autres décisions tout aussi structurantes (changer de banque, refondre un site, embaucher) finissent par être tranchées ?

Pourquoi cette décision est la plus repoussée des décisions SI

En écoutant les dirigeants que j'accompagne à La Réunion, j'ai identifié cinq raisons qui se renforcent les unes les autres.

1. Le coût visible. Un changement d'ERP, c'est rarement moins de quelques dizaines de milliers d'euros. Pour une TPE/PME, c'est un poste qui fait peur, parce qu'il est concentré dans le temps.
2. Le vendor lock-in (un terme que je vais expliquer juste après). Plus vous restez longtemps sur un ERP, plus partir devient compliqué.
3. La peur de la migration. Récupérer cinq ans de données, paramétrer le nouveau système, former l'équipe, basculer sans casser l'opérationnel. Ça fait beaucoup à porter pour une petite structure.
4. L'absence de "moment idéal". Il n'y en a jamais. Si l'activité tourne fort, on n'a pas la bande passante. Si elle ralentit, on n'a plus le budget.
5. Le SaaS pansement qui adoucit la douleur. Le plus pernicieux. Le pansement soulage juste assez pour que la douleur ne soit plus insupportable. L'urgence redescend. La décision attend. Ces cinq raisons ne sont pas indépendantes. Elles se renforcent. Et plus on attend, plus elles se renforcent encore.

Le vendor lock-in, c'est quoi exactement ?

Le vendor lock-in (ou "verrouillage fournisseur") est le mécanisme par lequel un client devient prisonnier de la solution qu'il utilise. Pas par contrat. Par accumulation.

Au démarrage, on choisit un ERP. On y entre nos données. On forme l'équipe. On adapte nos process. Tout va bien.

Au bout de cinq ans, partir représente : exporter (parfois imparfaitement) cinq ans de données, reformer toute l'équipe, reparamétrer un nouveau système, et accepter une période d'instabilité opérationnelle.

L'ERP est probablement l'outil le plus lock-in qui existe en entreprise, parce qu'il touche à tout : finance, stocks, RH, ventes, achats. Plus l'usage est dense, plus le mur de sortie est haut.

Les éditeurs le savent. Une bonne partie de leur modèle économique repose précisément sur cette inertie. Ce n'est pas un complot, c'est une mécanique.

Pourquoi la BI seule ne suffit pas pour cette décision

Dans l'épisode précédent, j'ai expliqué comment l'audit digital et la BI permettent de tester un scénario avant d'investir. La méthode est solide pour la plupart des projets de digitalisation.

Pour un ERP, elle bute sur un mur particulier.

Si votre ERP actuel ne vous permet même pas de produire les données qui valideraient le besoin de le remplacer (parce que les exports sont incomplets, les rapports illisibles, ou les croisements de données impossibles), alors cette incapacité elle-même est le diagnostic.

C'est exactement ce que je voyais chez le client de l'EP1 : impossible de sortir une vision globale des stocks sans plusieurs jours de travail manuel sous Excel. La BI ne pouvait pas fonctionner correctement parce que la matière première — des données propres et accessibles — n'existait pas.

D'où une montée en méthode au fil de cette série :

• Audit infrastructure (EP4) : valider que le socle technique tient.
• Audit digital + BI (EP5) : tester les hypothèses sur les données qu'on a déjà.
• POC fonctionnel (cet épisode) : quand les données seules ne suffisent pas, on simule en réel.

Comment on a débloqué la décision

Après plusieurs mois de pansement et un long échange, on s'est posé en face à face avec une question simple : "Qu'est-ce qui nous coûte le plus cher : changer, ou continuer comme ça ?"

Quand on a fait le calcul honnêtement (temps perdu, opportunités ratées, frustration des équipes), repousser n'était plus la décision la moins risquée. C'était devenue la plus coûteuse.

Et puis il y a un élément de calendrier qu'aucun dirigeant ne devrait ignorer en 2026 : l'obligation de facturation électronique pour les PME en septembre 2027. Ce genre d'échéance ne laisse plus la place à l'éternel report.

Le client était prêt. Il restait à choisir vers quoi aller.

Pourquoi j'ai recommandé Odoo

Quand j'ai exploré le marché ERP pour ce dossier, Odoo est rapidement remonté. Pas parce que c'est le plus gros nom, mais pour des raisons structurelles qui collent au profil d'une PME en transition :

• Open source. C'est rare pour un ERP qui pèse autant sur le marché. Ça veut dire un code accessible, des données ouvertes, et beaucoup moins de vendor lock-in qu'avec un éditeur propriétaire.
• Une communauté qui grandit fortement. Odoo prend des parts de marché aux acteurs historiques (Sage, EBP, Cegid). En France, près d'une PME sur cinq en phase de renouvellement d'ERP s'oriente aujourd'hui vers cette solution. L'écosystème de partenaires et de modules tiers est devenu massif.
• Une modularité réelle, pas juste marketing. On active ce dont on a besoin (caisse magasin, gestion de stock, comptabilité), on étend ensuite (CRM, RH, e-commerce). On paye ce qu'on utilise. Pour une PME qui ne veut pas signer un chèque pour des fonctions qu'elle n'utilisera jamais, ça change tout.
• Un retour terrain qui m'a marqué. Un restaurateur que je connais, qui tourne à bloc toute la semaine, m'a dit qu'Odoo lui faisait gagner un temps qu'il ne soupçonnait même plus. Quand un dirigeant qui n'a pas une minute de marge prend le temps de le dire, ça compte.

Le POC en cours

Avant de signer un engagement multi-année, on lance un POC (Proof of Concept, ou "preuve de concept") fonctionnel. Pendant quelques semaines, on simule sur Odoo les flux réels de l'entreprise : caisse magasin, gestion de stock, comptabilité avec factures fournisseurs.

Pas une démo édulcorée par l'éditeur. Un vrai test de réalité, avec leurs données, leurs cas particuliers, leurs habitudes d'équipe.

Si ça passe, on bascule. Si on découvre des points bloquants, mieux vaut les voir maintenant qu'après avoir signé.

C'est exactement ce que disait l'épisode 5 : tester les scénarios avant d'investir. Appliqué cette fois à la décision la plus lourde qu'une PME ait à prendre sur son système d'information.

Ce qui sera dans l'épisode final

Maintenant qu'un POC est en route, on pourrait croire que le plus dur est fait.

Ce serait une erreur.

La technique, c'est jamais le plus dur dans un changement d'ERP. Le plus dur, c'est l'humain. Comment l'équipe absorbe le changement, comment le dirigeant se rassure au moment de signer, comment on organise la bascule sans casser l'opérationnel.

C'est ce qu'on racontera dans le dernier épisode de cette série.

FAQ — POC et changement d'ERP

Combien coûte un POC ERP pour une PME ?

Pour une TPE/PME, un POC bien cadré coûte généralement entre 2 000 et 8 000 euros, selon la complexité fonctionnelle et le périmètre testé. C'est sans commune mesure avec le coût d'un déploiement raté, qui peut se chiffrer en dizaines de milliers d'euros et plusieurs mois perdus.

Combien de temps dure un POC ERP ?

En général entre quatre et huit semaines. Plus court, c'est une démo. Plus long, c'est déjà un mini-projet de déploiement. La durée idéale dépend du nombre de modules testés et de la complexité des scénarios métier que vous voulez simuler.

Faut-il toujours faire un POC avant de changer d'ERP ?

Pour une PME, oui. C'est le seul moyen sérieux de valider que l'outil répond à vos cas réels avant d'engager un budget conséquent. La seule exception acceptable : si votre besoin est très standard et que l'éditeur peut vous montrer plusieurs références identiques à votre cas.

Que faire si l'éditeur refuse de faire un POC ?

C'est un signal d'alerte. Soit l'éditeur n'a pas confiance dans son produit sur votre cas, soit il fonctionne sur un modèle d'engagement total qui ne laisse pas de place au test. Dans les deux cas, posez-vous la question avant de signer.

Quand vaut-il mieux moderniser son ERP que le changer ?

Quand le périmètre fonctionnel est encore globalement adapté et que seules quelques briques posent problème. Une montée de version, un module complémentaire ou une intégration externe peuvent suffire. Le changement complet se justifie quand l'écart entre ce que fait l'ERP et ce dont l'entreprise a réellement besoin est devenu structurel.

Vous reportez depuis trop longtemps une décision sur votre ERP ? Un échange permet souvent de clarifier si vous avez besoin de moderniser, de remplacer, ou simplement de remettre les bonnes questions sur la table. Contactez-moi pour en discuter.