Sommaire
Le choix de l'hébergement Odoo arrive vite dans un projet, parfois même avant les premiers paramétrages, et il vous engage pour plusieurs années. Entre Odoo Online, Odoo.sh et l'auto-hébergement sur vos propres serveurs, chaque option ferme certaines portes et en ouvre d'autres. Une mauvaise décision se paie six mois plus tard, en migration douloureuse, en modules custom impossibles à installer ou en facture serveur qui double sans prévenir. Chez Drakkar, on guide des PME sur ce choix toutes les semaines, et le critère qui tranche tient en une question : quelle dose de personnalisation votre projet va-t-il exiger ?
Les trois options d'hébergement Odoo
Odoo SA propose officiellement trois modes d'hébergement, auxquels s'ajoute le cas particulier de la version Community auto-hébergée. Chacun correspond à un curseur différent entre simplicité de gestion d'un côté et liberté de personnalisation de l'autre.
Tant que vous restez dans le standard Odoo, l'option Online suffit. Dès qu'un module spécifique entre en jeu, Odoo.sh prend le relais, et l'on-premise reste réservé aux organisations qui ont une vraie raison de tout gérer en interne.
Odoo Online (SaaS)
Fonctionnement et périmètre
Odoo Online, c'est la version la plus simple : vous accédez à votre instance via un navigateur, et Odoo SA s'occupe du reste (serveur, sauvegardes, mises à jour). Rien à installer, rien à provisionner, vous payez vos licences utilisateurs et vous travaillez. Cette option n'existe qu'en édition Enterprise.
Modules et personnalisations disponibles
La contrepartie de cette simplicité, c'est une fermeture quasi totale du périmètre : aucun module tiers, aucun module développé par votre intégrateur, et aucun accès au code source. Vous disposez des modules officiels Odoo et d'Odoo Studio pour ajouter quelques champs ou retoucher des vues, et rien de plus.
Sur ce point, il faut être précis sur ce que Studio permet réellement. François, l'un de nos consultants Odoo, illustre bien la limite : imaginons un client dont l'équipe commerciale travaille avec une liste fermée de métiers - maçon, électricien, plombier - qu'il veut associer à chaque contact. Le champ "fonction" natif d'Odoo est un champ texte libre, pas une liste déroulante contrôlée. Avec Studio, vous pouvez créer ce nouveau champ en quelques clics, sans toucher au code. C'est utile, c'est rapide. Mais si ce même client veut ensuite que ce champ pilote une logique de routage des devis ou déclenche une automatisation métier complexe, Studio atteint ses limites - il faut alors passer sur un module développé, et donc sur Odoo.sh. Chez Drakkar, on utilise volontiers Studio en phase de conception, pour maquetter rapidement des interfaces et valider des besoins avec le client - mais pas pour partir en production sur des fonctionnalités critiques.
Si demain vous voulez intégrer un connecteur métier spécifique ou un module communautaire OCA, ce sera impossible sans changer de mode d'hébergement.
Tarifs et limites techniques
Le tarif suit la grille standard Odoo Enterprise (par utilisateur, mensuel ou annuel), sans frais d'infrastructure additionnels. Les sauvegardes sont quotidiennes et répliquées sur trois continents. Si 99 % de vos besoins sont couverts par les fonctionnalités natives d'Odoo, foncez. Au moindre doute sur un développement spécifique à venir, regardez plutôt Odoo.sh.
Odoo.sh (PaaS)
Architecture et fonctionnalités
Odoo.sh est une plateforme cloud managée par Odoo SA qui vous donne accès à un environnement complet : votre dépôt Git, des environnements de staging séparés, un déploiement automatisé à chaque push, et un monitoring intégré. Concrètement, vous gardez la souplesse de l'on-premise (vos modules custom, vos modules OCA, vos forks) sans avoir à gérer le serveur.
Sur la gestion des sauvegardes, Odoo.sh applique une logique automatisée qui va plus loin qu'un simple backup nocturne. Les sauvegardes tournent chaque jour à partir de 19h, avec une gestion automatique de l'espace : les versions les plus anciennes sont purgées selon des règles prédéfinies, de sorte que vous n'avez pas à surveiller un quota de stockage ou à nettoyer manuellement des archives. Sur un on-premise, c'est à vous de gérer ce cycle - acheter de l'espace supplémentaire quand les backups saturent, décider quelles versions garder, tester régulièrement que la restauration fonctionne vraiment. Ce travail de fond, invisible quand tout va bien, devient critique le jour où vous en avez besoin.
Côté environnements de test, Odoo.sh inclut par défaut une base de staging gratuite pour chaque projet. C'est l'environnement dans lequel vous validez vos développements avant de les pousser en production - essentiel pour éviter de casser une instance live. Si votre projet nécessite plusieurs bases de staging en parallèle (par exemple pour tester une migration pendant que l'équipe continue de développer en feature branch), les bases supplémentaires sont payantes et doivent être anticipées dans le budget.
Tarification et coûts variables
Comptez environ 30 à 37 euros par utilisateur et par mois, plus 60 euros par mois pour l'infrastructure de base. À cela s'ajoutent les coûts variables liés aux ressources : nombre de workers (la puissance de calcul allouée), volume de stockage, bases de staging supplémentaires.
C'est là que les budgets dérapent le plus souvent. Les workers sont la variable la moins visible au départ : quand l'instance ralentit, le réflexe est d'en ajouter, ce qui augmente la facture. Sur un on-premise ou un cloud privé, vous avez la main directe sur le serveur - vous achetez un processeur plus puissant, vous ajoutez de la RAM, vous contrôlez exactement ce que vous payez et ce que vous obtenez. Sur Odoo.sh, vous vous adaptez aux paliers proposés par Odoo : vous montez d'un niveau ou vous n'y êtes pas, il n'y a pas de réglage fin. Ce n'est pas un défaut en soi, mais c'est un paramètre à intégrer dans votre projection de coûts à 2 ou 3 ans. Sans monitoring régulier, la facture peut doubler en un an quand la base de données grossit.
Cas d'usage adaptés
Odoo.sh est notre recommandation par défaut pour la grande majorité des PME que nous accompagnons : dès qu'un module spécifique, un connecteur métier ou un module OCA entre dans le périmètre, c'est l'option qui s'impose. C'est aussi le bon choix pour garder une discipline DevOps propre (staging, validation avant production, rollback) sans monter une équipe d'infrastructure dédiée.
On-Premise et cloud privé
Hébergement sur vos serveurs
L'on-premise au sens strict signifie installer Odoo sur vos propres machines, dans vos locaux ou sur un serveur loué. Vous récupérez le code source (Community gratuite ou Enterprise sous licence), vous gérez tout : système d'exploitation, base PostgreSQL, reverse proxy, SSL, sauvegardes, monitoring, mises à jour de sécurité. La contrepartie de cette liberté, c'est que la moindre défaillance vous revient en pleine figure.
Hébergement chez un cloud provider tiers
Une variante consiste à héberger votre Odoo chez un cloud provider européen comme OVH, Scaleway ou Hetzner. C'est techniquement la même logique que l'on-premise (vous gérez tout), mais vous gagnez la résilience de l'infrastructure du provider. Cette option est souvent retenue pour des raisons de souveraineté des données ou de conformité RGPD, quand héberger hors UE pose problème.
Compétences et ressources nécessaires
Pour une PME sans DSI ni administrateur système expérimenté, l'on-premise est fortement déconseillé. La question n'est pas seulement technique : elle est aussi contractuelle et sécuritaire. Comme le rappelle François : si l'accès au serveur n'est pas correctement cloisonné, quelqu'un peut entrer, accéder à la base de données et en faire ce qu'il veut. Au niveau applicatif, Odoo intègre des mécanismes de sécurité solides - les mots de passe ne sont jamais stockés en clair en base. Mais au niveau serveur, si l'infrastructure n'est pas sécurisée, c'est toute la donnée qui est exposée, quelle que soit la qualité du logiciel qui tourne dessus. L'intégrateur qui prend en charge un on-premise pour un client assume de facto la responsabilité de cette sécurité - avec les engagements contractuels (NDA, SLA, responsabilité des dirigeants) que cela implique.
Chez Drakkar, on a fait le choix assumé de ne pas proposer l'hébergement on-premise : on préfère vous orienter vers Odoo.sh plutôt que de prendre la responsabilité d'une infra qu'on ne maîtriserait qu'à moitié. L'on-premise reste pertinent pour les ETI multi-sites, les industriels avec des intégrations machine lourdes ou les secteurs réglementés qui ont déjà une équipe IT solide en place.
Comment choisir entre les trois options
En pratique, le sujet rejoint celui du choix d'édition : si vous hésitez encore entre les deux versions, notre article odoo community vs enterprise reprend la décision sous l'angle fonctionnel et budgétaire. Les deux choix sont liés, puisque Odoo Online et Odoo.sh imposent l'édition Enterprise.
Les erreurs les plus fréquentes sur le choix d'hébergement
Notre recommandation
Pour la grande majorité des PME que nous accompagnons, Odoo.sh reste le meilleur compromis : un environnement managé qui vous laisse pousser vos modules custom, avec un staging propre et un budget qui reste prévisible tant que vous gardez un œil sur vos workers. Odoo Online conserve son intérêt pour les structures plus petites dont les besoins tiennent dans le standard, et l'on-premise se justifie quand vous avez déjà une vraie équipe IT et une raison réglementaire ou stratégique d'héberger en interne. Si vous hésitez sur votre cas, on peut auditer votre projet en 30 minutes et vous dire franchement quelle option a du sens, sans vous vendre la nôtre par défaut.
FAQ
