Votre Mac loué n’est pas chez un hébergeur cloud, et pour les tests c’est un atout

Un prospect a posé deux questions raisonnables avant de s’inscrire. Où sont les machines, et l’IP sortante est-elle géolocalisée au même endroit ? La réponse honnête : elles sont dans un site privé dans le New Jersey, sur une fibre professionnelle, et pas chez un hébergeur cloud. Il y a quelques semaines, cela semblait demander une excuse. Ce n’est pas le cas.

Ce que disent les bases de données

Nous avons vérifié depuis une machine plutôt que de supposer. L’adresse sortante appartient à un fournisseur de fibre professionnelle. Le DNS inverse pointe vers le pool clients du fournisseur. Deux services de géolocalisation indépendants sont d’accord sur la classification.

isp:      Verizon Business
as:       AS701
hosting:  false
proxy:    false
mobile:   false

Ce dernier bloc est l’essentiel. Pour tout système qui note le trafic selon sa provenance, ce Mac ressemble à un bureau, parce que c’est ce qu’il est.

Pourquoi cela compte pour les tests

Les systèmes anti-bot et anti-fraude se méfient des plages d’adresses des hébergeurs, et ils ont raison. Les parcours d’inscription, les bacs à sable de paiement, la vérification publicitaire, les panels de sondage et les services sensibles à la géographie se comportent donc autrement quand la requête vient d’une IP cloud. Un test qui passe depuis le portable d’un développeur et échoue en CI, c’est très souvent cela et rien d’autre.

Le premier client à nous interroger là-dessus fait de la QA iOS. Ses tests parlent à des services de production qui traitent le trafic cloud différemment. Pour ce travail, un Mac sur une ligne professionnelle normale n’est pas un compromis. C’est l’exigence.

Vérifiez votre propre trafic sortant

Vous pouvez vérifier la classification de n’importe quelle machine en une minute, depuis la machine elle-même. Voici les commandes exactes que nous avons lancées.

# what address does the world see?
curl -s https://api.ipify.org

# how is it classified?
curl -s "http://ip-api.com/json/<that-address>?fields=isp,as,hosting,proxy,mobile"

# what does reverse DNS say about it?
dig +short -x <that-address>

Lancez les trois mêmes commandes depuis un runner de CI dans le cloud et comparez. Le drapeau hosting et la forme du DNS inverse suffisent en général à expliquer un test qui n’échoue qu’en CI.

Les limites, honnêtement

• Pas d’IPv4 publique fixe ni dédiée. L’adresse est attribuée par une fibre professionnelle et peut changer. Si vous avez besoin d’une adresse fixe dans une liste blanche, ce n’est pas le bon produit.
• Aucun port entrant. Vous joignez le Mac par un réseau Tailscale privé, ou par le bureau dans le navigateur. Rien n’est exposé sur internet.
• Un seul emplacement. Vous ne pouvez choisir ni la ville ni le pays.
• Uniquement des services aux développeurs. La politique d’utilisation acceptable couvre la CI, les builds, les tests et les outils de développement, y compris les agents de code, sur vos propres logiciels. Elle ne couvre pas le scraping à grande échelle ni le contournement des conditions d’un autre service. Une vraie adresse réseau n’est pas une invitation à essayer.

À quoi cela sert

• La QA face à de vrais services qui notent le trafic cloud différemment.
• Les simulateurs et appareils de test qui parlent aux API de production pendant la CI.
• Les pipelines de build d’apps dont les propres backends bloquent les plages cloud.
• Les agents de code qui consultent la documentation et se connectent aux outils de développement sans se heurter aux murs anti-bot.

Avant, nous décrivions l’emplacement avec prudence. Maintenant, nous le décrivons exactement. Pour les clients à qui il convient, l’exactitude est justement l’argument.