Déploiement et implémentation ERP

3 things to do before choosing a manufacturing ERP

18/6/2026
  |  
Alex Barroux
Sommaire
Merci pour votre inscription à la newsletter Bonx ! Nous vous contacterons si nous pensons que notre contenu vous correspond.

La plupart des processus d'achat d'ERP s'alourdissent trop tôt. Les équipes rédigent de longs documents de besoins, comparent des grilles de fonctionnalités, assistent à des démonstrations soignées et vérifient si le système intègre des modules de planification, d'achats et de reporting (oui, oui et oui !). Ces questions ne sont pas mauvaises, mais elles sont trop génériques pour vous aider à choisir le bon ERP.

Un ERP industriel doit gérer le cœur opérationnel de l'entreprise : gestion des commandes, stocks, achats et gestion des fournisseurs, planification, production, qualité et logistique. Si le processus de sélection ne part pas de là, l'entreprise risque d'acheter un système qui semble complet en démonstration et déçoit pourtant les personnes qui doivent l'utiliser au quotidien.

Cet article vous propose trois choses concrètes à faire avant de choisir un ERP industriel : placer les opérations au centre, recenser les situations réelles que votre dispositif actuel ne gère pas bien, puis tester les éditeurs sur ces situations plutôt que sur une liste de contrôle générique.

1. Placer les opérations au centre, avec la finance dans la boucle

La finance doit bien sûr être associée à une décision ERP, même lorsqu'il s'agit d'un ERP industriel et non d'un ERP financier. L'équipe financière a besoin de chiffres fiables, de contrôles rigoureux, d'une visibilité sur les marges, d'une discipline achats, de reportings et des données qui alimentent in fine la comptabilité. Ces besoins sont légitimes, et les ignorer ne fait que créer des problèmes ensuite.

Pour autant, un ERP industriel ne doit pas être choisi comme si l'usine n'était qu'une source de données pour le reporting de fin de mois. Si la finance pilote seule le projet ERP, l'entreprise peut se retrouver avec un système solide sur le plan du contrôle mais défaillant au quotidien. Les chiffres seront peut-être plus propres, mais les planificateurs continueront à reconstruire leurs plannings hors système, les opérateurs continueront à saisir les données après coup, les commerciaux continueront à interroger la production pour des réponses que l'ERP devrait rendre visibles, les achats continueront à réagir trop tard parce que demande, stocks et contraintes fournisseurs ne sont pas suffisamment connectés, et ainsi de suite.

Les opérations doivent piloter la question de l'ERP industriel, car ce sont elles qui savent où le dispositif actuel cède sous la pression. En d'autres termes, les personnes en charge de la production, de la planification, des achats, de la qualité, des stocks, de la logistique et des engagements clients doivent définir ce que l'ERP doit rendre plus simple, plus rapide ou plus fiable.

La finance doit rester dans la boucle : elle apporte de la rigueur sur les données, la gouvernance, les coûts, les marges et le reporting. Mais le centre de gravité doit être opérationnel, car l'ERP industriel ne créera de valeur que si les personnes qui font tourner l'atelier peuvent l'utiliser dans leur façon de travailler au quotidien.

Cette distinction est encore plus importante pour les entreprises qui passent des tableurs à un ERP pour la première fois. Dans ces structures, le tableur existe souvent parce que les opérations ont dû inventer leur propre système bien avant que l'entreprise ne soit prête à en acheter un. Ne jetez pas ce savoir. Le tableur est peut-être fragile, mais il contient en général la logique que le futur ERP devra respecter et les scénarios (voir les sections suivantes !) que le nouveau logiciel devra bien gérer.

2. Recenser 3 à 5 situations opérationnelles que votre dispositif actuel ne gère pas bien

Comme évoqué en introduction, le réflexe dans un projet ERP est souvent de démarrer large, en détaillant tous les besoins et exigences. C'est là que beaucoup d'équipes se perdent. Elles tentent de cartographier chaque flux, de documenter chaque exception et de consigner chaque exigence possible avant même de parler aux éditeurs. Le résultat est généralement un document volumineux qui dit beaucoup et décide peu.

En pratique, il vaut souvent mieux commencer par trois à cinq situations opérationnelles que votre dispositif actuel ne gère pas bien. Ce dispositif peut être un ERP vieillissant, des tableurs, des outils no-code, du papier, ou un mélange de tout cela. L'enjeu est de trouver les endroits où un meilleur logiciel changerait clairement la donne, avec un retour sur investissement immédiat, avant d'élargir le périmètre si nécessaire.

