Ingénierie10 min de lecture

Exécuter des dizaines de navigateurs antidetect en parallèle sans perdre la synchronisation

Nous détaillons l’analyse visuelle groupée, la récupération d’état et les contrôles de concurrence qui permettent à de gros lots de navigateurs d’avancer comme un seul système.

1 avr. 2026

Le défi de l’automatisation parallèle des navigateurs

Exécuter un navigateur est simple. Exécuter 50 navigateurs faisant la même chose simultanément est un problème complètement différent. Les pages se chargent à des vitesses différentes, les CAPTCHA apparaissent dans certaines sessions mais pas dans d’autres, et les conditions réseau varient entre les profils. Sans coordination, un lot parallèle devient rapidement 50 scripts indépendants qui divergent.

Ornold traite un lot de navigateurs comme un système unique coordonné. Chaque action — navigation, remplissage de formulaires, clics, résolution de CAPTCHA — s’exécute dans toutes les sessions actives simultanément, avec gestion intégrée des divergences et des défaillances.

Comment fonctionne l’exécution parallèle dans Ornold

Lorsque vous dites à un agent IA « ouvrir google.com dans tous les navigateurs », Ornold ne parcourt pas les sessions une par une. Il envoie la commande de navigation à toutes les sessions actives en parallèle via CDP (Chrome DevTools Protocol). Il en va de même pour les clics, les remplissages de formulaires, les captures d’écran et toutes les autres actions du navigateur.

// This navigates ALL active sessions simultaneously
await browser_parallel_navigate({ url: "https://target.example/signup" });

// This fills the email field in ALL sessions at once
// Each session can get a different value
await browser_parallel_fill({
  ref: "email",
  values: profiles.map(p => p.email)
});

Le préfixe « parallel » dans les noms des outils n’est pas qu’une convention de nommage — il reflète le modèle d’exécution réel. Les commandes se distribuent à toutes les sessions, s’exécutent simultanément et les résultats sont collectés avant l’étape suivante.

Analyse de vision groupée

La partie la plus difficile de l’automatisation parallèle est de savoir ce qui s’affiche sur chaque écran. Dans un lot de 30 navigateurs, certains peuvent afficher le formulaire d’inscription, d’autres peuvent avoir un CAPTCHA et quelques-uns peuvent être bloqués sur un écran de chargement. Vous devez connaître l’état de chaque session avant de décider quoi faire ensuite.

L’analyse de vision groupée d’Ornold résout ce problème en prenant des captures d’écran de toutes les sessions, en les analysant comme un lot et en regroupant les sessions par leur état visuel :

// Analyze all sessions at once
const analysis = await browser_parallel_vision_analyze_grouped();

// Results are grouped by page state:
// group "signup_form": [session1, session2, ... session25]
// group "captcha": [session26, session27, session28]
// group "error_page": [session29]
// group "loading": [session30]

C’est fondamentalement différent de vérifier chaque session individuellement. Un appel API vous donne l’image complète. L’agent IA peut ensuite ramifier la logique : résoudre les CAPTCHA pour les sessions qui en ont besoin, réessayer la navigation pour celles qui ont échoué et continuer le flux pour celles qui sont prêtes.

L’analyse groupée est particulièrement précieuse lorsque les pages divergent en raison de tests A/B, du géociblage ou de la détection de bots. Au lieu de supposer que toutes les sessions sont dans le même état, vous voyez la réalité actuelle de chacune.

Concurrence bornée

Exécuter 50 navigateurs en vrai parallèle semble bien jusqu’à ce que vous heurtiez les limites de ressources. Chaque session de navigateur consomme CPU, mémoire et bande passante réseau. Les appels d’analyse de vision ont des limites de débit API. Les services de résolution de CAPTCHA limitent les requêtes simultanées.

Ornold utilise une concurrence bornée — il traite les sessions par lots contrôlés plutôt que de tout lancer à la fois :

Actions du navigateur (navigation, clic, remplissage) — S’exécutent dans toutes les sessions simultanément. Ce sont des commandes CDP légères qui ne consomment pas de ressources.
Analyse de vision — Traitée par groupes (par défaut : 12 à la fois). Les captures d’écran sont prises en parallèle, mais les appels d’analyse sont regroupés pour rester dans les limites de l’API.
Résolution de CAPTCHA — Les requêtes sont envoyées en parallèle, mais le service de résolution limite naturellement en fonction de la capacité. Ornold gère la file d’attente.
Captures d’écran — Capturées simultanément de toutes les sessions. Les données d’image sont diffusées en continu, non mises en mémoire tampon en mémoire.

// Control concurrency for vision analysis
await browser_parallel_vision_analyze_grouped({ maxConcurrency: 12 });

// For very large batches, you can lower concurrency
// to reduce memory pressure
await browser_parallel_vision_analyze_grouped({ maxConcurrency: 6 });

Suivi d’état et récupération

Dans toute opération par lot, certaines sessions échoueront. Une page peut ne pas se charger, un CAPTCHA peut expirer ou une soumission de formulaire peut renvoyer une erreur. La question est : comment détectez-vous les défaillances et vous rétablissez sans redémarrer tout le lot ?

Ornold fournit un suivi d’état en temps réel pour chaque session active :

// Check the state of all sessions
const status = await browser_status();
// Returns per-session info:
// { id: "session-1", url: "https://target.example/dashboard", state: "ready" }
// { id: "session-2", url: "https://target.example/signup", state: "ready" }
// { id: "session-3", url: "about:blank", state: "error" }

