Publier un module sur l'Odoo App Store : les règles écrites et celles que l'on apprend après 117 publications

L'Odoo App Store est le seul canal où un module Odoo se vend sans commercial : quelqu'un le cherche, l'achète et l'installe. Publier est gratuit et tout le monde peut le faire avec un dépôt git et un manifest bien écrit. Ce qui n'est écrit nulle part, c'est pourquoi une publication met des jours à apparaître, pourquoi une description s'affiche cassée, ou pourquoi un module qui compile sur votre machine ne s'installe pas sur l'Odoo de l'acheteur. Voici ce que nous avons appris en publiant 105 modules et en les maintenant en Odoo 19, 18 et 17.

Les règles écrites : dépôt, branche et manifest

Le mécanisme est simple et mérite d'être suivi à la lettre. Vous enregistrez un dépôt git dans votre compte apps.odoo.com ; l'App Store le scanne et publie chaque module qu'il y trouve. La branche compte : la branche 19.0 alimente les fiches d'Odoo 19, la 18.0 celles d'Odoo 18, la 17.0 celles d'Odoo 17. Un même nom technique sur les trois branches donne une seule fiche avec trois versions, et c'est ce que vous voulez : une URL, une page d'avis, trois boutons de téléchargement. Des noms techniques différents par version donnent trois fiches qui se partagent les visites.

Du manifest, ce que l'App Store lit et affiche :

• name, summary et category : le titre de la fiche, la ligne située dessous et l'endroit où elle apparaît dans le catalogue. Le nom doit être unique dans toute la boutique.
• version avec le préfixe de la version d'Odoo (19.0.1.0.0) : sans ce préfixe, la fiche ne sait pas à quel Odoo elle appartient.
• license : OPL-1 pour les modules payants, LGPL-3 ou AGPL-3 pour les gratuits. Un module payant sous licence libre est un cadeau que vous ne vouliez pas faire.
• price et currency : le prix de la fiche. Odoo garde une part de chaque vente et vous reverse le reste ; la répartition est publiée dans les conditions de l'App Store.
• images : la liste des captures, en commençant par la bannière visible dans le catalogue. Sans bannière, la fiche s'affiche avec un trou gris à côté de celles qui en ont une.
• static/description/index.html : la description longue. HTML sans scripts, images relatives à l'intérieur du module et, par expérience, caractères ASCII : un accent ou des guillemets typographiques mal encodés peuvent laisser la fiche avec des symboles cassés que vous ne voyez qu'une fois publiée.

Les règles qui ne sont pas écrites

Le re-scan fait foi, et on ne le force pas avec un zip

Après un push, la fiche ne change pas instantanément : l'App Store rescanne le dépôt à son propre rythme, qui peut être de quelques heures ou de quelques jours. La tentation est d'envoyer un zip à la main pour « accélérer ». Ne le faites pas : une version envoyée à la main et une version scannée depuis le dépôt cohabitent mal, et vous vous retrouvez avec une fiche dont vous ne savez plus d'où elle vient. La règle que nous suivons tient en une seule source, le dépôt, et de la patience. Si vous avez besoin que le scan prenne en compte un changement, incrémentez le numéro de version du manifest : une modification du contenu avec la même version n'est parfois pas prise en compte.

Compiler n'est pas installer

Le scan n'installe pas le module. Un manifest valide et un code qui s'importe sans erreur ne signifient pas que le module s'installe. En Odoo 19, cela est devenu particulièrement traître : les groupes de sécurité ont changé de modèle (res.groups.privilege), ir.cron n'accepte plus le champ numbercall, et les vues de liste s'appellent list, pas tree. Un module écrit pour la 17 passe le scan de la 19 sans broncher et échoue à l'installation sur l'Odoo de l'acheteur. Nous le détaillons dans pourquoi un module Odoo 19 compile mais ne s'installe pas.

Trois versions, ce sont trois modules qui se ressemblent

Maintenir le même module en 19, 18 et 17 ne consiste pas à copier le dossier sur trois branches. Chaque version a ses différences d'API, et la seule façon de savoir que les trois fonctionnent est de les installer sur un Odoo réel de chaque version. Nous le faisons sur Odoo.sh : une build par version, installation propre, tests, et seulement ensuite le push vers la branche que l'App Store scanne. Et avec Odoo 20, sorti en septembre 2026, le processus est le même avec une branche de plus. Un module testé uniquement sur la version pour laquelle il a été écrit est un module qui se vendra trois fois et échouera deux fois.

Le processus que nous suivons, dans l'ordre

1. Nom technique unique et définitif. On le cherche dans l'App Store avant d'écrire la première ligne ; le changer ensuite, c'est perdre la fiche et ses avis.
2. Manifest complet dès le premier commit : version avec préfixe, licence, prix, catégorie, images, dépendances exactes.
3. Installation propre sur un Odoo.sh réel de chaque version à publier, avec les tests au vert. Sans cela, pas de push.
4. Description en ASCII avec de vraies captures du module installé, pas des maquettes. L'acheteur compare ce qu'il voit sur la fiche avec ce qu'il installe.
5. Push vers la branche de version et attendre le scan. Pas de zips. S'il faut corriger, on incrémente la version et on attend de nouveau.
6. Vérifier la fiche publiée sur les trois versions : bannière, description sans symboles cassés, prix, bouton de téléchargement.

Ce que la publication ne fait pas pour vous

Publier n'est pas vendre. Une fiche bien faite apparaît quand quelqu'un cherche exactement ce problème, et c'est tout. Ce qui fait qu'un module s'installe, c'est qu'il fonctionne du premier coup, que la description dise ce qu'il fait et ce qu'il ne fait pas, et que les questions de support reçoivent une réponse. C'est pourquoi nous traitons chaque module publié comme un produit avec sa maintenance, pas comme un fichier envoyé. Et c'est pourquoi, quand un éditeur de logiciels nous demande un connecteur pour son produit, la publication sur l'App Store fait partie du travail, pas d'une option : c'est là que ses utilisateurs d'Odoo iront le chercher.

Questions fréquentes

Liens utiles chez FlexigoTech