Déployer Odoo from scratch : si vous savez installer WordPress, vous savez le faire

Odoo n’est pas compliqué. On vous fait juste croire que ça l’est.

Scène ordinaire. Vous cherchez à installer Odoo sur un serveur. Vous tombez sur la doc officielle : elle vous pousse vers Odoo.sh (leur plateforme SaaS) ou, à défaut, vers un paquet .deb qui installe tout en boîte noire. Vous cherchez un tutoriel communautaire : 150 lignes de docker-compose.yml, trois volumes nommés, un réseau bridge, et un restart: always qui sent le pansement sur jambe de bois. Vous demandez un devis à un intégrateur : 15 000 € pour « la mise en place de l’environnement », 800 €/jour pour « l’accompagnement au démarrage ».

Et vous vous dites : Odoo, c’est compliqué.

Non.

L’architecture d’Odoo, c’est un WordPress qui parle PostgreSQL et Python. Un interpréteur, une base de données, un dossier de fichiers, un reverse proxy devant. Point. Si vous avez déjà monté un WordPress sur un VPS (et si vous lisez cet article, c’est probablement le cas), vous avez déjà toutes les compétences nécessaires.

La complexité d’Odoo n’est pas technique. Elle est commerciale. L’éditeur (Odoo SA) a tout intérêt à vous pousser vers son SaaS ou ses partenaires certifiés. Les intégrateurs ont tout intérêt à maintenir une barrière à l’entrée qui justifie leurs tarifs. La documentation a tout intérêt à rendre l’installation manuelle suffisamment opaque pour que vous abandonniez et sortiez la carte bleue.

C’est exactement le même mécanisme que les agences WordPress en 2015 : des boîtes qui facturaient 10 000 € un site montable en une après-midi avec un thème premium et trois plugins. Le produit n’était pas compliqué. La rente, si.

Cet article va vous montrer, commande par commande, qu’installer Odoo sur un serveur nu est exactement aussi simple qu’installer WordPress. Pas plus, pas moins.

Le parallèle WordPress / Odoo : tout ce que vous savez déjà

Avant d’ouvrir un terminal, posons la table. Voici ce que vous maîtrisez déjà, et son équivalent exact dans l’écosystème Odoo :

La ligne de conclusion, c’est celle-ci : Odoo n’est pas plus « spécial » que WordPress + WooCommerce + un CRM + un module RH + un gestionnaire de stock. Il est juste cohérent par design : tout vient du même éditeur, tout partage le même ORM, la même base, les mêmes vues. Là où WordPress empile des plugins de trois auteurs différents qui se marchent dessus, Odoo intègre nativement. C’est sa force. Et les deux mondes ne sont pas étanches : WP4Odoo synchronise WooCommerce et Odoo en bidirectionnel, preuve que le pont technique entre les deux écosystèmes existe déjà. Mais côté déploiement, le geste est le même.

Pourquoi on vous fait croire que c’est compliqué

La doc officielle vous pousse ailleurs

Allez sur odoo.com/page/download. La première option, c’est Odoo.sh, leur PaaS managé. La deuxième, c’est un .deb / .rpm qui fait tout en une commande et ne vous apprend rien. L’installation depuis les sources ? Enterrée dans la doc développeur, noyée dans des prérequis Docker. Le message est clair : ne touchez pas à l’infrastructure, laissez-nous faire.

C’est un choix commercial parfaitement rationnel. Odoo SA gagne de l’argent sur Odoo.sh et sur les licences Enterprise. J’ai détaillé les quatre options d’hébergement Odoo dans un article dédié : Online, Odoo.sh, on-premise, hébergement tiers. Ce que vous lisez ici, c’est la cinquième option, celle que personne ne vous présente : le bare metal, à la main, sans intermédiaire. Un sysadmin qui installe Community en bare metal sur son propre serveur, c’est un client perdu.

Les intégrateurs vendent l’opacité

Un intégrateur Odoo certifié facture entre 800 et 1 500 € par jour. Son modèle économique repose sur une asymétrie d’information : vous ne savez pas faire, donc vous payez quelqu’un qui sait. Plus le « savoir-faire » paraît ésotérique, plus le tarif se justifie.

