Hébergement Odoo souverain : quel mode choisir ?

L'essentiel.

• Trois modes d'hébergement Odoo coexistent : Odoo Online et Odoo.sh, tous deux exploités par Odoo SA, et l'hébergement géré par un partenaire, comme DynCloud chez Dynapps.

• Odoo Online n'accepte aucun module tiers et limite la personnalisation à Studio et aux actions serveur. Odoo.sh accepte le code, mais éteint les workers au repos, production comprise.

• Sur Odoo Online et Odoo.sh, l'infrastructure physique est Google Cloud, pilotée par Odoo SA. Sur DynCloud, les données sont traitées et stockées en Belgique, dans les centres de données de Combell, à l'intérieur des frontières européennes.

• DynCloud repose sur un cluster Kubernetes géré, avec un objectif de point de reprise (RPO) de 4 heures et des sauvegardes toutes les 4 heures, plus une sauvegarde quotidienne conservée 30 jours.

• Le choix se joue sur trois questions : qui répond quand l'infrastructure tombe, ce que vous avez le droit d'installer, et où vivent vos données.

Si la souveraineté de vos données fait partie de vos critères, un seul des trois modes nomme le pays, l'exploitant et l'engagement contractuel : l'hébergement géré par votre partenaire d'intégration. Les deux plateformes d'Odoo SA fonctionnent sur Google Cloud, et leur infrastructure est gérée par Odoo SA, pas par votre intégrateur. Cet article compare les trois modes sur ce qu'ils permettent réellement, et sur ce qu'ils vous refusent.

Qu'entend-on par hébergement Odoo souverain ?

Un hébergement Odoo souverain est un hébergement dont vous connaissez l'emplacement physique, l'exploitant et les engagements contractuels.

Pour DynCloud, ces trois éléments sont nommés. Les centres de données sont ceux de Combell, en Belgique, à Diegem et Zaventem. Les données y sont traitées et stockées à l'intérieur des frontières européennes. Combell respecte le RGPD, et le traitement des données clients et utilisateurs suit les instructions du client, encadrées par un accord de sous-traitance (DPA). Dynapps et Combell sont tous deux certifiés ISO 27001.

Pour Odoo Online et Odoo.sh, l'infrastructure physique est Google Cloud. Odoo SA est également certifié ISO 27001, avec l'hébergement SaaS et la plateforme Odoo.sh dans le périmètre, et Odoo.sh ajoute une certification SOC 2. Sur Odoo Online, les sauvegardes sont répliquées sur trois centres de données en Europe et au Canada, avec une copie en stockage froid. L'architecture est solide. Ce n'est pas la même promesse : la gestion de l'infrastructure appartient à Odoo SA, et le périmètre géographique des sauvegardes dépasse l'Europe.

Précision utile pour un lecteur français : DynCloud est hébergé en Belgique, pas en France. La promesse porte sur l'Europe et sur un exploitant nommé, pas sur le territoire national.

Quelles sont les limites réelles de chaque mode ?

Les limites ne tiennent pas à Odoo, mais à ce que chaque plateforme autorise autour d'Odoo : le code, les accès réseau, les ressources et l'emplacement des données.

Huit critères séparent les trois modes.

Qui gère l'infrastructure.

• Odoo Online : Odoo SA.

• Odoo.sh : Odoo SA.

• DynCloud : Dynapps, sur l'infrastructure de Combell.

Modules tiers, code spécifique et intégrations.

• Odoo Online : aucun module tiers, personnalisation limitée à Studio et aux actions serveur, pas d'intégration logicielle.

• Odoo.sh : modules marketplace et développements spécifiques autorisés, personnalisation complète, mais paquets système impossibles.

• DynCloud : personnalisation complète, modules tiers et paquets système installables via Dynapps.

Disponibilité des workers.

• Odoo Online : gérée par Odoo SA.

• Odoo.sh : workers éteints au repos, production comprise, avec un démarrage à froid à la première requête après inactivité.

