Connecteur Pimcore Odoo : synchronisation bidirectionnelle produits et variantes

Table des matières :

1. Modèles de données Pimcore vs Odoo : où se cassent réellement les variantes
2. Définir la synchronisation bidirectionnelle : source of truth par champ, pas par système
3. Architecture d’un connecteur Pimcore Odoo robuste : événements + file + idempotence
4. Mapping produits/variantes : attributs, combinaisons, SKUs et traductions
5. Conflits, cohérence et reprises : ce que votre connecteur doit tracer explicitement
6. Tests, staging, sécurité : valider la bidirectionnalité sans casser l’ERP (ni la boutique)

Modèles de données Pimcore vs Odoo : où se cassent réellement les variantes

Une synchronisation bidirectionnelle produits et variantes entre Pimcore (PIM/MDM) et Odoo (ERP) se heurte d’abord à un problème de modèle, pas d’API. Côté Odoo, le couple product.template (produit “parent”) / product.product (variante) est structurant : les attributs (product.attribute, product.attribute.value) génèrent des combinaisons, et Odoo peut créer/archiver des variantes automatiquement selon les lignes d’attributs. Côté Pimcore, les variantes sont souvent modélisées via objets hérités (inheritance), field collections, ou objets enfants (selon la classe), ce qui donne une liberté… qui devient un piège quand il faut converger vers la mécanique Odoo.

Un point qui casse très souvent la synchro est la différence entre :

• attributs “variantants” (qui créent des product.product distincts) ;
• attributs “descriptifs” (qui ne doivent pas multiplier les variantes).

Odoo a justement une notion pour ça (attributs qui ne créent pas de variantes, selon la configuration), alors qu’en Pimcore on a tendance à ranger “tout ce qui ressemble à un attribut” au même niveau. Mini-scénario classique : dans Pimcore, vous avez Couleur + Taille + Matière. Si le connecteur pousse les 3 en variantant côté Odoo, vous explosez la combinatoire (ex. 8 couleurs × 6 tailles × 5 matières = 240 variantes au lieu de 48) et vous vous retrouvez à gérer des stocks sur des variantes qui n’ont aucun sens métier.

Le point critique est l’identifiant stable au niveau variante. Odoo utilise un id interne (non portable) et expose un default_code (SKU) et éventuellement un barcode. Pimcore a typiquement un key, un id objet, et des champs métiers (SKU, EAN, MPN). Si vous laissez la synchronisation “découvrir” les correspondances au fil de l’eau (ex. match par SKU), vous allez inévitablement produire des collisions (SKU réutilisé, changement de codification, variantes scindées/fusionnées). Le seul pattern robuste consiste à introduire un identifiant externe immuable (UUID) stocké dans les deux systèmes (champ custom côté Odoo, champ Pimcore, ou table de mapping dédiée).

Deux précisions opérationnelles qui évitent des incidents en production :

• Ne confondez pas “identifiant de mapping” et “identifiant métier”. Un EAN/GTIN est un excellent identifiant de distribution quand il est propre… mais dans la vraie vie il peut manquer, être dupliqué, ou ne pas exister sur certaines variantes (packs, sur-mesure, prototypes). L’UUID de mapping doit rester stable même si l’EAN change.
• Verrouillez contractuellement l’unicité : côté Odoo, imposez une contrainte (SQL ou logique applicative) sur x_pimcore_uuid pour éviter qu’un bug de retry crée deux templates/variantes “liés” au même UUID. Côté table de mapping, imposez des uniques sur (system, uuid) et (odoo_model, odoo_id).

Enfin, il faut accepter une limite d’Odoo : la génération de variantes n’est pas un simple CRUD. Modifier la structure d’attributs d’un product.template peut recréer des product.product, changer la matrice des combinaisons, et archiver des variantes existantes. Si votre connecteur “upsert” des variantes en boucle sans tenir compte de ces effets de bord, vous obtenez des doublons, des variantes orphelines et des écarts de stock. Concrètement, un connecteur robuste traite souvent le template comme une transaction : il met à jour les lignes d’attributs, laisse Odoo recalculer la combinatoire, puis re-map les variantes résultantes (par set de valeurs) avant d’écrire les champs de chaque variante.

