Une PME industrielle déploie un ERP standard pour gérer ses achats et sa production. Six mois plus tard, l’équipe logistique bidouille des exports Excel parce que le workflow de validation ne colle pas à son circuit interne. Le logiciel fonctionne, mais l’entreprise travaille autour de lui plutôt qu’avec lui. Ce scénario, on le croise sur la majorité des projets où le choix entre logiciel standard et développement sur mesure a été tranché trop vite, sans cartographier les processus réellement critiques.
Verrouillage technique d’un ERP standard : où se cache la rigidité
La rigidité d’un logiciel standard ne se manifeste pas le jour de l’installation. Elle apparaît quand on tente de modifier un processus métier que l’éditeur n’a pas prévu. Un CRM du marché gère très bien un tunnel de vente classique, mais si le cycle commercial de l’entreprise inclut une phase de co-conception avec le client, le modèle de données impose des contournements.
A lire en complément : Pourquoi choisir un cloud français sur mesure ?
Le vrai piège, c’est la personnalisation qui crée une dette technique silencieuse. Ajouter des champs personnalisés, des automatisations bricolées ou des plugins tiers finit par rendre les montées de version risquées. On se retrouve verrouillé non pas par le logiciel lui-même, mais par la couche de personnalisation qu’on a empilée dessus.
Depuis 2023, la réglementation européenne (Data Act, DMA) pousse les éditeurs à intégrer des mécanismes de portabilité et des API documentées. Choisir un logiciel sur mesure n’est plus la seule parade contre le verrouillage propriétaire, à condition de vérifier concrètement le niveau d’ouverture de la solution standard avant de signer.
A voir aussi : 10 éditeurs de logiciel dans le domaine de la data à suivre en France
Approche hybride : socle standard et extensions sur mesure découplées
Les retours d’expérience de DSI partagés lors de conférences récentes convergent vers un même schéma : garder un socle standard stable pour les fonctions génériques (comptabilité, gestion des contacts, reporting) et développer la spécificité métier dans des micro-services ou des applications low-code découplées du noyau.
Cette architecture a un avantage direct : les mises à jour de l’éditeur ne cassent pas les extensions métier, parce qu’elles communiquent par API, pas par modification du code source. On conserve la maintenance communautaire du standard tout en gardant la main sur ce qui différencie l’entreprise.
Trois critères pour délimiter le périmètre sur mesure
- Le processus concerné constitue un avantage concurrentiel ou une obligation réglementaire propre au secteur, pas une simple préférence d’organisation interne.
- Le logiciel standard ne propose aucune configuration native (règles métier, workflows paramétrables) qui couvre le besoin, même partiellement.
- Le coût de maintenance de l’extension reste soutenable par les équipes internes sur au moins trois ans, y compris en cas de turnover technique.
Si aucun de ces trois critères n’est rempli, adapter le processus au logiciel coûte moins cher que l’inverse. On sous-estime souvent combien un processus interne considéré comme « spécifique » relève en fait d’une habitude plus que d’une contrainte métier réelle.
Gestion de projet et adoption : les erreurs qui figent le périmètre
Un développement sur mesure peut devenir aussi rigide qu’un logiciel standard si le projet est mal cadré. Le problème classique : un cahier des charges rédigé en une fois, validé par la direction, puis transmis à une équipe de développement qui livre six mois plus tard un produit conforme au document mais décalé par rapport aux besoins réels des utilisateurs.
Découper le projet en lots courts avec des tests utilisateurs à chaque itération reste la meilleure protection contre cette dérive. Les équipes métier voient ce qui fonctionne et corrigent le tir avant que le périmètre ne se fige dans le code.
Coûts cachés à surveiller côté standard comme sur mesure
Côté standard, on pense rarement au coût des licences par utilisateur qui augmentent à chaque renouvellement, ni aux frais de consulting pour paramétrer les fonctionnalités avancées. Côté sur mesure, le poste le plus sous-estimé est la documentation technique. Sans elle, le départ d’un développeur clé peut bloquer toute évolution pendant des mois.
- Standard : vérifier la politique tarifaire sur trois à cinq ans, pas seulement le prix d’entrée. Examiner les conditions de réversibilité des données.
- Sur mesure : prévoir un budget de tests (unitaires, d’intégration, de non-régression) dès le démarrage, pas en fin de projet.
- Hybride : budgéter la maintenance des connecteurs API entre le socle standard et les extensions, car les versions d’API évoluent.
Qualité des données et interopérabilité : le vrai indicateur de souplesse
On peut débattre longtemps de standard contre sur mesure. Le critère qui tranche dans la pratique, c’est la capacité du système à exporter, transformer et réimporter des données sans perte de structure. Un logiciel souple est un logiciel qu’on peut quitter ou faire dialoguer avec un autre sans projet de migration pharaonique.
Avant de choisir, on recommande de tester concrètement l’export d’un jeu de données représentatif. Si l’export produit un fichier plat qui perd les relations entre objets (liens entre un contact et ses commandes, par exemple), la promesse de flexibilité de l’éditeur ne tient pas. Les retours varient sur ce point selon les versions et les modules activés, d’où l’utilité de faire ce test sur l’environnement réel, pas sur une démo commerciale.
La souplesse d’un système informatique ne se mesure pas au moment du déploiement. Elle se révèle le jour où l’entreprise change de stratégie, absorbe une filiale ou doit se conformer à une nouvelle exigence réglementaire.
Un logiciel standard bien choisi, avec des API ouvertes et un périmètre de personnalisation maîtrisé, peut offrir autant de marge de manœuvre qu’un développement sur mesure mal documenté. Le piège de la rigidité n’est pas dans la catégorie du logiciel, mais dans la qualité des décisions prises au moment du cadrage.
