Un jeudi de mars, à Bouaké, dans le bureau d’un dépôt de boissons. Le logiciel a été payé il y a quatorze mois. Sur l’écran, le stock affiche 412 casiers ; dans la cour, le magasinier en compte 380, et c’est lui qui a raison. Personne ne saisit plus les entrées depuis la saison des pluies. Le cahier à couverture rouge, lui, est à jour. Le gérant ne cherche pas un coupable : il cherche la date exacte à laquelle son projet est mort. Un échec de projet ERP en PME en a toujours une, et ce n’est jamais celle qu’on croit.
Ce genre de projet ne s’arrête presque jamais sur une panne. Il commence par une saisie qu’on saute un soir d’affluence, se poursuit par un paramétrage que plus personne ne sait modifier, et s’achève le jour où l’écran et le magasin cessent de dire la même chose. Voici les six causes dans l’ordre où elles arrivent réellement, les signaux qui les annoncent, la stratégie de déploiement qui correspond à votre profil, et de quoi rattraper un projet en train de dériver. Y compris quand l’outil n’est pas le nôtre.
L’abandon ne commence jamais par une panne
Un logiciel de gestion ne tombe pas en panne : il se vide. La première semaine, tout est saisi, les écrans sont beaux, on montre le tableau de bord aux visiteurs. Au deuxième mois, deux livraisons ne sont pas entrées le jour même. Au quatrième, l’inventaire ne tombe plus juste et personne ne sait pourquoi. Au sixième, la question « combien il m’en reste ? » se pose au magasinier, plus à l’ordinateur. Le logiciel fonctionne toujours parfaitement. Il ne sert plus à rien.
Un outil de gestion n’est presque jamais abandonné par décision. Il est abandonné par omission, un soir d’affluence, puis tous les autres soirs.
C’est ce qui rend le diagnostic difficile : il n’y a pas d’événement. Pas de facture d’assistance, pas de message d’erreur, pas de réunion de crise. Juste une décision minuscule, répétée, de faire sans. Et comme il n’y a pas d’événement, il n’y a pas non plus de décision inverse : on ne résilie même pas. On paie encore, longtemps après avoir arrêté de s’en servir.
Les six causes, dans l’ordre où elles arrivent
Elles s’enchaînent presque toujours dans le même ordre, et chacune rend la suivante plus probable. Cette chronologie n’est tirée d’aucune étude : c’est ce que nous voyons le plus souvent sur le terrain, la demi-journée de formation comprise. Repérez à quel étage vous êtes, et vous saurez ce qu’il reste à sauver.
-
Mois 0 On achète pour « plus tard » Le choix se fait sur la deuxième boutique, l’export vers le Mali, la comptabilité analytique. Rarement sur la semaine en cours. On paie un périmètre qu’on n’utilisera pas, et il alourdit celui qu’on utilise.
-
Semaine 1 Le paramétrage est délégué Taxes, unités, dépôts, droits d’accès, modèles de documents. Une personne fait tout, souvent bien. Personne n’écrit pourquoi tel champ a été rendu obligatoire.
-
Semaine 2 La formation tient en une demi-journée On forme le gérant plutôt que la personne qui saisit, sur des données de démonstration plutôt que sur les vraies, et on ne reforme jamais celui qui arrive au sixième mois.
-
Mois 2 Les entrées de stock décrochent La livraison arrive à onze heures, trois clients attendent au comptoir. La saisie attendra ce soir, puis demain. Le stock théorique commence à vivre sa vie.
-
Mois 4 Le premier écart détruit la confiance L’écran dit 412, la cour dit 380. Un écart qu’on n’explique pas dans la journée devient une raison permanente de ne plus croire l’écran, sur tout le reste aussi.
-
Mois 6 Le référent s’en va Avec lui part la seule personne qui savait où étaient les réglages. L’équipe ressort le cahier « en attendant », et cette attente n’a pas de fin prévue.
Regardez cette liste : aucune de ces six causes n’est technique. Aucune n’aurait été évitée par un logiciel plus puissant, et plusieurs auraient été aggravées par lui. C’est d’ailleurs pour cela qu’un projet trop ambitieux échoue plus souvent qu’un projet modeste : il multiplie les endroits où l’on peut cesser de saisir. Si vous n’êtes pas sûr du périmètre que vous avez acheté, relisez ce qui sépare un ERP d’un logiciel de gestion commerciale et d’une caisse avant de relancer quoi que ce soit.
Échec projet ERP PME : ce que dit une étude datée, et ce qu’elle ne dit pas
Cherchez « taux d’échec des ERP » et vous trouverez des pourcentages spectaculaires, rarement attribués, presque jamais datés. Nous n’en reprendrons aucun. Une seule source identifiable et datée a été retenue ici, et son périmètre doit être posé avant ses résultats, sinon le chiffre ment.
Il s’agit du 2026 ERP Report du cabinet américain Panorama Consulting Group. Les données ont été collectées de janvier 2025 à janvier 2026 auprès de 170 répondants, dont 56,5 % d’organisations multinationales, pour un chiffre d’affaires annuel médian de 200,5 millions de dollars. Autrement dit : ce ne sont ni des quincailleries de Thiès ni des dépôts de boissons de Bouaké. Ce sont de grandes entreprises, avec une direction de projet, un budget et des consultants.
- Plus d’un quart des organisations déclarent un projet au-dessus du budget.
- Près d’un quart déclarent un projet en retard sur le calendrier.
- Parmi celles qui sont en retard, la raison la plus fréquente est d’ordre organisationnel : gouvernance, résistance au changement, refonte des processus.
- Moins d’un quart déclarent une attention intense portée à l’accompagnement du changement.
- La durée médiane d’un projet y est de neuf mois.
Retenez la troisième ligne. Quand des entreprises à deux cents millions de dollars de chiffre d’affaires dérapent, ce n’est pas la machine qui les retarde : c’est la gouvernance, la résistance au changement et la refonte des processus. À votre échelle, ces trois mots portent des noms beaucoup plus simples : qui décide, qui saisit, qui vérifie. Si vous ne pouvez pas répondre aux trois avec un prénom, le projet n’a pas encore commencé.
Big bang, module par module, pilote : trois stratégies, trois profils
La façon dont on allume l’outil compte autant que l’outil. Trois stratégies existent, et la bonne dépend de votre taille et de votre nombre de points de vente, pas de votre ambition. Le rapport cité plus haut note d’ailleurs que plus d’un quart des organisations interrogées — de grandes entreprises, souvent multi-entités — ont adopté une approche hybride, plutôt que purement progressive ou purement big bang : elles démarrent d’un coup un noyau ou une entité pilote, puis étalent le reste. Cette proportion ne dit rien de votre boutique et nous ne la transposerons pas. Elle dit seulement une chose utile : les trois colonnes ci-dessous se mélangent souvent, et rien ne vous oblige à en choisir une pure.
| Au quotidien | Big bang | Module par module | Pilote sur un point de vente |
|---|---|---|---|
| Délai avant le premier bénéfice visible | ✗ | ✓ | ± |
| Risque le jour de la bascule | ✗ | ✓ | ✓ |
| Charge de formation par vague | ✗ | ✓ | ± |
| Cohérence des chiffres pendant la transition | ✓ | ✗ | ✗ |
| Ce que coûte un échec | ✗ | ± | ✓ |
| Une seule boutique, moins de 100 références | ✓ | ± | ✗ |
| Trois boutiques et un dépôt | ✗ | ± | ✓ |
| Disponibilité exigée du dirigeant | ✗ | ✓ | ± |
Aucune colonne n’est cochée. Celle du milieu convient au cas le plus fréquent : un commerce de cinq à quinze personnes, un ou deux points de vente, quelques centaines de références. Elle n’est pas la bonne pour tout le monde, et le tableau le dit sans détour. Une boutique de prêt-à-porter tenue à deux, avec quatre-vingts références, n’a rien à gagner à étaler : elle bascule le week-end de la fermeture annuelle, et c’est réglé. Un réseau de trois boutiques et d’un dépôt, lui, a tout intérêt au pilote : on choisit le site le plus calme, on y échoue si l’on doit échouer, et les deux autres héritent d’un paramétrage déjà corrigé.
Une règle vaut pour les trois : la cohérence des chiffres est le point faible de tout déploiement étalé, et c’est la ligne que le big bang gagne franchement. Pendant les semaines où deux systèmes cohabitent, écrivez sur une feuille quel système fait foi pour le stock et quel système fait foi pour la caisse, affichez-la au mur, et ne changez pas d’avis en cours de route. Si vous partez d’un tableur, le plan de bascule en sept jours propose un découpage déjà éprouvé.
Les signaux avant-coureurs, et quoi faire la semaine où vous les voyez
Un projet ne meurt pas d’un coup, donc il prévient. Voici les sept signaux qui précèdent l’abandon, avec la parade à appliquer dans la semaine, pas au prochain trimestre.
-
Un écart de stock inexpliqué traîne depuis plus d’une semaine. Parade : inventaire partiel sur les vingt références qui tournent le plus, et rien d’autre ce jour-là.
-
Quelqu’un ressaisit le soir ce qui a été noté sur un cahier dans la journée. Parade : supprimez l’un des deux supports cette semaine, jamais « bientôt ».
-
Une seule personne sait modifier un paramétrage. Parade : faites-lui écrire sur une page les taxes, les unités, les dépôts et les droits, pendant qu’elle est encore là.
-
Plus personne n’ouvre les rapports, même pas le lundi matin. Parade : un seul rapport, une seule fois par semaine, lu à voix haute devant l’équipe.
-
On répond à un client en regardant le rayon plutôt que l’écran. Parade : traitez-le comme une panne et cherchez la saisie manquante, pas le coupable.
-
Un module payé n’a jamais été ouvert depuis la mise en route. Parade : descendez de palier plutôt que de continuer à payer une intention.
-
La formation d’un nouvel arrivant se fait par-dessus l’épaule d’un collègue. Parade : une fiche d’une page par geste courant, refaite à chaque arrivée.
Le signal le plus sérieux est le deuxième. La double saisie n’est pas une organisation de transition : c’est un compte à rebours, et c’est toujours le logiciel qui perd, parce que le cahier ne tombe jamais en panne et ne demande jamais de mot de passe. Si vous en êtes là, les signes qu’un commerce a dépassé le cahier et le tableur se lisent aussi à l’envers : ils disent ce que votre outil devait remplacer et ne remplace plus.
Un outil plus petit qu’on alimente vaut mieux qu’un grand qu’on abandonne
La réponse à un projet qui dérape n’est presque jamais un outil de plus. C’est un périmètre de moins. Le rapport cité va dans ce sens, même pour de grandes structures : plus de la moitié des organisations interrogées ont amélioré quelques processus clés, plutôt que la plupart des processus ou aucun. À l’échelle d’un commerce, cela se traduit simplement : choisissez les deux gestes que vous répétez trente fois par jour, tenez-les à cent pour cent pendant trois mois, et n’ouvrez le troisième qu’après. C’est la méthode d’un premier outil, celle que suit le passage du cahier au logiciel de gestion — on commence par ce qu’on tiendra.
Le bon périmètre n’est pas celui qui couvre votre entreprise. C’est celui que votre équipe alimentera encore un samedi de forte affluence.
Cela vaut aussi pour le choix du palier tarifaire, et chez nous comme ailleurs. Chez Wurus, le Pack Business à 19 500 FCFA par mois ouvre la caisse, les transferts et ajustements de stock, les devis, les dépenses et les rapports ; la comptabilité et le CRM n’arrivent qu’au Pack Enterprise, à 150 000 FCFA par mois. Payer le palier haut pour une comptabilité que personne ne tiendra, c’est reprendre la première cause par le début. Un palier se monte quand un module déborde, pas quand on l’espère : la grille complète est publiée, et elle se relit tous les six mois.
Et si le calcul vous paraît abstrait, faites-le à l’envers. Douze mois de Pack Business au tarif mensuel représentent 234 000 FCFA (19 500 × 12). Ce montant est identique que l’outil soit alimenté tous les jours ou plus du tout depuis mars. Un abonnement abandonné ne coûte pas moins cher qu’un abonnement utilisé : il coûte exactement pareil, plus le temps passé à tenir le cahier à côté. Avant de relancer, passez les vingt questions à poser avant de choisir un logiciel de gestion sur l’outil que vous avez déjà : la moitié des réponses expliquera l’abandon.