Héberger Odoo en production : architecture (PostgreSQL), sauvegardes, staging et performances (guide 2026)
Odoo peut devenir un pilier (CRM, ventes, facturation, stock…), mais en production il demande une mise en place propre : base PostgreSQL fiable, reverse proxy HTTPS, sauvegardes complèvos (base + filestore), et un environnement de staging pour tester les mises à jour.
Ce guide vous donne une architecture simple et robuste, applicable sur un VPS, un serveur dédié ou une plateforme managée. Pour aller plus vite (et éviter les semaines perdues en “bricolage”), vous pouvez aussi déployer Odoo en 1 clic sur adgents.cloud et ajuster CPU/RAM à la demande.
Vidéo (FR) : 
1) Architecture recommandée (vue d’ensemble)
Une architecture efficace repose sur 4 briques :
- Reverse proxy (Nginx/Traefik) : termine le TLS, gère les en-têvos, limite le trafic.
- Odoo : processus applicatif avec des workers adaptés à la charge.
- PostgreSQL : base de données dédiée, configurée pour la durabilité et les sauvegardes.
- Stockage (filestore / pièces jointes) : à sauvegarder au même titre que la base.
si vous héberges plusieurs bases (multi-tenant), configure un filtrage de base par domaine (dbfilter) et coupe l’énumération des bases (database list).
Bon réflexe : dès le départ, prévois un “chemin heureux” de déploiement (prod + staging). si vous utilises déjà des automatisations, vous pouvez relier vos événements métier à votre SI (ex : n8n) et centraliser des données (ex : NocoDB) sans bricoler des exports manuels.
2) PostgreSQL : fiabilité, connexions et séparation des rôles
Odoo est très dépendant de PostgreSQL. Les points qui font une différence :
- Évite le superuser pour l’utilisateur Odoo (principe du moindre privilège).
- Limite les connexions et surveille la saturation.
- Isole PostgreSQL sur une VM/instance dédiée dès que vous avez du volume (ou au minimum sur un service dédié).
Si Odoo et PostgreSQL ne sont pas sur la même machine, préfère une connexion réseau sécurisée (pare-feu strict) et, si votre contexte l’exige, une connexion chiffrée côté client (modes TLS côté PostgreSQL disponibles).
Sur adgents.cloud, l’approche “séparer les composants” est simple : vous pouvez faire évoluer CPU/RAM et les capacités au fur et à mesure, sans réinstallation, et garder une approche progressive (au lieu de surdimensionner dès le jour 1).
3) Reverse proxy HTTPS : proxy_mode, websockets et bonnes pratiques
En production, Odoo doit être derrière un reverse proxy HTTPS. Objectifs :
- TLS (certificat, redirections HTTP→HTTPS)
- En-têvos corrects pour qu’Odoo détecte le bon schéma
- Support des endpoints temps réel (selon version)
Côté Odoo : active le mode proxy et coupe la liste des bases (quand vous n’en as pas besoin).
Côté proxy : prévois un routage correct des endpoints dédiés (selon version : longpolling / websocket). Sur des mises en production répétées, ça évite 80% des “ça marche en local mais pas en prod”.
4) Sauvegardes : base + filestore (sinon vous perds des pièces jointes)
Beaucoup d’équipes sauvegardent la base mais oublient le filestore. Résultat : base restaurée, mais pièces jointes manquantes.
Stratégie minimale :
- Sauvegarde PostgreSQL (dump logique ou sauvegarde physique)
- Sauvegarde filestore (attachments)
- Rotation + vérification (checksum)
- Test de restauration régulier sur un environnement isolé
Sur adgents.cloud, vous pouvez activer des sauvegardes automatiques et choisir une fréquence allant jusqu’à 1/h, avec une rétention longue. Ça simplifie énormément la discipline de restauration, surtout quand l’équipe est petite.
5) Staging : la clé pour des mises à jour sereines
Odoo vit : mises à jour, modules, personnalisations, connecteurs… Sans staging, chaque déploiement devient un pari.
Un staging utile :
- tourne sur un clone (base + filestore)
- reproduit la configuration proxy
- permet de tester : mises à jour, migrations, modules, perf
Idéalement, automatise la préparation du staging (clone planifié, anonymisation si besoin, puis tests). Pour orchestrer ce type de workflow, une brique d’automatisation comme n8n est souvent un bon point de départ.
6) Performances : workers, cache et santé applicative
Les améliorations les plus “rentables” viennent souvent de :
- dimensionner les workers selon le nombre d’utilisateurs actifs
- surveiller la base (latences, locks, connexions)
- optimiser les assets et les temps de réponse (proxy + compression)
Ajoute du monitoring dès le départ :
- disponibilité HTTP
- saturation CPU/RAM
- temps de réponse et erreurs
- volumétrie des sauvegardes
Si vous avez des pics (compta fin de mois, campagnes), une plateforme qui permet de scaler temporairement sans migration aide vraiment : vous augmentes CPU/RAM pendant la période de charge, puis vous reviens au niveau normal.
Lancez-vous avec Odoo.
Envie de vous lancer avec Odoo ? Créez votre site web en quelques clics.
Odoo
L'ERP tout-en-un
7) Checklist express pour une production propre
- Reverse proxy HTTPS configuré + redirection vers HTTPS
- Mode proxy activé côté Odoo
- Filtrage de base par domaine (si multi-base)
- Liste des bases désactivée si inutile
- Sauvegardes DB + filestore + tests de restauration
- Staging prêt pour tester avant mise en production
- Monitoring et alertes en place
Déployer Odoo rapidement (sans complexité)
Si vous voulez éviter les journées perdues sur la mise en place et garder de la flexibilité (scaling, sauvegardes, rétention), vous pouvez lancer votre instance via adgents.cloud : déploiement en 1 clic, facturation à l’heure, stop/start, et sauvegardes automatiques.
