• Réservations ouvertes pour T3 · Montréal · Toronto · Miami · Rabat · • Migrations Odoo 17 : planifiées 6 semaines à l’avance

Personnalisation Odoo : Studio, modules et mises à niveau

Illustration de deux personnes devant des écrans qui montrent un clavier de caisse, une liste de vérification et une liste de produits, avec le logo d’Odoo et deux engrenages au-dessus

La personnalisation Odoo comporte trois couches, et chacune coûte plus cher à maintenir que la précédente : la configuration, soit les paramètres du produit standard ; Studio, la boîte à outils sans code d’Odoo ; et les modules sur mesure, écrits en Python et en XML. Utilisez la couche la plus basse qui fait le travail, car chaque couche au-dessus ajoute du travail à chaque mise à niveau.

Ce guide suit la documentation d’Odoo 20.0 (en anglais) et cite la page derrière chaque énoncé. Il explique ce que chaque couche permet, ce qu’elle coûte à la mise à niveau, et les cas où la bonne réponse est de ne pas personnaliser. L’édition que vous utilisez change les options, et nous comparons les deux dans Odoo Community vs Enterprise. Les noms d’options et de forfaits sont donnés comme dans la documentation, en anglais.

Les trois couches de la personnalisation Odoo

CoucheCe que vous faitesQui s’en chargeÀ la mise à niveau
ConfigurationActiver et régler les options que les applications offrent déjàVotre équipe ou votre intégrateurLes applications standard sont couvertes par le service de mise à niveau d’Odoo avec Enterprise
StudioAjouter ou modifier, sans code, des champs, des vues, des modèles, des règles d’automatisation, des webhooks, des rapports PDF, des règles d’approbation et des règles de sécuritéUne personne formée, non développeuseCouverte tant que Studio reste installé et que son abonnement reste actif
Modules sur mesureDu code Python et XML qui étend par héritage les modèles et les vues d’OdooUn développeurLa base ne peut pas être mise à niveau tant que votre module n’existe pas pour la version visée

Sources : documentation de Studio, tutoriel sur l’héritage et documentation des mises à niveau. La dernière colonne concerne le service de mise à niveau d’Enterprise ; nous l’expliquons plus bas.

Configurer avant de personnaliser

Beaucoup de lacunes sont des paramètres que personne n’a activés. Avant de demander une modification, trouvez la documentation de l’application pour votre version, activez l’option dans une copie de test de votre base et voyez si elle fait ce qu’il vous faut.

Notre guide sur les stocks en donne un bon exemple. Un flux de réception et de livraison en une, deux ou trois étapes ressemble à une personnalisation, mais la documentation d’Odoo sur les routes indique que deux champs de l’entrepôt suffisent : vous n’écrivez pas les règles à la main. Nous le traitons dans Gestion des stocks Odoo. La configuration fait partie du produit standard : c’est la couche la moins chère à reporter d’une version à l’autre, même si le service de mise à niveau ne nettoie pas les données et la configuration existantes.

Demandez-vous aussi si c’est le processus, et non le logiciel, qui doit changer. Une étape qui n’existe que parce que l’ancien système l’exigeait n’est pas une exigence. Sur notre page Odoo, nous disons personnaliser le moins possible et préférer adapter le processus à l’outil quand nous le pouvons. C’est notre conseil, pas une règle d’Odoo, mais il coûte moins cher que l’autre voie.

Studio : sans code, mais avec un forfait

La documentation d’Odoo décrit Studio comme une boîte à outils pour personnaliser Odoo sans connaissances en programmation. Vous ouvrez une application, activez Studio, puis ajoutez ou modifiez des champs, des vues, des modèles, des règles d’automatisation, des webhooks, des rapports PDF, des règles d’approbation et des règles de sécurité dans n’importe quelle application. La page de Studio ajoute des champs par glisser-déposer, la modification de documents comme les factures, des déclencheurs et des actions automatisées, des approbations qui vérifient les actions critiques avant leur exécution, des changements de menus, des champs conditionnellement invisibles, obligatoires ou en lecture seule, et un éditeur XML pour les modifications avancées des rapports.

C’est une grande part de ce que la plupart des entreprises appellent de la personnalisation : un champ de plus sur un client, un écran avec moins de colonnes, une mise en page de facture, une approbation avant un gros bon de commande. C’est à Studio que nous recourons d’abord pour ces cas.

