Se rendre au contenu

Le modèle res.partner : maîtriser l’architecture Contacts & Partners d’Odoo

Guide pratique pour développeurs et consultants fonctionnels : maîtriser le modèle central de contacts d’Odoo
10 mars 2026 par
Le modèle res.partner : maîtriser l’architecture Contacts & Partners d’Odoo
Dasolo
| Aucun commentaire pour l'instant

Introduction


Dans Odoo, les modèles déterminent la manière dont les informations sont organisées et enregistrées. Tout élément métier — devis, facture, fiche contact — trouve sa place dans un modèle qui structure les données en tables et en champs.


S’approprier la notion de modèle est indispensable, que vous configuriez Odoo ou que vous développiez des modules. Les modèles forment l’ossature des données : ils définissent les champs, les liens entre enregistrements et toute la logique métier associée.

Cet article se concentre sur un modèle incontournable : res.partner. Qu’il s’agisse de créer des modules personnalisés, de synchroniser des données externes ou de paramétrer des flux de travail, vous croiserez très souvent ce modèle.

Qu’est-ce que le modèle res.partner


res.partner sert à représenter les personnes, les entreprises, clients et fournisseurs au sein d’Odoo. C’est l’endroit central où sont rassemblées les informations de toute entité tiers liée à votre activité.


Vous rencontrerez res.partner dans presque tous les modules : Ventes, CRM, Comptabilité, Achats et e‑commerce s’appuient dessus. Quand on enregistre un client, un lead ou un fournisseur, on crée ou on référence un enregistrement res.partner.


Le modèle est défini dans le module de base et les autres modules le complètent via l’héritage. Ainsi, CRM ajoute des champs pour les opportunités, la comptabilité enrichit avec des paramètres de paiement : chaque module étend sans dupliquer la structure fondamentale.

Champs-clés du modèle


Voici les champs principaux du modèle res.partner — les connaître facilite la manipulation des contacts et des partenaires dans Odoo.


1. name

Type : Char. Champ principal affichant le nom du partenaire. Pour une société, c’est le nom légal ; pour une personne, son nom complet. Il sert d’identifiant visible dans la plupart des vues.


2. create_date

Type : Datetime. Date et heure de création de l’enregistrement. Géré automatiquement par Odoo, utile pour l’audit et les rapports temporels.


3. write_date

Type : Datetime. Date et heure de la dernière modification. Permet de suivre l’actualité des données et d’identifier les mises à jour récentes.


4. email

Type : Char. Adresse e‑mail principale du contact. Employée pour les communications, l’accès portail et l’envoi de documents ; Odoo effectue des validations basiques du format.


5. phone

Type : Char. Numéro de téléphone fixe principal, affiché sur les fiches et utilisé par les workflows de communication.


6. mobile

Type : Char. Numéro de portable, souvent utilisé pour les notifications urgentes ou les SMS lorsque distinct du téléphone fixe.


7. street

Type : Char. Première ligne d’adresse. Fait partie du bloc d’adresse standard affiché sur documents et formulaires.


8. street2

Type : Char. Deuxième ligne d’adresse pour compléter l’adresse principale : étage, boîte, bâtiment, etc.


9. city

Type : Char. Localité (ville ou commune). Le format d’adresse peut varier selon le pays.


10. zip

Type : Char. Code postal. Utilisé pour la validation d’adresse et le calcul des frais d’expédition.


11. state_id

Type : Many2one (res.country.state). Région ou province. La liste est filtrée par pays ; tous les pays n’utilisent pas ce niveau administratif.


12. country_id

Type : Many2one (res.country). Pays du partenaire. Influence le format d’adresse, les règles fiscales et la localisation des documents.


13. is_company

Type : Boolean. Indique si l’enregistrement représente une entreprise ou une personne. Les entreprises peuvent avoir des contacts enfants ; les personnes peuvent pointer vers une société via parent_id.


14. parent_id

Type : Many2one (res.partner). Lien vers la société si l’enregistrement est un contact. Permet d’hériter certaines informations du parent et de structurer la hiérarchie société‑contacts.


15. child_ids

Type : One2many (res.partner). Inverse de parent_id : liste des contacts liés à une société. Pratique pour naviguer du compte entreprise vers ses interlocuteurs.


16. company_id

Type : Many2one (res.company). Dans un contexte multi‑sociétés, indique à quelle société Odoo appartient le partenaire. Impacte la visibilité et les règles d’accès.


17. vat

Type : Char. Numéro d’identification fiscale ou TVA. Validé selon le format pays. Indispensable pour la facturation et la conformité. Une notation particulière peut indiquer l’exonération TVA.


18. customer_rank

Type : Integer. Indicateur d’activité commerciale : Odoo augmente ce compteur quand des ventes sont enregistrées. Utile pour filtrer et prioriser les clients.


19. supplier_rank

Type : Integer. Indicateur d’activité fournisseur : incrémenté lors de commandes ou factures fournisseurs. Permet d’identifier les vendeurs actifs.


20. user_id

Type : Many2one (res.users). Commercial ou responsable lié au partenaire. Utilisé pour l’affectation d’activités, les rapports commerciaux et la gestion des opportunités.


21. type

Type : Selection. Type d’adresse pour les contacts enfants : Contact, Invoice, Delivery, Other. Détermine quelle adresse s’applique sur les documents (facture, livraison).


22. ref

Type : Char. Référence interne ou code partenaire. Pratique pour le mapping avec des systèmes externes ou pour un référencement personnalisé.


23. website

Type : Char. URL du site web du partenaire. Affichée sur la fiche et utile dans les contextes e‑commerce.


24. comment

