Intégration ERP : API, connecteurs et donnée unique en temps réel

Table des matières :

1. Donnée unique en temps réel : définition opérationnelle et limites côté PrestaShop
2. API, connecteurs, iPaaS : choisir un pattern d’intégration ERP sans se mentir
3. Contrats API : idempotence, versioning, pagination et budgets de latence
4. Temps réel : événements, CDC et pattern Outbox (au lieu du “cron toutes les 5 minutes”)
5. Connecteurs côté PrestaShop : module Symfony, services, files d’attente, et désinstallation propre
6. Exploitation : secrets, réseau, SIEM, RGPD et “runbooks” d’incident
7. Mettre en place la “donnée unique” sans couper la boutique : cartographie, mapping, staging, et tests de charge

Donnée unique en temps réel : définition opérationnelle et limites côté PrestaShop

Parler de donnée unique en temps réel dans une intégration ERP, ce n’est pas promettre une cohérence « magique » entre systèmes. C’est définir (i) une source de vérité (System of Record) par domaine (stock, prix, client, facturation…), (ii) un SLA de propagation mesurable (p. ex. 2–10 s sur stock, 1–5 min sur prix), et (iii) une stratégie explicite de cohérence (strong, eventual, ou read-your-writes selon les flux). Dans l’e-commerce, le “temps réel” est surtout un budget de latence acceptable par le métier : au-delà de quelques secondes sur le stock, vous déclenchez des surventes et des annulations.

Une façon simple d’éviter les malentendus (DSI / e-commerce / logistique) est de formaliser, noir sur blanc, qui fait foi et à quelle vitesse — pas “en théorie”, mais sur vos flux réels :

Domaine	Source de vérité (SoR) recommandée	Consommateur(s)	Objectif de propagation (SLA)	Cohérence acceptable
Stock disponible (par entrepôt/canal)	ERP/WMS (ou OMS)	PrestaShop, marketplace	2–10 s	Eventual + garde-fous (réservation)
Prix (tarif public, remises)	ERP/PIM	PrestaShop	1–5 min	Eventual
Catalogue (attributs, médias)	PIM (ou ERP si pas de PIM)	PrestaShop	15–60 min	Eventual
Commande (création, statut)	PrestaShop (front) puis ERP (back-office)	ERP, BI	5–30 s	Read-your-writes côté client
Client / adresses	Variable (CRM/ERP ou PrestaShop)	ERP, marketing	1–10 min	Eventual + règles anti-duplication

Le cœur de PrestaShop (8.x/9.x) n’est pas conçu comme un MDM/ERP : c’est une application transactionnelle orientée panier/commande, avec une modélisation catalogue et stock qui varie selon les modules (advanced stock, multi-entrepôts, marketplaces, etc.). Résultat : si vous branchez un ERP “en direct” sur la base PrestaShop, vous créez une intégration fragile (couplage au schéma SQL, migrations risquées, effets de bord sur les hooks). La bonne cible, en 2026, reste un contrat d’échange (API/événements) et une couche d’intégration qui absorbe les écarts de modèle.

Sur la partie inventaire, la synchronisation “temps réel” se heurte à deux sujets : la concurrence (plusieurs checkouts simultanés) et les écritures concurrentes (ERP, WMS, canal marketplace). Si votre objectif est une disponibilité unifiée multi-canal, partez d’un design de type réservation/allocations et évitez le simple “stock = quantité”.

Mini-scénario (très courant en France/EU) : vous avez un stock “physique” piloté par WMS, un stock “commercial” piloté par ERP (avec allocations B2B), et des engagements marketplace. Si PrestaShop affiche directement “physique – 1”, vous risquez la survente en période de soldes/ventes flash. À l’inverse, si vous passez par une réservation courte durée au moment du paiement (ou du passage au transporteur), vous absorbez la concurrence tout en gardant un affichage cohérent par canal.

La lecture recommandée côté site : Inventaire unifié : synchronisation temps réel et routage par canal et, pour la gestion de contention, Performance e-commerce : prévenir la concurrence sur les stocks avec Redis.

