Dimensionnement du serveur pour ERP : comment bien faire les choses

Le dimensionnement du serveur pour l’ERP fait partie de ces décisions qui semblent techniques mais qui ont des conséquences commerciales importantes. Sous-dimensionnez votre serveur et vous obtenez des plaintes en matière de performances dès le premier jour : chargements de pages lents, délais d'attente lors des pics d'utilisation et blocages de bases de données en cas de charge simultanée. Si vous le surdimensionnez, vous dépenserez beaucoup plus que nécessaire pour une infrastructure qui reste pour la plupart inutilisée.

La plupart des implémentations ERP comportent des erreurs de dimensionnement des serveurs dans l'une des deux directions suivantes : des équipes informatiques trop confiantes dont la taille est basée sur l'intuition "c'est juste une application Web" sans tenir compte de l'intensité de la base de données de l'ERP, ou des recommandations de fournisseurs calibrées pour des performances maximales à tout prix plutôt que des performances appropriées à un coût raisonnable.

Ce guide vous propose une approche structurée du dimensionnement des serveurs pour les déploiements ERP : les variables clés qui déterminent les besoins en ressources, les directives de dimensionnement spécifiques aux principales plates-formes ERP pour différents nombres d'utilisateurs et comment utiliser le calculateur de dimensionnement de serveur gratuit d'ECOSIRE pour modéliser votre situation spécifique.

Points clés à retenir

L'ERP nécessite beaucoup plus de bases de données que les applications Web classiques : les règles standard de dimensionnement des serveurs Web ne s'appliquent pas.

Le CPU est rarement la contrainte ; La RAM et les E/S disque constituent presque toujours le goulot d'étranglement des charges de travail ERP.

Odoo nécessite 2 à 4 Go de RAM par processus de travail simultané ; au moins 16 Go pour les instances de production comptant plus de 50 utilisateurs

Les exigences d'IOPS en matière de stockage de base de données sont considérablement sous-estimées dans la plupart des exercices de dimensionnement des serveurs.

Les instances cloud qui semblent équivalentes sur papier (même vCPU, même RAM) peuvent avoir des performances d'E/S très différentes - Toujours dimensionner en fonction de la charge simultanée maximale (et non de la charge moyenne) avec une marge de 30 à 40 %

Utilisez le calculateur de dimensionnement de serveur gratuit d'ECOSIRE pour générer une spécification pour votre nombre d'utilisateurs spécifique et votre plate-forme ERP.

Pourquoi le dimensionnement du serveur ERP est différent

Avant de plonger dans des recommandations spécifiques, il convient de comprendre pourquoi le dimensionnement du serveur ERP nécessite une analyse plus minutieuse que le dimensionnement d’une application Web classique.

Intensité de la base de données : les systèmes ERP sont fondamentalement des systèmes de traitement des transactions. Chaque action de l'utilisateur (création d'un bon de commande, publication d'une facture, déplacement de stock) génère plusieurs écritures dans la base de données qui doivent être validées de manière atomique. La couche de base de données gère des requêtes relationnelles complexes sur de grands schémas normalisés, souvent avec plusieurs jointures de tables et calculs agrégés. Ceci est très différent d'un système de gestion de contenu ou d'un site Web marketing, qui peut lire quelques tableaux dénormalisés par page vue.

Modèles de charge utilisateur simultanés : le comportement des utilisateurs ERP est plus simultané que celui des applications Web classiques. Sur un site Web grand public, les utilisateurs naviguent de manière indépendante avec des interactions peu fréquentes. Dans un système ERP, plusieurs utilisateurs d'un même service peuvent traiter simultanément les commandes pendant les heures de pointe (fin de mois, fin de journée, fermeture d'équipe). Ce modèle d'écriture simultanée crée un conflit de verrouillage de base de données qu'une application Web classique ne rencontre jamais.

