# Ma synchronisation avec un outil externe s’est arrêtée

> Une liaison entre deux systèmes ne tombe presque jamais sans raison, et presque jamais des deux côtés à la fois. Elle tombe parce qu’une autorisation a expiré, parce qu’un format a changé, ou parce qu’une limite d’appels a été atteinte. Dans les trois cas, le refus est explicite quelque part — il faut simplement savoir où regarder.

- Source canonique : [https://allaux.fr/problemes/synchronisation-avec-un-outil-externe-interrompue](https://allaux.fr/problemes/synchronisation-avec-un-outil-externe-interrompue)
- Langue : FR
- Dernière mise à jour : 2026-08-03

## Réponse directe

> Cherchez le code de refus renvoyé par l’autre système : 401 pour une clé expirée, 403 pour une permission retirée, 429 pour une limite d’appels atteinte. Les échanges sont tracés dans WooCommerce > État > Journaux côté WordPress et dans var/logs/ côté PrestaShop. Vérifiez ensuite que la clé est toujours active : Paramètres avancés > Webservice, ou WooCommerce > Réglages > Avancé > API REST.

## Dans quel sens la liaison est-elle cassée

- Le site n’envoie plus rien : le problème est dans le déclenchement, côté boutique.
- Le site envoie mais l’autre système refuse : la réponse contient un code et un message qui nomment la cause.
- L’autre système envoie mais le site ne traite rien : l’adresse de réception a changé, ou elle est protégée par une règle qui bloque l’appel.
- Les données circulent mais sont fausses : ce n’est pas une panne de liaison, c’est une correspondance de champs devenue inexacte.

## Les quatre causes que je rencontre le plus

L’autorisation a expiré. Beaucoup de services délivrent des jetons d’accès valables un temps limité, ou révoquent une clé lorsqu’un mot de passe change. La liaison fonctionne pendant des mois, puis s’arrête un matin sans que rien n’ait été modifié chez vous.

L’autre service a changé de version. Un champ renommé, un format de date modifié, un champ devenu obligatoire : l’appel est refusé alors que le code n’a pas bougé. Ces changements sont annoncés à l’avance par courriel, à une adresse que plus personne ne relève.

La limite d’appels est atteinte. Les services imposent un nombre maximal d’appels par minute ou par jour. Une synchronisation qui traite produit par produit atteint cette limite dès que le catalogue grossit, et les appels suivants sont rejetés.

Le certificat ou l’adresse a changé. Un site passé en HTTPS, un domaine modifié, un certificat expiré : l’autre système ne parvient plus à joindre l’adresse enregistrée chez lui.

## Retrouver le message de refus

1. **Chercher le journal côté site** — Une intégration correctement écrite enregistre chaque appel et chaque réponse. Si ce journal n’existe pas, c’est la première chose à ajouter, avant même de chercher la cause.
2. **Chercher le journal côté service** — La plupart des plateformes exposent un historique des appels reçus, avec le code de réponse. Si vos appels n’y figurent pas, ils ne partent pas.
3. **Rejouer un appel isolé** — Un seul produit, une seule commande. La réponse obtenue est bien plus lisible qu’un traitement de masse qui échoue sur une ligne inconnue.
4. **Vérifier la date d’expiration des accès** — Jeton, clé, mot de passe applicatif, certificat client : chacun a une échéance, et aucune n’est rappelée automatiquement.
5. **Vérifier ce qui a changé chez l’autre** — Note de version, changement d’offre, migration annoncée. Une liaison qui tombe sans cause côté boutique a presque toujours une cause côté partenaire.

## Une synchronisation qui reprend après une coupure peut tout écraser

> Si les deux systèmes ont été modifiés pendant l’interruption, la reprise doit décider quelle version fait foi. Sans cette règle, la synchronisation écrase les modifications les plus récentes par des données périmées. C’est la vraie difficulté du redémarrage, bien plus que le rétablissement de la liaison.

## Continuer sur la bonne page

- **Intégrations et API** — Comment je construis une liaison qui signale ses échecs au lieu de les taire. ([/services/integrations-api](/services/integrations-api))
- **Connecter un ERP ou un fournisseur** — Le cas PrestaShop, avec le service web et ses limites. ([/prestashop/problemes/connecter-erp-fournisseur-api](/prestashop/problemes/connecter-erp-fournisseur-api))
- **L’API REST expliquée** — Comment deux systèmes se parlent, et ce que signifie chaque code de réponse. ([/glossaire/api-rest](/glossaire/api-rest))
- **Le webhook expliqué** — Quand c’est l’autre service qui appelle votre site, et pourquoi l’appel peut échouer. ([/glossaire/webhook](/glossaire/webhook))

## FAQ

### Le prestataire dit que le problème vient de mon site, comment le vérifier ?

En demandant à voir ses journaux d’appels reçus. Si vos appels y figurent avec un code de refus, la cause est nommée noir sur blanc. S’ils n’y figurent pas, la démonstration est faite dans l’autre sens.

### Faut-il tout resynchroniser après une interruption ?

Rarement en totalité. Rejouer uniquement la période manquante est plus rapide et beaucoup moins risqué, à condition que les enregistrements portent une date de modification exploitable.

### Une synchronisation en temps réel est-elle préférable à une synchronisation planifiée ?

Pas toujours. Le temps réel expose à chaque indisponibilité de l’autre système ; une exécution planifiée avec reprise sur erreur est souvent plus robuste pour un flux de stock ou de prix.

### Pourquoi la liaison marche pour certains produits et pas pour d’autres ?

Parce que ces produits contiennent une valeur que l’autre système refuse : un champ vide devenu obligatoire, un caractère non accepté, une catégorie inconnue de son côté. Le point commun entre les produits en échec est la piste.

### Puis-je surveiller la liaison sans outil payant ?

Oui : un compteur du nombre d’éléments synchronisés par jour, comparé à la veille, suffit à détecter un arrêt. C’est simple à mettre en place et cela évite de découvrir la panne une semaine trop tard.