Créer un plafond de consommation personnalisé avec le Simbase Usage Guard Toolkit

Les limites d'utilisation intégrées de Simbase vérifient la consommation à l'arrivée des CDR du réseau, en général toutes les quelques heures. Si vous avez besoin de contrôles plus fréquents (toutes les 30 minutes, toutes les 5 minutes, à la demande) ou d'une logique personnalisée (alerte en cas d'avertissement, désactivation de certaines SIM seulement, exclusion des heures ouvrées), le Usage Guard Toolkit est une automatisation no-code que vous construisez vous-même avec l'API Simbase et Make.com.

Cet article explique ce que fait le Toolkit, quand c'est la bonne solution et comment le configurer.

Ce que fait le Toolkit

Une automatisation planifiée qui :

1. interroge l'API de consommation de Simbase pour chaque SIM de votre compte (ou un sous-ensemble filtré).

2. compare la consommation de chaque SIM à un seuil que vous définissez.

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

4. vous prévient (Slack, e-mail, webhook, journal Google Sheets, selon ce que vous connectez).

Il repose sur Make.com parce que c'est visuel, sans code, et que la plupart des clients le font tourner en moins de 15 minutes. La même logique fonctionne dans Zapier, n8n ou un script maison. Make.com est simplement la voie que Simbase a documentée.

Quand le Toolkit est la bonne solution

Choisissez le Toolkit à la place des limites d'utilisation natives (ou en complément) si vous avez besoin de :

• Intervalles de contrôle plus courts. Les limites d'utilisation natives s'appliquent à l'arrivée des CDR ; le Toolkit peut tourner aussi souvent que votre plateforme d'automatisation le permet.

• Notifications personnalisées. Un message Slack à 80 % du plafond et une désactivation à 100 % ? Construisez-le.

• Seuils à plusieurs niveaux. Avertir, puis désactiver, puis alerter l'équipe ops, le tout dans un seul flux.

• Conditions métier. Ne pas désactiver le week-end, ignorer certains tags, désactiver uniquement les SIM de test, etc.

• Intégration avec d'autres systèmes. Synchroniser la consommation avec votre CRM, journaliser chaque désactivation dans un data warehouse, etc.

Restez sur les limites d'utilisation natives si :

• le comportement par défaut (désactivation en cas de dépassement, remise à zéro mensuelle automatique en option) vous convient.

• vous ne voulez pas maintenir une automatisation tierce.

• vous n'avez pas besoin de notifications ou de logique métier personnalisées.

Vous pouvez aussi utiliser les deux : les limites d'utilisation natives comme base, et le Toolkit pour les cas particuliers. Ils ne se gênent pas.

Ce que le Toolkit ne peut pas faire

Même contrainte que les limites d'utilisation natives : il dépend des données de consommation Simbase, qui dépendent elles-mêmes de l'arrivée des CDR du réseau. Un Toolkit lancé toutes les 5 minutes travaille toujours sur des CDR qui peuvent dater de plusieurs heures.

Pour un vrai plafond strict en temps réel, il faut surveiller la consommation de données sur l'appareil lui-même et faire couper la connexion par l'appareil dès qu'il atteint la limite. Cela dépasse ce que Simbase ou Make.com peuvent fournir.

Blueprint

Si cela vous paraît compliqué, pas d'inquiétude. Ce tutoriel vous guide pas à pas pour construire votre propre Usage Guard Toolkit. Aucune ligne de code à écrire : nous vous montrons exactement comment le configurer dans Make.com.

Configurer le Toolkit

Étape 1 : choisir votre plateforme d'automatisation

Pour une première fois, nous recommandons Make.com :

• Éditeur de flux visuel, sans code.

• L'offre gratuite suffit pour les petites flottes.

• Les offres payantes gèrent des flottes plus grandes et des intervalles plus courts.

Zapier, n8n, Pipedream ou un script Python/Node maison fonctionnent aussi. 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

1. Connectez-vous à dashboard.simbase.com.

2. Allez dans Integrations → API.

3. Cliquez sur Create New API Key.

