Les sélecteurs adaptatifs sont très souvent attribués aux mauvais outils. Dans la moitié des comparatifs de web scraping que je lis, on associe le fait de « survivre à une refonte de site » à un gros crawler IA qui, en réalité, ne le fait pas. La bibliothèque Python qui met vraiment cette fonctionnalité en avant, c’est Scrapling, un projet en forte croissance qui affichait environ 68,7 k étoiles GitHub au 2026-07-09.
J’ai donc lancé le seul test qui compte pour ce genre d’affirmation. J’ai créé une page de test, enregistré un sélecteur, puis j’ai changé la classe de l’élément cible — exactement le genre de modification qui met silencieusement un scraper à zéro le lendemain d’une refonte. Un sélecteur classique est revenu vide. Le mode de correspondance adaptative de Scrapling a retrouvé l’élément malgré tout. Cette partie est bien réelle, et je vais montrer les chiffres. Ce que presque personne ne mesure, en revanche, c’est la limite de cette récupération — et c’est justement cette frontière qui fait tout l’intérêt du test.
Ce qu’est vraiment Scrapling
Scrapling se présente comme un framework de scraping web adaptatif capable de gérer « de la simple requête à l’exploration à grande échelle ». Si l’on enlève le slogan, on obtient deux briques empilées : un Fetcher HTTP qui récupère les pages et un Selector basé sur lxml qui les analyse, avec du CSS/XPath classique et des pratiques pseudo-sélecteurs ::text / ::attr(). Le projet est sous licence BSD-3-Clause, donc parmi les licences open source les plus permissives. J’ai testé la version 0.4.10, qui était la version courante au moment du test — pas de petit astérisque du type « vous avez benchmarké quelque chose de dépassé ».
La couche vraiment intéressante, c’est celle de l’adaptation au-dessus du parseur. Imaginez le fonctionnement d’un sélecteur classique : c’est une adresse postale codée en dur. « Récupère l’élément dont la classe est product-name. » Si l’adresse change — si la classe est renommée — la cible pointe dans le vide. Scrapling peut, lui, enregistrer l’empreinte d’un élément lors d’une première exécution, puis le retrouver plus tard, après une modification du balisage, grâce à cette empreinte plutôt qu’à l’ancienne adresse devenue obsolète. D’après la documentation de Scrapling sur le scraping adaptatif, la phase de correspondance évalue la similarité à partir de la balise, du texte, des attributs, des éléments voisins et de la position — aucun modèle IA n’entre en jeu, seulement une comparaison structurelle avec ce qui a été sauvegardé.
Il faut être clair sur l’origine de cette idée, car cela change la manière d’interpréter la fonctionnalité. La relocation adaptative est bien une capacité réelle et documentée, pas quelque chose que j’aurais découvert : la documentation officielle détaille tout le mécanisme d’enregistrement dans SQLite puis de correspondance par similarité, et plusieurs analyses externes l’expliquent aussi. Le concept de sélecteurs auto-réparables existait d’ailleurs déjà dans le monde des tests d’automatisation. Ce qui distingue Scrapling, c’est que cette capacité est intégrée nativement à la bibliothèque : les parseurs classiques comme lxml, parsel ou BeautifulSoup offrent des sélecteurs statiques, sans aucune relocation automatique. Il s’agit donc d’une fonctionnalité distinctive mais documentée, que j’ai reproduite et mise à l’épreuve — pas d’une capacité inexistante chez les autres.
Le test adaptatif, en détail
Voici le protocole. J’ai mis en place un catalogue de test et suivi un élément produit tant que sa classe était product-name. Puis j’ai renommé cette classe en product-title et relancé exactement le même code. Un sélecteur simple .product-name a renvoyé 0 élément — exactement le résultat vide attendu quand la classe ciblée n’existe plus. La recomposition adaptative de Scrapling a retrouvé l’élément suivi en s’appuyant sur l’empreinte enregistrée dans la version précédente. Le résultat brut se trouve dans le dépôt de benchmark à local_adaptive_selector.json.
Essayez Thunderbit pour l’extraction de données web
Et maintenant, la partie que la plupart des tests passent sous silence. J’ai poussé l’expérience plus loin avec un test synthétique sur plusieurs éléments — trois éléments suivis au lieu d’un seul. Scrapling a retrouvé le premier élément enregistré, mais pas les trois. Ce n’est pas un échec ni un bug ; la documentation décrit l’auto-correspondance comme un suivi d’élément, avec une empreinte par élément sauvegardé, donc un résultat de 1 sur 3 avec les réglages par défaut signifie que la fonctionnalité se comporte exactement comme prévu. Mais cela veut aussi dire que la description juste est « suivi résilient d’un élément », et non « récupération automatique d’une page entière après refonte ». L’auto-match suit l’élément que vous lui avez demandé de suivre. La résilience multi-éléments, c’est à vous de la paramétrer.
Cette nuance a plus de poids qu’il n’y paraît. « Survit aux changements de balisage » tient bien en titre. « Continue à suivre l’élément fingerprinté malgré les changements de balisage, et vous gérez le reste » correspond à la réalité de la fonctionnalité. Si vous partez avec la première idée, vous serez déçu. Si vous partez avec la seconde, l’outil fait le travail proprement.
Installation : la friction dont personne ne vous prévient
Cette partie m’a coûté du temps réel, donc je vous la donne avant que vous n’y tombiez. pip install scrapling installe le parseur — et seulement le parseur. Dès que j’ai écrit from scrapling.fetchers import Fetcher, tout s’est cassé en chaîne à cause de dépendances manquantes : d’abord curl_cffi, puis playwright, puis browserforge, chacune n’apparaissant qu’après résolution de la précédente.
La solution consiste à installer l’extra : pip install "scrapling[fetchers]", ou à utiliser la commande scrapling install, qui installe la pile complète de récupération HTTP + navigateur. Après cela, tout a fonctionné. Mais la séquence « l’installation de base semble OK puis explose au premier fetch » est bien réelle, et rien ne l’indique franchement dès le départ. Prévoyez dès la première commande l’extra [fetchers] et ses dépendances transitives lourdes, et vous éviterez tout ce détour.
Ce qui a tenu en extraction HTTP classique
Une fois les fetchers installés, le chemin d’extraction standard était solide — rappel de 1.0 sur toute la ligne :
| Test | Résultat |
|---|---|
| Catalogue statique + pagination | 12/12 produits |
| Extraction d’article | titre + 3/3 paragraphes |
| API JSON dynamique | 8/8 éléments |
| Books to Scrape (public) | 20 produits |
| Gestion d’un HTTP 500 | statut exposé proprement, aucun crash |
Le recours à lxml se voit ici. CSS et XPath se comportent comme on l’espère, et les pseudo-sélecteurs ::text / ::attr() gardent le code d’extraction court et lisible au lieu d’en faire une pile d’appels imbriqués. Le cas du 500 est petit, mais parlant : le Fetcher a exposé le code de statut au lieu de me jeter une trace d’erreur au visage — la différence entre un scraper qu’on peut planifier et un scraper qu’il faut surveiller à la main. Les chiffres complets sont dans scrapling-test-summary.json.
Rien de tout cela n’est spectaculaire. C’est simplement correct — et la correction est trop souvent sous-estimée.
Ce qu’il ne fait pas, volontairement
Le Fetcher HTTP ne rend pas JavaScript. Je l’ai pointé vers une page de test rendue côté client et j’ai obtenu 0 carte en retour ; même résultat, 0, sur la page publique Quotes to Scrape JS. Ce n’est pas un défaut : le Fetcher HTTP télécharge le HTML, il n’ouvre pas de navigateur, donc le contenu rendu côté client n’existe tout simplement pas à cet endroit. Scrapling propose un DynamicFetcher séparé, basé sur un navigateur, pour les pages JS. Je ne l’ai pas testé dans ce passage, donc je ne vais pas inventer de performance le concernant. Il ne faut simplement pas envoyer un site rendu côté client au chemin HTTP en espérant voir le contenu.
Il existe aussi un StealthyFetcher destiné à la détection anti-bot. Je le considère comme une question de conformité, point final — pas comme une fonctionnalité à brandir. Le droit de scraper, la manière de le faire et votre cadre légal vous appartiennent ; cette évaluation porte sur la capacité d’extraction, pas sur l’évasion. Je ne l’ai pas exécuté et je ne le note pas.
Avantages et inconvénients
Avantages :
- Les sélecteurs adaptatifs ont réellement retrouvé un élément suivi après un renommage de classe qui renvoyait 0 avec un sélecteur classique — c’est la raison distinctive d’utiliser Scrapling.
- Extraction HTTP avec rappel de 1.0 sur des pages statiques, des articles et des API JSON.
- CSS/XPath propres basés sur lxml, avec des pseudo-sélecteurs
::text/::attr()lisibles. - Gestion propre du HTTP 500 — statut exposé, aucun crash.
- La version testée correspond à la dernière version publiée, donc pas de dérive de version.
- Licence BSD-3-Clause permissive, adaptée à un usage commercial.
Inconvénients :
- L’auto-match suit un élément enregistré, pas une page entière — le test à trois éléments n’en a retrouvé qu’un. Il faut formuler l’attente en conséquence.
pip install scraplingn’installe que le parseur ; les fetchers nécessitent l’extra[fetchers]et toute sa chaîne de dépendances, que j’ai découverte à mes dépens.- Le
FetcherHTTP ne rend pas JavaScript ; le contenu côté client exige leDynamicFetcherbasé navigateur, qui n’a pas été testé ici. - La promesse de résilience demande un réglage manuel dans les cas multi-éléments.
Pour qui c’est fait — et qui devrait passer
Scrapling a toute sa place si vous maintenez des scrapers sur des sites qui se refont souvent et que vous êtes lassé de voir un simple renommage de classe casser silencieusement l’extraction du jour au lendemain. Si votre problème récurrent est « mes sélecteurs cassent toutes les quelques semaines et je veux juste que l’élément qui m’intéresse continue d’être retrouvé », l’outil vise exactement ce besoin. Il fonctionne aussi très bien comme extracteur lxml léger pour pages statiques et API JSON, même sans activer la couche adaptative.
En revanche, il faut réinitialiser ses attentes — ou regarder ailleurs — dans deux cas. Si vous espérez que les sélecteurs adaptatifs réparent automatiquement toute une page refondue — ils suivent des éléments, ils ne reconstruisent pas des interfaces — il vous faut un autre modèle mental. Et si vos cibles sont lourdes en JavaScript et que vous ne voulez pas mettre en place le DynamicFetcher basé navigateur, le seul chemin HTTP ne suffira pas. Dans tous les cas, si vous l’installez, ajoutez l’extra [fetchers] dès la première commande.
Où se situe une API de scraping IA managée
Scrapling est une bibliothèque open source gratuite que vous exécutez et maintenez vous-même. Vous possédez le code, la chaîne de dépendances et le réglage fin — en échange, vous ne payez rien par requête et gardez tout en interne. C’est un choix réel et défendable, et pour beaucoup d’équipes, c’est le bon.
La vraie question est : qui porte le problème de la résilience ? La réponse de Scrapling est : vous. Vous fingerprintiez les éléments et vous ajustez le suivi. Une API de scraping IA managée répond autrement : la gestion du changement est déportée côté serveur. C’est précisément la place que prend Thunderbit dans la pile des équipes techniques. POST /extract renvoie du JSON structuré à partir d’un JSON Schema que vous définissez, avec le rendu, l’anti-bot et la dérive du balisage absorbés côté serveur ; un flag renderMode détermine quelle partie de la page est exécutée avant l’extraction. Thunderbit propose aussi un serveur MCP pour les agents IA et les assistants de code — thunderbit_suggest_fields est gratuit et s’exécute en premier pour préparer une extraction — ainsi qu’une CLI via npx @thunderbit/thunderbit-cli pour le terminal, les scripts et l’intégration CI. Même moteur IA derrière ces trois interfaces.
Le vrai arbitrage n’est pas « mieux » contre « moins bien » : c’est l’endroit où vous voulez que la logique de résilience vive. Avec Scrapling, vous la gardez dans votre propre code, fingerprintée et ajustée par vous, sans coût à l’appel, en acceptant la maintenance que cela implique. Avec une API managée, vous déléguez la gestion du drift et vous payez à la requête. Petite infra auto-hébergée et envie de garder la main sur le tuning ? Le contrôle offert par Scrapling est le bon choix. Vous devez scaler sur une centaine de sites et vous n’avez pas envie de surveiller des empreintes de sélecteurs partout ? La solution managée élimine cette charge de maintenance.
Si vous comparez les options du marché, le benchmark open source complet des scrapers met Scrapling en face des autres sur les mêmes pages de test, et les analyses Scrapy review et Colly review couvrent deux autres frameworks orientés HTTP qui valent le détour.
Verdict
Faut-il utiliser Scrapling ? Oui — si vous voulez un extracteur Python open source dont le tour de force consiste à retrouver un élément suivi même quand le balisage autour change, et si vous avez une vision réaliste de ce que cette fonctionnalité sait faire. Il a retrouvé un élément qu’un sélecteur cassé ne pouvait plus atteindre, sur un renommage qui aurait silencieusement vidé les données d’un scraper classique. L’extraction HTTP standard est propre et a atteint un rappel complet sur toutes les pages de test. La licence est permissive et la version que j’ai testée était à jour.
Il faut juste dimensionner correctement l’affirmation, et vous serez satisfait. Il suit des éléments, il ne reconstruit pas automatiquement des pages — le test à trois éléments n’en a retrouvé qu’un. Installez l’extra [fetchers] dès le départ, sinon vous tomberez dans le mur de dépendances que j’ai rencontré. Et si vos pages nécessitent JavaScript, c’est le rôle du fetcher basé navigateur, pas du fetcher HTTP. Dans ces limites, Scrapling fait exactement ce pour quoi il est connu, et parmi les bibliothèques Python de scraping, c’est celle qui embarque réellement la fonctionnalité que tout le monde attribue à tort ailleurs.
Essayez Thunderbit pour l’extraction de données web Get Started Free
FAQ
Les sélecteurs adaptatifs de Scrapling survivent-ils vraiment à une refonte de site ?
Ils survivent au renommage de classe d’un élément suivi — ce qui a été vérifié lors du test. Après avoir renommé product-name en product-title, un sélecteur classique a renvoyé 0, tandis que la correspondance adaptative a retrouvé l’élément suivi. En revanche, Scrapling suit des éléments enregistrés plutôt que de reconstruire une page entière : dans le test synthétique à trois éléments, un seul a été retrouvé. Il faut donc le voir comme un suivi résilient d’élément, pas comme une récupération automatique d’une page complète.
Pourquoi pip install scrapling échoue-t-il quand j’importe un fetcher ?
Parce que l’installation de base ne contient que le parseur. L’import de scrapling.fetchers déclenche une cascade de dépendances manquantes — curl_cffi, puis playwright, puis browserforge. Lancez pip install "scrapling[fetchers]" (ou la commande scrapling install) pour récupérer toute la pile de fetchers, et l’import fonctionnera.
Scrapling peut-il extraire des pages rendues en JavaScript ?
Pas avec le Fetcher HTTP — il a renvoyé 0 sur la page JS de test et sur la page publique Quotes JS, car il télécharge le HTML sans exécuter de navigateur. Scrapling fournit un DynamicFetcher séparé, basé sur un navigateur, pour les pages JS ; ce test ne l’a pas couvert, donc je ne peux pas encore juger ses performances.
Scrapling est-il rapide et précis pour l’extraction classique ? Lors des tests, oui : rappel de 1.0 sur des catalogues statiques, des pages d’articles et des API JSON, avec un CSS/XPath propre fondé sur lxml. Il a aussi géré un HTTP 500 en exposant le statut au lieu de planter. Si vous n’utilisez jamais la couche adaptative, cela reste un extracteur léger et solide pour du contenu statique.
Scrapling est-il gratuit pour un usage commercial ? Oui, il est sous licence BSD-3-Clause, donc permissive et compatible avec un usage commercial. Comme toujours, vérifiez la licence actuelle sur le dépôt avant de bâtir dessus.
