Simbase Usage Guard Toolkit (DIY)

Définissez une limite d'utilisation personnalisée grâce à la boîte à outils Simbase Usage Guard

La fonctionnalité intégrée de Simbase Limites d'utilisation Vérifiez l'utilisation lorsque les CDR sont transmis par le réseau, généralement toutes les quelques heures. Si vous avez besoin de des contrôles plus stricts (toutes les 30 minutes, toutes les 5 minutes, à la demande) ou logique personnalisée (alerte en cas d'avertissement, désactivation de certaines cartes SIM uniquement, exclusion des heures de bureau), le Boîte à outils Usage Guard Il s'agit d'une solution d'automatisation « sans code » que vous pouvez créer vous-même à l'aide de l'API Simbase et de Make.com.

Cet article présente les fonctionnalités de la boîte à outils, les situations dans lesquelles elle constitue la solution la plus adaptée et la manière de la configurer.

Fonctionnalités de la boîte à outils

Une automatisation planifiée qui :

Interrogation de l'API d'utilisation de Simbase pour chaque carte SIM de votre compte (ou un sous-ensemble filtré).
Compare les utilisations pour chaque carte SIM, par rapport à un seuil que vous définissez.
Désactive les cartes SIM qui dépassent le seuil via l'API Simbase.
Vous informe (Slack, e-mail, webhook, journal Google Sheets, tout ce que vous configurez).

Il repose sur Make.com car c'est une solution visuelle, sans code, et la plupart des clients peuvent la mettre en place en moins de 15 minutes. Le même principe s'applique dans Zapier, n8n ou via un script personnalisé. Make.com n'est que la méthode que Simbase a documentée.

Quand la boîte à outils est la solution idéale

Privilégiez la boîte à outils plutôt que (ou en complément) des limites d'utilisation natives lorsque vous avez besoin :

Des intervalles de contrôle plus courts. Les limites d'utilisation natives s'appliquent dès la réception du CDR ; le Toolkit peut s'exécuter aussi souvent que le permet votre plateforme d'automatisation.
Flux de notification personnalisés. Vous voulez recevoir une notification Slack à 80 % de la capacité maximale et désactiver l'alerte à 100 % ? Créez-la.
Seuils à plusieurs niveaux. Avertir, puis désactiver, puis alerter l'équipe d'exploitation, le tout en une seule étape.
Conditions liées aux règles métier. Ne pas désactiver le service le week-end, ignorer certaines balises, ne désactiver que les cartes SIM de test, etc.
Intégration intersystèmes. Synchronisez les données d'utilisation avec votre CRM, enregistrez chaque événement de désactivation dans un entrepôt de données, etc.

Respectez les limites d'utilisation par défaut dans les cas suivants :

Le comportement par défaut (désactivation en cas de dépassement du plafond, réinitialisation automatique mensuelle facultative) correspond à ce que vous souhaitez.
Vous ne souhaitez pas gérer un système d'automatisation tiers.
Vous n'avez pas besoin de notifications personnalisées ni de logique métier.

Vous pouvez utiliser les deux: les limites d'utilisation natives servent de référence, tandis que le Toolkit gère les cas particuliers. Il n'y a pas de conflit entre les deux.

Ce que la boîte à outils ne peut pas faire

Même contrainte que pour les limites d'utilisation natives : Cela dépend des données d'utilisation de Simbase, ce qui dépend de la réception des CDR provenant du réseau. Une boîte à outils s'exécutant toutes les 5 minutes continue de fonctionner à partir de CDR qui peuvent dater de plusieurs heures.

Pour disposer d'une limite maximale stricte en temps réel, il faudrait surveiller la consommation de données sur l'appareil lui-même et faire en sorte que l'appareil coupe la connexion lorsqu'il atteint la limite. Cela dépasse les capacités de Simbase ou de Make.com.

Plan directeur

Make.com scenario showing the Usage Guard flow: query usage, iterate, get SIM state, disable SIM.

Si cela vous semble compliqué, ne vous inquiétez pas. Ce tutoriel vous guidera étape par étape dans la création de votre propre « Usage Guard Toolkit ». Vous n'aurez pas besoin d'écrire la moindre ligne de code, et nous vous montrerons exactement comment le configurer à l'aide de Make.com.

Configuration de la boîte à outils

Étape 1 : Choisissez votre plateforme d'automatisation

Make.com est recommandé aux nouveaux utilisateurs :

Générateur visuel de flux, aucun codage requis.
La formule gratuite suffit pour les petites flottes.
Les formules payantes sont destinées aux flottes plus importantes et aux intervalles plus courts.

Zapier, n8n, Pipedream ou un script Python/Node personnalisé fonctionnent tous. La suite de ce guide utilise Make.com ; les mêmes modules et la même logique s'appliquent ailleurs.

Étape 2 : Créer une clé API Simbase

Connectez-vous à dashboard.simbase.com.
Aller à Intégrations → API.
Cliquez ici Créer une nouvelle clé API.
Donne-lui un nom Boîte à outils Usage Guard (ou équivalent).
Définir toutes les ressources sur Écrire. Conservez les paramètres avancés par défaut.
Cliquez ici Créer et copiez la clé.

Voir Clés API pour connaître les droits associés à chaque niveau d'autorisation.

Considérez la clé API comme un mot de passeToute personne disposant de cette clé peut gérer vos cartes SIM. Enregistrez-la dans le gestionnaire de secrets ou de connexions de votre plateforme d'automatisation, et non en texte clair.

Étape 3 : Importer le plan Make.com

Simbase publie un modèle préconfiguré que vous pouvez importer en une seule étape :

Télécharger le plan (chercher Simbase-Usage-Guard-Toolkit.blueprint.json, environ 27 Ko).
Dans Make.com, créez un nouveau scénario.
Utilisation Importer un plan puis sélectionnez le fichier JSON téléchargé.
Ouvrir chacun des trois modules HTTP et remplacer le caractère de remplacement YoUrApiKeYHeRe avec votre clé API.
Réglez le seuil d'utilisation dans le module de comparaison (exemple par défaut : 10 Go).
Testez le scénario manuellement avant d'activer la planification.

Le schéma décrit le déroulement de base : récupération des données d'utilisation → itération sur les cartes SIM → comparaison avec le seuil → vérification de l'état actuel des cartes SIM → désactivation des cartes SIM qui ne sont pas déjà désactivées.

Étape 4 : Personnalisez-le en fonction de vos besoins

Le modèle sert de point de départ. Personnalisations courantes :

Conversion des seuils. L'API renvoie l'utilisation en octets, en gigaoctets binaires : 1 Go = 1 073 741 824 octets, donc 10 Go = 10 737 418 240. Cette convention diffère de celle du tableau de bord, où une limite d'utilisation de 1 Go correspond à 1 000 Mo. Un seuil de 10 Go dans le Toolkit est environ 7 % plus élevé qu'une limite d'utilisation de 10 Go. Si vous souhaitez que les deux correspondent, réglez la comparaison du Toolkit sur 10 000 000 000 à la place.
Pagination. Il faut environ 500 cartes SIM ou plus. Voir la section « Pagination » ci-dessous pour les grandes flottes.
Notifications. Ajouter un module permettant d'envoyer une notification via Slack, par e-mail ou via un webhook lorsqu'une carte SIM dépasse le seuil défini.
Filtre par balise. Appliquez cette vérification uniquement aux cartes SIM portant une balise spécifique (par exemple, production uniquement, exclure test).

Itération sur le tableau SIM

L'API d'utilisation renvoie un tableau d'objets SIM sous le data.simcards champ. Pour traiter chacun d'entre eux individuellement dans Make.com :

Dans le module HTTP, configurez Analyser la réponse à Oui.
Ajouter un Itérateur module.
Définissez le tableau de l'itérateur sur data.simcards à partir de la réponse HTTP.

Chaque itération correspond donc à une seule carte SIM que vous pouvez comparer et sur laquelle vous pouvez agir.

Pagination pour les grandes flottes

Par défaut, ce modèle ne prend pas en charge la pagination. Il fonctionne sans modification pour les flottes comptant jusqu'à quelques centaines de cartes SIM. Pour les flottes plus importantes :

Vérifiez la réponse de l'API pour voir s'il y a « has_more » : true.
Si c'est vrai, lisez le curseur valeur.
Envoyez une autre demande à /v2/usage/simcards?cursor=<value>.
Répétez jusqu'à ce que has_more est faux.

Sur Make.com, cela est mis en œuvre à l'aide d'un Un répéteur et une boucle de requêtes HTTP, ce qui sort du cadre du plan de base.

Avertissement

La boîte à outils Usage Guard est bricolage. Bien qu'il utilise l'API officielle de Simbase, Simbase décline toute responsabilité pour :

Limites non respectées en raison de retards liés au CDR ou à l'API.
Les cartes SIM ne sont pas désactivées à temps.
Excédent, coûts ou interruption de service qui en résulteraient.

Testez minutieusement votre configuration, surveillez-la régulièrement et ne comptez pas uniquement sur elle comme seule mesure de protection pour les SIM où tout dépassement de budget aurait des conséquences catastrophiques.

Questions fréquentes

Oui. La logique s'applique telle quelle. Le schéma de Make.com sert de point de départ ; il suffit de recréer les mêmes modules dans Zapier à l'aide d'étapes de requête HTTP.

Oui. Ajoutez un scénario planifié qui s'exécute le 1er de chaque mois et réactive les cartes SIM en fonction d'une balise ou d'un filtre. La fonctionnalité native « Réinitialisation automatique mensuelle des limites d'utilisation » s'en charge pour vous si vous n'avez besoin que du comportement de base.

Une fréquence plus élevée ne signifie pas nécessairement une plus grande précision. Le Toolkit analyse les données d'utilisation de Simbase, qui ne sont mises à jour qu'à l'arrivée des CDR provenant du réseau, souvent espacés de plusieurs heures. Une exécution toutes les 5 minutes revient principalement à relire les mêmes chiffres et à surcharger les opérations d'automatisation. Une fréquence de 15 à 30 minutes suffit pour la plupart des flottes.

Rien ne désactive les cartes SIM. Seul le Toolkit applique le seuil que vous avez défini ; ainsi, un scénario mis en pause, une clé API périmée ou un forfait Make.com épuisé supprime cette protection sans avertissement. Activez les notifications d’erreur dans Make.com et veillez à ce que les limites d’utilisation natives restent activées en arrière-plan, à titre de mesure de sécurité.