Le 15 du mois approche, la TVA est à déposer, et le rappel automatique d'Odoo arrive trois jours avant l'échéance au lieu de sept. C'est l'un des changements de la semaine du vendredi 23 au jeudi 29 octobre 2026 que j'ai retenus dans odoo/enterprise, avec un correctif sur le fichier de virements SEPA et un autre sur la liasse simplifiée 2033. Le conseil d'exploitation qui suit s'adresse à ceux qui font tourner Odoo sur leur propre serveur : les mises à jour de sécurité d'Ubuntu s'installent peut-être déjà toutes seules, mais ni PostgreSQL ni Odoo n'en font forcément partie.
Trois mises à jour de la semaine
Le rappel de déclaration de TVA arrive trois jours avant l'échéance
Dans le module account_reports de l'Enterprise, le rappel d'une déclaration fiscale à déposer partait jusqu'ici sept jours avant la date limite, vers tous les utilisateurs ayant le droit de gestionnaire de comptabilité sur la société concernée. Un commit du 27 octobre change les deux règles. Le rappel part désormais trois jours avant l'échéance, et il va d'abord aux adresses saisies dans un champ « Return Reminders » du journal des déclarations fiscales. Si ce champ est vide, Odoo retombe sur l'ancien comportement, tous les gestionnaires de comptabilité.
Mon avis : le délai raccourci est le point à surveiller. Pour une CA3 mensuelle, trois jours, c'est parfois un week-end, et c'est trop court pour réclamer une pièce manquante à un fournisseur. Ne comptez pas sur ce rappel comme seul filet : posez la date de dépôt dans l'agenda de la personne qui prépare la déclaration. Le champ dédié est en revanche une bonne nouvelle pour une PME dont le dirigeant, gestionnaire de comptabilité par défaut, recevait un message qui ne le concernait pas. D'après le code, l'adresse saisie doit correspondre à un utilisateur Odoo de la société pour recevoir le message ; vérifiez-le en provoquant un test avant l'échéance. Le même changement a été repris dans la branche 19.0 de l'Enterprise le 28 octobre.
Le fichier de virements SEPA ne mélange plus BIC et numéro de clearing
Dans account_iso20022, un compte bancaire qui portait à la fois un BIC et un numéro de clearing produisait un fichier de virements où la banque du bénéficiaire était identifiée de deux façons à la fois. Certaines banques rejettent un tel fichier, et le commit renvoie à la spécification du Conseil européen des paiements, qui n'autorise que le BIC pour la banque du créancier. Le correctif retire l'identifiant de clearing quand un BIC est renseigné, côté fournisseur comme côté banque émettrice.
Un fournisseur français n'a normalement pas de numéro de clearing, ce champ servant plutôt aux comptes étrangers. Vous êtes donc concerné si vous réglez des fournisseurs hors de France par lot SEPA, ou si vous avez rempli ce champ sur vos propres comptes. Le correctif est arrivé le 23 octobre en 19.0 et le 27 octobre en 20.0. Sur une base déjà à jour, un lot refusé par la banque sans explication mérite d'être regénéré avant de chercher ailleurs.
La liasse simplifiée 2033 retrouve ses salaires
C'est le correctif qui compte le plus pour un dirigeant ou un DAF. Dans l10n_fr_reports, les rapports 2033-A (bilan simplifié) et 2033-B (compte de résultat simplifié) comportaient plusieurs erreurs de formule, corrigées le 28 octobre. La ligne « Salaires et traitements » de la 2033-B pointait vers un compte 650 qui n'existe pas dans le plan comptable français : les comptes 641, 644 et 648 n'y étaient donc jamais reportés. La production immobilisée (compte 72) s'affichait mais n'entrait pas dans le sous-total des produits d'exploitation, ce qui minorait le résultat d'exploitation et le résultat de l'exercice. Les lignes financières omettaient certains mouvements passés directement sur les comptes 66 et 76, et le report à nouveau de la 2033-A comptait deux fois certains comptes.
Si vous avez extrait une liasse 2033 d'Odoo 20 ou de la version 19.4 avant cette date, comparez-la avec les balances de votre expert-comptable. Je n'ai pas retrouvé ces rapports dans la branche 19.0 du module, ce qui laisse penser que seules les bases en 19.4 et 20.0 sont concernées. Sur Odoo.sh et sur site, la correction suppose une mise à jour de la branche ou du paquet Enterprise.
Ubuntu se met à jour seul, PostgreSQL et Odoo pas forcément
Le conseil de la semaine part d'une question simple, que j'entends peu : quelqu'un sait-il ce qui s'installe la nuit sur votre serveur Odoo ? Sur Ubuntu, la documentation officielle indique que les mises à jour de sécurité s'appliquent automatiquement, sans intervention, par le paquet unattended-upgrades, installé par défaut. Il s'exécute une fois par jour. La bonne nouvelle s'arrête là, parce que trois limites changent la façon d'exploiter un serveur d'entreprise.
La première limite concerne l'origine des paquets. Par défaut, seuls les dépôts officiels d'Ubuntu sont pris en compte, et la documentation insiste sur un point : ajouter un autre dépôt ne suffit pas pour que ses mises à jour soient installées automatiquement. Si vous avez ajouté le dépôt officiel de PostgreSQL pour disposer d'une version plus récente, ou le dépôt nightly d'Odoo, leurs mises à jour ne partent pas seules. La documentation d'Odoo 19 le confirme à sa manière : pour garder une installation par dépôt à jour, elle recommande la commande habituelle apt-get upgrade, donc une action manuelle. Et pour l'édition Enterprise, il n'existe pas de dépôt nightly : le paquet se télécharge à la main sur le site d'Odoo. Autrement dit, un correctif de sécurité d'Odoo n'arrive jamais sans que quelqu'un le décide, ce qui me convient, mais à une condition : que ce quelqu'un existe et ait une date.
La deuxième limite est le redémarrage. Une mise à jour du noyau n'a d'effet qu'après un redémarrage, et l'option de redémarrage automatique est désactivée par défaut. Un serveur peut donc rester des mois sur un noyau corrigé sur disque et vulnérable en mémoire. La troisième tient au silence : sans adresse de messagerie configurée, aucun rapport n'est envoyé, et seuls les journaux du dossier /var/log/unattended-upgrades racontent ce qui s'est passé.
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 vaut pour un serveur que vous administrez. En Online et sur Odoo.sh, le système est géré par Odoo. Sur un serveur sur site, voici de quoi faire l'état des lieux en cinq minutes :
cat /etc/apt/apt.conf.d/20auto-upgrades systemctl list-timers apt-daily-upgrade.timer ls -lt /var/log/unattended-upgrades | head ls /var/run/reboot-required sudo unattended-upgrade --dry-run --debug
Le premier fichier doit contenir deux lignes à la valeur « 1 ». Le deuxième affiche la prochaine exécution. Le dossier de journaux doit avoir été modifié ces derniers jours. La présence du fichier reboot-required signale un redémarrage en attente. Quant à la dernière commande, elle simule une passe sans rien installer et liste les origines autorisées, ce qui permet de voir si votre dépôt PostgreSQL y figure.
Ma pratique, pour un serveur de PME avec Odoo et PostgreSQL sur la même machine : laisser les mises à jour de sécurité d'Ubuntu en automatique, renseigner l'option Unattended-Upgrade::Mail dans /etc/apt/apt.conf.d/50unattended-upgrades pour recevoir un rapport (elle demande qu'un client de messagerie léger soit configuré sur le serveur), et ne pas activer le redémarrage automatique tant que vous n'avez pas redémarré le serveur à la main, un soir, pour vérifier qu'Odoo et PostgreSQL repartent seuls. Si cet essai est concluant, l'option Automatic-Reboot-Time permet de fixer une heure, en heure locale du serveur, hors de la fenêtre de vos sauvegardes. Pour tout le reste, c'est-à-dire PostgreSQL hors dépôt Ubuntu et Odoo, fixez une fenêtre mensuelle, précédée d'une sauvegarde dont vous avez testé la restauration, comme on l'a vu pour la sauvegarde.
Dernier point d'attention : une mise à jour de PostgreSQL redémarre le service, et les utilisateurs connectés à ce moment peuvent voir une erreur ou un écran figé. La passe de nuit ne les gêne en principe pas, mais si votre société travaille tard ou à l'international, regardez l'heure d'exécution dans les journaux. Les questions de version de la base sont traitées dans l'article sur le choix de PostgreSQL pour Odoo 19, et celles du système dans celui sur Ubuntu 26.04.
Sources
- Documentation Ubuntu Server, mises à jour automatiques (consulté le 30/10/2026) : Lire la documentation
- Documentation Odoo 19.0, installation par paquets, dépôt et paquet de distribution (consulté le 30/10/2026) : Lire la documentation
- odoo/enterprise, module
account_reports, commit du 27/10/2026 (rappel de déclaration fiscale) - odoo/enterprise, module
account_iso20022, commits des 23 et 27/10/2026 (virements SEPA) - odoo/enterprise, module
l10n_fr_reports, commit du 28/10/2026 (liasse 2033)