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 (notification en cas d'alerte, 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 cas dans lesquels elle constitue la solution la plus adaptée et la procédure à suivre pour la configurer.

Fonctionnalités de la boîte à outils

Une automatisation planifiée qui :

1. Interrogation de l'API d'utilisation de Simbase pour chaque carte SIM de votre compte (ou un sous-ensemble filtré)

2. Compare les utilisations pour chaque carte SIM, par rapport à un seuil que vous définissez

3. Désactive les cartes SIM qui dépassent le seuil via l'API Simbase

4. 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 natives s'appliquent dès l'arrivée d'un 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 lorsque le plafond est atteint à 80 % et que le système se désactive à 100 % ? Créez-le

• Seuils à plusieurs niveaux. Envoyer un avertissement, puis désactiver la fonctionnalité, 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 une solution d'automatisation tierce

• 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, le Toolkit prenant en charge 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 stricte véritablement 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 dès que la limite est atteinte. Cela dépasse les capacités de Simbase ou de Make.com.

Plan directeur

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

• L'offre 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 un Simbaclé API

1. Connectez-vous pour dashboard.simbase.com

2. Aller à Intégrations → Clés API

3. Cliquez Créer une clé API

4. Donnez-lui un nom Boîte à outils Usage Guard (ou équivalent)

5. Activer Écrire autorisation. Conservez les autres paramètres par défaut.

6. Cliquez Créer et copiez la clé

Considérez la clé API comme un mot de passe. Toute 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 de Make.com

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

1. Télécharger le plan (cherchez Simbase-Usage-Guard-Toolkit.blueprint.json, environ 27 Ko).

2. Sur Make.com, créez un nouveau scénario

3. Utilisation Importer un modèle puis sélectionnez le fichier JSON téléchargé

4. Ouvrir chacun des trois modules HTTP et remplacer le caractère de remplacement YoUrApiKeYHeRe avec votre clé API

5. Réglez le seuil d'utilisation dans le module de comparaison (exemple par défaut : 10 Go)

6. 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 pour le Toolkit est environ 7 % supérieur à une limite d'utilisation de 10 Go — si vous souhaitez que les deux correspondent, définissez 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 les traiter individuellement sur Make.com :

1. Dans le module HTTP, configurez Analyser la réponse à Oui

2. Ajouter un Itérateur module

3. 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, le 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 si la réponse de l'API contient « has_more » : true

• Si c'est vrai, lisez le curseur valeur

• Envoyez une nouvelle demande à /v2/usage/simcards?cursor=<value>

• Répéter 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 directeur de base.

Avertissement

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

• Plafonds non atteints 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ésultent

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 serait catastrophique.

Questions fréquentes

À lire également

• Limites d'utilisation, l'alternative native présentant un coefficient de frottement plus faible

• Fonction de désactivation automatique, désactivation selon le calendrier

• API, l'interface sous-jacente

• Mots-clés, ce qui permet de limiter le champ d'application de la boîte à outils à certains sous-ensembles de la flotte