Serveur Odoo : calculer les ressources sans surdimensionner

Un serveur Odoo se dimensionne à partir des utilisateurs simultanés, des traitements de vos modules et de PostgreSQL, pas du nombre de comptes achetés. Pour Odoo 20, vérifiez d'abord Python 3.12 et PostgreSQL 16 au minimum. Ensuite, calculez les workers HTTP, comptez les crons, puis ajoutez à leur mémoire celle de la base et du système. Un résultat de 2 Go pour les processus Odoo ne signifie pas qu'une machine de 2 Go suffit.

Les chiffres ci-dessous sont vérifiés le 28 octobre 2026. Les règles de calcul viennent d'Odoo ; les exemples sont nos calculs, avec leurs hypothèses visibles. Ils concernent Community et Enterprise auto-hébergés, sans promettre une capacité identique pour tous les modules.

Les prérequis logiciels d'un serveur Odoo#

Le minimum logiciel dépend de la version majeure d'Odoo. Vérifiez-le avant de louer une machine. Gardez ce tableau dans votre dossier de migration.

La documentation d'installation d'Odoo 18 (nouvel onglet) donne les premiers minimums. Celle d'Odoo 20 (nouvel onglet) indique notamment le passage de PostgreSQL 13 à 16. « Minimum » ne veut pas dire que toute version ultérieure de Python fonctionnera : vérifiez aussi les dépendances de la branche choisie et celles de vos modules.

Pour la production, retenez Linux et le mode multi-process. Sous Windows, ce mode n'existe pas. Un installeur Windows convient aux essais locaux, pas au dimensionnement décrit ici. Le choix Debian ou Ubuntu vient ensuite : vérifiez les versions des paquets réellement disponibles, au lieu de vous fier seulement au nom de la distribution.

Enterprise ajoute des modules à Community. Son étiquette ne fournit donc pas un coefficient de RAM : ce sont les applications installées, les requêtes et les traitements exécutés qui changent la charge. Prévoyez aussi les dépendances système et celles des rapports PDF ; réussir un démarrage ne valide pas une installation complète.

Calculer les workers avant la mémoire#

La règle d'Odoo est un point de départ pour une charge à mesurer. Le guide de déploiement (nouvel onglet) propose environ 6 utilisateurs simultanés par worker et le repère CPU (nombre de CPU × 2) + 1. Il précise que les workers cron consomment eux aussi du CPU.

Un calcul reproductible pour 20, 30 et 60 utilisateurs#

Supposons une instance, un worker cron et une charge comparable à l'exemple officiel : 80 % de requêtes légères à 150 Mo, 20 % de lourdes à 1 Go. En reprenant sa convention de calcul, 1 Go vaut ici 1 024 Mo. La moyenne estimée par worker est donc 0,8 × 150 + 0,2 × 1 024 = 324,8 Mo.

Ce tableau exclut PostgreSQL, le système, le proxy et le worker événementiel dédié au websocket. Ne commandez pas une machine sur cette seule base. Les pointes restent à mesurer. Une estimation moyenne ne couvre pas le pic où plusieurs rapports lourds tournent ensemble.

Pour 30 utilisateurs simultanés, le compte HTTP donne 5 workers. Ajouter un cron porte le total de calcul à 6 : le repère de 2 CPU donne seulement 2 × 2 + 1 = 5. Ne présentez donc pas 2 CPU comme une capacité validée en oubliant le cron. Sur un VPS, mesurez aussi la contention de l'hôte : un vCPU partagé n'assure pas le temps processeur d'un cœur dédié.

L'intérêt du calcul détaillé est surtout de rendre visibles les processus et la mémoire que le raccourci oublie.

Les limites mémoire ne réservent pas la RAM#

limit_memory_soft et limit_memory_hard encadrent la mémoire virtuelle par worker sous Linux ; ils ne constituent pas un budget global de RAM physique pour la machine. La limite douce déclenche le recyclage après la requête, la limite dure peut interrompre le traitement. Ce sont des garde-fous, pas de la mémoire allouée à l'avance.

Le guide officiel donne, dans son exemple, 629145600 octets pour la limite douce et 1677721600 pour la dure. Ces valeurs correspondent à 600 et 1 600 Mio ; elles ne sont pas une recommandation universelle. Les recopier sur tous les workers sans vérifier la RAM disponible ne protège pas le serveur d'une saturation globale.

Commencez par mesurer la consommation lors d'un import, d'un calcul stocké et d'un export représentatifs de votre base. Un module qui lit des enregistrements en boucle peut saturer un worker bien avant que les autres soient occupés. Les autres attendent. Ajouter des workers ne corrigera pas cette requête.