Chez Bonx, par exemple, l'un de nos clients, un fabricant d'équipements d'éclairage, a fait exactement cela. L'entreprise n'a pas cherché à repenser l'ensemble de son activité avec l'ERP. Elle a commencé par un processus commercial suffisamment douloureux et suffisamment important pour être amélioré en premier. Cela a donné à la réflexion sur l'ERP une ancre concrète : non pas "quel système a le plus de modules ?", mais "quel système nous aide à mieux gérer ce processus ?"

Le résultat : une équipe de 10 ingénieurs commerciaux qui passaient tout leur temps à faire des devis et à échanger des emails avec leurs clients a récupéré environ 80 % de son temps pour développer vraiment le business. L'équipe est passée rapidement en production avec les agents de commandes de vente Bonx, ouvrant la voie à d'autres processus à traiter avec l'ERP une fois le succès démontré rapidement.

Une bonne situation opérationnelle n'est pas une fonctionnalité ERP, mais un moment réel dans l'entreprise où le système actuel cède, ralentit les équipes ou laisse trop de place à l'erreur. Voici quelques exemples courants de points de friction et de processus à améliorer :

  • Une commande client change après que la production a déjà commencé, et l'équipe doit recalculer manuellement quels stocks, achats, plannings et dates de livraison sont impactés.
  • Les commerciaux doivent savoir s'ils peuvent promettre une date de livraison, mais la réponse dépend des stocks, de la capacité, des lead times fournisseurs et de la mémoire du planificateur.
  • Un planificateur doit transformer manuellement les commandes ou les prévisions en ordres de fabrication.
  • L'ERP indique que le stock est disponible, mais le magasin ne fait pas confiance au chiffre sans vérifier sur place.
  • Un problème qualité bloque un lot, et personne ne peut immédiatement voir quelles commandes clients, expéditions ou étapes de production sont concernées.
  • Les achats découvrent les ruptures trop tard parce que demande, stocks et engagements fournisseurs ne sont pas reliés en un seul endroit.
  • Les opérateurs saisissent la production sur papier ou dans un tableur, puis quelqu'un d'autre met à jour le système plus tard.

Ces situations ancrent la discussion sur l'ERP dans le réel, en montrant où l'entreprise a besoin d'une meilleure coordination, de données plus fiables, de moins d'étapes manuelles ou de décisions plus claires, et là où l'ERP doit avoir le plus d'impact.

3. Tester des scénarios, pas des listes de fonctionnalités

Une fois que vous avez identifié les situations opérationnelles, utilisez-les. De nombreuses évaluations d'ERP retombent encore dans les listes de fonctionnalités. L'éditeur confirme que le système intègre MRP, achats, stocks, qualité, traçabilité, lecture de codes-barres, tableaux de bord, intégrations et reporting. Tout le monde coche les cases. La démonstration paraît convaincante.

Puis le système passe en production, et les vraies questions arrivent. Le planificateur voit-il ce qui a changé quand les commerciaux modifient une commande ? Les achats comprennent-ils quel retard fournisseur impacte quel ordre de fabrication ? La qualité peut-elle bloquer du stock sans le faire disparaître de la planification ? Les opérateurs peuvent-ils mettre à jour la production sans générer davantage de travail administratif ? Les commerciaux peuvent-ils obtenir une réponse fiable sans appeler trois personnes ?

Une liste de fonctionnalités répondra rarement à ces questions. Un test par scénario, si.

Reprenez les trois à cinq situations de la section précédente et demandez à chaque éditeur de les parcourir dans le système sous forme de flux complets et opérationnels, idéalement avec des données réelles si possible.

Par exemple, au lieu de demander "Gérez-vous la traçabilité ?", demandez : Un lot est rejeté au contrôle qualité alors que certains produits finis ont déjà été réservés pour des commandes clients. Montrez-nous comment le système identifie les stocks concernés, bloque ce qui ne doit pas partir, met à jour les commandes correspondantes et aide l'équipe à décider de la suite.

Au lieu de demander "Avez-vous un module de planification de la production ?", demandez : Une commande importante d'un client arrive plus tôt que prévu, alors qu'une livraison fournisseur est en retard et qu'une ligne de production est déjà saturée. Montrez-nous comment le système aide le planificateur à décider quoi fabriquer, quoi acheter, quoi décaler et ce que les commerciaux peuvent promettre avec certitude.