Type : Html. Notes internes visibles par les utilisateurs. Sert pour les consignes commerciales, historiques d’échanges ou remarques spécifiques.


25. active

Type : Boolean. Drapeau d’archivage : désactivé, l’enregistrement est masqué par défaut mais non supprimé physiquement, facilitant la conservation des historiques.


26. lang

Type : Selection. Langue préférée du partenaire. Utilisée pour traduire les emails et documents envoyés ; héritée du parent si nécessaire.


27. image_1920

Type : Binary. Image ou logo du partenaire. Odoo conserve différentes tailles pour l’affichage dans les fiches, rapports et sur le site web.


28. category_id

Type : Many2many (res.partner.category). Étiquettes ou segments. Utile pour le ciblage marketing, le filtrage et la classification personnalisée.

Comment ce modèle s’intègre aux processus métier


1. Ventes et CRM

Quand un commercial prépare un devis, il choisit un client parmi les partenaires. Le même enregistrement reliera le lead, l’opportunité et la commande : customer_rank et user_id alimentent les rapports et les assignations.


2. Facturation

Les factures et les avoirs réfèrent au partenaire pour l’adresse de facturation. Le champ vat sert au calcul des taxes. D’autres paramètres commerciaux comme les conditions de paiement peuvent être rattachés au partenaire.


3. Achats et fournisseurs

Les commandes d’achat et factures fournisseurs pointent sur res.partner. supplier_rank identifie les fournisseurs actifs et un champ buyer_id (ou user_id) peut désigner l’acheteur responsable.


4. E‑commerce et portail

Les visiteurs du site peuvent créer un compte partenaire lors de l’inscription : ce même enregistrement servira pour les commandes, devis et l’accès au portail client.


5. Multi‑société et consolidation

En environnement multi‑sociétés, une même entité légale peut être représentée par plusieurs enregistrements selon la société. company_id et les règles inter‑sociétés gouvernent le partage et la visibilité des données.

Comment les développeurs étendent ce modèle


Les développeurs étendent res.partner via différents mécanismes ; l’héritage de modèle d’Odoo est la méthode principale.


Héritage de modèle

Déclarez _inherit = 'res.partner' pour enrichir le modèle : ajouter des champs, redéfinir des méthodes ou ajouter des contraintes. Conserver ces changements dans un module séparé facilite les mises à jour.


Ajouter des champs

Déclarez de nouveaux champs dans votre modèle hérité en choisissant le type adapté (Char, Many2one, Boolean, Integer, Text, Selection). Pensez aux champs dépendants de la société en contexte multi‑societés.


Extensions Python

Surchargez create, write ou unlink pour injecter de la logique métier. Appelez systématiquement super() pour préserver le comportement natif. Attention aux champs calculés et à leurs dépendances pour éviter des boucles ou des incohérences.


Odoo Studio

Odoo Studio permet d’ajouter des champs sans coder — pratique pour des adaptations rapides. Pour des besoins complexes ou durables, privilégiez un module personnalisé pour la maintenabilité et les évolutions futures.

Bonnes pratiques


  • Créez d’abord la fiche société puis ajoutez les contacts avec parent_id pour respecter la hiérarchie société‑contacts.
  • Renseignez correctement country_id pour garantir le bon format d’adresse et le traitement fiscal adapté au pays.
  • Utilisez commercial_partner_id lorsque vous avez besoin de l’entité racine pour regrouper facturation ou rapports (par ex. gestion du crédit et consolidations).
  • Pour les intégrations API, préférez XML‑RPC ou JSON‑RPC exposés par Odoo. Le modèle res.partner est accessible : mappez soigneusement les identifiants externes pour éviter les doublons.
  • Pour les champs personnalisés, préfixez par x_ ou avec le nom de votre module afin d’éviter les collisions lors d’évolutions d’Odoo.

Erreurs fréquentes


  • Créer des partenaires en double au lieu de rechercher des existants. Servez‑vous d’email_normalized ou de ref pour dédupliquer lors des imports ou synchronisations.
  • Confondre parent_id et company_id. parent_id structure la relation contact→société ; company_id lie l’enregistrement à une société Odoo en multi‑société.
  • Oublier de définir le type des contacts enfants. Les adresses de facturation et de livraison doivent avoir le type adéquat pour apparaître correctement sur les documents.
  • Surcharger des méthodes centrales sans appeler super(). Ce type d’erreur peut casser d’autres modules ou compliquer les montées de version.
  • Ajouter des champs requis sans valeur par défaut. Lors d’un déploiement ou d’une mise à jour, les enregistrements existants risquent d’échouer à la validation.

Conclusion


Le modèle res.partner est au cœur d’Odoo : il centralise les contacts, clients et fournisseurs. Maîtriser ses champs et la façon dont il est étendu par les modules vous permettra de mieux configurer, personnaliser et intégrer votre instance Odoo.

Que vous cartographiez des processus métier comme consultant fonctionnel ou que vous développiez des modules, une bonne compréhension de res.partner évitera des erreurs coûteuses et accélérera vos déploiements.

Besoin d’aide pour votre projet Odoo ?


Dasolo accompagne les entreprises dans le déploiement, la personnalisation et l’optimisation d’Odoo. Nous sommes spécialisés en intégrations API et développement Odoo, avec une solide expérience des modèles et de l’architecture des données comme res.partner.

Si vous souhaitez un accompagnement pour votre implémentation Odoo, la création de modules sur mesure ou des intégrations, nous pouvons vous aider. Demandez une démo pour discuter de votre projet.

Le modèle res.partner : maîtriser l’architecture Contacts & Partners d’Odoo
Dasolo 10 mars 2026
Partager cet article
Se connecter pour laisser un commentaire.