API, connecteurs, iPaaS : choisir un pattern d’intégration ERP sans se mentir

Trois familles dominent en intégration ERP : API synchrone (REST/JSON ou SOAP), connecteur batch (CSV/XML via SFTP, jobs planifiés), et événementiel (bus Kafka/RabbitMQ/Redis Streams, webhooks, CDC). Sur le papier, l’API est séduisante : c’est “simple”, testable, observable. Dans la vraie vie, une API synchrone sans file de messages vous impose d’absorber les indisponibilités (ERP en maintenance, timeouts, pics de charge) au pire endroit : le front e-commerce.

Une grille de lecture utile (à partager avec le métier) consiste à confronter latence, résilience et coût opérationnel :

Pattern	Latence	Résilience aux pannes	Complexité d’exploitation	Cas d’usage “naturels”
API synchrone	Très faible	Faible à moyenne (sans queue)	Faible	création commande, check dispo ponctuel
Batch (SFTP/CSV)	Moyenne à élevée	Bonne (reprise facile)	Faible à moyenne	catalogue, prix, référentiels volumineux
Événements / CDC	Faible	Élevée (replay, découplage)	Élevée	stock, statuts, intégration multi-canal

Le batch reste pertinent quand le domaine le permet : mise à jour de prix à heure fixe, import catalogue la nuit, recalcul de règles tarifaires. Il est plus facile à reprendre (replay), mais il impose de gérer des fenêtres d’incohérence plus longues. Si vous avez déjà un ERP orienté connecteurs historiques, vous le verrez souvent sur des stacks type Dolibarr (SOAP) ou via exports. L’article Synchronisation Prestashop Dolibarr : installation, paramètres et webservices SOAP illustre bien le compromis : intégration rapide, mais surface d’erreurs et limites de débit.

L’événementiel est le meilleur candidat pour la donnée unique en temps réel, parce qu’il découple producteurs/consommateurs et met la reprise (replay) au centre. Mais il a un coût : gouvernance des schémas, gestion du “at-least-once”, outillage (DLQ, monitoring), et une équipe capable d’exploiter un broker.

Et l’iPaaS dans tout ça ? Il peut être un bon accélérateur quand :

• vous avez beaucoup d’applications (ERP + CRM + WMS + marketplace + BI) ;
• vous voulez une bibliothèque de connecteurs et des transformations “low code” ;
• vous acceptez un compromis : moins de contrôle fin, plus de gouvernance (et de coûts récurrents).

Si vous travaillez avec Odoo, l’approche bi-directionnelle (ERP ↔ e-commerce) est souvent la réalité, et elle force à définir clairement qui “possède” la donnée : cf. Intégration e-commerce Odoo : architecture bi-directionnelle et synchronisation stocks. Sans cette clarification, on se retrouve vite avec des “guerres d’écriture” (prix écrasés, clients dupliqués, statuts incohérents) qui coûtent plus cher que la mise en place d’un contrat propre.

Contrats API : idempotence, versioning, pagination et budgets de latence

Une intégration ERP par API tient ou casse sur le contrat. Concrètement : OpenAPI/JSON Schema versionnés, conventions de pagination (cursor-based si volumétrie), codes d’erreur stables, et surtout idempotence côté écriture. Le RFC HTTP rappelle une définition exploitable : “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 9110). Dans une sync ERP → PrestaShop, ça se traduit souvent par :

• une clé métier stable (erp_product_id, erp_order_id) persistée côté PrestaShop ;
• des endpoints “upsert” (PUT) ou des POST avec Idempotency-Key (si vous contrôlez l’API) ;
• un mécanisme de déduplication côté connecteur (hash payload + fenêtre temporelle).

Pour éviter les surprises, définissez aussi vos “détails qui fâchent” dès le départ (ceux qui font exploser une intégration en production) :

• Pagination : taille max de page, curseur, tri stable (sinon vous sautez des lignes ou vous les dupliquez).
• Gestion des erreurs : distinguer 4xx (payload à corriger) vs 5xx (rejouable), documenter précisément les cas 409/422.
• Time-out et retries : un retry aveugle peut créer un effet “mitrailleuse” sur un ERP fragile ; d’où l’intérêt de backoff + queue.
• Contrôle de version : versionner le contrat (URL ou header), et annoncer une politique de dépréciation.

