ERP sur mesure ou ERP standard personnalisé : comment choisir ?

Chaque PME possède ses propres règles de gestion. Un mode de calcul de prix dépend de plusieurs variables métier. Un circuit de validation suit une organisation particulière. Un responsable commercial attend une vue consolidée dès l’ouverture de son logiciel, tandis qu’un magasinier ne doit accéder ni aux coûts de revient ni aux marges.

Un développement spécifique peut alors être nécessaire pour répondre aux besoins de chaque profil, mais il ne constitue plus la seule manière d’adapter un ERP aux particularités d’une entreprise. Paramétrage, personnalisation des usages, automatisation et extensions permettent désormais d’aller plus loin avec une solution standard.

La question n’est donc pas seulement de choisir entre un ERP standard et un ERP sur mesure. Il faut déterminer quel niveau d’adaptation chaque besoin justifie, avec quelles conséquences sur le coût, la maintenance et la capacité à faire évoluer le système d’information.

Les appellations varient selon les éditeurs et les intégrateurs. Trois grands niveaux d’adaptation peuvent néanmoins être distingués.

Le développement spécifique

Le logiciel, ou une partie importante de celui-ci, est conçu pour répondre à des processus propres à l’entreprise. Cette approche offre une grande liberté fonctionnelle. Elle peut être pertinente lorsque le processus concerné constitue un véritable avantage concurrentiel et qu’aucune solution du marché ne permet de le couvrir correctement.

Cette liberté a cependant une contrepartie : l’entreprise doit financer la conception, les développements, les tests, la documentation et la maintenance du logiciel. Elle doit également anticiper son évolution à mesure que ses processus, son organisation ou son environnement réglementaire changent.

Le paramétrage d’un ERP standard

Le paramétrage consiste à exploiter les possibilités prévues par l’éditeur : règles de gestion, droits d’accès, plans comptables, circuits de validation, modèles de documents ou organisation des données.

Il permet d’adapter le fonctionnement de l’ERP sans modifier son socle. Les mises à jour sont généralement plus simples à gérer, même si leur impact doit toujours être vérifié avant déploiement.

La personnalisation et les extensions

Entre le paramétrage standard et le développement spécifique se trouve un troisième niveau. Il peut comprendre la création de vues par métier, l’ajout d’états, l’automatisation de tâches, la connexion à d’autres logiciels ou la mise en place d’une extension ciblée.

Selon l’ERP et la complexité du besoin, ces adaptations peuvent être réalisées avec les fonctions natives de la solution, des outils no-code ou low-code, des connecteurs ou un développement complémentaire limité.

L’objectif n’est pas d’éviter tout développement par principe. Il est de réserver le code spécifique aux besoins qui créent réellement de la valeur.

Le budget initial ne suffit pas à évaluer un ERP entièrement développé sur mesure. Son coût total doit également intégrer :

• la rédaction et la mise à jour de la documentation ;
• les tests fonctionnels et techniques ;
• les interfaces avec les autres applications ;
• la correction des anomalies ;
• l’adaptation aux évolutions de l’entreprise ;
• les contrôles nécessaires lors des changements réglementaires ou techniques ;
• la disponibilité des compétences capables de maintenir le logiciel.

Un développement spécifique peut aussi créer une dépendance à certaines technologies ou à une équipe restreinte. Ce risque dépend de la qualité de l’architecture, de la documentation, des contrats et de la capacité à transférer les connaissances. Il ne doit donc pas être considéré comme automatique, mais évalué dès le cadrage.

À l’inverse, un ERP standard n’est pas exempt de coûts d’évolution. Les interfaces, les extensions et les personnalisations doivent elles aussi être maintenues. L’enjeu consiste à comparer les approches sur l’ensemble du cycle de vie, et pas uniquement sur le montant du projet initial.

Un ERP standard n’est pas nécessairement un logiciel figé. Selon la solution et sa version, il peut permettre de :

• configurer des règles de gestion et des circuits de validation ;
• limiter l’accès aux informations en fonction des rôles ;
• organiser les menus et les écrans selon les postes de travail ;
• créer des champs, des listes et des tableaux de bord ;
• produire des états adaptés aux besoins de pilotage ;
• automatiser certaines actions récurrentes ;
• connecter l’ERP au CRM, au site e-commerce ou à un outil métier.

Ces possibilités ne dispensent pas d’un travail de conception. Avant de personnaliser un écran ou d’automatiser une tâche, il faut clarifier le besoin, vérifier la qualité des données et définir les responsabilités.

La personnalisation doit également rester maîtrisée. Accumuler les adaptations sans gouvernance peut recréer une forme de dette technique, même en l’absence de développement spécifique traditionnel.

