Sélecteurs XPath et CSS

Les sélecteurs sont la base de tout outil de scraping fondé sur des règles : ils lui indiquent précisément les éléments dont il doit extraire les données. Un sélecteur bien conçu résiste aux petites mises à jour du site ; un sélecteur fragile cesse de fonctionner dès qu’un développeur modifie une classe ou réorganise la mise en page. Savoir créer des sélecteurs durables est l’une des compétences les plus utiles en web scraping, même avec un outil visuel qui les génère automatiquement. Les deux principaux langages sont les sélecteurs CSS et XPath. Tous deux peuvent localiser des éléments dans un document HTML, mais fonctionnent différemment et possèdent chacun leurs avantages.

​

Sélecteurs CSS

Les sélecteurs CSS emploient la même syntaxe que les feuilles de style des développeurs web. Ils ciblent les éléments selon leur balise, classe, identifiant, attribut et relation avec d’autres éléments. Par exemple, div.product-card h2 sélectionne tous les éléments h2 situés dans des div de classe product-card. Ils sont généralement plus courts, lisibles et rapides à évaluer par le navigateur. Ils constituent le meilleur choix par défaut pour la plupart des extractions simples.

​

XPath

XPath est plus puissant, mais plus détaillé. Il traite le document HTML comme un arbre et permet de le parcourir dans toutes les directions : vers les enfants, les parents, les éléments voisins ou ailleurs dans le document. Surtout, il peut sélectionner un élément selon son texte, par exemple //a[contains(text(), "Next Page")], ce que CSS ne permet pas. XPath est donc essentiel pour trouver un bouton par son libellé ou une cellule de tableau par son contenu. Ses conditions, fonctions et prédicats complexes le rendent également plus expressif sur les structures atypiques.

​

Lequel choisir ?

Le compromis oppose simplicité et souplesse. CSS traite plus proprement la majorité des cas courants. Choisissez XPath lorsque la structure HTML est complexe, qu’une correspondance textuelle est nécessaire ou que l’élément ne peut être identifié que par sa relation avec un élément voisin ou ancêtre.

​

Écrire des sélecteurs durables

Quel que soit le langage, quelques principes améliorent la durabilité :

• Évitez les noms de classe générés automatiquement. Les frameworks comme React, Vue et Angular produisent souvent des classes qui changent à chaque compilation, telles que .css-1a2b3c.
• Privilégiez les attributs sémantiques. id, data-*, role et aria-label ont moins de chances de changer, car ils portent un sens au-delà du style. [data-product-id] résiste à une réécriture CSS, contrairement à .flex-row__inner--lg.
• Gardez les sélecteurs courts. Plus la chaîne de relations parent-enfant est longue, plus une modification intermédiaire risque de la rompre.
• Évitez les sélecteurs de position. nth-child et les chemins XPath absolus tels que /html/body/div[3]/div[2]/ul/li[1] supposent que l’élément conserve exactement sa place dans le DOM, ce qui est rarement vrai.
• Ancrez-vous au repère stable le plus proche. Partez de l’élément pertinent le plus proche doté d’un identifiant stable, plutôt que de parcourir le document depuis sa racine.

​

Le défi du Shadow DOM

Le Shadow DOM constitue un obstacle croissant. Cette fonction des composants web enferme une partie du DOM derrière une limite. Les sélecteurs XPath et CSS standard ne peuvent pas pénétrer une racine shadow : les éléments concernés leur sont invisibles. Avec l’adoption croissante des composants web, un outil peut voir l’enveloppe extérieure sans accéder au contenu affiché. Il faut alors un outil capable de franchir cette limite. Playwright étend les sélecteurs standard avec la syntaxe >> ; Octoparse ajoute à XPath une syntaxe personnalisée qui permet de cibler une racine shadow comme un sous-arbre DOM ordinaire.

​

L’approche d’Octoparse

Octoparse utilise principalement XPath pour cibler les éléments. Son modèle de navigation en arbre correspond naturellement à la manière dont une personne non technique envisage une page : « le prix dans cette fiche produit » se traduit plus directement en XPath qu’en chaîne CSS. L’utilisateur peut ainsi examiner et ajuster le sélecteur sans être développeur. Lorsqu’un utilisateur clique sur un élément, Octoparse ne génère pas simplement un XPath fonctionnel : il applique un algorithme intelligent de priorité des attributs. Le système évalue leur stabilité sémantique et préfère les identifiants significatifs tels que id, data-* et role aux classes instables et indices de position fragiles. Le XPath généré est conçu pour résister aux petites modifications : une réorganisation ou un nouveau style ne rompt pas un sélecteur ancré sur data-product-id. Cet algorithme a été entièrement reconstruit dans Octoparse 10.1.0, afin de générer dès le premier clic un XPath exact et durable sur la grande majorité des pages. Pour les pages à composants web, le générateur utilise aussi l’extension XPath personnalisée d’Octoparse pour le Shadow DOM. Un élément dans une racine shadow reste donc accessible dans le même langage. Deux capacités d’IA complètent ce générateur :

• Génération XPath assistée par IA, qui analyse le contexte plus large de la page pour produire des sélecteurs plus résilients
• Autoréparation par IA (prochainement), qui détecte les sélecteurs rompus et les reconstruit depuis la nouvelle structure, tant pour la pagination que pour les champs

Ces fonctions répondent à l’évolution du Web vers des pages plus dynamiques, composées et cloisonnées.

​

À retenir

Consacrez du temps aux fondamentaux des sélecteurs, même avec un outil visuel. Comprendre leur fragilité ou leur durabilité permet d’évaluer les résultats générés, de résoudre les pannes et de créer des outils fiables sur la durée. Une fois les valeurs brutes localisées, l’étape suivante consiste à nettoyer et transformer le texte en données réellement utiles.