C’est exactement le même mécanisme que les agences WordPress qui vendaient un site à 15 000 € monté avec Elementor et 12 plugins premium. Le rôle des « experts certifiés Odoo », c’est le même que celui des « consultants WordPress Senior » de 2016 : plus vous compliquez, plus vous justifiez vos 120 €/h.

Je ne dis pas que tous les intégrateurs sont des charlatans. Il y a des projets Odoo complexes qui justifient un accompagnement (migration multi-sociétés, développements spécifiques lourds, intégrations EDI). Mais pour un déploiement standard d’une PME ? Vous pouvez le faire vous-même. Et vous devriez le faire vous-même, ne serait-ce que pour comprendre ce qui tourne sur votre serveur. C’est d’ailleurs en installant Odoo from scratch pour développer mon premier module (un pipeline de digitalisation de factures fournisseurs par IA, en Community, sans la brique OCR verrouillée en Enterprise) que j’ai réalisé à quel point la barrière à l’entrée était artificielle.

Le requirements.txt fait peur (à tort)

Quand vous ouvrez le requirements.txt d’Odoo, vous voyez 80 dépendances Python. Ça impressionne. Sauf que :

• La moitié sont des bibliothèques standard (parsing XML, manipulation d’images, cryptographie).
• Un pip install -r requirements.txt dans un venv les installe en 30 secondes.
• C’est exactement la même réalité qu’un stack WordPress sérieux : PHP-FPM, extensions php-gd, php-xml, php-mbstring, php-curl, php-zip, Redis, OPcache… Personne ne dit que WordPress est « compliqué » parce qu’il faut installer php-intl.

PostgreSQL n’est pas plus dur que MySQL

C’est l’autre épouvantail. « Odoo utilise PostgreSQL, c’est pas pareil. » Si. Les commandes changent, la logique est identique :

Même geste, même logique, syntaxe légèrement différente. Si vous savez créer une base MySQL pour WordPress, vous savez créer une base PostgreSQL pour Odoo. La courbe d’apprentissage, c’est 15 minutes.

La vraie difficulté, c’est la migration SaaS → on-premise

S’il y a un point où la complexité n’est pas fabriquée, c’est celui-ci. Odoo Online tourne sur la dernière version, souvent en avance sur ce que votre serveur cible, et Odoo ne fournit pas d’outil de downgrade. Incompatibilité de schéma, dépendance au support pour obtenir un export dans la bonne version, tables critiques qui changent entre releases : migrer une base SaaS vers un serveur on-premise, c’est un projet à part entière là où en WordPress c’est un export XML et un wp import. J’ai détaillé les implications de chaque option d’hébergement dans mon comparatif dédié. C’est aussi un argument pour commencer en bare metal directement plutôt que de passer par le SaaS « pour tester ».

Le déploiement bare metal, étape par étape

On y est. Quatre blocs, dans l’ordre. À la fin, vous avez un Odoo 18 fonctionnel en HTTPS.

1. Préparer le système et PostgreSQL

# Mise à jour système
sudo apt update && sudo apt upgrade -y

# Installer PostgreSQL
sudo apt install -y postgresql

# Créer l'utilisateur PostgreSQL pour Odoo
sudo -u postgres createuser -s odoo

# Vérifier
sudo -u postgres psql -c "\du"
Langage du code : PHP (php)

C’est l’équivalent exact de votre sudo apt install mariadb-server + CREATE USER 'wordpress'@'localhost'. Si vous hébergez déjà sous Debian, vous êtes en terrain connu.

Le flag -s donne le rôle superuser : en production, vous pouvez restreindre, mais pour un premier déploiement, ça simplifie. Comme quand vous donnez GRANT ALL à votre user WordPress.

2. Créer un utilisateur système, un venv Python, et installer les dépendances

# Installer les dépendances système
sudo apt install -y python3-dev python3-venv python3-pip \
    libxml2-dev libxslt1-dev libpq-dev libldap2-dev libsasl2-dev \
    libssl-dev libjpeg-dev zlib1g-dev libfreetype6-dev \
    node-less npm git

# Installer wkhtmltopdf (version spécifique requise par Odoo)
# Odoo 18 nécessite wkhtmltopdf 0.12.6.1 avec le patch Qt
sudo apt install -y wkhtmltopdf

# Créer l'utilisateur système
sudo useradd -m -d /opt/odoo -s /bin/bash odoo

