Le fichier contacts est le référentiel le plus abîmé de tout ERP : trois fiches pour le même client, une adresse e-mail saisie avec une faute, un numéro de TVA en double, et une facture envoyée au mauvais interlocuteur.
Seize modules communautaires s'attaquent aux trois temps du problème : empêcher le doublon, le détecter, le fusionner proprement.
Résumé
Cinq modules outillent la déduplication : des droits dédiés sur l'assistant natif, deux critères supplémentaires de détection — la référence et le site web —, des filtres d'exclusion pour restreindre le périmètre de recherche, et la consolidation des comptes utilisateurs lors d'une fusion.
Cinq empêchent : unicité du numéro de TVA, unicité de la référence configurable par société, validation et normalisation de l'adresse e-mail avec vérification du domaine, et deux bandeaux d'alerte quand un e-mail ou un mobile est déjà utilisé par un autre contact.
Six enfin structurent : une référence séquentielle attribuée automatiquement aux contacts commerciaux, une référence fournisseur — celle que le fournisseur vous attribue — avec sa séquence, un groupe de sécurité d'édition des contacts, une approbation par paliers, et l'archivage hiérarchique d'une société avec ses contacts.
L'essentiel
- Des droits dédiés sur la déduplication : fusionner des contacts n'est pas un geste anodin.
- Deux critères de détection en plus : la référence et le site web.
- Des filtres d'exclusion pour cibler la recherche de doublons.
- Le numéro de TVA et la référence rendus uniques, par contrainte.
- L'adresse e-mail validée, domaine vérifié — pas seulement la syntaxe.
- Un bandeau d'alerte quand un e-mail ou un mobile existe déjà ailleurs.
- Une référence séquentielle automatique à la création d'un contact commercial.
- L'archivage hiérarchique : archiver une société archive ses contacts.
Ce que ces modules ajoutent à l'instance
| Famille | Modules | Nombre |
|---|---|---|
| Déduplication | partner_deduplicate_acl, partner_deduplicate_by_ref, partner_deduplicate_by_website, partner_deduplicate_filter, base_partner_merge_user_consolidation | 5 |
| Contraintes et alertes | partner_vat_unique, partner_ref_unique, partner_email_check, partner_email_duplicate_warn, partner_mobile_duplicate_warn | 5 |
| Références | base_partner_sequence, partner_supplier_ref, partner_supplier_ref_sequence | 3 |
| Droits et cycle de vie | partner_readonly_security, partner_tier_validation, partner_archive_propagate | 3 |
Un menu ajouté : Contacts ▸ Outil ▸ Dédoublonner, qui donne accès à l'assistant de déduplication encadré par ses droits.
Dédoublonner, avec un garde-fou
L'assistant de déduplication d'Odoo fusionne des fiches définitivement : les documents des deux contacts se retrouvent sur un seul. C'est exactement le genre d'opération qui ne devrait pas être à la portée de tout utilisateur ayant accès au menu — et c'est pourtant le cas en standard.
partner_deduplicate_acl ajoute des groupes de sécurité dédiés à cet assistant. Trois modules enrichissent ensuite la détection :
| Module | Critère ou apport |
|---|---|
partner_deduplicate_by_ref | La référence du contact comme critère de doublon |
partner_deduplicate_by_website | Le site web comme critère — deux fiches pour le même domaine |
partner_deduplicate_filter | Des filtres d'exclusion : restreindre la recherche selon la nature des fiches |
base_partner_merge_user_consolidation | La consolidation des comptes utilisateurs liés lors de la fusion |
Le dernier traite un effet de bord méconnu : fusionner deux contacts dont chacun porte un compte utilisateur laisse, sans lui, une situation incohérente. Le module consolide.
Le critère « site web » est le plus efficace sur un fichier de prospection : les fiches issues de sources différentes partagent rarement une orthographe, mais presque toujours un domaine.
Empêcher le doublon plutôt que le corriger
partner_vat_uniqueimpose l'unicité du numéro de TVA parmi les contacts : deux fiches pour la même entreprise deviennent impossibles.partner_ref_uniqueimpose l'unicité de la référence, configurable par société — important en multi-société, où les codes clients peuvent légitimement se répéter.partner_email_checkvalide et normalise l'adresse e-mail : syntaxe correcte, et vérification que le domaine existe réellement.partner_email_duplicate_warnetpartner_mobile_duplicate_warnaffichent un bandeau d'avertissement quand l'adresse ou le mobile saisi existe déjà sur un autre contact.
La distinction entre contrainte et alerte est le choix de paramétrage à faire : une contrainte bloque et garantit la propreté, une alerte informe et laisse passer les cas légitimes — deux personnes qui partagent une adresse de contact générique, par exemple.
La vérification du domaine est le contrôle le plus rentable du lot : elle attrape les fautes de frappe dans les noms de domaine, qui sont la première cause de facture jamais reçue — et jamais payée.
Avec l'arrivée de la facture électronique, cette qualité d'adresse devient structurante : voir l'annuaire et le routage.
Donner une référence stable à chaque contact
| Module | Ce qu'il attribue |
|---|---|
base_partner_sequence | Une référence séquentielle — P/00001, P/00002 — à chaque contact commercial, dès sa création |
partner_supplier_ref | La référence que le fournisseur vous attribue, distincte de votre référence interne |
partner_supplier_ref_sequence | Le remplissage automatique de cette référence fournisseur par une séquence |
Le premier est la base d'un fichier exploitable : une référence stable permet les imports, les rapprochements et les échanges avec d'autres systèmes. Sans elle, le seul identifiant partagé est le nom — qui change.
Le deuxième traite l'autre sens de la relation : votre fournisseur vous a attribué un numéro de compte, qu'il attend sur vos commandes et vos règlements. Le noter sur sa fiche évite de le chercher dans un ancien courriel à chaque virement.
Qui modifie un contact, et comment on l'archive
partner_readonly_securitycrée un groupe Édition des contacts : sans lui, un utilisateur ne peut ni créer, ni modifier, ni supprimer de contact, quels que soient ses autres droits.partner_tier_validationajoute une approbation par paliers sur les contacts, en s'appuyant sur les étapes de contact.partner_archive_propagatepermet d'archiver — ou de réactiver — une société et tous ses contacts en une fois, hiérarchiquement.
Le premier répond à une demande constante : beaucoup d'utilisateurs doivent consulter le fichier clients sans pouvoir le modifier. Odoo lie trop souvent lecture et écriture, et c'est ainsi qu'un commercial change une adresse de facturation au milieu d'un cycle.
L'approbation par paliers sur les contacts se justifie dans les organisations où créer un client engage un encours ou une analyse de risque. Elle suppose les étapes de contact, qui structurent ce cycle de création.
L'archivage hiérarchique, enfin, corrige un comportement incomplet : archiver une société laisse ses contacts actifs, qui continuent d'apparaître dans les listes et les sélections — et un courriel part chez une entreprise qui n'existe plus.
La gestion fine des droits et des profils est traitée dans sécuriser les accès Odoo.
Limites connues
- La fusion est définitive : d'où l'intérêt des droits dédiés, et d'une sauvegarde avant toute campagne de déduplication.
- L'unicité du numéro de TVA échoue sur une base contenant des doublons : nettoyage préalable obligatoire.
- Un même numéro de TVA peut légitimement exister deux fois en multi-société : vérifier avant d'imposer la contrainte.
- La vérification du domaine d'un e-mail suppose un accès réseau depuis le serveur.
- Les alertes de doublon n'empêchent rien : elles informent, et supposent qu'on lise.
- L'archivage hiérarchique archive beaucoup : à utiliser en connaissance de cause sur une société à nombreux contacts.
Identité technique
Les seize modules viennent du dépôt OCA partner-contact, branche 18.0 — 100 modules au total —, tous en licence AGPL-3. L'approbation par paliers s'appuie sur le socle générique du dépôt server-ux, et l'alerte sur le mobile sur la validation téléphonique d'Odoo.
Les familles voisines du même dépôt seront traitées dans les fiches suivantes : identité des personnes, adresses et localisation, relations et segmentation.
Questions fréquentes
Qui peut fusionner des contacts dans Odoo ?
En standard, tout utilisateur ayant accès au menu — alors que la fusion est définitive et déplace les documents des deux fiches. partner_deduplicate_acl encadre l'assistant par des groupes de sécurité dédiés. Prévoyez aussi une sauvegarde avant toute campagne de déduplication.
Comment détecter des doublons qui n'ont pas le même nom ?
En ajoutant des critères : partner_deduplicate_by_ref utilise la référence, partner_deduplicate_by_website le site web. Ce dernier est le plus efficace sur un fichier de prospection — des fiches de sources différentes partagent rarement une orthographe, mais presque toujours un domaine.
Peut-on interdire deux fiches avec le même numéro de TVA ?
Oui, avec partner_vat_unique. Attention : la contrainte échoue tant que des doublons existent, donc le nettoyage est préalable. Et en multi-société, un même numéro peut légitimement apparaître deux fois — à vérifier avant d'imposer la règle.
Comment éviter les adresses e-mail erronées ?
partner_email_check valide la syntaxe et vérifie que le domaine existe réellement. C'est le contrôle le plus rentable du lot : les fautes de frappe dans les noms de domaine sont la première cause de facture jamais reçue — donc jamais payée.
Archiver une société archive-t-elle ses contacts ?
Pas en standard : les contacts restent actifs et continuent d'apparaître dans les listes et les sélections. partner_archive_propagate permet d'archiver — ou de réactiver — une société et tous ses contacts en une fois, hiérarchiquement.
Se faire accompagner
La qualité du fichier contacts se dégrade tant qu'aucune règle ne s'y oppose : chaque import, chaque formulaire web, chaque commercial pressé ajoute une fiche. Et chaque doublon coûte un courrier perdu, une relance envoyée au mauvais interlocuteur, ou un encours mal calculé.
Nous traitons donc dans cet ordre : d'abord le nettoyage avec sauvegarde, ensuite les contraintes qui empêchent la rechute, et enfin les droits — parce qu'un fichier propre tenu par trente personnes sans règle redevient sale en six mois. Voir les prestations d'Atalios Consulting, notre méthode ou demander un rappel.
Pour aller plus loin
- Identité, adresses et contacts dans Odoo
- Identité française : SIRET, régions, départements
- Sécuriser les accès Odoo
En résumé
Trois temps contre les doublons : empêcher par des contraintes d'unicité et un contrôle d'adresse, détecter par des critères et des alertes, fusionner sous droits dédiés avec consolidation des comptes utilisateurs. Plus une référence stable et un archivage qui n'oublie pas les contacts. Parlons de votre fichier clients.
