API vs webhook : tirer l'information ou se la faire pousser

Dans le cahier des charges : « connexion par API¹ ». Trois mois plus tard, quelqu'un demande des webhooks². Les deux camps ont raison, sur des problèmes différents. Encore faut-il nommer lesquels.

Une API¹ (Application Programming Interface) est une interface documentée qui permet à un logiciel d'appeler un autre : lire une commande, créer un tiers, lister des stocks. Un webhook² est une notification HTTP poussée par le système source vers une URL que vous exposez, quand un événement survient (commande créée, paiement reçu, ticket fermé).

Pull contre push, et ce que ça change pour l'intégration en ETI¹⁰. Portlane utilise les deux comme modes d'entrée ; le cœur reste le chemin après réception.

Définition utile, pas marketing

• API¹ : vous tirez (ou envoyez) à la demande, souvent REST/JSON, parfois SOAP⁶ encore.
• Webhook² : le système source pousse un événement vers vous quand ça arrive.
• Polling³ : stratégie qui consiste à rappeler l'API¹ à intervalle régulier pour détecter du nouveau. Utile sans webhook².

En une phrase : l'API¹ répond à une question que vous posez ; le webhook² vous annonce une nouvelle sans que vous ayez demandé à cet instant.

Ce que l'API fait bien

• Contrôle du rythme : vous décidez quand appeler.
• Requêtes précises : filtres, pagination, lecture ciblée.
• Écriture : créer / mettre à jour chez la cible via l'API¹ cible.
• Universalité : presque tout exposé modernement parle API¹.

Ce que le webhook fait bien

• Réactivité : l'événement arrive quand il se produit, pas au prochain cron.
• Moins de charge inutile : pas besoin de poller toutes les minutes « au cas où ».
• Déclencheurs métier : adapté pour démarrer un flux sur « commande confirmée ».

Limites des deux (sans langue de bois)

• API + polling³ : simple, mais latence et charge ; risque de rater la fenêtre si mal cadencé.
• Webhook² : exige une URL joignable, une auth solide, une gestion des retries côté émetteur, et surtout une réception durable chez vous.
• Les deux : sans file d'attente⁴ derrière, un pic ou une panne fait perdre des événements ou saturer le worker.

API vs webhook, côte à côte

• Direction API¹ : souvent pull (vous appelez). Webhook² : push (on vous appelle).
• Latence API¹ + polling³ : selon l'intervalle. Webhook² : proche du temps réel de l'événement.
• Complexité ops API¹ : credentials, quotas, pagination. Webhook² : endpoint public, signatures, replay, disponibilité.
• Best for API¹ : sync planifiée, lectures riches, écritures. Webhook² : réagir à un événement métier dès qu'il existe.

Le pattern qui tient en production

• Recevoir (webhook² ou résultat d'appel API¹).
• Poser en file d'attente⁴. Ne pas traiter dans la requête HTTP si le travail est long.
• Transformer (code testable).
• Livrer via l'API¹ cible, avec retries et rejeu.
• Isoler les échecs via DLQ / patterns.

API¹ et webhook² sont la bordure. La solidité se joue après.

Où se place Portlane

Portlane traite API¹ et webhook² comme des entrées vers un chemin unique : file → orientation → Python → livraison. Interfaces documentées HTTP/JSON, plutôt qu'un catalogue de connecteurs⁷ comme argument central.

Encore en développement actif. Vocabulaire d'entrée ici ; produit : pourquoi nous construisons Portlane.

Comment trancher

• Le système source a-t-il des webhooks² fiables et documentés ? Sinon, API¹ + polling³.
• Avez-vous besoin de réagir en secondes, ou une sync horaire suffit ?
• Pouvez-vous exposer un endpoint authentifié chez vous (ou via un reverse proxy) ?
• Dans tous les cas : file d'attente⁴ derrière la réception.

Pour aller plus loin

• Qu'est-ce qu'un iPaaS
• Dead letter queue et patterns
• Rejeu de flux
• L'ESB est trop vieux

API¹ vs webhook², ce n'est pas une guerre. C'est pull contre push, et ensuite la question devient : que fait votre runtime du message une fois arrivé ?

Questions fréquentes

API et webhook, c'est la même chose ?

Non. Une API¹ est une interface pour interroger ou commander un système (souvent en tirant l'information). Un webhook² est une notification poussée par le système quand un événement survient. L'un tire, l'autre pousse.

Faut-il abandonner le polling au profit des webhooks ?

Quand le système source offre des webhooks² fiables : souvent oui pour la réactivité. Sinon, un appel planifié (polling³) reste rationnel. Beaucoup de SI réels mélangent les deux.

Un webhook remplace-t-il une file d'attente ?

Non. Le webhook² livre l'événement à votre bordure. La file d'attente⁴ le conserve pour le traitement asynchrone, les retries et le rejeu. Sans file, un webhook² lent ou en panne perd des événements.

Comment Portlane voit API et webhook ?

Comme deux façons d'entrer dans le chemin : récupération planifiée via API¹, ou réception d'événements (webhook²). Ensuite : file, transformation, livraison. Produit en développement actif.

Les webhooks sont-ils plus sûrs ?

Pas automatiquement. Il faut authentifier l'émetteur, valider les signatures, gérer les replays malveillants. Une API¹ tirée avec des credentials maîtrisés peut être plus simple à sécuriser selon le contexte.

Glossaire

• ¹ API : interface qui permet à deux logiciels d'échanger des données ou des commandes de façon standardisée.
• ² Webhook : notification HTTP poussée par un système lorsqu'un événement survient.
• ³ Polling : appels répétés à une API pour détecter des nouveautés.
• ⁴ File d'attente : stockage temporaire des messages avant traitement.
• ⁵ REST : style d'API HTTP courant (ressources, verbes, JSON).
• ⁶ SOAP : protocole d'échange XML plus ancien, encore présent dans certains SI.
• ⁷ Connecteur : module éditeur pour brancher une application sur une plateforme.
• ⁸ Retry : nouvelle tentative après un échec transitoire.
• ⁹ Rejeu : retraitement contrôlé d'un message déjà reçu.
• ¹⁰ ETI : entreprise de taille intermédiaire en France.