Webhooks : connecter deux outils sans perdre les événements

Un webhook permet à un service web de prévenir un autre outil lorsqu’un événement se produit. Une commande est validée, un ticket est créé ou un document est signé : au lieu d’interroger régulièrement la première application, le flux de travail reçoit une notification et peut déclencher une action. Cette mécanique est utile pour relier des services qui ne proposent pas de connecteur prêt à l’emploi. Elle demande toutefois quelques précautions : un événement peut être envoyé plusieurs fois, arriver avec retard ou ne jamais atteindre sa destination.

Commencez par définir précisément le cas d’usage. Par exemple, lorsqu’une commande passe au statut « confirmée », votre boutique en ligne peut envoyer un événement à un outil de gestion de tâches pour créer une tâche de préparation. Notez le déclencheur, les informations nécessaires et l’action attendue. Limitez les données transmises à ce qui est utile : l’identifiant de commande, son statut et, si nécessaire, une référence client. Évitez d’envoyer des données personnelles ou des détails de paiement si le processus n’en a pas besoin. Cette étape facilite aussi le choix du connecteur ou du service intermédiaire.

Configurez ensuite une URL de réception dédiée, généralement fournie par l’outil qui doit recevoir l’événement. Dans l’application émettrice, sélectionnez les événements à transmettre et indiquez cette adresse. Pour vérifier le fonctionnement, utilisez un environnement de test ou un événement fictif, si le service le permet. Examinez la requête reçue : elle contient souvent un type d’événement et un ensemble de données au format JSON. Vérifiez que le statut attendu est bien présent et que l’outil destinataire sait l’interpréter. Si une étape de transformation est nécessaire, gardez-la explicite : par exemple, convertir « confirmed » en « à préparer » plutôt que de laisser cette correspondance implicite.

Prévoyez le cas où la notification échoue. Le service destinataire peut être temporairement indisponible, répondre trop lentement ou refuser une donnée inattendue. Consultez la documentation des deux outils pour connaître leur comportement en cas d’erreur : certains renvoient automatiquement l’événement, d’autres le marquent comme échoué sans nouvelle tentative. Quand les envois répétés sont possibles, rendez l’action idempotente : avant de créer une tâche, recherchez si une tâche portant déjà l’identifiant de la commande existe. Cela évite les doublons si la même notification est reçue plusieurs fois. Si vous gérez le point de réception vous-même, consignez le résultat et renvoyez rapidement une réponse au service émetteur.

Les journaux d’exécution servent à diagnostiquer les incidents, mais ils peuvent contenir des informations sensibles. Limitez les droits d’accès à ces journaux, masquez les données inutiles et définissez une durée de conservation adaptée à votre activité. Protégez également l’adresse de réception : si le service propose une signature ou un jeton d’authentification, activez-le et stockez le secret dans un gestionnaire prévu à cet effet plutôt que dans un document partagé. Testez régulièrement le flux avec un événement contrôlé et vérifiez que les erreurs sont visibles par la personne chargée de les traiter. Une alerte sur les échecs persistants est plus utile qu’une surveillance permanente de chaque événement réussi.

Enfin, prévoyez une solution de repli. Si la synchronisation s’interrompt, les commandes doivent rester consultables dans l’outil d’origine et une personne doit pouvoir relancer le traitement sans créer de doublon. Documentez le déclencheur, les données transmises, les droits nécessaires et la procédure de reprise. Un webhook fiable ne repose pas seulement sur une connexion qui fonctionne lors du premier essai : il s’appuie sur des événements vérifiables, un traitement tolérant aux répétitions et une reprise clairement définie.