Charge de travail de génération de rapports : les rapports ERP (en particulier les rapports financiers, l'ancienneté des stocks et la prévision de la demande) exécutent des requêtes complexes multi-tables qui peuvent s'exécuter pendant 30 à 120 secondes et consommer une quantité importante de CPU et d'E/S pendant l'exécution. Lorsque trois membres du personnel financier exécutent tous simultanément les rapports de clôture de fin de mois, le pic de charge qui en résulte peut être important.

État de session et processus de travail : Odoo exécute spécifiquement des processus de travail Python qui maintiennent l'état de session pour chaque connexion utilisateur active. Chaque processus de travail consomme environ 200 à 400 Mo de RAM en régime permanent et jusqu'à 1 Go lors d'une exécution intensive de rapports. Le serveur a besoin de suffisamment de RAM pour exécuter tous les travailleurs actifs simultanément sans basculer sur le disque : l'échange dans un serveur de base de données ERP entraîne une dégradation catastrophique des performances.

Variables clés dans le dimensionnement du serveur ERP

Quatre variables déterminent plus que toutes les autres les besoins en ressources du serveur ERP :

1. Nombre d'utilisateurs simultanés (et non nombre total d'utilisateurs)

Le nombre total d’utilisateurs est un mauvais indicateur des besoins en ressources. La bonne mesure est le pic d'utilisateurs simultanés : le nombre d'utilisateurs qui font activement des requêtes au système en même temps pendant la période la plus chargée de la journée.

Estimation du pic d'utilisateurs simultanés à partir du nombre total d'utilisateurs :

