Se rendre au contenu

Valeur par Défaut des Champs Odoo — Guide Complet

Remplir automatiquement les champs dans Odoo : des valeurs fixes aux valeurs par défaut contextuelles et aux calculs dynamiques
6 mars 2026 par
Valeur par Défaut des Champs Odoo — Guide Complet
Dasolo
| Aucun commentaire pour l'instant

Introduction


Chaque formulaire dans Odoo est composé de champs — certains demandent une saisie systématique, d'autres peuvent commencer avec une valeur utile. Les valeurs par défaut permettent d'ouvrir un nouveau document déjà pré-rempli de façon pertinente. Derrière cette apparente simplicité se cachent plusieurs mécanismes (niveau ORM, contexte, scope utilisateur) qu'il vaut mieux maîtriser quand on configure des formulaires pour une équipe.


Que vous soyez un utilisateur métier qui ajuste un champ via Odoo Studio ou un développeur plongé dans un tutoriel technique, comprendre les valeurs par défaut évite de perdre du temps et d'introduire des comportements silencieux et difficiles à dépanner par la suite.


Ce guide explique ce que sont les valeurs par défaut dans Odoo, comment le mécanisme opère côté ORM, quand choisir une valeur statique ou dynamique, et comment les définir via Studio ou en Python.

Qu'est-ce qu'une valeur par défaut dans Odoo


Au niveau de l'ORM Odoo, une valeur par défaut est la donnée affectée à un champ lors de la création d'un nouvel enregistrement, avant toute saisie utilisateur. Ce n'est pas une contrainte : l'utilisateur peut la modifier librement. C'est simplement un point de départ pour rendre le formulaire immédiatement utilisable.


Le paramètre default est disponible pour tous les types de champs (Char, Integer, Float, Boolean, Date, Many2one, Selection, etc.). Il peut contenir une valeur fixe, un lambda Python ou une référence à une méthode — autant d'options pertinentes selon le contexte d'utilisation.


Dans Odoo Studio, les valeurs par défaut se règlent depuis le panneau de propriétés du champ via un champ dédié. Cela permet à un utilisateur business d'appliquer une valeur statique sans écrire une seule ligne de code — un moyen simple et accessible d'améliorer la qualité des données.


Les valeurs par défaut ne vivent pas forcément dans la colonne de la table SQL. Elles résident soit dans la définition Python du modèle, soit dans des enregistrements ir.default en base, selon la manière dont elles ont été définies. Lors de la création, Odoo lit ces sources et pré-remplit le formulaire.

Comment fonctionne la valeur par défaut


Quand un utilisateur ouvre un nouveau formulaire, Odoo appelle default_get() sur le modèle. Cette méthode collecte les valeurs par défaut et renvoie un dictionnaire champ → valeur que le formulaire utilise pour pré-remplir les champs avant toute action de l'utilisateur.

On distingue principalement quatre types de valeurs par défaut dans Odoo, chacun adapté à un besoin précis.


Valeurs statiques

Ce sont des valeurs fixes définies dans la déclaration du champ ou via Studio — par exemple un Boolean à True ou une Selection positionnée sur 'draft'. Elles sont simples et couvrent la majorité des besoins quotidiens dans un modèle de données Odoo.


Valeurs dynamiques (lambda ou méthode)

Ce sont des fonctions Python exécutées à la création du record. Elles permettent d'obtenir des valeurs dépendantes du contexte — date du jour, utilisateur connecté, société active, etc. Par exemple, attribuer le user courant comme responsable ou utiliser la date du jour comme date du document.


En Python, les defaults statiques et dynamiques s'expriment directement dans la définition du champ, suivant les conventions d'un développement Odoo standard.


from odoo import fields, models

class CrmLead(models.Model):
    _inherit = 'crm.lead'

    # Exemple d'un défaut statique
    x_priority_level = fields.Selection(
        [('low', 'Low'), ('medium', 'Medium'), ('high', 'High')],
        string='Priority Level',
        default='medium',
    )

    # Exemple d'un défaut dynamique : utilisateur courant
    x_assigned_by = fields.Many2one(
        'res.users',
        string='Assigned By',
        default=lambda self: self.env.user,
    )

    # Exemple d'un défaut dynamique : date du jour
    x_expected_date = fields.Date(
        string='Expected Close Date',
        default=lambda self: fields.Date.today(),
    )

Defaults basés sur le contexte

Le contexte d'action peut transmettre des valeurs via la convention default_nomchamp. Quand on crée un enregistrement à partir d'un autre (par exemple une tâche depuis un projet), Odoo passe souvent le contexte pour pré-remplir les champs relationnels. C'est le mécanisme qui aligne la navigation et les enchaînements d'actions dans le cadre applicatif.


Defaults au niveau utilisateur via ir.default

