Personnaliser Odoo 19 : configuration, Studio ou modules personnalisés ?

Tout projet Odoo finit par se heurter à la même question : le flux standard est proche, mais pas tout à fait conforme à ce que souhaite l'entreprise. Faut-il modifier un paramètre, ouvrir Odoo Studio ou demander à un développeur d'écrire un module personnalisé ? La réponse a des conséquences à long terme sur le coût, la stabilité et, surtout, les mises à niveau.

Chez 1CBMS, nous appliquons une règle simple dans chaque mise en œuvre : d'abord la configuration, puis Studio, puis les modules personnalisés. Chaque échelon descendu apporte davantage de flexibilité, mais ajoute aussi un élément que l'entreprise doit assumer et maintenir pendant toute la durée de vie du système.

Une remarque sur les sources : cet article s'appuie sur la documentation officielle d'Odoo pour la version 19.0. Les menus et les options peuvent varier selon les versions, les éditions et les types d'hébergement ; vérifiez donc toujours le comportement dans une base de test avant de modifier la production.

Premier niveau : la configuration avant tout

Odoo est livré avec un grand nombre de paramètres, d'options et d'enregistrements configurables dans chaque application. Bien des demandes qui ressemblent à des personnalisations sont en réalité des fonctionnalités standard qui n'ont pas encore été activées, comme des étapes de workflow supplémentaires, des mises en page de documents ou des champs facultatifs qui apparaissent dès qu'une fonctionnalité est activée.

Avant de rédiger la moindre spécification pour Studio ou pour du code, passez en revue les points suivants avec les utilisateurs clés du processus :

• Examinez la page Paramètres de chaque application concernée et lisez ce que chaque option active.
• Vérifiez si le besoin est couvert par des enregistrements configurables tels que des étapes, des étiquettes, des équipes, des types d'opérations ou des modèles d'e-mails.
• Utilisez les paramètres de mise en page des documents de la société pour les logos, les couleurs, les polices et les pieds de page, plutôt que de modifier les modèles de rapports.
• Demandez-vous si l'entreprise peut adapter son processus au flux standard, car les flux standard sont testés et mis à niveau par Odoo.

La configuration est le niveau le moins coûteux à maintenir. Elle fait partie du produit standard, elle est reprise par le processus de mise à niveau et elle ne crée pas de base de code séparée que quelqu'un devrait entretenir.

Deuxième niveau : ce que permet Odoo Studio

La documentation d'Odoo décrit Studio comme une boîte à outils permettant de personnaliser Odoo sans connaissances en programmation. On l'ouvre avec l'icône Basculer vers Studio depuis l'application et le modèle à modifier, et on le ferme avec le bouton Fermer.

D'après la documentation officielle, Studio couvre les domaines suivants :

• Champs : des champs simples comme texte, entier, décimal, monétaire, date, case à cocher, sélection, fichier et image, et des champs relationnels comme Many2One, One2Many, lignes, Many2Many, étiquettes et champs liés.
• Vues : formulaire, activité, recherche, kanban, liste, carte, calendrier, cohorte, Gantt, pivot et graphique.
• Modèles et applications : de nouveaux modèles créés de toutes pièces, avec des fonctionnalités suggérées comme le chatter, les étapes de pipeline, les étiquettes, l'archivage et les lignes pour accélérer leur création.
• Règles d'automatisation : des déclencheurs basés sur la mise à jour de valeurs, des événements liés aux e-mails, des conditions temporelles, la création ou la suppression d'enregistrements, des modifications de l'interface et des webhooks externes.
• Règles d'approbation : des étapes de validation associées à des boutons, avec des approbateurs définis comme utilisateurs, groupes ou les deux. Studio couvre également les webhooks et les règles de sécurité.
• Rapports PDF : modification du texte statique, insertion de champs dynamiques, de tableaux, de colonnes et d'images dans les modèles de rapports ; notez que modifier l'en-tête ou le pied de page d'un rapport affecte tous les rapports.

Lorsque vous modifiez une vue par glisser-déposer, Studio crée automatiquement la vue héritée et le XPath appropriés au lieu d'écraser la vue standard. Tout le travail réalisé dans Studio est regroupé dans un module nommé studio_customization dans votre base de données, qui peut être exporté sous forme de fichier ZIP et importé dans une autre base.

Studio est une application Odoo Enterprise. La page officielle précise également que l'installation de Studio sur une base relevant de la formule tarifaire Standard entraîne un passage à la formule Personnalisé ; vérifiez donc l'impact commercial avec votre gestionnaire de compte Odoo avant de l'activer. Les bases Community n'incluent pas Studio ; tout ce qui dépasse la configuration s'y fait au moyen des paramètres techniques en mode développeur ou de modules.

Deuxième niveau, suite : les limites de Studio

Studio est puissant, mais la documentation elle-même signale plusieurs limites et risques que tout projet doit respecter :

• Le nom technique d'un champ ne peut plus être modifié dans Studio après sa création, et les champs personnalisés doivent conserver au moins le préfixe x_, les champs Studio utilisant x_studio_.
• La vue activité et les blocs conditionnels des rapports ne peuvent être modifiés qu'en éditant le XML, ce qui nécessite le mode développeur.
• La modification directe des vues standard ou héritées est déconseillée, car ces changements seraient réinitialisés et perdus lors des mises à jour ou des mises à niveau de modules.
• Odoo recommande vivement de dupliquer un rapport standard et de modifier la copie, et avertit que modifier directement le XML d'un rapport peut poser des problèmes lors des mises à niveau.
• L'action Exécuter du code des règles d'automatisation exécute du Python, et la documentation indique que la maintenance du code personnalisé n'est incluse ni dans la formule Standard ni dans la formule Personnalisé et entraîne des frais supplémentaires.
• Les webhooks doivent être conçus avec un développeur ou un profil technique, car des webhooks mal configurés peuvent perturber la base de données.
• Les personnalisations Studio exportées ne peuvent être importées que dans une base de données de la même version d'Odoo, avec les mêmes applications et modules installés.

