Changer d'ERP en PME : retour d'expérience terrain

« Nous avons besoin d'un logiciel pour mieux gérer nos stocks. »

C'est la demande, en apparence très simple, qui m'a été faite lors de ma première mission de freelance, chez une PME de vente au détail. Quelques semaines plus tard, une chose était claire : le logiciel n'était pas le sujet. Le vrai problème, c'était un ERP choisi cinq ans plus tôt, un bon choix à l'époque, que l'entreprise avait fini par dépasser.

Cet article raconte cette mission de bout en bout et en tire une méthode pour tout dirigeant qui se demande s'il doit changer d'ERP : le diagnostic, le coût réel d'un système d'information qui ne suit plus, l'angle mort de l'infrastructure, le test des hypothèses avant d'investir, les raisons pour lesquelles cette décision est toujours repoussée, et ce que je ferais différemment dès le premier jour.

Ce guide réunit en un seul article ma série « Choix digitaux stratégiques », publiée en sept épisodes début 2026.

L'essentiel en bref

• Un ERP qui était un bon choix il y a cinq ans peut devenir un frein sans avoir changé : c'est l'entreprise qui a évolué... mais pas l'outil.
• Dans ce contexte, le vrai coût n'est pas que la licence. C'est le temps passé à reconstituer l'information (ici, environ 385 heures par an) et le retard permanent sur les décisions.
• Un SaaS « pansement » soulage l'opérationnel, mais il peut aussi repousser la vraie décision.
• Avant de changer d'ERP : auditer l'infrastructure, tester ses hypothèses sur ses propres données, puis valider par un POC (preuve de concept).
• Fixer dès le départ un point de bascule (une date, un seuil) pour éviter l'attentisme.

Le contexte : un bon choix d'ERP devenu un frein

Un choix cohérent… à l'époque

Il y a environ cinq ans, cette entreprise de vente au détail avait choisi un ERP pour structurer son activité. À ce moment-là, c'était un bon choix :

• un périmètre fonctionnel adapté ;
• un coût maîtrisé ;
• une mise en place rapide.

Le problème ne venait donc pas de l'outil lui-même, mais d'un élément rarement anticipé : l'évolution de l'entreprise. Entre-temps, l'activité s'était développée, les volumes avaient augmenté, les sites s'étaient multipliés et la gestion des stocks était devenue beaucoup plus complexe.

L'ERP, lui, n'avait pas changé. Il ne s'était pas dégradé : il répondait simplement un peu moins bien, chaque jour un peu moins.

Ce que j'ai observé en arrivant

Pour obtenir une vision globale des entrées et sorties de stock sur l'ensemble des sites, les équipes devaient :

1. extraire plusieurs jeux de données depuis l'ERP ;
2. les manipuler sous Excel ;
3. croiser manuellement les informations ;
4. reconstruire un tableau de pilotage final.

Résultat : plusieurs heures de travail étalées sur plusieurs jours, pour une information qui aurait dû être disponible en quelques minutes : Visibilité des entrées et sorties de stock sur l'ensemble des sites. Afin de créer un rapport de pilotage sur les prochaines commandes. Et un point alarmant : c'est que ce n'était plus exceptionnel mais complètement normal dans leur quotidien.

Le vrai problème n'était pas Excel

À ce stade, mon client (et sûrement comme beaucoup) en a conclu : « il nous faut un nouveau logiciel ». En réalité, le problème était plus profond :

• l'ERP n'a jamais permit de répondre à un besoin BI avancée, et à l'heure actuelle ce manque est devenu critique
• aucune vision à long terme sur l'évolution de l'entreprise n'avait été intégrée au départ ;
• les processus avaient évolué, mais pas le système d'information.

