Commander un canal proxy à la main depuis l'espace client fonctionne tant que vous gérez une dizaine de canaux. Dès que le parc se chiffre en centaines et que le renouvellement doit suivre la consommation du budget, le mode manuel atteint ses limites, et c'est là que l'API entre en jeu. Voyons le cycle type d'attribution et de renouvellement d'un canal, la différence entre une adresse dédiée et un forfait de trafic, ainsi que la marche à suivre lorsqu'il n'y a plus de stock dans le pays voulu.
Cycle type : du catalogue au renouvellement
Le travail avec l'API proxy suit le même schéma quel que soit le type de canal. On commence par interroger le catalogue : la liste des types disponibles, des pays et des prix actuels, qui montre ce qui est réellement en stock avant de passer commande. Vient ensuite la commande d'un canal précis, avec son type et son pays ; en réponse, l'API renvoie les identifiants de connexion (adresse, port, identifiant et mot de passe), que vous pouvez insérer immédiatement dans votre processus de travail. Tant que le canal est actif, son état se suit par une requête distincte : le trafic restant pour les forfaits, ou la date d'expiration pour une adresse dédiée. Le cycle se termine par le renouvellement si la ressource est encore nécessaire, ou par la résiliation du canal si la tâche est terminée et qu'il n'y a aucun intérêt à payer pour rien.
Adresse dédiée ou forfait de gigaoctets
Une adresse dédiée de centre de données ou ISP est facturée au mois : vous payez un prix fixe pour une durée donnée, l'adresse vous reste attribuée pendant toute la période payée, et le renouvellement n'est qu'un nouveau paiement pour une nouvelle durée. Les canaux résidentiels et mobiles fonctionnent autrement : la facturation se fait au gigaoctet, et l'adresse elle-même est attribuée par session. À chaque nouvelle requête, ou à l'expiration de la session, le système peut fournir une autre IP du pool. Cette différence compte dès l'intégration : un code qui conserve la même adresse dans une variable pendant tout le script ne fonctionne plus sur les canaux à session et doit redemander une adresse pour chaque nouvelle session. Pour une analyse détaillée des cas où l'un des types est plus avantageux que l'autre, consultez l'article proxys mobiles ou résidentiels.
Comment interroger la consommation de trafic sans surcharge
La consommation de trafic des canaux au forfait ne change pas instantanément après chaque requête : les données se synchronisent avec un certain retard, et interroger le point d'accès de consommation chaque seconde ne donne pas de chiffres plus récents, cela ne fait qu'épuiser la limite de requêtes. Une pratique raisonnable consiste à vérifier le solde de trafic toutes les quelques minutes, ou à lier la vérification à la fin d'un gros lot de tâches plutôt qu'à chaque requête passant par le proxy. Le même principe d'intervalle raisonnable s'applique à d'autres parties du catalogue, par exemple lors de la configuration de la rotation d'IP par API : des interrogations fréquentes n'accélèrent pas le résultat, elles consomment simplement la limite.
Lorsqu'il n'y a pas de stock dans le pays voulu
Le catalogue renvoie explicitement un statut d'absence de stock pour un pays et un type de canal donnés, et non un délai d'attente dépassé ou une erreur générique : vous pouvez ainsi traiter la situation dans le code plutôt que de deviner ce qui s'est passé. Trois options sont possibles : attendre et renouveler la requête plus tard si le pool est réapprovisionné régulièrement ; passer à un pays voisin de la même région si la géolocalisation n'est pas critique ; ou demander au support, par un ticket, les délais de réapprovisionnement prévus pour la destination concernée. Ne prévoir dans l'automatisation que le scénario nominal, sans gérer l'absence de stock, est une cause fréquente de plantage du script en production, au lieu d'un basculement propre vers une solution de repli.
Stockage et rotation des identifiants attribués
Les identifiants de connexion (adresse, port, identifiant et mot de passe) doivent être conservés comme n'importe quel secret : dans des variables d'environnement ou un gestionnaire de secrets, et non dans le code du script. Le fournisseur ne modifie pas automatiquement en arrière-plan l'identifiant et le mot de passe d'un canal ; la rotation relève donc du client : en cas de soupçon de fuite des identifiants, il vaut mieux commander de nouveau le canal que d'essayer de changer le mot de passe d'une ressource déjà attribuée. La liste complète des canaux actifs, leur statut et leurs identifiants se vérifie facilement dans l'espace client, où vous voyez aussi quelles ressources arrivent bientôt à expiration et doivent être renouvelées.
Questions fréquentes
Peut-on obtenir les identifiants immédiatement après la commande, sans attendre ?
Oui, l'API renvoie les identifiants de connexion de façon synchrone dans la réponse à la requête de commande : pour les proxys, il n'existe pas d'étape d'activation distincte nécessitant une interrogation, contrairement aux activations par e-mail, où il faut attendre l'arrivée du message.
Que devient un canal s'il n'est pas renouvelé à temps ?
Une adresse dédiée est libérée à l'expiration de la durée payée et peut être attribuée à un autre client ; mieux vaut donc planifier le renouvellement à l'avance. Les canaux au forfait cessent simplement de répondre lorsque le trafic est épuisé ou que la période de facturation se termine, sans pénalité ni blocage du compte.
Faut-il informer l'API de la résiliation d'un canal, ou suffit-il de ne plus l'utiliser ?
Il vaut mieux appeler explicitement la résiliation du canal via l'API : cela libère la ressource immédiatement, et non à l'expiration de la durée, et cela arrête la facturation si le tarif prévoit un renouvellement automatique.
La description complète des méthodes de commande, de renouvellement et de suivi se trouve dans la documentation technique de l'API. Les types et pays actuellement disponibles figurent dans la rubrique proxys.