R2 - Service de proxys HTTP/HTTPS et coaching technique

1. Contexte

Avant et pendant le début de mon BTS, j'ai créé et géré une activité dans les services réseau : location de proxys HTTP/HTTPS à destination de resellers actifs sur le marché des produits en édition limitée (sneakers, drops streetwear, accessoires).

J'ai d'abord lancé l'activité en 2019 sous le nom Addict Proxies, puis je l'ai fait évoluer sous une autre structure (auto-entreprise FR) jusqu'au début 2024, où j'ai décidé d'arrêter pour me concentrer sur ma formation.

Sur l'ensemble de l'activité, le service a servi plus de 1000 clients cumulés, avec une infrastructure dimensionnée autour de 4 serveurs Linux, 16 sous-réseaux IPv4 en /24 (environ 4000 IPs), et un partenariat avec Oxylabs pour étendre l'offre aux IPs résidentielles. La communauté autour du service comptait plus de 4000 abonnés sur le réseau social principal, et l'infrastructure traitait plusieurs dizaines de checkouts par jour validés via les outils des clients.

C'est cette aventure qui m'a fait découvrir, dans le concret, ce que ça veut dire d'être prestataire IT à grande échelle : la conception technique évidemment, mais aussi tout ce qui va avec, relation client, support quotidien, facturation, conformité légale, gestion d'incidents en temps réel, et même la transmission de savoir-faire (cf. coaching technique plus bas).

2. Ce que je voulais réussir

Le service devait répondre à plusieurs objectifs en parallèle :