Sur PrestaShop, évitez d’appeler le backoffice en synchrone depuis l’ERP sans budget de performance. Les mêmes causes produisent les mêmes effets : surcharge PHP-FPM, contention MySQL, et dégradation du tunnel. Si vous n’avez pas mesuré, vous pilotez à l’aveugle : alignez vos objectifs sur des métriques type TTFB et saturation worker.

Un repère opérationnel (à adapter) :

• flux “stock” : P95 < 10 s de bout en bout (ERP → intégration → PrestaShop), avec une file d’attente qui absorbe les pics ;
• flux “prix” : P95 < 5 min ;
• taux d’erreur “rejouable” : < 0,1% sur 24 h (au-delà, vous faites du support au lieu d’exploiter).

Pour cadrer : TTFB PrestaShop : réduire le Time To First Byte sous 200 ms et Performance PrestaShop : benchmarks et optimisation PHP-FPM, OPCache, MySQL.

Enfin, pensez sécurité API dès la conception : scopes, rotation de secrets, RBAC, rate limiting, audit logs, et segmentation réseau. Une API d’intégration n’est pas “un webservice interne” : c’est une surface d’attaque. Pour une approche orientée production : Sécurité PrestaShop : protéger API backoffice, WAF et journalisation SIEM et la référence OWASP API Security Top 10.

Temps réel : événements, CDC et pattern Outbox (au lieu du “cron toutes les 5 minutes”)

Le “temps réel” robuste en ERP integration se fait rarement avec un cron. Les architectures qui tiennent utilisent une combinaison : outbox (enregistrement atomique d’un événement lors de la transaction métier), broker (Kafka/RabbitMQ/Redis Streams), et consommateurs idempotents. Si vous lisez un ERP et poussez vers PrestaShop, l’objectif est de rendre l’ERP producteur d’événements (ou de simuler ce comportement).

Le point clé du pattern outbox, c’est qu’il évite le piège “double écriture” (mettre à jour la table métier et publier un message) sans transaction commune. En pratique :

• la transaction ERP écrit l’objet (ex. product, stock_move) et une ligne outbox (ex. event_type, aggregate_id, payload, created_at) ;
• un worker lit l’outbox et publie vers le broker ;
• la publication est traçable et rejouable, sans bloquer l’ERP.

Quand l’ERP ne sait pas émettre d’événements, la solution pragmatique est la CDC (Change Data Capture) sur la base de l’ERP : vous captez les changements au niveau du log de transactions, puis vous publiez des événements normalisés. Debezium résume exactement le concept : “Debezium is an open source distributed platform for change data capture.” CDC réduit la latence sans multiplier les hooks applicatifs, mais impose une discipline : schémas d’événements versionnés, gestion des suppressions, et contrôle du backfill (snapshot initial).

Deux garde-fous souvent oubliés en “CDC + e-commerce” :

• Données personnelles : si la CDC touche des tables clients/adresses, vous dupliquez potentiellement de la PII dans des logs et des queues. Il faut chiffrer, limiter les champs, maîtriser la rétention et les accès (sinon, vous créez un “shadow SI” difficile à auditer).
• Modèle d’événements : publier “l’objet complet” à chaque changement peut coûter cher ; publier des deltas peut compliquer la reconstruction. Une approche hybride (delta + checkpoint) est souvent plus robuste.

Le revers, c’est le “at-least-once” : vous recevrez des doublons, et parfois dans le désordre. Donc vous modélisez la consommation comme un état dérivé recalculable, pas comme une suite d’actions irréversibles. Sur les stocks, ça signifie souvent : publier des deltas + un checkpoint (quantité de référence) ou publier des réservations. Sur la partie observabilité de pipeline, Logstash : plugins Input, Filter, Output pour Elasticsearch et Kafka ou un équivalent reste utile.

Connecteurs côté PrestaShop : module Symfony, services, files d’attente, et désinstallation propre

