- Les modifications aux progiciels coûtent cher trois fois : au développement, à l'entretien et à chaque mise à jour de version.
- L'approche recommandée est d'adopter les processus d'affaires standards pris en charge par le progiciel (approche « vanille »).
- Avant toute modification : analyse complète des coûts (conception, entretien, soutien, migration) et des bénéfices réels.
- En dernier recours, une extension ajoute de la fonctionnalité sans compromettre l'intégrité du progiciel.
Les modifications aux progiciels sont coûteuses, et ce, à tous les égards. On pourrait les comparer à des saveurs de crème glacée : dans l'univers des progiciels, il n'y a pas de meilleure saveur que la vanille. En d'autres termes, les modifications laissent souvent une saveur amère.
On suggère donc d'adopter des processus d'affaires pris en charge par les progiciels, une approche beaucoup plus efficace que d'adapter le logiciel à votre organisation à coups de modifications.
Pourquoi les modifications aux progiciels sont-elles si coûteuses?
Parce qu'elles coûtent cher trois fois : au développement, à l'entretien, puis à chaque mise à jour du progiciel, où elles doivent être revues et adaptées à la nouvelle version. Elles représentent aussi des facteurs de risque majeurs pour un projet d'implantation. Aucune modification ne devrait être mise en place sans une analyse complète des coûts et des bénéfices.
Lors d'un passage à une nouvelle version, les modifications apportées doivent être revues et adaptées. C'est une opération coûteuse qui retarde l'échéancier du projet de migration. Il est aussi fort possible que l'équipe qui a initialement développé la modification ne soit plus disponible, et que la documentation soit introuvable.
Dans les cas extrêmes, des modifications trop importantes peuvent même empêcher le fabricant d'honorer le contrat de soutien de son produit : une problématique sérieuse si le progiciel a besoin d'une mise à jour ou d'un entretien.
Dans l'univers des progiciels, il n'y a pas de meilleure saveur que la vanille.
Que vérifier avant de modifier un progiciel?
Tous les coûts liés à la conception, à l'entretien, au soutien et à la migration éventuelle de la modification, ainsi que les bénéfices réels qu'elle apporte. Ces demandes de changement peuvent augmenter les coûts prévus dans les budgets de projets ERP.
Si le besoin persiste, informez-vous d'abord auprès du fabricant : la fonctionnalité pourrait être livrée dans la prochaine version du progiciel. Vous pouvez aussi lui demander de développer la modification, ou à tout le moins de réviser votre design et de chiffrer la prise en charge une fois la modification en production.
Pourquoi les modifications étaient-elles monnaie courante il y a 20 ans? Les progiciels offraient moins de fonctionnalités et étaient moins complexes. Aujourd'hui, ils prennent généralement en charge les pratiques d'affaires les plus répandues et reconnues.
Quelle est la différence entre une modification et une extension?
Une extension ajoute de la fonctionnalité sans toucher au cœur du progiciel, alors qu'une modification altère le produit lui-même. Certains éléments ne sont d'ailleurs pas considérés comme des modifications : les interfaces, les programmes de conversion de données et les rapports. Les interfaces sont souvent essentielles pour intégrer le progiciel aux autres applications de l'organisation, même si elles restent coûteuses à développer et à tester.
La création d'une extension doit toutefois suivre certaines règles. En premier lieu, il ne faut jamais créer directement des enregistrements dans la base de données du progiciel : s'il est nécessaire d'en créer, il faut passer par les interfaces fournies par le fabricant.
N'oubliez pas de documenter toutes les modifications, extensions et interfaces. Ces documents sont des mines d'or : ils soutiennent la production du progiciel et la migration vers la prochaine version.
Avant d'apporter des modifications, rappelez-vous les raisons qui vous ont poussé à choisir un progiciel : éviter de faire du développement, accéder facilement aux nouvelles versions et profiter des meilleures pratiques d'affaires. Les modifications peuvent paraître économiques à court terme; elles ne simplifieront ni vos processus à moyen et long terme, ni le passage à la prochaine version. C'est un pensez-y-bien.
Configuration, extension ou modification : comment décider?
Une habitude interne ne justifie pas automatiquement un développement. À l’inverse, un besoin de traçabilité ou un engagement contractuel peut exiger une adaptation. Faites décrire le besoin par le responsable du processus avant de choisir le moyen technique.
| Option | Quand la retenir | Preuve avant approbation |
|---|---|---|
| Processus standard | Le besoin est satisfait en changeant une pratique interne | Démonstration avec données représentatives et validation métier |
| Configuration | Le produit propose les paramètres et règles nécessaires | Paramètres documentés, droits d’accès et essais des exceptions |
| Extension ou interface | Le besoin subsiste et les mécanismes prévus par l’éditeur le permettent | Compatibilité vérifiée, gestion des rejets et responsable du soutien |
| Modification du cœur | Cas exceptionnel, après examen des autres options | Accord sur le soutien, coût d’évolution, solution de remplacement et décision de direction |
Cas d’usage pour une PME manufacturière québécoise
Exemple fictif. Un manufacturier de 180 employés veut reproduire un formulaire d’expédition historique. Commencez par vérifier si le document standard, les champs configurables et le générateur de rapports répondent au besoin. Si le besoin réel est la traçabilité d’un lot, testez cette chaîne complète au lieu de valider seulement l’apparence du formulaire.
Un distributeur peut avoir besoin d’une interface transporteur; une firme de services, d’une règle de facturation par projet. Une interface ne modifie pas nécessairement le cœur du produit, mais elle ajoute des responsabilités de sécurité, de surveillance et de reprise. Son coût ne disparaît pas parce qu’on l’appelle une extension.
Quels critères d’acceptation joindre à une demande de développement?
La demande doit relier le besoin, le résultat attendu et la preuve de réussite. Faites approuver les éléments suivants avant d’engager les travaux.
- Un propriétaire métier et une conséquence vérifiable si le besoin n’est pas satisfait.
- Une démonstration des options standard et configurables déjà examinées.
- Les règles d’accès, les données touchées et le traitement des erreurs.
- Un scénario nominal et un scénario d’exception avec résultat attendu.
- Le coût initial, le soutien, les essais récurrents et les conditions d’évolution.
- Le code, la documentation, les droits d’utilisation et une solution de remplacement documentés selon le contrat.
Questions fréquentes
Qu'est-ce qu'une approche « vanille » en implantation de progiciel?
C'est le fait d'implanter le progiciel sans modification, en adoptant les processus d'affaires standards qu'il prend en charge. Cette approche réduit les coûts de développement et d'entretien, simplifie les mises à jour et réduit les risques de compatibilité; les conditions de soutien restent celles du contrat.
Pourquoi les modifications compliquent-elles les mises à jour?
À chaque nouvelle version du progiciel, les modifications doivent être revues, adaptées et retestées. L'opération est coûteuse et retarde la migration, d'autant plus si l'équipe d'origine n'est plus disponible ou que la documentation manque.
Quelles alternatives existe-t-il à la modification d'un progiciel?
Quatre pistes : adopter le processus standard du progiciel, attendre la fonctionnalité dans une prochaine version, faire développer la modification par le fabricant, ou créer une extension qui ajoute la fonctionnalité sans compromettre l'intégrité du produit.
Une extension ERP est-elle sans risque lors des mises à jour?
Non. Une extension peut éviter de modifier le cœur du produit, mais elle doit rester compatible avec ses interfaces et ses versions. Prévoyez des essais de régression, un responsable du soutien et une procédure de retrait ou de correction.
Source primaire : recommandations de PlanAxion issues de son expérience en implantation, évolution et soutien de progiciels.
