Si vous avez commencé à vous intéresser à l'automatisation, aux intégrations entre outils, ou si vous avez déjà configuré un workflow dans Make ou n8n, vous avez probablement croisé le terme "webhook". Il revient régulièrement dans les documentations techniques, dans les paramètres des outils SaaS, et dans les conversations avec des développeurs. Et il est rarement bien expliqué.
Un webhook n'est pas un outil en soi. C'est un mécanisme de communication entre applications. Comprendre comment il fonctionne permet de mieux utiliser les outils d'automatisation, de mieux dialoguer avec des prestataires techniques, et de comprendre pourquoi certaines intégrations fonctionnent en temps réel alors que d'autres ont un délai.
L'analogie qui clarifie tout
Avant la définition technique, une analogie.
Imaginez que vous attendez un colis. Deux façons de savoir s'il est arrivé. La première : vous appelez le service de livraison toutes les heures pour demander si le colis est là. C'est fastidieux, souvent inutile, et vous monopolisez une ligne téléphonique pour rien. La deuxième : vous donnez votre numéro au livreur, et il vous appelle uniquement quand le colis est livré. Vous n'attendez rien activement, vous êtes notifié au moment précis où ça arrive.
Un webhook fonctionne exactement comme la deuxième option. Plutôt qu'une application qui interroge régulièrement une autre pour savoir si quelque chose a changé (ce qu'on appelle le polling), le webhook envoie une notification automatique au moment précis où l'événement se produit. Pas avant, pas après.
La définition technique, accessible
Un webhook est une URL que vous fournissez à un service, et sur laquelle ce service envoie automatiquement des données dès qu'un événement précis se produit.
Concrètement : vous avez une boutique Shopify. Vous configurez un webhook dans Shopify en lui indiquant une URL et un événement ("nouvelle commande"). Dès qu'une commande est passée, Shopify envoie automatiquement les données de cette commande (client, produits, montant, adresse) à votre URL. L'application ou le service qui écoute cette URL reçoit les données et peut agir en conséquence : créer une ligne dans un tableur, notifier votre équipe sur Slack, créer une expédition dans votre outil logistique.
L'URL qui reçoit les données s'appelle l'endpoint webhook. Elle est générée par l'outil qui va recevoir et traiter les données (Make, n8n, votre propre serveur). L'outil qui envoie les données (Shopify, Stripe, votre CRM) est appelé le producteur du webhook.
Webhook vs API : la différence essentielle
Les deux termes reviennent souvent ensemble, et la confusion est fréquente. Ce sont deux façons différentes pour des applications de communiquer.
Une API (Application Programming Interface) fonctionne à la demande. Votre application fait une requête à l'API d'un service pour obtenir des données ou déclencher une action. Vous posez une question, vous obtenez une réponse. C'est vous qui initiez la communication, quand vous le décidez.
Un webhook fonctionne en mode push. C'est le service qui vous envoie les données, sans que vous ayez à les demander, dès que l'événement se produit. C'est le service qui initie la communication.
En pratique, les deux sont complémentaires. Vous utilisez une API quand vous avez besoin d'interroger un service à la demande (récupérer le statut d'une commande spécifique, chercher un contact dans un CRM). Vous utilisez un webhook quand vous voulez être notifié en temps réel d'un événement sans avoir à demander en permanence (une nouvelle commande, un paiement reçu, un formulaire soumis).
Le polling (interroger régulièrement une API pour détecter des changements) est la solution de substitution quand un webhook n'est pas disponible. C'est moins efficace : ça génère des requêtes inutiles, ça introduit un délai, et ça consomme des ressources des deux côtés.
Des cas d'usage concrets
E-commerce : déclencher des actions à chaque commande
C'est probablement le cas d'usage le plus courant. Shopify, WooCommerce, et la plupart des plateformes e-commerce proposent des webhooks sur des événements clés : nouvelle commande, commande annulée, paiement reçu, remboursement effectué, nouveau client créé.
Un webhook sur "nouvelle commande" peut simultanément notifier votre entrepôt, créer une ligne dans votre tableau de suivi des expéditions, ajouter le client à votre liste d'emailing, et notifier votre commercial si la commande dépasse un certain montant. Tout ça en quelques secondes, automatiquement, sans intervention manuelle.
Paiements : confirmer et agir en temps réel
Stripe, le processeur de paiement, est connu pour la qualité de ses webhooks. Dès qu'un paiement est confirmé, un abonnement activé, ou une facture payée, Stripe envoie un webhook à l'URL que vous avez configurée. C'est ce mécanisme qui permet à des services en ligne d'activer un accès immédiatement après le paiement, sans délai ni vérification manuelle.
Sans webhook, la confirmation de paiement nécessiterait soit une vérification manuelle, soit un polling régulier de l'API Stripe. Avec le webhook, la confirmation est reçue en temps réel et les actions qui en dépendent (activation de compte, envoi de facture, notification interne) se déclenchent immédiatement.
Formulaires : traiter les soumissions instantanément
Des outils comme Tally, Typeform ou les formulaires natifs Webflow peuvent envoyer un webhook à chaque nouvelle soumission. Les données du formulaire (nom, email, message, réponses aux questions) arrivent immédiatement dans votre outil de traitement, sans délai et sans avoir à consulter une interface pour voir les nouvelles réponses.
Un webhook sur un formulaire de contact peut créer automatiquement un lead dans votre CRM, envoyer une notification à votre équipe, déclencher un email de confirmation au prospect, et ajouter la personne à une séquence d'emailing. Le tout sans que personne n'ait à surveiller une boîte mail ou un tableau de bord.
Monitoring : être alerté quand quelque chose se passe
Des outils de surveillance (disponibilité de site, alertes de sécurité, dépassement de seuil) utilisent les webhooks pour envoyer des alertes en temps réel vers Slack, Teams, ou un email. Plutôt que de vérifier manuellement un tableau de bord, vous êtes notifié au moment précis où l'événement se produit.
Comment configurer un webhook dans Make ou n8n
Pour quelqu'un qui utilise Make ou n8n pour ses automatisations, les webhooks sont souvent le point d'entrée des workflows les plus utiles.
Dans Make. Créez un nouveau scénario. Ajoutez un module "Webhooks" en premier, choisissez "Custom webhook", et Make génère une URL unique. Copiez cette URL, collez-la dans l'outil source (Shopify, Stripe, Tally, etc.) en lui indiquant l'événement à surveiller. Dès que l'événement se produit, Make reçoit les données et les passe aux modules suivants du scénario.
Dans n8n. Ajoutez un nœud "Webhook" en point de départ du workflow. n8n génère une URL d'écoute. Configurez l'outil source pour envoyer ses données à cette URL sur l'événement choisi. Quand les données arrivent, le workflow se déclenche automatiquement.
Dans les deux cas, la première réception de données est souvent nécessaire pour que l'outil reconnaisse la structure des données et propose les champs disponibles pour les étapes suivantes. On appelle ça "écouter" le webhook : vous déclenchez manuellement un événement test dans l'outil source pendant que Make ou n8n est en attente, et l'outil enregistre la structure reçue.
Ce qu'il faut savoir sur la fiabilité des webhooks
Les webhooks ne sont pas infaillibles, et c'est utile de le savoir avant de construire des processus critiques dessus.
Les webhooks peuvent échouer. Si l'URL de destination est temporairement indisponible au moment où le webhook est envoyé, la donnée peut être perdue. La plupart des services sérieux (Shopify, Stripe) ont des mécanismes de retry : ils réessaient l'envoi plusieurs fois sur une période donnée si la première tentative échoue. Mais ce n'est pas universel.
L'ordre d'arrivée n'est pas garanti. Dans des systèmes à fort volume, plusieurs webhooks envoyés en succession rapide peuvent arriver dans un ordre différent de celui de leur émission. Si votre workflow dépend d'un ordre précis d'événements, il faut le concevoir en conséquence.
La sécurité des webhooks. Une URL de webhook est publique : n'importe qui qui connaît l'URL peut théoriquement y envoyer des données. Les services sérieux signent leurs webhooks avec un secret partagé (une clé que seul le service émetteur connaît) que vous pouvez vérifier à la réception pour vous assurer que les données viennent bien de la bonne source. Make et n8n permettent de configurer cette vérification.
Quand utiliser un webhook plutôt qu'une intégration native
Beaucoup d'outils d'automatisation proposent des intégrations natives avec les services populaires : un module Shopify dans Make, un nœud Stripe dans n8n. Ces intégrations utilisent souvent des webhooks en arrière-plan, mais vous évitent de les configurer manuellement.
Le webhook direct est utile quand une intégration native n'existe pas pour l'outil que vous utilisez, quand vous avez besoin d'un contrôle plus fin sur les données reçues ou les événements déclencheurs, ou quand vous connectez un outil développé sur mesure qui doit communiquer avec votre écosystème d'automatisation.
Pour les outils courants (Shopify, Stripe, Typeform, HubSpot, Airtable), commencez par vérifier si une intégration native existe dans Make ou n8n avant de configurer un webhook manuel : c'est souvent plus simple et mieux documenté.
Ce qu'on retient
Un webhook est un mécanisme de notification en temps réel : un service envoie automatiquement des données à une URL que vous avez configurée dès qu'un événement précis se produit. C'est plus efficace que le polling, plus réactif qu'une vérification manuelle, et c'est la base de la plupart des automatisations temps réel entre outils.
Dans la pratique pour une PME : les webhooks Shopify pour déclencher des actions à chaque commande, les webhooks Stripe pour agir dès qu'un paiement est confirmé, les webhooks de formulaires pour traiter les soumissions instantanément. Tous configurables dans Make ou n8n sans développement, en quelques minutes une fois le principe compris.
Ce qu'il faut garder en tête : les webhooks peuvent échouer, leur ordre d'arrivée n'est pas garanti, et leur sécurité mérite attention pour les processus sensibles.
Voir aussi :