ERP de bureau avec horaires de travail normaux : 15 à 25 % du total des utilisateurs sont simultanés en période de pointe
Fabrication avec plusieurs équipes : 25 à 35 % du total des utilisateurs simultanés (pics de changement d'équipe)
Opérations distribuées sur plusieurs fuseaux horaires : concurrence de pointe plus faible mais durée de pointe plus longue
Utilisation intensive en fin de mois : pic temporaire à 40–50 % simultanément pendant les périodes de fermeture

Pour un déploiement Odoo de 100 utilisateurs avec une utilisation normale au bureau, prévoyez 15 à 25 utilisateurs simultanés en période de pointe typique, avec une provision pour 40 à 50 utilisateurs simultanés en fin de mois. Cela devrait déterminer votre calcul de taille, et non le total de 100 utilisateurs.

2. Volume des transactions et complexité des transactions

Des volumes de transactions élevés entraînent la charge d’écriture de la base de données indépendamment des utilisateurs simultanés. Une société de distribution qui traite 2 000 bons de commande par jour génère beaucoup plus d’E/S d’écriture dans la base de données qu’une entreprise de services professionnels comptant 100 utilisateurs mais un faible volume de transactions. De même, les transactions complexes (ordres de travail de fabrication qui mettent à jour simultanément la consommation de la nomenclature, les stocks, la comptabilité analytique et les enregistrements de qualité) génèrent plus d'E/S que les transactions simples (une écriture de journal qui met à jour deux comptes généraux).

Estimez la complexité de vos transactions en réfléchissant aux modules utilisés : les stocks de fabrication et multi-entrepôts génèrent les transactions les plus complexes ; les modules simples de comptabilité et de ressources humaines génèrent le plus simple.

3. Taille de la base de données et taux de croissance

La taille de la base de données affecte les performances des requêtes de deux manières : directement (les tables plus volumineuses prennent plus de temps à analyser) et indirectement (les jeux de travail qui dépassent la RAM disponible entraînent des échecs de cache et une augmentation des E/S).

Les bases de données ERP croissent plus rapidement que ne le prévoient la plupart des équipes informatiques. Une base de données de départ de 20 Go peut atteindre 100 Go en deux à trois ans avec une croissance normale de l'historique des transactions, des pièces jointes et des journaux d'audit. Dimensionnez votre stockage en fonction de trois années de croissance attendue, et pas seulement des besoins actuels.

4. Charge de travail d'intégration et d'API

Si votre ERP se connecte à des systèmes externes via API (plateforme de commerce électronique, système 3PL, API bancaires, connecteurs de place de marché), ces intégrations génèrent une charge de serveur supplémentaire qui ne se reflète pas dans le nombre d'utilisateurs. Chaque appel d'API passe par la couche d'application et la base de données de l'ERP : une intégration à grand volume (traitant 1 000 demandes de synchronisation de commandes par heure) peut correspondre à la charge de 10 à 20 utilisateurs simultanés.

Directives de dimensionnement par plate-forme et nombre d'utilisateurs

Odoo 19 Entreprise

L'architecture d'Odoo utilise des processus de travail (Odoo Workers) qui répondent chacun aux demandes des utilisateurs. Le nombre de travailleurs et les ressources de serveur requises évoluent en fonction du nombre d'utilisateurs simultanés.

Calcul du travailleur Odoo :

Travailleurs recommandés = (utilisateurs simultanés / 6) + 1, arrondi à l'unité supérieure
Chaque collaborateur nécessite environ 300 à 500 Mo de RAM en régime permanent, jusqu'à 1 Go lors de rapports volumineux
Les travailleurs Cron (pour les processus en arrière-plan) ajoutent 2 à 4 travailleurs supplémentaires

Spécifications minimales recommandées par nombre d'utilisateurs :

Nombre total d'utilisateurs	Pic simultané	Travailleurs	CPU (cœurs)	RAM	Stockage SSD
10-25	3-6	3	4	8 Go	100 Go
25-50	6-12	4	4	16 Go	200 Go
50-100	12-25	6	8	32 Go	300 Go
100-200	25-50	10	16	64 Go	500 Go
200-400	50-100	18	32	128 Go	1 To
400+	100+	30+	48+	256 Go+	2 To+

Remarques importantes sur le dimensionnement d'Odoo :

La base de données (PostgreSQL) et l'application (processus de travail Odoo) fonctionnent idéalement sur des serveurs distincts au-dessus de 100 utilisateurs. Réunies sur un seul serveur, la base de données et l'application se disputent la RAM.
La mémoire partagée PostgreSQL (effective_cache_size) doit être définie sur 50 à 75 % de la RAM du serveur de base de données.
Le stockage SSD est obligatoire pour le répertoire de données PostgreSQL — la rotation du disque entraîne des performances catastrophiques sur n'importe quelle base de données ERP.
Un serveur Redis distinct pour le stockage de session Odoo est recommandé pour les déploiements de plus de 50 utilisateurs.

Microsoft Dynamics 365 Business Central

Business Central est hébergé dans le cloud sur l'infrastructure Microsoft Azure lors de l'utilisation du modèle de déploiement SaaS. Dans ce cas, le dimensionnement du serveur est géré par Microsoft. Pour les déploiements sur site :

Nombre total d'utilisateurs	Pic simultané	CPU (cœurs)	RAM	RAM du serveur SQL	Stockage
10-25	3-6	4	16 Go	8 Go	150 Go
25-75	6-18	8	32 Go	16 Go	300 Go
75-150	18-37	16	64 Go	32 Go	500 Go
150-300	37-75	32	128 Go	64 Go	1 To

Business Central sur site utilise SQL Server comme base de données, qui dispose d'un modèle de gestion de la mémoire distinct de PostgreSQL. Allouez de la RAM dédiée au pool de tampons de SQL Server (via le paramètre max server memory) : environ 75 % de la RAM du serveur de base de données.

SAP Business One

SAP Business One est déployé sur site (Windows ou HANA) ou sur SAP Business One Cloud :

Nombre total d'utilisateurs	Pic simultané	Processeur	RAM (SAP HANA)	RAM (SQL Serveur)	Stockage
Jusqu'à 25	6-10	8 cœurs	64 Go	32 Go	500 Go
25-75	15-25	16 cœurs	128 Go	64 Go	1 To
75-150	25-50	32 cœurs	256 Go	128 Go	2 To

SAP HANA (la base de données en mémoire utilisée avec l'édition SAP Business One HANA) a des besoins en RAM beaucoup plus élevés que les bases de données sur disque traditionnelles, car l'ensemble de travail doit tenir dans la mémoire. Les exigences en matière de RAM pour HANA ne sont pas négociables : HANA qui manque de mémoire plante et ne se dégrade pas.

## Recommandations d'instances cloud

Lors de l'auto-hébergement d'un ERP sur AWS, Azure ou GCP, la sélection du bon type d'instance est très importante. Toutes les instances avec le même nombre de processeurs virtuels et de RAM ne fonctionnent pas de manière équivalente pour les charges de travail de base de données.

Recommandations AWS pour Odoo (application combinée + base de données, moins de 100 utilisateurs) :

t3.xlarge (4 vCPU, 16 Go) : Développement et petite production (moins de 25 utilisateurs)
r6i.xlarge (4 vCPU, 32 Go) : petite et moyenne production (25 à 50 utilisateurs)
r6i.2xlarge (8 vCPU, 64 Go) : production moyenne (50 à 100 utilisateurs)
r6i.4xlarge (16 vCPU, 128 Go) : grande production (100 à 200 utilisateurs, combinés)

Recommandations AWS pour Odoo (application divisée/base de données, plus de 100 utilisateurs) :

Serveur d'applications : c6i.2xlarge (8 vCPU, 16 Go) — optimisé pour le calcul
Serveur de base de données : r6i.4xlarge (16 vCPU, 128 Go) — mémoire optimisée
Stockage de base de données : volumes EBS io2 (IOPS provisionnées) – 3 000 à 6 000 IOPS provisionnées

Équivalents Azure :

Serveur d'applications : Standard_F8s_v2 (8 vCPU, 16 Go)
Serveur de base de données : Standard_E16s_v5 (16 vCPU, 128 Go)

Équivalents GCP :

Serveur d'applications : c2-standard-8 (8 vCPU, 32 Go)
Serveur de base de données : n2-highmem-16 (16 vCPU, 128 Go)

Le piège des performances d'E/S : les volumes EBS gp3 standard sur AWS fournissent 3 000 IOPS par défaut. Pour une base de données ERP de production comptant plus de 50 utilisateurs simultanés, cela s'avère souvent insuffisant, en particulier lors de la clôture de fin de mois, lorsque plusieurs rapports complexes sont exécutés simultanément. Utilisez des volumes IOPS provisionnés io2 pour le stockage de la base de données, avec un minimum de 3 000 IOPS provisionnées. La différence de coût est significative (0,065 $/Go/mois pour gp3 contre 0,125 $/Go/mois pour io2 plus 0,065 $/IOPS/mois pour les IOPS provisionnées), mais la différence de performances est également significative.

Architecture haute disponibilité

Pour les systèmes ERP de production où les temps d'arrêt ont un impact commercial significatif, envisagez une architecture à haute disponibilité qui offre une résilience contre les pannes d'un seul serveur.

Architecture HA minimale pour Odoo (100+ utilisateurs) :

Deux serveurs d'applications derrière un équilibreur de charge (sessions round-robin ou sticky)
Base de données principale PostgreSQL avec une réplique de secours (utilisant la réplication en streaming ou AWS RDS Multi-AZ)
Cluster Redis (deux nœuds) pour le stockage de session
Stockage de fichiers partagés (AWS EFS ou équivalent) pour les données des pièces jointes d'Odoo

Cette architecture offre une résilience contre toute panne de serveur unique sans nécessiter d'intervention manuelle. Le basculement du PostgreSQL principal vers le serveur de secours est automatique (à l'aide de Patroni ou AWS RDS) et s'effectue généralement en 30 à 60 secondes.

Cibles RPO et RTO pour un ERP typique :

Objectif de point de récupération (perte de données maximale) : 5 minutes (avec réplication synchrone) à 30 minutes (avec réplication asynchrone)
Objectif de temps de récupération (temps d'arrêt maximum) : 30 à 60 secondes pour le basculement automatique, 15 à 30 minutes pour la récupération manuelle

Utilisation du calculateur de dimensionnement du serveur ECOSIRE

Le calculateur de dimensionnement de serveur gratuit d'ECOSIRE à l'adresse /tools/server-sizing-calculator automatise le processus de calcul décrit ci-dessus. Entrées :

Sélection de la plateforme ERP
Nombre total d'utilisateurs
Pourcentage maximal d'utilisateurs simultanés (ou estimation automatique basée sur le cas d'utilisation)
Volume de transactions (faible, moyen, élevé, très élevé)
Nombre et volume d'intégration (aucun, basique, modéré, intensif)
Exigences de disponibilité (serveur unique, haute disponibilité, reprise après sinistre)
Préférence du fournisseur de cloud (AWS, Azure, GCP ou sur site)

Sorties :

Spécifications de serveur recommandées pour les niveaux d'application et de base de données
Recommandations d'instances cloud spécifiques pour votre fournisseur préféré
Estimation mensuelle des coûts d'infrastructure
Projection de croissance sur trois ans indiquant quand vous devrez effectuer une mise à niveau
Exigences d'IOPS de stockage et niveau de stockage recommandé

Le calculateur est calibré sur les propres données de déploiement de production d'ECOSIRE sur des dizaines d'implémentations client, ce qui rend les estimations plus fiables que la seule documentation du fournisseur.

Questions fréquemment posées

Comment estimer le pic d'utilisateurs simultanés si nous n'avons jamais utilisé un ERP auparavant ?

Pour les nouvelles implémentations sans données historiques, utilisez 20 % du nombre total d'utilisateurs comme estimation de départ pour un déploiement de bureau normal. Si vous avez plusieurs équipes ou travaillez sur plusieurs fuseaux horaires, utilisez 25 à 30 %. Ajoutez ensuite une marge de croissance de 50 % au cours des deux premières années. Pour un ERP de 100 utilisateurs avec des heures de bureau normales, prévoyez 20 utilisateurs simultanés en période de pointe typique, prévoyez-en 30 et développez la capacité pour atteindre 40 sans modifications de l'infrastructure. Cette approche de marge évite les problèmes de performances à mesure que l’adoption s’améliore dans les mois suivant la mise en service.

Devrions-nous exécuter l'application et la base de données Odoo sur le même serveur ou sur des serveurs distincts ?

Pour les déploiements de moins de 50 utilisateurs, un seul serveur combiné convient généralement : les charges de travail des applications et des bases de données à cette échelle n'entrent généralement pas en conflit. Pour 50 à 100 utilisateurs, la décision dépend des modèles d'utilisation : si la base d'utilisateurs est répartie uniformément tout au long de la journée, sans périodes de pointe significatives, un serveur combiné peut toujours fonctionner. En cas de pics importants (fin de mois, clôture d'équipe), des serveurs d'applications et de bases de données séparés assurent une meilleure isolation. Au-dessus de 100 utilisateurs, des serveurs distincts sont fortement recommandés.

