Choisir un crawler open source : quatre rôles et quatre critères d’évaluation

Une recherche de crawlers sur GitHub peut faire apparaître des centaines, voire des milliers de dépôts. Beaucoup de personnes choisissent simplement en regardant le nombre d’étoiles et commencent par le projet le plus populaire.

Popularité et adéquation au besoin sont pourtant deux choses différentes. Même un projet très connu devient pénible à utiliser si son positionnement ne correspond pas à votre scénario. Le point de départ le plus simple consiste à séparer les responsabilités : un système de collecte capable de fonctionner durablement est généralement composé de plusieurs éléments aux rôles distincts. Comprendre chaque rôle rend ensuite la comparaison des implémentations beaucoup plus simple.

Frameworks de crawling général : pour les pages à structure stable

Ces frameworks gèrent la planification des requêtes, la collecte concurrente et les pipelines de données. Ils reçoivent des lots d’URL et produisent des résultats structurés. Leur écosystème mûr et leurs mécanismes de middleware permettent d’ajouter sa propre logique et de faire tourner durablement des tâches à très grande échelle.

Ils ne savent pas traiter seuls les pages dont le contenu n’apparaît qu’après rendu JavaScript. Dans ce cas, la réponse récupérée n’est qu’une coquille vide et il faut ajouter un moteur de rendu. Ils conviennent bien aux cibles stables comme les pages de liste, les pages de détail et les API ouvertes.

Automatisation du navigateur : pour le rendu et l’interaction

Les pages qui exigent un vrai rendu, une session connectée ou plusieurs clics avant d’afficher le contenu doivent être confiées à l’automatisation du navigateur. Ces outils peuvent fonctionner avec plusieurs moteurs, disposent de mécanismes d’attente aboutis et permettent de prendre directement en charge les requêtes et réponses de la page.

En contrepartie, ils consomment beaucoup plus de ressources que de simples requêtes HTTP. La concurrence maximale dépend essentiellement de la mémoire et du processeur de la machine. L’automatisation laisse aussi des signatures détectables, que les sites dotés de contrôles stricts peuvent reconnaître.

Planification et files : utiles lorsque le volume augmente

Avec peu de cibles, une simple boucle peut suffire. Quand les tâches se comptent par milliers et qu’il faut contrôler la fréquence et les nouvelles tentatives, une couche de planification séparée devient nécessaire : ordre des tâches, niveau de concurrence, délai avant nouvelle tentative et critères d’abandon. Mettre toute cette logique dans le framework de crawling rend rapidement le code difficile à maintenir.

Une erreur classique consiste à se contenter d’une file interne au processus. Si le processus redémarre, toutes les tâches en attente disparaissent. Au minimum, la file doit être persistante et son état consultable.

Parsing et stockage : ils déterminent si les données sont directement exploitables

Ce qui revient du réseau est du HTML ; ce qu’il faut réellement, ce sont des champs. La couche de parsing doit gérer les règles d’extraction, valider les champs, supprimer les doublons et enregistrer les données. Pour les sites qui changent souvent de structure, une extraction adaptative fondée sur les caractéristiques de la page plutôt que sur des sélecteurs codés en dur peut réduire la maintenance.

Côté stockage, il faut veiller à l’idempotence. Les nouvelles tentatives sont normales ; les écritures doivent donc être dédupliquées à partir d’un identifiant unique, sans quoi les doublons contamineront les analyses en aval.

Problèmes fréquents une fois les composants assemblés

Chaque composant est relativement simple pris séparément. Les problèmes apparaissent surtout aux interfaces.

• La couche de planification relance une tâche, mais le parsing ne déduplique pas et crée des lignes en double
• La couche navigateur n’a pas de limite de concurrence, épuise les ressources locales et fait échouer tout le lot
• Les règles de parsing sont codées en dur, donc chaque modification du site impose une nouvelle version
• Les composants n’utilisent pas le même identifiant de tâche, les états ne correspondent plus et la reprise sur point de contrôle devient impossible

Quatre critères d’évaluation

Une fois la catégorie choisie, utilisez ces quatre critères pour filtrer les projets concrets.

Pour l’activité de maintenance, regardez la fréquence des commits et la vitesse de réponse aux issues sur les derniers mois, pas le nombre total d’étoiles. Un projet qui n’est plus maintenu peut cesser de fonctionner dès que le site cible évolue.

La documentation et les exemples déterminent le coût de prise en main. Une documentation vague ou limitée aux cas les plus simples peut allonger fortement le temps d’apprentissage.

Pour l’extensibilité, vérifiez les points de branchement disponibles : peut-on remplacer le proxy, connecter son propre moteur de rendu ou changer de stockage ? Avec des points d’extension clairs, les adaptations futures peuvent souvent se faire sans modifier le code source.

Les risques de licence et de conformité sont facilement oubliés. Avant une utilisation commerciale, vérifiez le type de licence et évitez celles qui sont incompatibles avec votre usage. Il faut également évaluer le périmètre de collecte, la fréquence des requêtes et les conditions du site cible ; ces questions sont indépendantes de la qualité technique du framework.

La couche d’environnement relève d’un autre niveau

Le framework résout la manière de collecter, pas les problèmes d’identité et d’échelle. Lorsque les tâches nécessitent une connexion, une séparation régionale ou plusieurs comptes en parallèle, tout exécuter dans le même environnement de navigateur crée deux problèmes : les sessions se contaminent parce que cookies et stockage local se chevauchent, et le site cible peut considérer des tâches sans lien comme un même groupe de visites.

Une approche mature consiste à faire des environnements de navigateur une couche de ressources indépendante. Les tâches demandent un environnement dans un pool puis le libèrent à la fin. Dans ce type d’architecture, PurpleMark occupe cette couche et fournit des ressources d’environnement créables en lots, associables à des sorties réseau indépendantes et consultables par état.

Les limites à respecter en matière de conformité

Respectez les règles robots et les conditions d’utilisation du site cible, ne collectez pas d’informations personnelles, ne contournez pas les mesures techniques de protection et limitez la fréquence des requêtes afin de ne pas perturber le service normal. Le choix du projet répond à une question d’efficacité ; ces décisions déterminent si la collecte peut être réalisée.