Étude de cas7 min de lecture

Mettre à l’échelle l’inscription de comptes sur 50 profils : un vrai scénario par lot

Une équipe a combiné des données uniques par profil, la résolution automatique de CAPTCHA et des vérifications de reprise pour garder une exécution d’inscription sur 50 navigateurs cohérente du début à la fin.

8 mars 2026

Le Scénario

Une équipe devait enregistrer des comptes sur une plateforme dans 50 profils de navigateur antidétection. Chaque compte nécessitait une adresse e-mail unique, un nom, un numéro de téléphone et un mot de passe. Le flux d’inscription incluait une vérification par e-mail, un défi reCAPTCHA v2 et une étape d’intégration après l’inscription.

Faire cela manuellement aurait pris 3-4 heures. Avec Ornold MCP et un agent IA, l’ensemble du lot s’est terminé en moins de 25 minutes — y compris la résolution de CAPTCHA et la récupération d’erreurs.

Préparation : données par profil

La première étape consistait à préparer des données uniques pour chacun des 50 profils. Chaque champ requis par le formulaire d’inscription devait avoir une valeur distincte par session. Réutiliser les données entre les profils est le moyen le plus rapide d’être signalé.

L’équipe a préparé un ensemble de données avec :

Adresses e-mail uniques (une par profil, de différents fournisseurs)
Noms réalistes correspondant aux paramètres régionaux/langue du profil
Mots de passe forts (uniques par profil, non séquentiels)
Numéros de téléphone pour la vérification par SMS (d’un service de numéros virtuels)

La qualité des données est plus importante que la vitesse d’automatisation. Un e-mail en double ou un nom manifestement faux peut déclencher la détection de fraude et signaler l’ensemble du lot. Investissez du temps dans la création d’ensembles de données réalistes et diversifiés.

// Exemple de structure d’ensemble de données de profil
const profiles = [
  { email: "sarah.mitchell@proton.me", name: "Sarah Mitchell", phone: "+1-555-0142", password: "kR9#mPx2vL" },
  { email: "james.wong@tutanota.com", name: "James Wong", phone: "+1-555-0198", password: "nT4$hQw8bJ" },
  // ... 48 profils supplémentaires uniques
];

Phase 1 : lancement et navigation

Avec 50 sessions Linken Sphere prêtes (chacune avec son propre proxy, empreinte digitale et fuseau horaire), la première étape consistait à naviguer simultanément vers la page d’inscription.

// Démarrer toutes les sessions et naviguer vers la page d’inscription
await browser_list(); // Vérifier que 50 sessions sont disponibles
await browser_parallel_navigate({ url: "https://target.example/signup" });

// Attendre le chargement du formulaire dans toutes les sessions
await browser_parallel_wait_for({
  text: "Create your account",
  timeoutMs: 20000
});

48 sessions sur 50 ont chargé la page d’inscription en 8 secondes. Deux sessions étaient plus lentes en raison de la latence du proxy — la commande `wait_for` a attendu qu’elles rattrapent la marque de 14 secondes.

Phase 2 : remplissage du formulaire

Chaque session avait besoin de ses propres données uniques. La commande de remplissage parallèle d’Ornold accepte un tableau de valeurs qui correspond 1:1 aux sessions actives :

// Remplir l’e-mail — chaque session obtient une valeur unique
await browser_parallel_fill({
  ref: "email",
  values: profiles.map(p => p.email)
});

// Remplir le nom
await browser_parallel_fill({
  ref: "fullname",
  values: profiles.map(p => p.name)
});

// Remplir le mot de passe
await browser_parallel_fill({
  ref: "password",
  values: profiles.map(p => p.password)
});

Le remplissage du formulaire sur les 50 sessions a pris environ 3 secondes. Le mode d’interaction basé sur DOM (gratuit, sans crédits de vision) a géré les champs de formulaire structurés sans problème.

Phase 3 : résolution de CAPTCHA

La page d’inscription avait un défi reCAPTCHA v2. Ornold l’a détecté dans les 50 sessions et a envoyé des demandes de résolution en parallèle :

// Résoudre les CAPTCHA dans les 50 sessions
const captchaResult = await browser_solve_captcha();
// { total: 50, detected: 50, solved: 47, failed: 3 }

47 CAPTCHA sur 50 ont été résolus à la première tentative (15-35 secondes). Trois sessions ont échoué — le service de résolution a dépassé le délai d’attente. Au lieu de réessayer l’ensemble du lot, l’équipe a réessayé uniquement les sessions échouées :

// Réessayer les sessions échouées
const retryResult = await browser_solve_captcha();
// Cible uniquement les sessions qui ont encore des CAPTCHA non résolus
// { total: 3, detected: 3, solved: 3, failed: 0 }

