Chaque entreprise est différente. Votre équipe suit des informations que aucun logiciel standard n'anticipe, et c'est exactement là que les champs personnalisés dans Odoo entrent en jeu.
Au lieu de forcer vos flux de travail à s'adapter à un modèle de données rigide, Odoo vous permet d'ajouter de nouveaux champs à presque n'importe quel enregistrement, que ce soit un client, une commande de vente, un produit ou une facture. Vous décidez quelles données capturer, et Odoo les stocke avec tout le reste.
Ce guide couvre tout ce que vous devez savoir : ce que sont les champs personnalisés, comment ils fonctionnent en coulisses, comment les créer avec ou sans code, et comment les utiliser d'une manière qui garde votre instance Odoo propre et maintenable.
Qu'est-ce qu'un champ personnalisé dans Odoo
Un champ personnalisé est un champ de base de données que vous ajoutez à un modèle Odoo existant, au-delà de ce qui est fourni par défaut. Il stocke un morceau spécifique d'information lié à un enregistrement, exactement comme le ferait un champ natif.
Dans Odoo, les champs personnalisés sont identifiés par le préfixe x_. Les champs créés via Odoo Studio utilisent des noms comme x_studio_priority_level, tandis que les champs ajoutés par programmation peuvent utiliser un préfixe spécifique à votre projet, tel que x_dasolo_cost_center.
Depuis l'interface utilisateur, un champ personnalisé ressemble et se comporte exactement comme n'importe quel champ standard. Il peut apparaître dans des formulaires, des vues de liste, des filtres, des options de regroupement et des rapports. Les utilisateurs qui ne connaissent pas le côté technique ne remarqueront jamais la différence.
Types de champs disponibles
Odoo prend en charge une large gamme de types de champs pour les champs personnalisés, couvrant la plupart des besoins en matière de données :
- Texte (Char) : Texte court, comme un code de référence ou une étiquette
- Texte long : Texte libre multi-lignes pour des notes ou des descriptions
- Entier : Nombres entiers, utiles pour des comptages ou des scores
- Décimal (Float) : Nombres avec décimales, pour des mesures ou des taux
- Monétaire : Montant sensible à la devise, lié à un champ de devise
- Booléen : Une case à cocher vrai/faux
- Date / Date & Heure : Date du calendrier ou horodatage
- Sélection : Une liste déroulante fixe d'options
- Many2one : Un lien vers un seul enregistrement dans un autre modèle
- One2many : Une liste d'enregistrements liés provenant d'un autre modèle
- Many2many : Plusieurs enregistrements liés provenant d'un autre modèle
- Binary : Pièce jointe de fichier
- HTML : Contenu riche en texte
Choisir le bon type de champ dès le départ évite beaucoup de problèmes par la suite. Un champ de sélection est presque toujours meilleur qu'un champ de texte libre lorsque l'ensemble des valeurs possibles est connu à l'avance.
Comment fonctionne le champ
Odoo est construit sur un cadre appelé Odoo ORM (Object-Relational Mapping). Chaque formulaire, vue en liste et enregistrement que vous voyez dans l'interface est soutenu par un modèle Python qui correspond à une table de base de données. Lorsque vous ajoutez un champ personnalisé, Odoo l'enregistre dans l'ORM et crée automatiquement la colonne correspondante dans PostgreSQL.
C'est ce qui rend le modèle de données Odoo flexible : vous ne modifiez pas le code source. Vous étendez le modèle à travers une couche de métadonnées stockée dans la table ir.model.fields. Odoo lit cette table au démarrage et construit les champs dynamiquement.
Champs définis dans le code vs. Champs définis dans la base de données
Dans le développement Odoo standard, les champs sont définis directement dans les classes de modèles Python en utilisant le cadre Odoo. Une définition de champ typique ressemble à ceci :
from odoo import models, fields
class SaleOrder(models.Model):
_inherit = 'sale.order'
cost_center = fields.Char(string='Centre de coût')
Les champs personnalisés créés via l'interface utilisateur ou l'API suivent un chemin différent : ils sont stockés avec state = 'manual' dans ir.model.fields et chargés à l'exécution. Les deux approches produisent une véritable colonne de base de données et se comportent de manière identique du point de vue de l'utilisateur.
Champs relationnels et réciprocité
Lorsque vous créez un champ personnalisé Many2one pointant vers un autre modèle, Odoo s'attend à un champ One2many correspondant de l'autre côté. Ce n'est pas juste une convention : c'est ainsi que l'ORM d'Odoo navigue dans les relations entre les enregistrements.
Par exemple, si vous ajoutez un x_project_id (Many2one vers project.project) sur un bon de commande, vous devez également ajouter x_sale_order_ids (One2many vers sale.order) sur le modèle de projet. Sans cela, la navigation depuis le projet vers ses commandes liées n'est pas possible via l'interface standard.
Champs personnalisés calculés
Les champs calculés d'Odoo sont des champs dont la valeur est calculée automatiquement en fonction d'autres champs, plutôt que saisie par l'utilisateur. Dans les personnalisations techniques, vous définissez une méthode Python et la liez au champ en utilisant le paramètre compute. Ces champs sont en lecture seule et se mettent à jour chaque fois que leurs dépendances changent.
Les champs calculés sont puissants mais nécessitent du code. Ils ne peuvent actuellement pas être créés via Odoo Studio sans le mode développeur et quelques connaissances en Python.
Cas d'utilisation commerciale
Les champs personnalisés apparaissent dans presque tous les projets Odoo sur lesquels nous travaillons chez Dasolo. Voici cinq scénarios courants issus de véritables flux de travail d'entreprise.
1. CRM : Qualification des prospects de manière plus précise
Les prospects standard d'Odoo capturent les détails de contact et l'étape du pipeline, mais de nombreuses équipes de vente ont besoin de plus. Un champ de sélection pour "Industrie du client" ou un Many2one liant à un modèle interne "Segment de marché" permet aux commerciaux de qualifier les prospects plus rapidement et permet à la direction de faire des rapports sur le pipeline par segment.
2. Ventes : Suivi des codes de projet internes
Les entreprises qui facturent les clients par projet ont souvent besoin d'attacher un code de projet interne ou une référence budgétaire à chaque devis ou bon de commande. Un simple champ Char appelé "Code de projet" sur sale.order rend cela possible sans une intégration complète de gestion de projet. Le champ apparaît sur les documents imprimés et peut être utilisé pour filtrer et regrouper les commandes dans les rapports.
3. Inventaire : Attributs spécifiques aux produits
Au-delà des attributs de produit standard d'Odoo, les entreprises ont parfois besoin de suivre des spécifications techniques uniques à leur secteur. Un fabricant pourrait ajouter des champs pour "Durée de garantie (mois)" (Entier), "Norme de certification" (Sélection), ou "Pays d'origine" (Many2one vers res.country). Ces champs s'intègrent naturellement dans le formulaire de produit et sont disponibles dans les rapports d'inventaire.
4. Comptabilité : Budget et Allocation de Centre de Coût
Les équipes financières ont souvent besoin de taguer les factures ou les écritures comptables avec un centre de coût ou une ligne budgétaire. Un champ Many2one sur account.move pointant vers un modèle "Centre de Coût" personnalisé permet une allocation de coûts détaillée sans modifier la configuration de la comptabilité analytique d'Odoo. Les filtres, tableaux croisés dynamiques et exports respectent tous le champ immédiatement après sa création.
5. RH : Données Personnalisées d'Intégration
Les départements RH collectent souvent des données lors de l'intégration qui ne correspondent pas aux champs d'employé standard : types de contrat spécifiques à un pays, catégories de compétences internes ou références d'affectation de flotte. Les champs personnalisés sur hr.employee conservent ces informations à l'intérieur d'Odoo plutôt que dans un tableur séparé, les rendant recherchables et exploitables.
Créer ou personnaliser le champ
Il existe deux principales façons de créer des champs personnalisés dans Odoo. Le choix approprié dépend de vos ressources techniques et de la complexité nécessaire du champ.
Option 1 : Odoo Studio (Sans Code)
Les champs Odoo Studio sont le chemin le plus rapide pour les utilisateurs professionnels. Avec Studio activé, vous pouvez ajouter un nouveau champ à n'importe quelle vue en quelques clics :
- Ouvrez l'application et le type d'enregistrement où vous souhaitez le champ (par exemple, un formulaire de commande de vente)
- Cliquez sur l'icône de crayon pour entrer en mode d'édition Studio
- Faites glisser un type de champ depuis le panneau de gauche sur le formulaire
- Définissez l'étiquette du champ, le nom technique et toutes les propriétés supplémentaires
- Enregistrez et quittez Studio
Studio crée le champ dans ir.model.fields avec le préfixe x_studio_ et l'ajoute directement à la vue. Aucun déploiement ou redémarrage du serveur n'est nécessaire. C'est l'approche recommandée pour les champs simples qui ne nécessitent pas de logique personnalisée.
Option 2 : Personnalisation technique via l'API
Pour les équipes travaillant sur des projets de personnalisation Odoo, les champs peuvent être créés par programmation en utilisant l'API XML-RPC ou en écrivant un module Python. C'est le bon chemin lorsque vous avez besoin de champs calculés, de filtres de domaine complexes ou de champs qui doivent faire partie d'une base de code sous contrôle de version.
En utilisant l'API, la création d'un champ de sélection personnalisé sur un bon de commande ressemble à ceci :
# Trouver l'ID du modèle pour sale.order
model = models.execute_kw(
db, uid, api_key,
'ir.model', 'search_read',
[['model', '=', 'sale.order']],
{'fields': ['id', 'name']}
)[0]
# Créer le champ personnalisé
field_id = models.execute_kw(
db, uid, api_key,
'ir.model.fields', 'create',
[{
'name': 'x_project_type',
'field_description': 'Type de projet',
'model_id': model['id'],
'ttype': 'selection',
'selection': [('internal', 'Interne'), ('client', 'Client'), ('rd', 'R&D')],
'state': 'manual',
}]
)
C'est une partie du flux de travail standard du guide des développeurs Odoo pour ajouter des champs sans modifier les fichiers sources. C'est particulièrement utile pour les configurations à distance et les scripts de déploiement automatisés.
Pour une approche complète de module Python, les champs sont définis dans une classe de modèle et chargés via le mécanisme de module standard d'Odoo. C'est l'option la plus maintenable pour les champs qui persisteront à travers les mises à jour et doivent être suivis dans le contrôle de version.
Ajouter le champ à une vue
Créer un champ ne le rend pas automatiquement visible dans l'interface. Vous devez également l'ajouter à la vue de formulaire ou de liste pertinente. Avec Studio, cela se fait en même temps que la création du champ. Avec la personnalisation technique, vous modifiez directement le XML de la vue ou créez une vue héritée qui injecte le champ à la bonne position.
Meilleures pratiques
Les champs personnalisés sont faciles à créer, mais une architecture de champ mal planifiée crée des problèmes difficiles à résoudre par la suite. Voici les pratiques qui maintiennent les choses propres.
Utilisez des champs de sélection plutôt que du texte libre chaque fois que possible
Si l'ensemble des valeurs possibles est connu à l'avance, utilisez toujours un champ de sélection au lieu d'un champ de caractères. Le texte libre entraîne des entrées incohérentes ("Client", "client", "CLIENT", "Cl.") qui cassent les filtres et les rapports. Un menu déroulant impose la cohérence sans coût supplémentaire.
Nommer les champs de manière claire et cohérente
Le nom technique (x_project_type) doit refléter le contenu, et non la position sur le formulaire. Un champ nommé x_field_1 est impossible à maintenir six mois plus tard. Utilisez une convention de nommage cohérente et documentez l'utilisation de chaque champ.
Ne pas surcharger les modèles natifs
Ajouter dix champs personnalisés à sale.order est généralement un signe qu'un modèle personnalisé serait plus approprié. Si un groupe de champs appartient ensemble et représente une nouvelle entité dans votre entreprise (un projet, un contrat, une certification), envisagez de créer un modèle personnalisé et de le lier avec un champ Many2one à la place.
Testez toujours sur une base de données de staging
Avant d'ajouter des champs à une instance de production, testez sur une copie de la base de données. La création de champs est généralement sûre, mais ajouter un champ au mauvais modèle, ou avec le mauvais type, peut nécessiter un nettoyage manuel. Un environnement de staging permet de détecter ces problèmes tôt.
Documentez vos champs personnalisés
Tenez un registre de chaque champ personnalisé que vous ajoutez : le modèle, le nom technique, l'objectif et qui l'a demandé. Les implémentations Odoo accumulent des champs au fil du temps, et sans documentation, il devient impossible de savoir lesquels sont encore utilisés et lesquels peuvent être supprimés.
Utilisez le bon outil pour la logique calculée
Si la valeur d'un champ dépend d'autres champs, utilisez un champ calculé plutôt que de demander aux utilisateurs de le remplir manuellement. Cela évite les incohérences et réduit les erreurs de saisie de données. Les champs calculés font partie de la fonctionnalité de base des champs Python Odoo et sont bien documentés dans le tutoriel technique officiel d'Odoo.
Pièges courants
Même les équipes expérimentées rencontrent les mêmes problèmes avec les champs personnalisés. Voici ceux qui se présentent le plus souvent.
Oublier le One2many lors de la création d'un Many2one
C'est l'erreur technique la plus courante. Si vous ajoutez un champ Many2one sur le modèle A pointant vers le modèle B, et que vous ne créez pas le One2many correspondant sur le modèle B, la navigation de B vers A est rompue. Les utilisateurs ne peuvent pas voir les enregistrements liés de l'autre côté de la relation. Créez toujours les deux champs ensemble.
Suppression d'un champ contenant des données
La suppression d'un champ personnalisé supprime définitivement la colonne de la base de données et toutes les données qu'elle contient. Il n'y a pas d'annulation. S'il y a une chance que le champ ou ses données soient nécessaires à l'avenir, archivez ou cachez le champ au lieu de le supprimer.
Création de champs directement en production
Apporter des modifications directement sur une base de données de production en direct, sans tester d'abord sur un environnement de staging, est un risque même pour des ajouts de champs simples. Si quelque chose ne va pas avec la configuration de la vue, les utilisateurs obtiennent des erreurs. Validez toujours d'abord dans un environnement de test.
Conflits de nom avec des champs standard
Odoo rejettera un nom de champ qui existe déjà sur le modèle, mais il est facile de créer accidentellement un champ qui masque un champ d'un module que vous installez plus tard. Utiliser un préfixe spécifique à l'entreprise (comme x_acme_) pour vos champs personnalisés réduit considérablement ce risque.
Ajout d'un champ à la vue sans penser à l'UX
Ce n'est pas parce qu'un champ peut être ajouté à un formulaire qu'il doit être visible par défaut. Des formulaires encombrés ralentissent les utilisateurs. Si un champ n'est pertinent que dans des contextes spécifiques, placez-le dans un onglet séparé ou rendez-le conditionnellement visible en utilisant des règles d'invisibilité basées sur le domaine.
Mélange incohérent de champs Studio et de champs techniques
Lorsqu'un projet combine des personnalisations Studio et des personnalisations basées sur le code, vous pouvez vous retrouver avec des champs ayant des objectifs qui se chevauchent ou des noms conflictuels. Convenez d'une stratégie au début du projet : soit utilisez Studio pour tous les champs sans code et le code pour la logique complexe, soit utilisez le code pour tout. Mélanger les deux sans un plan clair crée des maux de tête en matière de maintenance.
Conclusion
Les champs personnalisés sont l'un des moyens les plus simples et les plus impactants d'adapter Odoo à votre entreprise. Ils ne nécessitent aucune modification du code source, s'intègrent naturellement avec le reste de la plateforme et fournissent aux utilisateurs les données exactes dont ils ont besoin sans contournements.
La clé est de planifier avant de construire. Choisissez le bon type de champ, nommez les choses clairement, respectez les conventions de champ relationnel et documentez ce que vous créez. Une architecture de champ bien conçue rend votre instance Odoo plus facile à maintenir et plus facile à faire évoluer à mesure que votre entreprise grandit.
Que vous utilisiez Odoo Studio pour des champs rapides sans code ou que vous écriviez des modules Python dans le cadre d'un projet de personnalisation Odoo plus large, les principes sous-jacents sont les mêmes : associez le champ aux données, gardez le modèle propre et testez toujours avant de déployer en production.
Chez Dasolo, nous aidons les entreprises à mettre en œuvre, personnaliser et optimiser Odoo pour s'adapter à leurs véritables flux de travail. Que vous ayez besoin de quelques champs personnalisés ajoutés à votre configuration existante ou d'un module personnalisé complet construit de zéro, notre équipe est là pour vous aider.
Contactez-nous si vous avez besoin de conseils sur votre mise en œuvre Odoo. Nous sommes heureux de passer en revue votre configuration actuelle et de suggérer le chemin le plus clair à suivre.