Configurer Odoo : réglages, profils et redémarrage

Ajuster les workers, les limites et le SMTP d'un environnement - pourquoi enregistrer n'est pas appliquer, pourquoi un nombre de workers relève du calcul et non du goût, et quelles clés la plateforme ne vous laissera jamais définir.

Vérifié le 13 août 2026

L'onglet Configuration est l'odoo.conf de votre environnement, moins les parties qui ne vous appartiennent pas. C'est là que vous décidez combien de workers servent les requêtes, combien de temps une requête peut durer, et par où part le courrier sortant.

Deux habitudes rendent cet onglet sûr : lire la bannière de redémarrage, et traiter le nombre de workers comme un calcul plutôt que comme une préférence.

Ce que vous pouvez régler, et ce qui reste à la plateforme

Seules les clés d'une liste blanche sont modifiables ici. Tout ce qui en sort est refusé — pas masqué derrière un avertissement : refusé.

L'onglet Configuration : la bannière de redémarrage, les configurations suggérées, et la section Performance et limites avec Workers HTTP et Threads cron, chacun affichant sa clé et ses bornes. — Chaque champ porte sa clé technique en dessous et sa plage acceptée à côté : une valeur qui sera refusée se voit avant d'être enregistrée.

Les clés que possède la plateforme sont les identifiants de base de données, les chemins de fichiers, les ports et les interrupteurs de sécurité qui empêchent un environnement d'atteindre les données d'un autre. Elles sont écrites par le système et l'emportent, quoi que l'on définisse.

Un réglage peut aussi être en lecture seule pour votre environnement en particulier : le profil avec lequel il a été créé restreint encore la liste blanche. Ces réglages restent affichés, marqués, plutôt que de disparaître — un réglage que vous ne pouvez pas changer mérite d'être connu, et sa valeur mérite d'être lue.

Chaque champ affiche sa clé technique en dessous (workers, limit_time_cpu) — celle que vous chercherez dans la documentation d'Odoo — et ses bornes à côté. Ces bornes sont revérifiées à l'enregistrement.

Les profils de dimensionnement

Au-dessus des réglages figurent quatre configurations suggérées, et la ligne à leur droite nomme le gabarit pour lequel elles ont été calculées : le CPU et la mémoire de cet environnement, pas un tableau générique.

Les quatre configurations suggérées - Équilibré, Nombreux utilisateurs simultanés, Imports et traitements longs, Développement - calculées pour 2 vCPU / 2 GiB, avec Équilibré sélectionné et une note indiquant que les champs ont été remplis mais que rien n'a encore été modifié. — Un profil remplit les champs et s'arrête là. La note le dit explicitement, car un formulaire qui s'est rempli tout seul ressemble exactement à un formulaire qui s'est enregistré tout seul.

Profil	Pour
Équilibré	Une journée de travail normale.
Nombreux utilisateurs simultanés	Plus de workers, limites de requête plus courtes.
Imports et traitements longs	Limites longues, pour qu'un gros import ne soit pas coupé en cours de route.
Développement	Mode threadé : un seul processus, donc un point d'arrêt stoppe bien ce que vous déboguez.

Cliquer sur l'un d'eux remplit les champs et s'arrête là. Rien n'est enregistré, rien ne redémarre, et le panneau le dit. Relisez les valeurs, puis enregistrez vous-même — le clic qui enregistre est celui qui redémarrera l'Odoo de quelqu'un, et il vous appartient.

Les valeurs proposées sont en outre ramenées dans les bornes de chaque réglage et revalidées avant même de vous être montrées : un profil ne peut donc pas remplir le formulaire avec quelque chose qui échouera à l'envoi.

Pourquoi le nombre de workers est un calcul

Trop peu de workers et les requêtes font la queue pendant que des cœurs restent inactifs. Trop et chacun reçoit une part de mémoire trop petite pour charger une page. Les deux se ressentent comme « Odoo est lent » et se corrigent en sens inverse.

