La qualité du fichier contacts était un sujet d'hygiène. Depuis le 1er septembre 2026, c'est une obligation : le SIREN d'un client est devenu la clé de routage de vos factures électroniques, et un SIREN faux produit une facture qui n'arrive pas.
Huit modules du socle s'y emploient, chacun sur un défaut précis : le nom mal découpé, la référence en double, le SIRET invalide, l'adresse incohérente. Aucun n'est spectaculaire ; ensemble, ils évitent le travail de nettoyage qu'on finit toujours par faire.
Résumé
Huit modules travaillent une seule matière : des contacts identifiables sans ambiguïté. Le plus important est l10n_fr_siret, qui valide la clé de contrôle du SIRET et signale les doublons de SIREN — devenu critique depuis que le SIREN route vos factures électroniques.
Une décision se prend tôt et ne se rattrape pas facilement : l'ordre d'affichage des noms de partner_firstname, qui se configure au niveau système. Le changer après un import de plusieurs milliers de contacts oblige à recomposer les noms existants.
L'essentiel
l10n_fr_siret: découpe le SIRET en SIREN et NIC, valide la clé de contrôle, et signale les doublons de SIREN entre contacts.partner_firstname: prénom et nom séparés, avecnamerecalculé — 36 champs ajoutés.partner_identification: tout type de numéro d'identification typé et daté sur un contact.partner_ref_uniqueetbase_partner_sequence: une référence unique, séquentielle, propagée aux adresses enfants.base_location+ import Geonames : l'adresse complétée depuis le code postal ou la ville.base_search_fuzzy: la recherche par similarité, pour retrouver « Dupond » en tapant « Dupont ».
l10n_fr_siret : le module qui compte le plus en 2026
Le module officiel l10n_fr d'Odoo ajoute un champ SIRET sur les contacts, mais n'en vérifie pas la validité. C'est précisément le trou que ce module comble, et il est devenu critique.
| Ce qu'il fait | Pourquoi c'est devenu important |
|---|---|
| Découpe le SIRET en SIREN et NIC | Le SIREN est la clé de routage de la facture électronique |
| Valide la clé de contrôle (checksum) | Un SIREN invalide est détecté à la saisie, pas au rejet de la facture |
| Signale les doublons de SIREN entre contacts | Deux fiches pour la même entité produisent deux encours et deux relances |
La validation de la clé de contrôle est le gain le plus direct : elle attrape la faute de frappe au moment de la saisie. Sans elle, l'erreur se découvre des semaines plus tard, quand la facture revient rejetée avec « destinataire introuvable ».
Le module ajoute 33 champs et dépend de l10n_fr et de base_view_inheritance_extension. Il s'adresse en particulier aux sociétés multi-établissements, qui manipulent plusieurs NIC pour un même SIREN.
Voir l'annuaire national et le routage.
Les noms : partner_firstname et crm_lead_firstname
Odoo stocke le nom d'une personne dans un champ unique. Cela suffit jusqu'au jour où il faut écrire « Bonjour Marie » dans un courriel, trier par nom de famille, ou exporter vers un outil qui attend deux colonnes.
partner_firstname scinde le nom en First name et Last name, et transforme le champ name standard en champ calculé et stocké à partir des deux. La compatibilité est donc préservée : tout ce qui lit name continue de fonctionner.
- 36 champs ajoutés, 1 modèle créé, et l'extension s'applique aussi aux utilisateurs (
res.users), pas seulement aux contacts. - L'ordre d'affichage du nom complet et le caractère obligatoire de chaque champ se configurent au niveau système.
crm_lead_firstnameétend la même logique aux pistes et opportunités du CRM, et synchronise avec la fiche contact créée depuis la piste.
Limite répertoriée : les motifs de recomposition du nom ne sont configurables qu'au niveau système. Le dépôt note qu'il serait souhaitable de les faire dépendre de la langue, du pays ou de la société du contact — ce n'est pas le cas aujourd'hui. Sur un fichier international, l'ordre retenu ne conviendra donc pas à tous.
Les références : unicité, séquence, identifiants typés
Trois modules se répartissent un même problème : identifier un contact de façon fiable et non ambiguë.
| Module | Ce qu'il fait | Version |
|---|---|---|
base_partner_sequence | Attribue une référence séquentielle automatique (P/00001), propagée aux adresses enfants | 18.0.1.2.0 |
partner_ref_unique | Impose l'unicité du champ Reference, configurable par société | 18.0.1.0.0 |
partner_identification | Gère tout type de numéro d'identification ou de certificat, par catégorie | 18.0.1.2.0 |
Les deux premiers se complètent : la séquence garantit la continuité et évite la saisie manuelle, l'unicité garantit qu'un code venu d'un import ou d'un ERP tiers ne sera pas attribué deux fois. La propagation aux adresses enfants du même contact commercial est le détail qui rend la référence réellement utilisable.
partner_identification est d'une autre nature : il ouvre un référentiel d'identifiants typés et datés — registre du commerce, numéro de TVA, identifiants fiscaux étrangers, numéro d'adhérent, permis. Il ajoute 62 champs et deux menus, et sert de socle à d'autres modules OCA.
Limite répertoriée sur ce dernier : la recherche d'un contact par identifiant passe par le formulaire de recherche avancée, et on ne peut pas chercher par émetteur, dates de validité, catégorie ou notes. C'est un référentiel de stockage, pas un outil de recherche.
Enfin, crm_lead_code applique la même idée aux pistes : un code séquentiel unique, lisible, citable au téléphone — au lieu d'un identifiant technique.
Les adresses : base_location et l'import Geonames
Saisir une adresse à la main produit des incohérences : un code postal qui ne correspond pas à la ville, une ville orthographiée de trois façons, un département erroné. Sur un fichier de plusieurs milliers de contacts, cela rend toute analyse géographique inutilisable.
base_location introduit un référentiel de codes postaux liés à une ville, un état et un pays. À la saisie du code postal ou de la ville, les autres champs se complètent.
| Module | Ce qu'il apporte | Menus |
|---|---|---|
base_location | Le référentiel Zip / Ville / État / Pays, 27 champs ajoutés | Contacts ▸ Configuration ▸ Localisation ▸ Codes postaux et Villes |
base_location_geonames_import | L'assistant d'import en masse depuis la base publique Geonames | Contacts ▸ Configuration ▸ Localisation ▸ Importer de Geonames |
Le second est indispensable au premier : personne ne saisira à la main les milliers de codes postaux d'un pays. L'assistant les importe depuis Geonames, pays par pays, et permet de rafraîchir le référentiel. Il est réservé aux administrateurs.
base_location sert aussi de brique de base à des modules de localisation nationaux plus spécifiques — c'est pourquoi il figure au socle même quand l'autocomplétion d'adresse n'est pas une priorité.
base_search_fuzzy : le module invisible qui évite les doublons
Celui-ci ne se voit jamais et sert souvent. Il crée des index PostgreSQL de type GIN ou GiST, fondés sur l'extension pg_trgm, sur des champs texte — ce qui rend possible une recherche par similarité de trigrammes via l'opérateur de domaine %.
En clair : retrouver « Dupond » en tapant « Dupont ». Sur un fichier alimenté par plusieurs personnes, c'est ce qui évite la création d'un doublon parce que la recherche exacte n'avait rien renvoyé.
Mais il faut lire sa limite avec attention, car elle détermine son utilité réelle :
- Le module ne modifie aucune recherche existante de l'interface standard. Il fournit l'infrastructure — le modèle, l'écran de configuration des index — que d'autres modules ou des développements exploitent dans leurs propres domaines de recherche.
- Le dépôt note qu'il ne modifie pas la recherche générale, celle des vues liste et des champs relationnels.
- Et il indique que ce module ne devrait plus être nécessaire à partir de la version 16 d'Odoo, qui améliore la gestion des index.
Conclusion honnête : sur Odoo 18, son intérêt est à vérifier au cas par cas. Il figure au socle comme infrastructure disponible, pas comme fonctionnalité active. Son menu se trouve dans Paramètres ▸ Technique ▸ Structure de la base de données ▸ Index Trigram.
Dans quel ordre s'en occuper
| Priorité | Module | Pourquoi |
|---|---|---|
| 1 | l10n_fr_siret | Le SIREN est la clé de routage de vos factures électroniques |
| 2 | base_partner_sequence + partner_ref_unique | Une référence fiable avant tout import |
| 3 | partner_firstname | À décider avant les premiers imports : il change la structure du nom |
| 4 | base_location + Geonames | Utile dès que vous analysez par zone géographique |
| 5 | partner_identification | Quand vous gérez des identifiants étrangers ou réglementés |
| 6 | base_search_fuzzy | Infrastructure : à activer si un besoin précis l'exige |
La troisième ligne mérite l'attention : partner_firstname change la façon dont le nom est composé, et l'ordre retenu se configure au niveau système. Le décider après un import de plusieurs milliers de contacts oblige à recomposer les noms existants.
Ces modules travaillent exactement la matière qui fait le succès ou l'échec d'une mise en conformité : le fichier clients. Voir la liste de contrôle en 7 points.
Identité technique
| Module | Dépôt OCA | Version | Licence |
|---|---|---|---|
l10n_fr_siret | l10n-france | 18.0.1.4.0 | AGPL-3 |
partner_firstname | partner-contact | 18.0.6.2.1 | AGPL-3 |
partner_identification | partner-contact | 18.0.1.2.0 | AGPL-3 |
partner_ref_unique | partner-contact | 18.0.1.0.0 | AGPL-3 |
base_partner_sequence | partner-contact | 18.0.1.2.0 | AGPL-3 |
base_location | partner-contact | 18.0.1.1.1 | AGPL-3 |
base_location_geonames_import | partner-contact | 18.0.1.0.0 | AGPL-3 |
base_search_fuzzy | server-tools | 18.0.2.0.0 | AGPL-3 |
Le dépôt partner-contact compte 98 modules documentés — c'est l'un des plus fournis de l'écosystème. Les huit ci-dessus font partie de notre socle commun, avec crm_lead_code et crm_lead_firstname.
Questions fréquentes
Pourquoi la qualité du fichier contacts est-elle devenue une obligation ?
Parce que depuis le 1er septembre 2026, le SIREN d'un client est la clé de routage de vos factures électroniques. Un SIREN absent ou faux ne produit pas une facture imparfaite : il produit une facture qui n'arrive pas, donc qui n'est pas payée. l10n_fr_siret valide la clé de contrôle à la saisie.
partner_firstname casse-t-il la compatibilité avec le champ nom standard ?
Non : le champ name d'Odoo devient un champ calculé et stocké, reconstitué depuis le prénom et le nom. Tout ce qui lit name continue de fonctionner. En revanche, décidez l'ordre d'affichage avant vos imports — il se configure au niveau système, et le changer ensuite oblige à recomposer les noms existants.
Peut-on chercher un contact par son numéro d'identification ?
Par le formulaire de recherche avancée, oui. Mais c'est une limite répertoriée du module : on ne peut pas chercher par émetteur, dates de validité, catégorie ou notes. partner_identification est un référentiel de stockage structuré, pas un moteur de recherche.
base_search_fuzzy rend-il la recherche d'Odoo tolérante aux fautes ?
Pas tout seul, et c'est important : il fournit l'infrastructure — les index trigrammes et leur écran de configuration — sans modifier aucune recherche existante de l'interface. Le dépôt note par ailleurs qu'il ne devrait plus être nécessaire à partir de la version 16 d'Odoo.
Faut-il importer tout Geonames ?
Non, pays par pays, et seulement ceux où vous avez des contacts. L'import en masse d'un pays représente plusieurs milliers d'entrées : utile pour la France si vous analysez par zone, inutile pour un pays où vous avez trois clients.
Se faire accompagner
Ces modules donnent les outils ; ils ne nettoient pas votre base. Le travail réel est de compter vos fiches sans SIREN, de trier par chiffre d'affaires, et de corriger en commençant par les clients que vous facturez chaque mois.
C'est le chantier qui conditionne toute la conformité, et il n'est pas technique. Nous le menons avec vous — comptage, priorisation, synchronisation avec l'annuaire national, et décision sur l'ordre des noms avant les imports. Voir les prestations d'Atalios Consulting ou demander un rappel.
Pour aller plus loin
- l10n_fr_einvoicing : la facturation électronique française dans Odoo
- L'annuaire national : SIREN, SIRET et code de routage
- Le socle commun : les 57 modules de chaque instance
En résumé
Huit modules pour une seule chose : des contacts identifiables sans ambiguïté. Le plus important est l10n_fr_siret, qui valide la clé de contrôle du SIRET et signale les doublons de SIREN — devenu critique depuis que le SIREN route vos factures. Et une décision à prendre tôt : l'ordre des noms. Parlons de votre fichier clients.
