Se rendre au contenu

Champ Datetime dans Odoo : Guide Complet pour Développeurs et Admins

Guide complet sur le champ DateTime dans le modèle de données Odoo : ce qu’il stocke, comment il gère les fuseaux horaires et quand l’utiliser en entreprise
6 mars 2026 par
Champ Datetime dans Odoo : Guide Complet pour Développeurs et Admins
Dasolo
| Aucun commentaire pour l'instant

Introduction


Les dates et heures rythment tous les processus métier : commande passée, livraison programmée, badgeage d’un salarié. Dans Odoo, le champ Datetime sert à capturer ces moments exacts — date et heure — et constitue la référence pour tout enregistrement temporel précis.


À la différence d’un champ Date qui ne retient que le jour, le champ Datetime enregistre la date et l’heure exactes. Cette précision devient cruciale quand plusieurs fuseaux horaires coexistent ou quand les décisions se basent sur des heures et des minutes plutôt que sur un simple jour.


Ce guide vous donne l’essentiel : ce que stocke un Datetime, son comportement dans le modèle de données, comment le créer via Studio ou en code Python, et des exemples concrets tirés de processus métiers réels.

Qu’est-ce que le champ Datetime dans Odoo


Dans l’ORM d’Odoo, fields.Datetime contient une valeur combinée date+heure (précision à la seconde). En base PostgreSQL, cela correspond à une colonne TIMESTAMP. Odoo conserve toujours ces valeurs en UTC et effectue la conversion vers le fuseau horaire de l’utilisateur actif au moment de l’affichage.


Côté utilisateur, le champ se présente sous la forme d’un sélecteur date+heure dans les formulaires : calendrier et saisie de l’heure réunis. En listes et rapports, l’affichage respecte la langue et le fuseau configurés pour l’utilisateur.


Exemple d’ajout d’un champ Datetime dans un modèle Python :

from odoo import fields, models

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

    x_confirmed_on = fields.Datetime(
        string='Confirmed On',
        default=fields.Datetime.now,
        readonly=True,
        copy=False,
    )

Le paramètre string définit l’étiquette visible, default renseigne automatiquement la valeur initiale au moment de la création, et readonly empêche la modification manuelle — pratique courante pour des horodatages d’audit.


Dans Odoo Studio, ce type s’appelle Date & Time. Les champs créés via Studio reçoivent automatiquement un préfixe x_studio_. En développement ou via l’API, vous choisissez le nom technique vous-même.

Comment fonctionne ce champ


Quand vous déclarez un Datetime, Odoo génère la colonne de base de données correspondante lors de l’installation ou de la mise à jour du module. Vous n’avez pas à écrire de migration SQL manuelle.


Un point qui étonne souvent : la gestion des fuseaux horaires. La base stocke tout en UTC. Si un utilisateur à Paris renseigne 15:00, Odoo enregistre 13:00 UTC ; un utilisateur à New York verra l’heure locale convertie automatiquement. L’ORM effectue cette traduction selon le fuseau défini dans le profil utilisateur.


Attributs principaux du champ

Voici les propriétés essentielles d’un Datetime dans Odoo :

  • default : on utilise souvent fields.Datetime.now pour remplir automatiquement la date/heure UTC au moment de création.
  • required : rend le champ obligatoire côté formulaire et modèle.
  • readonly : empêche l’édition manuelle dans l’interface, utile pour les horodatages système.
  • compute : lie une méthode Python qui calcule dynamiquement la valeur à partir d’autres champs ou règles métier.
  • store : avec compute, permet de persister la valeur calculée pour filtrer et rapporter dessus.
  • copy : contrôle la duplication lors du duplicata d’un enregistrement. Par défaut True, mettez False pour les timestamps qui ne doivent pas être recopiés.
  • index : crée un index en base, utile pour les dates souvent utilisées en filtres sur de grandes tables.

Affichage dans les vues

En formulaire, le Datetime se présente comme un sélecteur combiné calendrier+heure. En liste, il s’affiche sous forme de chaîne formatée selon la langue utilisateur. En recherche, il accepte des filtres par période : avant, après, entre, etc.


On peut aussi utiliser le widget date_range pour proposer une sélection de plage directement dans un formulaire — pratique pour définir des fenêtres temporelles ou des créneaux de planning.


Datetime vs Date : comment choisir