Deux points pratiques :

  • Il est lié à un forfait. La page des prix d’Odoo indique « Odoo Studio » sur la carte Custom, pas sur la carte Standard, et sa foire aux questions dit que le forfait gratuit peut prendre Studio comme sa seule application. La documentation de Studio précise que l’installer avec un forfait Standard déclenche une vente additionnelle vers Custom. Chiffrez-le avant de prévoir l’utiliser.
  • Sa couverture à la mise à niveau comporte des conditions. Selon les modalités du service de mise à niveau, les personnalisations faites avec Studio sont couvertes tant que Studio reste installé et que son abonnement reste actif. Abandonner Studio plus tard change cela.

La documentation de Studio ne dresse pas la liste de ses limites fonctionnelles : testez donc votre besoin dans une copie avant de le promettre. Tenez une courte liste de ce que vous avez construit avec Studio, pourquoi et à la demande de qui. Un an plus tard, personne ne s’en souvient.

Modules sur mesure : du code qui étend Odoo

Quand un paramètre ou Studio ne suffit pas, un développeur écrit un module. Le tutoriel d’Odoo sur l’héritage décrit deux façons d’étendre un modèle défini par un autre module. La plus courante déclare _inherit avec le nom du modèle existant, et le module peut alors ajouter des champs, redéfinir des champs, ajouter des contraintes, ajouter des méthodes ou redéfinir des méthodes existantes. L’autre, la délégation, relie chaque enregistrement à un enregistrement d’un modèle parent.

Les vues fonctionnent de la même manière. Selon le tutoriel, au lieu de modifier les vues existantes sur place, Odoo offre l’héritage de vues : une vue d’extension désigne sa vue parente avec inherit_id, et ses éléments xpath sélectionnent et modifient le contenu du parent, avec une position comme inside, replace, before, after ou attributes.

Deux règles en découlent, et nous les respectons toutes les deux :

  • Étendre, ne jamais modifier les fichiers d’Odoo. Un changement fait à l’intérieur du code d’Odoo doit être refait à chaque mise à jour. Un module qui hérite se place à côté du code d’Odoo et peut être reporté d’une version à l’autre.
  • Appeler le parent. Quand vous redéfinissez create(), write() ou unlink(), le tutoriel dit qu’il est « très important d’appeler toujours super() pour ne pas briser le flux » (traduction libre).

Avant de commander un module, regardez dans la boutique d’applications Odoo. Quelqu’un publie peut-être déjà ce qu’il vous faut, comme un connecteur ou une règle comptable locale. Rappelez-vous qu’un module additionnel, qu’il soit conçu à l’interne ou par un tiers, est exclu du service de mise à niveau à moins d’avoir un contrat de maintenance, comme l’explique la section suivante.

Testez chaque module dans une copie de votre base, avec de vraies données, jamais en production. Donnez au développeur vos vrais cas limites : le client atypique, la note de crédit, la commande dans une deuxième devise.

Ce que coûte une personnalisation à la mise à niveau

C’est là que les personnalisations deviennent coûteuses, et c’est la raison de choisir la couche la plus basse. La documentation des mises à niveau d’Odoo indique ceci :

  • Chaque version majeure est soutenue pendant trois ans : une base sera donc mise à niveau selon un calendrier.
  • Une base contenant des modules personnalisés ne peut pas être mise à niveau tant qu’une version de ces modules n’est pas disponible pour la version visée. Leur responsable les met à jour, et Odoo recommande de le faire en parallèle de la demande d’une base de test mise à niveau.
  • Si un changement dans une nouvelle version brise une personnalisation, la corriger relève du responsable de votre module personnalisé.
  • Avec Odoo Enterprise, la mise à niveau vers la version la plus récente est gratuite, selon l’Enterprise Subscription Agreement. Les applications standard et les personnalisations faites avec Studio sont couvertes ; les développements ne le sont que dans le cadre d’un abonnement de maintenance des personnalisations.
  • Ne sont pas couverts : le nettoyage des données et de la configuration existantes, la mise à niveau de modules additionnels sans contrat de maintenance, et la formation sur la nouvelle version.

