Webhooks et API : l’automatisation en temps réel

Tous vos scénarios planifiés partagent une faiblesse : ils vérifient. Toutes les 15 minutes, ils demandent « du nouveau ? » — et 95 fois sur 96, la réponse est non. Opérations gaspillées, latence subie. Les webhooks inversent la logique : c’est l’application qui vous prévient, instantanément, uniquement quand il se passe quelque chose. Et leur cousine l’API vous ouvre l’accès direct à n’importe quelle application, même sans module Make. Ces deux concepts sont la porte du niveau expert — et ils sont bien plus simples qu’ils n’en ont l’air.

Le webhook : une sonnette, pas une ronde

Concrètement, un webhook est une URL unique que Make génère pour vous (module « Webhooks → Custom webhook »). Vous collez cette URL chez l’application émettrice (Stripe, Typeform, Calendly… toutes le proposent dans leurs réglages « Webhooks » ou « Notifications »), et c’est tout : à chaque événement, l’app POSTe les données vers votre scénario, qui démarre instantanément.

Votre premier webhook en 4 gestes

1. Dans Make : nouveau scénario → module Custom webhook → « Add » → copiez l’URL générée.
2. Chez l’app émettrice : réglages → Webhooks → collez l’URL, choisissez l’événement (« payment succeeded », « form submitted »…).
3. Déclenchez un événement test ; Make capture la structure des données automatiquement.
4. Construisez la suite du scénario avec ces données, comme d’habitude.

L’API : parler directement aux applications

Une API n’est rien d’autre que la porte de service officielle d’une application : des adresses (endpoints) qui acceptent des requêtes structurées. Le module HTTP de Make sait les appeler toutes — c’est lui qui rend « toutes les apps connectables », promesse déjà croisée dans l’article connexions. Trois éléments à fournir, toujours les mêmes : la méthode et l’URL (que dit la documentation de l’app), l’authentification (votre clé d’API), et le corps de la requête (les données en JSON).

La compétence-clé n’est pas technique : c’est savoir lire une page de documentation d’API — repérer l’endpoint, l’exemple de requête, et le recopier dans le module HTTP en remplaçant les valeurs. Faites-le une fois ; toutes les autres documentations vous sembleront familières.

Module HTTP - exemple : créer une page Notion

Méthode : POST
URL     : https://api.notion.com/v1/pages
Headers : Authorization: Bearer {votre clé}
          Notion-Version: 2022-06-28
Body    : { "parent": {"database_id": "xxx"},
            "properties": { ... } }

FAQ — vos questions fréquentes

Quelle est la différence entre webhook et API, au fond ?

Le sens de l’appel : avec un webhook, l’application vous appelle (événement → vous). Avec une API, c’est vous qui appelez l’application (vous → action). Les deux se combinent dans un même scénario : un webhook Stripe déclenche, un appel API Notion exécute.

Tous les services proposent-ils des webhooks ?

Les outils modernes, presque tous (Stripe, Typeform, Calendly, GitHub, Shopify…). Les plus anciens ou grand public, pas toujours — d’où l’utilité de garder le polling dans sa boîte à outils. La page « Developers » ou « Intégrations » d’un service vous le dira en 30 secondes.

Le module HTTP est-il plus difficile que les modules natifs ?

Il demande un peu plus de rigueur (recopier la doc sans faute de frappe), mais c’est de la lecture, pas de la programmation. Et le jeu en vaut la chandelle : il supprime définitivement la phrase « cette app n’est pas compatible ».

Et dans n8n, tout cela existe ?

Oui, et même en mieux : le node Webhook est natif (souvenez-vous, n8n self-host les inclut gratuitement), et le node HTTP Request est l’un des plus utilisés de l’outil. Les concepts de cet article se transposent à l’identique.

En résumé

Webhook = l’app vous prévient (instantané, économe) ; API = vous commandez l’app (universel). Avec ces deux clés, plus aucune limite de catalogue ni de latence. Dernier article du module, et pas le moindre pour votre portefeuille : optimiser les coûts de vos automatisations.