# Cloner Odoo 18
sudo -u odoo git clone https://github.com/odoo/odoo.git \
    --depth 1 --branch 18.0 /opt/odoo/odoo-server

# Créer le venv et installer les dépendances Python
sudo -u odoo python3 -m venv /opt/odoo/venv
sudo -u odoo /opt/odoo/venv/bin/pip install wheel
sudo -u odoo /opt/odoo/venv/bin/pip install -r /opt/odoo/odoo-server/requirements.txt
Langage du code : PHP (php)

Décomposons ce que vous venez de faire :

• Les lib*-dev : l’équivalent des extensions PHP (php-gd, php-xml, php-curl…). Des bibliothèques système que Python utilise pour compiler ses modules. Pas plus ésotérique.
• wkhtmltopdf : l’outil qui génère les PDF (factures, rapports). C’est LE piège classique d’Odoo, on y revient en partie VII.
• Le venv : un environnement Python isolé. L’équivalent conceptuel d’un php-fpm dédié à un site. Ça évite les conflits de versions entre projets.
• Le git clone --depth 1 : vous récupérez le code source d’Odoo, branche 18.0, sans l’historique Git. C’est comme télécharger WordPress et le dézipper dans /var/www/.

Le requirements.txt qui faisait peur ? Une commande pip install et c’est réglé. Exactement comme sudo apt install php-gd php-xml php-mbstring php-curl php-zip php-intl.

3. Premier lancement : création de la base

# Lancer Odoo en mode « première fois »
sudo -u odoo /opt/odoo/venv/bin/python /opt/odoo/odoo-server/odoo-bin \
    --addons-path=/opt/odoo/odoo-server/addons \
    -d ma_base \
    --without-demo=all \
    -i base
Langage du code : PHP (php)

Odoo démarre, crée la base ma_base dans PostgreSQL, installe le module base, et écoute sur http://localhost:8069.

C’est votre équivalent de « ouvrir http://monsite.com/wp-admin/install.php et cliquer sur Installer ». Sauf qu’ici, ça se passe en CLI. Le résultat est le même : une application fonctionnelle avec un écran de login.

Ouvrez http://votre-ip:8069 dans un navigateur. Vous devriez voir l’écran de connexion Odoo. Login par défaut : admin / admin.

Astuce : Le flag --without-demo=all évite de charger les données de démonstration. En prod, c’est ce que vous voulez. En dév, retirez-le pour avoir des données de test.

4. Nginx reverse proxy + Systemd + SSL

Le service Systemd

Créez /etc/systemd/system/odoo.service :

[Unit]
Description=Odoo 18
After=postgresql.service
Requires=postgresql.service

[Service]
Type=simple
User=odoo
Group=odoo
ExecStart=/opt/odoo/venv/bin/python /opt/odoo/odoo-server/odoo-bin \
    --config=/etc/odoo/odoo.conf
Restart=on-failure
RestartSec=5

[Install]
WantedBy=multi-user.target
Langage du code : JavaScript (javascript)

sudo systemctl daemon-reload
sudo systemctl enable odoo
sudo systemctl start odoo

C’est votre php8.3-fpm.service, en version Odoo. Même logique : un process qui tourne en arrière-plan, géré par systemd, qui redémarre automatiquement en cas de crash.

Le reverse proxy Nginx