La page des prix indique que la maintenance du code personnalisé n’est comprise dans aucun forfait. La mise à niveau gratuite couvre donc le produit d’Odoo. Le coût du code que vous avez ajouté vous revient, dans une soumission ou en heures de personnel.

La documentation recommande aussi de tester la copie mise à niveau sur les flux d’affaires clés, les intégrations, les exportations, les actions automatisées et les actions serveur, et de répéter la mise à niveau de production la veille de la mise en service, puisque les scripts de mise à niveau changent avec le temps. Chaque personnalisation que vous ajoutez est un élément de plus à mettre sur cette liste.

Avec Community, le service de mise à niveau ne fait pas partie du tableau.

Quand personnaliser est une mauvaise idée

  • Un paramètre ou le flux standard le fait déjà. Vérifiez d’abord la configuration, dans une copie de votre base.
  • Vous reproduisez l’ancien système. Retrouver un écran familier ou une ancienne mise en page de rapport est une habitude, pas une exigence. Demandez quelle décision l’écran appuie.
  • Personne n’en sera responsable. Un module sans responsable désigné échoue à la première mise à niveau, puisque c’est ce responsable qui doit le mettre à jour.
  • La fonction exige un forfait ou une édition que vous n’avez pas choisie. Si elle dépend de Studio sur toutes les applications, vous regardez le forfait Custom. Si vous êtes sur Community, vous écrivez du code. Décidez d’abord de l’édition.
  • Elle touche aux stocks ou à la comptabilité. Selon notre expérience, les changements à la façon dont le stock bouge ou dont les écritures sont comptabilisées sont les plus difficiles à reporter d’une version à l’autre. Préférez un rapport ou un champ de plus à un calcul modifié.
  • Un module tiers existe, mais personne ne le maintient. Il est moins cher à adopter, mais vous héritez du même problème de mise à niveau.

Un ordre de travail raisonnable

  1. Écrivez la lacune en une phrase : qui a besoin de quoi, à quelle fréquence, et ce que cela coûte aujourd’hui.
  2. Cherchez un paramètre. Lisez la documentation de l’application pour votre version et essayez-le dans une copie.
  3. Envisagez de changer le processus si cela coûte moins cher que de construire.
  4. Essayez Studio pour les champs, les vues, les rapports et les automatisations simples, si votre forfait l’inclut.
  5. Écrivez un module seulement pour ce qui reste, avec une spécification, des tests dans une copie et un responsable désigné.
  6. Consignez chaque personnalisation : ce qu’elle fait, pourquoi, qui la maintient et dans quelle version elle a été testée en dernier.
  7. Répétez la mise à niveau dans une copie avant la vraie, avec les personnes qui utilisent le système.

Questions fréquentes

Peut-on personnaliser Odoo ?

Oui, de trois façons : la configuration, Studio et les modules qui étendent Odoo par héritage.

Quelle est la différence entre Odoo standard et personnalisé ?

Le standard, c’est ce qu’Odoo livre et met à niveau. Le personnalisé, c’est tout ce que vous ajoutez par-dessus, que ce soit Studio, un module écrit pour vous ou un module tiers. La documentation des mises à niveau les traite différemment : les applications standard sont couvertes, alors que les modules personnalisés exigent un responsable.

Les personnalisations se brisent-elles à la mise à niveau d’Odoo ?

Elles le peuvent. Une base contenant des modules personnalisés ne peut pas être mise à niveau tant que ces modules n’existent pas pour la version visée, et la page d’Odoo sur les mises à niveau indique que corriger une personnalisation brisée par une nouvelle version revient à son responsable. Testez d’abord dans une copie.

Faut-il un développeur, ou Studio suffit-il ?

Studio couvre les champs, les vues, les rapports, les automatisations et les approbations. Au-delà, il faut un développeur. Studio est indiqué dans le forfait Custom, selon la page des prix.

Le soutien d’Odoo couvre-t-il mes personnalisations ?

Pas le code personnalisé : la page des prix indique que la maintenance du code personnalisé n’est pas comprise.

Si vous hésitez sur ce qu’il faut configurer, construire ou laisser tel quel, parlez-nous avec votre liste de lacunes. Nous vous dirons dans quelle couche chacune se range, et comment nous procédons dans notre travail d’implantation et de soutien d’Odoo.

Tous les articles