Automatiser une application sans webhook dans n8n : le polling intelligent

Un CRM interne sans API événementielle, un ERP métier hébergé chez un prestataire qui ne propose que du REST classique, une plateforme SaaS dont les webhooks sont réservés au plan Enterprise : la majorité des automatisations n8n ne partent pas d’un événement poussé par l’application, mais doivent aller chercher l’information elles-mêmes. C’est plus courant qu’on ne le pense — une étude de Paul Murley, Zane Ma, Joshua Mason, Michael D. Bailey et Amin Kharraz, « WebSocket Adoption and the Landscape of the Real-Time Web », présentée à The Web Conference 2021, montre qu’à l’échelle du web entier, l’interrogation périodique (polling) reste largement plus répandue que les mécanismes événementiels comme WebSocket, y compris pour des usages qui bénéficieraient d’un flux temps réel. Le polling n’est donc pas un pis-aller honteux : c’est un pattern d’intégration à part entière, à condition de le construire correctement dans n8n plutôt que de brancher un Schedule Trigger sur un HTTP Request et d’espérer que ça tienne.

Pourquoi tant d’applications n’exposent pas de webhook

Avant de construire quoi que ce soit, il vaut la peine de vérifier vraiment l’absence de webhook plutôt que de la supposer :

• Logiciels métier et ERP (comptabilité, gestion de stock, CRM interne) : conçus avant l’ère des API événementielles, ils exposent souvent un simple CRUD REST ou SOAP, sans notification de changement.
• Fonctionnalité payante : de nombreux SaaS (support, facturation, e-commerce) réservent les webhooks à leurs plans supérieurs, alors que l’API de lecture reste disponible sur tous les niveaux d’abonnement.
• Politique réseau restrictive : certaines entreprises interdisent les connexions entrantes vers leurs systèmes internes pour des raisons de sécurité, rendant un webhook physiquement impossible à recevoir — voir notre guide sur la sécurisation des webhooks n8n pour comprendre pourquoi ce choix se défend.
• API mal documentée ou tierce non officielle : le webhook existe côté fournisseur mais n’est pas exposé publiquement, ou seulement via un partenariat commercial hors de portée.

Dans ces quatre cas, le polling n’est pas un contournement temporaire : c’est l’architecture définitive, à concevoir comme telle.

L’architecture du polling intelligent dans n8n

Un polling naïf récupère tout à chaque exécution et filtre après coup — ce qui fonctionne sur 50 enregistrements et s’effondre sur 50 000. La bonne architecture répartit le travail en trois étapes distinctes.

1. Le Schedule Trigger interroge, l’API filtre

Le node Schedule Trigger déclenche l’exécution à intervalle régulier, mais l’essentiel du travail se joue dans le node HTTP Request qui suit : plutôt que de tout récupérer, exploitez les paramètres de filtrage côté serveur que propose presque toute API REST digne de ce nom — updated_since, created_after, un paramètre sort=desc combiné à une pagination arrêtée dès le premier enregistrement déjà connu (voir notre guide de pagination avec HTTP Request). Faire filtrer l’API elle-même, plutôt que n8n après coup, réduit le volume de données transférées et le nombre d’items à traiter en aval — exactement le type de gain que documente une étude de référence sur les protocoles de communication web : Pimentel et Nickerson, « Communicating and Displaying Real-Time Data with WebSocket », publiée en 2012 dans IEEE Internet Computing, quantifie précisément le surcoût réseau d’une interrogation périodique par rapport à une communication événementielle — un rappel utile pour ne pas aggraver ce surcoût par un polling mal filtré.

2. Un curseur mémorise ce qui a déjà été vu

Le workflow doit savoir, d’une exécution à l’autre, où il s’est arrêté. C’est exactement le rôle de $getWorkflowStaticData() — nous détaillons sa syntaxe complète, ses pièges (notamment sur les exécutions de test) et ses limites en mode queue dans notre guide dédié au static data n8n. En résumé pour le polling : stockez le timestamp ou l’ID le plus récent traité avec succès, et utilisez-le comme paramètre de la requête suivante. Sur une instance en mode queue avec plusieurs workers (voir notre guide du mode queue Redis), préférez une table Supabase ou Postgres dédiée : le static data est attaché à l’instance principale, pas partagé entre workers.

