Retour au blog

Bienvenue chez Guarda : l’intelligence IP au service de décisions trafic fiables

annoncesproduitintelligence IP

Présentation de Guarda : ce que vérifie notre API d’intelligence IP, comment le score de risque est construit et comment les équipes l’utilisent pour distinguer les vrais utilisateurs des proxies, VPN et bots.

Pourquoi nous avons créé Guarda

Tout produit en ligne finit par se heurter au même dilemme : une requête arrive, et vous n’avez que quelques millisecondes pour décider du niveau de confiance à lui accorder. Le compte est peut-être parfaitement légitime. Ou il s’agit peut-être de la cinquième inscription en une minute depuis une IP louée dans un datacenter. À cet instant précis, le seul signal vraiment disponible est la connexion elle-même : l’adresse IP, le réseau derrière elle et l’usage habituel de ce réseau.

Guarda a été conçu pour transformer ce signal ténu en information exploitable. Nous analysons une adresse, classons le réseau auquel elle appartient, puis renvoyons un verdict accompagné des éléments qui le justifient.

Ce que renvoie concrètement une requête

Un seul appel à l’API vous fournit :

  • Type de connexion — résidentielle, opérateur mobile, entreprise ou hébergement/datacenter.
  • Indicateurs d’anonymisation — proxy, VPN, nœud de sortie TOR ou relais ouvert.
  • Identité réseau — ASN, nom de l’organisation et plage d’adresses concernée.
  • Géolocalisation — pays, région et ville, avec une précision importante : la donnée au niveau de la ville reste une estimation, pas une certitude.
  • Score de risque — une synthèse de 0–100 de tous ces signaux, pour définir un seuil unique plutôt que dix règles distinctes.

Le point essentiel, c’est que les preuves accompagnent toujours le score. Si une adresse est signalée, vous pouvez comprendre si c’est parce qu’elle appartient à un fournisseur cloud, parce qu’elle apparaît dans une liste de sorties TOR, ou parce que l’ASN d’hébergement est associé à des abus automatisés récurrents. Un score impossible à expliquer est un score que personne ne fera confiance en file de revue de production.

Classer plutôt que coller des étiquettes

Il y a un sujet sur lequel nous sommes particulièrement exigeants : qualifier un réseau pour ce qu’il est réellement. Un résolveur DNS Google ou une adresse Cloudflare n’est pas un VPN. C’est de l’infrastructure. Étiqueter tout trafic non résidentiel comme « VPN » est le moyen le plus rapide de perdre la confiance d’une équipe fraude : dès qu’un analyste vérifie une IP familière et voit un libellé manifestement faux, tous les autres verdicts deviennent suspects.

C’est pourquoi Guarda distingue clairement hébergement/datacenter, VPN commercial et proxy résidentiel. Dans la pratique, ces trois catégories ne portent pas le même niveau de risque et n’appellent pas les mêmes réponses.

Comment les équipes l’utilisent

Les cas d’usage que nous observons le plus souvent :

  • Protection à l’inscription. Évaluer le risque dès la création du compte ; envoyer les adresses à haut risque vers une vérification par e-mail ou téléphone plutôt que de bloquer immédiatement.
  • Risque paiement. Croiser le verdict IP avec un écart de pays de facturation et la vélocité carte. Une IP seule ne devrait jamais faire refuser un paiement, mais c’est un excellent critère d’arbitrage.
  • Contenus et licences. Détecter les sorties de VPN commerciaux lorsque les droits géographiques l’exigent réellement.
  • Qualité analytique. Retirer le trafic datacenter des rapports afin que vos taux de conversion décrivent des humains, pas des scripts.

Pensé pour le chemin critique

L’API repose sur un simple appel HTTP avec une clé : JSON en entrée, JSON en sortie. Les résultats sont mis en cache afin que les vérifications répétées d’une même adresse n’entraînent pas d’aller-retour inutile. Les recherches par lot sont également disponibles pour l’analyse de logs et les reprises d’historique. Et vous pouvez tester n’importe quelle adresse depuis la page d’accueil, sans compte, avant même d’écrire une ligne de code.

La suite sur ce blog

Nous voulons faire de ce blog une ressource concrète : comment fonctionnent réellement les signaux de détection, où ils atteignent leurs limites, ce que coûtent les faux positifs et comment construire des politiques capables de bloquer les abus sans pénaliser le client connecté au Wi-Fi d’un hôtel. Si vous souhaitez que nous abordions un sujet précis, dites-le-nous : c’est la référence que nous aurions aimé trouver lorsque nous avons commencé.

Bienvenue à bord.

Votre connexion