La résolution de CAPTCHA est l’étape la plus lente dans la plupart des flux d’inscription. Résolvez après avoir rempli le formulaire (pas avant) pour minimiser le risque d’expiration du jeton.

Phase 4 : soumission et vérification

Avec les formulaires remplis et les CAPTCHA résolus, l’étape suivante consistait à cliquer sur le bouton de soumission et à vérifier que l’inscription a réussi :

// Soumettre le formulaire
await browser_parallel_click({ ref: "submit" });

// Attendre la page de succès
await browser_parallel_wait_for({
  text: "Check your email",
  timeoutMs: 15000
});

// Vérifier le statut
const status = await browser_status();

Résultats après la soumission :

46 sessions ont atteint la page de confirmation "Check your email"
2 sessions ont reçu un défi de sécurité secondaire (demande de vérification par téléphone)
1 session a reçu une erreur "too many requests"
1 session a dépassé le délai d’attente lors de la soumission

Phase 5 : récupération d’erreurs

Au lieu de redémarrer l’ensemble du lot, l’équipe a géré chaque type d’erreur séparément :

Vérification par téléphone (2 sessions)

Ces sessions avaient besoin d’une étape supplémentaire. L’agent IA a détecté le champ de saisie du téléphone, rempli les numéros virtuels de l’ensemble de données et soumis. Les deux sessions se sont terminées après la vérification par SMS.

Erreur de limite de débit (1 session)

L’erreur "too many requests" était liée au proxy — l’adresse IP avait été utilisée récemment. L’équipe a changé le proxy de la session et réessayé. L’inscription a réussi à la deuxième tentative.

Délai d’attente dépassé (1 session)

Un simple rechargement de la page et une nouvelle soumission ont résolu le problème. Les données du formulaire étaient toujours remplies (le navigateur les a conservées), donc seule l’action de soumission devait être répétée.

Résultat final : 50 comptes sur 50 enregistrés avec succès. Temps total de la première navigation à la dernière confirmation : 23 minutes.

Ce Qui L’a Rendu Possible

Plusieurs facteurs ont transformé cela d’un script fragile en une opération de lot fiable :

Données par profil — Chaque session avait des données uniques et réalistes. Pas de doublons, pas de motifs.
Exécution parallèle — Les 50 sessions ont traversé chaque phase ensemble, pas une à la fois.
Récupération sélective — Les erreurs ont été traitées par session, pas en redémarrant le lot. L’agent IA a identifié ce qui s’était mal passé et a appliqué la correction appropriée.
Vérifications d’état entre les phases — Les appels `browser_status()` et `wait_for` après chaque étape ont détecté les divergences tôt.
Logique de nouvelle tentative de CAPTCHA — Les résolutions échouées ont été réessayées individuellement au lieu de résoudre à nouveau l’ensemble du lot.

Ventilation du Temps

Lancement de session + navigation : ~15 secondes
Remplissage du formulaire (50 sessions) : ~3 secondes
Résolution de CAPTCHA (première passe) : ~35 secondes
Nouvelle tentative de CAPTCHA (3 sessions) : ~25 secondes
Soumission du formulaire + vérification : ~10 secondes
Récupération d’erreurs (4 sessions) : ~8 minutes
Total : ~23 minutes pour 50 comptes

Sans la phase de récupération d’erreurs, le chemin heureux pour 46 sessions se serait terminé en environ 2 minutes. La plupart du temps total a été consacré à la résolution de CAPTCHA et à la gestion des cas limites — ce qui est attendu à cette échelle.

Leçons pour une Mise à l’Échelle Supplémentaire

La qualité des données est le goulot d’étranglement, pas la vitesse d’automatisation. Consacrez plus de temps aux ensembles de données réalistes qu’à l’optimisation du temps de clic.
La qualité du proxy affecte directement le taux de réussite. Les proxys partagés bon marché entraînent des limites de débit et des blocages. Les proxys résidentiels ou mobiles fonctionnent considérablement mieux.
N’exécutez pas plus de sessions que votre machine ne peut en gérer. 50 instances Chromium nécessitent 16-24 Go de RAM. Surveillez l’utilisation des ressources et augmentez le matériel avant d’augmenter le nombre de sessions.
Intégrez la récupération au flux de travail dès le départ. Avec 50+ profils, certaines erreurs sont garanties. La question est de savoir si vous les gérez automatiquement ou manuellement.
Testez d’abord avec 5 profils. Validez l’ensemble du flux de bout en bout avant de passer à 50. Le débogage à grande échelle est exponentiellement plus difficile.
Échelonnez les gros lots. L’exécution de 100 profils à la fois à partir de la même plage d’adresses IP est un signal d’alarme. Divisez-les en groupes de 20-30 avec des délais entre eux.