Un utilisateur supprime six mois de pièces jointes pour libérer de la place, et le soir même le disque du serveur Odoo affiche le même taux de remplissage. Ce n'est pas un bug : la suppression dans Odoo et la libération du fichier sur le disque sont deux opérations distinctes, séparées par une tâche planifiée. Trois mises à jour de la semaine d'abord, puis la place disque d'un Odoo hébergé chez vous et la façon de la mesurer avant qu'elle ne manque.
Trois mises à jour de la semaine (16 au 22 octobre 2026)
Le règlement groupé de plusieurs factures fournisseurs se rapproche à nouveau tout seul
Vous créez trois factures d'un même fournisseur, vous en sélectionnez deux et vous les payez avec l'option « Grouper les paiements ». Le relevé de banque arrive avec un libellé qui cite les références des deux factures, le bon partenaire et le montant négatif du total. Le rapprochement automatique aurait dû lier la ligne de relevé aux deux factures. Il ne le faisait pas, parce qu'une condition de calcul compare un solde cumulé à zéro et ne tient pas compte du signe : pour un paiement sortant, le solde est toujours négatif et la boucle s'arrête après la première facture. Le correctif prend la valeur absolue en compte (module account_accountant d'odoo/enterprise, application Comptabilité, donc Enterprise uniquement). Il est présent dans la 19.0, dans les versions intermédiaires 19.1 à 19.4, dans la 20.0 et dans la branche de développement.
Si vous payez vos fournisseurs par virements groupés, rejouez ce cas sur une copie de base après la mise à jour. Il se distingue des modèles décrits dans l'article sur les règles de rapprochement bancaire : c'est le rapprochement par référence qui est en cause.
La liste des montants à régler ne perd plus de lignes quand on change la date
Depuis le rapport de balance âgée, on ouvre la liste des montants à régler d'un partenaire, puis on modifie le filtre de date « ouvert au » dans la barre de recherche. Des écritures bien ouvertes disparaissaient. La date du rapport était écrite en dur dans le domaine de l'action ; en ajoutant la date choisie à l'écran, on obtenait deux conditions contradictoires sur la même date, et la requête ne renvoyait plus rien d'exploitable. Le commit retire la date en dur et la transmet comme filtre de recherche par défaut, que l'utilisateur peut donc modifier (module account_reports d'odoo/enterprise). Il figure dans la 20.0 et la saas-19.4. La 19.0 n'a pas le même code à cet endroit, et je ne sais pas dire si elle montrait le même symptôme.
Si vous avez constaté des lignes manquantes après un changement de date, comparez avec le total du rapport avant de conclure à une erreur de saisie.
Un tableau des flux de trésorerie par la méthode indirecte arrive en 20.0
Le commit du 19 octobre ajoute un nouveau rapport, « Indirect Cash Flow Statement », dans les modules account_reports et account_asset d'odoo/enterprise. Il part du résultat net, ajoute les corrections non monétaires (amortissements, provisions, plus et moins-values de cession, écarts de change latents, résultat financier), puis les variations du besoin en fonds de roulement : créances clients, dettes fournisseurs, stocks, produits constatés d'avance. Il est présent dans la 20.0 et dans la branche de développement, pas dans la 19.0 ni dans les versions 19.x intermédiaires.
Le rapport lit des balises posées sur les comptes. Le commit complémentaire d'odoo/odoo, « Add account tags for Indirect Cash Flow Report », ajoute ces balises au plan comptable générique, au plan belge et au plan américain. Je n'y vois aucun plan français. Mon avis : avant de présenter ce tableau à un banquier ou à un commissaire aux comptes, vérifiez balise par balise que vos comptes de classe 1 à 5 sont bien rattachés ; sans cela, le rapport sera incomplet sans prévenir.
Où part la place disque d'un Odoo sur site
Un Odoo hébergé chez vous occupe de la place à trois endroits : la base PostgreSQL, le dossier des fichiers joints (le filestore) et les sauvegardes que vous y déposez. Les deux premiers grossissent avec l'usage, le troisième avec votre politique de conservation. Ce qui suit vaut pour Odoo 19.0 Community ou Enterprise sur un serveur Linux. En Online et sur Odoo.sh, l'espace est géré par l'éditeur et ne se mesure pas de cette façon.
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.
Mesurer avant d'agir
Le filestore se trouve dans le dossier de données d'Odoo, sous filestore/nom_de_la_base. L'emplacement dépend de l'option data_dir du fichier de configuration et de l'utilisateur système qui lance Odoo. Commencez par la taille globale, puis celle du filestore :
df -h grep data_dir /etc/odoo/odoo.conf du -sh /chemin/du/data_dir/filestore/*
Côté PostgreSQL, deux requêtes en lecture seule donnent l'essentiel. La première liste les dix plus grosses tables avec leurs index, la seconde répartit les pièces jointes par modèle de document :
SELECT c.relname, pg_size_pretty(pg_total_relation_size(c.oid)) FROM pg_class c JOIN pg_namespace n ON n.oid = c.relnamespace WHERE n.nspname = 'public' AND c.relkind = 'r' ORDER BY pg_total_relation_size(c.oid) DESC LIMIT 10; SELECT res_model, count(*), pg_size_pretty(sum(file_size)::bigint) FROM ir_attachment GROUP BY res_model ORDER BY sum(file_size) DESC NULLS LAST LIMIT 10;
Je n'ai pas de répartition type à vous donner : elle dépend de vos usages, des PDF générés, des emails entrants et des documents stockés. Les candidats habituels sont la table des pièces jointes et celle des messages (mail_message), à vérifier chez vous. Notez ces mesures chaque mois : une croissance se lit sur trois relevés, jamais sur un seul.
Pourquoi supprimer ne libère pas tout de suite
Quand on supprime une pièce jointe, Odoo retire la ligne de la table ir_attachment et inscrit le nom du fichier dans une liste de contrôle. Le fichier lui-même est effacé plus tard par une méthode de nettoyage du filestore, appelée par la tâche planifiée « Base: Auto-vacuum internal data ». Dans les données du module base, cette tâche est réglée sur un passage par jour. Le nettoyage verrouille la table des pièces jointes en lecture partagée pendant l'opération, avec un délai d'attente de dix secondes : si le verrou n'est pas obtenu, il abandonne et reviendra à un autre passage.
Le même passage vide d'autres tables techniques. Les messages du bus de notifications sont conservés vingt-quatre heures par défaut (paramètre système bus.gc_retention_seconds). Les notifications de messagerie lues par des utilisateurs internes sont supprimées au bout de cent quatre-vingts jours. Si la tâche planifiée est désactivée, ou si elle échoue chaque nuit, rien de tout cela ne part : vérifiez-la avec la méthode décrite dans l'article sur la surveillance des actions planifiées.
PostgreSQL ne rend pas l'espace au système
Côté base, la logique est la même en plus subtile. Supprimer des lignes ne réduit pas les fichiers de PostgreSQL : le VACUUM ordinaire, que l'autovacuum de PostgreSQL lance seul, rend l'espace réutilisable dans la même table mais, selon la documentation, ne le restitue pas au système d'exploitation dans la plupart des cas. Une base nettoyée garde donc sa taille, mais grossit moins vite ensuite.
La tentation, quand le disque est plein, est de lancer VACUUM FULL sur la plus grosse table. C'est l'erreur à éviter. Cette commande réécrit la table dans un nouveau fichier, elle pose un verrou exclusif (plus personne ne lit ni n'écrit dans la table pendant ce temps) et, d'après la documentation PostgreSQL, elle demande de la place supplémentaire puisque l'ancienne copie n'est libérée qu'à la fin. Sur un disque à 95 %, elle peut échouer faute de place pour la copie. Si vous devez la lancer, vérifiez que le disque peut accueillir une seconde copie de la table, faites-le hors des heures de travail, après une sauvegarde restaurée avec succès (voir comment tester une restauration).
Mon seuil et ma règle pour les sauvegardes
Je règle l'alerte à 80 % de remplissage, pas à 95 %. Entre les deux, vous avez le temps d'agrandir le volume ; au-delà, chaque opération de maintenance devient risquée. Quant aux sauvegardes, elles ne devraient pas vivre sur le disque qui porte la base : une copie de la base et du filestore stockée au même endroit fait doubler l'occupation et disparaît avec le serveur. Le principe de la copie hors machine est exposé dans l'article sur la sauvegarde d'une base Odoo.
Sources
- odoo/odoo, branche 19.0,
odoo/addons/base/models/ir_attachment.py(nettoyage du filestore) (consulté le 23/10/2026) : Lire le fichier - odoo/odoo, branche 19.0,
odoo/addons/base/data/ir_cron_data.xml(tâche « Base: Auto-vacuum internal data ») (consulté le 23/10/2026) : Lire le fichier - odoo/odoo, branche 19.0,
addons/bus/models/bus.pyetaddons/mail/models/mail_notification.py(conservation) (consulté le 23/10/2026) : Lire le fichier - odoo/odoo, commit des balises du flux de trésorerie indirect (consulté le 23/10/2026) : Lire le commit
- Documentation PostgreSQL, commande VACUUM (consulté le 23/10/2026) : Lire la documentation
- Commits odoo/enterprise des modules
account_accountantetaccount_reports, du 19 au 21 octobre 2026.