En 2026, si vous développez un connecteur ERP côté PrestaShop, partez sur une base PrestaShop 9.1 (Symfony 6.4) et un PHP aligné (typiquement 8.2/8.3 en prod, selon votre hébergeur). Ne codez pas l’intégration comme un “script d’import” collé dans un controller : vous voulez des services testables, des Command/Handler, et une séparation claire entre parsing, mapping et persistence. La série Module PrestaShop 9 : structure, services et bonnes pratiques Symfony fournit le cadre de base.

Concrètement, un connecteur “propre” côté boutique a souvent :

• une couche inbound (API/webhook/consommation de queue) ;
• une couche mapping (ERP → modèle canonique → PrestaShop) ;
• une couche persistence (écritures maîtrisées, transactions, verrous si nécessaire) ;
• une couche observabilité (corrélation, métriques, journaux) ;
• une couche reprise (DLQ + replay).

Le point souvent négligé : la gestion de reprise. Une intégration ERP échoue en prod (timeouts, payload invalide, deadlocks MySQL, etc.). Votre module doit donc : (i) persister un journal des échanges (request/response, correlation id), (ii) exposer une DLQ logique (table ou queue), (iii) permettre le replay, et (iv) limiter l’impact sur la boutique (backpressure).

Un modèle minimal de journalisation qui rend service (sans “loguer toute la vie”) :

• correlation_id (UUID)
• direction (ERP→PS / PS→ERP)
• entity_type (product/stock/order/customer)
• external_id
• status (success/retryableerror/fatalerror)
• http_status (si API)
• error_code + error_message (normalisés)
• payload_hash (pour déduplication)
• created_at, processed_at

Pour les erreurs PHP et la séparation dev/prod, ne réinventez pas : appuyez-vous sur Gestion d’erreur PHP : bonnes pratiques et configuration développement/production.

Dernier point : un connecteur mal désinstallé laisse des tables, des overrides, des hooks et parfois des cron zombies. C’est un risque de sécurité et de performance à moyen terme. Mettez au carré install()/uninstall(), vos migrations, vos index, et vos cleanups — et prévoyez aussi le cas “désactivation temporaire” (feature flag) sans casser la boutique. L’article Modules PrestaShop : désinstallation propre, performances et sécurité en production devrait être un prérequis avant de brancher un ERP en production.

Exploitation : secrets, réseau, SIEM, RGPD et “runbooks” d’incident

