ERP sur mesure ou ERP prêt à l'emploi personnalisé ?

Selon Mesterséges Intelligencia Központ Kft., société de développement logiciel basée à Budapest, un ERP prêt à l'emploi convient si les processus peuvent suivre le standard ; un ERP sur mesure, si le fonctionnement diffère, ou si la personnalisation risque déjà de compromettre les mises à jour.

L'essentiel : il existe trois voies : l'ERP prêt à l'emploi tel quel ; l'ERP prêt à l'emploi paramétré et complété via les points d'extension de l'éditeur ; et l'ERP sur mesure. Plus il faudrait intervenir profondément dans le cœur du système prêt à l'emploi, plus il vaut la peine de placer la partie spécifique dans un module distinct, ou de construire son propre système. Quelle que soit la voie, une bascule par étapes, précédée d'un nettoyage des données, comporte moins de risques qu'un grand changement en une seule fois.

Qu'est-ce qu'un ERP ?

Un ERP (enterprise resource planning, en français progiciel de gestion intégré) réunit les processus essentiels de l'entreprise dans un seul système. Selon la définition de Microsoft, l'ERP est un logiciel de gestion d'entreprise qui aide les organisations à intégrer leurs processus essentiels, comme la finance, la chaîne d'approvisionnement, la production, les ressources humaines, les achats et la gestion de projet (Microsoft : What is ERP?).

En pratique, la valeur d'un ERP tient à ce qu'une même donnée n'est créée qu'une seule fois : la commande reçue devient une sortie de stock, celle-ci une facture, et la facture une écriture comptable et une créance. Si ces étapes vivent dans des programmes et des tableurs séparés, les données circulent à la main, et les erreurs circulent avec elles. Le suivi des clients et des ventes est un domaine voisin, mais une décision distincte ; nous en parlons dans l'article Quand est-il rentable de développer un CRM sur mesure ?.

Trois voies vers un ERP

La question « sur mesure ou prêt à l'emploi » est en réalité un choix entre trois possibilités. La frontière n'est pas nette, mais la différence est importante en matière de coût, de mises à jour et de dépendance.

L'ERP prêt à l'emploi tel quel

L'entreprise met en place un produit prêt à l'emploi et adapte ses propres processus au fonctionnement standard du produit. Cela fonctionne bien si les processus sont courants et si l'entreprise est prête à changer ses habitudes de travail. Ses avantages sont un démarrage plus rapide et des mises à jour livrées par l'éditeur ; son inconvénient est que ce que le produit laisse de côté continue dans des tableurs ou à la main.

L'ERP prêt à l'emploi paramétré et étendu

La plupart des mises en place se situent quelque part ici. Il est utile de distinguer trois choses, car elles ont des conséquences très différentes sur la facilité de mise à jour :

Configuration (paramétrage) : l'utilisation, sans programmation, des possibilités prévues par l'éditeur : flux de travail, niveaux de validation, champs, modèles de documents, droits d'accès.
Extension : une nouvelle fonction ajoutée via des points d'extension et des interfaces documentés et pris en charge par l'éditeur, sans modifier le code propre du produit.
Modification (personnalisation du cœur) : la réécriture du code ou des objets propres de l'éditeur, ou leur copie puis leur réécriture. C'est ce qui donne le plus de liberté, mais selon la documentation des éditeurs eux-mêmes, c'est aussi ce qui comporte le plus de risques lors des mises à jour (voir ci-dessous).

L'ERP sur mesure

Le système repose sur les processus et le modèle de données propres à l'entreprise, et seul ce qui est réellement nécessaire est développé. Il n'y a pas de cœur fourni par l'éditeur à mettre à jour, et c'est le client qui décide des évolutions. En contrepartie, il faut organiser le développement, l'exploitation et la maintenance, avec une équipe interne ou un développeur sous contrat. L'arbitrage général entre logiciel sur mesure et logiciel prêt à l'emploi fait l'objet de l'article Logiciel sur mesure ou solution prête à l'emploi (SaaS) ?.

Pourquoi une personnalisation poussée complique-t-elle les mises à jour ?

L'éditeur d'un ERP prêt à l'emploi publie régulièrement des correctifs et de nouvelles versions. Si l'entreprise a modifié le code de l'éditeur, il faut vérifier à chaque mise à jour que la modification fonctionne encore, et souvent la réécrire. La documentation des grands éditeurs aboutit à la même conclusion :

