Le développement Odoo est souvent la ligne la plus floue d’un projet : on pense « spécifique » dès qu’un besoin sort de l’ordinaire, alors que la plupart des écarts se traitent sans écrire une ligne de code. Bien personnaliser Odoo, c’est d’abord choisir le bon niveau d’intervention, puis s’imposer une discipline qui protège les mises à jour futures.
Cette page présente les trois niveaux de personnalisation, leurs conséquences sur la maintenance, les bonnes pratiques à exiger et les questions à poser à un développeur ou à un intégrateur. Elle complète le guide de mise en place d’Odoo et la présentation générale d’Odoo.
Les trois niveaux de personnalisation d’Odoo
Une personnalisation se classe selon l’effort qu’elle demande et le risque qu’elle fait peser sur la suite.
| Niveau | Ce que l’on fait | Code ? | Effet sur les mises à jour |
|---|---|---|---|
| 1. Paramétrage | Activer des fonctions, régler des options, adapter documents et droits | Non | Aucun ou très faible |
| 2. Extension sans code ou existante | Studio, applications communautaires, connecteurs | Non ou peu | Faible à modéré, à vérifier |
| 3. Module sur mesure | Programmation d’un comportement spécifique | Oui | Maintenance à prévoir à chaque version |
La règle de bon sens : on ne monte d’un niveau que si le niveau inférieur ne répond pas au besoin, et qu’on a mesuré ce que la montée coûte dans la durée.
Niveau 1 : le paramétrage, à épuiser en premier
Avant toute personnalisation d’Odoo, il faut explorer ce que le standard sait déjà faire. Le catalogue est large : Odoo annonce 50 applications principales, et une communauté qui a contribué à plus de 50 000 applications supplémentaires. Beaucoup de besoins jugés « spécifiques » sont en réalité couverts par une option que l’on n’avait pas vue.
Le paramétrage couvre notamment :
- l’activation et la désactivation de fonctions dans chaque application ;
- les circuits de validation, les conditions de vente et d’achat, les modèles de documents ;
- les droits d’accès par profil ;
- les taxes, les plans comptables et les journaux, côté comptabilité et finance.
C’est le niveau le moins cher à mettre en œuvre et le plus sûr pour les montées de version. Un projet qui tient presque entièrement à ce niveau est un projet sain. Pour parcourir ce que le standard propose, consultez la page sur les modules Odoo.
Niveau 2 : Studio, applications existantes et connecteurs
Odoo Studio
Odoo Studio permet de personnaliser sans code les champs, les vues, les modèles, les applications, les règles d’automatisation, les webhooks, les rapports PDF, les règles d’approbation et les règles de sécurité. C’est l’outil adapté pour ajouter un champ de suivi, réorganiser un écran, créer une petite application interne ou déclencher une action automatique.
Deux points de vigilance, côté budget :
- Studio fait partie de la formule Custom. Odoo précise qu’installer Studio ou ajouter des sociétés fait basculer une base gratuite en Custom.
- Sur une base en formule Standard, installer Studio déclenche automatiquement un passage à la formule Custom : une commande complémentaire avec un délai de 30 jours en contrat annuel, ou un basculement automatique au prochain cycle de facturation en contrat mensuel.
Autrement dit, utiliser Studio n’est pas neutre sur l’abonnement. Le détail des formules se trouve dans la page prix d’Odoo.
Applications de la communauté et connecteurs
Avant de faire développer, vérifiez si une application existante couvre le besoin. Cela économise du temps, mais ne dispense pas de contrôle : une application de la communauté n’a pas le même niveau de suivi qu’une application officielle. Il faut regarder qui la maintient, avec quelle régularité, pour quelle version, et sous quelle licence.
Pour relier Odoo à un autre logiciel (boutique en ligne, transporteur, outil de paie, banque), les connecteurs et intégrations sont la première piste. Odoo eCommerce, par exemple, gère le catalogue et les variantes, les comptes clients, le B2B et le B2C, les paniers abandonnés, les modes de livraison, les retours et la facturation, avec le multi-sites ; il se connecte à plus de vingt fournisseurs de paiement et diffuse les produits via Google Merchant Center, TikTok, Facebook ou Instagram. Un développement n’a de sens que pour un flux que ces briques ne couvrent pas.
Niveau 3 : le développement spécifique
Langage, outils et licences
Odoo est écrit en Python, et les modules spécifiques s’y programment : modèles de données, vues, règles métier, rapports. Les développeurs peuvent créer des modules fondés sur Odoo et les distribuer sous la licence de leur choix, à condition qu’elle soit compatible avec celle de l’édition d’origine : LGPLv3 pour Community, restrictions Enterprise pour Enterprise.
Ce point juridique a des conséquences pratiques. Odoo 19 Community est sous licence LGPLv3 ; Odoo 19 Enterprise est sous la licence Odoo Enterprise Edition v1.0, utilisable seulement avec un abonnement Enterprise valide pour le bon nombre d’utilisateurs. Un module livré par un prestataire ne remplace jamais l’abonnement : demandez que la licence du module et ses conditions de réutilisation soient écrites noir sur blanc.
L’API externe, alternative au code interne
Quand le besoin est d’échanger des données avec un système tiers, l’API externe évite souvent de toucher au cœur d’Odoo. Sa documentation présente JSON-2 comme l’API courante, avec clés d’API, droits d’accès, choix de la base et transactions ; XML-RPC et JSON-RPC y sont traités comme historiques, avec un guide de migration vers JSON-2. Un développement d’intégration neuf doit donc s’appuyer sur JSON-2.
Attention : l’API externe fait partie des fonctions réservées à la formule Custom. C’est un critère à intégrer dès le chiffrage.
Quand le développement est-il justifié ?
Un développement spécifique se défend lorsque trois conditions sont réunies :
- le besoin porte sur un processus qui fait réellement la différence de votre activité ;
- ni le paramétrage, ni Studio, ni une extension existante ne le couvrent ;
- le gain attendu dépasse le coût de construction et de maintenance sur la durée.
À l’inverse, adapter Odoo pour reproduire à l’identique l’ancien logiciel est un réflexe coûteux. Mieux vaut revoir le processus que programmer l’habitude.
L’impact sur les mises à jour et les migrations
Chaque module sur mesure est un engagement. À chaque changement de version majeure, le code spécifique doit être revu, testé et souvent adapté. Plus le module modifie en profondeur le standard, plus la facture de montée de version grimpe. C’est la raison pour laquelle certaines entreprises restent bloquées sur une version ancienne : leurs développements rendent la migration trop lourde.
Les facteurs qui aggravent le risque :
- un module qui remplace des fonctions du standard au lieu de les étendre ;
- l’absence de documentation et de tests ;
- un code détenu par un seul développeur, sans accès partagé ;
- l’empilement de petits ajouts jamais nettoyés.
Avant de lancer un chantier de changement de version, un audit de l’existant permet de recenser les modules spécifiques, leur utilité réelle et leur état. Le sujet est détaillé dans la page migration Odoo et dans celle sur les versions et éditions.
Les bonnes pratiques à imposer
Rester au plus près du standard
Le standard est maintenu, testé et migré par l’éditeur. Tout ce que l’on y retire du périmètre spécifique, on le retire aussi de la facture future. Une bonne règle de gouvernance : chaque demande de spécifique est justifiée par écrit, chiffrée en construction et en maintenance, et validée par un décideur côté entreprise.
Documenter
Un module sans documentation dépend de la mémoire de son auteur. Exigez pour chaque développement :
- une spécification fonctionnelle validée avant de coder ;
- une description technique : modèles, champs, règles, dépendances ;
- un mode d’emploi à destination des utilisateurs.
Tester
Les tests évitent qu’une correction casse un autre processus. Attendez au minimum des scénarios de recette écrits, exécutés dans un environnement de test distinct de la production, avec vos propres données représentatives. Les développements à fort enjeu (facturation, stocks, paie) méritent des tests automatisés.
Maîtriser le code et l’hébergement
Odoo se déploie en Odoo Online (SaaS), Odoo.sh (formule Custom) ou sur site (formule Custom). Le mode d’hébergement conditionne ce qu’il est possible de déployer : un module spécifique n’a pas le même cadre sur chacun. Ce choix se prépare avec la page hébergement et cloud. Dans tous les cas, le code livré doit être dans un dépôt dont vous avez l’accès.
Prévoir le support
Un spécifique vit après la recette : corrections, évolutions, montée de version. Le contrat de support et maintenance doit nommer clairement qui répond de quoi, y compris pour les modules développés.
Comment évaluer un développeur ou un intégrateur Odoo
Un bon interlocuteur commence par vous dissuader de développer ce qui n’en vaut pas la peine. Voici une grille de questions utile en entretien.
| Question à poser | Réponse attendue |
|---|---|
| Qu’est-ce qui, dans mon besoin, relève du paramétrage ? | Une distinction claire entre paramétrage, Studio et code |
| Existe-t-il une extension ou un connecteur déjà disponible ? | Une recherche préalable, avec avis sur la fiabilité |
| Comment testez-vous avant la mise en production ? | Environnement de test, scénarios de recette, jeux de données |
| Qui détient le code et sous quelle licence ? | Dépôt accessible, licence compatible avec l’édition utilisée |
| Comment gérez-vous les montées de version ? | Méthode et responsabilités décrites, coût cadré |
| Quelle documentation livrez-vous ? | Spécifications, description technique, mode d’emploi |
Quelques signaux d’alerte :
- un chiffrage de développement sans spécification écrite ;
- un code que le prestataire refuse de transmettre ;
- une promesse de « tout adapter » à l’identique de l’ancien système ;
- aucune référence que vous puissiez contacter.
Pour choisir un prestataire sur des critères plus larges (organisation, secteurs, références, réactivité), lisez la page choisir un intégrateur Odoo et le guide général pour choisir un intégrateur ERP. Un cahier des charges soigné reste le meilleur garde-fou : voyez le guide sur le cahier des charges ERP.
Chiffrer le développement : ce qu’il faut savoir
Aucun budget sérieux ne se donne sans cahier des charges. Le coût dépend du périmètre fonctionnel, de la complexité des règles, du nombre d’intégrations et du niveau de test exigé. Demandez toujours une ventilation entre construction, recette, documentation et maintenance annuelle, et rapprochez-la du coût des licences, que vous trouverez dans la page sur les prix d’Odoo et dans le guide des prix des ERP.
Besoin d’un intégrateur Odoo pour cadrer vos développements ?
Intégrateurs ERP est un service gratuit de mise en relation : nous ne réalisons pas les projets et nous ne sommes affiliés à aucun éditeur. Vous décrivez votre besoin, et nous vous mettons en relation avec un intégrateur adapté à votre projet. Le fonctionnement est expliqué dans la page comment ça marche.
Questions fréquentes
Quelle est la différence entre paramétrer et développer dans Odoo ?
Paramétrer consiste à utiliser les options existantes : activer des fonctions, régler des règles, adapter des documents. Développer consiste à écrire du code pour ajouter un comportement que l’outil ne propose pas. Le paramétrage est plus rapide à mettre en place et ne gêne pas les montées de version ; le développement doit être justifié par un besoin métier précis.
Odoo Studio suffit-il pour personnaliser Odoo sans programmer ?
Studio permet de personnaliser sans code les champs, les vues, les modèles, les applications, les règles d’automatisation, les webhooks, les rapports PDF, les règles d’approbation et les règles de sécurité. Pour une logique métier complexe, un calcul spécifique ou une intégration poussée, un développement reste généralement nécessaire. Studio est inclus dans la formule Custom.
Un module sur mesure complique-t-il les mises à jour d’Odoo ?
Oui, chaque module spécifique doit être vérifié, voire adapté, à chaque changement de version majeure. Plus il modifie en profondeur le comportement du standard, plus ce coût de maintenance augmente. Un module qui s’appuie sur des mécanismes d’extension propres et qui est bien testé se migre beaucoup plus facilement.
Peut-on connecter Odoo à un autre logiciel sans développer un module ?
Souvent oui, grâce aux connecteurs existants ou à l’API externe. Celle-ci présente JSON-2 comme l’API courante, avec clés d’API et droits d’accès, et fait partie des fonctions de la formule Custom. Un développement n’est utile que si aucun connecteur ne couvre le flux attendu.
Comment vérifier le sérieux d’un développeur ou d’un intégrateur Odoo ?
Demandez-lui de distinguer ce qui relève du paramétrage de ce qui nécessite du code, de décrire sa méthode de test et de documentation, et d’expliquer comment il traite les montées de version. Exigez un cahier des charges validé, un code livré dans un dépôt dont vous avez l’accès, et des références que vous pouvez contacter.
Sources
- Odoo — documentation Studio (19.0)
- Odoo — licences (documentation 19.0)
- Odoo — documentation de l’API externe (19.0)
- Odoo — tarifs
- Odoo — à propos
Les noms de logiciels cités sont des marques de leurs éditeurs respectifs, mentionnées à titre d’information. Ce site est indépendant et n’est affilié à aucun éditeur.