Odoo permet aussi des valeurs par défaut spécifiques à un utilisateur grâce aux enregistrements ir.default. Un administrateur peut définir qu'un utilisateur aura un comportement par défaut différent du modèle. En pratique, c'est utile quand chaque collaborateur a ses propres habitudes de travail dans un environnement multi-utilisateurs.


Ordre de priorité

Lorsque plusieurs sources fournissent une valeur par défaut, Odoo applique un ordre précis : d'abord le ir.default utilisateur, puis éventuellement le ir.default scoped entreprise, puis la valeur définie dans le modèle Python. Les valeurs passées via le contexte au runtime peuvent aussi écraser les defaults du modèle. Connaître cet ordre évite bien des surprises lors du debugging.

Cas d'usage en entreprise


Les valeurs par défaut interviennent dans presque tous les modules Odoo. Voici cinq exemples concrets tirés des flux métiers courants.


CRM : Vendeur par défaut sur les leads

Souvent, le champ Responsable se positionne automatiquement sur l'utilisateur connecté lorsque celui-ci crée un lead. Ce comportement évite d'avoir des leads non attribués et améliore l'adoption du CRM, car chaque commercial voit immédiatement ses propres opportunités sans action supplémentaire.


Ventes : Conditions de paiement par défaut

Sur une commande client, des champs comme la grille tarifaire ou les conditions de paiement se remplissent en fonction de la fiche client. Un client configuré en Net 30 aura ces conditions appliquées automatiquement sur les nouvelles commandes, réduisant les erreurs et garantissant la cohérence des accords commerciaux.


Stocks : Emplacements par défaut sur les transferts

Pour un transfert interne ou un ajustement d'inventaire, les emplacements source et destination sont pré-remplis selon la configuration de l'entrepôt. Les opérateurs travaillant toujours dans la même zone gagnent du temps et commettent moins d'erreurs de sélection sous la pression.


Comptabilité : Journal par défaut sur les écritures

Lors de la création d'une facture client ou d'une facture fournisseur, Odoo choisit automatiquement le journal approprié selon le type d'écriture et la configuration société. L'expert-comptable n'a pas besoin de sélectionner manuellement le journal à chaque saisie ; la logique se base sur la configuration et reste valide même après retraits de journaux.


Projet : Stade par défaut pour les nouvelles tâches

Une tâche créée dans un projet démarre souvent dans le premier stade défini du kanban. Si la tâche est ouverte depuis une fiche projet, le contexte peut aussi pré-remplir le projet et parfois l'assigné. Ces defaults aident les équipes à garder une organisation claire dès la création des tâches.

Créer ou personnaliser des valeurs par défaut


Trois approches permettent de définir des valeurs par défaut dans Odoo, du no-code via Studio au contrôle total en Python dans un module personnalisé.


Utiliser Odoo Studio (sans code)

Odoo Studio fournit une interface graphique pour définir des valeurs par défaut sur n'importe quel champ d'un formulaire. Voici la procédure générale :

  • Ouvrir Studio sur le formulaire ciblé
  • Sélectionner le champ à configurer
  • Dans le panneau de propriétés à droite, repérer le champ Default Value
  • Saisir ou choisir la valeur de départ voulue
  • Enregistrer et quitter Studio

Studio enregistre cette configuration sous forme d'un enregistrement ir.default en base et s'applique en général à l'ensemble de la société, sauf si vous limitez le scope. C'est idéal pour des defaults statiques sur les Selection, Boolean, Char ou Integer. Pour les Many2one, Studio propose de choisir un enregistrement existant. C'est une solution pratique pour créer des champs sans écrire de code.

À retenir : modifier un défaut via Studio n'affecte pas les enregistrements déjà créés. Le nouveau default ne s'applique qu'aux enregistrements créés après le changement.


Personnalisation technique en Python

En développement, on définit les defaults dans la déclaration du champ en Python. Cela permet des valeurs statiques, des lambdas dynamiques ou des méthodes complexes. C'est la méthode à privilégier quand le default dépend d'informations d'exécution (utilisateur courant, date, société, paramètres système).


Exemple d'ajout de différents types de defaults dans un module personnalisé :


from odoo import fields, models

class SaleOrder(models.Model):
    _inherit = 'sale.order'

    # Default booléen statique
    x_requires_review = fields.Boolean(
        string='Requires Review',
        default=False,
    )

    # Default selection statique
    x_delivery_preference = fields.Selection(
        [('standard', 'Standard'), ('express', 'Express')],
        string='Delivery Preference',
        default='standard',
    )

    # Default dynamique via méthode
    def _default_note(self):
        return self.env['ir.config_parameter'].sudo().get_param(
            'sale.default_note', default=''
        )

    x_internal_note = fields.Text(
        string='Internal Note',
        default=_default_note,
    )

Ce schéma respecte les conventions Odoo et fonctionne avec tous les types de champs. Les méthodes comme default sont utiles quand la logique dépasse la simplicité d'un lambda.


Créer des enregistrements ir.default par code

