"Hier, tout fonctionnait bien, non ?" - Une phrase que toute personne ayant exploité un crawler a dite au moins une fois
Temps de lecture : 7 minutes | Dernière mise à jour : Janvier 2026
La durée de vie d'un crawler est plus courte que prévu
Lorsque vous créez un crawler, tout fonctionne parfaitement au début. Les données arrivent proprement, le planificateur fonctionne bien.
Mais au fil du temps, cela se produit :
- 1 semaine : Pas de problème. "J'ai vraiment bien fait ça"
- 1 mois : Des données vides commencent à arriver sur une page spécifique
- 3 mois : Pas d'erreurs mais les résultats de la collecte sont étranges. L'IP est également bloquée
- 6 mois : La moitié du crawler cesse de fonctionner en raison du renouvellement du site
Le crawler ne se casse pas. Le site web continue de changer.
Cet article explique pourquoi les sites web changent constamment et pourquoi la maintenance d'un crawler devient un combat sans fin sur le plan technique.
Cas réel : Crawler de surveillance des prix du commerce électronique
Une entreprise a développé un crawler pour surveiller les prix des concurrents sur 3 places de marché (Coupang, 11th Street, Gmarket).
Premiers 3 mois : Fonctionne parfaitement. Un rapport Excel est généré automatiquement chaque matin.
Mois 4 : Coupang a renouvelé son frontend. Le crawler a commencé à renvoyer des données vides, mais il a fallu une semaine avant que quelqu'un ne s'en rende compte. La correction a pris 3 jours.
Mois 6 : 11th Street a renforcé la détection de bots. Le blocage IP a commencé. Un service de proxy a été introduit, entraînant des coûts supplémentaires de 300 000 wons par mois.
Mois 9 : Gmarket a modifié la structure de réponse de l'API. L'analyse JSON est corrompue. Un développeur externe a été chargé de la correction, mais cela a pris 2 jours pour comprendre le code et 3 jours pour le corriger. Coût : 1,2 million de wons.
Coût total après 1 an : Développement initial 3 millions de wons + Maintenance (4 corrections) 4,8 millions de wons + Proxy 1,8 million de wons = 9,6 millions de wons. Trois fois plus que prévu initialement.
Cette entreprise a finalement opté pour un service de crawling par abonnement. La raison est simple : un forfait mensuel prévisible est meilleur pour les affaires que des coûts de maintenance imprévisibles.
Les 7 raisons du changement des sites web
1. Renouvellement du frontend
La raison la plus courante. Les entreprises changent régulièrement leur frontend pour améliorer l'expérience utilisateur, modifier leur image de marque et optimiser les performances.
- Fréquence : Les grands sites se renouvellent tous les trimestres à semestres
- Impact : La structure HTML, les noms de classe CSS, l'ensemble de l'arborescence DOM changent
- Impact sur le crawler : Le parsing basé sur les sélecteurs est complètement cassé
Les grands sites comme Naver, Coupang, 11th Street changent particulièrement souvent leur frontend. Depuis l'introduction de frameworks SPA comme React et Vue.js, le crawling est devenu beaucoup plus difficile avec la combinaison de SSR et CSR.
2. Tests A/B
Les grands sites effectuent toujours des tests A/B. Même URL, mais des HTML différents sont renvoyés à chaque utilisateur.
- Fréquence : En continu (des dizaines de tests simultanés)
- Impact : Même page mais structure différente à chaque visite
- Impact sur le crawler : Les résultats varient à chaque collecte, rendant le débogage difficile
Beaucoup de cas de "fonctionnait bien hier mais pas aujourd'hui" sont dus aux tests A/B. Les structures DOM peuvent être complètement différentes en fonction du groupe de test.
3. Renforcement de la détection/blocage des bots
Les sites web améliorent constamment leurs systèmes de détection des bots.
- Technologies : Cloudflare, Akamai Bot Manager, PerimeterX, DataDome
- Méthodes de détection : Modèles d'IP, empreintes de navigateur, analyse comportementale, challenge JavaScript
- Fréquence des mises à jour : Changement des règles chaque mois à tous les deux mois
En particulier, Naver et Coupang en Corée exploitent leurs propres systèmes de détection de bots, renforçant continuellement les règles de blocage. Ce qui passait hier en termes d'User-Agent et d'en-têtes peut être bloqué aujourd'hui.
4. Modification des points de terminaison de l'API
Même si le frontend reste le même, un changement dans l'API interne peut casser le crawler.
- Formes : Mise à jour de la version de l'API, modification des paramètres, changement de la structure de réponse
- Fréquence : À chaque déploiement backend (1 à 2 fois par semaine)
- Impact sur le crawler : Échec d'analyse JSON, modification du mode d'authentification
Les crawlers qui appellent directement des API REST sont particulièrement vulnérables. Les entreprises ne rendent pas leurs API internes publiques, donc les changements sont imprévisibles.
5. Changement des politiques d'authentification/sécurité
Les sites nécessitant une connexion modifient régulièrement leurs méthodes d'authentification.
- Formes : Ajout de l'authentification à deux facteurs, raccourcissement du délai d'expiration de la session, ajout de CAPTCHA, modification du mode de token
- Fréquence : Trimestrielle à semestrielle
- Impact sur le crawler : L'automatisation de la connexion est cassée
Les sites financiers et gouvernementaux renforcent fréquemment leur sécurité, et les changements sont souvent appliqués sans annonce préalable.
6. Changement de la méthode de chargement du contenu dynamique
Les méthodes de chargement du contenu avec JavaScript deviennent de plus en plus complexes.
- Formes : Chargement paresseux, défilement infini, mises à jour en temps réel basées sur WebSocket
- Tendances : HTML statique → AJAX → SPA → Hybride SSR/ISR
- Impact sur le crawler : Impossible de récupérer les données avec de simples requêtes HTTP
Le nombre de sites nécessitant l'utilisation de navigateurs sans tête (Puppeteer, Playwright) augmente chaque année, ce qui augmente considérablement les coûts et la complexité du crawling.
7. Changements légaux/politiques
Les changements dans le fichier robots.txt, les mises à jour des conditions d'utilisation, le renforcement des restrictions d'accès affectent également les crawlers.
- Formes : Ajout de restrictions de crawling dans le robots.txt, renforcement des limites de taux, restrictions d'accès par région
- Fréquence : Tous les six mois à un an
- Impact sur le crawler : La portée légale de la collecte de données se rétrécit
Fréquence des changements par site - Observations sur 7 ans
Hashscraper a crawlé plus de 5 000 sites au cours des 7 dernières années. Voici la fréquence des changements par type de site basée sur cette expérience :
| Type de site | Fréquence de renouvellement du frontend | Fréquence de modification du crawler nécessaire |
|---|---|---|
| Grandes plateformes de commerce électronique (Coupang, 11th Street) | Hebdomadaire à bimensuelle | 2 à 4 fois par mois |
| Portails (Naver, Daum) | Bimensuelle à mensuelle | 1 à 2 fois par mois |
| Réseaux sociaux (Instagram, X) | Mensuelle à bimensuelle | 1 à 2 fois par mois |
| Organismes publics/financiers | Trimestrielle à semestrielle | Trimestrielle à semestrielle |
| Petites boutiques en ligne | Semestrielle à annuelle | Semestrielle à bimensuelle |
Point clé : Plus le site est grand, plus les changements sont fréquents. Si vous exploitez 10 crawlers, vous devrez en réviser au moins 1 à 2 chaque semaine.
Notre crawler d'entreprise est-il fiable ? - Auto-diagnostic
Si trois des éléments suivants s'appliquent, il est temps de revoir votre stratégie de maintenance du crawler :
- [ ] Le crawler a soudainement cessé de fonctionner au cours des 3 derniers mois
- [ ] Un développeur doit modifier le code à chaque changement sur le site
- [ ] Il a fallu plus de 24 heures pour détecter une panne du crawler
- [ ] Les coûts de proxy augmentent progressivement
- [ ] Vous utilisez un service externe en raison de la contournement des CAPTCHA
- [ ] Une seule personne comprend le code du crawler
- [ ] Vous consacrez plus de 4 heures par jour à la maintenance du crawler
Si cinq éléments ou plus s'appliquent : Il est probable que vos coûts actuels soient plus élevés que ceux d'un service professionnel.
Coûts cachés de la maintenance du crawler
Les coûts réels de l'exploitation directe d'un crawler.
Coûts de développement initial
| Élément | Coût |
|---|---|
| Développement du crawler (site simple) | 50 à 100 000 wons |
| Développement du crawler (site complexe) | 200 à 500 000 wons |
| Configuration du navigateur sans tête | +50 à 100 000 wons |
| Mise en place de proxy/blocage | +50 à 200 000 wons |
Coûts annuels de maintenance (pour un crawler)
| Élément | Coût mensuel | Coût annuel |
|---|---|---|
| Adaptation aux changements du site (1 à 2 fois par mois) | 50 à 100 000 wons | 600 à 1 200 000 wons |
| Serveur/infrastructure | 10 à 30 000 wons | 120 à 360 000 wons |
| Coût du proxy | 10 à 50 000 wons | 120 à 600 000 wons |
| Surveillance/gestion des pannes | 20 à 50 000 wons | 240 à 600 000 wons |
| Total | 90 à 230 000 wons | 1 080 à 2 760 000 wons |
Si vous exploitez 10 crawlers, cela représente entre 10 millions et 28 millions de wons par an. En ajoutant les coûts de l'ingénieur développeur (de 6 à 12 millions de wons par an), les coûts réels de l'exploitation directe deviennent évidents.
Comparaison des solutions
| Solution | Coût | Rapidité de mise en œuvre | Avantages | Inconvénients |
|---|---|---|---|---|
| Embauche d'un personnel dédié | 6 à 12 millions de wons par an | Immédiat | Contrôle total | Difficulté de recrutement, limite d'une personne |
| Externalisation en cas de problème | 50 à 150 000 wons par tâche | 3 à 7 jours | Coût uniquement en cas de besoin | Lent, variations de qualité |
| Service par abonnement | À partir de 300 000 wons par mois | Moins de 24 heures | Prévisibilité, expertise disponible | Pas de propriété de code |
| Self-service basé sur des crédits | À partir de 30 000 wons par mois | Immédiat (avec prépaiement) | Économique, démarrage rapide | Limité à un site |
1 à 2 crawlers : Externalisation ou self-service basé sur des crédits suffisent.
3 crawlers ou plus : Un personnel dédié ou un service par abonnement est plus rentable.
Pour commencer : Le self-service basé sur des crédits est abordable à partir de 30 000 wons par mois, idéal pour les tests sans engagement financier.
Conclusion
Un crawler n'est pas une solution ponctuelle. Le web est un écosystème vivant et les sites changent chaque semaine.
La question clé n'est pas "comment éliminer la maintenance", mais "qui, avec quelle structure et à quel coût assurera la maintenance".
En calculant honnêtement les coûts cachés de l'exploitation directe, la réponse est souvent surprenante.
Prochaines étapes
- Tester avec des crédits - À partir de 30 000 wons par mois, utilisez immédiatement des bots prépayés
- Consultation gratuite sur abonnement - Si vous avez besoin d'un crawling personnalisé
Si vous souhaitez vous concentrer uniquement sur les données sans vous soucier de la maintenance, Hashscraper est là pour vous.
Hashscraper - Équipe d'experts ayant crawlé plus de 5 000 sites en 7 ans
