Stack · Infrastructure
Hébergement & infrastructure Odoo
Odoo n'est pas une application PHP. Il lui faut un processus qui tourne en permanence, une base PostgreSQL et de la mémoire — ce qui exclut d'emblée l'hébergement mutualisé.
L’hébergement d’Odoo est le sujet qu’on traite en dernier et qui décide de tout le reste. Une infrastructure sous-dimensionnée ne se rattrape pas par du bon code, et un ERP indisponible arrête l’entreprise — pas seulement un site web.
Ce qu’Odoo exige, et que le mutualisé ne donne pas
C’est la première chose que nous vérifions quand quelqu’un nous dit « on a déjà un hébergement ». Souvent, il s’agit d’un mutualisé qui héberge très bien un site WordPress — et qui n’accueillera jamais un ERP.
Les options réelles
| Option | Ce qu’on gagne | Ce qu’on accepte |
|---|---|---|
| Odoo.sh | Environnements, déploiement par Git, sauvegardes, mises à jour | Un cadre, et une facture qui suit les utilisateurs |
| VPS / dédié infogéré | Liberté totale, coût maîtrisé | Quelqu’un doit surveiller, sauvegarder, mettre à jour |
| On-premise | Données chez vous, contrôle total | Une vraie compétence système en interne, et du matériel |
Il n’y a pas de bon choix universel. La question qui tranche n’est pas technique : qui, concrètement, se lèvera la nuit si le serveur tombe ? Si personne n’a de réponse, Odoo.sh ou un infogéré s’imposent.
Le dimensionnement : croiser deux axes
L’erreur la plus fréquente est de dimensionner sur les seuls utilisateurs humains.
Un connecteur consomme des workers exactement comme un utilisateur — souvent davantage, parce qu’il n’a pas de temps de réflexion entre deux appels. Une infrastructure calibrée pour quarante personnes, mise en service avec trois connecteurs actifs, sature immédiatement. L’exploitant conclut qu’Odoo est lent ; c’est l’infrastructure qui n’a jamais été calibrée pour ce qu’on lui demande.
Nous dimensionnons donc sur : utilisateurs simultanés réels + charge d’API + traitements planifiés + marge de croissance.
Les tâches planifiées : l’oubli qui coûte cher
C’est le grand classique de l’installation faite vite. Odoo repose sur des tâches planifiées pour tout ce qui se produit « tout seul » : relances de factures, réapprovisionnements, traitements différés, envois de mails.
Quand elles ne tournent pas, rien ne le signale. Odoo a l’air de fonctionner. Les utilisateurs saisissent, les écrans répondent, et pendant ce temps aucune relance ne part et aucun réappro ne se déclenche. Le problème se découvre des semaines plus tard, en cherchant pourquoi les impayés grimpent.
Ce que nous vérifions sur un existant
- Le mode d’hébergement et les ressources réellement allouées.
- Le nombre de workers, croisé avec la charge réelle.
- L’état des tâches planifiées — tournent-elles, et quand ?
- Les sauvegardes : existent-elles, et ont-elles déjà été restaurées ? Voir sauvegarde & reprise.
- Les traces et la supervision : sait-on que le service est tombé avant que le premier utilisateur n’appelle ?
Les limites, dites franchement
Nous ne sommes pas hébergeur. Nous concevons, nous dimensionnons, nous installons et nous documentons. L’exploitation quotidienne revient à Odoo.sh, à votre infogéreur ou à votre équipe — et il faut que ce soit clair pour quelqu’un, sinon personne ne le fait.
Un serveur plus gros ne corrige pas un modèle lent. Voir performance : doubler la machine sur une base mal conçue, c’est payer deux fois plus cher la même lenteur.
Le on-premise a un coût caché. Le matériel est visible ; la personne qui applique les correctifs de sécurité, surveille les disques et teste les restaurations ne l’est pas. Ce coût-là existe quand même.
Questions fréquentes
Peut-on héberger Odoo sur un mutualisé ?
Non. Odoo est un service qui tourne en permanence et qui exige sa propre base PostgreSQL ; un hébergement mutualisé n’offre ni l’un ni l’autre. Toute promesse contraire relève du malentendu ou de la vente forcée.
Odoo.sh ou VPS ?
Odoo.sh apporte le confort — environnements, déploiement par Git, sauvegardes, mises à jour — au prix d’un cadre. Un VPS infogéré donne la liberté et la responsabilité qui va avec : quelqu’un doit surveiller, sauvegarder, mettre à jour. Le bon choix dépend de qui, chez vous ou chez votre prestataire, portera cette responsabilité au quotidien.
Combien de ressources faut-il ?
Cela se dimensionne sur deux axes qu’on oublie souvent de croiser : les utilisateurs humains et les appels d’API. Un connecteur actif consomme des workers comme un utilisateur — parfois plus. Une infrastructure calibrée sur les seuls humains sature dès la mise en service des connecteurs.
Faut-il un serveur pour la base et un autre pour Odoo ?
Pas au départ. À partir d’une certaine charge, séparer PostgreSQL a du sens : les deux ne consomment pas les mêmes ressources et ne se dimensionnent pas au même rythme. C’est une décision de croissance, pas un prérequis.
Et les tâches planifiées ?
C’est l’oubli classique d’une installation faite vite. Sans elles, les relances ne partent pas, les réapprovisionnements ne se déclenchent pas, les traitements différés dorment. Odoo a l’air de fonctionner, et la moitié de ce qui devrait se produire tout seul ne se produit jamais.
Un point technique à valider ?
Décrivez le contexte : version d'Odoo, systèmes en jeu, volumétrie. Réponse d'un intégrateur sous 24 h ouvrées.