Personnaliser Odoo
Personnaliser Odoo est facile. Bien le personnaliser — pour que ça survive aux upgrades, ne casse pas pour le prochain consultant et ne double pas silencieusement votre TCO sur cinq ans — est un autre sport. Nous avons hérité de suffisamment de personnalisations Odoo héroïques mais immaintenables pour connaître les règles qui comptent. Ce guide est le playbook.
La plupart des regrets de personnalisation Odoo se ramènent à l'une de trois décisions : Studio utilisé là où il fallait un module custom, du code custom utilisé là où Studio aurait suffi, ou pire — les deux ensemble sans propriétaire clair.
Faites le bon choix et Odoo s'adaptera magnifiquement à votre métier. Faites le mauvais et chaque upgrade annuel deviendra un petit projet d'archéologie. Les règles ci-dessous sont comment nous gardons nos clients dans le premier camp.
Les trois outils de personnalisation que vous avez vraiment
Odoo vous donne trois vrais chemins de personnalisation : configuration (sans code, livré avec le produit), Studio (low-code, livré avec Enterprise) et modules custom (Python + XML, écrits par un développeur). Ils diffèrent en coût, en longévité, en compatibilité upgrade et en cas d'usage. La plupart des équipes sous-utilisent les deux premiers et surutilisent le troisième.
Il y a un quatrième chemin que beaucoup oublient : le catalogue de modules OCA (Odoo Community Association). Des centaines de modules communautaires couvrent des besoins courants qui seraient sinon du dev custom. Nous utilisons des modules OCA chaque semaine — bien choisis et bien maintenus, c'est un levier gratuit.
- Configuration : champs, paramètres et règles intégrés — sans code, sans risque upgrade
- Studio : personnalisation low-code de champs/vues/rapports — Enterprise uniquement, surtout sûr à l'upgrade
- Modules custom : Python + XML — totalement flexibles, à vous, vrai travail d'upgrade
- Modules OCA : gratuits, maintenus par la communauté, qualité variable — auditez avant installation
- Automatisation de workflow : couverte par Odoo Automations + Studio pour la plupart des besoins
Studio — quand c'est la bonne réponse (et quand ce ne l'est pas)
Studio est génial pour les changements additifs, locaux et à faible enjeu : un nouveau champ sur une commande de vente, une vue custom pour l'équipe entrepôt, un petit ajustement de rapport. C'est stocké en base, survit à la plupart des upgrades, et tout consultant Odoo peut le lire. Pour les bons cas d'usage, Studio économise des semaines de temps développeur.
Studio est la mauvaise réponse pour la logique métier critique, les calculs complexes, les intégrations avec systèmes externes ou tout ce qui demande de vrais tests. Nous avons vu 40 k€ de « règles » Studio qui auraient dû être un module custom à 15 k€ — plus dur à déboguer, plus dur à upgrader, et impossible à peer-reviewer.
- Utilisez Studio pour nouveaux champs, vues simples, rapports simples, automatisations simples
- Utilisez Studio quand le changement est local et ne sera pas réutilisé entre modules
- N'utilisez pas Studio pour des calculs métier critiques ou intégrations externes
- N'utilisez pas Studio pour ce qui demande des tests unitaires — il n'y en a pas
- Documentez les changements Studio dans votre wiki projet — ils sont invisibles depuis Git
Modules custom — quand ils valent le coup
Les modules custom sont la bonne réponse quand le changement est structurel, réutilisable, métier-critique, ou doit s'intégrer avec quoi que ce soit en dehors d'Odoo. Exemples que nous construisons régulièrement : moteurs de prix sectoriels, intégrations EDI, portails clients à logique custom, modules de reporting agrégeant entre sociétés. Bien faits, ils survivent aux upgrades pendant des années.
Le coût est réel : budgétez 5-50 k€ par module custom selon le scope, plus 10-30 % de ce chiffre annuellement pour upgrade et maintenance. La règle que nous appliquons est « deux fois ». Si une demande sera faite par plus d'une personne, plus d'une fois par semaine, sur plus d'un écran — c'est un candidat module custom. Sinon, Studio.
- Utilisez modules custom pour logique structurelle, réutilisable ou métier-critique
- Utilisez-les pour toute intégration non-triviale avec systèmes externes
- Toujours avec Git, peer review, tests automatisés — sans exception
- Budgétez 10-30 % du coût de build annuellement pour upgrade et maintenance
- Évitez l'anti-pattern « un gros module custom » — divisez en modules focalisés
Modules OCA — le levier gratuit sous-utilisé
L'OCA (Odoo Community Association) maintient des centaines de modules communautaires couvrant des besoins qui seraient sinon du dev custom. Beaucoup sont production-grade et utilisés par des milliers d'entreprises. Ils sont gratuits, open source, et bien maintenus pour les plus populaires — mais la qualité varie et vous devez auditer avant d'installer.
Notre règle : vérifier OCA avant de chiffrer tout module custom. Une demande custom sur trois a un équivalent OCA crédible qui vous amène à 80 % du chemin gratuitement. Les 20 % restants sont souvent acceptables, ou une petite extension. Nous traitons OCA comme un citoyen de premier ordre dans toute discussion de personnalisation.
- Vérifier OCA avant de chiffrer tout module custom — économise une fois sur trois
- Auditez les modules OCA : dernier commit, mainteneur, compatibilité version
- Restez sur des modules OCA largement utilisés — la longue traîne est risquée
- Les modules OCA peuvent être étendus (héritage) — vous ne forkez pas, vous enveloppez
- Le retard d'upgrade OCA est réel — vérifiez qu'un module supporte votre version cible
Compatibilité upgrade — le vrai coût de la personnalisation
Toute personnalisation a une taxe upgrade. Configuration : gratuite. Studio : presque gratuit (corrections occasionnelles par upgrade). OCA : modéré (dépend du timing de release communautaire). Modules custom : argent réel par upgrade — typiquement 10-25 % du coût de build initial, selon la propreté de l'écriture et l'évolution des APIs internes Odoo.
Les équipes qui souffrent le plus au moment de l'upgrade sont celles qui ont sauté la peer review, sauté les tests et codé en dur contre des classes internes Odoo plutôt que des APIs publiques. Les équipes qui passent les upgrades sans souci sont celles qui ont traité leurs modules custom avec la même discipline qu'un code de production quelconque.
- Configuration : 0 % de coût upgrade — toujours gratuit
- Studio : ~5 % de coût upgrade — surtout gratuit, corrections manuelles occasionnelles
- OCA : ~10-20 % de coût upgrade — dépend du timing de release communautaire
- Modules custom : 10-25 % du build initial par upgrade — proportionnel à la discipline
- Couverture de tests et peer review au build prédisent le coût d'upgrade plus que tout
Erreurs de personnalisation que nous nettoyons sans cesse
Voici les patterns qui transforment un Odoo gérable en Odoo cher.
- Utiliser Studio pour de la logique de prix métier-critique — invisible depuis Git, intestable, fragile.
- Écrire un module custom pour un changement de 5 lignes que Studio aurait fait en 10 minutes.
- Ignorer OCA — payer 15 k€ pour ce qu'un module communautaire mature et gratuit fait déjà.
- Personnaliser sur le premier projet d'un consultant junior, sans peer review ni tests.
- Construire un gros module custom « utils » plutôt que des petits modules focalisés et mono-objet.
Comment mesurer la santé de votre stratégie de personnalisation
Marqueurs que nous regardons après un an d'opération.
- Part de code custom sous 15 % de l'empreinte Odoo totale — prédit un faible coût d'upgrade.
- Changements Studio documentés dans le wiki — chaque changement Studio a une note d'une ligne.
- Couverture de tests sur les modules custom au-dessus de 60 % — protège upgrade et refactoring.
- Délai d'upgrade vers la version annuelle suivante sous 4 semaines — proxy de la discipline au build.
- Nombre de modules OCA similaire ou supérieur au nombre de modules custom — signale la discipline.
Comment nous abordons la personnalisation chez Flydoo
Notre défaut est « configurer d'abord, Studio ensuite, OCA en troisième, custom en dernier ». Nous documentons chaque décision de personnalisation avec un rationale d'une page expliquant pourquoi nous avons choisi cette approche. Les modules custom passent par Git, peer review, tests automatisés à chaque commit. Les changements Studio sont loggés dans le wiki projet avec une capture d'écran.
Nous disons non aux clients quand une demande coûterait cher à maintenir — et nous proposons l'alternative moins chère. Environ deux demandes custom sur trois sont redirigées vers Studio, OCA ou un changement de processus. La troisième devient un module custom correctement ingénieré.
- Ordre par défaut : configurer → Studio → OCA → custom — expliquer toute déviation
- Chaque personnalisation a un rationale d'une page documentant pourquoi cette approche
- Modules custom : Git, peer review, tests automatisés, sans exception
- Changements Studio loggés dans le wiki avec capture d'écran — la visibilité compte
- Nous disons non aux personnalisations chères et offrons l'alternative moins coûteuse
Checklist pratique de personnalisation
Cochez la plupart avant d'approuver tout dev custom.
- La configuration seule a été écartée avec preuves
- Studio a été envisagé et écarté pour une vraie raison
- OCA a été cherché — aucun module équivalent n'existe ou ne marche
- Le business owner peut expliquer le changement en un paragraphe sans jargon
- Le coût upgrade estimé sur 3 ans a été inclus dans le budget
- Le module custom vivra dans Git avec peer review et tests
- Les exigences de documentation sont accordées avant le démarrage
À retenir
- Hiérarchie de personnalisation : configurer → Studio → OCA → custom — dans cet ordre
- Studio est génial pour changements locaux à faible enjeu, dangereux pour la logique métier-critique
- Les modules OCA sont un levier gratuit sous-utilisé — vérifiez avant de chiffrer du custom
- Les modules custom coûtent 10-25 % du build initial par upgrade annuel — budgétez-le
- Couverture de tests et peer review au build prédisent le coût d'upgrade plus que tout
Questions fréquentes
Dois-je utiliser Studio ou un module custom ?
Studio pour les changements additifs, locaux, à faible enjeu — nouveaux champs, vues simples, petits rapports. Modules custom pour la logique structurelle, réutilisable, métier-critique, ou toute intégration non-triviale. Le test rapide : « plus d'une personne, plus d'une fois par semaine, sur plus d'un écran en dépendra-t-elle ? » Si oui, module custom. Sinon, Studio est en général très bien. L'erreur est d'utiliser Studio pour des choses qui ont besoin de peer review, tests et Git — ces choses ne sont pas optionnelles pour la logique métier-critique.
Qu'est-ce que l'OCA et devons-nous l'utiliser ?
OCA est l'Odoo Community Association — une non-profit qui maintient des centaines de modules communautaires. Beaucoup sont production-grade et utilisés par des milliers d'entreprises ; certains sont en early-stage ou abandonnés. Oui, vous devriez utiliser OCA — mais auditez chaque module : dernier commit, compatibilité avec votre version cible, activité du mainteneur, et nombre d'étoiles/forks. Une demande custom sur trois a une solution OCA crédible qui vous amène à 80 % du chemin gratuitement.
Combien la personnalisation ajoute-t-elle au coût d'upgrade ?
Changements de configuration : rien. Changements Studio : un petit fix par upgrade dans 10-20 % des cas. Modules OCA : dépend du timing de release communautaire, en général 10-20 % du coût de build équivalent par upgrade. Modules custom : 10-25 % du coût de build initial par upgrade annuel, dépendant fortement de la discipline d'ingénierie (Git, tests, peer review, usage d'APIs publiques vs internes). Les équipes qui passent les upgrades sans souci sont celles qui ont bien construit dès le départ.
Pouvons-nous nous auto-personnaliser sans partenaire ?
Configuration et Studio : oui, avec une formation correcte. Beaucoup de nos clients gèrent eux-mêmes les changements Studio une fois formés. Modules custom : pas sans un développeur Python en interne qui connaît le framework et les conventions Odoo. La tentation de « juste faire coder ça par quelqu'un » finit en général par un module custom qui casse à la prochaine upgrade. Si vous allez construire du code custom, traitez-le comme tout code de production : Git, review, tests.
Quelle est l'erreur de personnalisation la plus chère ?
Mettre de la logique métier-critique dans Studio. C'est invisible depuis Git, dur à peer-reviewer, intestable en automatisation, et plus dur à déboguer que du code équivalent. Nous avons vu des moteurs de prix, calculs de TVA et workflows d'approbation construits dans Studio qui ont coûté à l'entreprise des semaines de travail d'audit et des dizaines de milliers en réparation. Si le changement compte, construisez-le comme un vrai module. Studio est pour le tweak additif de 5 minutes, pas pour le cœur de votre métier.
Besoin d'aide pour appliquer tout cela à votre contexte ? Parlons-en.