Odoo Studio vs code custom — quand utiliser lequel
Studio est brillant pour le bon usage et un piège lent pour le mauvais. Nous utilisons les deux sur chaque projet client — cet article est le cadre que nous appliquons pour décider lequel va où.
Odoo Studio est la couche de personnalisation low-code qui permet d'ajouter des champs, construire des écrans, concevoir des rapports et câbler des automatisations sans écrire de Python. C'est vraiment utile — et vraiment détourné. La plupart de la dette technique qu'on nous demande de nettoyer est de la prolifération Studio sans contrôle.
Nous ne sommes pas anti-Studio. Utilisé avec discipline il accélère la livraison, donne du pouvoir aux utilisateurs métier et garde les petites personnalisations hors du backlog dev. Sans discipline il produit de la logique non documentée, des migrations fragiles et une configuration que personne ne comprend en année trois.
Cet article est la règle empirique que nos consultants appliquent : où Studio gagne, où le code gagne, où la ligne bouge avec la maturité de l'équipe, et comment nous gouvernons la frontière sur notre portefeuille client.
Où Studio est la bonne réponse
Studio est à son meilleur pour les changements petits, additifs, bien bornés qui mappent proprement aux concepts Odoo existants : quelques champs supplémentaires, une vue ajustée, un rapport custom, une automatisation simple. Ces changements croupiraient sinon dans un backlog pendant des semaines.
Nous poussons fortement pour Studio dans ces cas. Cela met la personnalisation entre les bonnes mains (l'utilisateur métier le plus proche du besoin) et garde l'équipe dev focalisée sur les changements qui demandent vraiment du code.
- Ajouter quelques champs custom aux modèles existants
- Réordonner ou renommer des champs dans une vue existante
- Construire un petit rapport ou template d'impression
- Câbler une automatisation simple (changement de statut → email)
- Créer un nouveau modèle léger pour un cas d'usage interne
Où le code custom est la bonne réponse
Le code gagne dès que la logique se complexifie, que la réutilisation compte, que le changement touche plusieurs modules, ou que la surface d'intégration n'est pas triviale. Tout ce que vous voudriez couvert par des tests, code-reviewé et versionné appartient à un vrai module.
Si un changement Studio devient dur à expliquer en un paragraphe ou dur à reproduire sur un sandbox, il a dépassé Studio. Le refactorer tôt en module vous épargne un refactor bien plus dur plus tard.
- Logique qui couvre plusieurs modèles ou modules
- Intégrations avec systèmes externes au-delà des webhooks simples
- Tout ce qui demande tests unitaires ou d'intégration
- Code sensible à la performance (batchs, rapports sur grosses données)
- Tout changement qu'un junior ne devrait pas modifier sans review
La zone grise — et comment la garder propre
Certains changements démarrent en Studio et le dépassent discrètement. L'odeur classique est quand une automatisation Studio en déclenche une autre, ou quand des champs Studio apparaissent dans des rapports custom. C'est là que nous tirons un trait et migrons en module.
La discipline n'est pas 'jamais Studio pour x' ; c'est 'quand Studio y dépasse seuil z, on promeut en module'. Documentez le seuil une fois et vous arrêtez d'avoir la même dispute chaque trimestre.
- Automatisation Studio chaînée à une autre automatisation Studio
- Champs Studio utilisés dans des rapports custom non triviaux
- Logique Studio à déployer sur plusieurs bases
- Tout ce qu'un key user a peur de toucher
- Customisation devenue un point de défaillance unique
Gouvernance — la pièce manquante sur la plupart des projets
Studio sans gouvernance produit de la prolifération. Chaque projet que nous auditons a au moins un changement Studio non documenté d'un power user d'il y a trois ans que personne n'ose toucher. Évitez ça en mettant une barre petite mais réelle dès le jour 1.
Gouvernance ne veut pas dire bureaucratie — un registre partagé, un nettoyage trimestriel et un propriétaire explicite des changements Studio par module. Une demi-journée par trimestre suffit pour rester sain.
- Maintenir un registre des changements Studio par module
- Nommer un propriétaire par module qui revoit les changements
- Passe de nettoyage trimestrielle de la prolifération
- Documenter chaque changement Studio en une ligne
- Tester sur sandbox avant d'appliquer en production
La règle de seuil que nous appliquons chez Flydoo
Notre règle interne est simple : si une personnalisation touche plus de deux modules, a une logique conditionnelle au-delà d'un simple 'si', ou doit être déployée sur plus d'une base — elle appartient au code. Sinon, Studio est très bien.
- Touche plus de deux modules → module
- Plus d'une condition → module
- Doit être déployée sur plusieurs bases → module
- A besoin de tests → module
- Sinon → Studio est la bonne réponse
Erreurs Studio que nous nettoyons sans cesse
Cinq schémas trouvés dans presque tous les audits.
- Construire des workflows critiques en Studio sans registre ni propriétaire.
- Chaînes d'automatisations Studio que personne ne sait débuguer end-to-end.
- Déployer manuellement des changements Studio entre bases au lieu d'un module.
- Traiter les changements Studio comme 'gratuits' — pas de test, pas de review, pas de doc.
- Promouvoir des changements Studio en code seulement après qu'ils ont cassé en prod.
Comment mesurer que la frontière est saine
Indicateurs suivis par module sur les projets clients.
- Nombre de changements Studio par module — devrait plafonner, pas croître.
- Complétude du registre Studio — chaque changement documenté.
- Nombre de promotions Studio→code par an — petit mais non nul.
- Temps de debug d'un incident lié à Studio — borné, pas 'on ne sait pas'.
- Nombre de changements Studio non documentés — zéro après le premier nettoyage.
Comment Flydoo opère la gouvernance Studio
Chaque projet client démarre avec une politique Studio d'une page : qui peut changer quoi, ce qui est registré, et le seuil de promotion vers le code. Nous co-possédons le registre avec le lead IT du client et le revoyons trimestriellement.
Quand un changement Studio dépasse le seuil, nous planifions la promotion vers un module dans le sprint suivant. Nous ne laissons jamais une chaîne d'automatisations Studio grossir au point qu'un d'entre nous soit le seul à la comprendre.
- Politique Studio d'une page sur chaque projet
- Registre Studio co-possédé avec le lead IT du client
- Revue Studio trimestrielle dans l'agenda
- Promotion en code planifiée dès le franchissement du seuil
- Partage de connaissance — jamais une seule personne expert
Avant de valider un changement Studio
Parcourez cette courte liste avant de cliquer sauvegarder.
- Changement décrit en un paragraphe
- Propriétaire par module identifié
- Changement testé d'abord sur sandbox
- Entrée ajoutée au registre Studio
- Règle de seuil appliquée — sous le seuil, Studio ; au-dessus, planifier un module
- Plan de retour arrière documenté pour les changements non triviaux
- Date de revue trimestrielle dans l'agenda
Studio et code sont partenaires, pas rivaux
Studio est la bonne réponse pour le bon type de changement. Le code custom pour le reste. Les équipes qui gagnent choisissent délibérément, documentent leurs choix et revoient la frontière régulièrement.
Si vous nettoyez de la prolifération Studio, ce n'est pas la faute de Studio — c'est l'absence de gouvernance. Mettez en place la politique, le registre et la revue trimestrielle et l'outil recommence à payer.
Nous menons volontiers un audit Studio d'une journée sur n'importe quel Odoo en production et vous disons quels changements rester, promouvoir ou retirer.
Questions fréquentes
Studio est-il considéré 'production-grade' ?
Oui — Odoo supporte officiellement Studio en production. Le risque n'est pas l'outil ; c'est la prolifération non documentée. Avec un registre, un propriétaire et une règle de seuil, Studio est un composant légitime d'une prod Odoo.
Les changements Studio survivent-ils à une migration ?
La plupart oui, certains cassent. Toujours tester sur une migration sandbox avant la prod. Les changements Studio qui touchent des champs dépréciés ou des vues retirées doivent être revus à chaque release mineure.
Puis-je versionner les changements Studio ?
Les changements Studio vivent dans la base, pas dans un repo Git, donc ils ne sont pas versionnés comme un module. Vous pouvez exporter et tracker l'export, mais le chemin propre pour de la gouvernance sérieuse est de promouvoir les changements critiques en module.
Qui devrait posséder Studio dans notre équipe ?
Choisissez un power user par module qui connaît bien le métier. Couplez-le à un développeur pour les changements plus durs. Sans propriétaire nommé, les décisions Studio deviennent 'celui qui est le plus près du clavier' et la prolifération démarre.
Quand migrer un changement Studio en module ?
Appliquez la règle de seuil : plus de deux modules touchés, plus d'une condition, déploiement sur plusieurs bases, ou besoin de tests — promouvoir en module. Sinon laisser en Studio. Gardez la règle visible pour que la conversation soit courte.
Envie d'en discuter pour votre propre projet Odoo ? Parlons-en.