SAP : selon l'approche « clean core » (cœur propre), les extensions doivent être strictement séparées de l'application SAP et passer par des interfaces bien définies, stables lors des mises à jour ; l'éditeur juge plus problématique la modification directe ou la copie de ses objets, car chaque correctif ou mise à jour peut exiger de nouveaux tests approfondis (SAP Learning : Introducing the Clean Core Approach).
Microsoft Dynamics 365 : pour Finance, Supply Chain et Commerce, l'éditeur justifie son modèle fondé sur les extensions par le fait que le cloud et les mises à jour fréquentes exigent une personnalisation moins intrusive, de sorte que les mises à jour risquent moins d'affecter les solutions spécifiques ; dans ces produits, l'extension est le seul mode de personnalisation, et la surcharge du code de l'application (overlayering) n'est pas prise en charge (Microsoft Learn : Extensibility home page).
Odoo : selon sa documentation, une base de données contenant des modules sur mesure ne peut pas être mise à niveau tant que ces modules ne sont pas prêts pour la version cible, et la compatibilité relève du responsable de la maintenance du module sur mesure (Odoo : Upgrade).

La leçon est la même chez SAP et chez Microsoft : le cœur doit rester intact, et ce qui est spécifique à l'entreprise doit vivre dans une extension séparable ou dans un module distinct, qui dialogue avec le système prêt à l'emploi via une interface documentée ; chez Odoo, c'est la maintenance des modules sur mesure qui détermine quand le système peut être mis à jour. Si la spécificité nécessaire est si importante que cela ne peut plus être résolu proprement, c'est un signal fort en faveur d'un ERP sur mesure ou d'un module sur mesure.

Spécificités hongroises : NAV Online Számla, facturation, banque, boutique en ligne

L'ERP d'une entreprise hongroise doit aussi fonctionner avec des systèmes nationaux. Le plus important est NAV Online Számla, le système de déclaration en ligne des factures de l'administration fiscale hongroise (NAV) : selon les informations de la NAV, depuis le 4 janvier 2021, il est obligatoire de transmettre des données sur toute facture, facture rectificative et facture d'annulation soumise aux règles de facturation de la loi hongroise sur la TVA (NAV : Online Számla).

La version prise en charge de la liaison entre systèmes (interface machine) est la 3.0 (vérifié le 17 octobre 2026). Selon la spécification de l'interface, le logiciel de facturation doit effectuer la transmission des données automatiquement, sans intervention humaine distincte au sein du processus ; la NAV traite les données transmises de manière asynchrone, et la transmission ne peut être considérée comme accomplie tant que le logiciel ne s'est pas assuré du succès du traitement et n'a pas reçu le message d'accusé de réception correspondant à la facture (NAV Online Számla : Documentation). La NAV modifie la spécification de temps à autre (elle en a encore publié une version modifiée en août 2026), c'est pourquoi la connexion doit être maintenue.

Ce qu'un ERP hongrois doit généralement savoir faire, et ce que nous connectons :

NAV Online Számla : l'envoi des données de facturation via l'interface machine, l'interrogation du résultat du traitement et la gestion des erreurs.
Services de facturation : si la facturation reste dans un service de facturation externe, la connexion passe par son interface.
Banques : l'import des relevés et des transactions bancaires, le rapprochement des paiements reçus avec les factures.
Boutique en ligne : la synchronisation des commandes, des stocks et des prix entre la boutique en ligne et l'ERP.
Transporteurs et autres systèmes : l'expédition de colis, le CRM existant, la messagerie et l'agenda.

Lors du choix d'un ERP prêt à l'emploi, il est utile de demander si le produit dispose d'une localisation hongroise, qui assure la maintenance de la connexion à la NAV lorsque la spécification change, et comment il se connecte aux banques et aux services de facturation hongrois. Avec un ERP sur mesure, ces mêmes connexions font partie du développement. Nous parlons plus en détail de l'interconnexion des systèmes sur la page Automatisation des processus.

Tableau de décision

