Synchronisation Prestashop Dolibarr : installation, paramètres et webservices SOAP

Table des matières :

Synchronisation PrestaShop–Dolibarr : ce que SOAP change vraiment côté architecture
Prérequis serveur : PHP, extensions, TLS et exécution batch sans bricolage
Activer et cadrer les webservices SOAP côté Dolibarr (WSDL, droits, entités)
Côté PrestaShop : module de synchronisation, configuration et stockage des correspondances
Client SOAP PHP : configuration, timeouts et gestion correcte des faults
Mapping métier : tiers, produits, stocks, commandes — là où ça casse réellement
Paramètres de synchronisation : fréquence, incrémental, idempotence et nettoyage des données
Sécurité et observabilité : SOAP expose des surfaces d’attaque, traitez-le comme une API critique
Recette technique : cas de test concrets et check-list de mise en production

Synchronisation PrestaShop–Dolibarr : ce que SOAP change vraiment côté architecture

Sur le papier, “Synchronisation PrestaShop Dolibarr” veut dire réconcilier deux modèles de données qui n’ont pas été conçus pour dialoguer. PrestaShop (8.1.x / 9.1.x) expose nativement un Webservice REST (XML/JSON selon implémentation), mais pas de SOAP dans le cœur. Dolibarr, lui, a historiquement proposé des webservices SOAP (NuSOAP) et, selon versions/modules, une API REST plus moderne. Résultat : quand vous imposez “SOAP” dans le cahier des charges, vous imposez généralement SOAP côté Dolibarr et un client SOAP côté PrestaShop, tout en gardant côté PrestaShop vos points d’entrée habituels (hooks, commandes Symfony, tables de mapping).

Dans l’architecture, ça a une conséquence concrète : vous allez maintenir une couche d’adaptation (adapter/anti-corruption layer) qui “traduit” :

les identifiants (IDs PrestaShop vs IDs Dolibarr),
les concepts (déclinaisons, états de commande, règles de taxe),
et les contraintes techniques (timeouts, tailles de payload XML, sécurité TLS).