• DynCloud : tous les workers maintenus actifs en permanence, avec des redémarrages périodiques.

Haute disponibilité et tolérance de panne.

• Odoo Online : bascule automatique en cas de panne matérielle, perte de données quasi nulle, mais pas de PostgreSQL en haute disponibilité.

• Odoo.sh : tolérance de panne au niveau des workers, pas de PostgreSQL en haute disponibilité non plus.

• DynCloud : tolérance de panne automatique, répartition de charge, réplication de base disponible sur demande.

Mises à jour mineures d'Odoo.

• Odoo Online : automatiques, poussées par Odoo SA.

• Odoo.sh : poussées chaque semaine par Odoo SA, avec un gel de 3 mois maximum et une intervention manuelle côté client.

• DynCloud : tous les 3 mois, pilotées par Dynapps, avec un rythme ajustable.

Sauvegardes de production.

• Odoo Online : 14 sauvegardes sur 3 mois, répliquées sur trois centres de données en Europe et au Canada.

• Odoo.sh : quotidiennes, conservées 7 jours, 4 semaines et 3 mois.

• DynCloud : toutes les 4 heures, soit 6 par jour, plus une sauvegarde quotidienne conservée 30 jours.

Accès réseau et base de données.

• Odoo Online : ni VPN, ni whitelisting IP, ni accès direct à la base, ni IP fixe, ni accès serveur.

• Odoo.sh : mêmes refus, et une IP fixe seulement partielle, puisqu'elle peut changer avec notification par appel API.

• DynCloud : tunnels VPN, whitelisting IP, accès direct à la base, IP fixe et accès serveur pour la configuration.

Emplacement des données.

• Odoo Online : Google Cloud, géré par Odoo SA.

• Odoo.sh : Google Cloud, géré par Odoo SA.

• DynCloud : Belgique, centres de données Combell certifiés ISO 27001.

Odoo Online : simple, et fermé.

Odoo Online convient aux entreprises qui utilisent les applications Odoo Enterprise standard, sans code ajouté.

La limite arrive dès la première intégration. Pas de module tiers, pas de connexion directe à la base, pas de VPN, pas d'IP fixe, pas de whitelisting. La personnalisation s'arrête à Studio et aux actions serveur. Les bases de test expirent après 14 jours. Et la configuration d'e-mail par défaut utilise les serveurs d'Odoo avec un domaine Odoo, du type info@client.odoo.com, avec un risque de classement en spam si la configuration n'est pas reprise correctement.

Odoo.sh : ouvert au code, contraint par la plateforme.

Odoo.sh lève la contrainte du code : modules marketplace et développements sur mesure y sont autorisés, et la personnalisation est complète.

Trois limites restent, et elles pèsent en production. D'abord, les workers s'éteignent au repos, y compris en production : la première requête après une période d'inactivité subit un démarrage à froid. Ensuite, les mises à jour mineures sont poussées chaque semaine par Odoo SA, avec un gel de 3 mois maximum et une intervention manuelle pour le client. Enfin, les paquets système ne sont pas installables, et les outils qui dépendent d'un accès réseau ou base, VPN, ETL PowerBI sur environnement mutualisé, whitelisting IP, restent hors d'atteinte. L'IP est fixe sur le papier, mais elle peut changer : le client en est averti par un appel API.

Côté environnements, la branche de staging impose une nouvelle copie de la production tous les 30 jours. Et le stockage plafonne à 512 Go pour les clients mutualisés.

DynCloud : géré, ouvert, et ce qu'il demande en retour.

DynCloud est un cluster Kubernetes géré par Dynapps, en collaboration avec Combell depuis 2023, avec tolérance de panne automatique, répartition de charge, redémarrage rapide des conteneurs défaillants et montée en charge verticale comme horizontale.

