Veille Odoo : trois mises à jour, et les journaux d'un serveur

Un comptable exporte le Grand livre auxiliaire en Excel pour un contrôle et constate que les cellules à zéro sont vides. Il n'a rien fait de travers : l'export de plusieurs versions d'Odoo avait ce défaut, corrigé les 2 et 3 octobre. C'est l'un des trois changements de la semaine du vendredi 2 au jeudi 8 octobre 2026 que j'ai retenus dans le dépôt odoo/enterprise. Le conseil d'exploitation qui suit concerne les serveurs hébergés chez vous : où vont les journaux d'Odoo, comment les faire tourner sans casser l'écriture, et comment les lire avant que quelqu'un vous appelle.

Trois mises à jour de la semaine

Les régularisations de stock affichent enfin leur coût

Les listes de régularisation de l'application Comptabilité, sous Comptabilité > Révision > Ventes (« Factures à émettre » et « Facturé, non livré »), n'affichaient que le montant du chiffre d'affaires. Un commit du 2 octobre ajoute deux colonnes optionnelles, un coût unitaire et un coût total. Le coût total se calcule ainsi : (quantité livrée à la date − quantité facturée à la date) × coût du produit. Le message du commit donne la raison : une marchandise livrée et non facturée, ou facturée et non livrée, a un effet sur la valeur du stock, et la liste ne le montrait pas.

Le gain concret se voit à la clôture. Quand le rapport de valorisation du stock ne tombe pas juste avec la comptabilité, on pouvait chercher longtemps l'écart entre la livraison et la facture. Un point de prudence : le calcul prend le coût inscrit sur la fiche produit, pas les couches de valorisation. Pour un produit en coût moyen ou en FIFO, vérifiez que ce coût est à jour avant de vous fier à la colonne. Cette évolution est présente dans la branche 20.0 et pas dans la 19.0. Les deux libellés de colonnes ne sont pas encore traduits en français dans le dépôt.

Retrouver les écritures de régularisation depuis la commande

Le deuxième commit, du même jour, part d'un constat que tous les comptables connaissent : une écriture de régularisation peut être générée depuis une commande, depuis un rapport ou autrement, et on ne sait plus ensuite laquelle correspond à quoi. Les commandes de vente et d'achat reçoivent un bouton « Accrual Entries » (écritures de régularisation) qui ouvre les écritures liées. Deux réserves : le bouton n'apparaît qu'en mode développeur, et seulement s'il existe au moins une écriture. Un commit complémentaire rend en outre cliquables les lignes de régularisation du rapport de valorisation du stock, qui renvoient vers la liste filtrée correspondante.

Ces deux ajouts ne changent aucun calcul. Ils raccourcissent le temps de justification, donc de réponse au commissaire aux comptes ou à l'expert-comptable qui demande d'où vient un montant. Ils sont, eux aussi, dans la 20.0. Ils s'ajoutent à une bonne sauvegarde de la base, qui reste le filet de sécurité d'une clôture.

Les zéros reviennent dans les exports Excel des rapports

Dans le code de l'export XLSX des rapports comptables, une cellule dont la valeur était 0 était remplacée par une chaîne vide. Le commit corrige la condition pour ne vider que les cellules sans valeur. Le message du commit prend pour exemple le Grand livre auxiliaire, mais le code est commun à tous les rapports de l'application Comptabilité. La correction a été reportée le 2 et le 3 octobre sur les branches saas-19.2, saas-19.3, saas-19.4 et 20.0, ainsi que sur la branche de développement.

Pourquoi cela compte : une cellule vide et une cellule à zéro ne se comportent pas pareillement dans un tableur. Un test sur les cellules vides, une recherche, un tableau croisé dynamique ou un contrôle « cette ligne est-elle à zéro ? » donnent des résultats différents. Si vous alimentez un fichier de consolidation depuis ces exports, il faut refaire l'export après la mise à jour, car les anciens fichiers ne se corrigent pas. En Online, la correction suit la mise à jour de votre version ; sur Odoo.sh et sur site, il faut mettre à jour le code de la branche concernée. D'après le code, la 19.0 utilise un autre chemin d'export et n'est pas concernée par cette ligne ; je ne l'ai pas testé sur une base.

Où vont les journaux de votre Odoo, et comment les faire tourner

Quand Odoo tourne chez vous, c'est vous qui répondez à la question « qu'est-ce qui s'est passé hier à 14 h ? ». Sans journal lisible, la réponse est un haussement d'épaules. Sur Online, vous n'avez pas ce réglage, et sur Odoo.sh les journaux se consultent depuis l'interface de la branche ; ce qui suit concerne donc le sur site. Par défaut, tout part sur la sortie standard

