API de recherche IP en masse : architecture et limites
Une API de recherche IP en masse permet de résoudre de nombreuses adresses en une seule requête au lieu d'un appel par adresse, et l'architecture qui l'entoure se résume à trois contraintes : la taille maximale d'un lot, le budget de requêtes que vous pouvez dépenser, et votre capacité à éviter de poser deux fois la même question. Cet article décrit une conception pratique, en s'appuyant sur le point de terminaison bulk d'ipto pour les chiffres concrets.
Ce qu'accepte le point de terminaison de recherche IP en masse
La recherche en masse d'ipto est un POST vers /v1/ip/bulk avec un tableau JSON de chaînes IP. La requête accepte jusqu'à 100 adresses, les doublons sont supprimés avant le traitement, et la réponse est un objet indexé par adresse IP, chaque entrée ayant la forme d'un résultat de recherche unitaire avec le pays, la ville, l'ASN, l'organisation et les champs is_vpn, is_tor, is_abuser, is_datacenter et bogon. Le mode bulk est une fonctionnalité des offres payantes, disponible en Pro et Enterprise, tandis que l'offre Free couvre les recherches unitaires à 1 000 requêtes par jour sans inscription. Consultez la documentation de l'API pour le format de requête actuel.
Le point de comptabilité important est que le bulk est facturé par élément. Un lot de 100 adresses compte pour 100 sur votre budget quotidien, exactement comme 100 recherches individuelles. Le regroupement n'étire donc pas votre quota. Ce qu'il économise, ce sont les allers-retours, l'établissement de connexions et l'orchestration côté client, qui constituent souvent le vrai goulot d'étranglement lorsque vous enrichissez un fichier de logs ou une liste de clients.
Concevoir le pipeline autour du budget
Comme chaque adresse consomme du budget, la requête la moins chère est celle que vous n'envoyez jamais. Commencez par filtrer. Les adresses privées et réservées n'auront jamais de géolocalisation significative, et vous pouvez les écarter localement ou les classer avec le vérificateur d'IP bogon avant qu'elles ne coûtent quoi que ce soit. Dédoublonnez l'ensemble restant, car les logs de production sont dominés par un petit nombre de visiteurs récurrents, de robots d'exploration et de passerelles NAT. Un ensemble de hachage placé devant le constructeur de lots est généralement la modification au meilleur rendement.
Ajoutez ensuite un cache indexé par adresse, avec une durée de vie adaptée à la vitesse d'évolution des données qui vous intéressent. Les correspondances pays et ASN sont stables pendant de longues périodes : des jours sont donc raisonnables. Les indicateurs de réputation changent plus vite, puisque les flux de menaces d'ipto sont actualisés toutes les 6 heures et ses jeux de données IP et ASN quotidiennement ; mettre un verdict en cache plus de quelques heures ajoute de l'obsolescence sans beaucoup économiser. Si possible, gardez des TTL distincts par champ, ou mettez tout le résultat en cache au TTL le plus court.
- Filtrez localement les adresses bogon et les entrées manifestement invalides.
- Dédoublonnez au sein du traitement et par rapport au cache.
- Découpez les adresses restantes en groupes d'au plus 100.
- Envoyez les lots avec une concurrence bornée plutôt que tous à la fois.
- Écrivez les résultats dans le cache et dans le magasin de destination, indexés par adresse.
Concurrence, backoff et fenêtre quotidienne
Un budget quotidien est une fenêtre fixe : le mode de défaillance à prévoir est donc son épuisement en cours de traitement. Estimez le coût avant de commencer : le nombre d'adresses uniques et non bogon correspond au nombre de requêtes que le traitement dépensera. S'il dépasse ce qu'il reste pour aujourd'hui, répartissez le traitement sur plusieurs fenêtres, priorisez d'abord les adresses les plus précieuses, ou ne recourez aux recherches unitaires que pour les plus risquées. Conservez la progression afin qu'un traitement relancé reprenne au dernier lot terminé plutôt qu'au début.
Utilisez une concurrence modeste. Quelques lots en parallèle suffisent presque toujours, puisque chaque lot porte déjà 100 recherches, et un éclatement non borné ne fait que rendre les défaillances plus difficiles à analyser. En cas d'erreur transitoire ou de réponse de dépassement de budget, réessayez avec un backoff exponentiel et du jitter, et considérez un budget épuisé comme un signal pour s'arrêter et reprendre plus tard, non comme quelque chose à retenter en boucle serrée. Rendez chaque écriture idempotente afin qu'un lot rejoué ne puisse pas insérer deux fois les lignes.
Choisir entre bulk et recherches unitaires
Pour les chemins en temps réel, comme un formulaire d'inscription ou un paiement, utilisez une recherche unitaire par événement. La latence est faible, le cache absorbe les répétitions et vous ne dépensez du budget que pour les adresses qui arrivent réellement. Le bulk sert au travail hors ligne : rattraper une table, noter une journée de logs ou auditer une liste d'autorisation. Si votre objectif est la notation du risque plutôt que l'enrichissement brut, le vérificateur de score de fraude combine les signaux d'IP, d'e-mail, de téléphone et de User-Agent en un seul score de 0 à 100, ce qui peut remplacer plusieurs appels distincts. Pour une comparaison plus longue des limites des offres gratuites entre fournisseurs, voir notre comparatif des limites des offres gratuites.
Enfin, journalisez votre propre consommation. Suivez les requêtes dépensées par traitement, le taux de succès du cache et la part d'adresses écartées comme bogon ou doublons. Ces trois chiffres vous disent si l'architecture fonctionne bien avant qu'une alarme de budget ne le fasse.
Avant de scripter un gros lot, essayez à la main quelques adresses : la recherche ASN indique quel réseau possède une plage que vous voyez sans cesse dans vos logs, ce qui permet souvent de traiter tout un réseau par une seule décision au lieu de milliers de recherches unitaires.