La reprise de données, c’est un classique : on charge une première version “pour démarrer”, puis viennent les retouches… et les retouches des retouches. Dans un projet Odoo, les imports sont presque toujours itératifs : correction de mapping, enrichissement, nettoyage, changement de structure, nouveaux enregistrements apparus pendant le projet, etc.
Et pour éviter que chaque nouvel import se transforme en fabrique à doublons (ou en séance de “matching au feeling”), Odoo propose un outil aussi simple que puissant : les External IDs (identifiants externes, parfois appelés XML IDs). Odoo
Pourquoi la reprise de données n’est (presque) jamais “one shot”
Même avec une préparation sérieuse, il arrive toujours un moment où l’on se dit :
“On a oublié une colonne”
“Finalement on change la structure des catégories”
“On veut enrichir les fiches produits”
“On doit corriger des adresses”
“L’ancien système a continué de vivre, il faut réintégrer les nouveautés”
La vraie question n’est donc pas “comment importer une fois ?”, mais :
Comment réimporter pour mettre à jour — sans dupliquer, sans ambiguïté, et sans bricolage ?
Trois identifiants à ne plus confondre
1) L’ID interne Odoo (Database ID)
C’est l’identifiant interne d’un enregistrement dans la base. Dans PostgreSQL, il s’agit bien, dans la plupart des modèles persistants, d’une colonne id qui sert de clé primaire (créée/maintenue automatiquement) — ce n’est pas un “champ métier” et il n’est pas conçu pour être partagé entre bases ou environnements.
Dans l’interface d’import Odoo, tu peux d’ailleurs voir la notion de “Database ID” (ID base de données) comme colonne possible.
Ce qu’il faut retenir :
utile techniquement,
instable d’une base à l’autre (test → prod, ou réimport “à blanc”),
pas adapté comme clé d’échange “métier”.
2) La référence (ou un champ métier)
Très utile au quotidien, mais :
elle peut changer (nouvelle codification),
être mal saisie,
ou ne pas être unique.
Elle aide souvent à retrouver… mais pas toujours à mettre à jour sans ambiguïté.
3) L’External ID (clé stable de correspondance)
C’est une clé technique gérée par Odoo (via ir.model.data) qui associe un enregistrement à un identifiant externe stable (souvent construit comme module.nom).
Et surtout : en import, si ton fichier contient une colonne “External ID”, Odoo met à jour les enregistrements déjà importés au lieu de les recréer, ce qui permet de rejouer le même fichier après corrections.
“On peut déjà retrouver l’objet avec la référence.” Oui… mais ce n’est pas le vrai sujet.
On peut se dire : “On peut déjà retrouver l’objet avec la référence.”
C’est vrai… quand la référence est propre, unique, stable, et que tout le monde la respecte religieusement (spoiler : rarement).
Le sujet de la reprise de données, c’est plutôt :
mettre à jour le bon enregistrement
de façon automatique
et rejouable
Le cas ultra fréquent : plusieurs clients avec le même nom
Dans les bases réelles, on voit souvent :
plusieurs “Magasin Central”
plusieurs “Boutique Paris”
plusieurs “Agence Lyon”
Typiquement : une chaîne de magasins, ou des établissements secondaires.
Sans External ID, une mise à jour basée sur le nom (ou une pseudo-référence) devient :
soit un matching fragile (“nom + CP + ville…”),
soit une source de doublons,
soit pire : une mise à jour du mauvais enregistrement.
Avec un External ID basé sur l’identifiant unique de l’ancien système :
tu sais exactement lequel tu mets à jour
et tu peux réimporter autant de fois que nécessaire sans ambiguïté.
Les avantages (concrets) des External IDs en reprise de données
1) Imports rejouables : création au premier passage, mise à jour aux suivants
Odoo le gère très clairement : si tu importes avec “External ID”, les enregistrements déjà importés sont modifiés, pas recréés.
C’est la base d’une reprise sereine : tu peux corriger ton fichier et le réimporter.
2) Reprise incrémentale : tu avances par vagues (comme un projet sérieux)
V1 : socle minimal (clients/produits)
V2 : enrichissement (catégories, tags, conditions)
V3 : corrections et normalisation
V4 : ajouts de dernière minute
Et tout ça sans transformer ta base en cimetière de doublons.
3) Relations entre objets beaucoup plus robustes
Odoo recommande explicitement d’utiliser l’identifiant unique de l’application d’origine pour reconstruire les liens via les colonnes du type XXX/ID (relation vers l’External ID).
C’est particulièrement précieux pour :
sociétés ↔ contacts ↔ adresses
produits ↔ catégories ↔ variantes
produits ↔ fournisseurs
listes de prix ↔ règles tarifaires
4) Un process “mettable à jour” (la bonne formulation)
Plutôt que “réversible”, l’idée est :
un process reproductible, contrôlable et rejouable pour des mises à jour successives.
C’est exactement ce que permet la colonne External ID en import. Odoo
Méthodologie recommandée (simple et efficace)
Étape 1 — Exiger un identifiant unique stable côté client
Demander au client son identifiant unique (ancien système) pour :
clients / fournisseurs
produits
catégories
etc.
Étape 2 — Définir une convention de nommage
Exemples :
legacy_partner_12345
legacy_product_98765
legacy_category_42
Objectif : éviter les collisions, rester lisible.
Étape 3 — (Recommandé) Conserver aussi l’identifiant historique dans un champ “métier”
En plus de l’External ID (technique), garder un champ type “Identifiant ancien système” aide :
la recette,
le support,
et la compréhension côté utilisateurs.
Étape 4 — Import initial, puis imports de mise à jour
Tu importes une première fois, puis tu rejoues :
Odoo met à jour via External ID.
Après la migration : “les External IDs reprennent leur vie normale”
Point important : oui, c’est surtout pendant la migration que l’External ID est une star, parce que c’est la période des réimports et des ajustements. C’est d’ailleurs l’un des usages clés documentés : réimporter le même fichier pour mettre à jour sans créer de doublons, et reconstruire les relations via XXX/ID.
Après le go-live :
tu n’es pas obligé d’en parler tous les matins (on a déjà assez de sujets),
les External IDs que tu as posés pendant la migration restent une fondation technique très utile si tu dois rejouer des imports / corriger / interfacer,
mais pour les nouveaux enregistrements créés au fil de l’eau (par les utilisateurs, automatisations, etc.), il n’y a généralement pas d’External ID “lisible” créé “métier” par défaut.
Et c’est là que beaucoup le découvrent à l’export :
si aucun External ID propre n’existe, Odoo peut générer un identifiant générique du type __export__.sale_order_1884 (ou équivalent), pratique pour la machine… nettement moins pour l’humain.
Conclusion
Importer une base dans Odoo, c’est bien.
Pouvoir la mettre à jour proprement dix fois, sans doublons et sans ambiguïté, c’est mieux.
Les External IDs ne sont pas “un gadget technique” : ce sont les rails qui transforment une reprise de données en processus maîtrisé. Et une fois la migration passée, ils restent discrètement à leur poste — comme les meilleures traditions : celles qui évitent les mauvaises surprises.
Si tu veux, je peux aussi te proposer une version “cas pratique” (chaîne de magasins + produits multi-références) avec une structure de fichiers d’import et les colonnes exactes à prévoir.