Personnaliser un ERP sans se piéger à la prochaine version

« Est-ce qu’on peut faire comme avant ? » est la question la plus coûteuse d’un projet ERP. Techniquement, presque tout se développe. Mais chaque développement s’ajoute à la facture de chaque mise à jour, et un ERP trop personnalisé finit figé sur une version ancienne.

Niveau 1 : adapter le processus

L’écart entre votre façon de faire et le standard du logiciel a deux origines possibles : une règle métier réelle, ou une habitude. Une habitude se change. Le standard d’un ERP comme Odoo ou Dolibarr reflète la pratique de milliers d’entreprises ; s’y aligner coûte une formation, pas un développement. Le cadrage sert à faire ce tri, et le cahier des charges note pour chaque règle si elle est légale, contractuelle ou simplement habituelle.

Niveau 2 : paramétrer

Sans écrire de code, un ERP se règle beaucoup : champs supplémentaires, listes de valeurs, règles de validation, étapes de processus, modèles de devis et de factures, rapports filtrés. Sur Odoo, l’application Studio, réservée à l’édition Enterprise, pousse ce paramétrage loin : formulaires, vues, automatisations simples.

Studio a une limite à connaître : ce qu’il crée vit dans la base et suit les migrations de l’éditeur, mais une accumulation de règles sans documentation devient difficile à comprendre. La même discipline s’applique : chaque ajout a une raison écrite.

Niveau 3 : développer

Certaines règles justifient un développement : un calcul de prix propre au métier, une intégration sans connecteur, un document réglementaire spécifique. Dans ce cas :

1. 01Un module isolé

   Jamais de modification du code de l’éditeur.

2. 02Court

   La règle métier, rien d’autre.

3. 03Testé

   Des tests automatiques qui disent si la migration l’a cassé.

4. 04Documenté

   Pourquoi il existe, qui l’a demandé, ce qu’il fait.

Les consignes de développement d’Odoo décrivent cette organisation en modules. Dolibarr suit la même logique avec ses modules externes.

Le coût réel d’un développement

Un développement coûte trois fois : à l’écriture, à chaque migration de version, et à chaque fois qu’une personne nouvelle doit le comprendre. Odoo sort une version majeure par an ; un module spécifique doit être vérifié, souvent adapté, à chaque passage. Sur cinq ans, ce coût de maintenance dépasse souvent celui de l’écriture.

Avant de valider un développement, posez la question : ce qu’il fait gagner chaque année couvre-t-il sa maintenance ? Si la réponse est incertaine, restez au niveau 2.

Les modules de la communauté

Les modules de l’association OCA pour Odoo ou du DoliStore pour Dolibarr comblent beaucoup de besoins sans développement. Ils ont un avantage, la maintenance partagée, et un risque, un auteur qui arrête de suivre les versions. Vérifiez qu’un module est maintenu sur les versions récentes avant de l’adopter, et limitez leur nombre.

Le signe qu’on est allé trop loin

Une migration de version repoussée d’année en année parce qu’elle « casserait trop de choses ». C’est le symptôme décrit dans Pourquoi un projet ERP échoue. La sortie passe par un inventaire des développements, la suppression de ceux qui ne servent plus, et le remplacement de ceux que le standard couvre désormais.

Une règle à écrire dès le cadrage

Le meilleur moment pour fixer la règle des trois niveaux est le cadrage, avant le premier atelier. Écrite dans le cahier des charges, elle donne à chacun le même réflexe : quand une demande arrive, on cherche d’abord dans le standard, puis dans le paramétrage, et on ne développe qu’avec une raison écrite et un gain chiffré. Les ateliers deviennent plus courts, et la liste des développements reste lisible. le guide complet de l’ERP replace cette règle dans l’ensemble du projet. Dans notre offre CRM et ERP, chaque développement proposé est justifié par écrit et chiffré, maintenance comprise.

Questions fréquentes

Sources

1. Documentation développeur d’Odoo (nouvel onglet)odoo.com