Au lieu de demander "Vous intégrez-vous avec notre outil commercial ?", demandez : Les commerciaux confirment une commande avec des détails personnalisés, des contraintes de livraison et une date d'expédition promise. Montrez-nous comment cette commande devient du travail opérationnel sans que quelqu'un ait à ressaisir les mêmes informations dans un autre outil.

C'est un test bien plus exigeant, et c'est précisément l'objectif. Un ERP industriel peut avoir les bons modules et échouer quand même sur les situations quotidiennes qui comptent. Le système peut gérer les achats en théorie, mais laisser quand même les acheteurs courir après l'information. Il peut gérer la production en théorie, mais obliger quand même les opérateurs à saisir les données après coup. Il peut gérer les stocks en théorie, mais laisser quand même les équipes débattre du chiffre auquel se fier.

Le test par scénario révèle aussi dans quelle mesure l'éditeur s'attend à ce que vous adaptiez vos façons de travailler au logiciel. Une part d'adaptation est normale, il faut être clair là-dessus. Aucune entreprise ne devrait préserver chaque vieille habitude au prétexte que "c'est comme ça qu'on fait ici." Mais si la réponse à chaque scénario réel est que votre équipe doit changer sa façon de vendre, de planifier, de produire, de contrôler la qualité, de gérer les stocks ou de traiter les exceptions, soyez vigilant. Le système doit rendre vos opérations plus lisibles et plus faciles à piloter.

C'est particulièrement important pour les fabricants qui montent en charge, car votre activité continuera d'évoluer après le go-live. De nouveaux produits, de nouveaux clients, de nouveaux fournisseurs, de nouveaux canaux, de nouvelles règles qualité et de nouvelles contraintes de production apparaîtront. Quand vous testez les éditeurs, demandez comment le système évolue après l'implémentation. Si chaque amélioration devient un projet de conseil, vous n'achetez pas seulement un logiciel. Vous achetez une dépendance.

Pour aller plus loin sur les pièges d'implémentation qui surviennent après la sélection, l'article de Bonx sur pourquoi les implémentations ERP échouent pour les fabricants explore en détail les délais longs, les projets pilotés par la finance et le risque d'accepter des processus ERP génériques comme "best practice."

Où Bonx se positionne

Bonx est un ERP industriel natif IA qui couvre la gestion des commandes, les stocks, les achats et la gestion des fournisseurs, la planification, la production, la qualité et la logistique dans un seul système opérationnel. Il se connecte également aux outils déjà en place, notamment CRM, e-commerce et outils de comptabilité, sans demander à l'entreprise de tout remplacer autour de l'ERP.

Les clients Bonx démarrent en production en 1 à 3 mois, ce qui change la donne dans le choix de l'ERP. Un déploiement plus rapide ne signifie pas faire l'impasse sur les détails opérationnels, mais partir des situations qui comptent et construire à partir de là, plutôt que de passer des mois à rédiger un document qui sera peut-être déjà obsolète au moment où l'implémentation commence.

Feroce est passée en production avec Bonx en 42 jours sans interrompre ses opérations, avant qu'une apparition dans une émission nationale multiplie les commandes par dix. Something Added, fabricant additif, a déployé Bonx en deux mois avec une intégration native aux imprimantes 3D HP : Bonx regroupe désormais les commandes, génère les ordres de fabrication et affecte les tâches aux machines selon les règles de production. L'Atelier du Ferment a connecté la planification de la production, la traçabilité par lots, Sidely et Pennylane avec Bonx, Bonx générant les ordres de fabrication et les suggestions d'approvisionnement en fonction des ventes, de la DLC et de la capacité de stockage frigorifique.

Le bon ERP n'est pas celui qui a la liste de modules la plus longue. C'est celui en lequel votre équipe peut avoir confiance quand une commande change, quand un stock évolue, quand un fournisseur est en retard, quand la production est reprogrammée, quand la qualité bloque un lot ou quand les commerciaux ont besoin d'une réponse maintenant.

Placez les opérations au centre, avec la finance dans la boucle. Recensez trois à cinq situations opérationnelles que votre dispositif actuel ne gère pas bien. Puis testez les éditeurs sur ces scénarios, plutôt que de laisser le processus d'achat se réduire à une liste de fonctionnalités.

Ça a l'air intéressant ?

Bénéficiez d'une démonstration personalisée en 48h.