Odoo décrit une personne par un nom, une fonction et une adresse. C'est suffisant pour facturer, insuffisant pour un cabinet, une association, une école ou toute organisation dont les contacts sont des individus avant d'être des clients.
Dix-sept modules communautaires complètent cette description — et l'un d'eux mérite d'être lu avant les autres, parce qu'il organise tous les suivants.
Résumé
partner_contact_personal_information_page ajoute un onglet vide sur la fiche contact, conçu comme conteneur. Six modules le remplissent : date de naissance avec âge calculé, genre, nationalité, lieu de naissance, et une tranche d'âge calculée depuis un référentiel configurable.
Trois complètent le nom : un deuxième prénom, un second nom de famille — indispensable pour les noms hispaniques et portugais —, et la propagation de la langue entre une société et ses contacts. Deux outillent les civilités : leur archivage et leur ordre d'affichage.
Quatre structurent la place dans l'organisation : un référentiel de postes, un référentiel de départements, des rôles multiples par contact, et une valeur « utilisateur final » ajoutée au type d'adresse. Deux derniers adaptent le vocabulaire : un module de renommage pour le secteur associatif, et une application complète de gestion d'animaux — pour les vétérinaires, refuges et élevages.
L'essentiel
- Un onglet dédié aux informations personnelles, rempli par des modules indépendants.
- Date de naissance, âge calculé et tranche d'âge depuis un référentiel configurable.
- Genre, nationalité et lieu de naissance sur la fiche contact.
- Un deuxième prénom et un second nom de famille — les noms hispaniques enfin corrects.
- La langue propagée d'une société vers ses contacts.
- Des référentiels de postes, de départements et de rôles plutôt que du texte libre.
- Les civilités archivables et ordonnées — « M. » avant « Docteur honoris causa ».
- Un vocabulaire associatif pour les organisations sans clients.
Ce que ces modules ajoutent à l'instance
| Famille | Modules | Nombre |
|---|---|---|
| Informations personnelles | partner_contact_personal_information_page, partner_contact_birthdate, partner_contact_gender, partner_contact_nationality, partner_contact_birthplace, partner_contact_age_range | 6 |
| Noms et civilités | partner_middlename, partner_second_lastname, partner_contact_lang, partner_title_active, partner_title_order | 5 |
| Place dans l'organisation | partner_contact_job_position, partner_contact_department, partner_contact_role, partner_contact_type_end_user | 4 |
| Vocabulaire et métiers | partner_noncommercial, animal | 2 |
Les menus ajoutés : Contacts ▸ Configuration ▸ Emplois, Départements, Partner Roles, Intervalles d'âge, et l'application Animaux avec sa configuration.
Un onglet, et ce qu'on y met
partner_contact_personal_information_pagen'ajoute aucune donnée : il crée un onglet vide. C'est un choix d'architecture typique de l'OCA — un conteneur partagé, que chaque module remplit sans se marcher dessus. Installé seul, il ne sert à rien ; installé avec ses compagnons, il évite une fiche contact où dix modules se disputent la même place.
| Module | Donnée ajoutée |
|---|---|
partner_contact_birthdate | La date de naissance et l'âge calculé en années complètes |
partner_contact_gender | Le genre : homme, femme, autre |
partner_contact_nationality | La nationalité, indépendante du pays de l'adresse |
partner_contact_birthplace | Le lieu de naissance : ville, code postal, région, pays |
partner_contact_age_range | Une tranche d'âge calculée depuis un référentiel configurable |
Ces données servent des métiers précis : une mutuelle, une association sportive, une école, un cabinet médical. Elles ne servent à rien dans un négoce — et c'est important, parce que collecter une donnée personnelle sans finalité est précisément ce que le RGPD interdit.
La nationalité distincte du pays d'adresse mérite une mention : les deux sont régulièrement confondues dans les bases de données, et la confusion a des conséquences réglementaires dès qu'un dispositif dépend de l'une ou de l'autre.
Le traitement des données personnelles et la conformité sont abordés côté éditorial dans le RGPD et la sous-traitance.
Les noms : trois champs ne suffisent pas toujours
La séparation prénom / nom est fournie par un module déjà traité ailleurs. Deux modules l'étendent :
partner_middlenameajoute un deuxième prénom, courant dans les pays anglo-saxons et dans les documents d'identité.partner_second_lastnameajoute un second nom de famille — indispensable pour les noms hispaniques et portugais, où chaque personne porte le nom de son père et celui de sa mère.
Tronquer un nom hispanique à un seul patronyme n'est pas un détail d'affichage : c'est une erreur d'identification, qui fait échouer les rapprochements bancaires et les contrôles d'identité.
partner_contact_lang complète par un sujet pratique : la langue se propage automatiquement d'une société vers ses contacts, et devient visible et modifiable directement sur la fiche. Sans lui, un contact créé sous une société anglophone reçoit ses documents en français parce que personne n'a pensé au champ.
Deux modules enfin outillent les civilités : partner_title_active permet d'archiver une civilité obsolète, et partner_title_order de contrôler leur ordre d'affichage — pour que « M. » et « Mme » apparaissent avant les titres rares.
La place d'une personne dans son organisation
| Module | Ce qu'il structure |
|---|---|
partner_contact_job_position | Un référentiel de postes géré centralement, en complément du champ texte libre |
partner_contact_department | Un référentiel de départements auquel rattacher un contact dans sa société |
partner_contact_role | Des rôles multiples par contact, en plus de sa fonction |
partner_contact_type_end_user | Une valeur « utilisateur final » ajoutée au type d'adresse |
La différence entre poste, département et rôle structure la relation commerciale : le poste dit ce qu'une personne fait, le département où elle le fait, et le rôle ce qu'elle est pour vous — interlocuteur de facturation, responsable technique, signataire.
C'est le rôle qui compte le plus en pratique : il permet d'adresser un document à la bonne personne — la facture au service comptable, le bon de livraison au magasin — sans dépendre de la mémoire du commercial.
Le quatrième module traite un cas de distribution : distinguer, parmi les adresses d'un client, celle de l'utilisateur final du produit — important lorsque le facturé, le livré et l'utilisateur sont trois entités différentes.
Deux modules pour des contextes particuliers
partner_noncommercialne change aucune logique : il renomme les libellés, les textes d'aide et les filtres des Contacts pour un contexte associatif ou non commercial. Une association n'a pas de « clients » ni de « fournisseurs » : elle a des adhérents, des bénévoles, des partenaires.animalajoute une application complète de gestion d'animaux : identité, espèce, race, couleur, poids, sexe, date de naissance, photo. Elle s'adresse aux vétérinaires, refuges, élevages et pensions.
Le premier illustre un principe sous-estimé : le vocabulaire d'un logiciel décide de son adoption. Une association dont le logiciel parle de « clients » passe son temps à traduire mentalement — et finit par ne pas s'y reconnaître.
Le second est un exemple de ce que le catalogue OCA contient : des applications verticales complètes, que personne ne cherche jusqu'au jour où le besoin se présente.
Limites connues
- L'onglet d'informations personnelles est vide sans ses compagnons : il ne sert à rien installé seul.
- Collecter une donnée personnelle demande une finalité : date de naissance, genre et nationalité relèvent du RGPD et ne s'installent pas « au cas où ».
- Les référentiels de postes et de départements doivent être tenus : sinon ils deviennent une liste de valeurs créées à la volée, sans valeur analytique.
- Les rôles n'ont d'effet que si les documents s'en servent : leur intérêt dépend des modules qui les exploitent.
partner_noncommercialne change que des libellés : les objets et la logique restent ceux d'Odoo.- L'application Animaux est autonome : elle ne se relie pas d'elle-même aux ventes ou aux interventions.
Identité technique
Les dix-sept modules viennent du dépôt OCA partner-contact, branche 18.0, tous en licence AGPL-3. Six dépendent de l'onglet d'informations personnelles, deux de la séparation prénom / nom, et animal de la messagerie d'Odoo.
Les familles voisines : doublons et qualité des contacts et identité, adresses et contacts.
Questions fréquentes
Pourquoi un module qui ajoute un onglet vide ?
partner_contact_personal_information_page sert de conteneur partagé : les modules de date de naissance, genre, nationalité ou lieu de naissance y placent leurs champs sans se disputer la place sur la fiche. C'est un choix d'architecture de l'OCA — inutile seul, structurant avec ses compagnons.
Odoo gère-t-il les noms hispaniques ?
Pas en standard. partner_second_lastname ajoute un second nom de famille, indispensable dans les pays hispaniques et au Portugal où chaque personne porte le nom de son père et celui de sa mère. Tronquer à un seul patronyme fait échouer les rapprochements bancaires et les contrôles d'identité.
Quelle différence entre poste, département et rôle ?
Le poste dit ce qu'une personne fait, le département où elle le fait, et le rôle ce qu'elle est pour vous : interlocuteur de facturation, responsable technique, signataire. C'est le rôle qui permet d'adresser chaque document à la bonne personne sans dépendre de la mémoire du commercial.
Faut-il installer les champs de données personnelles « au cas où » ?
Non. Date de naissance, genre, nationalité et lieu de naissance sont des données personnelles : les collecter suppose une finalité déclarée. Ces modules servent des métiers précis — mutuelle, association sportive, école, cabinet médical — et n'ont pas leur place dans un négoce.
Peut-on adapter le vocabulaire d'Odoo à une association ?
partner_noncommercial renomme les libellés, textes d'aide et filtres des Contacts pour un contexte associatif : une association a des adhérents et des bénévoles, pas des clients. Le module ne change aucune logique — mais le vocabulaire décide souvent de l'adoption d'un outil.
Se faire accompagner
Décrire des personnes dans un ERP pose une question avant toute autre : pourquoi. Chaque champ personnel ajouté est une donnée à protéger, à justifier et, le jour venu, à supprimer sur demande.
Nous partons donc des usages — à qui envoyez-vous quoi, et qui décide chez votre client — pour n'installer que les champs qui servent. Les rôles et les référentiels de postes passent presque toujours cette épreuve ; les données de naissance, rarement. Voir les prestations d'Atalios Consulting ou demander un rappel.
Pour aller plus loin
- Doublons de contacts : détecter, fusionner, interdire
- Identité, adresses et contacts dans Odoo
- RGPD : ce qu'il faut vérifier chez un sous-traitant
En résumé
Un onglet conteneur et six modules qui le remplissent, trois champs de nom au lieu de deux, des référentiels de postes, départements et rôles plutôt que du texte libre — et deux modules de contexte, dont un vocabulaire associatif. À installer en partant de l'usage, car chaque donnée personnelle se justifie. Parlons de votre fichier contacts.