La documentation Pimcore est claire sur le fait que Pimcore est conçu comme une plateforme de gestion de données et non un ERP, ce qui implique que l’intégration doit expliciter les règles de gouvernance des données plutôt que de les laisser implicites (docs : https://pimcore.com/docs/pimcore/current/).

Définir la synchronisation bidirectionnelle : source of truth par champ, pas par système

Une “synchronisation bidirectionnelle” n’est pas “tout le monde écrit tout partout”. En pratique, vous devez définir une source of truth par domaine (référentiel produit, logistique, finance) puis par champ. Exemple classique : descriptions marketing, médias et attributs de merchandising dans Pimcore ; stock, coûts, règles de réappro et parfois prix B2B dans Odoo. Si vous ne faites pas cette séparation, le premier import massif se passe bien… puis le run quotidien devient un générateur de conflits.

La manière la plus opérationnelle consiste à produire une matrice de responsabilités (RACI) par champ, et à l’implémenter dans le connecteur comme une politique d’écriture. Exemple concret :

• Écriture autorisée Pimcore → Odoo : nom, descriptions, poids, dimensions, EAN, attributs/valeurs, images (ou URLs), statut “vendable”.
• Écriture autorisée Odoo → Pimcore : disponibilité, délais, stock(s), statuts logistiques, coûts, éventuellement tarifs selon règles.
• Unidirectionnel uniquement pour certains champs sensibles : comptabilité, unités, taxes (souvent Odoo-only), ou DAM (souvent Pimcore-only).

Pour rendre cette décision “exécutable” (et pas juste un doc), formalisez-la en tableau simple que le connecteur peut traduire en règles :

Champ / Domaine	Pimcore écrit	Odoo écrit	Règle de conflit recommandée
Nom + descriptions (FR/EN)	Oui	Non (sauf exception)	LWW par champ, mais Pimcore prioritaire
Attributs & valeurs (taxonomie)	Oui	Non	Conflit bloquant si Odoo a divergé
default_code (SKU)	Oui (souvent)	Parfois	Workflow de changement + anti-doublon
barcode (EAN/GTIN)	Oui	Rarement	Validation stricte + refus des doublons
Stock dispo	Non	Oui	Odoo prioritaire (et attention aux modèles de stock)
Coût	Non	Oui	Odoo prioritaire
Images (DAM)	Oui	Non	Pimcore prioritaire, Odoo ne stocke souvent qu’un “cover”

Au niveau technique, cette politique doit s’appuyer sur une notion de mutabilité et de champ verrouillé (ex. un champ “managed_by” par bloc de données), sinon le connecteur ne peut pas arbitrer correctement. Et surtout, ne vous fiez pas à un simple “last updated wins” global : c’est trop brut. Utilisez plutôt un LWW par champ quand c’est tolérable, et des verrous métiers quand ce ne l’est pas (ex. interdiction de renommer un attribut déjà poussé en production).

Point d’attention très concret côté Odoo : certains champs “semblent” être des champs de stock (qty_available, etc.) mais sont calculés. Dans la plupart des cas, un connecteur ne doit pas “écrire le stock” en mettant à jour un champ sur product.product : il doit passer par des opérations de stock (mouvements/ajustements) cohérentes avec la configuration entrepôts (multi-warehouse), lots/séries, et éventuellement multi-sociétés. Ce détail change tout en France/Europe dès qu’on est en multi-entrepôts (ex. 3PL + dépôt interne) ou en gestion de lots (cosmétique, pharma, alimentaire).

Si votre e-commerce est PrestaShop, cette gouvernance n’est pas qu’un sujet back-office : la façon dont vous exposez les variantes a un impact direct sur l’UX (listes produits) et le SEO (indexation des combinaisons). Pour la couche boutique, le sujet “variante visible vs non visible” se recoupe avec les pratiques décrites dans Afficher les produits par attributs PrestaShop : variantes en listes produits et, pour l’indexation/canonical, dans Référencement PrestaShop : optimiser fiches produits, catégories, canonical et hreflang.

Architecture d’un connecteur Pimcore Odoo robuste : événements + file + idempotence

Les exemples ci-dessous partent sur Pimcore 11.x (Symfony 6.4, PHP 8.3) et Odoo 17.x via JSON-RPC. Pré-requis côté infra : une file de messages (RabbitMQ/Redis Streams), une base de mapping (MariaDB/MySQL), et un environnement de staging fidèle. Si vous n’avez pas de staging, vous allez tester la régénération de variantes directement sur la prod Odoo, ce qui est mécaniquement risqué (voir Staging PrestaShop : créer un environnement Docker fidèle à la production).

Le pattern qui tient la charge et les cas d’erreur est le suivant : (1) capture d’événements côté Pimcore, (2) normalisation + publication dans une file, (3) workers qui appellent Odoo, (4) écriture d’un journal de sync + table de correspondance, (5) callbacks/webhooks ou polling pour le retour Odoo → Pimcore. C’est la même logique que pour une intégration ERP e-commerce “propre” : découpler l’écriture (événements) de l’exécution (workers), limiter les transactions distribuées, et rendre chaque message rejouable. Le panorama “API, webhooks, files RabbitMQ” est détaillé dans Intégration ERP e‑commerce : architecture API, webhooks et files RabbitMQ.

Dans la pratique, côté Odoo, prévoyez souvent un mode polling (par write_date ou par un champ technique “à synchroniser”) plutôt que de dépendre de webhooks génériques : Odoo expose très bien des APIs, mais l’émission d’événements “push” est généralement mise en place via un module spécifique ou des automatisations, selon votre niveau de personnalisation. L’important n’est pas le mécanisme (poll vs push), mais le fait de rejouer et réconcilier : si un événement est raté, votre système doit le rattraper.

Le point non négociable est l’idempotence. Une file + des retries implique que le même message peut être traité plusieurs fois. Il faut donc un upsert déterministe. L’RFC HTTP définit précisément le concept : “A request method is considered "idempotent" if the intended effect on the server of multiple identical requests with that method is the same as the effect for a single such request.” (RFC 7231, section 4.2.2 : https://www.rfc-editor.org/rfc/rfc7231). En clair : votre connecteur doit produire le même état Odoo après 1 ou 5 exécutions du même message.

Une manière simple d’y arriver (sans “magie”) est de standardiser l’enveloppe de message :

• external_uuid (l’UUID Pimcore immuable)
• entity (product.template, product.product, attributs…)
• operation (upsert, archive, link, unlink)
• payload_hash (hash stable du payload normalisé)
• idempotency_key (souvent entity + external_uuid + payload_hash)

Ainsi, si un message identique revient, vous le dédupliquez avant d’appeler Odoo, ou vous faites un “no-op” contrôlé.

Côté Odoo, JSON-RPC reste l’interface la plus standard (il existe aussi XML-RPC). Exemple minimaliste (Symfony HttpClient) pour exécuter execute_kw sur product.template ; à adapter (auth, gestion d’erreurs, pagination) :

// Pimcore/Symfony 6.4 - PHP 8.3
$payload = [
  'jsonrpc' => '2.0',
  'method'  => 'call',
  'params'  => [
    'service' => 'object',
    'method'  => 'execute_kw',
    'args'    => [$db, $uid, $apiKey, 'product.template', 'search_read',
      [[['x_pimcore_uuid', '=', $uuid]]],
      ['fields' => ['id','name','write_date']]
    ],
  ],
  'id' => 1,
];
$response = $httpClient->request('POST', $odooUrl.'/jsonrpc', ['json' => $payload]);
$data = $response->toArray(false);

Mapping produits/variantes : attributs, combinaisons, SKUs et traductions

Le mapping “produit” est rarement le problème ; le mapping “variantes” l’est presque toujours. En Odoo, une variante (product.product) est la matérialisation d’un ensemble de valeurs d’attributs attachées au template. Dans Pimcore, vous avez souvent un objet “Produit” avec des enfants “Variante” où chaque variante porte sa propre liste d’attributs (taille, couleur) et ses champs (SKU, EAN, images spécifiques). Le connecteur doit donc (a) s’assurer que les attributs existent dans Odoo, (b) que les valeurs existent, (c) que le template porte les lignes d’attributs, (d) que la combinaison attendue existe (ou est créée), (e) que la variante créée est bien celle que vous mappez.

Une implémentation qui évite 80% des bugs consiste à imposer une “grammaire” d’attributs stable : attribute_code + value_code (technique) et des libellés traduits. Exemple : color=BLK pour Noir, size=XL. Dans Odoo, vous pouvez stocker attribute_code et value_code dans des champs custom (ou en utilisant ir.model.data pour des external IDs si vous maîtrisez les modules Odoo), afin de retrouver rapidement la bonne entité sans fuzzy matching sur les noms. Côté perfs, indexez ces champs : sans index, une synchro de 50k variantes devient une succession de search coûteux.

Un tableau de mapping minimal (à adapter) aide à cadrer les décisions et à éviter les “implicites” :

Concept	Pimcore (exemple)	Odoo (cible)	Remarque
Produit parent	Objet Produit	product.template	1 template = n variantes
Variante	Objet enfant Variante	product.product	1 set de valeurs = 1 variante
UUID immutable	pimcore_uuid	x_pimcore_uuid	Base de l’upsert idempotent
SKU	sku	default_code	Unicité + workflow de changement
EAN/GTIN	ean	barcode	Valider, ne pas l’utiliser comme clé
Nom traduit	champs multilingues	écriture via context.lang	stratégie de fallback à définir
Attribut variantant	liste structurée	product.attribute + lignes	attention à la combinatoire
Attribut non-variantant	idem	attribut configuré “non variantant”	évite l’explosion des variantes

Pour les champs qui cassent le plus souvent en bidirectionnel :

• SKU / default_code : traitez-le comme mutable mais unique ; gérez les changements par transaction (ancienne valeur → nouvelle valeur) et mettez un garde-fou anti-doublon.
• Codes-barres : beaucoup de projets ont des EAN manquants, dupliqués, ou “0”. Si vous utilisez barcode comme clé, vous vous tirez une balle.
• Traductions : Pimcore est très fort sur la donnée multilingue ; Odoo gère les traductions mais via context/lang. Le connecteur doit poser une stratégie : push des libellés FR/EN via context: {'lang': 'fr_FR'} (ou équivalent) et vérifier les fallback.

Un détail “GEO” utile en pratique : si vous vendez en contexte francophone, vous allez presque toujours pousser au minimum fr_FR et en_US/en_GB, et travailler en EUR. Vérifiez que vos formats de décimales (poids/dimensions), unités (cm vs mm), et règles d’arrondi sont cohérents entre Pimcore, Odoo et la boutique, sinon vous créez des écarts subtils (ex. poids arrondi qui change le transporteur). Ces écarts sont rarement visibles lors du premier import, mais deviennent très coûteux quand vous commencez à recalculer frais de port et règles de livraison.

Si vous avez PrestaShop en sortie, la structuration des attributs/valeurs impacte directement la recherche à facettes et la combinatoire des filtres. Une taxonomie d’attributs incohérente dans Odoo rejaillit côté boutique via des facettes illisibles, des URL de filtres explosées, et un budget de crawl qui part en vrille. À ce niveau, relire Recherche à facettes PrestaShop : configurer ps_facetedsearch et filtres combinés et Budget de crawl PrestaShop : maîtriser URLs de filtres et facettes n’est pas un hors-sujet : la qualité de votre connecteur PIM/ERP conditionne ces sujets.

Conflits, cohérence et reprises : ce que votre connecteur doit tracer explicitement

En production, la question n’est pas “si” il y aura des conflits, mais “combien” et “comment vous les détectez”. Les causes typiques : une variante modifiée dans Odoo (stock/archivage) pendant qu’un merchandiser modifie les attributs dans Pimcore ; un template dont les attributs changent, déclenchant une régénération de variantes ; des imports massifs qui saturent Odoo et produisent des timeouts. La seule réponse viable est de journaliser : pour chaque message, stockez external_uuid, modèle, action, hash du payload, horodatage, statut, erreur, nombre de retries.

Ajoutez aussi un point souvent négligé : le “compte” et le “contexte” de modification. Si une mise à jour Odoo vient d’un import comptable, d’un utilisateur back-office, ou de votre connecteur, la résolution de conflit n’est pas la même. Côté Odoo, vous pouvez marquer les écritures “connecteur” via un champ technique, ou a minima via le write_uid et une convention de compte technique. Côté Pimcore, même logique : distinguer ce qui vient d’un enrichissement éditorial vs d’un flux ERP.

Pour arbitrer proprement, utilisez des “versions” comparables : modificationDate (Pimcore) vs write_date (Odoo). Attention : ce sont des timestamps issus de systèmes différents, avec des fuseaux, des formats, et parfois des secondes arrondies. Normalisez en UTC et stockez en RFC3339. Dans Odoo, write_date est généralement renvoyé comme une chaîne YYYY-MM-DD HH:MM:SS sans information de fuseau : votre connecteur doit fixer une convention (et la tester sur votre instance) pour éviter les faux “conflits” dus à un décalage.

Pour les merges, adoptez une règle explicite :

• LWW par champ si le champ est faible impact (ex. description courte).
• Priorité système si le champ est critique (ex. prix, taxes, stock).
• Conflit bloquant si le champ change de nature (ex. changement de set d’attributs qui modifie les variantes).

La stratégie de retry doit être agressive mais contrôlée : exponential backoff, circuit breaker, et dead-letter queue pour les erreurs non transitoires (validation, données incohérentes). Ne loggez pas “à la main” avec des dumps : produisez des logs structurés + un trace ID par message. Le rappel le plus utile sur les logs reste celui du Twelve-Factor App : “Logs are the stream of aggregated, time-ordered events collected from the output streams of all running processes and backing services.” (https://12factor.net/logs). En pratique : JSON logs + agrégation (OpenSearch/ELK) + métriques (Prometheus) + alertes.

Exemple de champs utiles à tracer (même si vous ne les exposez pas en UI) :

• trace_id (corrélation bout-en-bout)
• idempotency_key
• direction (pimcore_to_odoo, odoo_to_pimcore)
• status (success, retrying, blocked, dead_letter)
• duration_ms
• odoo_error_code / validation_path (quand vous pouvez l’extraire)

Enfin, surveillez la base de mapping. Elle devient rapidement un point chaud : lookup à chaque upsert, contraintes d’unicité, migrations de schéma. Indispensables : index composite sur (system, external_uuid), index sur odoo_model + odoo_id, et une politique de purge/archivage du journal. Si vous voyez des requêtes qui dérivent, vous retombez sur un problème classique d’e-commerce : requêtes lentes et verrous. Le guide Audit MySQL/MariaDB : optimiser les requêtes lentes e‑commerce est directement applicable à ce sous-système.

Tests, staging, sécurité : valider la bidirectionnalité sans casser l’ERP (ni la boutique)

La bidirectionnalité se teste avec des jeux de données qui ressemblent à la vraie vie : attributs incomplets, variantes désactivées, changements de taxonomie, produits multi-catégories, traductions partielles. Évitez le test “happy path” sur 10 produits : il ne couvre rien. Mettez en place un dataset de non-régression (ex. 1 000 templates, 10 000 variantes, 3 langues, 2 pricelists) et des scénarios reproductibles : renommage d’un attribut, suppression d’une valeur, split d’un produit en deux, fusion de variantes, changement de SKU.

Ajoutez un scénario de test qui simule la régénération de variantes (le cas le plus risqué) :

1. créer un template avec 2 attributs variantants (ex. couleur/taille) ;
2. synchroniser vers Odoo et mapper toutes les variantes ;
3. modifier la taxonomie (ex. ajouter une valeur, ou basculer un attribut en non-variantant) ;
4. vérifier que le connecteur :

• ne crée pas de doublons,
• re-map correctement les variantes existantes,
• n’écrit pas de stock “au mauvais endroit”.

Côté CI/CD, vous voulez des tests d’intégration qui peuvent tourner sans toucher l’Odoo de prod. Deux approches réalistes : (1) un Odoo de staging avec base anonymisée/rafraîchie, (2) un mock contractuel de l’API JSON-RPC (Pact, VCR, snapshots) plus des tests end-to-end sur staging. Si votre connecteur est un module (PrestaShop ou Pimcore), l’outillage “compatibilité / validation” est transposable : ps-validator : intégration CI/CD du Validator PrestaShop en terminal illustre le principe (automatiser les contrôles), et ChaosLab : tester modules PrestaShop sur 23 environnements PHP rappelle pourquoi vous devez tester contre plusieurs versions de PHP si votre runtime varie.

Sur la sécurité, ne banalisez pas l’accès ERP : l’API Odoo doit être derrière TLS, avec un compte technique à privilèges minimaux, et idéalement une segmentation réseau (VPN/allowlist). Les credentials doivent vivre dans un coffre (Vault/KMS), pas dans des .env copiés à la main. Et si le connecteur touche aussi PrestaShop (import des données produit, mises à jour des stocks), appliquez la même rigueur sur les API : scopes, rotation de secrets, limitation des endpoints. Les principes généraux sont couverts dans PrestaShop : sécuriser APIs et modules avec SBOM, WAF et CI/CD et, pour la partie “créer un connecteur propre”, dans Intégration API PrestaShop : créer un connecteur ERP sur mesure.

Enfin, pour la mise en production, planifiez la charge. Une synchro initiale de 10k variantes peut passer “à la main”, mais 200k variantes avec images + traductions impose du batching, de la parallélisation contrôlée, et des plafonds de débit pour ne pas dégrader Odoo (verrous, latence utilisateur back-office). Un repère simple pour dimensionner : mesurez la latence moyenne d’un “upsert variante” (ex. 200–800 ms selon votre instance et la complexité), puis calculez un débit cible conservateur, et n’augmentez la concurrence qu’après avoir observé les verrous et le temps de réponse côté Odoo.

Si vous hébergez PrestaShop et vos services de sync sur la même infra, vous devez aussi protéger le front : files dédiées, workers isolés, limites CPU/RAM, et cache côté boutique. Les checklists d’architecture et d’exploitation de Hébergement PrestaShop géré : migration sans coupure, staging et maintenance et PrestaShop auto-hébergé : prérequis d’installation, maintenance et sécurité donnent un cadre opérationnel : même si votre connecteur n’est pas “dans” PrestaShop, il partage les mêmes contraintes de prod (latence, incidents, rotation de logs, backups, restauration).