Une réservation qui ne remonte pas dans le CRM, un dossier créé deux fois, une relance envoyée après un règlement : ces incidents peuvent venir d'une automatisation mal préparée aux imprévus. En 2026, connecter WordPress, un outil de réservation et un logiciel métier ne suffit pas. Pour une PME à Nice ou Cannes, la bonne question est aussi : que se passe-t-il lorsque la connexion échoue ?

Un webhook, c'est une notification entre logiciels

Un webhook permet à un service de prévenir un autre logiciel lorsqu'un événement survient. Par exemple, une plateforme de paiement signale un règlement à votre CRM, qui actualise le dossier client. Cette notification arrive généralement à une adresse web prévue pour la recevoir.

Le mécanisme paraît simple. Mais il faut distinguer l'événement, sa livraison et l'action qu'il déclenche. Recevoir une notification ne signifie pas que toute la chaîne a terminé son travail.

Accuser réception sans perdre le travail à effectuer

Selon le service, une absence de réponse ou une erreur peut provoquer une nouvelle livraison. Les délais et les possibilités de reprise varient : aucun comportement ne doit être supposé universel.

Demandez à votre prestataire de séparer la réception des opérations longues. Pour une notification valide à traiter, le système devrait d'abord l'enregistrer durablement, puis confirmer sa réception selon les règles du fournisseur. Une file d'attente peut ensuite organiser le travail en arrière-plan. GitHub recommande notamment le traitement asynchrone pour répondre rapidement.

Cette confirmation n'atteste pas que le CRM a été mis à jour. Si cette étape échoue, votre système doit conserver la tâche et prévoir sa reprise. Répondre immédiatement sans avoir sécurisé son enregistrement risque de faire disparaître le travail après une panne.

Empêcher une notification répétée de créer un doublon

Shopify documente l'utilisation d'un identifiant de livraison pour détecter les notifications répétées. Dans votre intégration, choisissez l'identifiant adapté au fournisseur et conservez son état : reçu, en cours, terminé ou en erreur.

Ne marquez pas une action comme terminée dès son arrivée. Si le traitement s'interrompt ensuite, la prochaine tentative pourrait être ignorée alors que rien n'a abouti. Demandez aussi une protection contre deux traitements simultanés du même événement.

Le résultat attendu porte un nom technique : l'idempotence. Répéter la même opération doit produire le même résultat métier. Une réservation déjà enregistrée actualise ainsi le dossier existant au lieu d'en créer un second. Cette protection doit aussi couvrir les actions externes, comme l'envoi d'un message. Lorsque l'API destinataire accepte une clé d'idempotence, utilisez-la selon sa documentation ; sinon, prévoyez un contrôle de résultat avant de relancer une action incertaine.

Gérer les retards et retrouver les données manquantes

Stripe ne garantit pas l'ordre de livraison des événements. Une notification ancienne ne doit donc pas écraser aveuglément un état plus récent dans votre CRM. Selon l'API, vérifiez la version de la donnée ou consultez son état actuel avant une modification sensible.

Shopify recommande également une vérification périodique par API pour rapprocher les données des deux systèmes. Adaptez sa fréquence à votre activité et aux limites du service. Par exemple, comparez les réservations confirmées avec les dossiers présents dans le CRM, puis examinez les écarts avant de les corriger.

Les contrôles à demander avant la mise en service

Faites tester une coupure et une reprise, pas seulement une transmission réussie :

  • Renvoyer le même événement sans créer de nouveau dossier.
  • Simuler une indisponibilité du CRM, puis vérifier la reprise.
  • Recevoir un événement ancien après un événement récent.
  • Déclencher une alerte lorsqu'une tâche reste bloquée.
  • Vérifier l'authenticité des notifications selon le mécanisme du fournisseur, notamment sa signature lorsqu'elle est disponible.

La documentation GitHub explique par exemple comment vérifier une signature avec un secret partagé. Les journaux devraient permettre de retrouver l'identifiant, l'heure, le résultat et l'erreur éventuelle, sans recopier inutilement les données des clients.

Dimensionner la fiabilité selon votre activité

Un indépendant à Monaco et une entreprise de réservation dans les Alpes-Maritimes n'ont pas les mêmes contraintes. Commencez par le flux dont l'échec coûte le plus cher. NIKAIA.NET peut vous accompagner pour concevoir des intégrations PHP, WordPress et CRM avec des règles de reprise explicites et des incidents visibles.

Points à vérifier avant publication

Relire les politiques actuelles de livraison et de reprise des fournisseurs, les identifiants disponibles, les mécanismes de signature, la prise en charge des clés d'idempotence et les limites API. Vérifier que les exemples correspondent aux connecteurs réellement utilisés.