Quel type de stockage devons-nous utiliser pour la base de données Odoo ?

Le stockage SSD est obligatoire pour le répertoire de données PostgreSQL — le disque tournant (HDD) produit des performances inacceptables sur n'importe quelle base de données ERP de production. Sur les plates-formes cloud, utilisez le SSD IOPS provisionné (AWS io2, Azure Premium SSD v2, GCP Extreme Persistent Disk) pour le stockage de la base de données si vous avez plus de 50 utilisateurs simultanés. Les disques SSD à usage général (AWS gp3, Azure Standard SSD) sont acceptables pour les déploiements de développement et de petite production de moins de 25 utilisateurs simultanés.

Quelle marge devrions-nous intégrer dans le dimensionnement de notre serveur ?

Prévoyez une marge de 30 à 40 % au-dessus de votre charge de pointe prévue pour les opérations normales, et une marge de 100 % (le double de la capacité de pointe) pour les périodes exceptionnelles comme la clôture de fin de mois ou les périodes de pointe des ventes. Les déploiements cloud peuvent utiliser la mise à l'échelle automatique pour gérer des périodes exceptionnelles sans payer pour cette capacité de manière permanente : un avantage de coût significatif par rapport à une infrastructure fixe sur site.

Prochaines étapes

Utilisez le calculateur de dimensionnement de serveur gratuit d'ECOSIRE sur /tools/server-sizing-calculator pour générer une spécification pour votre déploiement spécifique. Le calculateur génère une recommandation d'instance AWS/Azure/GCP et une estimation mensuelle des coûts d'infrastructure que vous pouvez utiliser pour la planification budgétaire.

Si vous planifiez une mise en œuvre d'Odoo et souhaitez qu'ECOSIRE gère le dimensionnement et la configuration de l'infrastructure parallèlement à la mise en œuvre, la planification de l'infrastructure est incluse dans chaque engagement de mise en œuvre d'ECOSIRE.

Server Sizing for ERP: How to Get It Right