Trois façons d'héberger Odoo
Avant de parler d'Odoo.sh, il faut savoir qu'Odoo se déploie de trois manières. Le choix conditionne votre budget, votre autonomie et surtout votre capacité a personnaliser l'outil.
| Mode | Pour qui | Code sur mesure | Qui gère l'infra |
|---|---|---|---|
| Odoo Online (SaaS) | Besoins standards, aucun développement | Non, Studio uniquement | Odoo |
| Odoo.sh (PaaS) | PME avec modules sur mesure | Oui, via Git | Odoo, avec accès technique |
| On-premise | Contrôle total, contraintes d'infra | Oui, sans limite | Vous |
Odoo Online est la solution la plus simple et la moins chere. Vous ne pouvez pas installer de module sur mesure, seulement personnaliser via Studio. L'on-premise vous donne un contrôle total mais vous rend responsable des sauvegardes, des mises a jour, de la sécurité et du serveur. Odoo.sh se situe entre les deux : vous gardez la liberté d'installer des modules sur mesure, mais Odoo gère l'infrastructure a votre place.
Points cles
- Odoo.sh est la plateforme d'hébergement officielle d'Odoo, réservée aux abonnements Enterprise
- Elle repose sur Git : chaque branche est un environnement (production, staging, development)
- Les sauvegardes, le SSL, les serveurs mail et le monitoring sont inclus et gérés par Odoo
- Si vous n'avez aucun code sur mesure, Odoo Online est plus simple et moins cher qu'Odoo.sh
Qu'est-ce qu'Odoo.sh, concrètement
Odoo.sh est une plateforme d'hébergement gérée (un PaaS, Platform as a Service) construite autour de votre code. Elle se connecte a un depot Git (GitHub ou GitLab) qui contient vos modules sur mesure. Un projet Odoo.sh correspond a une base de production unique.
L'idée centrale est simple : votre configuration technique vit dans Git, pas seulement dans la base de données. Chaque fois que vous poussez du code, Odoo.sh reconstruit un environnement, installe les modules et lance les tests. Vous obtenez un historique complet des changements et la possibilité de revenir en arrière.
Odoo.sh nécessité un abonnement Enterprise. La version Community ne s'y héberge pas. Si vous hésitez encore entre les deux éditions, ce point peut orienter votre décision : choisir Odoo.sh, c'est choisir Enterprise.
Le cycle Git : production, staging, development
C'est le coeur d'Odoo.sh et ce qui le distingue d'un simple hébergement. Chaque branche de votre depot est un environnement isole, avec son propre role.
| Type de branche | Données | Usage |
|---|---|---|
| Production | Vos données réelles | La base en ligne, une seule |
| Staging | Copie neutralisée de la production | Recette et tests avant mise en prod |
| Development | Données de démonstration | Développement et tests unitaires |
Le principe de travail est le suivant. Vous développez ou testez une modification sur une branche development, qui part de données de démonstration. Quand c'est pret, vous fusionnez vers une branche staging : Odoo.sh y créé automatiquement une copie de votre production, mais neutralisée (les envois d'e-mails, les paiements et les taches planifiees sont desactives pour ne rien declencher par erreur). Vos utilisateurs clés valident dans ces conditions proches du réel. Une fois la recette faite, vous fusionnez vers production et la modification part en ligne.
A chaque push, Odoo.sh lance un build, installe les modules et exécute les tests. Si un test echoue, vous le voyez avant la mise en production. Un editeur web et un accès SSH permettent d'inspecter les logs et de corriger. Ce circuit evite la faute classique : modifier directement la base en ligne et découvrir le bug une fois que tout le monde travaille dessus.
Ce qui est inclus dans la plateforme
Odoo.sh prend en charge la partie infrastructure que vous devriez sinon gérer vous-même sur un serveur dédié.
Les sauvegardes de la production sont automatiques, toutes les 24 heures. Odoo.sh conserve 14 sauvegardes complètes réparties sur trois mois environ (une par jour sur sept jours, une par semaine sur quatre semaines, une par mois sur trois mois). Vous pouvez les télécharger. Attention : les branches staging et development ne sont pas sauvegardees, elles ne sont pas faites pour stocker des données durables.
Sont egalement inclus le certificat SSL (renouvele automatiquement), les serveurs mail entrant et sortant, la gestion du DNS, le monitoring, l'accès aux logs et un shell. Vous pouvez choisir la region d'hébergement, ce qui compte pour le RGPD : une PME française peut demander un hébergement en Europe pour garder ses données dans l'Union.
Dimensionner et budgeter
Le budget Odoo.sh se lit en deux couches. D'abord l'abonnement Enterprise (par utilisateur et par application), puis les ressources de la plateforme elle-même. Odoo fait varier son tarif changer regulierement, donc raisonnez en logique plutôt qu'en montant fige.
Trois leviers déterminent le coût de la plateforme :
- Les workers. Un worker est une unité de traitement qui sert les requetes. Plus vous avez d'utilisateurs simultanes et de traitements lourds, plus il en faut. Les branches staging et development sont limitees a un seul worker restreint, ce qui est normal : elles servent aux tests, pas a la charge réelle.
- Le stockage. Facture au gigaoctet supplementaire au-dela de ce qui est inclus.
- Les branches staging. Chaque environnement de staging permanent a un coût. Une PME en a rarement besoin de plus d'un ou deux.
Le bon reflexe est de demarrer petit. Un projet type commence avec un worker de production et une branche staging, puis on ajoute des workers quand la charge le justifie. Odoo.sh permet cet ajustement sans reinstallation.
Déployer proprement : les étapes
Voici l'ordre que nous suivons pour un déploiement Odoo.sh sain, du depot vide a la mise en production.
- Créez le depot Git et le projet Odoo.sh. Reliez GitHub ou GitLab, choisissez la version d'Odoo et la region d'hébergement.
- Structurez le code. Placez vos modules sur mesure dans le depot. Les modules tiers passent par des sous-modules Git, ce qui garde leur origine traçable et leur mise a jour maitrisee.
- Configurez une branche development. Elle sert a construire et valider les modules sur données de démonstration, sans risque.
- Créez une branche staging. Testez sur une copie neutralisée de vos données réelles, avec vos utilisateurs clés.
- Chargez les données initiales. Importez le plan comptable, les clients, les fournisseurs, les articles et les stocks, puis vérifiez leur cohérence avant la bascule.
- Basculez en production. Fusionnez vers la branche production, contrôlez le build et surveillez les logs les premiers jours.
- Documentez le circuit. Notez qui a le droit de fusionner vers production. C'est cette discipline, plus que l'outil, qui protège votre base en ligne.
Mettre a jour Odoo sans casser la production
Odoo publie une version majeure par an. La montée de version est le moment le plus sensible de la vie d'une instance, et Odoo.sh la rend testable au lieu de risquee.
Le principe : vous ne mettez jamais a jour la production directement. Vous testez d'abord sur une branche staging. Odoo fournit une plateforme de migration (upgrade.odoo.com) qui convertit la base vers la nouvelle version. Le code standard est migre automatiquement. Vos modules sur mesure, eux, doivent être adaptes a chaque version majeure : c'est le vrai coût d'une montée de version, et il augmente avec le volume de personnalisation. Une fois la version testee et validee en staging, vous planifiez la bascule de production a une date calme.
C'est aussi une raison de limiter le sur-mesure : chaque module spécifique est une ligne a reprendre a chaque montée de version.
Quand Odoo.sh n'est pas le bon choix
Odoo.sh est excellent, mais ce n'est pas la réponse par défaut. Trois cas ou il vaut mieux passer votre chemin.
Si vous n'avez aucun module sur mesure et des besoins standards, Odoo Online est plus simple et moins cher. La souplesse Git d'Odoo.sh ne vous servirait a rien. Payer un PaaS pour ne jamais pousser une ligne de code n'a pas de sens.
Si vous avez une contrainte forte d'hébergement sur vos propres serveurs, une politique de sécurité interne stricte ou un besoin d'infrastructure très spécifique, l'on-premise reste le seul mode qui vous donne ce contrôle. Vous assumez alors sauvegardes, sécurité et mises a jour.
Si vous n'avez ni ressource technique interne ni intégrateur, Odoo.sh sera sous-exploite. Le circuit Git suppose quelqu'un qui comprenne les branches et les builds. Sans cela, l'outil devient une contrainte plutôt qu'un atout.
Et rappelons l'evidence : si votre besoin n'est pas un ERP intégré mais un simple logiciel de facturation ou de compta, Odoo tout court peut être surdimensionne. Le bon hébergement ne rattrape jamais un mauvais choix d'outil.
Notre recommandation
Pour une PME qui a des modules sur mesure et veut un déploiement fiable sans gérer de serveur, Odoo.sh est le meilleur compromis. Le circuit production, staging et development transforme les mises en production et les montées de version en operations testees plutôt qu'en paris.
Chez Roekish, nous mettons en place ce circuit des le début du projet, avec une règle simple : rien ne part en production sans passer par staging. Cette discipline, associee a une personnalisation raisonnee, est ce qui garde une instance Odoo stable dans la durée. Si vous hésitez entre Odoo Online, Odoo.sh et l'on-premise, notre diagnostic vous aide a trancher selon votre volume de sur-mesure et vos contraintes d'hébergement.