Webhook

Un webhook est un message qu'un logiciel envoie à un autre au moment précis où quelque chose se passe. Un client paie, un colis part, une personne s'inscrit à votre newsletter, et la première application prévient la seconde dans la foulée. Personne n'appuie sur un bouton, et la seconde application n'a pas besoin de demander sans arrêt s'il y a du nouveau.

Vous utilisez des webhooks sans le savoir. Ce sont eux qui font qu'un prestataire de paiement confirme une commande dans votre boutique en ligne, qu'un outil d'expédition renvoie un numéro de suivi, ou qu'un service d'automatisation copie chaque nouveau client dans un tableur. Si vous vendez en ligne, si vous choisissez des outils ou si vous payez un freelance pour les connecter, comprendre le principe vous aide à poser les bonnes questions et à trouver le maillon faible quand quelque chose casse.

Qu'est-ce qu'un webhook ?

Un webhook est une requête HTTP qu'une application envoie automatiquement vers une adresse web que vous lui indiquez, chaque fois qu'un événement choisi se produit. Cette adresse s'appelle l'endpoint, ou URL de rappel. La requête transporte un petit paquet de données, le plus souvent au format JSON, qui décrit l'événement : quelle commande, quel montant, quel client, à quelle heure.

L'image la plus parlante est celle de la boîte aux lettres et du SMS. Avec un appel API classique, votre application va voir l'autre et lui demande « quoi de neuf ? ». On appelle cela le polling. Avec un webhook, c'est l'autre application qui vient vers vous dès qu'il y a une nouvelle. Certains développeurs parlent d'ailleurs d'« API inversée ».

Un webhook n'est pas une API à lui seul. C'est un mode de communication que les API utilisent. La plupart des services qui envoient des webhooks proposent aussi une API classique, et une intégration solide combine les deux : le webhook annonce « la commande 4812 a été remboursée », puis votre application interroge l'API pour récupérer les détails fiables. Un webhook n'est pas non plus un e-mail ou une notification destinée à un humain. Il est fait pour être lu par une machine.

Le vocabulaire que vous croiserez dans les réglages des outils :

• Événement ou topic : ce qui déclenche l'envoi, par exemple order.paid ou customer.created.
• Payload : les données transportées par le message.
• Signature ou secret : un code qui prouve que le message vient bien de l'expéditeur annoncé.
• Retry : une nouvelle tentative d'envoi après un échec.
• Idempotence : la capacité à recevoir deux fois le même message sans faire deux fois le travail.

Les webhooks sont une brique de base de l'architecture événementielle, où les systèmes réagissent à des événements plutôt que de tourner à heure fixe.

Pourquoi c'est important

Les webhooks déterminent à quelle vitesse et avec quelle fiabilité vos outils restent d'accord entre eux. Quand ils fonctionnent, votre boutique, votre prestataire de paiement, votre outil d'e-mailing et votre entrepôt partagent la même réalité en quelques secondes. Quand ils tombent en panne sans bruit, vous vous retrouvez avec des commandes payées invisibles, des e-mails jamais partis et un stock faux.

Prenons une boutique qui traite 800 commandes par mois avec un panier moyen de 45 €. Une application de préparation externe reçoit les nouvelles commandes par webhook. Un vendredi soir, un développeur modifie un réglage serveur et l'endpoint cesse de répondre. Si personne ne s'en aperçoit pendant 48 heures, environ 53 commandes restent bloquées. Si un quart des clients écrivent au support et que 10 % demandent un remboursement, vous perdez environ 240 € de remboursements et plusieurs heures de support, sans compter les avis négatifs. Une simple alerte sur les envois échoués aurait détecté la panne en quelques minutes.

Les webhooks changent aussi le coût d'une intégration. Interroger une API toutes les minutes représente 43 200 requêtes par mois et par connexion, dont la grande majorité ne renvoie rien. Beaucoup de services limitent ou facturent les appels. Un freelance qui construit une intégration sur du polling peut épuiser un quota et ralentir tout le système. Un webhook, lui, envoie une requête par événement réel. Pour une créatrice qui réalise 150 ventes par mois, cela fait 150 messages au lieu de dizaines de milliers de vérifications à vide.

Comment ça marche

Le mécanisme reste le même, quels que soient les outils :

• Vous déclarez un endpoint. Dans l'application émettrice, vous ou votre développeur collez une URL qui appartient à l'application réceptrice, puis vous choisissez les événements à suivre.
• Un événement se produit. Un client valide son checkout, un remboursement est émis, un colis reçoit un numéro de suivi.
• L'émetteur prépare le payload. Il regroupe le type d'événement, un identifiant, un horodatage et les données utiles dans un message JSON.
• L'émetteur signe et envoie. Il ajoute une signature calculée avec un secret partagé, puis envoie une requête HTTP POST vers votre endpoint, en HTTPS.
• Le récepteur vérifie et répond vite. Il contrôle la signature, enregistre le message et renvoie un code de succès (un statut 2xx) en quelques secondes. Le traitement lourd se fait ensuite, en arrière-plan.
• L'émetteur réessaie en cas d'échec. S'il reçoit une erreur ou aucune réponse, il retente plus tard, souvent avec des délais croissants sur plusieurs heures ou jours. Après trop d'échecs, certains services désactivent l'endpoint.
• Le récepteur gère les doublons. Comme les nouvelles tentatives existent, un même événement peut arriver deux fois. Le récepteur s'appuie sur l'identifiant de l'événement pour ne créer l'expédition ou n'envoyer l'e-mail qu'une seule fois.

