Quand un projet Odoo démarre, le choix de l'hébergement bascule vite vers l'arbitrage budgétaire. On hésite entre Odoo Online d'un côté, et Odoo.sh ou on-premise de l'autre. On compare les tarifs, on regarde la souveraineté, on signe. Notre comparatif général sur les trois modes d'hébergement couvre déjà ces dimensions. Cet article ouvre un autre angle, celui qui rattrape la majorité des projets six mois après la mise en production : ce que vous pouvez personnaliser, et avec quels outils.
Sur Odoo Online, Studio est le seul levier
Sur Odoo Online (le SaaS natif), la personnalisation passe exclusivement par Odoo Studio. C'est un outil no-code intégré qui permet d'ajouter des champs, de modifier des vues, de générer des rapports, de définir des actions automatisées et de poser des règles de validation¹. Ces capacités couvrent une part réelle des besoins quotidiens d'une PME, notamment quand les processus métier sont proches de ce qu'Odoo propose en standard.
Les limites sont également réelles, et c'est là que les projets se cognent. Studio ne permet pas de modifier la logique métier en profondeur. Vous ne pouvez pas surcharger une méthode compute pour calculer une remise commerciale qui mélange ancienneté du client, volume cumulé sur trois mois et type de produit. Vous ne pouvez pas écrire un contrôleur HTTP pour exposer une API personnalisée vers un système externe. Vous ne pouvez pas installer un module tiers du dépôt OCA, ni un module développé sur mesure². Les actions automatisées Studio peuvent exécuter du code Python, mais dans un sandbox qui interdit les imports et certaines opérations de base, ce qui les cantonne à des manipulations simples sur les enregistrements.
Concrètement, sur Odoo Online, vous travaillez avec ce qu'Odoo a prévu, plus une couche de personnalisation visuelle. Si votre activité a un processus qui sort du cadre, vous le détectez généralement entre les ateliers de cadrage et la fin du paramétrage. Et là, soit vous adaptez votre processus à l'outil, soit vous changez de mode d'hébergement.
Sur l'hébergé, les modules custom débloquent tout
Sur Odoo.sh ou en on-premise, le code Python redevient accessible. Vous pouvez développer des modules sur mesure, surcharger n'importe quelle méthode, ajouter des champs calculés complexes, écrire des contrôleurs, construire des intégrations EDI ou OCR avec un service externe, ou installer un module communautaire OCA³. Odoo.sh ajoute par-dessus un workflow Git natif (branches de développement, staging, production), des environnements préconfigurés, des sauvegardes intégrées et un déploiement continu⁴. C'est l'environnement que nous utilisons chez Nexelans pour la plupart des projets PME qui ont des besoins métier sortant du cadre.
L'OCA, c'est un point qu'on sous-estime souvent côté décideurs. Le dépôt regroupe plusieurs centaines de modules communautaires maintenus, qui couvrent des cas que le standard Odoo ne traite pas ou traite mal⁵. Gestion documentaire avancée, intégrations bancaires françaises, modules de localisation pour des cas spécifiques, fonctionnalités complémentaires sur le commerce ou la production. La majorité de ces modules ne s'installe pas sur Odoo Online. Ils nécessitent un accès à l'environnement, donc Odoo.sh ou un hébergement sur vos propres serveurs.
Le piège : Studio reste utilisable sur l'hébergé
Voilà où ça devient intéressant. Sur Odoo.sh et en on-premise, Studio reste actif. Beaucoup de projets démarrent en mode hybride : un peu de Studio pour les ajustements rapides, un peu de code pour le dur. C'est tentant parce que ça donne aux référents fonctionnels la main sur la configuration, sans solliciter l'équipe technique pour chaque petite modification.
Le piège se referme à la première migration de version, ou à la première fois où une modification Studio en production casse un module custom. Le projet de PME standard finit avec quarante modifications Studio dont plus personne ne se souvient, des dépendances implicites entre Studio et le code, et un gestionnaire de versions Git qui ne voit qu'une moitié de la réalité. C'est le scénario classique d'une dette technique cachée qui ne se révèle que quand on doit migrer.
Pourquoi les intégrateurs préfèrent le code
Quatre arguments très pratiques expliquent ce choix, et ils valent la peine d'être posés clairement parce qu'ils décrivent ce qu'on ne voit pas avant d'avoir migré une instance.
Premièrement, Studio vit en base de données, pas dans Git. Une modification Studio est un enregistrement dans ir.model.fields, ir.actions.server ou des tables similaires. Elle n'apparaît pas dans le diff de votre dépôt. Si vous voulez retracer qui a modifié quoi sur un projet de deux ans, vous devez interroger la base, pas l'historique Git. Pour des audits ou des reprises de projet par un nouvel intégrateur, c'est un trou noir.
Deuxièmement, la promotion entre environnements ne fonctionne pas comme avec du code. Sur Odoo.sh, votre code passe automatiquement de la branche staging à la branche production via un merge Git. Vos modifications Studio, elles, restent dans la base où elles ont été faites. Pour les transposer, il faut soit copier la base entière (ce qui écrase tout ce qui a été fait en production depuis), soit refaire les modifications à la main, soit exporter et réimporter via les fichiers XML que Studio génère, ce qui marche mal en cas de conflits.
Troisièmement, les tests automatisés ne couvrent pas Studio. Si vous avez investi dans une suite de tests Python qui valide votre logique métier à chaque commit, ces tests ne savent rien des champs ajoutés par Studio ni des actions automatisées qu'il a créées. Vous pouvez avoir 100 % de couverture sur votre code et zéro garantie sur la moitié de votre logique fonctionnelle.
Quatrièmement, la migration de version devient sensiblement plus compliquée. Une modification en code custom suit un workflow connu : on adapte les modules à la nouvelle version, on lance les tests, on corrige les régressions. Les modifications Studio, elles, sont à reprendre une par une, parfois à recréer manuellement parce que les noms de champs ou les structures de vues ont bougé. Sur une instance avec beaucoup de Studio, une migration vers une version majeure peut prendre deux à trois fois plus de temps qu'attendu.
Quand Studio garde sa place même en hébergé
Tout ça ne veut pas dire que Studio est à bannir une fois qu'on est sur Odoo.sh ou en on-premise. Trois cas justifient son usage et nous les recommandons régulièrement à nos clients.
D'abord, les ajustements UI mineurs : renommer une étiquette, masquer un champ pour un profil utilisateur, réorganiser un formulaire. Ces modifications sont superficielles, elles ne touchent pas la logique métier, et leur revue par une équipe technique serait disproportionnée par rapport à l'enjeu.
Ensuite, l'extension côté client mérite d'être considérée. Quand un client veut pouvoir ajouter ses propres champs sur certains objets sans solliciter à chaque fois un développeur, on cadre le périmètre où Studio est autorisé (typiquement quelques objets non critiques) et on documente les règles. Ça donne de l'autonomie au client tout en gardant les zones sensibles sous contrôle Git.
Enfin, le prototypage rapide trouve sa place. Pour valider une idée fonctionnelle avec un référent métier en cinq minutes plutôt qu'en deux jours, Studio est imbattable. Une fois la mécanique validée, on retranscrit en code custom et on supprime la modification Studio. Le prototype reste dans Studio le temps de la validation, pas dans la production finale.
Comment décider en pratique
Trois questions suffisent à arbitrer entre Online et hébergé sur le critère de la personnalisation.
- Avez-vous identifié, lors du cadrage, au moins un besoin qui dépasse les capacités de Studio ?
- Avez-vous une équipe technique interne ou un partenaire d'intégration qui pourra versionner du code Python ?
- Anticipez-vous, dans les douze à dix-huit mois, des évolutions métier qui demanderont des développements spécifiques ?
Si vous répondez oui à au moins une, vous gagnerez du temps en partant directement sur Odoo.sh ou on-premise. Migrer d'Online vers Odoo.sh après douze mois de production reste possible mais coûteux : reprise des données, retest des flux, requalification des paramétrages, et perte des modifications Studio qui n'auront pas été conservées dans l'export. Si vous répondez non aux trois, Online Standard est probablement votre meilleur compromis prix/simplicité, à condition d'avoir bien validé que votre activité ne sortira pas du cadre standard.
Côté code Odoo cette semaine
Sur le repo public odoo/odoo, la branche master a connu un mouvement parlant cette semaine sur le périmètre e-commerce et variantes produits.
Revert d'un fix sur le carousel produit multi-variantes
Le 7 mai, le commit a annulé un correctif posé le 21 avril qui visait à corriger l'affichage du carousel produit dans website_sale quand un article avait beaucoup de variantes. Trois semaines après le merge initial, le fix est sorti de la branche, ce qui signifie qu'il introduisait soit une régression, soit un effet de bord détecté en pré-production. Le sujet n'est pas anodin pour les boutiques en ligne avec des catalogues à fort volume de déclinaisons (mode, pièces détachées, agroalimentaire avec sous-conditionnements).
Pour un projet où le carousel produit a été personnalisé via Studio sur Odoo Online, ce genre de mouvement est invisible côté client : la version SaaS reçoit la mise à jour automatiquement et l'incident est absorbé sans trace. Pour un projet en code custom sur Odoo.sh, le passage en CI sur la branche cible affiche le revert et permet de re-tester son override avant la promotion. C'est exactement la différence concrète qu'évoque la section précédente. Sur l'hébergé avec du code versionné, vous voyez ce qui change. Sur Online avec du Studio, vous le découvrez quand un utilisateur appelle.
Cohérence du website_id sur les domaines de produits
Le 6 mai, le commit 16d87b2 a corrigé une incohérence sur la résolution du website_id dans sale_product_domain. Pour les configurations multi-sites, où plusieurs sites web cohabitent sur la même instance Odoo, ce genre de correctif évite que les filtres de produits affichent des résultats issus du mauvais site. Ce n'est pas un changement spectaculaire, mais c'est typiquement le type de fix que les clients en multi-sites attendent depuis longtemps et qu'il vaut la peine de signaler.
Si vous êtes en cours d'arbitrage sur le mode d'hébergement de votre futur Odoo, ou si vous avez un projet sur Online qui commence à atteindre les limites de Studio, on en discute volontiers. Nous contacter
Sources
Odoo Documentation : Studio
« Studio is a tool to create and customize Odoo applications without the need to know how to code. »
Odoo Documentation : Odoo Online
« Odoo Online does not allow installation of custom modules or third-party apps outside the official App Store. »
Odoo Documentation : Odoo.sh
« Odoo.sh is a cloud platform that lets you develop, test and deploy Odoo customizations. »
Odoo Documentation : Odoo.sh Git Workflow
Documentation officielle du workflow Git natif d'Odoo.sh, avec branches de développement, staging et production.
Odoo Community Association (OCA) sur GitHub
Catalogue des modules communautaires maintenus par l'OCA, organisés par domaine fonctionnel, installables uniquement sur Odoo.sh ou on-premise.
Nexelans : Odoo Online, Odoo.sh ou on-premise : comment choisir en 2026
Article comparatif précédent qui couvre l'arbitrage général entre les trois modes d'hébergement Odoo : coûts, souveraineté des données, contraintes réglementaires.
GitHub : odoo/odoo, commit 4d9316f
Revert du 7 mai 2026 sur le module website_sale concernant l'affichage du carousel produit pour les articles à nombreuses variantes. Branche master.