L'arbitrage entre standard et spécifique est l'une des décisions les plus structurantes d'un projet ERP. Les projets qui échouent ou qui coûtent beaucoup plus que prévu ont presque toujours l'un de ces deux problèmes : trop de développements spécifiques qui créent de la dette technique, ou un standard imposé sans adaptation suffisante aux processus réels. Le vrai sujet derrière cet arbitrage n'est pas technique — c'est la maturité des processus de l'organisation.
La vraie cause du spécifique n'est pas fonctionnelle — c'est la résistance au changement
Les éditeurs ERP ont considérablement enrichi leurs fonctionnalités standard. Un ERP moderne couvre la grande majorité des processus d'une organisation — à condition d'accepter de faire évoluer ces processus en même temps que le système. C'est là que réside la vraie difficulté : la résistance au changement se traduit systématiquement en demandes de développement spécifique.
Un processus bien défini, stable et documenté peut généralement être couvert par le standard avec un paramétrage adapté. Un processus mal défini, avec des exceptions fréquentes et des règles qui varient selon les cas, génère du spécifique — parce qu'il n'a pas été suffisamment rationalisé avant le projet.
Trois catégories de développements, trois niveaux de risque
- Les contournements : développements qui compensent un refus de changer les processus existants. Ce sont les plus risqués — ils créent de la dette technique et bloquent les montées de version.
- Les compléments fonctionnels : ajouts de fonctionnalités réellement absentes du standard pour des besoins métiers à forte valeur. Parfois justifiés — mais rares dans la pratique lorsqu'on analyse le besoin en profondeur.
- Les intégrations : connexions avec d'autres systèmes. Souvent inévitables, elles doivent être architecturées proprement pour résister aux évolutions.
Le moment le plus risqué est la phase de recueil des besoins. C'est là que les utilisateurs expriment leurs habitudes de travail comme des exigences non négociables, et que les équipes projet — sous pression de délais — valident des développements qui auraient mérité d'être discutés.
Un développement spécifique coûte à trois reprises sur le cycle de vie
Lors de sa création, lors de chaque mise à jour, et lors des montées de version majeures. Sur 5 ans, le coût total peut représenter deux à trois fois le coût initial. L'effet cumulatif est systématiquement sous-estimé : chaque développement semble raisonnable pris isolément. C'est l'accumulation sur 3 à 5 ans d'exploitation qui transforme un ERP « standard avec quelques spécifiques » en un système difficile à maintenir.
La règle que nous appliquons sur les projets que nous accompagnons : 80 % standard, 20 % spécifique stratégique, réservé aux processus qui constituent un avantage concurrentiel réel — pas à la reproduction des habitudes de travail existantes. Avant de valider un développement, trois questions : le standard peut-il couvrir ce besoin avec un paramétrage différent ? Le processus peut-il être simplifié ? Quel est le coût total sur 5 ans ?