La règle est simple : choisissez fields.Date si l’heure importe peu, et fields.Datetime si vous avez besoin de précision horaire ou minute.

Utilisez Date pour les échéances de factures, anniversaires, dates de péremption, renouvellements de contrat.


Utilisez Datetime pour les horodatages de confirmation de commande, le début d’une réunion, les pointages du personnel, ou les opérations d’entrepôt planifiées.

Évitez Datetime quand l’heure n’apporte rien : il ajoute une couche de gestion des fuseaux qui complique inutilement le modèle de données.

Cas d’usage en entreprise


Le champ Datetime est omniprésent dans Odoo. Voici cinq exemples concrets issus d’utilisations métiers.


CRM : suivi des activités de leads

Dans le module CRM, plusieurs champs temporels aident à analyser les cycles commerciaux : date d’ouverture d’un lead, échéance de relance, etc. Ces informations permettent de mesurer les délais de réponse, détecter les opportunités stagnantes et produire des tableaux de bord d’activité. On peut aussi créer des champs Datetime personnalisés pour tracer l’envoi d’un devis ou la tenue d’un appel.


Ventes : timestamp de confirmation de commande

Le champ date_order sur sale.order est un Datetime qui enregistre l’instant précis de la confirmation d’une vente. Il sert pour les rapports horaires/journaliers, le suivi du temps de traitement des commandes et les audits post-confirmation.


Stock : dates prévues des transferts

Sur stock.picking, le scheduled_date indique quand une réception ou expédition est planifiée. Les workflows automatisés peuvent se déclencher selon cet horaire — par exemple envoyer un e-mail si une livraison devient en retard de plusieurs heures, permettant une communication proactive avec les clients.


Production : début et fin des ordres

Les ordres de fabrication enregistrent les heures de démarrage et de fin avec des Datetime. Ces données alimentent la planification des capacités, le calcul d’efficacité et l’analyse des performances par poste ou par tranche horaire, essentielles pour détecter des goulots d’étranglement.


RH : pointage et congés

Le module Présences utilise des Datetime pour les enregistrements d’entrée/sortie. Les demandes de congé peuvent aussi nécessiter des heures précises de début et de fin. La paie et les calculs d’heures supplémentaires reposent souvent sur ces horodatages au minute près, d’où l’importance d’une précision fiable.

Créer ou personnaliser le champ Datetime


Trois méthodes principales pour ajouter un Datetime à un modèle, selon que vous préférez no-code ou développeur.


Via Odoo Studio (sans code)

Odoo Studio permet d’ajouter un champ sans programmer. Procédure générale :

  1. Ouvrez Odoo Studio depuis le menu principal.
  2. Allez sur le formulaire à modifier.
  3. Glissez-déposez un champ Date & Time depuis la barre latérale vers le formulaire.
  4. Configurez l’étiquette, l’obligation et éventuellement une valeur par défaut dans le panneau de propriétés.
  5. Enregistrez et fermez Studio.

Studio crée automatiquement le champ avec le préfixe x_studio_ et met à jour la vue. Aucune migration SQL n’est requise — Odoo gère la création en base. C’est l’option recommandée pour les utilisateurs métiers souhaitant étendre un formulaire sans développeur.


Via Python dans un module personnalisé

Pour les développeurs, on définit les champs dans les fichiers Python du module — méthode à privilégier quand il faut versionner et déployer des personnalisations :


from odoo import fields, models

class ResPartner(models.Model):
    _inherit = 'res.partner'

    x_last_contact_date = fields.Datetime(
        string='Last Contact Date',
        default=fields.Datetime.now,
        copy=False,
    )

Après la définition Python, ajoutez le champ à la vue via XML pour l’afficher. Odoo créera automatiquement la colonne TIMESTAMP lors de l’installation ou de la mise à jour du module.


Via l’API XML-RPC

Pour des automatisations ou déploiements programmatiques, on peut créer des champs via l’API XML-RPC :


field_id = models.execute_kw(
    ODOO_DB, uid, ODOO_API_KEY,
    'ir.model.fields', 'create',
    [{
        'name': 'x_last_contact_date',
        'field_description': 'Last Contact Date',
        'model_id': model_id,
        'ttype': 'datetime',
        'state': 'manual',
    }]
)

