Les APIs Meraki offrent une des limites de débit les plus généreuses du secteur : jusqu’à 10 appels par seconde, bien au-dessus de la plupart des solutions de réseau géré dans le cloud. Pour la grande majorité des clients, c’est largement suffisant. Certains déploiements à très grande échelle peuvent atteindre cette limite. Mais ce n’est pas là que le vrai problème commence.
Le besoin
Le problème de fond, c’est que le polling est le mauvais modèle pour des données événementielles, quelle que soit la limite de débit.
Prenons un cas concret. Je veux tracer les changements de configuration du dashboard dans Splunk. Avec l’Add-On Meraki pour Splunk, je configure une collecte périodique. Résultat : polling toutes les heures, aucun changement détecté pendant plusieurs jours, puis un incident à 14h10 et une notification dans Splunk 50 minutes plus tard.
Ce délai n’est pas un problème de fréquence d’appels. C’est un problème de modèle. Quand vous interrogez régulièrement le statut de vos équipements, vous ne cherchez pas à confirmer qu’ils fonctionnent. Vous cherchez à savoir quand ils tombent. Ce qui compte pour les équipes réseau, ce ne sont pas les états stables, ce sont les changements d’état. Et pour ça, interroger toutes les heures génère une masse d’appels inutiles, pour une information qui arrive trop tard.
La solution
Le principe est simple : au lieu que votre système interroge Meraki, c’est Meraki qui pousse l’information vers vous dès qu’un événement se produit. C’est exactement le même raisonnement que la streaming telemetry, appliqué aux APIs.
Les Push APIs Meraki permettent de s’abonner à des topics (changements de configuration, disponibilité des équipements, statut des liens, …) et de recevoir les mises à jour en temps réel via webhook. Sans polling, sans délai, sans appels redondants. C’est exactement le même principe que la streaming telemetry, mais appliqué aux APIs.
Le résultat
Une fois les Push APIs configurées, vous pouvez alimenter un dashboard Splunk avec vos changements de configuration en temps réel. Vous pouvez même connecter un LLM (Large Language Model) pour interroger vos logs directement depuis Telegram.
La bonne information arrive au bon moment, sans surcharger votre infrastructure ni votre quota d’appels API.
Conclusion
Le titre de cet article est volontairement provocateur. Le polling des APIs Meraki reste essentiel pour l’automatisation et les requêtes à la demande, et avec 10 appels par seconde, vous avez une marge confortable. Mais pour les événements, les changements et l’alerting, le polling n’est plus le bon outil. Passer au push, c’est aligner le modèle de collecte sur la nature des données : des états qui changent, pas des états qu’on surveille en continu.
Si vous êtes prêts à passer au push, vos équipes de comptes Cisco peuvent vous aider à démarrer dès aujourd’hui.
Et vous, quels événements aimeriez-vous recevoir en temps réel plutôt que d’aller les chercher ? Dites-le nous en commentaire !
Authors