Sans option, Odoo écrit sur la sortie d'erreur, ce qui convient en développement. En production, deux choix existent : laisser un service systemd capter la sortie (le journal du système la conserve), ou demander un fichier avec l'option logfile. Le paquet Debian d'Odoo choisit le fichier : le service lance Odoo avec --logfile /var/log/odoo/odoo-server.log. Si vous avez installé depuis les sources, vérifiez dans votre fichier /etc/odoo/odoo.conf ou dans votre unité systemd que le cas est réglé, sans quoi vos journaux sont peut-être perdus au redémarrage.

La rotation : le fichier suit le renommage

Un fichier de journal que personne ne fait tourner finit par remplir le disque, ce qui, si la partition est partagée avec la base, arrête PostgreSQL et Odoo en même temps. Le paquet Debian fournit une règle logrotate avec copytruncate, qui copie le fichier puis le vide. Cela fonctionne partout, mais les lignes écrites entre la copie et le vidage peuvent être perdues.

Le code d'Odoo 20.0 offre mieux. Sous Linux, le fichier de journal est ouvert avec un gestionnaire (WatchedFileHandler) qui détecte qu'il a été renommé ou supprimé et rouvre un nouveau fichier. Une rotation classique par renommage fonctionne donc sans redémarrer Odoo ni tronquer. Voici une règle à placer dans /etc/logrotate.d/odoo, à adapter à vos chemins et à votre utilisateur :

/var/log/odoo/*.log {
    daily
    rotate 30
    compress
    delaycompress
    missingok
    notifempty
    create 0640 odoo adm
}

Trente jours de journaux compressés suffisent le plus souvent à remonter un incident signalé tardivement. Si vos obligations internes ou votre politique RGPD fixent une durée de conservation, c'est elle qui décide, pas ce chiffre.

Vérifier la rotation avant d'en avoir besoin

1. Lancez logrotate -d /etc/logrotate.d/odoo : l'option -d simule et affiche ce qui serait fait.
2. Forcez une rotation sur un serveur de recette avec logrotate -f /etc/logrotate.d/odoo.
3. Ouvrez une session dans Odoo, puis lancez ls -l /var/log/odoo/ : le nouveau fichier doit grossir et l'ancien (suffixe .1) doit rester figé.

Si l'ancien fichier continue de grossir, le processus écrit toujours dans l'ancien : cherchez un lancement d'Odoo qui n'utilise pas l'option logfile, ou un mode de rotation qui ne correspond pas à ce que le code attend. Je n'ai pas testé cette règle sur un serveur : faites la vérification ci-dessus avant de supprimer copytruncate en production.

Le niveau de détail et la lecture quotidienne

Le niveau par défaut est info. Les niveaux debug_sql, debug_rpc ou debug multiplient le volume, et debug_rpc_answer enregistre aussi les réponses des appels, avec le risque d'y retrouver des données personnelles. Servez-vous-en pour un diagnostic ciblé, puis revenez à info.

Une ligne de journal suit le format : date, heure, numéro de processus, niveau, base, composant, message. Ce petit filtre donne chaque matin les erreurs les plus fréquentes de la veille, ce qui suffit à repérer un module qui tombe en erreur en boucle :

zcat -f /var/log/odoo/odoo-server.log.1 | awk '$4=="ERROR" || $4=="CRITICAL" {print $6}' | sort | uniq -c | sort -rn | head

Il compte les erreurs par composant. Si un composant revient des centaines de fois, ouvrez le fichier à cet endroit. Notez enfin que l'option syslog est déclarée obsolète depuis Odoo 20 : le message l'indique, et recommande l'option log-config, qui accepte un fichier de configuration de journalisation (JSON, et TOML en 20.0). Si vous envoyez vos journaux à un serveur central par syslog, prévoyez ce changement avant votre montée de version, que vous pouvez préparer avec le comparatif des modes d'hébergement en main.

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.

Sources

• odoo/odoo, branche 20.0, odoo/netsvc.py (gestionnaire de fichier, option obsolète) (consulté le 09/10/2026) : Lire le fichier
• odoo/odoo, branche 20.0, debian/odoo.service et debian/logrotate (consulté le 09/10/2026) : Lire le fichier
• Documentation Odoo 20.0, interface en ligne de commande, section Logging (consulté le 09/10/2026) : Lire la documentation
• Commits odoo/enterprise des 2 et 3 octobre 2026.