Ce que cela ouvre concrètement : accès direct aux serveurs et aux conteneurs pour les changements de configuration, whitelisting IP, connexions PG agent, tunnels VPN, accès proxy direct à la base, connexions tierces spécifiques. Les ressources peuvent être augmentées temporairement en CPU, mémoire et espace disque, pour absorber un lettrage de masse mensuel ou une campagne d'imports sans toucher à l'exploitation quotidienne.

Ce que cela demande en retour, parce que l'article serait malhonnête sans cette partie. Les mises à jour mineures ne sont pas automatiques : elles sont pilotées tous les 3 mois par Dynapps, et ajustées pour les environnements complexes. La configuration d'e-mail passe par un fournisseur externe, avec un accompagnement à l'intégration. Et la responsabilité de l'infrastructure est partagée entre Dynapps et Combell, pas assumée par vos équipes : c'est l'intérêt du modèle, mais cela suppose que ce partage vous convienne.

Et l'infrastructure propriétaire ?

L'hébergement sur votre propre infrastructure reste une quatrième voie, et la seule qui vous donne le contrôle complet de l'environnement.

Il déplace la charge plutôt qu'il ne la supprime. Sauvegardes, patching Linux, certificats, DNS, haute disponibilité et certification deviennent la responsabilité de votre DSI ou de votre partenaire informatique. C'est un choix cohérent quand l'hébergement interne est une exigence d'entreprise, pas un choix par défaut.

Comment déterminer les ressources dont vous avez besoin ?

Le dimensionnement dépend de l'usage réel, pas du seul nombre d'utilisateurs.

Les paramètres qui comptent : le nombre d'utilisateurs Odoo, leur profil (un utilisateur léger, qui saisit seulement ses heures, ne pèse pas comme un utilisateur intensif), le nombre et le type d'applications (CRM et Ventes seuls, ou aussi Inventaire, Fabrication, Comptabilité et Gestion de projet), la présence d'un e-commerce, les intégrations avec d'autres systèmes, et le volume de développement spécifique.

Quatre paliers couvrent les situations courantes. Les utilisateurs conseillés sont donnés pour un usage sporadique, puis pour un usage intensif.

• Small, 10 utilisateurs sporadiques ou 2 intensifs. Commandes de vente, achats et factures simples, boutique en ligne à faible trafic, développement spécifique à impact limité.

• Medium, 20 utilisateurs sporadiques ou 10 intensifs. Commandes et factures majoritairement simples avec quelques dossiers complexes, boutique à trafic moyen sans pics marqués, développement spécifique à impact moyen.

• Large, 75 utilisateurs sporadiques ou 20 intensifs. Volumes importants de commandes simples et complexes, trafic moyen avec pics, impression de rapports volumineux, traitements réguliers de gros volumes de données, base volumineuse accélérée par la mise en cache.

• Custom, dimensionnement dédié. Code spécifique à exigences particulières, très grand nombre d'utilisateurs, boutique à forts pics de trafic, volumes de données importants, ressources dédiées.

Chaque palier intègre une chaîne DTAP complète (Development, Testing, Acceptance, Production), c'est-à-dire quatre environnements distincts avec leur propre base, configuration et code, le code passant d'un environnement au suivant après validation.

Ces paliers restent indicatifs. En début de collaboration, le besoin exact n'est jamais connu : l'estimation se fait sur les informations disponibles, puis se réévalue pendant l'implémentation et s'ajuste si nécessaire. Les personnalisations et les pics de charge liés à vos cycles métier ont un impact significatif sur le résultat.

Pourquoi Dynapps ?

DynCloud existe parce que l'hébergement conditionne la qualité de l'implémentation, et que dépendre d'un tiers dans une situation critique ralentit la réponse.

Géré avec Combell depuis 2023, DynCloud donne à Dynapps le contrôle complet de l'infrastructure : une réponse plus rapide en cas d'urgence, et une compatibilité avec nos procédures internes de validation de code et de gestion des releases. La plateforme est pensée pour le co-développement, avec trois parties dans la boucle, le développeur externe, Dynapps pour la validation du code et la gestion des releases, et le client. Dynapps et Combell sont certifiés ISO 27001.