Webhook : c'est quoi, et comment ça se branche
Un moyen pour une application de prévenir une autre au moment où quelque chose se passe. Voilà comment ça fonctionne — et surtout ce qui décide si ça se branche chez vous ou pas.
L'essentiel, si vous ne lisez qu'un paragraphe
- Un signal, pas un traitement. Le webhook prévient au moment où l'événement se produit ; il ne fait rien tout seul. Ce qui compte, c'est ce qui le reçoit et ce qu'on lui fait faire ensuite.
- Instantané, au lieu d'être interrogé. Sans webhook, votre outil demande « est-ce qu'il y a du nouveau ? » à intervalle régulier. Avec, c'est l'autre qui parle — délai en secondes, et rien de consommé quand il ne se passe rien.
- Ce qui tranche, ce n'est presque jamais la technique. C'est le niveau d'abonnement que vous payez, et la façon dont l'éditeur protège l'accès. Ça se vérifie avant de commencer.
Un webhook, en une phrase
Un webhook, c'est une application qui prévient une autre application à l'instant où un événement se produit.
La première envoie un message à une adresse que vous lui avez donnée ; la seconde n'a rien à demander, elle reçoit.
Un webhook ne fait rien tout seul : c'est un signal, pas un traitement. Ce qui compte, c'est ce qui le reçoit et ce qu'on lui fait faire ensuite.
Vos deux outils entrent dans l'une de ces trois pièces ? Décrivez-les dans l'audit de faisabilité — gratuit, réponse sous 48-72 h ouvrées.
Ce que ça change face à une API qu'on interroge
Dans les deux cas, deux outils se parlent. La différence est dans le sens de l'initiative.
Ce n'est pas une question de mode : c'est ce qui décide si une automatisation est instantanée ou en retard, et si elle tient dans le plan tarifaire que vous payez déjà. Un webhook mal authentifié, en revanche, est une porte ouverte sur vos données — c'est le premier point de la section suivante.
Vous ne savez pas si votre outil sait prévenir, ou seulement répondre ? C'est exactement la question de l'audit.
À quoi ça sert dans une entreprise
Le webhook est presque toujours la première brique d'une intégration, parce qu'il déclenche le reste.
Quelques exemples courants :
-
Un formulaire rempli
La fiche se crée dans le CRM ou le tableur, et la personne reçoit une réponse immédiate.
-
Un paiement encaissé
La facture se rapproche du règlement, sans que quelqu'un aille comparer deux relevés.
-
Une signature posée
Le dossier passe à l'étape suivante et l'équipe est prévenue.
-
Un devis accepté
Le projet se crée, et la relance s'arrête d'elle-même.
Dans tous ces cas, le webhook est le point de départ ; le reste est du branchement entre outils, ce que je détaille sur la page des outils. Les mêmes mécanismes servent aussi à relier Airtable, un Google Sheet, un outil d'automatisation comme n8n, ou votre logiciel métier.
L'un de ces quatre cas ressemble au vôtre ? Dites-moi lequel, et avec quels outils.
Ce qui fait échouer un webhook
Quatre fois sur cinq, la difficulté n'est pas d'écrire l'automatisation : elle est dans ces cinq points, et ils se découvrent avant de commencer — pas en cours de route.
-
L'authentification Qui a le droit d'envoyer le message ? Un webhook sans clé ni signature est un webhook que n'importe qui peut appeler. Il faut un secret partagé, une signature à vérifier, ou une origine autorisée.
-
Le plan tarifaire C'est le cas le plus fréquent, et le plus vexant : l'interface de connexion existe, la documentation est publique, mais elle est réservée à un abonnement supérieur. Aucun contournement n'est propre — autant le savoir avant d'acheter quoi que ce soit.
-
Les données manquantes Le message dit qu'un événement a eu lieu, mais ne transporte pas le champ dont vous avez besoin. Il faut alors rappeler l'outil pour compléter, et ce deuxième appel a lui aussi ses limites.
-
Le rejeu Si la réception échoue — une coupure, un service indisponible —, le message est-il renvoyé plus tard, ou perdu ? Sans file d'attente ni rejeu, une panne d'une minute peut laisser un trou dans vos données.
-
Les environnements Une adresse de test qui se retrouve en production, ou l'inverse : c'est la panne classique des intégrations qui n'avaient jamais été documentées.
Rien de tout cela n'est grave. Mais chacun de ces points peut transformer une connexion « évidente » en projet beaucoup plus lourd — et c'est exactement ce qu'un audit doit sortir avant la première ligne de travail.
Ces cinq points, l'audit les vérifie un par un. Évitez-les avant d'acheter quoi que ce soit.
Ce que l'audit regarde, point par point
La réponse dépend de vos outils, pas de la théorie.
L'audit de faisabilité examine cinq choses. Vous recevez le schéma du flux, les prérequis et une estimation. C'est gratuit, et ça ne vous engage à rien — le formulaire est juste en dessous : décrivez vos deux outils et ce qui se passe à la main aujourd'hui, et je vous réponds sous 48-72 h ouvrées.
Ce qu'on me demande sur ce genre de branchement
Non. Il y a trois chemins possibles, dans cet ordre : le connecteur prévu par l'éditeur, l'interface de connexion (une API) qu'on décide d'interroger, et — si le logiciel n'expose vraiment rien — l'automatisation qui pilote son interface comme le ferait une personne. Le troisième est plus fragile, mais il évite de changer de logiciel. Lequel s'applique chez vous se tranche pendant l'audit.
Ça dépend entièrement de la façon dont il est protégé. Une adresse de webhook sans clé ni signature est ouverte à qui la connaît : c'est une porte d'entrée sur vos données. Avec un secret partagé, une signature à vérifier et une origine autorisée, c'est un canal fermé. C'est le premier point que l'audit regarde — et si la protection n'est pas possible côté éditeur, je vous le dis avant de commencer.
Non. Ce qui est branché vit soit directement dans vos outils actuels, soit sur un compte d'automatisation à votre nom (n8n, Make, Power Automate). Rien à installer sur les postes, rien à apprendre : c'est mon travail, pas le vôtre.
Non, et ce n'est pas le but. Je ne vends aucun logiciel et je ne vous fais pas prendre un abonnement de plus : je relie ceux que vous avez déjà. Si un outil est réellement un obstacle, je vous le dirai — mais c'est rarement la conclusion de l'audit.
Rien ne dépend de moi pour tourner : ce qui est branché vit sur vos outils ou sur un compte à votre nom, et vous repartez avec la documentation. Chaque flux est réglé pour vous alerter quand un envoi échoue, au lieu de tomber en silence. Reprendre la main plus tard, c'est une intervention ponctuelle — pas un abonnement obligatoire.
Est-ce que ça se branche chez vous ?
3 écrans, 1 minute. Vous recevez sous 48-72 h ouvrées le schéma de ce qui peut se brancher chez vous, les prérequis et une estimation. Gratuit, sans engagement.
Trois étapes, un livrable à chacune
Vous décrivez ce qui se passe à la main aujourd'hui. Je réponds sous 48-72 h ouvrées avec le schéma de ce qui peut se brancher chez vous, les prérequis et une estimation.
Audit de faisabilité
Formulaire en 3 minutes : vos outils, le sens du flux, le déclencheur, le volume. Réponse sous 48-72 h ouvrées avec le schéma du flux, les prérequis et les 3 chantiers prioritaires. Gratuit.
Devis à périmètre écrit
Ce que je branche, ce qui reste validé par vous, le délai et le prix fixe. Le périmètre est écrit avant de commencer, pas ajusté en cours de route.
Construction et passation
Je branche sur vos outils, je teste, je documente. Vous recevez les workflows documentés et la passation — vous gardez tout, et vous n'êtes pas dépendant de moi.