server {
    listen 80;
    server_name odoo.mondomaine.com;

    # Redirection HTTPS (après Certbot)
    # return 301 https://$server_name$request_uri;

    proxy_read_timeout 720s;
    proxy_connect_timeout 720s;
    proxy_send_timeout 720s;
    client_max_body_size 200m;

    location / {
        proxy_pass http://127.0.0.1:8069;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header X-Forwarded-Host $host;
        proxy_set_header X-Forwarded-Server $host;
    }

    # Headers sécurité — mêmes que pour un WordPress sécurisé
    add_header X-Frame-Options "SAMEORIGIN" always;
    add_header X-Content-Type-Options "nosniff" always;

    location /longpolling {
        proxy_pass http://127.0.0.1:8072;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }

    location ~* /web/static/ {
        proxy_cache_valid 200 90m;
        proxy_buffering on;
        expires 864000;
        proxy_pass http://127.0.0.1:8069;
    }
}
Langage du code : PHP (php)

sudo ln -s /etc/nginx/sites-available/odoo /etc/nginx/sites-enabled/
sudo nginx -t
sudo systemctl reload nginx

Si vous avez déjà configuré un vhost Nginx pour WordPress avec fastcgi_pass, vous reconnaissez la structure. La seule différence : au lieu de fastcgi_pass vers PHP-FPM, c’est un proxy_pass vers le port 8069. Nginx ne parle plus à un interpréteur PHP mais à un serveur HTTP Python. Le reste (headers, timeouts, cache des statiques), c’est identique.

Le bloc /longpolling est spécifique à Odoo : c’est le websocket qui gère les notifications en temps réel (messages instantanés, mise à jour des vues). Il écoute sur le port 8072.

SSL avec Certbot

sudo apt install -y certbot python3-certbot-nginx
sudo certbot --nginx -d odoo.mondomaine.com
Langage du code : CSS (css)

Strictement identique à ce que vous faites pour WordPress. Certbot modifie le vhost, ajoute le certificat, configure le renouvellement automatique. Rien de spécifique à Odoo. Pensez ensuite à configurer vos headers HTTP de sécurité, la même discipline que sur vos sites WordPress.

odoo.conf décrypté : le wp-config.php d’Odoo

Le fichier de configuration d’Odoo, c’est son wp-config.php. Créez-le dans /etc/odoo/odoo.conf :

sudo mkdir -p /etc/odoo
sudo chown odoo:odoo /etc/odoo

Voici les trois profils, ligne par ligne.

Profil 1 : Dév local

[options]
; === Base de données ===
db_host = localhost
db_port = 5432
db_user = odoo
db_password = False
; False = authentification peer (pas de mot de passe, comme MySQL en local)

; === Chemins ===
addons_path = /opt/odoo/odoo-server/addons,/opt/odoo/custom-addons
data_dir = /opt/odoo/.local/share/Odoo

; === Serveur ===
http_port = 8069
workers = 0
; workers = 0 : mode mono-thread, parfait pour le dév
; Équivalent de PHP built-in server (php -S localhost:8000)

; === Proxy ===
proxy_mode = False
; Pas de reverse proxy en dév local

; === Sécurité ===
admin_passwd = mon_master_password
; Protège /web/database/manager (création/suppression de bases)
; N'existe pas en WordPress — c'est un bonus sécurité

; === Logs ===
log_level = debug
logfile = False
; False = sortie console (pratique en dév)
Langage du code : PHP (php)

Profil 2 : Petite prod

[options]
; === Base de données ===
db_host = localhost
db_port = 5432
db_user = odoo
db_password = un_vrai_mot_de_passe
db_name = ma_base_prod
; db_name : restreint Odoo à une seule base (sécurité)

dbfilter = ^ma_base_prod$
; Empêche l'accès aux autres bases via l'URL
; Équivalent de définir DB_NAME dans wp-config.php

; === Chemins ===
addons_path = /opt/odoo/odoo-server/addons,/opt/odoo/custom-addons
data_dir = /var/lib/odoo

; === Serveur ===
http_port = 8069
workers = 4
; workers > 0 : mode multi-process
; Règle : (2 × CPU) + 1
; Équivalent de pm.max_children dans php-fpm.conf

max_cron_threads = 2
; Threads dédiés aux tâches planifiées (ir.cron)
; Équivalent de wp-cron, mais géré en interne

limit_memory_hard = 2684354560
limit_memory_soft = 2147483648
limit_time_cpu = 600
limit_time_real = 1200
; Limites de ressources par worker — même logique que
; memory_limit et max_execution_time en php.ini

; === Proxy ===
proxy_mode = False
; Pas encore derrière Nginx ? Laissez à False

; === Sécurité ===
admin_passwd = un_master_password_tres_long
list_db = False
; list_db = False : cache la liste des bases sur l'écran de login
; Sécurité basique mais importante

; === Logs ===
log_level = warn
logfile = /var/log/odoo/odoo-server.log
log_handler = :WARNING
Langage du code : PHP (php)

Le fichier odoo.conf contient le mot de passe de la base en clair. Verrouillez-le :

sudo chmod 640 /etc/odoo/odoo.conf
sudo chown root:odoo /etc/odoo/odoo.conf

Standard sysadmin : même réflexe que pour un wp-config.php en production.

Profil 3 : Derrière Nginx / HTTPS

Partez du profil 2 et ajoutez :

; === Proxy ===
proxy_mode = True
; CRITIQUE : sans ça, Odoo ne lit pas les headers X-Forwarded-*
; et génère des URLs en http:// au lieu de https://
; C'est comme set_real_ip_from dans Nginx pour WordPress
Langage du code : PHP (php)

C’est le paramètre que tout le monde oublie et qui cause 80 % des problèmes « mon Odoo est en HTTP alors que j’ai Certbot ». proxy_mode = True dit à Odoo : « je suis derrière un reverse proxy, fais confiance aux headers X-Forwarded-For et X-Forwarded-Proto ». Sans ça, les redirections, les liens dans les emails, les URLs des rapports PDF : tout sera en http://.

Correspondances wp-config.php ↔ odoo.conf

Le filestore : le wp-content/uploads/ d’Odoo

Dans WordPress, quand vous uploadez une image ou un PDF, il atterrit dans wp-content/uploads/2026/02/. Dans Odoo, c’est le filestore, et le concept est rigoureusement identique.

Où il se trouve

/var/lib/odoo/filestore/ma_base/
├── 00/
│   ├── 00a1b2c3d4e5f6...
│   └── 00f7e8d9c0b1a2...
├── 01/
│   └── 01abc123def456...
├── ...
└── ff/
Langage du code : JavaScript (javascript)

Odoo stocke les fichiers avec un hash SHA-1 comme nom, organisés en sous-dossiers par les deux premiers caractères du hash. C’est moins lisible que uploads/2026/02/photo.jpg, mais c’est plus efficace : pas de collision de noms, pas de problème d’encodage, déduplication automatique (deux pièces jointes identiques = un seul fichier physique).

Le chemin est défini par data_dir dans odoo.conf. Par défaut :

• En dév : ~/.local/share/Odoo/filestore/
• En prod : /var/lib/odoo/filestore/ (si vous avez configuré data_dir = /var/lib/odoo)

Le backup, c’est base + filestore

C’est la règle critique, exactement comme pour WordPress :

Un dump SQL sans le filestore, c’est une base de données qui référence des fichiers qui n’existent plus. Des factures sans logo, des produits sans photo, des pièces jointes vides. Exactement comme un dump WordPress sans wp-content/uploads/.

En pratique, un one-liner suffit :

pg_dump ma_base | gzip > dump_$(date +%Y%m%d).sql.gz && tar czf filestore_$(date +%Y%m%d).tar.gz /var/lib/odoo/filestore/ma_base/
Langage du code : JavaScript (javascript)

Automatisez en cron, testez la restauration mensuellement, comme pour WordPress.

Restaurer une base Odoo

Via l’interface web (le plus simple) :

1. Accédez à https://odoo.mondomaine.com/web/database/manager
2. Entrez le master password (admin_passwd de odoo.conf)
3. Cliquez sur « Restore Database »
4. Uploadez le .zip (qui contient le dump SQL + le filestore + un manifest.json)
5. Choisissez « This database is a copy » (neutralise les emails et les crons, comme un staging WordPress)

Via le terminal (pour les gros fichiers ou l’automatisation) :

# Créer la base
sudo -u postgres createdb -O odoo ma_base_restauree

# Importer le dump
sudo -u postgres psql ma_base_restauree < dump.sql

# Copier le filestore
sudo cp -r filestore_sauvegarde/ /var/lib/odoo/filestore/ma_base_restauree/
sudo chown -R odoo:odoo /var/lib/odoo/filestore/ma_base_restauree/

# Redémarrer Odoo
sudo systemctl restart odoo
Langage du code : PHP (php)

Erreur 413 ? Si la restauration via le web échoue sur les grosses bases, augmentez client_max_body_size dans votre config Nginx. C’est le même problème que l’upload de gros médias dans WordPress.

Les vrais pièges (pas ceux qu’on vous vend)

Maintenant qu’on a démystifié le déploiement, parlons des vrais problèmes. Pas ceux que les intégrateurs inventent pour justifier leurs factures : ceux que vous rencontrerez réellement.

wkhtmltopdf : le seul vrai piège technique

Odoo utilise wkhtmltopdf pour générer les PDF (factures, devis, rapports). Le problème : Odoo nécessite une version spécifique avec un patch Qt, et celle des dépôts Debian/Ubuntu n’est pas toujours la bonne.

Si vos PDF sont moches (pas de CSS, mise en page cassée, headers manquants), c’est presque toujours ça. Odoo 18 requiert wkhtmltopdf 0.12.6.1 (patched Qt), vérifiez avec wkhtmltopdf --version et testez un PDF de facture après installation.

# Vérifier la version installée
wkhtmltopdf --version

# Si la version n'est pas la bonne, installer manuellement
# Vérifiez la version recommandée sur le GitHub d'Odoo
wget https://github.com/wkhtmltopdf/packaging/releases/download/0.12.6.1-3/wkhtmltox_0.12.6.1-3.bookworm_amd64.deb
sudo apt install -y ./wkhtmltox_0.12.6.1-3.bookworm_amd64.deb
Langage du code : PHP (php)

C’est le seul composant d’Odoo qui demande une attention particulière à la version. L’équivalent WordPress serait une version spécifique de libgd pour le traitement d’images, sauf que ça n’arrive jamais en pratique.

Workers : l’équivalent des processus PHP-FPM

Avec workers = 0 (mode dév), Odoo traite une requête à la fois. En production, il faut passer en mode multi-process :

workers = 4          # (2 × nombre de CPU) + 1
max_cron_threads = 2 # Threads pour les tâches planifiées
Langage du code : PHP (php)

Concrètement : 2 CPU → workers = (2×2)+1 = 5. 4 CPU → workers = (2×4)+1 = 9.

C’est exactement la logique de pm.max_children dans la config PHP-FPM :

Si Odoo rame avec plusieurs utilisateurs, c’est presque toujours un problème de workers, pas un problème de « complexité Odoo ».

Droits fichiers : même combat que WordPress

# Le user odoo doit posséder ses fichiers
sudo chown -R odoo:odoo /opt/odoo/
sudo chown -R odoo:odoo /var/lib/odoo/
sudo chown -R odoo:odoo /var/log/odoo/

# Les fichiers de config lisibles par odoo uniquement
sudo chmod 640 /etc/odoo/odoo.conf
Langage du code : PHP (php)

C’est le chown -R www-data:www-data /var/www/wordpress/ que vous connaissez par cœur. Même réflexe, même logique.

Mise à jour des modules : le wp plugin update d’Odoo

# Mettre à jour un module spécifique
sudo -u odoo /opt/odoo/venv/bin/python /opt/odoo/odoo-server/odoo-bin \
    -u nom_du_module -d ma_base --stop-after-init

# Mettre à jour tous les modules (après un git pull)
sudo -u odoo /opt/odoo/venv/bin/python /opt/odoo/odoo-server/odoo-bin \
    -u all -d ma_base --stop-after-init
Langage du code : PHP (php)

Le flag --stop-after-init fait qu’Odoo s’arrête après la mise à jour au lieu de rester en écoute. C’est l’équivalent de wp plugin update contact-form-7, en un peu plus verbeux, mais même résultat.

Community vs Enterprise : où est la frontière

Cet article installe Community, mais la question se pose toujours. En résumé : Community couvre largement le périmètre d’une PME qui démarre, surtout complété par les modules OCA. Enterprise est un produit abouti qui se justifie quand vos besoins dépassent ce périmètre. J’ai détaillé la frontière entre les deux dans mon comparatif des options d’hébergement Odoo. Ce qui compte ici, c’est que le déploiement bare metal fonctionne pour les deux éditions, le geste est identique.

Reprenez le contrôle

Vous venez de lire environ 3 000 mots. Et dans ces 3 000 mots, il n’y a rien que vous ne sachiez pas déjà faire.

Installer PostgreSQL, c’est installer MySQL. Créer un venv Python, c’est configurer PHP-FPM. Mettre un reverse proxy Nginx devant odoo-bin, c’est mettre un reverse proxy devant n’importe quoi. Configurer odoo.conf, c’est remplir wp-config.php. Sauvegarder base + filestore, c’est sauvegarder base + uploads.

La seule différence entre « je sais installer WordPress » et « je sais installer Odoo », c’est que quelqu’un vous a convaincu que la deuxième phrase était fausse.

Odoo on-premise sans Docker, sans intégrateur et sans bullshit, c’est possible. La vraie valeur n’est pas dans l’outil. Elle n’a jamais été dans l’outil. Elle est dans ce que vous en faites avec votre métier.