Une intégration ERP est un composant d’infrastructure, pas juste “du code”. Pour la gestion des secrets (tokens API, certificats, DSN), appliquez une règle simple et vérifiable. La recommandation la plus concise reste celle du Twelve-Factor App : “Store config in the environment.” (https://12factor.net/config). En pratique : variables d’environnement injectées par l’orchestrateur, Vault/Secrets Manager, rotation, et interdiction des secrets en base ou dans le dépôt.

Côté réseau, segmentez : DMZ/API gateway, filtrage egress, mTLS si possible. Sur OVHcloud/VPS, ce sont des sujets concrets (anti-DDoS, règles firewall, ports SMTP, etc.). Les articles VPS OVHcloud : sécurité, anti-DDoS, SMTP 25 et bonnes pratiques admin et Landing zone OVHcloud : architecture hub-and-spoke avec OPNsense HA sont directement applicables si votre connecteur transite par une zone d’intégration.

Pour le SIEM et les logs, cherchez l’exploitabilité plutôt que le volume :

• 1 identifiant de corrélation de bout en bout (ERP ↔ intégration ↔ PrestaShop) ;
• des événements “métier” (ex. stock_update_applied, order_export_failed) en plus des logs techniques ;
• des alertes actionnables (ex. DLQ qui dépasse un seuil, taux d’erreurs 4xx, latence P95 qui dérive).

Enfin, ne négligez pas la conformité : une sync ERP manipule souvent des données personnelles (client, adresses, historiques). Vous devez connaître vos finalités, minimiser, tracer, et gérer la purge. Pour cadrer côté boutique : Audit RGPD PrestaShop : 88 points de contrôle pour boutiques.

Et côté prod : écrivez des runbooks (quoi faire quand l’ERP est down, quand la queue grossit, quand un delta stock diverge) et testez-les en conditions réalistes. Un runbook “utile” tient souvent en une page et répond à :

• Symptôme (ex. “la queue stock grossit depuis 30 min”)
• Impact (ex. “risque de survente / affichage faux”)
• Vérifications (métriques, logs, statut ERP, statut broker)
• Actions sûres (pause consommateurs, bascule mode dégradé, replay)
• Critères de sortie (latence revenue sous X, DLQ vidée, divergence résolue)

Mettre en place la “donnée unique” sans couper la boutique : cartographie, mapping, staging, et tests de charge

Le chemin pragmatique vers une intégration ERP propre passe par une phase de cartographie : entités, champs, clés, règles de gestion, et responsabilités (qui écrit quoi). Le piège classique : un mapping “à la main” qui explose au premier cas métier (produits pack, déclinaisons, taxes multi-pays, arrondis, etc.).

Un bon livrable (simple mais structurant) est une matrice “champ → règle → responsabilité”, par exemple :

• si le prix promo est calculé dans l’ERP, alors PrestaShop ne doit pas recalculer une règle concurrente ;
• si le stock est unifié multi-entrepôts, alors PrestaShop ne doit pas écraser une disponibilité par défaut à chaque delta ;
• si la TVA dépend du pays, alors le mapping doit préciser si vous poussez un prix TTC, HT, ou les deux + règles.

Documentez un modèle canonique (même minimal) et posez des clés techniques : external_id, source_system, last_sync_at, checksum. Pour l’approche audit/mapping/staging, la méthode décrite dans Migration PrestaShop vers Shopify : méthode d’audit, mapping et staging se transpose très bien à un projet ERP : ce sont les mêmes mécanismes de réduction du risque.

Ensuite, implémentez un plan en deux temps : backfill (reconstruire l’état cible depuis l’ERP) puis delta (maintenir à jour via événements/CDC). Ne mélangez pas les deux dans le même job sans garde-fous, sinon vous créez des effets de bord impossibles à diagnostiquer. Une bonne pratique simple : un marqueur “mode backfill” qui :

• écrit plus lentement (throttling) ;
• logue davantage (pour expliquer les écarts) ;
• ne déclenche pas certains hooks coûteux (selon votre design).

Côté base PrestaShop/MySQL, vous allez souvent ajouter des index et des tables de correspondance : faites-le proprement, avec EXPLAIN et des migrations versionnées. Pour éviter les régressions : Index MySQL : optimiser WHERE, JOIN et ORDER BY avec EXPLAIN et Base de données PrestaShop : routine de maintenance et nettoyage automatisé.

Enfin, validez par la charge et l’observation, pas au doigt mouillé. Une intégration “temps réel” peut être parfaite fonctionnellement et catastrophique en prod si elle génère des pics d’écritures (prix/stock) au mauvais moment.

Checklist de validation avant go-live (très concrète) :

• pic “catalogue/prix” : combien d’updates/minute votre PrestaShop encaisse sans dégrader le tunnel ?
• pic “commandes” : export commandes ERP en parallèle des confirmations e-mail / paiement ;
• scénario “ERP down 2 h” : la boutique continue-t-elle à vendre ? quel mode dégradé (stock figé, stock tampon, message) ?
• scénario “replay” : rejouer 10 000 événements stock crée-t-il des doublons ou des effets de bord ?
• divergence contrôlée : comment détectez-vous un écart (inventaire vs affichage) et comment vous le corrigez (reconciliation job) ?

Mettez en place des tests de charge ciblés (import catalogue, flash sale, pics de commandes), corrélez avec la saturation MySQL/PHP-FPM, et fixez des SLO (tail latency, taille de queue, taux d’erreurs). Pour industrialiser cette partie : PrestaShop performance : monitoring, tests de charge et runbooks soldes et, pour la reproductibilité des builds de connecteurs, Intégration continue PrestaShop : BuildKit, GitHub Actions et build reproductible.