Un Odoo sur site qui ralentit vers 10 heures, quand tout le monde est connecté, n'a pas forcément besoin d'un serveur plus gros. Il a souvent besoin d'être réglé. Par défaut, Odoo démarre dans un mode multi-thread pensé pour le développement, et une installation qui n'a jamais été réglée tourne encore ainsi. Le conseil d'exploitation de cette semaine donne une méthode de calcul et la façon de vérifier le résultat. Avant cela, voici trois correctifs publiés entre le vendredi 18 et le jeudi 24 septembre, tous sur la branche 19.0 : deux dans le dépôt public odoo/odoo, un dans le dépôt odoo/enterprise.
Trois correctifs de la semaine
Recrutement : les pièces jointes des candidats parrainés ne fuient plus
Avec le module de parrainage, un salarié qui recommande un candidat obtient un accès limité à sa candidature, sans pouvoir l'ouvrir s'il n'en est pas l'intervieweur. Pourtant, le bouton des pièces jointes de la fiche du poste listait les documents de toutes les candidatures de ce poste, y compris celles que l'utilisateur ne devait pas voir : il pouvait donc télécharger le CV d'un candidat qu'il avait parrainé. Le correctif du 23 septembre en 19.0 filtre ces pièces jointes selon les droits réels de l'utilisateur. Pour une PME qui utilise le parrainage, c'est un correctif de protection des données personnelles à appliquer sans attendre.
Factur-X : le nom de l'acheteur n'est plus vide
Dans le fichier Factur-X généré par Odoo, le nom de l'acheteur reprenait le nom du contact de facturation. Quand l'adresse de facturation d'un client est un contact sans nom propre, ce champ pouvait rester vide. Le correctif du 21 septembre en 19.0 reprend dans ce cas le nom de la société cliente. Avec la facturation électronique, un champ obligatoire vide peut conduire au rejet d'une facture : si vous utilisez des adresses de facturation sans nom, vérifiez le XML d'une facture récente.
Rapprochement automatique : majuscules et minuscules ne bloquent plus
Le rapprochement bancaire automatique de l'Enterprise cherche dans le libellé du virement la référence de la facture. Jusqu'ici, la comparaison tenait compte de la casse : un client qui écrivait « inv/2026/00123 » au lieu de « INV/2026/00123 » laissait une ligne de relevé à rapprocher à la main. Le correctif du 22 septembre, dans le module account_accountant, ignore désormais les majuscules et les minuscules dans cette comparaison. Les libellés de virement sont saisis par vos clients, souvent sur un téléphone, et rarement recopiés à l'identique : ce changement devrait réduire la pile des lignes à traiter le lundi matin.
Dimensionner les workers d'un Odoo sur site
Avant d'appliquer ces conseils : testez chaque manipulation sur une copie de votre base ou sur un serveur de test, jamais directement en production. Ces conseils sont rédigés sans connaître votre configuration et peuvent ne pas s'appliquer tels quels chez vous. Nexelans ne peut pas être tenue responsable des conséquences d'une manipulation faite sans ces précautions.
Ce conseil concerne les installations sur vos serveurs. En Online et sur Odoo.sh, ces réglages sont gérés par Odoo.
Passer en multi-processus
La documentation de déploiement d'Odoo 19 est explicite : le serveur multi-thread, actif par défaut, sert surtout au développement et aux démonstrations, et une limite de Python l'empêche de tirer parti de tout le matériel. Le serveur multi-processus est celui de la production. Il s'active en donnant au paramètre workers une valeur non nulle. Il n'existe que sous Linux.
Calculer le nombre de workers
La documentation donne deux repères, qu'il faut croiser :
- un maximum théorique de (nombre de cœurs × 2) + 1 workers ;
- environ six utilisateurs simultanés par worker.
Son exemple : un serveur de quatre cœurs et soixante utilisateurs simultanés. Le besoin théorique est de 60 / 6 = 10 workers, le maximum de (4 × 2) + 1 = 9. Odoo retient huit workers HTTP et un pour les actions planifiées, avec une surveillance de la charge processeur. Notez que le paramètre max_cron_threads, qui fixe le nombre de workers dédiés aux actions planifiées, vaut 2 par défaut et s'ajoute aux workers HTTP.
Attention au mot « simultanés ». Une PME de soixante utilisateurs nommés n'a presque jamais soixante utilisateurs qui cliquent au même instant. Comptez ceux qui travaillent réellement en même temps aux heures de pointe, pas les licences.
Calculer la mémoire
La même page propose une estimation : 20 % de requêtes lourdes, à environ 1 Go par worker, et 80 % de requêtes légères, à environ 150 Mo. Pour neuf workers, on obtient 9 × ((0,8 × 150) + (0,2 × 1 024)), soit environ 3 Go pour Odoo seul. Ajoutez la mémoire de PostgreSQL et du système : sur un serveur unique, la base de données doit avoir sa propre part, faute de quoi elle ira chercher sur le disque ce qu'elle aurait dû garder en mémoire.
Deux limites protègent le serveur. limit_memory_soft recycle un worker à la fin de sa requête s'il dépasse le seuil ; limit_memory_hard l'arrête immédiatement. D'après la référence de la ligne de commande, elles valent par défaut 2 048 Mio et 2 560 Mio. L'exemple de la documentation de déploiement les abaisse nettement, à 600 Mio et 1 600 Mio environ, ce qui recycle plus tôt les workers gourmands.
Régler les délais
limit_time_cpu limite le temps processeur d'une requête, et limit_time_real sa durée totale, requêtes SQL comprises. Les valeurs par défaut de la ligne de commande sont de 60 et 120 secondes ; l'exemple de la documentation de déploiement monte à 600 et 1 200 secondes. Des délais trop courts tuent les exports, les clôtures et les gros rapports ; des délais trop longs laissent une requête bloquer un worker. Partez de l'exemple de la documentation, puis ajustez en lisant les journaux.
Ne pas oublier proxy_mode
Une installation de production passe par un proxy inverse, Nginx par exemple, qui gère le HTTPS. Dans ce cas, activez proxy_mode = True pour qu'Odoo utilise les vraies informations du client (nom d'hôte, protocole, adresse IP) et non celles du proxy. La documentation précise qu'il ne faut l'activer que derrière un proxy. En multi-processus, le proxy doit aussi rediriger les chemins commençant par /websocket/ vers le worker dédié à la messagerie instantanée.
Vérifier après réglage
- Redémarrez Odoo et vérifiez dans les journaux le démarrage des workers HTTP et des workers d'actions planifiées.
- Aux heures de pointe, surveillez la charge processeur et la mémoire. La documentation vise, dans son exemple, une charge stable plutôt qu'un serveur saturé.
- Cherchez dans les journaux les workers tués pour dépassement de mémoire ou de temps : quelques-uns sont normaux, des dizaines par heure signalent une limite trop basse ou un traitement à optimiser.
- Faites tourner un export volumineux et la génération d'un gros rapport PDF pour vérifier que les délais suffisent.
Ces réglages ne remplacent pas une base saine. Avant de modifier la configuration, assurez-vous d'avoir une sauvegarde testée, comme le rappelle l'article sur la sauvegarde d'une base Odoo, et notez les valeurs d'origine pour pouvoir revenir en arrière.
Sources
- odoo/odoo, commit cc931f0 (23/09/2026), pièces jointes des candidats parrainés : Voir le commit
- odoo/odoo, commit c4c7821 (21/09/2026), nom de l'acheteur en Factur-X : Voir le commit
- odoo/enterprise, commit 124c6da (22/09/2026, branche 19.0), référence de paiement insensible à la casse
- Documentation Odoo 19.0, déploiement sur site (workers, mémoire, proxy) : Lire la page
- Documentation Odoo 19.0, référence de la ligne de commande (valeurs par défaut) : Lire la page