ERP personnalisé : paramétrer, développer des spécifiques ou passer au sur-mesure ?

Aucune entreprise n'utilise un ERP exactement tel qu'il sort de la boîte. Il faut au minimum le configurer, souvent l'adapter, parfois le transformer profondément. Un ERP personnalisé est donc la norme. La vraie question est : jusqu'où personnaliser ? Car chaque adaptation a un coût, immédiat et surtout futur.

Cet article distingue les niveaux de personnalisation d'un ERP, leurs conséquences, et aide à repérer le moment où il vaut mieux construire à côté plutôt que de continuer à tordre l'outil.

Les quatre niveaux de personnalisation

Les niveaux 1 et 2 sont sans risque et doivent être exploités au maximum. Le niveau 3 est celui où les projets dérapent. Le niveau 4 est souvent l'alternative la plus saine quand le besoin est vraiment spécifique.

Pourquoi les développements spécifiques coûtent plus cher qu'il n'y paraît

Sur le moment, un développement spécifique dans l'ERP semble la solution la plus simple : on ajoute ce qui manque, directement dans l'outil. Le coût réel apparaît plus tard.

• Les montées de version. L'éditeur fait évoluer son logiciel ; vos spécifiques doivent suivre. Avec des dizaines de modules maison, chaque mise à jour devient un projet. Beaucoup d'entreprises finissent bloquées sur une version ancienne, sans les correctifs de sécurité ni les nouveautés réglementaires. C'est un travers fréquent sur Odoo, que nous évoquons dans notre avis sur Odoo.
• La dépendance à l'intégrateur. Les spécifiques sont souvent peu documentés et seul celui qui les a écrits sait les maintenir.
• La complexité cumulée. Chaque spécifique interagit avec les autres et avec le standard. Les bugs deviennent difficiles à diagnostiquer.
• Les tests. Il faut retester l'ensemble à chaque changement, ce qui est rarement fait correctement.

Les bonnes pratiques de personnalisation

1. Questionner le besoin avant de personnaliser. Le processus peut-il s'aligner sur le standard sans perte de valeur ? Souvent oui, pour ce qui n'est pas différenciant.
2. Épuiser le paramétrage et le low-code avant d'écrire du code.
3. Isoler les spécifiques dans des modules séparés plutôt que de modifier le cœur de l'ERP.
4. Documenter chaque adaptation : pourquoi, quoi, comment la tester.
5. Tenir un registre des spécifiques et le revoir à chaque montée de version : certains deviennent inutiles quand l'éditeur ajoute la fonction.
6. Sortir du cœur ce qui est vraiment spécifique, sous forme de brique externe connectée.

Quand basculer vers des briques sur mesure

Quelques signaux montrent que la personnalisation de l'ERP a atteint ses limites :

• les spécifiques représentent une part importante du budget annuel de l'ERP ;
• la dernière montée de version a été repoussée faute de budget ou par peur de tout casser ;
• les utilisateurs terrain trouvent l'outil lent ou inadapté, malgré les adaptations ;
• un processus clé (production, chantier, service) est géré en grande partie hors de l'ERP ;
• le même besoin a été adapté plusieurs fois sans jamais donner satisfaction.

À ce stade, la solution n'est pas forcément de changer d'ERP. On peut garder l'ERP pour son socle standard et développer une application dédiée au processus spécifique, connectée par API. L'ERP redevient simple et facile à mettre à jour, la brique sur mesure épouse le métier. C'est l'approche hybride que nous détaillons dans notre guide de l'ERP sur mesure.

ERP personnalisable : les critères à vérifier au moment du choix

Si vous choisissez un ERP, sa capacité à être personnalisé proprement compte autant que ses fonctions :

• la richesse du paramétrage sans code ;
• les outils low-code fournis (champs, écrans, rapports, automatisations) ;
• la qualité de l'API : complète, documentée, stable entre versions ;
• la politique de montée de version de l'éditeur et la compatibilité des extensions ;
• l'écosystème d'intégrateurs et de modules ;
• la possibilité de connecter de l'IA et des automatisations sur les données de l'ERP (voir ERP et IA).

Ces critères ont leur place dans votre cahier des charges ERP.

Exemple : la tarification complexe

Prenons un négociant dont les prix dépendent du client, du volume trimestriel, de la famille de produits et de cours de matières premières mis à jour chaque semaine.

• Option A, spécifique dans l'ERP : on modifie le moteur de prix de l'ERP. Rapide au départ, mais à chaque montée de version, ce moteur modifié doit être réécrit et retesté.
• Option B, brique externe : un service de calcul de prix sur mesure, appelé par l'ERP et par le site e-commerce via API. L'ERP reste standard ; la logique de prix est maîtrisée, testée et réutilisée partout.

L'option B demande un peu plus de conception au départ, mais elle est beaucoup plus durable. Voir aussi notre article sur l'ERP négoce, où ce cas est fréquent.

Conclusion

Un ERP personnalisé est inévitable, mais toutes les personnalisations ne se valent pas. Paramétrer et configurer : oui, sans retenue. Modifier le code de l'ERP : avec parcimonie, en documentant. Et pour les processus vraiment différenciants, construire à côté, sous forme de briques sur mesure connectées, est souvent la solution la plus économique dans la durée.

Chez Automato, nous aidons les entreprises à faire ce tri, puis à développer les briques sur mesure et les connexions qui allègent leur ERP. Pour faire le point sur vos spécifiques, commencez par notre offre de cadrage.