Stack · Développement
Développement de module Odoo
La question n'est pas « est-ce faisable ». Presque tout l'est. La question est : dans quel état sera ce code à la prochaine migration, et qui saura le reprendre ?
Presque tout est faisable dans Odoo. C’est ce qui rend la question « c’est possible ? » inutile — la réponse est oui, et elle ne vous apprend rien.
Les bonnes questions sont ailleurs : dans quel état sera ce code à la prochaine migration ? Qui pourra le reprendre si nous disparaissons ? Et surtout : fallait-il vraiment développer ?
Paramétrer avant de développer
Une bonne part des demandes de développement que nous recevons n’en sont pas. Un champ à ajouter, une automatisation, une vue adaptée, une règle de tarif : ça se paramètre, ça survit aux migrations tout seul, et ça ne coûte presque rien.
Le développement commence là où le paramétrage s’arrête. Nous le disons même quand le développement serait plus rentable pour nous — parce que le module de trop, c’est de la maintenance à vie pour un besoin qu’une case à cocher couvrait.
La règle qui prime toutes les autres
Odoo est conçu pour être étendu : on hérite d’un modèle pour lui ajouter un champ, on surcharge une méthode en appelant celle d’origine, on étend une vue par un point d’insertion. Ces mécanismes survivent aux montées de version, précisément parce qu’ils ne touchent à rien.
Le code vous appartient
C’est un choix de principe, et il a des conséquences concrètes :
| Notre pratique | Ce que ça vous garantit |
|---|---|
| Module versionné dans votre dépôt | Vous ne perdez rien si nous disparaissons |
| Code documenté | Un autre développeur peut le lire |
| Mapping écrit, champ par champ | Personne n’a à deviner ce que fait le connecteur |
| Aucun secret dans le code | Vos clés ne partent pas dans un dépôt |
| Pas d’obfuscation, pas de licence maison | Vous pouvez changer de prestataire |
Le vrai test tient en une phrase : un confrère peut-il reprendre ce module sans nous appeler ? Si la réponse est non, le module est mauvais — même s’il fonctionne. Nous écrivons en sachant qu’un autre le lira.
Ce qui fait qu’un module tient
- Le périmètre. Un module fait une chose. Un module fourre-tout qui gère la synchro, les remises et les étiquettes est impossible à migrer par morceaux.
- L’héritage plutôt que la copie. Copier une méthode pour en changer trois lignes fige le comportement d’origine : les correctifs d’Odoo ne vous atteindront plus jamais.
- Les tests. Pas de la couverture pour la couverture : les cas qui font mal — un flux rejoué, une valeur manquante, une API qui répond mal.
- La journalisation. Ce que le module a fait, sur quel enregistrement, avec quel résultat. Lisible par votre équipe, pas seulement par nous.
Reprendre un module existant
C’est une part importante de notre travail, et le diagnostic tient en trois questions :
- Touche-t-il au cœur ? Si oui, l’ampleur est connue : c’est une reconstruction, avec un calendrier.
- Est-il versionné ? Si le seul exemplaire est sur le serveur de production, il n’y a pas d’historique et pas de retour arrière.
- Est-il compréhensible ? Un développeur qui ne l’a pas écrit peut-il dire ce qu’il fait ?
Trois non, et vous n’avez pas un module : vous avez une dette dont vous ne connaissez pas encore le montant. Nous le chiffrons avant de nous engager, plutôt que de le découvrir ensemble à mi-parcours.
Les limites, dites franchement
Un développement, c’est de la maintenance à vie. Chaque module devra être porté à chaque migration. Le coût réel d’une fonction n’est pas son développement, c’est sa maintenance sur cinq ans. Nous chiffrons les deux.
Certaines demandes ne méritent pas un module. Contourner une contrainte fonctionnelle par du code, c’est souvent créer un problème plus gros que celui qu’on résout. Nous le disons.
Nous refusons les urgences qui imposent le raccourci. Un développement pressé qui modifie le cœur nous ferait gagner un projet et vous coûterait une migration. Ce n’est pas un échange équitable.
Pour ce que ça implique au moment de changer de version, voir migration de version.
Questions fréquentes
Pourquoi refuser de modifier le cœur d'Odoo ?
Parce que la facture arrive plus tard, et qu’elle est salée. Une modification du cœur est perdue ou incompatible à la migration suivante : il faut alors reconstruire ce que le raccourci avait économisé, des années après, sans celui qui l’a écrit. Nous refusons, même quand ça ferait gagner trois jours, et même quand le client insiste.
À qui appartient le code ?
À vous. Il est versionné dans votre dépôt, documenté, et reprisable par un autre prestataire. Nous ne construisons pas de dépendance : si vous partez, vous partez avec tout. C’est aussi la meilleure garantie que le code est propre — on écrit différemment quand on sait qu’un confrère le lira.
Faut-il développer ou paramétrer ?
Paramétrer d’abord, toujours. Une bonne part des demandes de développement se règlent par une configuration, une automatisation ou une vue. Le développement commence là où le paramétrage s’arrête, pas avant — et c’est à nous de le dire, y compris quand le développement serait plus rentable pour nous.
Comment savoir si un module existant est de bonne qualité ?
Trois questions suffisent à trancher : touche-t-il au cœur ? est-il versionné quelque part ? un développeur qui ne l’a pas écrit peut-il comprendre ce qu’il fait ? Trois non, et vous n’avez pas un module, vous avez une dette dont vous ne connaissez pas encore le montant.
Les modules de la communauté sont-ils utilisables ?
Souvent oui, et c’est parfois plus sage que de redévelopper. Le critère n’est pas la gratuité mais la maintenance : un module actif, suivi sur les versions récentes, est un bon pari. Un module abandonné depuis deux versions est une dette qu’on adopte volontairement.
Un point technique à valider ?
Décrivez le contexte : version d'Odoo, systèmes en jeu, volumétrie. Réponse d'un intégrateur sous 24 h ouvrées.