Avant de configurer la moindre application, vous devez décider où sera hébergée votre base de données Odoo 19 Enterprise. Le choix de l'hébergement détermine ce que vous pouvez personnaliser, qui contrôle le serveur, la fréquence des mises à niveau obligatoires et qui est responsable des sauvegardes.
Odoo propose trois modes d'hébergement : Odoo Online, Odoo.sh et l'hébergement sur site (auto-hébergé). Tous trois exécutent les mêmes applications Enterprise standard, mais ils divergent nettement dès que vous avez besoin de code personnalisé, d'un accès au serveur ou d'un rythme de mise à niveau particulier.
Une remarque sur les sources : ce guide s'appuie sur la documentation officielle d'Odoo pour la version 19.0. Les règles et politiques d'hébergement peuvent évoluer ; vérifiez donc chaque point important pour votre projet dans une base de test et au regard de vos propres conditions d'abonnement avant de vous engager.
Les trois options en une minute
- Odoo Online : le logiciel en tant que service d'Odoo. Odoo gère les serveurs et la plateforme, et vous travaillez dans les applications standard et Studio.
- Odoo.sh : la plateforme cloud officielle d'Odoo pour héberger et gérer Odoo avec votre propre code, reliée à un dépôt GitHub et organisée en branches de développement, de préproduction et de production.
- Sur site : vous installez et exploitez Odoo sur votre propre serveur, ou sur un serveur cloud que vous louez, et vous enregistrez la base de données avec votre code d'abonnement Enterprise.
La personnalisation : le critère décisif pour la plupart des projets
La documentation d'Odoo indique clairement qu'Odoo Online est incompatible avec les modules personnalisés et avec les modules de l'Odoo Apps Store. Sur Online, vous configurez les applications standard et pouvez créer des personnalisations avec Studio, mais vous ne pouvez pas installer vos propres modules Python.
Odoo.sh est conçu pour le code personnalisé. Vous poussez vos modules sur une branche de votre dépôt GitHub et la plateforme détecte automatiquement les dossiers contenant des modules Odoo. Des modules communautaires publics peuvent également être ajoutés, par exemple sous forme de sous-modules Git.
L'hébergement sur site offre la même liberté qu'Odoo.sh pour les modules personnalisés, puisque vous contrôlez le serveur et les modules qu'il charge. La différence est que rien de ce qui entoure le code n'est géré pour vous.
Règle pratique : si vos besoins comprennent le moindre développement Python personnalisé ou la moindre application tierce de l'Apps Store, Odoo Online est exclu et le vrai choix se joue entre Odoo.sh et l'hébergement sur site.
Contrôle et accès
Sur Odoo Online, vous gérez la base de données via le gestionnaire de bases de données d'Odoo. Vous pouvez y dupliquer la base pour des tests, la renommer, télécharger une sauvegarde, lancer une mise à niveau lorsqu'elle est disponible, gérer les noms de domaine et transférer la propriété. Il n'existe aucun accès au serveur ni au shell.
Sur Odoo.sh, chaque branche dispose d'outils de développement dans le navigateur : un shell web pour les commandes Linux de base et psql, un éditeur en ligne avec des consoles Python et Odoo shell, un accès SSH avec votre propre clé, et un intercepteur de courriels qui capte les e-mails des builds hors production.
L'hébergement sur site donne un contrôle total sur le système d'exploitation, PostgreSQL, le proxy inverse et le fichier de configuration d'Odoo. Le guide de déploiement d'Odoo considère la sécurité comme un processus continu et énumère des tâches telles que servir Odoo en HTTPS derrière un proxy inverse, définir un filtre de bases de données sur les serveurs multi-bases, utiliser un utilisateur PostgreSQL qui n'est pas superutilisateur et désactiver le gestionnaire de bases de données sur les systèmes exposés à Internet.
Obligations de mise à niveau
Chaque type d'hébergement s'accompagne d'une règle de mise à niveau différente. Ce point est souvent négligé lors du choix et devient urgent par la suite ; mettez-le donc sur la table dès le premier jour.
- Odoo Online : selon la documentation d'Odoo sur les mises à niveau, une base de données sur une version majeure doit être mise à niveau tous les deux ans, et une base sur une version mineure doit l'être quelques semaines après la sortie de la version suivante. Si aucune action n'est entreprise avant l'échéance, Odoo met automatiquement la base à niveau.
- Odoo.sh : après les trois premières années de support d'une version, vous disposez de deux années supplémentaires pour effectuer la mise à niveau, et vous êtes averti lorsqu'une mise à niveau est requise.
- Sur site : vous pouvez rester indéfiniment sur la même version. Odoo ne le recommande pas, et des écarts de version plus faibles facilitent les mises à niveau.
Les modules personnalisés concernent toutes les options sauf Online. Odoo précise qu'une base de données comportant des modules personnalisés ne peut pas être mise à niveau tant que ces modules ne sont pas disponibles pour la version cible, et que leur mise en compatibilité relève de la responsabilité du mainteneur du module.
Avec Odoo Enterprise, le service de mise à niveau couvre les applications standard, les personnalisations Studio tant que Studio reste installé et que l'abonnement est actif, ainsi que les développements couverts par un abonnement de maintenance des personnalisations. Les modules internes ou tiers sans contrat de ce type, le nettoyage des données existantes et la formation ne sont pas couverts.
Le processus recommandé est le même sur toutes les plateformes : demander une base de test mise à niveau, mettre à jour les modules personnalisés, tester minutieusement, signaler les problèmes à Odoo, puis planifier la mise à niveau de production, pendant laquelle la base de données est indisponible.
Sauvegardes et copies de test
Odoo Online : la documentation indique que des sauvegardes sont effectuées quotidiennement dans le cadre du SLA Odoo Cloud Hosting. Vous pouvez aussi télécharger une sauvegarde ZIP depuis le gestionnaire de bases de données ; si la base est trop volumineuse, le support Odoo propose une autre méthode.
Odoo.sh : la base de production est sauvegardée automatiquement chaque jour, et chaque sauvegarde comprend le dump de la base, le filestore, les journaux et les sessions. La documentation mentionne sept sauvegardes quotidiennes, quatre hebdomadaires et trois mensuelles, des serveurs de sauvegarde dédiés conservant des copies mensuelles supplémentaires. Vous pouvez également réaliser des sauvegardes manuelles des builds de production et de préproduction.
Les builds de préproduction et de développement sur Odoo.sh ne sont pas sauvegardés automatiquement. Les bases de préproduction sont des copies neutralisées de la production qui sont supprimées au bout d'un certain temps, et les bases de développement sont éphémères et construites à partir de données de démonstration ; ne conservez donc jamais de travail réel uniquement à ces endroits.
Sur site : les sauvegardes sont entièrement à votre charge. Planifiez la sauvegarde de la base PostgreSQL et du filestore, conservez des copies hors du serveur et testez régulièrement les restaurations.
Quelle que soit l'option choisie, les bases de test de mise à niveau et les bases de préproduction Odoo.sh sont neutralisées : les actions planifiées sont désactivées, les e-mails sortants sont interceptés ou remplacés, et les connecteurs de paiement et d'expédition passent en mode test. Cela protège la production, mais les intégrations doivent être réactivées délibérément si vous souhaitez les tester.
Facteurs de coût à comparer sans grille tarifaire
Les prix dépendent de votre contrat et évoluent dans le temps ; comparez donc ce qui détermine le coût plutôt que les montants affichés.
- Périmètre de l'abonnement : Odoo.sh exige un code d'abonnement Enterprise incluant l'hébergement Odoo.sh, tandis que l'hébergement sur site utilise un abonnement Enterprise enregistré sur votre propre serveur, avec une base de données liée par abonnement.
- Utilisateurs : une base de données sur site doit respecter le nombre d'utilisateurs prévu par son abonnement ; en cas de dépassement, un avertissement s'affiche et un délai limité est accordé pour corriger le nombre avant l'expiration de la base.
- Infrastructure : sur Odoo.sh, vous dimensionnez les workers, le stockage et les builds de préproduction au sein de la plateforme ; sur site, vous payez vous-même les serveurs, le stockage, la bande passante et la supervision, et le serveur doit conserver un accès réseau au service de validation d'Odoo.
- Ressources humaines : l'hébergement sur site nécessite une personne capable d'administrer Linux, PostgreSQL, HTTPS et les mises à jour de sécurité ; Odoo.sh nécessite des développeurs à l'aise avec Git ; Odoo Online ne requiert ni l'un ni l'autre.
- Cycle de vie des personnalisations : chaque module personnalisé doit être maintenu et porté à chaque mise à niveau, ce qui représente un coût récurrent sur Odoo.sh et sur site, sauf s'il est couvert par un abonnement de maintenance.
À qui convient chaque option
Odoo Online convient aux entreprises qui peuvent fonctionner avec Odoo standard et Studio, souhaitent démarrer au plus vite et s'accommodent du calendrier de mises à niveau d'Odoo. Les entreprises de négoce, de services et de commerce de détail aux processus standard en sont des candidates typiques.
Odoo.sh convient aux projets qui nécessitent des modules personnalisés ou des applications tierces sans vouloir gérer de serveurs, et qui tiennent à tester chaque modification sur une copie de préproduction avant sa mise en production.
L'hébergement sur site convient aux organisations disposant d'une équipe informatique interne, d'exigences strictes en matière de localisation des données ou de réseau, d'intégrations avec du matériel local, ou du besoin de décider précisément du moment des mises à niveau.
Si vous envisagez Odoo Community, notez qu'Odoo.sh exige un code d'abonnement Enterprise et que le service de mise à niveau gratuit décrit ci-dessus est un avantage Enterprise ; Community est donc normalement auto-hébergé et mis à niveau par vos propres moyens.
Enterprise n'est pas une base de code distincte : la documentation d'installation d'Odoo décrit le dépôt Enterprise comme un ensemble de modules supplémentaires venant s'ajouter à Community ; une installation Enterprise auto-hébergée nécessite donc les deux. Passer ultérieurement de Community à Enterprise constitue un projet à part entière, car la documentation d'Odoo sur les mises à niveau ne traite pas le changement d'édition comme faisant partie d'une mise à niveau.
Changer de type d'hébergement par la suite
Le choix n'est pas définitif, mais la migration est plus simple dans certains sens que dans d'autres.
- D'Odoo Online vers Odoo.sh ou sur site : téléchargez une sauvegarde depuis le gestionnaire de bases de données, puis importez-la ou restaurez-la. Les versions intermédiaires d'Online ne sont pas prises en charge ailleurs ; vous devrez donc peut-être d'abord passer à la version majeure suivante.
- D'Odoo.sh ou sur site vers Odoo Online : toutes les applications non standard doivent d'abord être désinstallées, dans un build de préproduction ou une base dupliquée, et la migration elle-même se demande via un ticket au support Odoo.
- De l'hébergement sur site vers Odoo.sh : utilisez l'import de l'onglet Sauvegardes de la branche de production. L'import nécessite un espace de stockage libre équivalent à quatre fois la taille du dump, écrase les données actuelles de la branche et désactive les serveurs de courrier sortant et les actions planifiées jusqu'à ce que vous réactiviez ceux dont vous avez besoin.
Une liste de contrôle pour décider
- Avons-nous besoin, maintenant ou dans un avenir prévisible, d'un module Python personnalisé ou d'un module de l'Apps Store ? Si oui, excluez Odoo Online.
- Pouvons-nous accepter le calendrier de mises à niveau obligatoires d'Odoo Online, ou avons-nous besoin de mieux maîtriser le moment de chaque changement de version ?
- Avons-nous besoin d'une copie de préproduction pour tester chaque modification avant la mise en production ?
- Disposons-nous, ou pouvons-nous recruter, des personnes capables de gérer Linux, PostgreSQL, HTTPS, la supervision et la sécurité d'un serveur sur site ?
- Existe-t-il des contraintes de localisation des données, de réseau ou de matériel qui imposent notre propre serveur ?
- Qui est responsable de la vérification des sauvegardes et des tests de restauration, et à quelle fréquence seront-ils réalisés ?
- Qui maintient et porte nos modules personnalisés à chaque mise à niveau, et cela est-il couvert par un abonnement de maintenance ?
Comment 1CBMS peut vous aider
1CBMS aide les entreprises en Égypte et en Irak à choisir le bon hébergement Odoo avant le début de la mise en œuvre. Nous confrontons vos besoins à ce que chaque plateforme permet, signalons tôt tout besoin de modules personnalisés, mettons en place des projets Odoo.sh ou des serveurs sur site selon de bonnes pratiques de sauvegarde et de sécurité, et planifions les mises à niveau afin que votre système Odoo 19 Enterprise reste supporté. Contactez-nous via www.1cbms.com pour étudier votre cas.