Odoo Studio est sans doute l’un des outils les plus séduisants de l’écosystème Odoo.
Accessible, visuel, simple à prendre en main, il donne l’illusion qu’en quelques clics, tout est possible : créer un champ, modifier une vue, ajouter une automatisation.
Une démonstration plus tard, tout le monde applaudit.
Mais dans les coulisses, un engrenage fragile peut se mettre en place… et se casser au moment où l’on s’y attend le moins : migration, mise à jour de module, restauration de base…
Un outil sans code… mais pas sans conséquences
Odoo Studio permet de modifier des modèles natifs d’Odoo (comme les contacts, les devis, les bons de commande), directement depuis l’interface graphique. Il ajoute des champs, des boutons, des vues, sans écrire une seule ligne de code.
Mais contrairement aux modules Odoo classiques, Studio ne déclare pas formellement ses dépendances techniques. Et c’est là que les ennuis commencent.
Exemple réel : quand Studio devient un piège
Imaginons ce scénario, rencontré dans de nombreux projets :
- Vous installez un module communautaire, par exemple pour enrichir la fiche client ou ajouter une gestion métier.
- Vous ajoutez, avec Studio, un champ dans res.partner (la fiche client standard) qui pointe vers un modèle du module communautaire.
- Tout fonctionne parfaitement. Jusqu’au jour où…
…vous migrez, ou vous mettez à jour un module.
Et là, Odoo commence par charger les modèles natifs, y compris les modifications Studio, puisque ces dernières sont attachées à ces modèles comme s’il s’agissait de code standard.
Mais le module communautaire, lui, n’est pas encore chargé à cette étape. Résultat :
Le champ Studio pointe vers un modèle inexistant.
Et Odoo plante.
Ce n’est pas un bug. C’est la logique d’Odoo.
Dans un module traditionnel, vous auriez une déclaration claire dans le __manifest__.py :
'depends': ['base', 'mon_module_communautaire']
Mais Studio n’enregistre aucune dépendance. Il ajoute le champ dans le modèle… et se fiche de savoir si le modèle cible est disponible ou non au moment du chargement. Résultat : des erreurs incompréhensibles en migration, ou pire, une base inexploitée après une mise à jour.
Migrations, mises à jour, restaurations : même combat
Ce piège ne concerne pas uniquement les migrations majeures (par exemple de la version 17 à 18).
Il peut surgir :
- lors d’une simple mise à jour de module communautaire,
- après une restauration de base,
- ou même à l’occasion d’un déploiement sur une instance de test.
Dès qu’il y a un décalage de chargement entre un modèle communautaire et un champ Studio qui en dépend, le risque est là.
Nos conseils chez Auguria
Parce que l’outil est bon, mais son usage mérite méthode, voici notre approche.
1. Utilisez Studio pour maquetter
Studio est parfait pour tester une idée, créer une maquette en atelier client, montrer un flux.
C’est rapide, réversible, parlant.
Mais ce n’est pas une base fiable pour construire un socle applicatif pérenne.
2. Une fois l’idée validée, transformez-la en module
Dès que le besoin est validé, recodez proprement la fonctionnalité dans un module Odoo traditionnel :
- structuré,
- versionné,
- contrôlé,
- avec ses dépendances déclarées.
C’est plus robuste, plus propre… et surtout migrable sans douleur.
3. Ne créez jamais de champ Studio pointant vers un modèle communautaire ou custom
C’est le cas typique qui déclenche les erreurs de migration : un champ créé avec Studio qui dépend d’un module non encore chargé.
À éviter absolument. C’est une règle d’or que nous appliquons systématiquement.
Ce que Studio ne vous dit pas…
Studio donne l’illusion que l’on peut développer sans développeur.
Mais un bon système d’information, ça se pense, ça se structure, ça se documente.
Et ça se migre.
Chez Auguria, on adore la souplesse. Mais pas au prix de la fiabilité.
On aime l’agilité. Mais pas sans cadre.
Et surtout, on préfère dire la vérité sur les outils. Même quand ils sont séduisants.
En résumé
Odoo Studio est un formidable levier d’innovation rapide.
Mais sans discipline, il devient une source de dette technique et de blocages futurs.
Si vous cherchez la rapidité et la robustesse, alors il faut articuler Studio avec une vraie méthode projet.
Et si vous doutez, ou si vous hésitez entre Studio, module custom et bonne vieille ligne de code…
Appelez-nous.
Nous, on ne bricolera pas. On construira.