Collecteur de données avec reprise

Contexte

Les données à récupérer couvraient plus de cinq ans : des archives hebdomadaires, de la première semaine de 2019 à juillet 2024. Impossible de tout obtenir en une passe, et au moindre arrêt il fallait d’abord retrouver où l’on en était. Le calendrier du projet rendait le délai important.

Ce que nous avons constaté

Le problème ne venait pas de l’outil de collecte, mais de la façon d’envoyer les requêtes. Envoyées en rafale, à un rythme sans rapport avec une lecture humaine, elles finissent par ne plus recevoir de réponse, et la collecte du jour reste à moitié faite.

Le problème

Nous avons reformulé l’objectif : non pas « récupérer vite », mais « récupérer jusqu’au bout ». Mieux vaut prendre plus de temps et couvrir toute la période que s’arrêter à mi-chemin. Des données incomplètes devront de toute façon être récupérées à nouveau.

Ce choix suppose d’avoir vérifié au préalable les conditions d’utilisation du site et son fichier d’exclusion des robots. Sans établir d’abord que ces données peuvent être collectées, le reste de la conception n’a pas de sens.

Ce que nous avons réalisé

• Contrôle de l’intervalle et des nouvelles tentatives — les requêtes sont étalées plutôt qu’envoyées en rafale. C’est ce qui permet aux cinq années d’arriver sans trou
• Découpage par semaine — la période de plus de cinq ans n’est pas traitée d’un bloc, mais semaine par semaine. En cas d’échec, seule la semaine concernée est à reprendre
• Reprise au point d’arrêt — le programme mémorise l’endroit où il s’est arrêté. Une longue collecte n’aboutit que si elle ne repart jamais de zéro
• Affichage du temps restant — la progression et le temps restant estimé restent à l’écran. Une tâche de plusieurs heures sans aucun indicateur finit souvent interrompue par l’utilisateur

Résultats

Toute la période, de la semaine 1 de 2019 à la semaine 30 de 2024, a été récupérée sans lacune. La même architecture est depuis réutilisée pour d’autres collectes.