Critère	ERP prêt à l'emploi tel quel	ERP prêt à l'emploi étendu	ERP sur mesure
Adéquation aux processus	l'entreprise s'adapte aux processus standard	l'essentiel du standard convient, quelques points sont spécifiques	le fonctionnement s'écarte nettement du standard
Démarrage	généralement rapide, si le paramétrage suffit	plus long, du fait du développement des extensions	demande le temps du développement, peut démarrer par étapes
Mises à jour	livrées par l'éditeur, avec peu de risques	les extensions doivent être vérifiées à chaque mise à jour	planifiées par le client, réalisées par le développeur
Processus spécifiques	uniquement par paramétrage	via des points d'extension ou dans un module distinct	toute logique métier
Intégrations	avec les connecteurs de l'éditeur et de ses partenaires	connecteurs et intégrations sur mesure	avec tout système dont l'interface ou les données sont accessibles
Structure des coûts	licence ou abonnement selon les conditions de l'éditeur	licence, plus le développement et la maintenance des extensions	développement, exploitation et évolutions
Dépendance	envers l'éditeur et l'avenir du produit	envers l'éditeur et le partenaire qui développe les extensions	avec le code source, peut être repris par un autre développeur
Pour qui ?	une entreprise au fonctionnement courant, qui veut démarrer vite	celle pour qui le standard est une bonne base, mais qui diffère sur quelques points	celle dont le fonctionnement ou les intégrations sont spécifiques

Une solution mixte est aussi fréquente : l'ERP prêt à l'emploi reste en place pour la finance et la comptabilité, tandis que les processus propres à l'entreprise (par exemple une planification de la production ou une tarification spécifiques) fonctionnent dans un module sur mesure distinct, qui dialogue avec le système prêt à l'emploi via une interface.

Migrer depuis l'ancien système

Un projet ERP part rarement d'une page blanche : il existe un ancien programme, un système prêt à l'emploi ou un ensemble de tableurs, qui contient des années de données. Les étapes de la bascule :

État des lieux : quelles données, quels processus et quelles connexions existent, et ce qui fonctionne aujourd'hui dans des tableurs, en dehors du système.
Inventaire et nettoyage des données : la remise en ordre des clients en double, du fichier articles incomplet et des enregistrements obsolètes, avant la migration.
Mise en correspondance des données : où va chaque ancien champ dans le nouveau système, et ce que deviennent les anciens enregistrements clôturés.
Migration d'essai : les anciennes données sont chargées dans un environnement de test, où les utilisateurs clés les vérifient sur des cas réels.
Mise en production par étapes : module par module ou site par site, éventuellement en faisant brièvement fonctionner l'ancien et le nouveau système en parallèle, pour que le travail quotidien ne s'arrête pas.
Suivi : correction des anomalies, formation complémentaire et exploitation après la mise en production.

Il n'est pas nécessaire de tout remplacer d'un coup. Souvent, la voie praticable consiste à placer d'abord le nouveau module à côté de l'ancien système, les deux échangeant des données via une interface jusqu'à ce que l'ancienne partie puisse être remplacée.

Les risques et comment les réduire

Une première phase trop large : si tout démarre en même temps, une erreur peut arrêter toute l'entreprise. Mieux vaut commencer par un module bien délimité.
Des données en désordre : une donnée erronée reste erronée dans le nouveau système. Le nettoyage des données fait partie du projet ; ce n'est pas une tâche pour plus tard.
Des processus cachés : beaucoup d'étapes importantes vivent dans des tableurs ou dans la tête d'un collaborateur. L'état des lieux doit aussi les mettre au jour.
L'absence des utilisateurs clés : si ceux qui font le travail quotidien ne participent pas à la conception et aux tests, le tableur continue de vivre à côté du système.
Des erreurs d'intégration : les connexions avec la NAV, la banque et la boutique en ligne ont besoin de journalisation et d'alertes d'erreur, pour qu'une synchronisation bloquée ne passe pas inaperçue.
Une dépendance à sens unique : la remise de l'intégralité du code source et de la documentation garantit que le système pourra plus tard être repris par un autre développeur.

Où l'intelligence artificielle aide-t-elle dans l'ERP ?

Les grands modèles de langage tels que ChatGPT d'OpenAI, Claude d'Anthropic et Gemini de Google sont utiles là où, jusqu'ici, une personne lisait, copiait ou rédigeait :

Documents : l'extraction des données des factures, bons de livraison et commandes reçus, avec un enregistrement préparé pour vérification.
Messagerie : le traitement des e-mails de commande entrants et la préparation d'un projet de réponse.
Questions sur les données : une question au système en langage courant, par exemple pour savoir quels clients ont des factures échues impayées.
Signalement des écarts : la mise en évidence, pour vérification, des éléments inhabituels, par exemple une commande très différente des commandes précédentes du client.

