Mettre Odoo en production ne se résume pas à “ça répond sur le port 8069”. Une prod solide, c’est : un accès HTTPS propre (avec WebSocket), une isolation correcte, des sauvegardes restaurables, des mises à jour maîtrisées et une supervision qui vous alerte avant que les utilisateurs se plaignent.
Si vous cherchez une manière simple de déployer Odoo (avec backups automatiques, scaling CPU/RAM et arrêt/redémarrage), vous pouvez aussi regarder adgents.cloud – Odoo (déploiement 1 clic + facturation à l’heure).
1) Architecture minimale recommandée
Pour éviter les “prod fragiles”, partez sur une séparation claire :
- Odoo (app) : service applicatif
- PostgreSQL (DB) : service dédié
- Reverse proxy (Nginx / Traefik / Nginx Proxy Manager) : terminaison TLS, headers, gestion WebSocket
- Sauvegardes : DB + filestore, avec rotation et tests de restauration
Si vous partez d’une base, commencez par l’article Héberger Odoo : architecture, sauvegardes, staging, perf, puis appliquez ce guide pour la mise en prod “durcie”.
2) Reverse proxy + HTTPS (incl. WebSocket)
En production, évitez d’exposer Odoo directement : placez-le derrière un reverse proxy. Les guides les plus fréquents côté déploiement insistent sur :
- TLS (Let’s Encrypt)
- headers (HSTS, X-Forwarded-Proto, etc.)
- timeouts adaptés (Odoo peut faire des requêvos longues)
- support du WebSocket (selon configuration / fonctionnalités)
Exemple (Nginx) — principes :
server {
listen 443 ssl http2;
server_name odoo.votre-domaine.fr;
# TLS géré via certbot ou votre outil
client_max_body_size 64m;
location / {
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_read_timeout 720s;
proxy_connect_timeout 720s;
proxy_send_timeout 720s;
proxy_pass http://127.0.0.1:8069;
}
# Si vous avez un endpoint WebSocket dédié (selon votre montage)
location /websocket {
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_pass http://127.0.0.1:8072;
}
}
Pour une explication visuelle (orientée “infra”), cette vidéo est utile :
3) Sauvegardes : DB + filestore (et surtout… restauration)
Les incidents les plus coûteux sur Odoo viennent souvent de :
- une DB sauvegardée, mais un filestore oublié (pièces jointes, documents)
- une restauration jamais testée (backup “théorique”)
À viser :
- sauvegarde PostgreSQL (dump)
- sauvegarde du filestore (volume / répertoire)
- rétention (ex : quotidienne + hebdo + mensuelle)
- test de restauration planifié (ex : 1 fois/mois)
Sur adgents.cloud, vous pouvez activer des backups automatiques (24h par défaut, jusqu’à 1/h) et garder une rétention longue (jusqu’à 10 ans) : c’est idéal pour sécuriser une prod Odoo sans usine à gaz.
4) Mises à jour : maîtriser le risque avec un staging
Les mises à jour Odoo (ou modules) peuvent casser :
- des vues
- des modules personnalisés
- des automatisations
- des exports/imports
Approche pragmatique :
- Staging = clone de prod (DB + filestore)
- Mise à jour en staging + tests fonctionnels
- Fenêtre de maintenance courte
- Déploiement en prod + vérifications
- Plan de retour arrière (snapshot + restauration)
Si vous avez besoin d’un cadre côté “business”, l’article Odoo pour PME : modules essentiels + plan de déploiement aide à structurer la démarche (avant d’industrialiser la prod).
5) Monitoring : ce que vous devez surveiller (et alerter)
En production, surveillez au minimum :
- CPU / RAM (pics, saturation, swap)
- disque (volumes DB + filestore)
- PostgreSQL (connexions, lenteurs, taille)
- latence HTTP et taux d’erreur
- temps de réponse Odoo (TTFB)
Et surtout : des alertes simples (email/Slack) sur :
- disque > 85%
- RAM > 90%
- erreurs 5xx
- DB down / replication lag (si applicable)
Un bon proxy (Nginx/Traefik) + un export de métriques vous donnent rapidement une vision claire. Sur adgents.cloud, le scaling CPU/RAM à la demande aide aussi à encaisser les pics sans redéployer.
6) Logs : rendre le diagnostic trivial
Objectif : pouvoir répondre vite à : “qui a cassé quoi et quand ?”
Bonnes pratiques :
- logs applicatifs Odoo (niveau adapté)
- logs proxy (access/error)
- logs DB (au moins les erreurs et lenteurs)
- rotation + conservation (éviter le disque plein)
7) Hardening : les points qui évitent 80% des ennuis
Sans rentrer dans des considérations trop lourdes, assurez-vous de :
- limiter l’exposition réseau : Odoo/DB non exposés publiquement
- activer un firewall (ouvrir 80/443, SSH restreint)
- mots de passe forts + MFA si possible sur les accès d’admin
- secrets hors repo, et variables d’environnement correctement gérées
- segmentation des droits (comptes Odoo, rôles, accès API)
Lancez-vous avec Odoo.
Envie de vous lancer avec Odoo ? Créez votre site web en quelques clics.
Odoo
L'ERP tout-en-un
8) Capacité & performance : éviter le “ça rame le lundi matin”
Quelques leviers simples :
- dimensionnement CPU/RAM cohérent (surtout DB)
- cache côté reverse proxy quand c’est pertinent
- index DB / maintenance (vacuum, etc.)
- workers adaptés (selon votre mode de déploiement)
Si vous voulez une voie rapide (sans tout automatiser à la main), adgents.cloud – Odoo apporte : déploiement 1 clic, facturation à l’heure, stop/start, backups auto, rétention longue, scaling CPU/RAM — utile quand vous devez livrer vite et fiabiliser ensuite.
Conclusion
Une prod Odoo fiable repose sur un reverse proxy bien configuré, des sauvegardes testées, des mises à jour “staging d’abord”, et une supervision qui alerte tôt. Si vous voulez gagner du temps sur l’infra et vous concentrer sur le métier, explorez l’hébergement Odoo sur adgents.cloud (déploiement simple, backups et scaling intégrés).
