Plateforme

Le modèle d’isolation : un siège, une identité

La raison d’être d’une plateforme Android distant — au lieu de dix fenêtres d’émulateur sur un seul portable — c’est la séparation. Chez CloudPhoneHub, chaque cloud phone est un siège autonome : son propre espace utilisateur Android, son propre stockage, sa propre identité d’appareil et sa propre sortie réseau. Les sièges ne partagent pas de pool de fingerprints, et les sièges d’un client ne sont pas tirés en silence du même modèle d’identité que ceux d’un autre.

Cela compte surtout pour le multi-comptes. Les plateformes bannissent rarement un compte isolément — elles relient les comptes qui semblent partager le même appareil, la même installation ou le même réseau, puis agissent sur la grappe. Si cinq logins partagent des signaux d’identité au niveau de l’hôte, un seul challenge peut se propager à cinq. L’isolation par siège, c’est ce qui fait que chaque compte ressemble à son propre téléphone dans sa propre poche. Ce n’est pas un bouclier anti-ban — rien ne l’est — mais cela supprime le signal de liaison le plus évident et le moins cher que les clouds low-cost orientés densité laissent traîner.

Règle qu’on répète partout sur ce site : un compte, un siège, une persona proxy. La plateforme est conçue pour en faire le chemin facile, pas l’exception.

Apportez votre proxy, routé par appareil

L’identité réseau, c’est la moitié de la bataille : le support proxy est donc de première classe, pas une arrière-pensée. Vous attachez votre propre proxy par siège — mobile sticky ou résidentiel — et ce siège route exclusivement à travers lui. Pas de sortie partagée imposée, pas de pool mystère où votre compte hérite de la réputation d’inconnus qui utilisaient la même IP la semaine dernière.

• Routage par appareil — chaque cloud phone a sa propre sortie, définie avant le premier login pour que le compte naisse sur le réseau où il vivra.
• IP mobile de préférence — quand l’histoire du compte est « une personne en 4G », une sortie mobile sticky colle bien mieux qu’une IP datacenter.
• Résidentiel en repli — un résidentiel de qualité fonctionne quand le mobile n’est pas disponible pour la géographie visée.

On ne revend délibérément pas un pool proxy maison comme solution miracle. C’est vous qui contrôlez l’hygiène réseau, parce que vous connaissez la géographie et la tolérance au risque de vos comptes mieux qu’aucun réglage par défaut. Voyez la page Snapchat pour comprendre pourquoi c’est non négociable sur l’app sociale la plus difficile.

ADB et API REST : automatiser sans casser le fingerprint

Les opérateurs sérieux finissent par vouloir de l’automatisation — installs, sauvegardes, configuration scriptée, contrôles de santé. La plateforme expose l’accès ADB et une API REST pour piloter les sièges par programme, mais l’objectif de conception est que l’automatisation n’aplatisse pas tous les sièges en une seule et même machine.

Le piège de l’automatisation naïve, c’est qu’elle fait se comporter tous vos appareils de façon identique : même cadence, mêmes timings, mêmes actions, même ordre. Cette uniformité est elle-même un fingerprint. L’API sert à gérer l’inventaire et le provisionnement ; ce n’est pas un permis pour lancer un script au pas cadencé sur cinquante comptes chauffés. On oriente les gens vers ADB et l’API sur les tiers supérieurs précisément parce qu’on doit les mobiliser quand le process est mature — après la chauffe humaine, pas à sa place.

En pratique : utilisez l’API pour monter des sièges, attacher des proxies et suivre l’inventaire ; utilisez ADB pour les installs et la maintenance ; gardez humain ce qui doit avoir l’air humain. Une automatisation qui respecte le fingerprint est un avantage. Une automatisation qui l’ignore est une machine à bans lente.

Une identité d’appareil qui tient des semaines et des mois

Un cloud phone n’est utile que si le compte chauffé lundi est toujours sur le même appareil le mois suivant. L’identité du siège est conçue pour être stable au fil des reboots et sur de longs horizons — les caractéristiques d’appareil dont dépend un compte chauffé ne changent pas sous vos pieds à chaque redémarrage du siège.

C’est la propriété la plus sous-estimée quand les gens comparent les hosts. Un siège qui re-tire discrètement son identité ressemble, pour l’app, à un appareil flambant neuf qui se connecte à un compte établi — exactement le signal qui déclenche les boucles de vérification. La stabilité, c’est ce qui permet à un compte de vieillir gracieusement. La principale chose qui la casse, c’est vous : réinitialiser en usine un siège chauffé sans plan de recovery jette l’identité que vous avez mis des jours à bâtir. Traitez un siège chauffé comme une infra de production, pas comme une VM jetable.

Versions Android et specs par tier

Les ressources évoluent avec le plan : vous achetez le siège qui correspond à la charge, au lieu de surpayer un test ou de sous-dimensionner la production :

• Spark ($9) — le siège de test. Assez pour confirmer qu’une app s’installe et s’ouvre proprement, mener des expériences jetables et valider un proxy avant de vous engager. Ressources de classe partagée ; pas là où vous garez dix comptes chauffés.
• Creator ($19) — le siège social de production. Ressources dédiées pour le travail social quotidien, prêt pour le proxy, dimensionné pour un vrai compte que vous gardez ouvert et chaud.
• Studio ($34) — le siège de flotte. Ajoute de la marge et l’accès pour l’orchestration root/ADB/API quand votre automatisation est réelle et votre process éprouvé.

La version Android exacte et les specs par siège sont listées sur la page tarifs à côté de chaque tier — vérifiez là plutôt que de vous fier à un chiffre cité dans un blog. Le principe est simple : Spark pour le prouver, Creator pour l’exploiter, Studio pour le scaler.

Disponibilité 24/7 pour les sessions chaudes

Les émulateurs tournent tant que votre PC est allumé. Les cloud phones sont faits pour rester debout. Cette différence est tout l’enjeu du travail social : sessions chaudes, présence en arrière-plan, et la possibilité pour un coéquipier dans une autre ville de reprendre un siège sans que votre portable soit ouvert.

La disponibilité 24/7, c’est ce qui fait qu’un compte chauffé se comporte comme le téléphone toujours allumé d’une vraie personne, plutôt que comme un appareil qui n’existe que pendant vos heures de travail depuis un seul fuseau horaire. C’est aussi ce qui rend possible le passage de relais en agence : les sièges vivent dans la plateforme, pas sur le bureau de quelqu’un. On ne citera pas un pourcentage d’uptime qu’on ne peut pas tenir, mais l’intention de conception, ce sont des sièges durables et persistants que vous pouvez nommer, proxifier, auditer et transmettre. Explorez le modèle complet sur la page des appareils cloud.