Une instance Odoo qui fonctionne bien pendant deux ans finit par ralentir, et personne ne sait pourquoi : la base a triplé, les pièces jointes sont dupliquées, les messages s'accumulent, et une action planifiée échoue en silence depuis trois semaines.
Seize modules communautaires outillent l'exploitation d'une instance.
Résumé
Quatre modules traitent le volume : la taille par modèle mesurée et journalisée chaque jour, le réglage de l'autovacuum PostgreSQL sur les tables qui accumulent des lignes mortes, des règles de purge des anciens messages et pièces jointes, et la désactivation de l'indexation du contenu des pièces jointes.
Trois modules traitent les sauvegardes et les pièces jointes : des sauvegardes planifiées en local et vers un serveur distant en SFTP, la restriction de la suppression des pièces jointes par niveau, et le nettoyage des boîtes de messagerie entrantes.
Quatre modules traitent les erreurs et les sessions : l'envoi d'un courriel quand une action planifiée échoue, la remontée vers Sentry des erreurs applicatives, le stockage des sessions en base pour les déploiements à plusieurs serveurs, et le filtrage des bases par en-tête HTTP du proxy.
Cinq modules enfin traitent l'inventaire et la migration : l'analyse du code installé par auteur et par type — cœur Odoo, OCA, développement interne —, l'analyse de migration comparant deux bases, la liste des modules auto-installables modifiable par configuration, et l'enregistrement des hôtes distants qui se connectent.
L'essentiel
- La taille disque par modèle, mesurée chaque jour.
- Des sauvegardes planifiées en local et en SFTP.
- Des règles de purge des messages et pièces jointes anciens.
- L'autovacuum PostgreSQL réglé sur les tables à lignes mortes.
- Un courriel quand une action planifiée échoue.
- Les erreurs remontées vers Sentry.
- Les sessions stockées en base pour plusieurs serveurs.
- Le code installé analysé par auteur : cœur, OCA, interne.
Ce que ces modules ajoutent à l'instance
| Famille | Modules | Nombre |
|---|---|---|
| Volume | database_size, database_autovacuum_tuning, autovacuum_message_attachment, attachment_unindex_content | 4 |
| Sauvegardes et pièces jointes | auto_backup, attachment_delete_restrict, mail_cleanup | 3 |
| Erreurs et sessions | scheduler_error_mailer, sentry, session_db, dbfilter_from_header | 4 |
| Inventaire et migration | module_analysis, upgrade_analysis, module_change_auto_install, base_remote | 4 |
Les menus : Paramètres ▸ Technique ▸ Database Size et ses deux vues, Structure de la base de données ▸ Sauvegardes automatisées et Database Autovacuum Tuning, E-mail ▸ Règle de suppression des messages, Paramètres ▸ Upgrade Analysis et ses cinq sous-menus, Paramètres ▸ Remotes, et une section d'analyse sous Applications.
Savoir où part le volume
La question « pourquoi ma base Odoo pèse 40 Go » a presque toujours la même réponse, et ce n'est jamais celle qu'on croit : ce sont les messages, les pièces jointes indexées deux fois, et les lignes mortes qu'un autovacuum mal réglé n'a jamais nettoyées.
database_size mesure et journalise chaque jour la taille de chaque modèle : tables, index, tables de relation, pièces jointes. Deux vues permettent de voir la taille par modèle et de comparer son évolution.
C'est l'outil qui transforme une impression en diagnostic : on voit quel modèle a grossi, et de combien, semaine après semaine.
autovacuum_message_attachment(LGPL-3) définit des règles de purge des anciens messages et pièces jointes, sous Paramètres ▸ Technique ▸ E-mail ▸ Règle de suppression des messages.attachment_unindex_contentdésactive l'indexation du contenu des pièces jointes par Odoo — qui duplique les données entre le fichier et la base.database_autovacuum_tuning(LGPL-3) ajuste les seuils d'autovacuum PostgreSQL sur les tables accumulant trop de lignes mortes.
Le réglage de l'autovacuum est le geste d'administration qui donne le gain le plus spectaculaire sur une instance ancienne : les tables de messages et de mouvements de stock subissent des millions de mises à jour, et les seuils par défaut de PostgreSQL ne sont pas conçus pour cela.
Les sauvegardes et les pièces jointes
auto_backup configure et planifie des sauvegardes automatiques de la base, en local et vers un serveur distant en SFTP — donc à travers un tunnel chiffré. Menu sous Sauvegardes automatisées.
C'est le module à installer sur toute instance qui n'est pas hébergée par un prestataire gérant les sauvegardes. Et même dans ce cas, une sauvegarde applicative supplémentaire ne coûte rien.
attachment_delete_restrictrestreint la suppression des pièces jointes par niveau. Le standard n'impose aucune restriction : quiconque peut écrire sur un document peut en supprimer les pièces.mail_cleanupajoute aux serveurs de messagerie entrants la possibilité de marquer comme lus, déplacer ou supprimer les messages plus anciens qu'un nombre de jours donné. Il dépend du module de configuration de messagerie par environnement.
La restriction de suppression des pièces jointes est un contrôle de conservation : une facture fournisseur scannée, supprimée par erreur six mois plus tard, n'existe plus nulle part si la pièce était l'original.
Les erreurs et les sessions
scheduler_error_mailer envoie un courriel quand une action planifiée échoue.
Une action planifiée en échec est silencieuse dans Odoo : elle se désactive au bout de quelques tentatives, et personne ne le sait. La facturation récurrente qui ne part plus, les relances qui ne sortent plus, l'import bancaire qui s'est arrêté : tous se découvrent par leurs conséquences.
sentry connecte le serveur à un service de collecte et d'agrégation d'erreurs : chaque erreur atteignant un niveau de journal donné y est envoyée.
session_db(LGPL-3) stocke les sessions HTTP en base PostgreSQL au lieu de fichiers sur disque. Conçu pour les déploiements à plusieurs serveurs, où un utilisateur ne doit pas perdre sa session en changeant de nœud.dbfilter_from_headerfiltre la liste des bases accessibles à partir d'un en-tête HTTP envoyé par le proxy inverse — nginx, Caddy, Apache —, en complément du filtre de configuration.
Le dernier est la bonne façon de servir plusieurs bases depuis un même serveur : le proxy décide, l'application obéit.
Savoir ce qui est installé
module_analysis analyse le code des modules installés pour savoir combien vient du cœur d'Odoo, de l'OCA, ou de développements internes. Il apporte un référentiel d'auteurs, de types de modules et de règles d'affectation, plus une vue par type.
La proportion de code sur mesure dans une instance est l'indicateur le plus prédictif de son coût de migration. Une instance à 5 % de développement interne monte de version en quelques jours ; à 40 %, c'est un projet.
upgrade_analysis outille la préparation d'une migration : il compare la structure et les données d'une base locale avec celles d'une base distante, et produit les fichiers d'analyse. Cinq sous-menus sous Paramètres ▸ Upgrade Analysis.
module_change_auto_installpermet de modifier par configuration la liste des modules marqués auto-installables, sans toucher aux manifestes.base_remoteenregistre chaque hôte distant qui se connecte au serveur — adresse externe et nom d'hôte s'il est résolvable — dans un modèle consultable sous Paramètres ▸ Remotes.
Le dernier sert au diagnostic et à la sécurité : savoir d'où viennent les connexions est la première chose qu'on regarde après un comportement suspect.
Limites connues
- Les purges de messages et de pièces jointes sont irréversibles : définir les règles avec la durée de conservation légale en tête, pas avec le volume.
attachment_unindex_contentdésactive la recherche dans le contenu des pièces jointes : c'est le prix du gain de volume.- Le réglage de l'autovacuum touche PostgreSQL : à faire avec l'administrateur de base, sur des tables identifiées, pas globalement.
auto_backupstocke un mot de passe SFTP dans la configuration, donc dans la base : préférer une authentification par clé si le module le permet, et vérifier les droits sur l'enregistrement.- Une sauvegarde applicative n'est pas une sauvegarde système : elle ne contient pas le système de fichiers des pièces jointes si celles-ci sont hors base.
sentryenvoie des traces d'erreur à un service externe : ces traces peuvent contenir des données. Vérifier la configuration de filtrage et le lieu d'hébergement du service.session_dbchange le stockage des sessions : une déconnexion générale est à prévoir à l'activation.upgrade_analysisse connecte à une base distante en RPC : à n'utiliser que vers une base de travail, jamais vers une production.
Identité technique
Les seize modules viennent du dépôt OCA server-tools, branche 18.0 — 56 modules au total. Treize sont en AGPL-3, trois en LGPL-3. Les dépendances : base et base_setup pour la plupart, mail pour les sauvegardes, les purges et les alertes, web pour le filtrage de bases et les hôtes distants, mail_environment pour le nettoyage de messagerie. session_db n'a aucune dépendance.
Voir aussi journaliser, tracer et auditer et les briques techniques du serveur pour le reste du dépôt.
Questions fréquentes
Pourquoi ma base Odoo pèse-t-elle 40 Go ?
database_size répond précisément : il mesure et journalise chaque jour la taille de chaque modèle — tables, index, relations, pièces jointes — avec une vue de comparaison. La réponse est presque toujours la même : les messages, les pièces jointes indexées deux fois, et les lignes mortes qu'un autovacuum mal réglé n'a jamais nettoyées.
Comment purger les anciens messages et pièces jointes ?
autovacuum_message_attachment définit des règles de purge sous Paramètres ▸ Technique ▸ E-mail ▸ Règle de suppression des messages. Attention : ces purges sont irréversibles. Définissez les règles avec la durée de conservation légale en tête, pas avec le volume.
Comment savoir qu'une action planifiée a échoué dans Odoo ?
Par défaut, on ne le sait pas : elle se désactive au bout de quelques tentatives, en silence. scheduler_error_mailer envoie un courriel à chaque échec. La facturation récurrente arrêtée, les relances qui ne sortent plus, l'import bancaire interrompu se découvrent sinon par leurs conséquences.
Peut-on sauvegarder une base Odoo automatiquement vers un serveur distant ?
Oui : auto_backup planifie des sauvegardes en local et en SFTP. Deux réserves : le mot de passe SFTP est stocké en base, et une sauvegarde applicative ne contient pas le système de fichiers des pièces jointes si celles-ci sont stockées hors base.
Comment estimer le coût de migration d'une instance Odoo ?
module_analysis analyse le code installé par auteur et par type — cœur Odoo, OCA, développement interne. La proportion de code sur mesure est l'indicateur le plus prédictif : à 5 %, une montée de version prend quelques jours ; à 40 %, c'est un projet. upgrade_analysis outille la préparation elle-même.
Se faire accompagner
L'exploitation d'une instance Odoo se joue sur trois mesures que personne ne met en place au démarrage : la taille par modèle, l'échec des actions planifiées, et la part de code sur mesure. Les trois se posent en une demi-journée et évitent chacune un incident coûteux.
Nous installons donc ces trois mesures dès la mise en service, avec les sauvegardes et les règles de purge, et nous reprenons le réglage de l'autovacuum PostgreSQL sur les tables identifiées. Une base dont on connaît la croissance ne surprend pas. Voir les prestations d'Atalios Consulting ou demander un rappel.
Pour aller plus loin
En résumé
Une instance Odoo qui fonctionne bien pendant deux ans finit par ralentir sans qu'on sache pourquoi : la base a triplé, les pièces jointes sont dupliquées, et une action planifiée échoue en silence depuis trois semaines. Seize modules outillent l'exploitation. Parlons de votre instance.
