ERP sur mesure pour PME : quand ça vaut le coup (et quand non)

Qu'est-ce qu'un ERP, et qu'est-ce qui change sur mesure ?

Un ERP fait circuler la même information entre tous les services : une commande client déclenche une réservation de stock, un ordre de production, une facture et une écriture comptable, sans ressaisie. C'est cette circulation qui distingue un ERP d'une collection de logiciels métier juxtaposés.

Sur mesure, ce sont vos règles de gestion qui pilotent ces enchaînements. Un ERP du marché impose les siennes : ses statuts, ses documents, sa façon de calculer un prix de revient. Tant que votre métier correspond à ce que l'éditeur a modélisé, c'est un avantage — vous héritez de bonnes pratiques. Dès qu'il s'en écarte, cela devient une contrainte.

La règle des 80 % : le seul critère qui compte vraiment

Avant de comparer les prix, faites cet exercice : listez vos processus principaux et évaluez honnêtement la part que couvre un ERP du marché sans développement spécifique.

ERP sur mesure ou Odoo : la comparaison honnête

Odoo est un excellent produit, et nous le recommandons régulièrement. Son écosystème de modules couvre la plupart des besoins standards, et sa communauté garantit une pérennité que peu d'éditeurs offrent.

Sa limite apparaît quand vos processus s'écartent du modèle. Réécrire le cœur d'un module standard vous fait payer deux fois : le développement d'abord, puis la dette à chaque mise à jour. À partir de ce point, le sur mesure redevient plus économique — et surtout plus stable.

Combien coûte un ERP sur mesure pour une PME ?

Le prix se raisonne par module, jamais globalement. Un premier module en production coûte 15 000 à 25 000 €. Un ERP couvrant quatre à cinq périmètres se situe entre 45 000 et 90 000 €, étalés sur douze à dix-huit mois.

Cet étalement n'est pas une facilité de paiement : c'est la méthode elle-même. Chaque module est mis en service, utilisé, mesuré, avant que le suivant ne commence. Vous pouvez interrompre le programme à tout moment sans perdre ce qui est déjà en production.

Par quel module commencer ?

La réponse n'est pas « par la base » mais « par ce qui coûte le plus de temps aujourd'hui ». Le module qui produit le gain le plus visible finance politiquement la suite du programme.

• Gestion commercialeDevis, commandes, bons de livraison, facturation. Bon premier module quand la saisie commerciale est manuelle ou éclatée entre plusieurs fichiers.
• Stocks et logistiqueEntrées et sorties, multi-dépôts, seuils d'alerte, traçabilité. Souvent le meilleur point de départ dans l'industrie et la distribution : le gain est immédiatement chiffrable.
• Production et planificationNomenclatures, ordres de fabrication, charge des ressources. Le module le plus complexe : à aborder une fois le socle de données en place.
• Achats et fournisseursDemandes d'achat, commandes, réceptions partielles, rapprochement des factures. Bon second module, parce qu'il s'appuie sur les articles déjà modélisés.

Un point technique décide de la réussite du programme : le modèle de données commun. Articles, tiers, documents, mouvements — cette structure partagée par tous les modules détermine si l'ERP pourra grandir ou devra être réécrit au troisième module. C'est l'étape sur laquelle il ne faut pas économiser.

Trois cas où il ne faut pas développer d'ERP

• Vous cherchez d'abord à faire des économiesUn ERP ne réduit pas les coûts à court terme : il coûte, puis fait gagner du temps. Si la motivation principale est budgétaire, le retour sur investissement sera décevant et le projet abandonné en cours de route.
• Vos processus ne sont pas écritsInformatiser un processus flou produit un logiciel flou. Si personne ne sait décrire précisément comment une commande est traitée aujourd'hui, commencez par l'écrire — c'est souvent là que se trouvent les vrais gains, avant tout développement.
• Personne ne pilotera le projet en interneUn ERP se construit avec les équipes métier, sur plusieurs mois. Sans un référent disponible pour arbitrer et faire tester, le projet dérive quel que soit le prestataire. C'est la première cause d'échec, loin devant la technique.

Il existe souvent une solution intermédiaire plus rentable : garder vos outils actuels et développer uniquement les automatisations qui les relient. Cette approche est détaillée dans notre article sur l'automatisation des processus.

Questions fréquentes