Les coûts cachés d’un ERP fortement personnalisé

Les coûts cachés d’un ERP fortement personnalisé

Situation illustrative : dans une ETI industrielle, une modification apparemment mineure du calcul des délais de livraison doit être mise en production avant la prochaine campagne commerciale. L’éditeur affirme que le standard couvre presque le besoin. L’intégrateur rappelle que quinze ans d’adaptations rendent toute évolution risquée. Les métiers refusent de perdre une règle jugée indispensable. Le DSI doit trancher : financer un développement supplémentaire, revenir au standard ou différer une promesse faite aux clients. Le coût visible tient dans un devis. Le coût réel se cache dans les dépendances que cette décision prolongera.

La personnalisation transforme chaque évolution en enquête

Un ERP personnalisé n’est pas seulement un logiciel enrichi. C’est un empilement de règles, d’interfaces, de traitements nocturnes, de droits spécifiques et d’exceptions dont la justification s’est parfois perdue. Avant de modifier une fonction, les équipes doivent déterminer qui l’utilise, quelles données elle transforme, quels flux elle déclenche et quels contrôles elle contourne. Cette phase d’archéologie mobilise des experts rares avant même que le développement commence.

Le mécanisme du surcoût est cumulatif. Une adaptation crée une dépendance ; celle-ci alourdit les tests ; les tests retardent les montées de version ; le retard réduit le support disponible et pousse à de nouveaux contournements. Le budget de maintenance n’explique alors qu’une partie du problème. Il faut aussi compter le temps métier consacré aux recettes, les incidents provoqués par des effets de bord et les décisions reportées faute de visibilité.

Le vrai prix apparaît hors de la facture ERP

Le comité de direction voit les licences, le contrat de support et les prestations. Il voit moins facilement les rapprochements manuels, les fichiers locaux, les reprises de données et les contrôles compensatoires rendus nécessaires par les adaptations. Une interface fragile peut imposer une surveillance quotidienne. Un référentiel spécifique peut compliquer l’intégration d’une acquisition. Une règle codée sur mesure peut empêcher l’activation d’une fonction standard pourtant déjà payée.

Le DSI doit donc déplacer la discussion : combien coûte l’ERP, mais aussi combien coûte l’organisation construite autour de ses particularités ? Cette vue inclut les compétences captives, les délais de changement, les opérations de secours, les anomalies récurrentes et les projets dépendants. Elle révèle surtout les coûts sans propriétaire : chacun optimise son périmètre, tandis que l’entreprise supporte collectivement la complexité.

Cartographier avant de promettre une trajectoire

La première étape consiste à inventorier les personnalisations actives, pas seulement celles documentées. Il faut rapprocher le code spécifique, les interfaces, les traitements planifiés, les rôles, les incidents et les usages observés. Chaque élément reçoit un propriétaire métier, une criticité opérationnelle et une justification actuelle. Une personnalisation sans utilisateur identifié n’est pas automatiquement supprimable, mais elle devient un objet d’enquête prioritaire.

La deuxième étape qualifie les dépendances : processus touchés, données manipulées, applications connectées, compétences nécessaires et conséquences d’une indisponibilité. La troisième compare trois scénarios pour chaque ensemble cohérent : conserver, simplifier ou remplacer par le standard. Enfin, un lot pilote peu risqué permet de vérifier la méthode, la capacité de test et la réalité des gains avant d’annoncer un vaste programme de « retour au standard ».

Mesurer la complexité qui ralentit l’entreprise

Quelques indicateurs suffisent s’ils conduisent à des décisions. Le DSI peut suivre la part des incidents impliquant du spécifique, le délai moyen d’analyse avant correction, le nombre d’interfaces sans propriétaire, la couverture des tests de non-régression, le volume de traitements manuels compensatoires et le nombre de versions de retard. Il peut également mesurer le délai nécessaire pour intégrer une évolution réglementaire, commerciale ou industrielle.

Ces indicateurs ne servent pas à désigner des coupables. Ils objectivent la vitesse perdue et le risque accepté. Leur tendance importe davantage qu’un score théorique : une baisse des incidents mais une hausse du délai de changement peut signaler un système stable uniquement parce que plus personne n’ose le toucher. Le tableau de bord doit relier la technique à des processus concrets : produire, livrer, facturer, clôturer et décider.

Éviter les remèdes qui aggravent la dépendance

La première erreur consiste à décréter un retour intégral au standard sans distinguer les vraies spécificités concurrentielles des habitudes historiques. On déplace alors la charge vers les utilisateurs, qui recréent leurs anciens mécanismes dans des tableurs ou des outils périphériques. La deuxième est de confier l’inventaire au seul intégrateur : il connaît la solution, mais ne peut pas décider de la valeur métier ni arbitrer seul sa propre dépendance.

La troisième erreur est de lancer une migration avant d’avoir nettoyé les données, clarifié les responsabilités et supprimé les variantes inutiles. La complexité voyage alors vers la nouvelle plateforme. Enfin, réduire le sujet à une négociation tarifaire donne un soulagement provisoire sans modifier le coût structurel. Un meilleur taux journalier ne compense pas une architecture que chaque changement rend plus opaque.

Arbitrer entre avantage métier et liberté future

La bonne décision n’est pas toujours de supprimer le spécifique. Certaines règles soutiennent réellement une manière de produire, de servir ou de contrôler que le standard ne couvre pas correctement. Elles méritent d’être conservées si leur valeur est démontrée, leur propriétaire identifié, leurs tests automatisables et leur maintenance maîtrisée. Les autres doivent être simplifiées, isolées ou retirées selon une trajectoire compatible avec l’exploitation.

L’arbitrage final appartient à la direction, éclairée par le DSI : payer aujourd’hui pour réduire une dépendance, ou accepter explicitement le coût futur d’une exception. Cette décision doit intégrer la continuité d’activité, la cybersécurité, la qualité des données, la capacité de mise à niveau et le pouvoir de négociation face aux fournisseurs. Dans cette perspective, Révolution Numérique ! apporte un cadre utile pour relier technologie, coûts, risques et gouvernance ; DSI EN CRISE peut compléter la réflexion lorsque l’ERP, les fournisseurs ou un grand programme échappent déjà au contrôle. Le sujet n’est pas de rendre l’ERP « pur », mais de retrouver le droit de décider sans que chaque choix soit dicté par le passé.

Pour approfondir

Ouvrage : Révolution Numérique !: Le guide pour comprendre, décider et agir dans l’entreprise numérique — Amazon

Ouvrage : DSI EN CRISE: Reprendre le contrôle de l’IT, des ERP et des grands programmes — Amazon

Consulter la référence

Consulter la référence

#GouvernanceIT #ArchitectureSI #DSI #GuyDeLussigny #TransformationNumerique