L'ordre d'arrivée n'est pas garanti non plus. Un message « commande modifiée » peut arriver avant « commande créée ». Un bon récepteur lit l'horodatage ou va chercher l'état actuel via l'API plutôt que de se fier à l'ordre de réception.

Repères et exemples

Il n'existe pas de note unique pour les webhooks, mais ces repères vous aident à juger un outil ou le travail d'un prestataire :

• Délai de livraison. La plupart des services livrent le message entre 1 et 10 secondes après l'événement. Plus d'une minute un jour normal signale un problème d'un côté ou de l'autre.
• Temps de réponse. Le récepteur doit répondre en moins de 5 à 10 secondes. Beaucoup d'émetteurs abandonnent au bout de 10 à 30 secondes et comptent un échec.
• Fenêtre de nouvelles tentatives. Les politiques courantes réessaient pendant 24 heures à 3 jours. Au-delà, il faut rejouer ou rapprocher les événements à la main.
• Taux d'échec. Une intégration saine échoue sur bien moins de 1 % des envois. Des échecs répétés au-dessus de quelques pour cent demandent une correction.

Des situations typiques :

• Une créatrice qui vend une formation utilise le webhook de son prestataire de paiement pour ajouter chaque acheteur à une communauté privée.
• Une petite marque envoie un webhook à son outil d'expédition à chaque commande payée, et l'outil lui en renvoie un avec le numéro de suivi, qui alimente les e-mails de suivi de commande.
• Un fondateur qui construit un MVP connecte un formulaire à un service d'automatisation qui publie chaque nouveau prospect dans la messagerie de l'équipe.

Erreurs fréquentes

• Ne pas vérifier la signature. Quiconque devine l'URL de votre endpoint peut envoyer de faux messages « commande payée ». Vérifiez toujours la signature avant d'agir.
• Faire le travail lent avant de répondre. Générer un PDF ou appeler trois autres services avant de répondre provoque des délais dépassés, des nouvelles tentatives et des doublons.
• Ignorer les doublons. Sans contrôle d'idempotence, une seule nouvelle tentative peut expédier deux colis ou envoyer deux factures.
• Aucune surveillance. Beaucoup d'équipes apprennent qu'un webhook est cassé par un client mécontent. Les envois échoués doivent déclencher une alerte.
• Faire du webhook la seule source de vérité. Des messages se perdent. Un rapprochement quotidien via l'API rattrape ce qui a glissé entre les mailles.

Bonnes pratiques

• Abonnez-vous seulement à ce que vous utilisez. Moins d'événements, c'est moins de bruit, moins de charge et moins de risques de panne.
• Vérifier, stocker, puis traiter. Contrôlez la signature, enregistrez l'événement brut, répondez succès, puis traitez-le dans une tâche de fond.
• Utilisez l'identifiant comme clé. Gardez la trace de chaque identifiant traité pour ignorer les doublons sans risque.
• Consultez le journal d'envoi. La plupart des émetteurs gardent l'historique des tentatives. Vérifiez-le après chaque changement de serveur et mettez des alertes sur les échecs.
• Prévoyez un rejeu. Assurez-vous que vous ou votre développeur pouvez renvoyer ou récupérer les événements après une panne.
• Protégez les secrets. Traitez le secret de signature comme un mot de passe, et changez-le quand un prestataire quitte le projet.
• Mettez-le par écrit. Quand vous confiez une intégration à un développeur, inscrivez la vérification de signature, les nouvelles tentatives, la gestion des doublons et la surveillance dans les critères d'acceptation.

Dans Roctify

Roctify ne propose pas de webhooks publics aujourd'hui. Pour la plupart des vendeurs, le manque est moins gênant qu'il n'y paraît, parce que les tâches qu'on relie habituellement avec des webhooks se passent déjà dans un seul système. Votre page lien en bio et votre vitrine partagent un catalogue unique, donc le stock, les commandes et les clients se mettent à jour partout en même temps. Les paiements via Stripe et PayPal confirment directement les commandes dans la boutique, et les produits digitaux et formations sont livrés automatiquement après paiement. L'e-mail marketing et les formulaires sont dans le même compte à partir de l'offre Creator, donc un nouvel acheteur n'a pas besoin d'être poussé vers un autre outil.

Quand vous comparez des plateformes, comptez combien d'outils externes il faudrait relier par webhooks, et qui entretiendrait ces raccords. Si votre activité demande des intégrations au-delà des fonctionnalités intégrées, par exemple un ERP ou un système d'entrepôt sur mesure, elles se discutent dans l'offre Enterprise.

FAQ

Un webhook, est-ce la même chose qu'une API ?

Non. Une API regroupe toutes les façons dont une application accepte qu'on lui parle, généralement sur demande. Un webhook est un mode précis où l'application vous envoie des données d'elle-même quand un événement se produit. La plupart des intégrations utilisent les deux : le webhook sert d'alarme, l'API sert de source de détails.

Faut-il un développeur pour utiliser des webhooks ?

Pas toujours. Des services d'automatisation permettent de recevoir des webhooks et de déclencher des actions sans code, ce qui suffit pour des flux simples comme « chaque nouveau prospect part dans un tableur ». Dès que l'argent, le stock ou l'expédition sont en jeu, un développeur qui gère signatures, nouvelles tentatives et doublons vaut son prix.

Que se passe-t-il si mon endpoint est hors service ?

L'émetteur réessaie généralement pendant une période qui va de quelques heures à quelques jours. Si votre endpoint revient à temps, les événements arrivent en retard mais ils arrivent. Sinon, ils sont perdus et il faut les rejouer ou comparer les données via l'API pour combler le trou.