Si votre Odoo tourne sur un serveur que vous louez ou que vous administrez, il existe très probablement une page de gestion des bases que personne chez vous n'a jamais ouverte. Elle est joignable depuis Internet tant que vous ne l'avez pas fermée, et la documentation d'Odoo la décrit comme un outil de développement qui n'a rien à faire en production. Avant d'y venir, voici les trois mises à jour de la semaine du vendredi 30 octobre au jeudi 5 novembre 2026 qui m'ont paru utiles à une PME française sur l'Enterprise.
Trois mises à jour de la semaine
Un rejet de la télédéclaration de TVA ne plante plus en multi-sociétés
Dans le module l10n_fr_reports d'odoo/enterprise, quand l'administration rejette l'export EDI d'une déclaration de TVA, Odoo crée automatiquement une activité « À faire » pour prévenir quelqu'un. Le correctif des 3 et 4 novembre traite un cas de base multi-sociétés : la recherche de l'écriture de clôture pouvait renvoyer plusieurs enregistrements pour la même période, et le code, qui en attendait un seul, s'arrêtait sur une erreur. Dans ce cas, l'activité n'était pas créée, et le rejet risquait de passer inaperçu, ce qui est le pire scénario pour une échéance fiscale.
Deux autres changements viennent avec le même commit. L'activité est désormais rattachée à la déclaration elle-même, plutôt qu'à l'écriture de clôture. Elle est aussi attribuée à l'utilisateur qui a lancé l'export, et non plus au compte système qui exécute l'action planifiée, ce qui évitait que le rappel reste dans une boîte que personne ne lit. Le correctif est disponible en 20.0 et sur la branche de développement. Si vous gérez plusieurs sociétés avec télédéclaration, il justifie une mise à jour de votre branche Enterprise avant la prochaine échéance de TVA.
La création de la déclaration fiscale française pouvait lever une erreur
Toujours dans l10n_fr_reports, un contrôle sur le libellé des crédits d'impôt de la section III du formulaire 2069-RCI avait été retiré, puis remis par une modification ultérieure. Selon le message du commit, cette remise provoquait une erreur à la création de la déclaration fiscale française. Le commit du 3 novembre retire de nouveau ce contrôle, en 20.0 comme sur la branche de développement.
Je ne sais pas dire à partir du code combien d'utilisateurs ont réellement rencontré l'erreur ; le message ne le précise pas. Si vous avez vu une fenêtre d'erreur en ouvrant une déclaration sur une base 20.0 récente, c'est probablement lui, et la mise à jour de la branche la règle. Sinon, rien à faire.
SEPA : un paiement hors euro est refusé à l'enregistrement
Dans account_sepa_direct_debit et account_iso20022, un commit du 4 novembre traite une règle simple : SEPA ne fonctionne qu'en euros, et une banque rejette tout paiement dans une autre devise. Jusqu'ici, le prélèvement SEPA affichait un avertissement mais laissait enregistrer le paiement. Le virement SEPA faisait l'inverse : il bloquait à l'enregistrement, sans prévenir avant. Désormais, le prélèvement est bloqué avec le message « SEPA only accepts payments in EUR », et le virement affiche un avertissement dès le choix de la méthode, y compris dans l'assistant d'enregistrement d'un paiement.
Ce correctif n'est pour l'instant que sur la branche de développement, pas en 20.0. Il concerne surtout les sociétés qui facturent en dollars ou en livres et qui choisissent un mode de règlement SEPA par habitude. Mon avis : c'est un bon garde-fou, qui évite de découvrir le problème au moment où la banque refuse le fichier.
Votre page de gestion des bases est-elle ouverte sur Internet ?
Odoo embarque un gestionnaire de bases, accessible par l'adresse /web/database/manager, qui permet de créer, dupliquer, sauvegarder, restaurer et supprimer des bases. Il est protégé par un mot de passe maître, le paramètre admin_passwd du fichier de configuration. La documentation d'Odoo 19 est sans ambiguïté : il est fortement recommandé de désactiver ce gestionnaire sur tout système exposé à Internet, parce qu'il est conçu comme outil de développement et de démonstration, qu'il n'est pas prévu pour la production et qu'il peut exposer des fonctions dangereuses. Elle ajoute qu'en production, la création de bases et les sauvegardes doivent être faites par l'administrateur système.
Ce conseil concerne les installations sur site et les serveurs que vous louez. En Online, Odoo gère cette partie, et sur Odoo.sh l'accès aux bases passe par la plateforme.
Pour savoir où vous en êtes, ces deux commandes suffisent. La première montre les paramètres de sécurité du fichier de configuration (le chemin /etc/odoo/odoo.conf est celui d'une installation par paquet, adaptez-le sinon). La seconde teste la page depuis l'extérieur.
grep -E "^(admin_passwd|list_db|db_name|dbfilter|proxy_mode)" /etc/odoo/odoo.conf curl -sI https://erp.exemple.fr/web/database/manager | head -1
Si la seconde commande répond « 200 », la page est servie à tout le monde. Cela ne signifie pas que quelqu'un peut entrer, le mot de passe maître reste demandé, mais la porte est visible, et un mot de passe maître resté à la valeur par défaut admin en ferait une porte ouverte. La documentation précise que le mot de passe maître d'une nouvelle installation est généré aléatoirement, mais que la base reste accessible à tous tant que ce mot de passe n'a pas été défini.
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.
La désactivation tient en un paramètre, mais elle a une condition que la documentation énonce clairement : Odoo doit savoir seul quelle base servir, sinon les utilisateurs se retrouvent bloqués puisqu'ils ne peuvent plus la choisir. Il faut donc renseigner db_name, ou un filtre dbfilter qui ne retient qu'une seule base pour le nom de domaine utilisé, puis passer list_db à False :
[options] db_name = ma_base dbfilter = ^ma_base$ list_db = False
Après un redémarrage du service, la liste des bases et les écrans de gestion disparaissent. Deux conséquences pratiques. Vous ne pourrez plus sauvegarder ni restaurer par le navigateur, ce qui est voulu : les sauvegardes doivent passer par un script, et la restauration d'essai que j'ai décrite dans un article de cet été se fait en ligne de commande. Et si vous aviez des utilisateurs qui passaient par le sélecteur de base, ils tomberont directement sur l'écran de connexion.
Si vous préférez garder les écrans accessibles à quelques postes, la documentation propose de bloquer au niveau du serveur web frontal toutes les adresses commençant par /web/database, sauf éventuellement le sélecteur. Avec Nginx, cela ressemble à ceci, à placer dans le bloc du site :
location ^~ /web/database/ {
allow 203.0.113.10; # remplacez par l'adresse de votre bureau ou de votre VPN
deny all;
}
Dans tous les cas, si les écrans restent joignables, remplacez admin_passwd par une valeur aléatoire longue. La documentation donne une commande Python pour en générer une de 32 caractères et rappelle de la conserver dans un endroit sûr.
Et les mots de passe des utilisateurs ?
La même page de documentation rappelle que les attaques par force brute sur les mots de passe sont courantes sur un Odoo exposé. Chaque tentative de connexion écrit une ligne dans le journal avec l'identifiant visé et l'adresse source, ce qui permet à un outil comme fail2ban de bloquer l'adresse fautive. Voici le filtre et la prison proposés par la documentation : quinze minutes de blocage après dix échecs en une minute depuis la même adresse.
# /etc/fail2ban/filter.d/odoo-login.conf [Definition] failregex = ^ \d+ INFO \S+ \S+ Login failed for db:\S+ login:\S+ from <HOST> ignoreregex = # /etc/fail2ban/jail.d/odoo-login.conf [odoo-login] enabled = true port = http,https bantime = 900 maxretry = 10 findtime = 60 logpath = /var/log/odoo/odoo.log
Deux réserves. Le chemin du journal doit être celui de votre installation, et il faut que Odoo écrive bien dans un fichier (paramètre logfile). Je vous conseille donc de faire échouer volontairement dix connexions depuis un poste de test pour vérifier que le blocage se déclenche, et de vous assurer que votre propre adresse de bureau n'est pas bloquée un lundi matin à cause d'un collègue qui a oublié son mot de passe. La sécurisation du certificat, elle, est traitée dans l'article sur le renouvellement HTTPS.
Mon avis, au bout du compte : sur un serveur sur site, list_db = False est le réglage à faire en premier, parce qu'il coûte une ligne et ferme la page la plus sensible. Le filtre fail2ban vient ensuite, et il vaut le détour seulement si quelqu'un lit les alertes.
Sources
- Documentation Odoo 19.0, déploiement sur site : sécurité, gestionnaire de bases, mot de passe maître et force brute (consulté le 06/11/2026) : Lire la documentation
- odoo/enterprise, module
l10n_fr_reports, commits des 3 et 4/11/2026 (rejet de l'export EDI de TVA en multi-sociétés) - odoo/enterprise, module
l10n_fr_reports, commit du 3/11/2026 (contrôle des crédits d'impôt de la déclaration) - odoo/enterprise, modules
account_sepa_direct_debitetaccount_iso20022, commit du 4/11/2026 (paiements SEPA hors euro)