Les limites de mémoire sont la partie qui mérite d'être comprise. Odoo applique limit_memory_soft et limit_memory_hard à lui-même : un worker qui dépasse la limite souple termine sa requête en cours puis se recycle, proprement. La plateforme, elle, applique la limite mémoire de l'environnement à l'ensemble d'un coup, et elle ne demande rien : elle tue le processus.

C'est pourquoi les profils ne répartissent qu'environ quatre cinquièmes de la mémoire de l'environnement entre les processus. Cette marge fait toute la différence entre un worker qui se recycle et un environnement tué pour dépassement mémoire. Si vous réglez ces valeurs à la main, gardez la même marge : dimensionner la limite d'Odoo pour qu'elle rejoigne exactement celle de l'environnement, c'est ainsi qu'un environnement se met à redémarrer sous charge.

Un environnement tué sur la mémoire se voit comme un compteur de redémarrages qui monte sur l'onglet Métriques, sans rien dans les journaux : le processus a été terminé, il n'a pas échoué. Le guide sur les logs et les métriques explique comment le lire.

Enregistrer n'est pas appliquer

C'est le point qui piège tout le monde.

Enregistrer écrit vos valeurs. L'Odoo en cours d'exécution continue de servir avec les anciennes tant que l'environnement n'a pas redémarré, et la bannière en haut de l'onglet le dit précisément aussi longtemps que c'est vrai.

La bannière ambre « Les changements enregistrés ne sont pas encore appliqués - redémarrez pour les appliquer », avec un bouton Redémarrer pour appliquer à côté. — Enregistré et appliqué sont deux états différents. La bannière existe parce que rien d'autre à l'écran ne les distingue.

Redémarrer pour appliquer s'en charge, et c'est un vrai redémarrage : l'environnement est brièvement indisponible. C'est pour cela que c'est un bouton distinct plutôt qu'un effet de l'enregistrement — vous choisissez le moment.

Vider un champ le remet par défaut

Il n'y a pas de bouton « revenir au défaut », et il n'en faut pas : videz le champ puis enregistrez, et le réglage retourne à la valeur par défaut de la plateforme au lieu d'être défini à une chaîne vide.

C'est la sortie sûre d'une valeur dont vous n'êtes plus certain. C'est aussi bon à savoir avant de vider un champ que vous vouliez seulement retaper.

Les paramètres personnalisés

Sous le catalogue, des paires clé/valeur libres pour les réglages qui appartiennent à vos propres modules — ceux qu'aucun catalogue générique ne peut lister.

Le bloc des paramètres personnalisés : deux lignes, acme_margin_alert_ratio = 0.15 et acme_portal_theme = light, au-dessus d'une explication indiquant que les clés réservées ou dangereuses sont refusées à l'enregistrement. — Libres, mais pas sans garde-fou : le refus survient à l'enregistrement, en nommant la clé.

Ils sont écrits dans la configuration de l'environnement exactement tels que saisis, et lus par votre module comme n'importe quel autre paramètre Odoo. La même règle de redémarrage s'applique.

Ce bloc n'apparaît que si le profil de votre environnement l'autorise.

Ce qui est refusé, et pourquoi

Trois familles de clés sont écartées à l'enregistrement, et le message nomme la clé plutôt que d'échouer vaguement :

Les clés possédées par la plateforme — base de données, chemins, ports, sécurité. Les définir d'ici pourrait pointer un environnement vers les données d'un autre.
Tout ce qui se termine par _path ou _db — des pointeurs vers le système de fichiers ou une base, refusés en famille plutôt qu'un par un, car les dangereux sont ceux que personne n'a pensé à lister.
addons_path en particulier, qui mérite sa propre réponse : il est dérivé de votre dépôt au moment du build, une entrée par répertoire contenant réellement des modules. Le déclarer à la main est l'habitude normale en auto-hébergement, alors on l'essaie ici d'abord et on en conclut que la plateforme ne sait pas charger son arborescence. Elle le sait — c'est exactement ce que le build fait pour vous.

Si une valeur est refusée pour dépassement de plage, ce sont les bornes affichées à côté du champ qui s'appliquent. Elles sont revérifiées côté serveur : un navigateur qui vous laisse taper 40 workers n'est pas une autorisation d'en avoir 40.