Le ttype: datetime indique la création d’un Datetime. Le state: manual signifie que le champ a été ajouté en dehors d’un module — réglage approprié pour les champs créés via Studio ou l’API.

Bonnes pratiques


1. Utilisez fields.Datetime.now sans parenthèses

Pour le défaut, écrivez default=fields.Datetime.now (sans ()) : si vous appelez la fonction lors du chargement du module, toutes les nouvelles lignes auront la même heure figée, ce qui fausse les analyses temporelles.


2. Mettez copy=False sur les horodatages d’événements

Les dates d’événements (confirmation, clôture…) ne doivent pas se recopier lors d’un duplicata. Utilisez copy=False pour éviter que des enregistrements dupliqués transportent des timestamps historiques erronés.


3. Écrivez toujours en UTC via l’API

Quand vous créez ou mettez à jour via XML-RPC, fournissez les dates/heures en UTC (format YYYY-MM-DD HH:MM:SS). L’API n’applique pas de conversion : la chaîne reçue est stockée telle quelle en tant qu’UTC, donc envoyer une heure locale induira un décalage difficile à corriger.


4. Utilisez readonly pour les timestamps générés automatiquement

Les horodatages système doivent généralement être en lecture seule pour empêcher des modifications manuelles qui falsifieraient l’historique. Si l’édition est nécessaire, contrôlez-la par les règles d’accès plutôt que d’autoriser tout le monde à modifier le champ.


5. Préférez Date quand l’heure n’est pas utile

Si seule la journée compte (échéance, renouvellement, péremption), utilisez fields.Date. Cela évite la complexité des fuseaux inutiles et simplifie l’expérience utilisateur et la maintenance.

Pièges fréquents


Confusion liée aux valeurs brutes en base

La source la plus fréquente d’erreurs : lire directement la base ou l’API donne la valeur UTC, pas l’heure locale. Des rapports ou intégrations basés sur ces valeurs brutes vont afficher des heures décalées. Toujours convertir côté client avant présentation.


Écrire des heures localisées via l’API

Si vous envoyez une date locale à l’API, elle sera stockée comme si elle était en UTC. Par exemple, enregistrer ’2026-01-01 15:00:00’ pour Paris peut aboutir à un affichage erroné selon l’heure d’été/hiver. Ce type d’erreur n’apparaît souvent qu’en production, quand des utilisateurs réels interagissent à travers différents fuseaux.


Ne pas appeler fields.Datetime.now() avec des parenthèses

Appeler la fonction lors de la définition (fields.Datetime.now()) fige la valeur au chargement du module : toutes les lignes créées pendant la vie du worker porteront la même date-heure. C’est un bug silencieux qui fausse durablement les analyses temporelles.


Oublier copy=False pour les timestamps d’événements

Sans copy=False, les duplications propagent des horodatages historiques (confirmation, début de production…), contaminant les rapports et rendant les pistes d’audit peu fiables. Ce petit oublie peut avoir un impact disproportionné sur la qualité des données.


Choisir Datetime quand Date suffit

Sélectionner Datetime pour une échéance facture ou une date de péremption crée une complexité inutile : les utilisateurs voient une heure superflue, des conversions de fuseau s’exécutent sans valeur ajoutée et l’interface devient moins claire.

Conclusion


Le champ Datetime est extrêmement utile quand la précision compte. Il intervient partout : ouverture d’un lead, démarrage d’une fabrication, pointage des employés…


Le point clé à retenir est le modèle de stockage en UTC. L’interface convertit pour l’utilisateur, mais toute lecture/écriture externe via l’API doit gérer explicitement cette réalité. La plupart des bugs liés aux fuseaux proviennent d’un malentendu à ce sujet.


En appliquant la bonne syntaxe pour les défauts, copy=False quand nécessaire, et en préférant Date lorsque l’heure n’est pas utile, vous garderez un modèle de données propre et des rapports fiables.

Chez Dasolo, nous accompagnons les entreprises dans l’implémentation, la personnalisation et l’optimisation d’Odoo dans tous les services. Que vous ayez besoin d’un modèle de données cohérent, d’ajouts de champs sur mesure ou du développement d’un module complet, notre équipe peut vous aider. Contactez-nous pour discuter de votre projet Odoo.

Champ Datetime dans Odoo : Guide Complet pour Développeurs et Admins
Dasolo 6 mars 2026
Partager cet article
Se connecter pour laisser un commentaire.