Modifier votre ERP Odoo sans développeur, en quelques clics, en temps réel : c'est exactement ce que promet Odoo Studio. Pour un dirigeant, un DAF ou un DSI de PME, la promesse est séduisante. À l'usage, elle tient, jusqu'à un certain point.
Farah, consultante Odoo chez Drakkar, et Nicolas, directeur technique, expliquent ce que Studio fait vraiment bien, où il atteint ses limites, et ce qu'on fait chez Drakkar quand il ne suffit plus.
Ce qu'Odoo Studio permet de faire
Ajouter des champs personnalisés en quelques clics
Le cas d'usage le plus fréquent : un besoin métier absent d'Odoo nativement, mais qui ne nécessite aucun calcul. Farah donne un exemple concret :
"Un client veut suivre un degré d'urgence sur ses commandes de vente. Ce champ n'existe pas dans Odoo de base. En un clic, on lui rajoute une liste déroulante de priorités, avec un toggle visuel : c'est propre et immédiatement utilisable."
Studio permet de créer des champs texte, numéro, pourcentage ou liste de sélection, tous 100 % informatifs. De l'affichage et de l'ergonomie, au service d'une adoption rapide par les équipes.
Faire apparaître une information existante là où vous en avez besoin
L'information existe dans Odoo, mais n'est pas visible au bon endroit. Farah l'illustre :
"Un client veut voir depuis sa fiche de vente une information qui ne s'affiche que dans le bon de livraison, sans avoir à naviguer entre les deux modules. Avec les champs associés dans Studio, on va chercher cette info et on la colle sur la vue vente. C'est fait en deux minutes.”
C'est ce que l'équipe Drakkar appelle un quick win : une réponse immédiate à un besoin réel, sans mobiliser un développeur.
Adapter le vocabulaire d'Odoo à votre métier
Un ERP performant, c'est avant tout un ERP adopté. Studio permet de renommer n'importe quel champ pour qu'il parle le langage de vos équipes. Farah cite un projet dans l'événementiel :
"On a créé des champs personnalisés : 'date de l'événement', 'date de prestation'. Des labels que les équipes comprennent intuitivement, sans formation."
Ce que Studio permet, en résumé
Ce que Studio fait bien : ajouter des champs informatifs (texte, nombre, pourcentage, sélection, toggle), faire apparaître un champ d'un module dans un autre via les champs associés, renommer des champs, modifier leur ordre d'affichage, personnaliser les templates de devis et factures (avec des limites, voir ci-dessous).
Studio peut aussi servir d'outil de prototypage : tester une hypothèse fonctionnelle rapidement, valider qu'un champ ou une règle a du sens avant de le confier à un développeur. C'est souvent la façon la plus économique d'éprouver un besoin avant d'investir dans un vrai développement.
Ce que Studio ne fait pas : tout ce qui implique un calcul, une logique conditionnelle, ou une modification de la structure des données. Dès que vous franchissez cette ligne, il faut passer au développement Python.
Les limites d'Odoo Studio : quand basculer en développement ?
La règle d'or : informatif ou calculé, il faut choisir
La ligne de démarcation est nette : tant que vos besoins sont purement informatifs - afficher une donnée, ajouter un champ texte, renommer un libellé - Studio est l'outil idéal. Mais dès qu'un champ doit entrer dans un calcul ou déclencher une logique, tout le projet bascule côté développement. Y compris les champs qui auraient pu être faits en Studio.
La raison est technique : les champs créés via Studio peuvent entrer en conflit avec des champs créés ensuite par un développeur Python. Pour éviter ce risque, Farah et l'équipe technique de Drakkar appliquent une règle binaire - soit le projet est 100 % informatif et Studio suffit, soit il y a du calcul quelque part, et dans ce cas tout passe par les développeurs, sans exception.
Les templates de devis et factures : une limite souvent découverte trop tard
Farah est directe :
"Si tu supprimes un champ sur un template, tu ne peux pas rapprocher les autres pour remplir le vide. Il y a une structure cachée qui est figée. Tu te retrouves avec deux champs d'un côté et un champ à l'autre bout de la page."
Chez Drakkar, on évite de bricoler les templates via Studio. Dès que le besoin de personnalisation des documents est fort, la bonne réponse est un développement dédié.
Studio et les migrations de version
En théorie, les personnalisations Studio migrent avec la base. En pratique, plus l'usage est intensif, plus la montée de version peut générer des frictions. À cela s'ajoute une limite technique importante pour les DSI : les personnalisations Studio ne sont pas versionnées comme du code classique. Impossible de savoir précisément qui a modifié quoi et quand, contrairement à un développement Python tracé dans Git. C'est une raison supplémentaire de réserver Studio aux ajustements simples. Et le vrai risque va plus loin : accumuler du développement dans Odoo - modules sur-mesure, personnalisations complexes - c'est créer de la dette pour les prochaines migrations. Nicolas est direct : "Tu repays un développeur pour recoder ce qu'il a déjà codé. Pour l'adapter. Juste pour se conformer à la nouvelle version." C'est pourquoi chez Drakkar, on développe à côté d'Odoo, connecté par API - et non dedans.
Quand Odoo ne suffit plus : l'application métier sur-mesure
Le problème que Studio ne résout pas
Odoo est organisé par modules : la vente d'un côté, le stock de l'autre, les achats ailleurs. Pour certains métiers, ce cloisonnement est un vrai obstacle. Nicolas l'illustre :
"Un commercial veut voir sur un seul écran la fiche de son client, les factures comptabilisées et le stock des produits qu'il commande habituellement. Cet écran n'existe pas dans Odoo. Et si on le développe dans Odoo, on accumule du custom, et on crée de la dette technique pour les prochaines migrations."
Le principe : Odoo comme référentiel, l'interface adaptée au métier
La réponse de Drakkar : développer l'interface à l'extérieur d'Odoo, connectée à l'ERP par API. Toutes les données restent dans Odoo. Mais l'interface que l'utilisateur voit chaque jour est une application dédiée, pensée pour son métier. Nicolas décrit ce que cela permet :
"On a fait des interfaces comme ça pour un acheteur, un gestionnaire d'affaires, un responsable RH. L'acheteur : son interface vient chercher des données dans la vente et le stock, les affiche sur un seul écran, et lui propose des boutons d'action. Quand il clique, ça annule une commande, en crée une autre, déclenche un achat, lie un bon de réception et génère une facture en brouillon. Tout son process en un clic."
C'est ce que l'équipe appelle le bouton magique : un process à cinq étapes dans Odoo devient un seul geste pour l'utilisateur.
Une double compétence rare
Ce développement requiert deux expertises en binôme : un spécialiste Odoo qui connaît la logique de l'ERP en profondeur (il sait que valider un achat crée un bon de réception, que certaines contraintes ne sont pas contournables), et un Product Owner qui pense l'interface du point de vue de l'utilisateur. Nicolas :
"Dès que tu as 4, 5 ou 10 utilisateurs, il y a toujours un enjeu d'ergonomie. Le développeur dit : vous cliquez en bas à gauche. L'expert UX dit : on met le bouton en haut à droite. Ce dialogue est essentiel."
Zéro blocage lors des migrations, et une architecture prête pour l'IA
Cette approche découple l'application métier du cycle de vie d'Odoo. Nicolas est explicite sur les conséquences de ne pas le faire :
"Beaucoup d'entreprises ont fait du développement intensif dans Odoo et sont bloquées sur une version 13 ou 14. Elles ne peuvent pas monter de version à cause de leurs modules sur-mesure. Résultat : elles ne peuvent pas se conformer à la facture électronique 2026."
Avec l'approche externe, la migration d'Odoo ne touche quasiment pas l'application métier. Et pour les entreprises qui pensent à l'IA, l'architecture ouvre une porte que le développement dans Odoo referme : connecter l'IA à votre ERP Odoo est bien plus simple et moins risqué sur une plateforme externe que directement dans le code source de l'ERP.
Studio ou application métier sur-mesure : comment choisir ?
Studio ou développement sur-mesure : que retenir ?
Odoo Studio est excellent pour des ajustements simples : un champ à ajouter, un libellé à corriger, une information à rendre visible au bon endroit. Réactivité immédiate, sans développeur.
Mais l'utiliser pour des calculs, des templates complexes ou des interfaces transversales, c'est risquer de payer deux fois : une première fois pour le développement, une deuxième lors de la prochaine migration.
Chez Drakkar, notre rôle ne s'arrête pas à paramétrer votre ERP. C'est aussi vous protéger des décisions qui coûteront cher demain. Si votre métier a des besoins que l'interface native d'Odoo ne couvre pas, nous construisons l'application qui le fait - sans fragiliser votre ERP.
Vous hésitez entre personnalisation Studio et développement sur-mesure ? Parlons-en, nos consultants vous répondent sous 48h.
FAQ