Technologie6 min de lecture

Vision-first vs sélecteurs CSS : pourquoi les clics par coordonnées tiennent mieux

Les sélecteurs cassent dès que le balisage change. L’analyse visuelle garde les automatisations stables en trouvant les éléments depuis des captures plutôt que via des chemins DOM fragiles.

8 avr. 2026

Le problème des sélecteurs dans les flux de travail antidétection

Les sélecteurs CSS sont le moyen par défaut par lequel les outils d’automatisation trouvent des éléments sur une page. Vous écrivez un chemin comme `button.submit-btn` ou `#login-form input[name="email"]`, et le script clique ou le remplit. Cela fonctionne jusqu’à ce que le balisage change — et dans les flux de travail antidétection, le balisage change constamment.

Différents profils de navigateur peuvent voir différentes versions de page. Les tests A/B, les mises en page géociblées, les bannières de consentement, les défis de détection de bots et les noms de classe dynamiques décalent le DOM entre les sessions. Un sélecteur qui fonctionne dans le profil #1 peut ne pas exister dans le profil #12.

Pourquoi les sélecteurs se cassent plus souvent que vous ne le pensez

Noms de classe dynamiques — Les frameworks comme React, Next.js et Tailwind génèrent des classes hachées ou utilitaires qui changent entre les builds. Un sélecteur ciblant `.css-1a2b3c` cesse de fonctionner après le prochain déploiement.
Tests A/B — La même URL peut servir des structures DOM complètement différentes à différents visiteurs. Votre sélecteur suppose une variante ; la page en affiche une autre.
Bannières de consentement et de cookies — Ces superpositions injectent de nouveaux éléments, décalent les z-index et enveloppent parfois la page entière dans un conteneur qui n’existait pas quand vous avez écrit le sélecteur.
Superpositions de détection de bots — Les défis Cloudflare, les interstitiels DataDome et les systèmes similaires remplacent le contenu de la page par leur propre balisage. Aucun ajustement de sélecteur n’aide quand la page elle-même a disparu.
Différences de localité et de géolocalisation — Les mises en page RTL, le texte des boutons traduits et les composants UI spécifiques à la région changent tous l’arborescence DOM.

Dans un script à navigateur unique, vous remarquez et corrigez ces problèmes un à la fois. Dans un lot de 50 profils, un sélecteur cassé échoue silencieusement dans des dizaines de sessions avant que quelqu’un ne le remarque.

Comment fonctionne l’interaction orientée vers la vision

Orienté vers la vision signifie que l’IA prend une capture d’écran de la page et l’analyse visuellement — de la même manière qu’un humain regarderait un écran. Au lieu de rechercher un sélecteur spécifique dans le DOM, elle identifie les éléments par leur apparence : "le bouton Sign Up bleu au centre de la page".

Le flux est simple :

Prendre une capture d’écran de l’état actuel de la page
L’envoyer à un modèle de vision qui identifie les éléments interactifs et leurs positions
Retourner des cadres de délimitation normalisés (coordonnées) pour chaque élément détecté
Cliquer, survoler ou interagir en utilisant ces coordonnées — aucune recherche DOM requise

// Vision-first click flow
await browser_parallel_navigate({ url: "https://target.example/signup" });
const grouped = await browser_parallel_vision_analyze_grouped();
// AI identifies elements visually across all active browsers
// Returns normalized bounding boxes for each element
await browser_parallel_click_normalized_box({ box: signUpButton.box });

Clics de coordonnées vs clics de sélecteur

Un clic de sélecteur dit "trouve l’élément à ce chemin DOM et clique-le". Un clic de coordonnées dit "clique à cette position sur l’écran". La différence compte quand les pages divergent.

Approche basée sur les sélecteurs

// Breaks if class name changes, element moves, or overlay appears
await page.click("button.btn-primary.submit-action");
// Breaks if form structure changes
await page.fill("#signup-form input[type=email]", "user@mail.com");

Approche basée sur la vision

// Works regardless of class names, IDs, or DOM structure
await browser_parallel_screenshot();
const analysis = await browser_parallel_vision_analyze_grouped();
// AI finds "Sign Up" button visually — same as a human would
await browser_parallel_click_normalized_box({ box: analysis.signUp.box });

L’approche basée sur la vision ne se soucie pas des noms de classe, des ID ou de la profondeur d’imbrication. Si le bouton est visible à l’écran, il sera trouvé. C’est particulièrement puissant dans les scénarios antidétection où chaque profil peut rendre une page légèrement différente.

Analyse groupée pour les opérations par lot

Lors de l’exécution de 20+ profils de navigateur en parallèle, l’analyse de vision doit être efficace. Ornold utilise l’analyse groupée — elle prend des captures d’écran de toutes les sessions actives, les envoie par lot au modèle de vision et retourne les résultats pour chaque session en un seul appel.