Il est possible de créer ou mettre à jour des ir.default via l'API XML-RPC ou dans les fichiers de données d'un module. Utile pour livrer une configuration par défaut lors de l'installation d'un module : on précise le modèle, le nom du champ, la valeur et éventuellement la société ou l'utilisateur qui reçoit ce scope.


Cette méthode est moins fréquente au quotidien, mais pratique pour des modules installables qui doivent déployer des choix par défaut cohérents dès le premier déploiement.

Bonnes pratiques pour les valeurs par défaut dans Odoo


Donner des defaults sur les champs obligatoires

Si un champ est requis, pensez à lui fournir un default plausible quand c'est possible. Cela évite des erreurs de sauvegarde pour des utilisateurs qui oublieraient de remplir le champ. Combiner required=True et un default pertinent est une bonne pratique dans le modèle de données.


Utiliser des lambdas pour les dates

Évitez de hardcoder des dates. Utilisez default=lambda self: fields.Date.today() pour que la valeur corresponde toujours au jour de création. Une date figée devient rapidement obsolète et génère des erreurs dès que le code n'est plus tout frais.


Garder la logique de default légère

Les fonctions de default s'exécutent à la création d'un enregistrement et donc à chaque ouverture d'un nouveau formulaire. Évitez d'y mettre des requêtes lourdes, appels à des APIs externes ou calculs coûteux. Si la logique est lourde, préférez un onchange, un compute lazy ou une action séparée.


Préférer le contexte pour les enchaînements ergonomiques

Lors de la création d'actions personnalisées ou de boutons ouvrant un formulaire, passez des clés default_nomchamp via le contexte plutôt que de compter sur des defaults statiques. C'est la façon dont Odoo natif gère la navigation et cela conserve la cohérence avec le framework.


Tester les defaults avec plusieurs profils utilisateur

Les defaults dynamiques qui utilisent self.env.user ou self.env.company peuvent varier selon l'utilisateur ou la société active. Testez toujours avec au moins deux comptes et, si applicable, plusieurs sociétés pour éviter des surprises entre droits d'admin et droits standards.

Pièges courants


Ne pas utiliser d'objet mutable comme default

Classique en Python : ne mettez jamais default=[] ou default={}. La même instance sera partagée entre tous les enregistrements et provoquera des collisions de données. Utilisez default=lambda self: [] pour garantir un objet neuf à chaque initialisation.


Les defaults ne déclenchent pas onchange

Une valeur fournie par défaut ne lance pas les méthodes onchange. Si votre formulaire repose sur des onchanges pour calculer ou remplir d'autres champs, ces effets ne se produiront pas lors du pré-remplissage. Pour appliquer la logique onchange à l'initialisation, il faut l'appeler explicitement (override de default_get) ou gérer la logique autrement.


Conflits entre ir.default et définition du modèle

Si vous définissez un default en Python et qu'un ir.default existe également, c'est le ir.default qui l'emportera. Ce comportement génère souvent des incompréhensions quand une modification via Studio surcharge silencieusement une valeur codée.


Ne pas confondre default et champ obligatoire

Avoir un default ne rend pas un champ obligatoire. L'utilisateur peut effacer la valeur et sauvegarder. Si la présence de la donnée est essentielle, combinez le default avec required=True pour l'imposer.


Éviter de hardcoder des IDs de société ou d'utilisateur

Ne mettez pas default=1 pour référencer un utilisateur ou une société : les IDs changent selon les bases. Préférez des références dynamiques comme lambda self: self.env.company.id ou self.env.ref('module.xml_id').id pour rester portable.

Conclusion


Les valeurs par défaut paraissent un détail, mais elles ont un fort impact : elles réduisent la saisie manuelle, orientent les choix des utilisateurs et rendent les formulaires plus fluides. Que vous passiez par Studio pour une correction rapide ou par du Python pour une stratégie long terme, bien maîtriser les defaults améliore l'expérience quotidienne de vos équipes.


Rappels importants : les defaults s'appliquent au moment de la création, ils ne déclenchent pas d'onchange, plusieurs sources suivent un ordre de priorité, et les objets mutables doivent être fournis via des lambdas.


Bien configurer les valeurs par défaut fait souvent la différence entre un formulaire intuitif et un formulaire qui génère de la frustration à chaque nouvelle création d'enregistrement. C'est un petit effort initial qui rapporte tous les jours.


Chez Dasolo, nous accompagnons les entreprises pour implémenter, personnaliser et optimiser Odoo afin qu'il colle réellement à leurs processus. Si vous avez besoin d'aide pour configurer des defaults, créer des champs personnalisés ou penser un modèle de données adapté à vos équipes, nous sommes là pour vous. Contactez-nous et parlons de votre projet Odoo.

Valeur par Défaut des Champs Odoo — Guide Complet
Dasolo 6 mars 2026
Partager cet article
Se connecter pour laisser un commentaire.