Certaines solutions illustrent l’évolution de la frontière entre ERP standard et ERP sur mesure. Sage 100 Experience Edition en fournit un exemple : cette nouvelle expérience s’appuie sur le socle Sage 100 existant et lui ajoute une interface web, des fonctions de personnalisation, des automatisations et un assistant conversationnel.

Prenons quelques exemples :

• Un écran dédié à un magasinier, conçu pour afficher les stocks sans donner accès aux prix d’achat, aux coûts de revient ou aux marges. Le responsable commercial dispose, de son côté, d’une vue consolidée de ses équipes et de ses produits dès l’ouverture de l’application.
• Un moteur de calcul, jusqu’alors traité dans un logiciel spécifique, peut être ajouté au processus de commande Sage 100 afin d’éviter la double saisie.
• Des états auparavant reconstruits manuellement dans un tableur peuvent également être intégrés à l’environnement de travail.

Ces exemples montrent qu’un besoin particulier ne conduit pas systématiquement à développer et maintenir une application séparée. Ils ne signifient pas pour autant que toute adaptation devient immédiate ou réalisable en autonomie.

Dans Sage 100 Experience Edition, les réglages d’affichage les plus simples, comme le choix des colonnes ou l’organisation du menu, peuvent être effectués directement par l’utilisateur. Les écrans métier, les états avancés, les automates ou les moteurs de calcul nécessitent un cadrage et une configuration avec des consultants maîtrisant la solution et les processus concernés.

Le périmètre disponible dans la solution Sage 100 Experience Edition dépend par ailleurs des modules, de la version et de l’environnement d’hébergement.

Dans Sage 100 Experience Edition, l’assistant Ask AI permet d’interroger les données de gestion en langage naturel. Un utilisateur peut, par exemple, demander une comparaison de son activité avec la période précédente sans construire lui-même une requête ou un état.

L’intelligence artificielle peut également contribuer à la création de pages ou d’automatisations avec l’aide d’un intégrateur certifié Sage tel que Parthena Consultant. Elle accélère alors certaines étapes de configuration, mais ne remplace pas l’analyse métier.

Un automate de relance de factures ne peut être pertinent que si les règles de sélection, les délais, les exceptions et les modalités de contrôle ont été définis. De la même manière, une réponse produite en langage naturel dépend de la qualité et de la disponibilité des données interrogées.

L’IA élargit donc les possibilités de personnalisation. Elle ne supprime ni la gouvernance, ni la sécurité, ni la validation humaine.

Le choix ne se résume pas à opposer un ERP standard rigide à un ERP entièrement développé sur mesure. Il consiste à déterminer, besoin par besoin, ce qui relève du standard, du paramétrage, d’une extension ou d’un développement spécifique.

Le sur-mesure conserve toute sa pertinence lorsqu’il soutient un processus réellement distinctif que les solutions du marché ne peuvent pas couvrir. Pour les autres besoins, un ERP standard correctement configuré et personnalisé peut offrir une trajectoire plus simple à maintenir et à faire évoluer.

La qualité de la décision dépend alors moins du nombre de fonctionnalités ajoutées que de la précision du cadrage : valeur métier, utilisateurs concernés, données nécessaires, modalités de maintenance et effets sur le système d’information.

Avant de lancer un développement ou une personnalisation, plusieurs questions permettent de cadrer la décision.

Le processus est-il réellement différenciant ?

Une règle qui contribue directement à l’avantage concurrentiel de l’entreprise peut justifier une adaptation avancée. Une habitude interne héritée de l’organisation existante mérite d’abord d’être questionnée.

Le besoin peut-il être couvert par le standard ?

Il faut examiner les fonctions natives, les paramètres disponibles, les modules complémentaires et les connecteurs avant d’envisager un développement.

Quelle est la fréquence d’utilisation ?

Un processus quotidien qui mobilise plusieurs équipes n’a pas la même valeur qu’un état consulté ponctuellement. L’effort d’adaptation doit rester proportionné à l’usage attendu.

Quel sera le coût de maintenance ?

L’entreprise doit savoir qui pourra corriger, tester et faire évoluer l’adaptation. Cette responsabilité doit être prévue dès la conception.

Quel sera l’impact des prochaines mises à jour ?

Une adaptation ne doit pas être évaluée uniquement au moment de sa mise en service. Sa compatibilité avec les futures versions et les autres composants du système d’information compte tout autant.

Les équipes participeront-elles à la conception ?

Un écran personnalisé n’améliore pas l’usage s’il ne correspond pas au travail réel. Les utilisateurs doivent contribuer au cadrage, aux tests et aux ajustements.