Ces sept modules ne servent aucun utilisateur métier. Ils servent celui qui exploite l'instance — et ils répondent à des questions que nos clients posent dès la première semaine : « mes équipes vont-elles voir des publicités pour la version payante ? », « comment met-on à jour sans tout casser ? ».
Trois relèvent de la marque blanche, deux de la maintenance, deux de l'outillage de rapports. Un seul demande de la prudence, et il le dit lui-même.
Résumé
Sept modules qui ne servent aucun utilisateur métier : trois retirent les renvois commerciaux vers odoo.com — y compris sur le portail vu par vos clients —, deux outillent la maintenance, deux ajoutent les formats de rapport Excel et CSV.
Un seul demande de la prudence, et il le dit lui-même : database_cleanup est potentiellement destructeur et peut endommager l'intégrité des données. La purge des champs, colonnes et tables orphelines ne se fait jamais directement en production. Son assistant de création d'index, en revanche, est gratuit et sans risque.
L'essentiel
- Trois modules de marque blanche :
disable_odoo_online,remove_odoo_enterprise,portal_odoo_debranding— aucun renvoi commercial vers odoo.com, ni côté interne ni côté portail client. database_cleanup: purge des résidus de modules désinstallés. 18 modèles créés, 182 champs, 9 menus — et un avertissement du module lui-même : potentiellement destructeur.module_auto_update: empreinte SHA1 du contenu de chaque module, et mise à jour uniquement de ceux dont le code a changé.report_xlsxetreport_csv: deux types de rapport supplémentaires, sockets techniques pour d'autres modules.- Tous sous licence AGPL-3 ou LGPL-3, dépôts
server-brand,server-toolsetreporting-engine.
La marque blanche : trois modules, trois surfaces
C'est la question posée en avant-vente, et elle est légitime : une instance Community affiche par défaut des renvois vers odoo.com — documentation, support, compte, store d'applications, réglages « à débloquer », téléchargement de l'application mobile. Et le portail client porte une mention Odoo.
| Module | Surface traitée | Ce qu'il retire |
|---|---|---|
disable_odoo_online | Liens vers les services odoo.com | Le notifieur de mise à jour (Community uniquement), les menus du store d'applications, et les liens Documentation, Support et Mon compte Odoo.com du menu utilisateur |
remove_odoo_enterprise | Incitations à la version payante | Les réglages verrouillés « à débloquer » des Réglages généraux, le bloc de téléchargement de l'application mobile, et le filtrage des modules et fournisseurs de paiement marqués « à acheter » |
portal_odoo_debranding | Portail client (frontend) | La promotion de marque Odoo des pages consultées ou imprimées par vos clients |
Le troisième est celui qui compte le plus vis-à-vis de l'extérieur : les devis, factures et commandes consultés en ligne par vos clients ne portent plus de bandeau publicitaire d'un éditeur tiers. Il n'ajoute aucun champ ni modèle — deux vues modifiées, rien d'autre.
Le deuxième a un effet secondaire utile : en filtrant les modules et fournisseurs de paiement payants des listes, il évite qu'un utilisateur installe ou configure quelque chose qui ne fonctionnera pas sans licence. Ce n'est pas qu'une question d'image.
database_cleanup : le seul module du socle à manipuler avec prudence
Celui-ci est différent de tous les autres, et il faut le dire franchement : le module avertit lui-même qu'il est potentiellement destructeur et peut endommager l'intégrité des données.
Son objet est utile : une base Odoo accumule des résidus. Un module désinstallé laisse des modèles, des champs, des colonnes SQL ; une migration laisse des entrées ir.model.data pointant vers des ressources disparues ; un développement abandonné laisse des menus vers un modèle inexistant.
| Ce qu'il peut purger | Risque |
|---|---|
| Modules obsolètes | Faible |
| Modèles orphelins | Moyen |
| Champs orphelins | Élevé — un champ encore utilisé emporte ses données |
| Colonnes SQL orphelines | Élevé |
| Tables et vues SQL orphelines | Élevé |
Entrées ir.model.data mortes | Faible |
| Menus vers un modèle inexistant | Faible |
Il fournit par ailleurs un assistant complémentaire bien plus anodin et franchement utile : créer les index PostgreSQL manquants sur les champs marqués index=True. Sur une instance qui a vécu plusieurs montées de version, c'est un gain de performance gratuit.
La règle que nous appliquons : on n'exécute aucune purge sans une sauvegarde restaurable vérifiée, et jamais directement en production. La séquence est toujours la même — restaurer une copie, purger sur la copie, vérifier les usages réels, puis seulement reproduire en production.
Le module ajoute 18 modèles, 182 champs et 9 menus sous Paramètres ▸ Technique ▸ Nettoyage de la base de données : c'est un outillage d'administration complet, pas un bouton. Voir sauvegardes et plan de reprise.
module_auto_update : ne mettre à jour que ce qui a changé
Mettre à jour un module Odoo après un déploiement se fait habituellement en relançant la mise à niveau de tous les modules installés. Sur une instance avec soixante modules communautaires, c'est long, et cela rejoue des migrations inutiles.
Ce module calcule une empreinte SHA1 du contenu de chaque module sur disque, la compare à celle enregistrée lors de la dernière mise à jour réussie, et ne relance la mise à niveau que des modules dont le code a effectivement changé.
- En exploitation : le temps de déploiement baisse, et le risque d'effet de bord diminue puisqu'on ne touche pas aux modules inchangés.
- Scriptable : le processus peut être appelé automatiquement, ce qui en fait une brique de chaîne de déploiement.
- Menu : Apps ▸ Mise à jour automatique des modules.
C'est typiquement le genre de module qu'un client n'ouvrira jamais et qui change la vie de celui qui exploite. Il ajoute un modèle, un menu et 11 champs.
report_xlsx et report_csv : deux sockets, pas deux rapports
Ces deux-là figurent au socle pour une raison indirecte : d'autres modules en dépendent.
| Module | Ce qu'il ajoute | Ce qu'il n'est pas |
|---|---|---|
report_xlsx | Un type de rapport XLSX, via la bibliothèque xlsxwriter | Il ne fournit qu'un exemple de démonstration |
report_csv | Un type de rapport csv, avec une classe Python abstraite | Il ne crée aucun rapport utilisable directement |
report_xlsx est une dépendance déclarée de mis_builder : sans lui, pas d'export Excel des états financiers. C'est la raison principale de sa présence au socle. Voir mis_builder.
Autrement dit : ne cherchez pas de nouveau menu après leur installation. Ils donnent à Odoo la capacité de produire des fichiers Excel et CSV comme formats de rapport, au même titre que le PDF — à charge pour d'autres modules d'en définir un.
Ce que ces modules ajoutent à l'instance
| Module | Modèles créés | Champs | Menus | Version | Licence |
|---|---|---|---|---|---|
disable_odoo_online | 0 | 2 | 0 | 18.0.1.0.0 | AGPL-3 |
remove_odoo_enterprise | 0 | 2 | 0 | 18.0.1.0.0 | AGPL-3 |
portal_odoo_debranding | 0 | 0 | 0 | 18.0.1.0.0 | LGPL-3 |
database_cleanup | 18 | 182 | 9 | 18.0.1.0.2 | AGPL-3 |
module_auto_update | 1 | 11 | 1 | 18.0.1.0.2 | LGPL-3 |
report_xlsx | 1 | 1 | 0 | 18.0.1.1.3 | AGPL-3 |
report_csv | 2 | 9 | 0 | 18.0.1.0.2 | AGPL-3 |
Le contraste de la ligne database_cleanup avec toutes les autres n'est pas un hasard : c'est le seul module de cette famille qui apporte un outillage complet, et le seul qui touche à la structure de la base.
Limites connues
database_cleanup: le module avertit lui-même qu'il est potentiellement destructeur et peut endommager l'intégrité des données. Il ne doit être utilisé qu'avec précaution, par un administrateur, jamais directement en production.disable_odoo_online: la désactivation du notifieur de mise à jour ne concerne que l'édition Community.remove_odoo_enterprisemasque les incitations commerciales ; il ne débloque évidemment aucune fonctionnalité payante.report_xlsxetreport_csvne fournissent aucun rapport utilisable seul : ce sont des sockets techniques.module_auto_updatecompare le code sur disque : il ne détecte pas un changement fait directement en base, par exemple une vue modifiée depuis l'interface.
La dernière limite mérite d'être comprise : si quelqu'un modifie une vue depuis l'interface d'Odoo, le module ne verra pas de changement de code, donc ne rejouera pas la mise à niveau — ce qui est le comportement souhaité, mais signifie que les modifications faites en base restent hors de son champ.
Identité technique
| Module | Dépôt OCA | Dépend de |
|---|---|---|
disable_odoo_online | server-brand | mail |
remove_odoo_enterprise | server-brand | base_setup |
portal_odoo_debranding | server-brand | portal |
database_cleanup | server-tools | base |
module_auto_update | server-tools | base |
report_xlsx | reporting-engine | base, web |
report_csv | reporting-engine | base, web |
Les sept font partie de notre socle commun. Le dépôt server-brand compte 3 modules documentés — les trois ci-dessus.
Questions fréquentes
Mes utilisateurs verront-ils des publicités pour Odoo Enterprise ?
Non : trois modules du socle y pourvoient. disable_odoo_online retire les liens vers les services odoo.com du menu utilisateur et les menus du store d'applications, remove_odoo_enterprise masque les réglages « à débloquer » et filtre les modules payants des listes, et portal_odoo_debranding retire la mention Odoo des pages vues par vos propres clients.
database_cleanup est-il risqué ?
Oui, et le module l'écrit lui-même : il est potentiellement destructeur et peut endommager l'intégrité des données. La purge des champs, colonnes et tables orphelines est la plus risquée — un élément encore utilisé emporte ses données. La règle : jamais en production, toujours sur une copie restaurée d'abord.
À quoi sert l'assistant de création d'index de database_cleanup ?
Il crée les index PostgreSQL manquants sur les champs marqués index=True. Contrairement aux purges, c'est une opération sans risque, et sur une instance ayant traversé plusieurs montées de version c'est un gain de performance gratuit.
Pourquoi report_xlsx figure-t-il au socle si aucun rapport n'y est fourni ?
Parce que c'est une dépendance déclarée de mis_builder : sans lui, pas d'export Excel des états financiers. C'est un socket technique qui donne à Odoo la capacité de produire des fichiers Excel comme format de rapport, à charge pour d'autres modules d'en définir un.
module_auto_update remplace-t-il une recette de montée de version ?
Non, il ne traite que la mise à jour sélective des modules dont le code a changé — ce qui réduit le temps et les effets de bord d'un déploiement. Une montée de version majeure demande toujours une instance de recette et une reprise de vos usages réels, module par module.
Se faire accompagner
Six de ces sept modules s'installent et s'oublient. Le septième, database_cleanup, est le seul du socle qui puisse abîmer une base — et c'est précisément celui qu'on est tenté d'utiliser quand une instance devient lourde.
Nous menons ces purges sur une copie restaurée, avec une vérification des usages réels avant de reproduire en production — et nous passons l'assistant de création d'index, qui est gratuit et sans risque. Voir les prestations d'Atalios Consulting ou demander un rappel.
Pour aller plus loin
- Sauvegardes et plan de reprise : les trois chiffres
- Quelle version d'Odoo choisir, et quand monter
- Le socle commun : les 57 modules de chaque instance
En résumé
Trois modules pour qu'aucun renvoi commercial n'apparaisse — ni en interne, ni sur le portail de vos clients. Deux pour l'exploitation : une purge des résidus à manipuler avec une sauvegarde sous la main, et une mise à jour sélective qui ne touche que ce qui a changé. Deux sockets de rapport dont mis_builder dépend. Parlons de votre exploitation.