En pratique, Studio est idéal pour la saisie de données, la mise en page, l'automatisation simple et les approbations. Il devient risqué lorsqu'il sert à dissimuler de la véritable programmation dans des modifications XML ou des actions Exécuter du code que personne ne documente.

Troisième niveau : quand un module Python personnalisé se justifie

Un module personnalisé est une base de code distincte qui étend Odoo au moyen de modèles, de vues, de règles de sécurité, de fichiers de données et de logique Python, construite avec le même framework qu'Odoo utilise pour ses propres applications. C'est le bon outil lorsque le besoin dépasse ce que la configuration et Studio peuvent exprimer proprement.

Les situations typiques dans lesquelles nous recommandons un module personnalisé sont notamment :

• Des règles métier, des calculs ou des contraintes complexes qui nécessitent des tests automatisés et un contrôle de version.
• Des intégrations avec des systèmes externes exigeant une gestion robuste des erreurs, des nouvelles tentatives et une journalisation.
• Des modifications de la logique métier standard, comme la manière dont les documents sont validés ou dont les valeurs sont calculées, et pas seulement de leur affichage.

L'hébergement compte ici. La documentation officielle indique qu'Odoo Online est incompatible avec les modules personnalisés ou les modules de l'Odoo Apps Store. Les modules personnalisés nécessitent Odoo.sh ou une installation sur site ; le choix de l'hébergement et la stratégie de personnalisation doivent donc être décidés ensemble.

Impact de chaque option sur les mises à niveau

• Configuration : fait partie du produit standard et est migrée par le processus de mise à niveau standard.
• Studio : les services de mise à niveau décrits dans la documentation d'Odoo incluent la mise à niveau de toutes les personnalisations créées avec l'application Studio, tant que Studio est installé et que son abonnement est actif.
• Modules personnalisés : une base de données comportant des modules personnalisés ne peut pas être mise à niveau tant qu'une version de ces modules n'est pas disponible pour la version cible d'Odoo, et il incombe au mainteneur du module de le rendre compatible.

Le guide d'Odoo pour la mise à niveau d'une base personnalisée recommande de geler les développements, de vérifier quelles fonctionnalités personnalisées sont désormais fournies en standard, de faire en sorte que chaque module s'installe proprement sur une base vide de la version cible, d'écrire des scripts de mise à niveau pour les modèles, champs et identifiants externes renommés, et de répéter la mise à niveau avant de toucher à la production.

Quel que soit le niveau, testez minutieusement la base mise à niveau. La documentation conseille de tester les flux métier de bout en bout, y compris les intégrations, les actions automatisées, les actions serveur et les rapports, et rappelle que les bases de test sont neutralisées, les actions planifiées et les e-mails sortants y étant désactivés.

Gouvernance : garder les personnalisations sous contrôle

Les personnalisations échouent rarement le premier jour. Elles échouent des années plus tard, lorsque plus personne ne se souvient pourquoi un champ existe ni qui a écrit une règle d'automatisation. Un modèle de gouvernance léger permet de l'éviter.

• Tenez un registre des personnalisations recensant chaque champ Studio, modification de vue, règle d'automatisation, règle d'approbation, rapport et module personnalisé, avec son responsable et sa justification métier.
• Effectuez toutes les modifications d'abord dans une base de test ou de préproduction, puis transférez-les en production selon un processus maîtrisé.
• Réservez Studio et le mode développeur à des administrateurs formés ; la documentation elle-même avertit que certains outils de développement sont avancés et comportent des risques.
• Passez le registre en revue avant chaque mise à niveau et retirez les personnalisations que la nouvelle version couvre en standard.
• Conservez le code des modules personnalisés sous contrôle de version avec des tests, et assurez-vous qu'un dispositif de maintenance est prévu.

Une matrice de décision applicable en atelier

Lorsqu'un nouveau besoin apparaît, nous examinons ces questions dans l'ordre et nous arrêtons au premier niveau qui y répond.

• Un paramètre standard, un enregistrement configurable ou une évolution du processus peut-il répondre au besoin ? Utilisez la configuration.
• S'agit-il d'un nouveau champ, d'une modification de la disposition d'une vue, d'une automatisation simple, d'une étape d'approbation ou d'un changement de libellé dans un rapport ? Utilisez Studio.
• Le besoin exige-t-il de la logique Python, des tests automatisés, une intégration complexe ou une réutilisation dans plusieurs bases ? Utilisez un module personnalisé.
• La base de données est-elle sur Odoo Online ? Restez dans le cadre de la configuration et de Studio, ou planifiez d'abord une migration vers Odoo.sh ou un hébergement sur site.

Comment 1CBMS peut vous aider

1CBMS aide les entreprises en Égypte et en Irak à concevoir des solutions Odoo 19 Enterprise qui restent proches du standard. Nous animons des ateliers d'analyse des écarts pour distinguer la configuration des véritables écarts, réalisons des personnalisations Studio rigoureuses, développons et maintenons des modules personnalisés lorsqu'ils sont réellement nécessaires, et préparons des registres de personnalisations et des plans de test de mise à niveau afin que votre système reste maintenable. Contactez-nous via www.1cbms.com pour examiner vos personnalisations actuelles ou planifier une nouvelle mise en œuvre.