Dans tout projet ERP arrive la phrase : « chez nous, on fait autrement ». Parfois, c'est vrai et c'est un avantage. Le plus souvent, c'est une habitude héritée d'un ancien logiciel, et la reproduire coûte cher longtemps.
Il n'existe pas de réponse générale, mais il existe une méthode pour trancher cas par cas, en quelques minutes.
L'essentiel
- Une personnalisation est une dette : elle se rembourse en recette à chaque montée de version majeure.
- La règle : ne personnaliser que ce qui porte un avantage concurrentiel, aligner le reste sur le standard.
- Quatre alternatives à essayer avant de développer : paramétrage, module communautaire, changement de procédure, renoncement.
- 1 725 modules communautaires documentés : beaucoup de « besoins spécifiques » sont déjà résolus par quelqu'un d'autre.
- Le signal d'alerte : une demande qui commence par « comme dans notre ancien logiciel ».
Les trois questions qui tranchent
- Est-ce que ça nous fait gagner des clients, ou de la marge ? Si la réponse est non, c'est une habitude, pas un avantage. Une habitude s'aligne.
- Est-ce qu'un concurrent ferait différemment ? Si tout le monde fait pareil dans votre métier, le standard le couvre probablement, ou un module communautaire le fait déjà.
- Qu'est-ce qui se passe si on fait comme le standard pendant trois mois ? C'est la question la plus efficace, et la plus rarement posée. Souvent, la réponse est « rien ».
La troisième question mérite d'être posée littéralement, en réunion. Elle transforme un débat de principe en expérience datée, et elle désamorce la plupart des demandes.
Un processus qu'on ne sait pas justifier autrement que par « on a toujours fait comme ça » n'est pas un processus : c'est un souvenir d'un logiciel qu'on a quitté.
Les quatre alternatives, dans l'ordre à essayer
| # | Alternative | Coût | Dette à la montée de version |
|---|---|---|---|
| 1 | Paramétrage du standard | Faible | Aucune |
| 2 | Module communautaire existant | Faible | Faible : porté par la communauté |
| 3 | Changer la procédure interne | Organisationnel | Aucune |
| 4 | Renoncer au besoin | Nul | Aucune |
| 5 | Développement spécifique | Élevé | Élevée, à chaque version |
L'ordre est le bon ordre, et la quatrième ligne est celle qu'on oublie : renoncer est une option légitime. Beaucoup de besoins exprimés en début de projet ne sont jamais réclamés une fois l'outil en service.
La deuxième ligne est celle qui surprend le plus. Avec 1 725 modules communautaires documentés sur 51 dépôts, la probabilité qu'un besoin « spécifique » soit déjà résolu est élevée — approbations d'achat, remises en cascade, contrôles de chronologie comptable, relances paramétrées. Voir comment choisir un module communautaire.
Quand la personnalisation est le bon choix
Elle existe, et elle est alors pleinement justifiée. Trois cas que nous rencontrons régulièrement.
- Un calcul propre à votre métier qui détermine votre prix de vente ou votre coût de revient — une formule de chiffrage, un barème, une méthode de valorisation particulière.
- Une intégration avec un équipement ou un système client : une machine d'atelier, un portail de donneur d'ordre, un format d'échange imposé.
- Un avantage concurrentiel reconnaissable : ce que vos clients remarquent et que vos concurrents ne font pas.
Dans ces trois cas, le bon réflexe n'est pas de modifier le cœur d'Odoo mais d'écrire un module : il s'installe, se désinstalle, se teste séparément, et il survit beaucoup mieux aux montées de version qu'une modification en place.
Ce que coûte une personnalisation sur cinq ans
Le devis initial d'un développement est la plus petite partie de son coût.
| Moment | Coût |
|---|---|
| Développement initial | Le montant du devis |
| Première montée de version | Recette + correction des écarts |
| Deuxième montée de version | Recette + correction, sur un code vieilli |
| Départ de la personne qui l'a demandée | Personne ne sait plus pourquoi c'est là |
| Le jour où ça bloque une évolution | Arbitrage entre le garder et tout refaire |
La quatrième ligne est la plus coûteuse et la moins anticipée. Un développement dont personne ne se souvient de la raison ne peut pas être supprimé — par prudence — et il continue d'être testé à chaque montée.
D'où une pratique simple et peu coûteuse : écrire, dans le module lui-même, pourquoi il existe. Pas ce qu'il fait — le code le dit — mais quel problème métier l'a justifié, et à quelle date. C'est ce qui permettra, dans trois ans, de décider de le retirer.
La règle que nous appliquons en projet
Elle est volontairement brutale, et elle évite des mois de discussion : aucun développement spécifique pendant les trois premiers mois.
La raison est empirique : la moitié des besoins « indispensables » exprimés avant le démarrage disparaissent une fois que l'équipe travaille réellement dans l'outil. Les autres se précisent, et se chiffrent mieux.
Trois mois après, la liste restante est courte, argumentée, et chaque ligne passe les trois questions. C'est à ce moment qu'on développe — et ce qu'on développe alors est utilisé. Voir réussir une migration vers Odoo.
Questions fréquentes
Peut-on modifier Odoo Community librement ?
Oui, sous licence LGPLv3 et avec les obligations de cette licence. La question n'est donc pas le droit mais le coût : chaque écart au standard se repaie en recette à chaque montée de version majeure. La bonne pratique est de passer par des modules plutôt que de modifier le cœur.
Combien coûte un développement spécifique dans Odoo ?
Le devis initial est la plus petite partie du coût. Il faut y ajouter la recette à chaque montée de version, et le risque qu'un développement devienne orphelin — plus personne ne sait pourquoi il existe, donc personne n'ose le retirer. Chiffrez sur cinq ans, pas sur la livraison.
Comment savoir si un module communautaire existe déjà pour mon besoin ?
En cherchant par domaine : approbations d'achat, remises, chronologie comptable, relances, rapports financiers. Avec 1 725 modules documentés sur 51 dépôts, la probabilité est élevée. C'est précisément pour répondre vite à cette question que nous maintenons cette documentation en français.
Que répondre à une équipe qui veut retrouver son ancien logiciel ?
Posez la troisième question : que se passe-t-il si on fait comme le standard pendant trois mois ? Elle transforme un débat de principe en expérience datée. Si au bout de trois mois le besoin est encore réclamé, il est réel et il mérite d'être chiffré.
Faut-il documenter les personnalisations ?
Oui, et pas seulement techniquement. Écrivez dans le module pourquoi il existe : quel problème métier l'a justifié, et à quelle date. C'est ce qui permettra, dans trois ans, de décider de le retirer — sans cette note, il sera conservé par prudence et testé indéfiniment.
Pour aller plus loin
- Quelle version choisir, et quand monter
- Les 6 modules par lesquels commencer
- Les erreurs d'un projet ERP en PME
En résumé
Trois questions : est-ce que ça nous fait gagner des clients ou de la marge, un concurrent ferait-il autrement, et que se passe-t-il si on fait comme le standard pendant trois mois. Quatre alternatives avant de développer. Et une règle : aucun développement spécifique les trois premiers mois. Parlons de vos vrais spécifiques.