Le SOAP n’est pas “magique”. C’est un protocole de messagerie XML avec WSDL et types, utile pour contractualiser, mais souvent plus fragile en production (erreurs de parsing XML, timeouts, WSDL cache, encodage, montées en charge). Le W3C définit SOAP comme : « SOAP is a lightweight protocol for exchange of information in a decentralized, distributed environment. » (W3C, SOAP Version 1.2 Part 1, https://www.w3.org/TR/soap12-part1/). “Lightweight” en 2026, ça se discute : sur des gros flux produits, la verbosité XML se paye en CPU + latence.

Avant d’installer quoi que ce soit, tranchez le point le plus coûteux si vous l’ignorez : qui est maître de la donnée ? Si PrestaShop est maître du catalogue, Dolibarr devient un récepteur (ou un miroir) pour facturation/ERP. Si Dolibarr est maître (plus courant en ERP), PrestaShop devient un front d’exposition : produits/stocks/prix “descendent” de Dolibarr, commandes “remontent” vers Dolibarr. Sans cette décision, vous fabriquez une synchro bi-directionnelle non déterministe (conflits, écrasements, commandes en double).

Une manière simple d’éviter les ambiguïtés est de décider par objet (et non “globalement”) :

Objet	Maître recommandé (cas le plus fréquent)	Sens principal	Remarque clé
Catalogue (produits, prix)	Dolibarr (ERP)	Dolibarr → PrestaShop	Éviter les écritures concurrentes sur prix/TVA
Stocks	Dolibarr si logistique ERP	Dolibarr → PrestaShop	Sinon oscillations et ruptures “fantômes”
Clients (tiers)	PrestaShop (B2C)	PrestaShop → Dolibarr	Nécessite une stratégie anti-doublons robuste
Commandes / factures	PrestaShop (commande) puis Dolibarr (facture)	PrestaShop → Dolibarr	Idempotence obligatoire (pas de double facture)

Pour cadrer les patterns de synchro (temps réel vs batch, idempotence, file d’attente), l’article sur l’intégration e-commerce Odoo donne un cadre réutilisable même si l’ERP n’est pas Odoo : https://www.expertise-prestashop.fr/2026/05/25/integration-e-commerce-odoo-architecture-bi-directionnelle-et-synchronisation-stocks/

Prérequis serveur : PHP, extensions, TLS et exécution batch sans bricolage

Les exemples ci-dessous sont validés sur PrestaShop 8.1.7 et 9.1.0, PHP 8.2.x, serveur Nginx (mais Apache OK), et Dolibarr 19.x (webservices SOAP actifs). Adaptez si vous êtes en PHP 8.3/8.4 : la logique reste identique, mais le comportement réseau/SSL varie parfois selon libcurl/OpenSSL. Pour les compatibilités PHP/PrestaShop, référez-vous à : https://www.expertise-prestashop.fr/2026/03/24/prestashop-9-1-compatibilite-php-8-1-8-5-cli-et-nouveautes-developpeurs/

Côté PrestaShop, le strict minimum pour consommer un SOAP Dolibarr est l’extension PHP soap. Le manuel PHP est explicite : « The SoapClient class provides a client for SOAP 1.1, SOAP 1.2 servers. » (PHP Manual, https://www.php.net/manual/en/class.soapclient.php). Vérifiez :

php -m | grep -i soap
php -i | grep -i "soap.wsdl_cache"

Si absent : activez extension=soap (Debian/Ubuntu : apt install php8.2-soap). En prod, gardez le cache WSDL activé (soap.wsdl_cache_enabled=1) mais maîtrisez-le (durée et invalidation lors des changements Dolibarr). Désactivez le cache uniquement en dev.

Deux détails “serveur” sont souvent oubliés et coûtent cher le jour où le flux grossit :

Cohérence PHP CLI vs PHP-FPM : la synchro batch passera via php CLI (cron), alors que votre site tourne via PHP-FPM. Assurez-vous qu’ils pointent sur la même version et les mêmes php.ini (sinon “ça marche en web, pas en cron”… ou l’inverse).
Limites d’exécution : un batch de synchro a rarement les mêmes contraintes qu’une page front. En pratique, surveillez memory_limit, default_socket_timeout, et la limite du service (systemd) si vous exécutez des commandes longues.

Le deuxième prérequis, c’est TLS. Ne faites pas transiter des credentials Dolibarr en clair. Forcer HTTPS, idéalement avec une allowlist IP au niveau reverse proxy (ou WAF) entre PrestaShop → Dolibarr. Sur la partie durcissement, l’approche “API backoffice + WAF + SIEM” de ce guide est applicable telle quelle : https://www.expertise-prestashop.fr/2026/05/29/securite-prestashop-proteger-api-backoffice-waf-et-journalisation-siem/

Enfin, une synchro sérieuse n’est pas un bouton backoffice cliqué “quand on y pense”. Elle s’exécute en batch (cron + commande Symfony) ou en asynchrone (queue). PrestaShop 8+ expose bin/console : c’est le point d’entrée propre. Évitez les scripts PHP appelés via HTTP (timeouts, exposition publique, logs pauvres).

Un repère opérationnel simple : si vous ne pouvez pas exécuter et monitorer la commande de synchro comme n’importe quel job (code retour, durée, logs, alerte), vous n’êtes pas “prêt prod”. Si vous n’êtes pas déjà outillé côté perf serveur, le travail sur TTFB et sur la visibilité des goulots se transpose directement aux jobs de synchro : https://www.expertise-prestashop.fr/2026/06/03/ttfb-prestashop-reduire-le-time-to-first-byte-sous-200-ms/

Activer et cadrer les webservices SOAP côté Dolibarr (WSDL, droits, entités)

Dolibarr propose des endpoints SOAP historiques via ses fichiers htdocs/webservices/*.php (NuSOAP). Selon votre version et modules activés, vous trouverez typiquement un WSDL du type :

https://dolibarr.example.com/webservices/server_other.php?wsdl
https://dolibarr.example.com/webservices/server_thirdparty.php?wsdl

Le bon réflexe : ouvrez le WSDL dans un navigateur et vérifiez qu’il est accessible uniquement depuis l’IP du serveur PrestaShop. En cas de 403/404, ce n’est pas “un bug PrestaShop” : c’est soit une route bloquée (Nginx), soit un module/permission Dolibarr, soit un chemin différent selon la distribution.

Un test rapide (utile aussi pour distinguer un problème TLS d’un problème applicatif) :

vérifiez que le WSDL répond en HTTPS (code 200),
et que la taille/latence est stable (un WSDL qui met 10 secondes à sortir annonce des problèmes à venir).

Le point qui casse 80% des intégrations : les droits de l’utilisateur Dolibarr utilisé par le webservice. Créez un compte technique dédié (pas un admin humain), avec un périmètre minimal : lecture/écriture tiers, produits, commandes, factures selon les flux. Si Dolibarr est en multi-société/multi-entité, la variable entity (ou un paramètre équivalent) doit être explicitement gérée, sinon vous synchronisez dans la mauvaise entité et vous ne le voyez qu’au moment de la facturation.

Sur l’authentification, le SOAP Dolibarr varie : login/mot de passe, parfois un token, parfois un couple login + password passé à une méthode login() qui retourne un sessionId. Ne “déduisez” pas : lisez le WSDL et générez un client à partir de celui-ci.

Deux recommandations pragmatiques (souvent négligées) :

Ne mettez pas le compte technique dans les mêmes groupes/droits qu’un humain. Un connecteur a tendance à “faire plus” que prévu au fil des itérations ; en limitant le périmètre, vous limitez l’impact d’une erreur de code.
Décidez si l’API Dolibarr est joignable depuis Internet. Dans beaucoup de cas, un réseau privé (VPN inter-sites, tunnel, VPC) est plus fiable qu’une exposition publique + IP allowlist.

Côté PrestaShop : module de synchronisation, configuration et stockage des correspondances

Dans PrestaShop, la synchro n’a pas sa place dans un override bricolé. Le pattern robuste : un module avec (1) une UI de config (backoffice), (2) une commande Symfony pour batch, (3) éventuellement des hooks pour déclencher une synchro incrémentale (ex : après création de commande). Sur PrestaShop 9 (Symfony 6.4), vous pouvez structurer proprement services/DI. Si vous utilisez Doctrine dans votre module (utile pour requêtes complexes et tests), le cadre de développement est bien décrit ici : https://www.expertise-prestashop.fr/2026/05/06/symfony-prestashop-developper-des-modules-robustes-avec-doctrine/

La configuration doit couvrir au minimum : URL WSDL Dolibarr, credentials, entity, timeouts, et stratégie de synchro (push/pull, sens, périmètre). Ne stockez pas un mot de passe en clair dans une table sans contrôle : utilisez les mécanismes de configuration PrestaShop mais chiffrez côté serveur si possible (libsodium/OpenSSL) et restreignez l’accès backoffice. Si vous ne pouvez pas, assumez : le risque est un accès latéral à Dolibarr en cas de compromission BO.

Pour éviter les erreurs “invisibles”, ajoutez aussi des paramètres qui ne sont pas purement techniques :

Mode “dry-run” (ou “lecture seule”) pour valider les mappings sans écrire dans Dolibarr.
Périmètre : toutes les boutiques / toutes les langues / uniquement une catégorie / uniquement les produits actifs.
Stratégie de reprise : nombre de retries, backoff, et seuil de mise en quarantaine.

Pour relier les objets, bannissez les “matchs” par email ou par référence produit (ça change). Faites du mapping explicite via une table dédiée, par exemple :

ps_dolibarr_mapping (object_type, prestashop_id, dolibarr_id, checksum, updated_at)

Le checksum (hash des champs synchronisés) permet d’éviter des updates inutiles et de limiter la charge. Indexez object_type + prestashop_id et object_type + dolibarr_id. Si vous négligez l’indexation, votre job passera de 30s à 30 min à mesure que le volume grandit (le symptôme classique : CPU faible mais I/O MySQL saturé).

Astuce de terrain : sur les objets “critiques” (commande, facture), stocker aussi la référence croisée dans Dolibarr (champ libre / extrafield / note) peut aider lors des restaurations ou des audits : si vous restaurez la base PrestaShop et perdez la table de mapping, vous avez au moins une trace côté ERP pour reconstruire.

Sur les aspects index et EXPLAIN : https://www.expertise-prestashop.fr/2026/05/25/index-mysql-optimiser-where-join-et-order-by-avec-explain/

Client SOAP PHP : configuration, timeouts et gestion correcte des faults

Le client SOAP le plus simple est SoapClient, mais le plus simple est rarement le plus résilient. En production, fixez explicitement : connection_timeout, exceptions, trace (désactivé en prod), cache_wsdl, et surtout la gestion de l’encodage. Exemple minimal (à adapter aux méthodes réelles de votre WSDL) :

$wsdl = 'https://dolibarr.example.com/webservices/server_other.php?wsdl';

$client = new SoapClient($wsdl, [
    'cache_wsdl' => WSDL_CACHE_BOTH,
    'exceptions' => true,
    'connection_timeout' => 10,
    'stream_context' => stream_context_create([
        'ssl' => [
            'verify_peer' => true,
            'verify_peer_name' => true,
        ],
        'http' => [
            'timeout' => 30,
        ]
    ]),
]);

try {
    $session = $client->login(['login' => $user, 'password' => $pass, 'entity' => 1]);
} catch (SoapFault $e) {
    // Log structuré + backoff, pas un die()
    throw new RuntimeException('Dolibarr SOAP login failed: '.$e->getMessage(), 0, $e);
}

Trois points à surveiller : (1) timeouts (un SOAP qui pend = job bloqué), (2) taille des payloads (XML volumineux = mémoire), (3) cache WSDL (un changement côté Dolibarr peut casser le parsing tant que le cache n’expire pas). Si vous faites une montée de version Dolibarr, planifiez explicitement une purge du cache WSDL (redémarrage PHP-FPM ou purge spécifique selon config).

Un quatrième point, plus “prod” que “dev” : limitez ce que vous loggez. SoapClient peut exposer la requête/réponse complète quand trace est activé ; c’est utile en debug, mais en production vous risquez de journaliser des données personnelles (adresse, email, téléphone) et/ou des secrets. Préférez des logs de métadonnées (durée, statut, IDs) plutôt que le payload brut.

Côté erreurs, différenciez :

SoapFault applicatif (méthode invalide, droits insuffisants) → à corriger, pas à “retry”.
Timeout / 502 / erreurs réseau → retry avec backoff.
Validation métier (TVA manquante, tiers incomplet) → à mettre en quarantaine (dead letter).

Le cœur PrestaShop n’offre pas une file d’attente robuste. Si vous devez fiabiliser, externalisez (RabbitMQ/Redis) ou au minimum journalisez de manière exploitable. Pour centraliser les logs et tracer les erreurs de synchro, une stack type Logstash est standard : https://www.expertise-prestashop.fr/2026/06/05/logstash-plugins-input-filter-output-pour-elasticsearch-et-kafka/

Mapping métier : tiers, produits, stocks, commandes — là où ça casse réellement

Clients / tiers : PrestaShop a customer, adresses multiples, groupes, langues. Dolibarr a thirdparty (société) + contacts/adresses. Décidez si un client PrestaShop = un tiers Dolibarr (B2C) ou si vous regroupez (ex : un tiers “Particuliers” + contacts). Dans 90% des B2C, le 1:1 est plus simple, mais attention aux doublons si l’email change : d’où l’importance du mapping par ID et non par email.

Point d’attention très concret en France/UE : B2B et TVA intracommunautaire. Si vous vendez aux pros, vous devrez souvent synchroniser des champs qui n’existent pas “nativement” dans un checkout B2C (raison sociale, n° TVA, SIRET selon votre process, adresse de facturation distincte). Décidez clairement si ces informations sont saisies dans PrestaShop (et “poussées” vers Dolibarr), ou si Dolibarr est maître du tiers (et PrestaShop ne fait que rattacher la commande à un tiers existant).

Produits : PrestaShop gère les déclinaisons (combinations) et les attributs ; Dolibarr gère produits/services avec références et, selon modules, variations limitées. La stratégie la moins mauvaise : considérer chaque combinaison PrestaShop comme une “référence” Dolibarr distincte (SKU unique), sinon vous perdez la granularité stock/prix. Mais ça multiplie le volume.

Deux pièges fréquents :

Arrondis / précision prix : PrestaShop et Dolibarr peuvent arrondir différemment (TTC/HT, règles de taxe, devises). Pour éviter des écarts de centimes qui “salissent” la comptabilité, choisissez une règle : pousser HT + taux de TVA, ou pousser TTC “figé”, mais soyez cohérent sur toute la chaîne.
Produits vs services : dans Dolibarr, les frais de port, emballage cadeau, ou “frais de paiement” sont plus simples à gérer comme services que comme produits physiques, surtout si vous n’avez pas de stock.

Si votre catalogue est massif, vous devez aussi traiter la question “archive vs suppression” : synchroniser des produits supprimés est une source de corruption. Si votre besoin est d’éviter la suppression côté boutique tout en nettoyant le front, un mécanisme d’archivage est préférable : https://www.expertise-prestashop.fr/2026/06/18/module-prestashop-archive-products-archiver-produits-sans-suppression/

Stocks : PrestaShop peut être en stock simple ou “advanced stock management” (ASM), Dolibarr gère des entrepôts. Vous ne pouvez pas synchroniser correctement si vous n’avez pas un niveau de détail cohérent. Choisissez :

Stock maître = Dolibarr : PrestaShop ne fait que refléter (jobs pull fréquents).
Stock maître = PrestaShop : Dolibarr reçoit les mouvements au fil des commandes (push).

Évitez le bi-directionnel sur stock sans mécanisme de verrouillage et d’événements (sinon oscillations). Pour les catalogues et recherches internes, si vous avez aussi ElasticSearch, limitez les invalidations lors des synchros pour ne pas exploser le temps de réindex : https://www.expertise-prestashop.fr/2026/05/26/prestashop-elasticsearch-accelerer-la-recherche-produit-sur-grands-catalogues/

Commandes / factures : PrestaShop a orders, order_state, payments, livraisons partielles. Dolibarr a commandes, expéditions, factures, avoirs. Ne tentez pas de “mapper” 1:1 les statuts : mappez plutôt des événements (commande payée, commande expédiée, remboursement) et stockez un journal d’événements synchronisés. L’idempotence est critique : un retry réseau ne doit pas créer une deuxième facture Dolibarr.

Ajoutez ici un mini-scénario très réaliste : une PME française vend sur PrestaShop, expédie via Colissimo/Mondial Relay, et facture dans Dolibarr. La synchro la plus robuste est souvent :

PrestaShop pousse la commande + lignes + frais de port (en service) vers Dolibarr dès que le paiement est confirmé.
Dolibarr gère la facture et l’expédition (avec son propre workflow), puis renvoie éventuellement un statut d’expédition vers PrestaShop.

En toile de fond, si votre entreprise est concernée par la réforme de la facturation électronique en France, anticipez dès maintenant la cohérence “commande → facture → avoir”.

Paramètres de synchronisation : fréquence, incrémental, idempotence et nettoyage des données

La fréquence de synchro se décide sur une contrainte métier (stock quasi temps réel vs batch nocturne), mais se met en œuvre comme une contrainte technique : limite de charge, fenêtre de maintenance, volume XML. Sur un site moyen (10k–50k produits, 200–2000 commandes/jour), un pull catalogue complet quotidien est acceptable, mais un push de commandes doit être proche du temps réel si Dolibarr pilote la logistique. En pratique : commandes toutes les 1–5 minutes (cron), produits/stocks toutes les 15–60 minutes, catalogue complet en nocturne.

Pour éviter de “sur-synchroniser”, formalisez votre cadence (même simple) :

Commandes : incrémental très fréquent + retry court (impact business immédiat).
Stocks : fréquent si promesse de livraison, sinon plus lâche.
Catalogue (descriptions, SEO) : rarement critique côté ERP → à isoler, voire à exclure.

L’incrémental ne doit pas dépendre uniquement de date_upd : c’est fragile si vous avez des jobs qui “touchent” des lignes sans changement réel. Le pattern correct : checksum ou versioning + table de queue (même minimale). Une simple table ps_dolibarr_outbox avec status, retries, last_error, next_attempt_at vous évite 80% des synchronisations “bloquées” parce qu’une seule entité échoue.

Pour l’idempotence, cherchez un identifiant fonctionnel stable par opération. Exemple : “créer commande Dolibarr pour la commande PrestaShop #12345” doit être une opération rejouable sans effet de bord. En pratique, ça implique :

une contrainte dans votre mapping (“une commande PrestaShop ne peut pointer que vers un document Dolibarr”),
et une vérification avant création (si mapping déjà présent, on update ou on ignore).

Le nettoyage est le sujet que tout le monde reporte… et qui finit par tuer les perfs. Les tables de mapping grossissent, les logs s’empilent, et vous gardez des IDs orphelins (produits supprimés, clients anonymisés RGPD). Mettez une routine de maintenance (purge, vacuum logique, archivage) et versionnez-la.

Checklist de maintenance (mensuelle/trimestrielle selon volume) :

purge des logs applicatifs au-delà d’une rétention définie,
purge ou marquage des mappings orphelins (si l’objet source n’existe plus),
reconstruction/optimisation des index si nécessaire (en restant prudent),
contrôle d’intégrité (ex. commandes sans mapping, tiers dupliqués détectés).

Une base PrestaShop non maintenue devient un ralentisseur majeur pour les jobs batch : https://www.expertise-prestashop.fr/2026/04/30/base-de-donnees-prestashop-routine-de-maintenance-et-nettoyage-automatise/

Sécurité et observabilité : SOAP expose des surfaces d’attaque, traitez-le comme une API critique

Le SOAP Dolibarr est une API. Traitez-le comme tel : authentification forte, droits minimaux, journalisation, et segmentation réseau. Évitez d’exposer le WSDL publiquement. Si vous êtes contraint (hébergement mutualisé), compensez par un token à usage unique côté applicatif et une rotation régulière des secrets.

Ajoutez une règle simple côté exploitation : si PrestaShop est compromis, Dolibarr est en danger (puisque le connecteur détient des credentials ERP). Donc la sécurité n’est pas “un sujet Dolibarr” ou “un sujet PrestaShop” : c’est une chaîne.

Les checklists “sécurité PrestaShop” sont réutilisables : durcissez aussi la boutique qui héberge le client SOAP, sinon un attaquant pivotera via PrestaShop vers Dolibarr : https://www.expertise-prestashop.fr/2026/04/20/securite-prestashop-2026-risques-majeurs-et-protections-professionnelles/

Côté observabilité, exigez des logs structurés (JSON) avec : correlation id, objecttype, prestashopid, dolibarrid, durationms, payload_size, résultat. Sans ces champs, vous ne diagnostiquerz pas les “sync partielles” (le cas le plus coûteux). Agrégez dans Elastic/Kibana via Logstash si votre volume le justifie (lien plus haut). Sur des flux sensibles, ajoutez des alertes : taux d’erreur > X% sur 5 minutes, queue > N messages, durée moyenne > Y secondes.

Pensez aussi “données personnelles” : vos logs de synchro peuvent contenir des identifiants clients et, si vous n’êtes pas vigilant, des adresses complètes. Appliquez une logique de minimisation (ne loggez pas le payload complet) et de rétention (purge), surtout si plusieurs équipes ont accès à Kibana.

Enfin, appliquez une discipline de patching. Les connecteurs et modules de paiement sont une surface d’attaque récurrente ; une boutique compromise n’a plus aucune crédibilité comme “source de vérité”. Gardez l’habitude de suivre les CVE et de planifier les mises à jour : https://www.expertise-prestashop.fr/2026/06/04/cve-2025-61922-ps_checkout-mise-a-jour-5-0-5-et-mesures/

Recette technique : cas de test concrets et check-list de mise en production

Avant prod, montez un environnement de préproduction avec une copie anonymisée (clients) et un sous-ensemble réaliste du catalogue. Testez au minimum : création tiers, update tiers, création produit, update prix/TVA, création commande, reprise sur erreur. Le but n’est pas de “voir une commande remonter”, mais de vérifier que l’algorithme est idempotent (même événement rejoué → pas de duplication Dolibarr).

Ajoutez quelques tests “métier” qui révèlent vite les incohérences :

commande avec remise (code promo) → comment est représentée la remise dans Dolibarr (ligne négative, remise globale, etc.) ?
commande avec frais de port offerts → éviter de créer une ligne à 0 qui casse la compta analytique si vous l’utilisez
changement d’adresse après commande (cas SAV) → votre synchro doit-elle propager ou figer ?

Testez aussi des cas déplaisants :

Dolibarr down (timeout) pendant 30 minutes → la queue doit absorber et reprendre.
WSDL changé (après upgrade Dolibarr) → comportement du cache WSDL, rollback.
Produit déclinaison supprimée côté PrestaShop → traitement dans Dolibarr (désactivation vs suppression).

Simulez en charge : 1000 updates produits en batch, 100 commandes “en rafale”, et mesurez. Si votre job “catalogue” sature le CPU, vous avez probablement un problème de sérialisation XML ou de requêtes SQL non indexées. Si le job sature le réseau, compressez côté proxy et réduisez le champ synchronisé (ne poussez pas des descriptions HTML si Dolibarr n’en a pas l’usage).

Check-list de mise en production (courte, mais qui évite les retours arrière douloureux) :

secrets en place (compte technique Dolibarr, droits minimaux, rotation planifiée)
accès réseau restreint (WSDL non public, IP allowlist/VPN si possible)
cron installé + supervision (durée, code retour, alertes)
mode “read-only sync” activable rapidement
purge WSDL cache planifiée en cas de mise à jour Dolibarr

Dernier point, opérationnel : documentez la procédure de rollback. Une synchro qui pousse de mauvais prix ou de mauvais stocks peut coûter très cher très vite. Conservez (1) une sauvegarde BDD PrestaShop, (2) une sauvegarde Dolibarr, (3) un mode “read-only sync” (désactivation des écritures) activable rapidement. Et si vous devez modifier le module en continu, mettez-le sous CI (PHPStan, tests, qualité) : https://www.expertise-prestashop.fr/2026/05/18/phpstan-et-rector-industrialiser-la-qualite-du-code-php/