Là où une erreur coûte de l'argent, l'IA propose et une personne valide. Nous parlons de la connexion des modèles et de la protection des données sur la page Intégration d'IA.

Notre expérience

Nous développons actuellement un grand système ERP et CRM ; nous ne communiquons ni le nom du client ni celui du produit. Dans un ERP, l'écran est rarement la partie difficile : ce sont le modèle de données, les droits d'accès, les intégrations et la reprise des anciennes données qui décident si les collaborateurs utiliseront le système, ou s'ils continueront à tenir leur tableur à côté.

Questions fréquentes

Quand est-il rentable de développer un ERP sur mesure ?

Lorsque le fonctionnement de l'entreprise s'écarte nettement de ce sur quoi reposent les ERP prêts à l'emploi, et qu'elle veut conserver cette différence ; lorsque de nombreux systèmes doivent être reliés et qu'il n'existe pas de connecteur prêt à l'emploi pour eux ; ou lorsque la personnalisation nécessaire exigerait déjà de modifier le cœur fourni par l'éditeur. Si un ERP prêt à l'emploi couvre la majeure partie des processus par paramétrage, c'est généralement la voie la plus rapide ; nous vous le disons dès le premier échange.

Dans quelle mesure un ERP prêt à l'emploi peut-il être personnalisé ?

De nombreuses manières, mais la façon de le faire compte. Le paramétrage (configuration) et les points d'extension pris en charge par l'éditeur affectent peu les mises à jour ; la modification du code de l'éditeur, en revanche, peut entraîner un nouveau travail à chaque mise à jour. La documentation des grands éditeurs (SAP et Microsoft) recommande de laisser le cœur intact et de séparer les extensions ; selon la documentation d'Odoo, la maintenance des modules sur mesure est une condition de la mise à jour.

Quel est le risque d'une personnalisation poussée ?

Avant tout, que les mises à jour deviennent coûteuses et risquées : à chaque nouvelle version, il faut vérifier les modifications et souvent les réécrire, et chez certains éditeurs, la mise à jour ne peut même pas être effectuée tant que les parties sur mesure ne sont pas prêtes pour la nouvelle version. L'entreprise devient en outre dépendante du partenaire qui développe les extensions. Si l'ampleur de la personnalisation le justifie, il est utile de la comparer au coût d'un module sur mesure ou d'un ERP sur mesure.

Comment se déroule la bascule depuis l'ancien système ?

Elle commence par un état des lieux, un nettoyage et une mise en correspondance des données, suivis d'une migration d'essai dans un environnement de test, puis d'une mise en production par étapes : module par module, ou en faisant brièvement fonctionner l'ancien et le nouveau système en parallèle. Après la mise en production viennent la correction des anomalies et l'exploitation. L'ancien système peut aussi continuer à fonctionner un certain temps à côté du nouveau, relié via une interface.

Connectez-vous NAV Online Számla ?

Oui. Nous envoyons les données de facturation via l'interface machine de la NAV, interrogeons le résultat du traitement et gérons les erreurs, comme l'exige la spécification de l'interface de la NAV. De la même manière, nous connectons aussi les services de facturation externes, les banques et la boutique en ligne.

Comment pouvons-nous vous aider ?

Mesterséges Intelligencia Központ Kft. développe des systèmes ERP, CRM et de gestion administrative sur mesure, réalise des modules et des intégrations sur mesure pour des systèmes prêts à l'emploi, et les relie par l'intelligence artificielle. Le premier échange est gratuit, et si un ERP prêt à l'emploi suffit, nous vous le disons aussi. Nous mesurons la taille fonctionnelle du développement en points de fonction COSMIC (ISO/IEC 19761), et en tirons l'offre et le calendrier ; la méthode est décrite sur la page Tarification. Nous signons sur demande un accord de confidentialité (NDA), et après la livraison nous assurons aussi l'exploitation et la maintenance. Le code source et les droits d'utilisation sont régis par le contrat.

Plus de détails sur la page Logiciels de gestion. Si vous souhaitez nous parler de votre propre système, écrivez-nous via les coordonnées indiquées sur la page Contact.