Avec les données d’état, l’agent IA peut prendre des décisions de récupération :

Sessions sur la mauvaise page — Naviguer à nouveau vers l’URL cible
Sessions avec CAPTCHA — Exécuter le solveur CAPTCHA uniquement pour ces sessions
Sessions avec erreurs — Prendre une capture d’écran pour diagnostic, puis réessayer ou ignorer
Sessions qui sont en avance — Attendre que les sessions plus lentes rattrapent avant l’action par lot suivante

Garder les sessions synchronisées

Le plus grand défi de l’automatisation parallèle n’est pas de démarrer 50 navigateurs — c’est de les garder synchronisés au fur et à mesure que le flux de travail progresse. Les différentes pages se chargent à des vitesses différentes. Certaines sessions atteignent les limites de débit. D’autres sont redirigées.

Ornold utilise la sémantique d’attente pour tous : après chaque action parallèle, il attend que toutes les sessions se terminent (ou que le délai d’attente expire) avant de passer à l’étape suivante. Cela empêche les sessions rapides de dépasser les sessions lentes.

// Navigate all sessions
await browser_parallel_navigate({ url: "https://target.example/signup" });

// Wait until all sessions show the signup form
await browser_parallel_wait_for({
  text: "Create Account",
  timeoutMs: 15000
});
// Only proceeds when ALL sessions are ready (or timed out)

// Now fill forms — all sessions are on the same page
await browser_parallel_fill({ ref: "email", values: emails });

Le délai d’attente dans `wait_for` agit comme une soupape de sécurité. Si une session ne peut pas atteindre l’état attendu dans le délai d’attente, elle est marquée plutôt que de bloquer tout le lot indéfiniment.

Données par profil dans les opérations par lot

Parallèle ne signifie pas identique. Chaque profil de navigateur a généralement besoin de données uniques — différentes adresses e-mail, noms, mots de passe ou autres valeurs de formulaire. Ornold prend en charge les valeurs par session dans les commandes par lot :

// Each session gets its own email
await browser_parallel_fill({
  ref: "email",
  values: [
    "user1@mail.com",
    "user2@mail.com",
    "user3@mail.com",
    // ... one per active session
  ]
});

// Each session gets its own password
await browser_parallel_fill({
  ref: "password",
  values: profiles.map(p => p.password)
});

Le tableau de valeurs est mappé 1:1 aux sessions actives dans l’ordre. Si vous avez 30 sessions actives, vous fournissez 30 valeurs. Cela maintient le modèle d’exécution parallèle tout en permettant une personnalisation complète par profil.

Un flux de travail parallèle complet

Voici un flux réaliste de bout en bout pour enregistrer des comptes sur 30 profils de navigateur anti-détection :

// 1. Start sessions and navigate
await browser_list(); // See available profiles
await browser_parallel_navigate({ url: "https://target.example/signup" });
await browser_parallel_wait_for({ text: "Create Account", timeoutMs: 15000 });

// 2. Fill forms with per-profile data
await browser_parallel_fill({ ref: "email", values: emails });
await browser_parallel_fill({ ref: "password", values: passwords });
await browser_parallel_fill({ ref: "name", values: names });

// 3. Solve CAPTCHAs (detected and solved across all sessions)
await browser_solve_captcha();

// 4. Submit
await browser_parallel_click({ ref: "submit" });

// 5. Verify results
await browser_parallel_wait_for({ text: "Welcome", timeoutMs: 20000 });
const status = await browser_status();
// Check which sessions succeeded and which need recovery

Conseils de mise à l’échelle

Commencez par 5-10 sessions pour valider le flux de travail, puis augmentez. Le débogage est beaucoup plus facile avec un petit lot.
Utilisez `browser_status()` après chaque étape majeure. Ne supposez pas que toutes les sessions sont dans le même état.
Définissez des délais d’attente raisonnables. Trop courts et vous obtiendrez de faux échecs. Trop longs et les sessions bloquées bloqueront tout le lot.
Pour les lots de plus de 30, envisagez de les diviser en groupes et de les exécuter séquentiellement. Cela réduit l’utilisation maximale des ressources.
Surveillez l’utilisation des ressources de votre navigateur anti-détection. Chaque profil consomme de la RAM — 50 instances de Chromium peuvent facilement utiliser 16+ Go.
Maintenez la qualité du proxy constante. Une qualité de proxy mixte entraîne des temps de chargement mixtes, ce qui cause des problèmes de synchronisation.

Pièges courants

Supposer que toutes les sessions voient la même page — Elles ne le font pas. Les tests A/B, le géociblage et la détection de bots créent des divergences. Vérifiez toujours avec `browser_status()` ou l’analyse groupée.
Pas de logique de récupération — Si vous ne gérez pas les défaillances, une session bloquée peut bloquer tout le lot. Construisez des tentatives et une logique d’omission.
Ignorer les limites de ressources — 50 navigateurs + analyse de vision + résolution de CAPTCHA peuvent surcharger une machine. Utilisez une concurrence bornée.
Pensée séquentielle dans un système parallèle — Ne parcourez pas les sessions une par une. Utilisez les outils `browser_parallel_*` pour agir sur toutes les sessions à la fois.
Ne pas valider les résultats — Une soumission de formulaire réussie ne signifie pas que le compte a été créé. Validez toujours l’état final.