3. Un filtre défensif élimine les doublons résiduels

Même avec un curseur fiable, prévoyez un filet de sécurité : un node Filter qui compare chaque ID reçu à une courte liste des derniers identifiants déjà traités, avant de laisser passer un enregistrement vers la suite du workflow. Cette logique est développée en détail dans notre article sur l’idempotence et l’évitement des doublons : les principes valent aussi bien pour un webhook rejoué que pour un polling qui chevaucherait légèrement deux exécutions.

Choisir l’intervalle : un arbitrage, pas un chiffre par défaut

Beaucoup de workflows partent sur « toutes les 5 minutes » sans réfléchir. Trois facteurs devraient guider ce choix :

• La fraîcheur réellement nécessaire : un digest quotidien tolère un polling toutes les heures ; une alerte de rupture de stock critique justifie un intervalle de quelques minutes. Interroger plus souvent que le besoin métier ne consomme que des ressources, sans bénéfice perçu.
• Le rate limit de l’API cible : calculez le nombre d’appels autorisés par jour, retranchez une marge de 20 à 30 % pour les relances en cas d’erreur (voir notre guide sur les erreurs 429 et le cadencement des appels API), et déduisez-en l’intervalle minimum viable.
• Le volume réel de nouveautés : si l’application génère en moyenne un nouvel enregistrement par heure, un polling toutes les cinq minutes ne fait que multiplier les appels à vide par douze, pour un gain de latence rarement perçu par l’utilisateur final.

Cas concret : surveiller les commandes d’un ERP sans webhook

Un exemple représentatif du pattern complet : un ERP de gestion commerciale interne, sans API événementielle, doit alimenter une automatisation de relance de dossiers incomplets — le même besoin métier que couvre notre guide sur les relances de dossiers incomplets, mais sans webhook disponible côté source.

1. Schedule Trigger toutes les 15 minutes, en heures ouvrées seulement (plusieurs Trigger Rules, comme décrit dans notre guide Schedule Trigger).
2. HTTP Request vers l’API de l’ERP avec un paramètre modified_since=<curseur>, trié par date de modification croissante.
3. Filter défensif contre la liste des derniers IDs déjà traités, stockée en static data.
4. IF pour distinguer commande nouvelle vs commande incomplète depuis plus de 48h.
5. Node Set pour mettre à jour le curseur, écrit en fin de workflow uniquement si l’exécution s’est terminée sans erreur — sinon le prochain passage revérifiera les mêmes enregistrements, ce qui est le comportement de repli souhaitable.
6. Notification Slack ou digest IA, sur le même principe que les workflows du Pack Inbox IA et du Pack Conformité & Audit, qui embarquent déjà ce type de logique de curseur et de déduplication prêtes à l’emploi.

Quand basculer vers un vrai webhook

Le polling reste un compromis, jamais un objectif. Dès qu’une application cible ouvre un webhook — passage à un plan supérieur, mise à jour de l’API, accès partenaire obtenu — la bascule mérite d’être planifiée plutôt que reportée indéfiniment : latence quasi nulle, aucun appel à vide, et une charge sur l’API tierce ramenée au strict nécessaire. Notre guide complet des webhooks n8n couvre la mise en place, et la transition est généralement rapide : le Schedule Trigger et le HTTP Request disparaissent, le reste du workflow (filtre défensif, traitement, notification) reste identique, puisque la logique de déduplication décrite plus haut protège tout autant contre les doublons de webhook.

En résumé

Le polling n’est pas un hack temporaire : c’est une architecture d’intégration légitime dès qu’un webhook n’est pas disponible, à condition de filtrer côté API, de mémoriser un curseur fiable, de garder un filet de déduplication, et de calibrer l’intervalle sur le besoin réel plutôt que sur une habitude. Les packs FlowKit appliquent déjà ces principes dans leurs workflows de veille et de relance — de quoi partir d’une base éprouvée plutôt que de réinventer la logique de curseur à chaque nouvelle intégration.