4. Nommez-la Usage Guard Toolkit (ou un nom similaire).

5. Réglez All resources sur Write. Laissez les paramètres avancés par défaut.

6. Cliquez sur Create et copiez la clé.

Consultez Clés API pour savoir ce que couvre chaque niveau d'autorisation.

Étape 3 : importer le blueprint Make.com

Simbase propose un blueprint préconfiguré à importer en une seule étape :

1. Téléchargez le blueprint (cherchez Simbase-Usage-Guard-Toolkit.blueprint.json, ~27 Ko).

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

3. Utilisez Import Blueprint et sélectionnez le fichier JSON téléchargé.

4. Ouvrez chacun des trois modules HTTP et remplacez l'espace réservé YoUrApiKeYHeRe par votre clé API.

5. Ajustez le seuil de consommation dans le module de comparaison (exemple par défaut : 10 Go).

6. Testez le scénario manuellement avant d'activer la planification.

Le blueprint gère le flux de base : récupérer la consommation → parcourir les SIM → comparer au seuil → vérifier le statut actuel de la SIM → désactiver les SIM qui ne le sont pas déjà.

Étape 4 : adapter à vos besoins

Le blueprint est un point de départ. Adaptations courantes :

• Conversion du seuil. L'API renvoie la consommation en octets, en gigaoctets binaires : 1 Go = 1 073 741 824 octets, donc 10 Go = 10 737 418 240. Ce n'est pas la même convention que dans le tableau de bord, où une limite d'utilisation de 1 Go correspond à 1 000 Mo. Un seuil Toolkit de 10 Go est donc environ 7 % plus élevé qu'une limite d'utilisation de 10 Go. Pour aligner les deux, réglez plutôt la comparaison du Toolkit sur 10 000 000 000.

• Pagination. Nécessaire au-delà d'environ 500 SIM. Voir Pagination pour les grandes flottes ci-dessous.

• Notifications. Ajoutez un module qui envoie un message Slack, un e-mail ou un webhook quand une SIM dépasse le seuil.

• Filtre par tag. N'appliquez la vérification qu'aux SIM portant un tag précis (par exemple uniquement production et pas test).

Parcourir le tableau de SIM

L'API de consommation renvoie un tableau d'objets SIM dans le champ data.simcards de la réponse. Pour les traiter un par un dans Make.com :

1. Dans le module HTTP, réglez Parse response sur Yes.

2. Ajoutez un module Iterator à votre scénario.

3. Définissez le tableau de l'itérateur sur data.simcards de la réponse HTTP.

Chaque itération correspond alors à une SIM que vous pouvez comparer et traiter.

Pagination pour les grandes flottes

Le blueprint n'inclut pas de pagination par défaut. Il fonctionne sans modification pour des flottes de quelques centaines de SIM. Pour des flottes plus grandes :

• Vérifiez si la réponse de l'API contient "has_more": true.

• Si c'est le cas, lisez la valeur de cursor dans la réponse.

• Envoyez une nouvelle requête à /v2/usage/simcards?cursor=<value>.

• Répétez jusqu'à ce que has_more soit false.

Dans Make.com, cela se fait avec un Repeater et une boucle de requêtes HTTP, ce qui dépasse le cadre du blueprint de base.

Avertissement

Le Usage Guard Toolkit est à monter vous-même. Même s'il utilise l'API officielle de Simbase, Simbase décline toute responsabilité pour :

• Les plafonds manqués à cause de retards des CDR ou de l'API.

• Les SIM qui ne sont pas désactivées à temps.

• Les dépassements, coûts ou interruptions de service qui en résultent.

Testez soigneusement votre configuration, surveillez-la régulièrement et n'en faites pas votre seule protection pour des SIM dont un dépassement de coûts serait catastrophique.

Questions fréquentes

Articles associés

• Limites d'utilisation : l'alternative native, plus simple

• Auto-disable : désactivation selon un calendrier

• Clés API : créer et restreindre la clé utilisée par le Toolkit pour s'authentifier

• API : l'interface sous-jacente

• Tags : pratique pour limiter le Toolkit à une partie de la flotte