API REST et webhook répondent à deux besoins différents : interroger un système à la demande, ou être notifié en temps réel. Comparatif pratique par KSolution.
Connecter deux outils métier — un CRM à un ERP, un formulaire à un tableau de bord — soulève systématiquement la même question technique : faut-il interroger l'API REST du système, ou attendre qu'il notifie via un webhook ? Le choix n'est pas une préférence technique, il dépend directement du besoin métier.
Quelle est la différence entre une API REST et un webhook ?
Une API REST se interroge à la demande — votre système envoie une requête et attend une réponse. Un webhook fonctionne à l'inverse : le système tiers envoie automatiquement une notification vers votre application dès qu'un événement se produit, sans que vous ayez à demander quoi que ce soit. L'API REST est un mode « pull », le webhook un mode « push ».
Quand utiliser une API REST plutôt qu'un webhook ?
L'API REST convient dès que votre application a besoin de contrôler le moment de la requête : afficher la liste des clients d'un CRM au chargement d'une page, vérifier le stock disponible avant validation d'une commande, récupérer l'historique complet d'un compte. Elle est adaptée aux besoins ponctuels ou déclenchés par une action utilisateur, où votre application décide quand elle a besoin de la donnée.
Son inconvénient principal : si vous voulez rester à jour en continu, il faut interroger l'API à intervalles réguliers (polling), ce qui génère du trafic inutile et un délai entre l'événement réel et sa détection — souvent plusieurs minutes selon la fréquence choisie.
Quand utiliser un webhook plutôt qu'une API REST ?
Le webhook convient dès qu'un événement doit déclencher une action immédiate ailleurs : un paiement validé qui doit créer une facture, un formulaire soumis qui doit notifier un commercial, un statut de livraison qui doit mettre à jour le CRM. Il élimine le polling et réduit le délai entre l'événement et sa prise en compte à quelques secondes.
Sa contrainte : votre application doit exposer une URL publique capable de recevoir les notifications, sécurisée (vérification de signature, HTTPS obligatoire), et tolérante aux doublons — un webhook peut être envoyé plusieurs fois pour le même événement en cas de problème réseau côté émetteur.
Comparatif direct : API REST ou webhook ?
| Critère | API REST | Webhook |
|---|---|---|
| Sens de la communication | Votre app interroge le système | Le système notifie votre app |
| Délai de mise à jour | Dépend de la fréquence d'interrogation | Quasi temps réel |
| Charge réseau | Élevée si polling fréquent | Minimale — un appel par événement |
| Complexité côté récepteur | Faible | Moyenne (endpoint public sécurisé) |
| Cas d'usage typique | Consultation de données à la demande | Synchronisation événementielle |
Peut-on combiner les deux dans une même intégration ?
Oui, et c'est même la pratique la plus robuste en environnement PME. Un webhook signale qu'un événement s'est produit (« commande créée »), puis l'application appelle l'API REST pour récupérer le détail complet de l'objet concerné plutôt que de se fier uniquement aux données envoyées dans la notification, souvent incomplètes. Cette combinaison limite le risque d'une intégration cassée si le format du webhook évolue sans préavis côté fournisseur.
Quelles erreurs fréquentes lors d'une intégration webhook ?
- Ne pas vérifier la signature du webhook, ce qui expose l'endpoint à des notifications falsifiées
- Ne pas gérer l'idempotence — traiter deux fois le même événement reçu en double sans détection
- Répondre trop lentement (au-delà de quelques secondes), ce qui pousse le système émetteur à considérer l'envoi comme échoué et à le renvoyer en boucle
- Ne pas journaliser les webhooks reçus, rendant tout diagnostic impossible en cas d'incident
Un endpoint webhook bien conçu répond immédiatement avec un code 200, puis traite l'événement de façon asynchrone via une file de messages — c'est le pattern utilisé côté Symfony avec Messenger, qui découple la réception de la notification du traitement métier réel.
Que faire si l'outil tiers ne propose pas de webhook ?
Certains outils métier, notamment les plus anciens ou les logiciels de gestion internes, n'exposent qu'une API REST classique sans mécanisme d'événement. Dans ce cas, le polling reste la seule option, mais il peut être optimisé : interroger uniquement les enregistrements modifiés depuis le dernier appel (paramètre updated_since ou équivalent) plutôt que l'ensemble des données, et espacer la fréquence selon la criticité réelle du besoin — toutes les cinq minutes pour une synchronisation de stock, une fois par jour pour un rapprochement comptable. Un polling mal calibré peut saturer l'API du système tiers et déclencher une limitation de débit (rate limiting), qui casse l'intégration au moment le moins opportun.
Comment choisir concrètement pour votre intégration ?
La question à se poser n'est pas « quelle technologie est la plus moderne » mais « qui a besoin de savoir, et à quel moment ». Si votre application a besoin de vérifier un état ponctuellement, l'API REST suffit. Si un événement chez un tiers doit déclencher une action chez vous sans délai, le webhook s'impose. Une intégration mal choisie sur ce critère se traduit presque toujours par des données désynchronisées ou un système de ressaisie manuelle en secours — le symptôme que nous détaillons dans notre article sur l'intégration d'outils métier en PME.
KSolution conçoit ces connecteurs sur mesure en tenant compte de la fiabilité réseau réelle des systèmes concernés, pas uniquement de la documentation API fournie. Pour évaluer l'intégration la plus adaptée à vos outils, échanger sur votre projet de connecteur.
