Choisir un ERP pour une PME : une démarche en sept étapes

Pour choisir un ERP, commencez par les problèmes opérationnels à résoudre et les preuves attendues. Une liste de fonctions ou une démonstration commerciale ne suffit pas. Formalisez vos processus, consultez sur un périmètre commun, testez les exceptions et comparez le coût total. La décision doit aussi tenir compte des ressources que votre équipe peut consacrer au projet.

Formuler un problème observable

Remplacez « moderniser la gestion » par une difficulté concrète : ressaisie entre commandes et factures, stock difficile à rapprocher ou validation dispersée. Décrivez où elle survient, qui la traite et ce qui permettrait de constater une amélioration. Il ne faut pas inventer un gain chiffré pour justifier le projet. Recueillez plutôt un petit échantillon de situations réelles et leur traitement actuel. Cette base permettra de vérifier que le futur système répond au problème, même si sa présentation visuelle est moins spectaculaire que celle d’un concurrent.

Cadrer un premier périmètre réalisable

Déterminez les processus indispensables au lancement, les équipes concernées et les interfaces nécessaires. Écartez les fonctions simplement séduisantes lorsqu’aucun usage n’est défini. Un périmètre réduit ne doit toutefois pas couper une opération au milieu sans prévoir la suite. Si la comptabilité reste dans un autre outil, décrivez le passage des données et les contrôles. Indiquez les limites acceptables et celles qui rendent une offre irrecevable. Faites valider ces choix par les personnes qui exécuteront les opérations, pas uniquement par la direction ou le service informatique.

Consulter sur une base commune

Envoyez aux prestataires une même description des besoins, des données, des volumes et des responsabilités attendues. Demandez des réponses structurées : standard, paramétrage, extension, développement ou absence de couverture. Chaque réponse doit renvoyer à un exemple ou à une preuve. Les offres peuvent proposer des architectures différentes ; votre travail consiste à comprendre leurs conséquences, pas à imposer artificiellement la même solution. Exigez des coûts séparés pour le lancement, le récurrent et la sortie. Listez les réserves et les hypothèses qui empêchent encore de comparer.

Éprouver les offres sur vos scénarios

Préparez des jeux d’essai anonymisés et un déroulé identique. Montrez les cas ordinaires, mais aussi un retour, un rejet de données ou une absence du valideur. Observez les manipulations, les contrôles et les étapes manuelles. Demandez au fournisseur de préciser la version et les composants utilisés. Une démonstration préparée sur une édition différente peut ne pas représenter ce qui est chiffré. Consignez les résultats sans transformer une impression favorable en note technique. Une fonction non démontrée reste à confirmer, même si elle apparaît dans la brochure.

Décider puis préparer l’exécution

Rapprochez la couverture fonctionnelle, les coûts et les risques. Distinguez critères éliminatoires et préférences. Une moyenne pondérée ne doit pas masquer un défaut bloquant. Présentez les écarts, les conditions de réussite et les engagements encore attendus. La décision finale doit désigner un responsable de projet, un budget et des règles de changement. Avant de signer, examinez la reprise, la recette, le support et la sortie. Faites intervenir les professionnels compétents pour les questions contractuelles, comptables ou de protection des données qui dépassent votre capacité d’évaluation.

Exemple de travail

Exemple de décision illustratif : deux offres couvrent la vente et les achats. L’offre A nécessite une interface de stock, tandis que B reprend ce processus dans le périmètre proposé. Avant de comparer leurs prix, décrivez les délais de synchronisation acceptables et le traitement d’un retour. Si A ne sait pas démontrer le rapprochement des stocks, la réserve est fonctionnelle, pas seulement financière. Inversement, B peut demander davantage de formation ou de reprise. Le dossier de choix doit montrer ces différences et les conditions de leur résolution. Aucun nombre de fonctions affichées ne permet, à lui seul, de conclure.

Fiche de vérification

Élément	Question à documenter	Preuve ou responsable
Besoin	Problème et résultat attendu	Responsable métier
Consultation	Réponse à périmètre commun	Hypothèses visibles
Démonstration	Scénarios et exceptions	Compte rendu
Décision	Coût et réserves	Conditions de lancement

À faire dans votre équipe

Préparez une page de synthèse comportant trois décisions : ce qui doit fonctionner au premier jour, ce qui peut être différé et ce qui ne sera pas traité. Pour chaque élément obligatoire, associez un scénario et un responsable de validation. Demandez ensuite aux équipes si elles pourraient travailler avec ce périmètre pendant une période de transition. Les réponses révèlent souvent une dépendance oubliée, par exemple un export vers le comptable ou un accès de remplacement. Intégrez ces dépendances avant la consultation. Cette étape évite que le choix d’un logiciel précède la compréhension du travail et que le projet se transforme ensuite en suite d’options ajoutées dans l’urgence.

Questions fréquentes

Faut-il commencer par une liste d’éditeurs ?

Commencez par vos besoins et vos contraintes. Une liste de produits devient utile lorsque vous disposez d’un cadre permettant de poser les mêmes questions à chacun.

Une petite équipe peut-elle suivre cette méthode ?

Oui, en adaptant les documents à la taille du projet. Quelques scénarios bien choisis et des responsabilités claires peuvent être plus utiles qu’un dossier volumineux jamais relu.

Quand demander un avis externe ?

Lorsque vous ne pouvez pas apprécier un engagement technique, juridique ou comptable important. Le conseil doit répondre à une question précise et rester indépendant de votre décision commerciale.

Pour poursuivre

Sources et portée

Microsoft — options de licence Business Central — référence officielle consultée le 30 octobre 2026.

Les démarches, tableaux et scénarios sont des propositions de méthode propres à ce guide. La référence officielle permet de vérifier les conditions ou notions mentionnées ; elle ne valide pas les hypothèses chiffrées illustratives et ne constitue pas un classement de produits.