Excel était ce qui était l'outil de BI : permettait de croiser les données, faire agréger les données, calculer des indicateurs clés en masse. Excel n'est en rien la cause du dysfonctionnement dans leur SI (système d'information).

Ma première réponse : un SaaS en pansement

Ma première réponse a été une solution à court terme : un SaaS complémentaire, développé pour automatiser une partie des traitements, réduire drastiquement le temps passé sur les exports et redonner de la visibilité aux équipes opérationnelles. J'ai volontairement isolé cet outil de l'ERP : le jour où l'ERP change, seule la couche d'accès aux données est à réécrire (le détail technique est dans l'étude de cas pilotage supply chain).

Sur le moment, c'était une bonne décision : elle a dégagé du temps critique là où l'entreprise en manquait le plus. Mais ajouter un outil, même pertinent, sur un système d'information déjà contraint revient souvent à traiter les symptômes sans s'attaquer à la cause. D'où une stratégie en deux temps :

• À court terme : soulager l'opérationnel.
• À moyen et long terme : repenser le système d'information dans son ensemble.

Un système d'information doit accompagner la trajectoire d'une entreprise, et non pas seulement répondre à un besoin immédiat.

Combien coûte vraiment un ERP qui ne suit plus ?

Quand on parle de système d'information, la discussion tourne souvent autour du coût des outils : licences, abonnements, intégration. Mais le coût le plus important est rarement visible sur une facture. Il se cache dans le temps perdu, la charge mentale et les décisions prises trop tard.

Parlons en heures, pas en outils

Prenons des chiffres volontairement simples. Dans cette entreprise, deux personnes se partageaient cette tâche. Ce n'étaient pas des spécialistes du stock : elles géraient aussi le suivi fournisseur, la coordination interne et les urgences du quotidien. Chacune consacrait environ quatre heures par semaine à reconstituer la situation des stocks.

385 heures passées non pas à décider, à améliorer ou à anticiper, mais à reconstruire une information qui pourrait voir devrait être immédiate. Ce sont plusieurs semaines de travail évaporées, des projets repoussés, des arbitrages faits dans l'urgence, une fatigue qui s'installe. Dans ce contexte, le système d'information ne fait pas gagner du temps : il en consomme.

Le vrai problème : le retard, pas l'effort

Le plus critique n'est pas tant le temps passé à produire l'information que le moment où elle arrive. Quand les chiffres sont enfin consolidés, l'opportunité est parfois passée, la décision aurait dû être prise plus tôt, et les conséquences sont déjà visibles sur le terrain : des ruptures de stock d'un côté, du sur-stockage de l'autre.

Un système lent ne bloque pas l'entreprise. Il la fait avancer avec un temps de retard permanent.

Un mauvais choix de système d'information coûte rarement cher le jour où il est fait. Il coûte cher chaque semaine, pendant des années.

Ce coût n'apparaît dans aucun budget IT. Il se manifeste dans la perte de temps, la fatigue des équipes et la baisse de qualité des décisions.

Quand les chiffres mentent : un problème d'organisation, pas d'outil

Il y a un moment, dans beaucoup de projets, où l'on croit encore que le problème est à taille humaine : un délai qu'on peut rattraper, un bug qu'on peut corriger, un processus qu'on peut ajuster. On bricole, on fait avec ce qu'on a. Puis arrive le jour où ça ne suffit plus, non parce que quelque chose s'est cassé, mais parce qu'on réalise que ce qui risquait de casser était là depuis le début.

Le choc : les chiffres de la direction n'étaient pas fiables

En retraçant avec la direction l'historique de leur système d'information depuis l'installation de l'ERP, j'ai mesuré l'ampleur de la situation. Les données qui guidaient les décisions ne venaient pas d'un tableau de bord en temps réel, mais d'un tableau reconstruit à la main sur plusieurs jours, à coups d'extractions et de croisements sous Excel. En parallèle, d'autres informations remontaient du terrain, à la main, à leur rythme, via des fichiers ou de simples conversations.

La direction a alors compris que les chiffres sur lesquels elle s'appuyait n'étaient pas ceux qu'elle avait sous les yeux, mais ceux qu'elle croyait avoir. Tant que tout le monde s'appuyait sur la même source, même imparfaite, cela donnait une illusion de cohérence.

Soigner les symptômes ou la cause ?

Ce n'est pas lors d'une réunion que l'évidence m'a frappé, mais dans un moment plus calme, en développant les premières versions du SaaS. Je me suis demandé : est-ce que ce que je fais résout le problème, ou est-ce que cela ne fait que masquer les symptômes ?

L'outil faisait gagner un temps réel et mesurable. Mais le vrai problème était structurel : il tenait à la façon dont l'entreprise avait organisé ses données, ses flux et ses prises de décision depuis cinq ans. Ce n'est pas un constat d'échec, c'est une prise de conscience nécessaire.

Cinq signaux qu'un système d'information ne suit plus

Voici ce que j'ai retrouvé dans cette mission, et que je cherche aujourd'hui chez chaque client :

1. Obtenir une vision globale demande plusieurs jours de manipulation manuelle (exports, puis Excel).
2. Plusieurs sources de vérité coexistent : l'ERP, des fichiers, des remontées orales.
3. Les chiffres de la direction et ceux du terrain ne concordent pas.
4. Des fichiers Excel « pansements » sont devenus la référence, parce qu'ils sont les seuls à offrir une vue d'ensemble (si c'est votre cas, lisez à partir de quand remplacer Excel par une application métier est rentable).
5. Les décisions arrivent après les conséquences.

Quand plusieurs de ces signaux se cumulent, la question n'est plus « quel outil ajouter ? » mais « quelle organisation de l'information voulons-nous ? ». Avec la direction, nous avons alors défini deux axes : continuer avec le SaaS pour limiter la casse sur les processus critiques, et, à long terme, changer d'ERP, la seule réponse structurelle.

L'angle mort des projets SI : l'infrastructure

Il y a un sujet que presque personne n'aborde au démarrage d'un projet de digitalisation, parce qu'il est invisible, du moins jusqu'au jour où il paralyse tout : l'infrastructure. On parle d'outil, d'ergonomie, de retour sur investissement. On parle rarement du socle sur lequel tout repose.

Ce qu'on entend par « infrastructure SI », concrètement

Le terme évoque des salles serveurs et des budgets de grands groupes. Pour une PME, c'est beaucoup plus simple, et beaucoup plus critique. Un audit d'infrastructure à petite échelle revient à répondre à trois questions :

1. Sur quoi vos données sont-elles stockées ?
2. Comment vos équipes se connectent-elles aux outils ?
3. Qui maintient l'ensemble en état de marche ?

À La Réunion, la qualité de la connexion varie fortement selon les communes. Une entreprise qui déploie un ERP cloud en partant du principe que « tout le monde a la fibre » risque de se retrouver avec des utilisateurs en ADSL en zone rurale, confrontés à des temps de chargement insupportables. Résultat : les équipes désertent l'outil au bout de quelques semaines. S'y ajoutent la latence vers certains datacenters et les structures multisites aux connexions hétérogènes, que les éditeurs basés en métropole ne maîtrisent pas toujours.

Un exemple de terrain

Sur une autre mission, j'ai accompagné une structure de services réunionnaise d'une vingtaine de collaborateurs dans le déploiement d'un outil de gestion partagée. Le projet était bien ficelé, le budget cohérent, les équipes motivées. Pourtant, trois mois après le lancement, l'outil « ramait », les collaborateurs étaient retournés à leurs fichiers Excel et le chef de projet interne était à bout.

En creusant, nous avons découvert que la connexion du site principal passait par un routeur vieillissant qui plafonnait les débits entrants. Le logiciel n'y était pour rien. Le remplacement du routeur et l'optimisation du réseau local ont pris deux semaines et coûté moins de 800 € de matériel. Mais entre-temps, l'entreprise avait perdu quatre mois et une bonne partie de l'adhésion de ses équipes.

Les trois questions à poser avant tout projet

1. Tous vos collaborateurs accèdent-ils aux outils depuis le même endroit, ou depuis des sites différents ?
2. Vos données sont-elles sauvegardées automatiquement, et avez-vous déjà testé une restauration ?
3. Avez-vous un interlocuteur technique, interne ou externe, qui connaît votre parc informatique et peut intervenir rapidement en cas de panne ?

Si la réponse à l'une de ces questions est floue ou négative, il y a un sujet à traiter avant d'aller plus loin. Pas après.

Tester avant d'investir : audit digital et Business Intelligence

Avant de décider quoi que ce soit sur un ERP, il faut vérifier que l'on ne se trompe pas de problème. L'audit digital et la Business Intelligence (BI) ne sont pas des gadgets réservés aux grandes entreprises : ce sont des outils de « test de réalité » pour tout dirigeant qui refuse de miser son budget sur de simples suppositions.

Deux exemples où l'intuition se trompait

• Le restaurateur de Saint-Pierre. Convaincu que son manque de réservations venait de sa visibilité en ligne, il s'apprêtait à investir 8 000 € dans un nouveau site et du référencement. L'audit de ses données a montré que son taux de conversion « visiteur vers réservation » était excellent. Le vrai problème : sa capacité d'accueil aux heures de pointe et un système de réservation qui gérait mal les créneaux. Les 8 000 € ont été économisés et réorientés vers un outil de gestion des réservations à 50 € par mois.
• L'artisan du bâtiment. Hésitant entre les réseaux sociaux et un système de devis automatisé, il penchait pour les réseaux sociaux parce que « tout le monde lui dit que c'est incontournable ». Dix-huit mois de données de prospection ont montré que 70 % de ses chantiers venaient de recommandations directes, et que son vrai goulot d'étranglement était le délai de réponse aux demandes de devis : trois jours en moyenne, contre quelques heures chez ses concurrents.

Construire un scénario testable

Un scénario testable tient en trois éléments :

1. L'hypothèse : « si je fais X, alors Y devrait se produire ».
2. Les indicateurs : ce qui permettra de valider ou d'invalider l'hypothèse.
3. Le seuil de décision : à partir de quel résultat l'action est-elle un succès ?

La plupart des projets de transformation numérique échouent parce qu'ils sautent cette étape. On lance un site, une campagne ou un outil sans avoir défini ce qui constituerait un succès, et six mois plus tard, il est impossible de savoir si l'investissement a porté ses fruits.

Les trois pièges du conseil digital sans données

• Copier ce qui marche chez les autres. Une stratégie performante pour un concurrent peut être catastrophique pour vous : votre structure de coûts, votre positionnement et votre clientèle sont différents.
• Céder aux sirènes technologiques. Chatbots, IA, automatisation extrême : ces outils ont leur utilité, mais elle n'est pas universelle.
• L'effet tunnel. Une fois engagé dans un projet coûteux, il est difficile d'admettre qu'il ne fonctionne pas. Des indicateurs définis à l'avance donnent des critères objectifs pour ajuster la stratégie, ou l'abandonner sans culpabilité.

Si vous hésitez sur la manière d'aborder un investissement, mon article Digitaliser son entreprise : un investissement, pas une dépense détaille l'état d'esprit à adopter.

Pourquoi la décision de changer d'ERP est toujours repoussée

Demandez à dix dirigeants de PME ce qu'ils pensent de leur ERP : neuf vous diront qu'il ne suit plus et qu'il faudrait en changer. Demandez-leur quand ils comptent le faire : la réponse sera presque toujours « on en parlera l'année prochaine ». Dans cette mission, la décision a été repoussée pendant des mois. Comme partout.

Les cinq raisons qui se renforcent les unes les autres

1. Le coût visible. Un changement d'ERP coûte rarement moins de quelques dizaines de milliers d'euros. Concentré dans le temps, ce poste fait peur.
2. Le vendor lock-in. Plus on reste 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 : beaucoup à porter pour une petite structure.
4. L'absence de « moment idéal ». 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. Le plus pernicieux : il soulage juste assez pour que la douleur ne soit plus insupportable. L'urgence redescend, la décision attend.

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. On choisit un ERP, on y entre ses données, on forme l'équipe, on adapte ses processus. Cinq ans plus tard, partir signifie 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 verrouillant de l'entreprise, parce qu'il touche à tout : finance, stocks, ressources humaines, ventes, achats. Plus l'usage est dense, plus le mur de sortie est haut. Ce n'est pas un complot des éditeurs, c'est une mécanique.

Quand l'impossibilité de mesurer est déjà un diagnostic

La BI est une excellente méthode pour la plupart des projets de digitalisation. Pour un ERP, elle bute sur un mur particulier : si votre ERP actuel ne permet même pas de produire les données qui valideraient le besoin de le remplacer (exports incomplets, rapports illisibles, croisements impossibles), alors cette incapacité est elle-même le diagnostic.

C'est exactement ce que je voyais ici : impossible de sortir une vision globale des stocks sans plusieurs jours de travail manuel sous Excel. D'où une montée en méthode à trois niveaux :

Comment la décision s'est débloquée

Après plusieurs mois de pansement, nous nous sommes posé une question simple, en face à face : « qu'est-ce qui nous coûte le plus cher : changer, ou continuer comme ça ? » Quand nous avons 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 devenu la plus coûteuse.

Un élément de calendrier a renforcé cette logique : la réforme de la facturation électronique. Depuis le 1er septembre 2026, toutes les entreprises assujetties à la TVA doivent pouvoir recevoir des factures électroniques, et les PME devront en émettre à partir du 1er septembre 2027. Une échéance de ce type ne laisse plus la place à l'éternel report (j'en parle dans Facture électronique 2026 : ce que chaque TPE et PME réunionnaise doit préparer).

Pourquoi j'ai recommandé Odoo, et pourquoi on passe par un POC

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

Pourquoi Odoo

Quand j'ai exploré le marché des 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é : un code accessible, des données ouvertes, et beaucoup moins de vendor lock-in qu'avec un éditeur propriétaire.
• Une communauté en forte croissance. Odoo s'impose comme alternative aux acteurs historiques (Sage, EBP, Cegid), avec un écosystème de partenaires et de modules tiers devenu massif.
• Une modularité réelle, pas juste marketing. On active ce dont on a besoin (caisse magasin, gestion de stock, comptabilité), puis on étend (CRM, RH, e-commerce). On paie ce qu'on utilise.
• Un retour terrain. 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.

C'est un choix adapté à ce contexte, pas une recommandation universelle : la bonne solution dépend de vos processus, et c'est précisément ce que le POC permet de vérifier.

Le POC : tester avec vos vraies données

Avant de signer un engagement pluriannuel, on lance un POC (Proof of Concept, ou « preuve de concept ») fonctionnel. Pendant quelques semaines, on simule sur le nouvel ERP les flux réels de l'entreprise : caisse magasin, gestion de stock, comptabilité avec factures fournisseurs.

Pas une démonstration édulcorée par l'éditeur : un vrai test de réalité, avec leurs données, leurs cas particuliers et leurs habitudes d'équipe. Si ça passe, on bascule. Si des points bloquants apparaissent, mieux vaut les voir maintenant qu'après avoir signé. C'est le principe « tester avant d'investir » appliqué à la décision la plus lourde qu'une PME ait à prendre sur son système d'information. À la fin de ma série, en mai 2026, ce POC était en cours.

Le plus dur n'est pas technique

On pourrait croire que le plus dur est fait quand le POC démarre. Ce serait une erreur. 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.

Ce que je ferais différemment dès le premier jour

Quand j'ai démarré cette mission, j'étais freelance depuis quelques semaines. J'avais l'expertise technique, et la posture de conseil dans la tête, sans encore l'avoir tout à fait dans les réflexes. Avec le recul, voici cinq choses que je referais autrement, et ce que je fais aujourd'hui.

1. Ne pas répondre à la question posée

Le client me demandait un outil de gestion de stocks. Le vrai problème : un ERP installé cinq ans plus tôt, qui ne suivait plus la croissance de l'entreprise. J'ai livré un SaaS qui a soulagé l'opérationnel, mais j'ai aussi conforté un statu quo : tant que la douleur restait gérable, la vraie décision pouvait continuer à être repoussée.

Ce que je fais maintenant : avant de proposer quoi que ce soit, je passe deux ou trois rendez-vous à reformuler la demande. Pas pour la disqualifier, mais pour la replacer dans le système d'information complet. « Il nous faut un outil pour X » est presque toujours le symptôme d'une question plus large que personne n'a osé formuler.

2. Chiffrer le coût du statu quo dès la première semaine

J'ai compris l'ampleur du temps perdu (385 heures par an) plusieurs semaines après mon arrivée. Posé sur la table dès le début, ce chiffre aurait permis de comparer beaucoup plus tôt le coût d'un changement d'ERP et celui de continuer comme avant.

Ce que je fais maintenant : dès le cadrage, je calcule le coût du statu quo. Pas celui de l'outil défaillant, mais celui des contournements, des décisions prises en retard et des heures non facturables qui s'accumulent. Ce chiffre est rarement demandé, et presque toujours décisif.

3. Auditer l'infrastructure avant tout le reste

J'avais supposé que les bases étaient saines. Cette supposition m'a coûté plusieurs semaines de travail qui auraient pu être évitées.

Ce que je fais maintenant : quatre questions avant la signature du devis.

• Un site ou plusieurs ? Quelle qualité de connexion sur chacun ?
• Le client connaît-il son infrastructure actuelle, et comment est-elle structurée ?
• Les sauvegardes existantes ont-elles déjà été testées en conditions réelles ?
• Qui est l'interlocuteur technique en cas de souci : une personne précise, joignable, identifiée ?

Sans réponse claire, je ne propose pas de feuille de route : je propose d'abord un audit d'infrastructure. C'est moins glamour à vendre, mais ça évite de construire sur du sable.

4. Cesser de croire que le problème est technique

Pendant longtemps, j'ai cherché la solution dans le bon outil : le bon SaaS, le bon paramétrage, les bonnes requêtes, le bon design. Or le problème était une organisation entière qui avait évolué sans que son système d'information suive : plusieurs canaux de remontée d'information, plusieurs sources de vérité, des Excel manuels devenus la référence. Aucun outil ne corrige ça. Il faut revoir les flux, les rôles, les règles de saisie, la hiérarchie des sources.

Ce que je fais maintenant : je n'attaque jamais un projet sans cartographier, même grossièrement, les flux d'information existants. Qui saisit quoi ? Qui décide à partir de quoi ? Où sont les Excel-pansements qui tournent en parallèle ? (Sur ce point, voir aussi comment travailler avec un développeur : comprendre le fonctionnement actuel avant de proposer une solution.)

5. Poser une deadline et des seuils de décision dès le départ

L'effet tunnel, c'est continuer un projet par inertie, parce qu'on a déjà investi et que personne ne veut être celui qui dit stop. Sur cette mission, je n'ai pas fixé de seuils. Le SaaS pansement est resté en place plus longtemps qu'il n'aurait dû, parce qu'aucun de nous deux n'avait écrit : « on bascule sur autre chose si, à telle date, on n'a toujours pas X et Y ». Au final, la décision a été prise après plusieurs incidents techniques, qui ont fait comprendre au client l'intérêt de mes recommandations. Ne pas mettre de date sur des points aussi stratégiques, et attendre, ce n'est pas du conseil : c'est de l'attentisme.

Ce que je fais maintenant : à la fin de chaque cadrage, je formule un point de bascule écrit. À telle date, ou si tel indicateur passe tel seuil, on rouvre la décision. Court, posé, partagé.

La leçon qui résume les autres

Ces cinq erreurs ont la même racine : j'ai répondu à la demande du client au lieu de poser les questions qui auraient permis de la formuler correctement. J'avais l'expertise. Il me manquait la rigueur de la phase amont.

C'est la zone où je vois le plus de TPE et de PME se tromper aujourd'hui. Pas parce que les éditeurs sont mauvais, ni parce que les équipes sont incompétentes, mais parce que le moment où il faut être lent et exigeant, celui où l'on choisit ce dans quoi on va vivre cinq ans, est presque toujours expédié en deux réunions.

Votre plan d'action avant de choisir ou de changer d'ERP

Voici la méthode que j'applique aujourd'hui, dans l'ordre :

FAQ : changer d'ERP en PME

Quand faut-il changer d'ERP ?

Quand l'écart entre ce que fait l'ERP et ce dont l'entreprise a réellement besoin est devenu structurel : vision globale impossible sans plusieurs jours d'Excel, sources de vérité multiples, chiffres de la direction et du terrain qui ne concordent pas. Si seules quelques briques posent problème, une montée de version, un module complémentaire ou une intégration externe peuvent suffire. La bonne question n'est pas « mon ERP est-il vieux ? » mais « que me coûte-t-il de continuer comme ça ? ».

Un SaaS complémentaire peut-il remplacer le changement d'ERP ?

Il peut soulager l'opérationnel à court terme, et c'était la bonne décision dans ce cas. Mais ajouter un outil sur un système d'information contraint traite les symptômes, pas la cause. Utilisé comme solution définitive, il risque surtout de repousser la décision de fond. C'est pourquoi je recommande une stratégie en deux temps, avec une date ou un seuil pour rouvrir la décision.

Combien coûte un POC ERP et combien de temps dure-t-il ?

Pour une TPE ou une PME, un POC bien cadré coûte généralement entre 2 000 et 8 000 €, pour une durée de quatre à huit semaines, selon le périmètre testé et la complexité des scénarios métier. Plus court, c'est une démonstration ; plus long, c'est déjà un mini-projet de déploiement. Ce sont des ordres de grandeur, sans commune mesure avec le coût d'un déploiement raté, qui peut se chiffrer en dizaines de milliers d'euros.

Combien coûte un audit digital pour une TPE ?

Un audit sérieux prend entre une demi-journée et deux jours, pour un coût généralement compris entre 500 et 2 000 € pour une TPE. Il faut disposer d'au moins douze mois de données de ventes ou de facturation, des statistiques du site web s'il y en a un, et des sources d'acquisition clients, même approximatives.

Qu'est-ce que le vendor lock-in d'un ERP ?

C'est le verrouillage progressif d'une entreprise sur la solution qu'elle utilise : à force d'y accumuler des données, des paramétrages et des habitudes d'équipe, partir devient de plus en plus coûteux. L'ERP est particulièrement concerné, car il touche à la finance, aux stocks, aux ventes, aux achats et aux ressources humaines. Une solution open source comme Odoo limite ce risque (code accessible, données ouvertes), sans le supprimer.

Faut-il auditer l'infrastructure avant un projet de système d'information ?

Oui, idéalement avant même de choisir l'outil. Un état des lieux simple suffit au départ : où les données sont stockées, comment les équipes se connectent, si les sauvegardes ont déjà été testées en restauration, et qui intervient en cas de panne. Sur l'un de mes projets, un routeur vieillissant, remplacé pour moins de 800 €, a fait perdre quatre mois à une entreprise.

Conclusion : appelez quelqu'un avant que le projet ne tienne plus

Si je devais résumer ce retour d'expérience en une phrase : le bon moment pour appeler quelqu'un de l'extérieur, ce n'est pas quand le projet ne tient plus. C'est avant qu'il commence.

Si vous vous reconnaissez dans cette histoire (l'ERP qu'on aurait dû changer il y a deux ans, le système d'information qui retarde toutes vos décisions, le projet de digitalisation repoussé parce qu'on ne sait pas par où commencer), c'est précisément le moment où je peux vous être utile.

Je propose un diagnostic gratuit de 30 minutes. Vous m'expliquez votre contexte, je vous renvoie une vision claire : où sont les vrais leviers, où sont les angles morts, par quoi commencer. Sans engagement, sans devis caché. Une conversation honnête entre quelqu'un qui a fait les erreurs racontées ici et quelqu'un qui peut vous éviter de les refaire.

➡️ Réserver 30 minutes →

Pour aller plus loin : ce que fait vraiment une entreprise de logiciels pour votre business à La Réunion et mes services d'accompagnement en digitalisation.