• Garantir des temps de réponse minimaux — sur des fenêtres de drops parfois de 10 minutes, quelques dizaines de millisecondes pouvaient faire la différence entre une requête validée et une requête perdue. Toutes les décisions techniques (multi-process Squid, choix du DC, sourcing d'IPs propres, rotation auto) ont été pilotées par cet objectif.
• Avoir une infrastructure proxy qui tient la route avec un volume client important (centaines de connexions simultanées, milliers de requêtes par minute en pic)
• Garantir une disponibilité élevée, mes clients me payaient un service qui devait fonctionner pour des fenêtres de drops souvent très courtes (parfois 10 minutes)
• Donner aux clients un dashboard où ils peuvent gérer eux-mêmes leurs accès
• Mettre en place un support réactif pour traiter les incidents en quelques minutes
• Respecter les obligations légales d'une auto-entreprise (CGU, mentions légales, RGPD)
• Garder les coûts d'infrastructure sous contrôle pour rester rentable malgré la concurrence

3. Comment je m'y suis pris

3.1 Choix des fournisseurs

J'ai construit l'offre autour de deux types d'IPs, chacun avec son fournisseur :

Pour les IPs datacenter (DC) : je suis allé chez Wolkee Cloud, un hébergeur allemand, pour les serveurs ; et chez Interlir pour les blocs IP en /24. Wolkee Cloud avait l'avantage d'être en contact direct avec les fournisseurs de blocs, ce qui permettait d'avoir les annonces BGP des nouveaux subnets beaucoup plus vite que via un hébergeur classique.

Sur une partie de l'infrastructure, j'ai aussi obtenu des IPs ISP annoncées sur datacenter qui passaient sur la bande passante de Deutsche Telekom (AS3320, l'un des meilleurs ASN d'Europe). Ces IPs offraient une qualité réseau « niveau pro » (moins de blacklists, latence plus stable) qui se rapprochait du résidentiel sans en avoir les coûts.

Pour les IPs résidentielles (ISP) : j'ai monté un partenariat avec Oxylabs, l'un des plus gros providers mondiaux de proxys résidentiels. L'idée était de proposer aux clients qui en avaient besoin une empreinte IP plus naturelle (mieux pour les sites où la détection de fingerprint réseau est forte), sans avoir à investir dans une infrastructure résidentielle propre.

Cette double offre m'a permis de couvrir des besoins très différents avec un seul service.

3.2 Côté serveurs

J'avais 4 serveurs Linux (Debian / Ubuntu Server), chacun avec 4 subnets /24. Sur chaque serveur, j'utilisais Squid comme proxy HTTP/HTTPS.

Pour exploiter les milliers d'IPs disponibles, j'ai collaboré avec un développeur externe qui a écrit pour moi un script bash sur mesure capable de :

• Configurer dynamiquement Squid pour qu'il écoute sur toutes les IPs du subnet
• Gérer les utilisateurs (création, suppression, gestion des quotas, attribution d'IPs)
• Gérer les sites (ajout, suppression, blocage par utilisateur ou par groupe)
• Recharger Squid sans couper le service après chaque modification
• Faire de l'auto-rotation des IPs blacklistées

Le script avait une interface en mode menu (50+ commandes) qui me faisait gagner un temps énorme au quotidien. La gestion de cette collaboration externe, cahier des charges, retours, évolutions, était une mini-prestation projet en soi.

Pour l'authentification, j'utilisais le système basic de Squid (auth_param basic) avec un couple utilisateur / mot de passe par client. Comme ça je pouvais voir qui consommait quoi, et bloquer un compte rapidement si quelqu'un dépassait son quota ou ne payait pas.

3.3 Capacity planning

Côté serveur, rien n'était figé : la charge CPU, la RAM et la bande passante variaient fortement selon le volume de commandes mensuel des clients. Un mois de drops importants pouvait représenter 5 à 10 fois la charge d'un mois calme.

Le défi : dimensionner l'infrastructure en continu sans sous-dimensionner (incidents en pic, perte de clients) ni surdimensionner (rentabilité dégradée). Concrètement :

• Suivi mensuel de la charge CPU moyenne et pic, du taux d'utilisation bande passante, et des temps de réponse moyens
• Ajustement du nombre de process Squid en parallèle selon la charge réelle
• Mutualisation entre serveurs : nouveaux clients attribués au serveur le moins chargé
• Dimensionnement RAM/CPU ajusté à chaque renouvellement hébergeur selon la trajectoire

C'est sur cette partie que j'ai le plus appris à raisonner en coûts ET en performances, pas juste en « est-ce que ça marche ».

3.4 Le dashboard client

Plutôt que de coder mon propre dashboard, j'ai utilisé un service externe spécialisé prêt à l'emploi que je branchais à mon infrastructure via API. Cela permettait de :

• Créer et gérer les comptes clients
• Générer automatiquement les identifiants Squid
• Suivre la consommation en temps réel
• Gérer le stock de proxys (que je rechargeais manuellement quand j'ajoutais des IPs)
• Donner des stats d'utilisation au client comme à moi

Pour la connexion au dashboard, j'ai mis du OAuth Discord parce que toute la communication et le support du service passaient par un serveur Discord communautaire de plus de 4000 membres. Comme ça l'utilisateur n'avait pas à créer un nouveau compte, il se connectait avec son Discord qu'il avait déjà, friction d'inscription en moins.

3.5 Les paiements

J'ai eu plusieurs systèmes de paiement, chacun pour de bonnes raisons :

• Au début PayPal, parce que c'est simple et que tout le monde a un compte
• Puis je suis passé sur Stripe parce que sur PayPal j'avais trop de litiges et de chargebacks qui dégradaient mon score vendeur
• En parallèle j'ai ajouté le paiement en cryptomonnaies (BTC, ETH, USDT) : une partie des clients le préférait, c'est rapide et il n'y a pas de chargebacks

Ça m'a permis de ne pas dépendre d'un seul moyen de paiement, quand l'un avait un problème, les autres tournaient.

3.6 Le coaching technique

À côté du service de proxys, j'ai aussi vendu un service de coaching pour des clients qui voulaient apprendre à monter leur propre infrastructure proxy. C'était une offre premium qui incluait :

• Sessions individuelles à distance
• Transmission complète du savoir-faire (approvisionnement en IPs, config Squid, scripts, monitoring)
• Accompagnement sur plusieurs mois après l'achat
• Support prioritaire et réponses aux questions techniques quel que soit leur niveau

Cette partie coaching m'a appris à structurer pédagogiquement ce que je savais faire à l'instinct. Et c'est là que j'ai eu mes meilleurs retours clients.

3.7 L'aspect légal

Comme j'étais en auto-entreprise déclarée, j'ai dû mettre tout en règle :

• Mentions légales complètes accessibles sur le site
• CGU précisant les usages autorisés et interdits
• Politique de confidentialité conforme RGPD (collecte minimale, droit d'accès, suppression sur demande)
• Comptabilité de l'activité (URSSAF, déclarations trimestrielles)

C'est tout sauf glamour mais ça fait partie du métier de prestataire.

3.8 Le support client

Je faisais le support de niveau 1 et 2 moi-même via Discord, avec des temps de réponse en général très courts :

• Diagnostic des problèmes (proxy qui ne répond pas, IP blacklistée par certaines plateformes, lenteurs)
• Reproduction du problème côté serveur (logs Squid, tests de connectivité)
• Remplacement des IPs blacklistées par d'autres du pool
• Communications proactives aux clients lors d'une maintenance ou d'un incident global

C'est cette partie qui m'a le plus appris, car les clients étaient impatients (souvent avec des fenêtres de drops de 10 minutes) et qu'on n'avait pas droit à l'erreur.

4. Ce que j'ai produit

• Une infrastructure de 4 serveurs Linux et 16 subnets /24 (~4000 IPs DC) + accès résidentiel via Oxylabs
• Un script bash sur mesure (50+ commandes) développé en collaboration avec un développeur externe
• Des configurations Squid automatisées avec authentification basic
• L'intégration du dashboard externe via API
• Un site vitrine avec mentions légales, CGU et politique RGPD
• Un serveur Discord communautaire de 4000+ membres pour le support et la communication
• Un service de coaching structuré avec parcours client documenté
• Des procédures de support documentées (diagnostic, remplacement d'IPs, gestion d'incidents)
• Un suivi comptable (URSSAF, tableaux financiers)

5. Résultats

• Plus de 1000 clients servis sur l'ensemble de l'activité
• 4000+ membres dans la communauté Discord du service
• Plusieurs dizaines de checkouts par jour validés via l'infrastructure
• ~5 ans d'activité continue (2019 → début 2024) entre les deux structures
• Subnets stables sur 6+ mois sans ban sur les sites majeurs (témoignage client)
• 3 systèmes de paiement opérationnels en parallèle (PayPal puis Stripe + crypto)
• Activité rentable couvrant les coûts d'infrastructure et de bande passante
• Arrêt propre au début de mon BTS, avec préavis aux clients

Quelques retours clients (anonymisés)

"Si je devais noter le script, je n'ai pas de mots. Il m'a aidé à améliorer drastiquement la performance et la vitesse des proxys, il est très simple à utiliser et ses nouvelles features sont très utiles. Autre avantage : Enzo est toujours très content de t'aider, de tout t'apprendre et de répondre à toutes les questions. Tu ne seras pas déçu, tu es entre de bonnes mains, ça vaut chaque centime."

"Plus de 4 mois depuis que j'ai acheté le coaching et je dois dire que je ne regrette pas un centime. Approche professionnelle, aide sur absolument tout, conseils qu'on n'a aucune chance de trouver ailleurs dans la vie. Tu peux poser une question aussi bête que tu veux, Enzo ne te juge pas et est toujours content de répondre. Les proxys fonctionnent absolument propres, honnêtement je suis surpris."

"Le serveur tourne depuis quelques mois maintenant et les proxys performent bien. Contrairement à d'autres, j'ai eu quelques downtimes mineurs. Mais quand j'ai demandé à d'autres clients coachés s'ils savaient comment fixer, ils me disaient 'jamais eu de problèmes'. Tant mieux pour eux ! Mais ce qui est bien pour tout le monde ? Enzo commence le troubleshooting et le fix tout de suite. Les erreurs arrivent, mais l'attitude face à la résolution peut varier, et là je suis content d'avoir Enzo et son attitude. Toujours friendly et helpful."

"6,5 mois plus tard… et mon subnet est toujours unbanned sur tous les sites importants, il fait 0 problème et 100% d'uptime tout ce temps. Ne m'a jamais laissé tomber et je l'utilise sur tous les sites."

6. Compétences du bloc 1 mises en œuvre

6 bis. Compétences E6 SISR mises en œuvre

7. Bilan personnel

Cette aventure a été le terrain où j'ai vraiment appris le métier de prestataire IT.

Côté technique, j'ai monté et fait tourner une vraie infrastructure réseau, avec plus de 1000 clients sur la durée, et des contraintes de disponibilité et de performance bien réelles (drops de 10 minutes, pas droit à l'erreur). Chaque incident me coûtait en réputation et en clients, donc chaque incident m'a appris quelque chose.

Côté professionnel, j'ai découvert toute la partie non-technique du métier : relations fournisseurs (Wolkee Cloud, Interlir, Oxylabs), gestion d'un développeur externe, support client à grande échelle, facturation multi-canal, gestion des litiges, conformité réglementaire. C'est cette dimension globale qui me passionne et qui motive mon envie de relancer une activité IT après le BTS.

Côté humain, le coaching que j'ai donné en parallèle du service m'a appris autre chose : structurer ce qu'on sait, l'expliquer simplement, accompagner sur la durée. Mes meilleurs retours clients viennent de cette partie. Savoir vulgariser sans jamais juger les questions s'est avéré être un vrai différenciateur.

Difficultés rencontrées et résolues

• Litiges PayPal et chargebacks, solution : passage à Stripe et ajout de la crypto pour ne pas dépendre d'un seul système
• IPs blacklistées rapidement par certaines plateformes, solution : rotation automatique côté script, partenariat Oxylabs pour les usages où le résidentiel est nécessaire
• Suivi des consommations clients à l'échelle de 1000+, solution : adoption d'un dashboard externe spécialisé plutôt qu'un développement interne
• Charge de support en pic, solution : structuration d'un serveur Discord communautaire où les clients pouvaient s'entraider et où la documentation était centralisée

Ce que je referais autrement

• Centraliser plus tôt le monitoring (Zabbix ou Prometheus + Grafana). À l'époque je faisais des checks ciblés sur les logs Squid et j'avais déployé plusieurs process Squid en parallèle pour répartir la charge — efficace mais réactif. Un monitoring centralisé m'aurait permis d'anticiper les incidents au lieu de les subir.
• Documenter plus tôt les procédures pour faciliter une éventuelle délégation (le coaching m'a montré à quel point la documentation structurée fait gagner du temps)
• Diversifier les paiements dès le début au lieu d'attendre les premiers litiges PayPal

Pourquoi cette expérience compte pour le BTS, j'ai mobilisé en autonomie l'intégralité des compétences du bloc 1 dans un contexte où les conséquences d'une erreur étaient immédiates et mesurables, et à une échelle (1000+ clients, 4000+ communauté) qui dépasse ce qu'on rencontre en stage classique. Le BTS m'apporte aujourd'hui le cadre théorique et méthodologique (référentiels, normes, ITIL, démarche projet structurée) qui me manquait à l'époque pour faire les choses proprement dès le départ.