Si vous intégrez un réseau de proxies dans un pipeline de production, quelqu’un des achats ou de l’ingénierie plateforme finira par demander quel est le SLA. C’est la bonne question à poser, et les réponses obtenues sont généralement moins informatives qu’il n’y paraît, car un chiffre comme 99,9% ne veut rien dire tant qu’on ne sait pas sur quoi il est mesuré, sur quelle période, et ce qui se passe en cas de non-respect.
Il existe aussi un piège spécifique dans cette catégorie. Un SLA de proxy promet que la passerelle est accessible. Il ne promet pas que les sites depuis lesquels vous collectez laisseront passer vos requêtes, et ce sont deux choses très différentes. Comprendre cette frontière constitue l’essentiel de ce qu’il faut savoir avant de signer quoi que ce soit.
Ce que signifie réellement un chiffre de disponibilité
Trois variables se cachent derrière chaque pourcentage, et un fournisseur qui ne donne que le pourcentage vous a fourni la partie la moins utile.
La première est la fenêtre de mesure. Un SLA mensuel de 99,9% autorise environ 43 minutes d’indisponibilité par mois. Le même 99,9% mesuré annuellement autorise environ 8 heures 45 minutes, et permet que ces heures soient consécutives. Le mensuel est nettement plus strict, et un fournisseur qui cite un chiffre annuel formule une promesse plus faible dans un langage identique.
La deuxième est la définition de l’indisponibilité. Le service est-il considéré comme indisponible uniquement quand la passerelle refuse les connexions, ou aussi quand elle répond techniquement mais que le taux d’erreur a explosé, ou que la latence s’est dégradée au point d’être inutilisable? De nombreux SLA ne comptabilisent que l’indisponibilité complète, ce qui signifie qu’une période où chaque requête renvoie une erreur alors que le point d’accès accepte toujours les connexions peut ne pas être comptée comme de l’indisponibilité du tout.
La troisième est qui mesure. Si le fournisseur est la seule source de vérité et ne publie aucun enregistrement indépendant, le chiffre est autodéclaré. Une page de statut publique avec un historique des incidents est ce qui rend le chiffre vérifiable.
La distinction la plus importante : la disponibilité de la passerelle n’est pas le taux de succès
C’est le point qui piège les équipes, et il vaut la peine d’être direct à ce sujet.
Un SLA de disponibilité couvre l’infrastructure du fournisseur : la passerelle accepte votre connexion, vous authentifie, et achemine votre requête. C’est ce qu’il contrôle et c’est ce qu’il promet.
Ce qu’il ne couvre pas, c’est si le site cible accepte la requête. Si un site bloque l’adresse de sortie, sert une page de challenge, ou renvoie un résultat vide, ce n’est pas de l’indisponibilité. Le proxy a fait son travail. Votre collecte a quand même échoué. Aucun fournisseur de proxy ne peut promettre un taux de succès contre des sites tiers, parce que ce sont les sites qui décident, ils changent leurs défenses sans préavis, et le même pool qui passe une cible un lundi peut peiner un vendredi. Tout fournisseur qui garantit un taux de succès sur des cibles arbitraires promet quelque chose qui échappe à son contrôle.
La conséquence pratique pour les achats est donc que le SLA vous protège contre une panne côté fournisseur, et que votre propre surveillance vous protège contre tout le reste. Vous avez besoin des deux, et confondre les deux mène à des équipes contractuellement couvertes mais opérationnellement aveugles. C’est à cela que sert la surveillance de votre pipeline, en mesurant le taux de succès validé par cible et par région plutôt qu’en supposant que le SLA le couvre, et c’est pourquoi détecter le contenu bloqué ou factice compte : une page de challenge renvoyée avec un code 200 est à la fois une réponse conforme au SLA et un échec de données.
Les crédits de service, et ce qu’ils valent vraiment
Quand un SLA n’est pas respecté, le recours standard est un crédit de service, généralement un pourcentage des frais mensuels proportionnel à l’ampleur du manquement, appliqué à une facture future.
Il faut être lucide sur son ampleur. Un crédit est calculé sur ce que vous avez payé au fournisseur, pas sur ce que la panne vous a coûté. Si une panne de passerelle de quatre heures bloque un flux de prix qui pilote vos propres décisions commerciales, le crédit ne représentera qu’une petite fraction d’une facture mensuelle de proxy, et l’impact commercial sera pour vous. Les crédits sont un mécanisme de responsabilisation et un signal que le fournisseur prend l’engagement au sérieux ; ils ne sont pas une assurance.
Deux détails mécaniques valent la peine d’être vérifiés. Les crédits ne sont généralement pas automatiques : de nombreux contrats exigent que vous en fassiez la demande dans un délai, souvent 30 jours, avec vos propres preuves. Et les crédits sont typiquement plafonnés à un certain pourcentage des frais mensuels. Les deux sont normaux, mais vous devez les connaître avant d’en avoir besoin.
Les exclusions à lire attentivement
La section des exclusions est l’endroit où un SLA est réellement défini. Les exclusions standard et raisonnables incluent la maintenance planifiée annoncée à l’avance, la force majeure, et les défaillances de réseaux que le fournisseur n’exploite pas. Soyez attentif à ceci :
La maintenance planifiée sans plafond ni délai de préavis, qui permet effectivement au fournisseur d’exclure toute indisponibilité qu’il déclare à l’avance. Les exclusions pour « mauvaise configuration du client » qui sont assez larges pour couvrir un usage ordinaire. Les exclusions liées aux tiers rédigées de façon si large que les problèmes de réseau en amont, qui sont l’essentiel de ce qui casse réellement, tombent hors de la promesse. Et les exclusions pour la dégradation par opposition à l’indisponibilité, qui est la façon dont un service lent mais vivant évite d’être comptabilisé.
Vérifiez aussi si le SLA couvre les composants dont vous dépendez réellement. Une entreprise de proxy en a plusieurs : la passerelle, le panneau et l’authentification, la facturation, et d’éventuelles API. Un SLA qui couvre la passerelle mais exclut l’authentification n’offre pas grande protection, puisque vous ne pouvez pas utiliser une passerelle accessible à laquelle vous ne pouvez pas vous authentifier.
Comment vérifier une affirmation avant de signer
Un SLA est une promesse sur l’avenir ; ce qui est vérifiable, ce sont le présent et le passé.
Commencez par la page de statut. Le statut en temps réel et, plus important encore, un historique public des incidents vous indiquent à quelle fréquence les choses se cassent, à quelle vitesse elles sont reconnues, et si les analyses post-mortem sont honnêtes. Un fournisseur sans page de statut publique vous demande de croire sur parole à la disponibilité. Shifter en publie une sur status.shifter.io avec la passerelle, les IP ISP, les API, le panneau et l’authentification, et la facturation suivis comme des sous-services distincts, ce qui offre la granularité souhaitable puisqu’elle permet de voir quel composant a échoué.
Ensuite, mesurez-le vous-même pendant l’évaluation. Effectuez une vérification de disponibilité à basse fréquence sur la passerelle depuis votre propre infrastructure pendant une période d’essai, et vous aurez un enregistrement indépendant plutôt qu’un chiffre marketing. Combinez cela avec un vrai test de taux de succès sur vos cibles réelles, comme dans tester la vitesse, le taux de succès et la précision de localisation, et vous connaîtrez les deux chiffres : si le service est disponible, et s’il fonctionne pour vous.
Enfin, examinez les délais de réponse du support, car en pratique ils comptent plus que le crédit. Quand quelque chose casse à 02:00, ce qui détermine votre rétablissement, c’est la rapidité avec laquelle un humain répond, pas le pourcentage qui apparaîtra sur la facture du mois prochain.
Ce que Shifter publie
Pour référence, les niveaux publiés sont : les meilleurs efforts du niveau Starter à Growth, généralement 99,5% ou mieux ; 99,9% de disponibilité mensuelle du niveau Business à Pro sans mécanisme de crédit formel ; et 99,9% sur Enterprise avec des crédits de service selon le contrat signé, calculés sur les dépenses mensuelles et payés sous forme de crédit de compte sur la prochaine facture. Les délais de réponse du support sont échelonnés de la même manière, allant du chat au meilleur effort sur les plans d’entrée jusqu’à un canal dédié et un gestionnaire de compte nommé sur Enterprise. Les détails se trouvent dans la documentation sur le support et le SLA.
La raison d’énoncer cela clairement est que l’échelonnement est normal dans ce secteur et mérite d’être compris : un SLA formel adossé à des crédits est généralement une fonctionnalité de contrat entreprise, et si votre processus d’achat en exige un, c’est la conversation à avoir en amont plutôt que de supposer qu’un plan en libre-service l’inclut.
Les questions à poser lors des achats
Demandez la fenêtre de mesure et si elle est mensuelle ou annuelle. Demandez la définition de l’indisponibilité, en particulier si des taux d’erreur élevés ou une latence dégradée comptent. Demandez quels composants le SLA couvre, passerelle, authentification, panneau, API, et s’ils sont mesurés séparément. Demandez si les crédits sont automatiques ou soumis à demande, quel est le délai de demande, et quel est le plafond. Demandez l’historique des incidents des douze derniers mois. Demandez quel est l’engagement de délai de réponse du support pour un incident de production en panne, et par quel canal. Et demandez ce qui est explicitement exclu.
Un fournisseur à l’aise pour répondre par écrit à tout cela vous dit quelque chose d’utile, indépendamment du chiffre lui-même.
En résumé
Traitez le pourcentage comme la partie la moins informative d’un SLA. La fenêtre, la définition de l’indisponibilité, les composants couverts, et les exclusions sont ce qui détermine si la promesse a un sens, et les crédits de service relèvent de la responsabilisation plutôt que d’une compensation pour vos pertes. Plus important encore, souvenez-vous de la frontière : un SLA de disponibilité couvre la disponibilité de la passerelle, jamais si des cibles tierces acceptent votre trafic, donc vous avez toujours besoin de votre propre surveillance du taux de succès pour savoir si votre collecte fonctionne réellement. Vérifiez avec un historique public des incidents et vos propres mesures pendant un essai, et pesez la réactivité du support au moins autant que le chiffre lui-même.
Si vous évaluez sur cette base, les choix au niveau des plans sont couverts dans choisir le bon plan de proxy résidentiel, et les critères au niveau du fournisseur dans comment choisir un réseau de proxy. Le service lui-même est celui des proxies résidentiels, avec des niveaux et une tarification par GB qui s’échelonnent du libre-service jusqu’aux conditions Enterprise contractuelles.