PostgreSQL et le filestore ont leur propre budget#

Prévoyez plus d'espace que le simple fichier de sauvegarde. Additionnez la base avec ses index, les pièces jointes du filestore, les journaux et l'espace temporaire des opérations que vous exécutez. Une restauration de test sur la même machine crée une copie supplémentaire : mesurez-la avant d'affirmer que le disque suffira.

Pour une installation Odoo 20 depuis les sources, ces commandes sont des lectures, à adapter au rôle PostgreSQL et au data_dir utilisés. La requête mesure la base avec ses index ; remplacez ma_base par son nom et le chemin par votre dossier de données :

psql -d ma_base -c "SELECT pg_size_pretty(pg_database_size(current_database()));"
du -sh /chemin/data_dir/filestore/ma_base
df -h /chemin/data_dir

Le nombre d'utilisateurs ne dimensionne pas le disque. Une équipe qui joint des documents et une autre qui saisit surtout du texte n'ont pas la même croissance. Relevez les tailles régulièrement et confrontez la tendance à votre durée de conservation.

La base consomme aussi de la RAM et du CPU. Les connexions Odoo, les tris SQL et le cache PostgreSQL concurrencent les workers quand tout tourne sur la même machine. Si vous augmentez workers, vérifiez le nombre de connexions observées et les réglages db_maxconn et max_connections avant de déplacer le problème vers PostgreSQL.

Quand séparer l'application et la base#

Séparez les composants pour une contention constatée ou un besoin d'exploitation, pas à partir d'un seuil arbitraire de comptes. Une seule machine reste plus simple à administrer. Elle évite aussi un trajet réseau supplémentaire pour chaque échange SQL entre machines.

Gardez le serveur de base proche de l'application sur un réseau privé. Séparer les deux ajoute des allers-retours réseau et une machine de plus à surveiller, sans diminuer pour autant les requêtes d'un module mal écrit. Pensez aussi à inclure le filestore dans votre plan de sauvegarde, même si PostgreSQL change de serveur : les deux doivent rester cohérents au moment de la restauration.

Ce qui reste à votre charge sur une plateforme#

Votre code garde le même coût CPU. Le mode d'hébergement change qui administre l'infrastructure. Le guide de l'hébergement Odoo compare les options ; la page des tarifs Ofleet décrit la facturation des ressources de la plateforme. Le prix d'Odoo par plan et par mode d'hébergement chiffre le coût de chaque option.

Sur votre serveur, vous gérez le système, PostgreSQL et les sauvegardes, en plus de vos modules. Sur Ofleet, vous pilotez vos instances et leur configuration en libre accès. Vous gardez la responsabilité de tester les développements spécifiques : logs et shell servent à comprendre pourquoi un traitement consomme, pas à le rendre moins coûteux sans modifier le code.

Questions fréquentes#

Combien de RAM pour Odoo avec 20 utilisateurs ?#

S'ils sont simultanés, le calcul présenté ici donne 4 workers HTTP et un cron, soit environ 1,6 Go pour ces workers avec les hypothèses d'Odoo. Ajoutez PostgreSQL, le système, le websocket et la marge pour les pointes. Si vous avez 20 comptes mais seulement quelques personnes actives ensemble, le point de départ est différent. Mesurez la simultanéité avant d'acheter.

Quelle version de PostgreSQL faut-il pour Odoo 20 ?#

La documentation Odoo 20 demande PostgreSQL 16 au minimum, contre 13 pour Odoo 19 et 12 pour Odoo 18. Une montée de version peut donc imposer un chantier PostgreSQL distinct du portage des modules. Vérifiez l'environnement cible, les extensions nécessaires et la restauration d'une copie avant de planifier la bascule de production.

Quel système d'exploitation choisir pour un serveur de production ?#

Retenez Linux pour le mode multi-process décrit dans cet article. Debian et Ubuntu sont des choix documentés pour l'installation, sous réserve de disposer des versions Python et PostgreSQL de votre branche. Windows convient aux tests locaux ; le serveur multi-process n'y est pas disponible. Vérifiez également les bibliothèques requises par vos modules et les rapports.

Faut-il un serveur dédié ?#

Pas nécessairement. Un VPS peut convenir si ses ressources et sa latence de stockage tiennent votre charge mesurée. Un serveur dédié se justifie si vous avez besoin d'isoler les ressources ou de maîtriser davantage la machine. Le nombre de comptes ne tranche pas : examinez les pointes, les traitements planifiés et la marge de croissance.

Pour vérifier votre calcul, faites tourner les imports et rapports de votre projet sur une instance de test. Vous pouvez essayer Ofleet, consulter les logs et comparer vos traitements avant de choisir les ressources de production.