C’est important pour deux raisons :

Efficacité — Un appel API gère toutes les sessions au lieu de N appels séparés. La latence reste à peu près constante quelle que soit la taille du lot.
Gestion de la divergence — L’IA voit l’état réel de chaque session. Si le profil #7 a une superposition CAPTCHA tandis que les autres affichent le formulaire, le résultat groupé le reflète. Vous pouvez ramifier la logique par session au lieu de supposer que toutes les pages se ressemblent.

// Grouped vision analysis across all active browsers
const results = await browser_parallel_vision_analyze_grouped();
// results.groups shows which browsers are in which state
// e.g., 15 browsers on the form, 3 on CAPTCHA, 2 on error page

Quand le mode DOM gagne toujours

L’analyse de vision n’est pas toujours le bon choix. L’interaction basée sur le DOM (mode par défaut d’Ornold) est plus rapide, gratuite et parfaitement fiable pour les pages structurées avec un balisage stable.

Utilisez le mode DOM quand :

La page cible a un HTML stable et prévisible (par exemple, votre propre application, des plateformes bien connues)
Vous remplissez des formulaires avec des champs de saisie et des étiquettes clairs
La vitesse compte plus que la résilience — les snapshots DOM sont instantanés, l’analyse de vision prend 1-3 secondes
Vous voulez éviter les coûts de crédit de vision

Utilisez le mode Vision quand :

Les pages varient entre les profils (tests A/B, géociblage, mises en page dynamiques)
Vous traitez avec des interfaces basées sur canvas, des pages riches en images ou des composants web personnalisés
Les sélecteurs se cassent constamment et le coût de maintenance est élevé
Vous devez vérifier à quoi ressemble réellement la page (QA visuelle)

Vous pouvez activer les deux modes à la fois. L’agent IA choisit automatiquement la meilleure approche pour chaque action — DOM pour les remplissages de formulaires simples, vision pour les pages complexes ou imprévisibles.

Comparaison dans le monde réel

Voici ce qui se passe en pratique lors de l’exécution d’un flux d’inscription sur 30 sessions Linken Sphere :

Automatisation basée sur les sélecteurs

25 sessions sur 30 se terminent avec succès
3 échouent parce qu’une bannière de consentement a décalé la mise en page du formulaire
1 échoue parce que Cloudflare a servi une page interstitielle
1 échoue parce que le site a déployé une nouvelle version pendant l’exécution avec des noms de classe différents
Total : 83% de taux de réussite. Une intervention manuelle est nécessaire pour 5 sessions.

Automatisation basée sur la vision

29 sessions sur 30 se terminent avec succès
1 échoue parce que la page n’a pas pu se charger (délai d’expiration du réseau — pas un problème de sélecteur)
Les bannières de consentement, les décalages de mise en page et les changements de noms de classe n’ont eu aucun effet
Total : 97% de taux de réussite. Une nouvelle tentative est nécessaire pour le délai d’expiration.

L’écart s’élargit à mesure que la taille du lot augmente. Avec 50+ profils, l’automatisation basée sur les sélecteurs nécessite généralement une maintenance constante. L’automatisation basée sur la vision reste stable car elle s’adapte à ce qui est réellement à l’écran.

Configuration du mode Vision dans Ornold

Activez le mode vision lors de la connexion de votre agent IA à Ornold MCP. Dans l’assistant du tableau de bord, sélectionnez "Les deux modes" à l’étape 2 pour obtenir les outils DOM + Vision. Ou ajoutez l’indicateur manuellement :

# Claude Code — enable both DOM and Vision modes
claude mcp add --transport stdio ornold-browser -- npx ornold-mcp --token YOUR_TOKEN --mode both --linken-port 40080

# Codex — in config.toml
[mcp_servers.ornold-browser]
command = "npx"
args = ["ornold-mcp", "--token", "YOUR_TOKEN", "--mode", "both", "--linken-port", "40080"]

Chaque analyse de vision coûte 1 crédit. Les snapshots DOM sont gratuits. Avec le mode "les deux" activé, l’agent IA utilise DOM par défaut et ne bascule vers la vision que si nécessaire.

Points clés à retenir

Les sélecteurs CSS supposent un DOM stable. Dans les flux de travail antidétection, le DOM est tout sauf stable.
L’interaction orientée vers la vision trouve les éléments par apparence, pas par chemin. Elle s’adapte automatiquement aux changements de mise en page, aux superpositions et aux tests A/B.
L’analyse de vision groupée gère la divergence des lots — chaque session est analysée en fonction de son état réel.
Le mode DOM est toujours le meilleur choix par défaut pour la vitesse et le coût. Utilisez la vision quand les pages sont imprévisibles ou que les sélecteurs se cassent constamment.
Les deux modes peuvent coexister. Laissez l’agent IA choisir le bon outil pour chaque action.