Un webhook renverse la question. Au lieu d'aller demander toutes les cinq minutes s'il y a du nouveau, vous laissez une adresse et le service vous écrit au moment où ça arrive.
C'est le mécanisme qui rend possible la plupart des automatisations qui réagissent en temps réel, et c'est aussi le plus mal compris de la mécanique : beaucoup de gens le rangent dans le rayon technique alors que c'est d'abord une décision d'architecture et de coût.
Définition
Un webhook est une notification envoyée automatiquement par un service vers une adresse que vous lui avez fournie, au moment précis où un événement se produit.
Techniquement, c'est un appel API inversé. D'habitude, c'est vous qui appelez le service. Ici, c'est le service qui vous appelle. D'où le nom parfois employé de « rappel HTTP ».
La comparaison la plus parlante est celle du colis. Le sondage, c'est aller vérifier votre boîte aux lettres toutes les dix minutes. Le webhook, c'est la notification qui vous prévient quand le facteur est passé. Même résultat, mais l'un vous mobilise en permanence et l'autre pas.
Ce que ça change concrètement
| Sondage | Webhook | |
|---|---|---|
| Appels par mois | Des milliers | Un par événement réel |
| Délai de réaction | Jusqu'à l'intervalle choisi | Immédiat |
| Mise en place | Quelques clics | Une adresse à déclarer |
| Si votre outil est indisponible | Rattrapé au passage suivant | Perdu, sauf rejeu par l'émetteur |
La dernière ligne est le seul vrai inconvénient, et il se traite. Les services sérieux réessaient plusieurs fois en cas d'échec, souvent pendant plusieurs heures. Vérifiez ce comportement dans leur documentation avant de bâtir dessus.
Les trois points de vigilance
L'adresse est une porte ouverte
Votre adresse de réception accepte des messages venus de l'extérieur. Si elle circule, n'importe qui peut vous envoyer de faux événements. La plupart des services proposent une signature à vérifier : c'est le premier réglage à faire, pas une option.
Le même événement peut arriver deux fois
C'est la conséquence directe du rejeu. Si votre traitement crée une facture, recevoir deux fois le même événement en crée deux. Votre Workflow doit reconnaître un événement déjà traité et l'ignorer.
Il faut répondre vite
L'émetteur attend une réponse en quelques secondes, sinon il considère l'envoi comme échoué. Si votre traitement est long, répondez immédiatement puis travaillez ensuite, plutôt que de faire patienter.
Ne mettez jamais d'information sensible dans l'adresse elle-même. Elle apparaît dans les journaux de nombreux systèmes. Le secret partagé et la signature se placent dans les en-têtes du message, jamais dans l'URL.
Tester un webhook avant de bâtir dessus
La méthode qui fait gagner le plus de temps consiste à regarder ce qui arrive réellement avant d'écrire la moindre étape. Les données reçues ne ressemblent presque jamais à ce qu'on imagine à la lecture de la documentation.
Déclarez l'adresse et ne faites rien d'autre. Votre outil d'automatisation fournit une adresse de test qui affiche les messages entrants tels quels.
Provoquez l'événement pour de vrai. Passez une commande de test, remplissez le formulaire vous-même. Les fonctions « envoyer un événement d'exemple » proposées par certains services envoient des données idéalisées qui n'ont pas la forme des vraies.
Lisez ce qui arrive. Notez les champs réellement présents, ceux qui sont vides, ceux qui portent un autre nom que prévu. C'est à partir de cette structure que vous construisez, pas à partir de la documentation.
Provoquez le cas particulier. Une commande sans adresse, un client sans nom, un montant à zéro. C'est là que vous découvrirez les champs absents qui feront échouer votre Workflow dans trois semaines.
Vérifiez le rejeu. Coupez votre outil, déclenchez l'événement, rallumez. Si le message arrive avec du retard, le service rejoue et vous êtes protégé. S'il ne vient jamais, il faudra prévoir un rattrapage périodique.
Questions fréquentes
Faut-il un serveur pour en recevoir un ?
Non. Les outils d'automatisation vous fournissent une adresse toute faite. Vous la copiez dans le service émetteur, et le Déclencheur est en place en deux minutes.
Comment tester avant de mettre en service ?
La plupart des outils affichent les messages reçus en direct. Déclenchez une fois l'événement pour de vrai, regardez ce qui arrive, et construisez la suite à partir des données réellement reçues plutôt que de celles que vous imaginez.
Quelle différence avec le MCP ?
Un webhook prévient d'un événement. Le MCP permet à un modèle d'utiliser des outils. Le premier est un signal entrant, le second un moyen d'agir. Ils se complètent plus qu'ils ne se ressemblent.
Comment mettre le premier en place ?
En partant d'un service que vous utilisez déjà et qui en propose, un outil de paiement ou de formulaire par exemple. Notre formation n8n montre ce branchement du début à la fin, signature de sécurité comprise.