La surveillance manuelle des appels d'offres sur les plateformes EIS (Zakupki.gov.ru), Sberbank-AST, RTS-tender prend 3 à 5 heures par jour. L'automatisation via des parseurs résout le problème, mais les plateformes gouvernementales bloquent activement les requêtes automatiques — l'IP est bannie après 50 à 100 requêtes. Les proxies permettent de contourner ces restrictions et de collecter des données sur les nouveaux appels d'offres 24 heures sur 24 sans risque de blocage de l'IP principale de l'entreprise.
Dans ce guide, nous allons examiner : quels proxies conviennent à différentes plateformes d'appels d'offres, comment configurer un parsing automatique sans blocages, quels outils prêts à l'emploi utiliser et comment éviter les erreurs typiques qui mènent à un bannissement.
Pourquoi les plateformes d'appels d'offres bloquent-elles les requêtes automatiques
Les plateformes d'appels d'offres publiques et commerciales utilisent une protection à plusieurs niveaux contre la collecte automatique de données. Cela est dû à plusieurs raisons : la charge sur les serveurs causée par les parseurs peut atteindre 60 à 70 % du trafic total, les concurrents utilisent les données collectées pour le dumping, et il existe également des exigences en matière de protection des données personnelles des participants aux achats.
Le système d'information unifié (EIS) est la plateforme la plus protégée. Le système enregistre les paramètres suivants de chaque requête : adresse IP, User-Agent du navigateur, fréquence des requêtes, séquence d'actions sur le site. Si plus de 100 requêtes proviennent d'une même IP par heure ou si les requêtes sont trop régulières (par exemple, toutes les 5 secondes), l'IP est bloquée pendant 24 à 72 heures. Le blocage s'applique à toute la plage de sous-réseau, donc toute l'entreprise peut être affectée.
Les plateformes commerciales (Sberbank-AST, RTS-tender, Fabriquant) utilisent une protection plus douce, mais surveillent également l'activité suspecte. Les principaux déclencheurs de blocage : absence de cookies, JavaScript désactivé, navigation trop rapide entre les pages (moins de 2 secondes par page), intervalles de temps identiques entre les requêtes.
Cas réel : Une entreprise de fourniture d'équipements a configuré un parseur pour surveiller les appels d'offres sur l'EIS sans proxy. Au cours des 2 premières heures de fonctionnement, le parseur a collecté des données sur 340 appels d'offres, mais ensuite l'IP du bureau a été bloquée. Les employés n'ont pas pu accéder à leur compte personnel EIS pour soumettre des offres pendant 48 heures. L'entreprise a manqué 3 appels d'offres importants d'une valeur totale de 12 millions de roubles.
Quel type de proxy choisir pour la surveillance des appels d'offres
Pour la surveillance des plateformes d'appels d'offres, trois types de proxies conviennent, chacun ayant ses propres caractéristiques d'application. Le choix dépend du volume de parsing, du budget et des exigences en matière de fiabilité.
| Type de proxy | Fiabilité pour l'EIS | Vitesse | Application |
|---|---|---|---|
| Proxies de centre de données | Moyenne (bloqués plus souvent) | Très élevée (50-100 ms) | Plateformes commerciales, tests |
| Proxies résidentiels | Élevée (IP réelles) | Moyenne (200-500 ms) | EIS, Sberbank-AST, parsing 24/7 |
| Proxies mobiles | Maximale (IP des opérateurs) | Moyenne (300-600 ms) | EIS avec des exigences élevées en matière de fiabilité |
Proxies résidentiels — le choix optimal pour la plupart des tâches de surveillance des appels d'offres. Ils utilisent des adresses IP d'utilisateurs domestiques réels, donc les plateformes perçoivent les requêtes comme des actions de personnes ordinaires. Pour l'EIS, il est recommandé d'utiliser des proxies résidentiels russes avec une rotation toutes les 10-15 minutes. Cela permet de collecter des données sur 500 à 1000 appels d'offres par jour sans aucun blocage.
Proxies de centre de données conviennent aux plateformes commerciales moins protégées : RTS-tender, Fabriquant, B2B-Center. Ils sont 3 à 5 fois moins chers que les résidentiels et fonctionnent plus rapidement, mais l'EIS reconnaît souvent et bloque ces IP. Utilisez-les pour des tests initiaux du parseur ou pour surveiller de petites plateformes régionales.
Proxies mobiles ont le niveau de confiance maximal, car ils utilisent des IP des opérateurs mobiles (MTS, Beeline, Megafon). Les plateformes ne bloquent presque jamais ces adresses, car derrière une IP d'opérateur peuvent se cacher des milliers d'utilisateurs réels. Inconvénient — coût plus élevé. Utilisez des proxies mobiles si vous travaillez avec des appels d'offres particulièrement précieux ou si vous avez déjà été bloqué en utilisant des proxies résidentiels.
Particularités de la protection des différentes plateformes : EIS, Sberbank-AST, RTS-tender
Chaque plateforme d'appels d'offres a ses propres caractéristiques de protection contre le parsing. Comprendre ces mécanismes permet de configurer le parseur de manière à minimiser le risque de blocage.
EIS (Zakupki.gov.ru) — protection maximale
Le système d'information unifié utilise la protection la plus stricte parmi toutes les plateformes. Les principaux mécanismes : limite de 100 requêtes par heure depuis une même IP, support obligatoire des cookies et de JavaScript, vérification du référent (d'où vient l'utilisateur), analyse des facteurs comportementaux (temps passé sur la page, mouvement de la souris, défilement).
Recommandations pour le parsing de l'EIS : utilisez des proxies résidentiels ou mobiles avec des IP russes, activez la rotation automatique des proxies toutes les 80-90 requêtes (pour ne pas atteindre la limite), ajoutez des délais aléatoires entre les requêtes de 3 à 8 secondes, utilisez des navigateurs sans tête (Puppeteer, Selenium) au lieu de simples requêtes HTTP — ils émuleraient complètement le comportement d'un navigateur réel.
Sberbank-AST — niveau de protection moyen
La plateforme Sberbank utilise des restrictions plus douces : limite d'environ 200-300 requêtes par heure, les cookies sont obligatoires, mais JavaScript n'est pas toujours vérifié, le blocage se produit en cas de comportement manifestement robotisé (intervalles identiques entre les requêtes, absence de référent).
Pour Sberbank-AST, des proxies résidentiels avec une rotation toutes les 200 requêtes suffisent. Vous pouvez utiliser des outils de parsing plus simples sans émulation complète du navigateur, mais ajoutez toujours des délais aléatoires de 2 à 5 secondes et des en-têtes User-Agent corrects.
RTS-tender, Fabriquant, B2B-Center — protection de base
Les plateformes commerciales ont une protection minimale : limites de 500+ requêtes par heure, la principale vérification est la présence de cookies et d'un User-Agent adéquat, elles bloquent rarement les proxies de centre de données.
Pour ces plateformes, même les proxies de centre de données avec une rotation de base conviennent. Vous pouvez utiliser des parseurs HTTP simples sans émulation de navigateur. L'essentiel est de ne pas envoyer des requêtes trop souvent (minimum 1-2 secondes entre les requêtes) et de changer périodiquement d'IP.
Outils prêts à l'emploi pour le parsing des appels d'offres sans programmation
Pour surveiller les appels d'offres, il n'est pas nécessaire d'écrire du code depuis zéro. Il existe des solutions prêtes à l'emploi avec une interface graphique qui prennent en charge le travail via des proxies.
Octoparse — un parseur visuel avec support des proxies et un planificateur de tâches. Il permet de créer un parseur pour n'importe quelle plateforme d'appels d'offres via une interface graphique : vous cliquez simplement sur les éléments de la page à collecter (numéro d'appel d'offres, client, montant, date de fin), et le programme crée automatiquement l'algorithme de parsing. Dans les paramètres, vous pouvez spécifier la liste des proxies, et Octoparse les fera automatiquement tourner. Coût — à partir de 75 $/mois, il existe une version gratuite avec des limitations.
ParseHub — un analogue d'Octoparse avec une interface plus simple. Bien adapté aux débutants. Prend en charge les sites JavaScript (important pour l'EIS), le travail via des proxies, l'exportation des données vers Excel/Google Sheets. La version gratuite permet de créer jusqu'à 5 projets de parsing. La version payante — à partir de 149 $/mois avec la possibilité de lancer le parsing selon un calendrier (par exemple, vérifier les nouveaux appels d'offres toutes les 2 heures).
Screaming Frog SEO Spider — à l'origine un outil pour le SEO, mais excellent pour le parsing de données structurées. Prend en charge les proxies, peut collecter des données à partir de pages selon des sélecteurs CSS spécifiés. Inconvénient — nécessite un peu de compréhension de la structure HTML des pages. Coût — 149 £/an (environ 15 000 roubles), ce qui est moins cher que les équivalents.
Services spécialisés de surveillance des appels d'offres — Kontur.Zakupki, Tender.Pro, B2B-Center ont déjà des systèmes de surveillance intégrés avec des filtres et des notifications. Ils ne nécessitent pas de configuration de proxies, car ils fonctionnent au nom du service. Coût — de 5 000 à 30 000 roubles par mois en fonction du nombre de catégories suivies. Inconvénient — vous dépendez des capacités du service et ne pouvez pas collecter de données supplémentaires ou les intégrer dans votre CRM.
Recommandation pour le choix de l'outil :
- Pour les débutants sans compétences techniques — ParseHub ou Octoparse
- Pour le parsing de 3 à 5 plateformes avec intégration dans la CRM — Screaming Frog + configuration de l'exportation
- Pour surveiller uniquement l'EIS sans données supplémentaires — services spécialisés
- Pour des tâches complexes (analyse de la documentation des appels d'offres, parsing de fichiers joints) — développement en Python avec Selenium
Configuration étape par étape de la surveillance via des proxies en 20 minutes
Examinons la configuration de la surveillance automatique des appels d'offres en prenant Octoparse comme exemple — l'un des outils les plus populaires avec une interface graphique. Cet exemple convient pour surveiller l'EIS, Sberbank-AST et d'autres plateformes.
Étape 1 : Obtention de proxies. Inscrivez-vous auprès d'un fournisseur de proxies et obtenez une liste d'adresses IP avec ports et données d'authentification. Pour surveiller l'EIS, il est recommandé d'avoir au moins 10 proxies résidentiels russes avec rotation automatique. Le fournisseur vous fournira les données au format : IP:PORT:USERNAME:PASSWORD (par exemple, 185.123.45.67:8000:user123:pass456).
Étape 2 : Installation et configuration d'Octoparse. Téléchargez Octoparse depuis le site officiel et installez-le sur votre ordinateur. Après le lancement, créez un nouveau projet de parsing en entrant l'URL de la page avec les résultats de recherche d'appels d'offres sur l'EIS (par exemple, recherche par mot-clé "équipement" dans votre région).
Étape 3 : Configuration des proxies dans Octoparse. Ouvrez Paramètres → Paramètres de proxy. Sélectionnez le mode "Utiliser un proxy personnalisé". Ajoutez vos proxies à la liste en indiquant l'IP, le port, le type (HTTP ou SOCKS5), le nom d'utilisateur et le mot de passe. Activez l'option "Changer de proxy pour chaque requête" — cela obligera le programme à changer de proxy après chaque requête, répartissant la charge et évitant les blocages.
Étape 4 : Création de l'algorithme de parsing. En mode constructeur visuel, cliquez sur les éléments de la page à collecter : numéro d'appel d'offres, nom, client, prix de départ, date de fin de soumission, région. Octoparse déterminera automatiquement la structure des données et créera l'algorithme de collecte. Vérifiez le résultat sur les 5 à 10 premières entrées — le programme affichera un aperçu du résultat du parsing.
Étape 5 : Configuration de la pagination. Les plateformes d'appels d'offres affichent les résultats page par page (généralement 10-50 appels d'offres par page). Dans Octoparse, ajoutez l'action "Cliquer sur le bouton de pagination" et indiquez le bouton "Page suivante". Le programme passera automatiquement d'une page à l'autre et collectera tous les résultats.
Étape 6 : Ajout de délais. Dans les paramètres du parseur, définissez des délais aléatoires entre les requêtes : minimum 3 secondes, maximum 8 secondes. Cela imite le comportement d'un utilisateur réel et réduit le risque de blocage. Ajoutez également un délai de 5 à 10 secondes après le chargement de chaque page — cela donne le temps aux éléments JavaScript de se charger complètement.
Étape 7 : Configuration du calendrier. Dans la section "Calendrier des tâches", configurez le lancement automatique du parsing. Pour surveiller les nouveaux appels d'offres, il est optimal de lancer la vérification toutes les 2 à 4 heures pendant les heures de travail. Par exemple : 9h00, 13h00, 17h00, 21h00. Cela permettra de suivre les nouvelles publications tout au long de la journée sans surcharge excessive de la plateforme.
Étape 8 : Exportation des données. Configurez l'exportation automatique des données collectées dans un format pratique : Excel, Google Sheets, base de données MySQL ou envoi par API vers votre système CRM. Octoparse peut automatiquement envoyer de nouvelles données après chaque lancement du parseur, ce qui permet de recevoir des notifications sur les nouveaux appels d'offres en temps réel.
Configuration de la rotation des proxies et des délais entre les requêtes
Une configuration correcte de la rotation des proxies et des délais est un facteur clé pour un parsing réussi sans blocages. Même avec des proxies de qualité, une mauvaise configuration entraînera un bannissement.
Stratégies de rotation des proxies : Il existe trois approches principales pour changer d'adresses IP pendant le parsing.
Rotation après chaque requête — la méthode la plus sûre, mais lente. Chaque requête à la plateforme provient d'une nouvelle IP. Convient pour l'EIS lors du parsing de grands volumes de données (1000+ appels d'offres). Inconvénient — augmente le temps de parsing, car l'établissement d'une nouvelle connexion via un proxy prend 200-500 ms.
Rotation par nombre de requêtes — un équilibre optimal entre vitesse et sécurité. Un proxy est utilisé pour 50-100 requêtes, puis changé pour le suivant. Pour l'EIS, il est recommandé de changer de proxy toutes les 80 requêtes (juste en dessous de la limite de 100). Pour les plateformes commerciales, vous pouvez augmenter à 200-300 requêtes par IP.
Rotation par temps — changement d'IP toutes les 10-15 minutes, indépendamment du nombre de requêtes. Convient pour un parsing prolongé avec une faible intensité (par exemple, surveillance des mises à jour tout au long de la journée). Certains fournisseurs de proxies offrent une rotation automatique par temps — vous obtenez une seule URL de proxy, mais l'IP change automatiquement toutes les N minutes.
Configuration des délais entre les requêtes : Un humain ne peut pas passer instantanément d'une page à l'autre — il a besoin de temps pour lire, faire défiler, cliquer. Le parseur doit imiter ce comportement.
| Plateforme | Délai entre les requêtes | Délai après le chargement de la page |
|---|---|---|
| EIS (Zakupki.gov.ru) | 3-8 secondes (aléatoire) | 5-10 secondes |
| Sberbank-AST | 2-5 secondes (aléatoire) | 3-7 secondes |
| RTS-tender, Fabriquant | 1-3 secondes (aléatoire) | 2-4 secondes |
Il est important d'utiliser des délais aléatoires dans la plage indiquée. Si le parseur effectue des requêtes exactement toutes les 5 secondes, le système de protection identifiera facilement le robot. La fonction de délai aléatoire est présente dans tous les outils de parsing populaires.
Conseil : Ajoutez un "mode nuit" pour le parsing. De 23h00 à 7h00, vous pouvez augmenter l'intensité des requêtes (réduire les délais), car à ce moment-là, l'activité des utilisateurs réels sur les plateformes est minimale, et les systèmes de protection fonctionnent moins strictement. Cela permettra de collecter plus de données dans le même temps.
Erreurs typiques qui mènent au blocage
Même en utilisant des proxies de qualité, un parseur peut être bloqué en raison d'erreurs techniques dans la configuration. Voici les problèmes les plus courants et comment les résoudre.
Erreur 1 : Utilisation du même User-Agent. Le User-Agent est une chaîne qui informe le site du navigateur et du système d'exploitation utilisés. Si toutes les requêtes proviennent du même User-Agent (par exemple, celui par défaut de la bibliothèque requests de Python), c'est un signe évident de robot. Solution : utilisez une liste de 10 à 20 User-Agent populaires pour différents navigateurs (Chrome, Firefox, Safari) et systèmes d'exploitation (Windows, macOS, Linux), et faites-les tourner de manière aléatoire à chaque requête.
Erreur 2 : Cookies désactivés. La plupart des sites installent des cookies lors de la première visite et vérifient leur présence lors des requêtes suivantes. Si le parseur ne conserve pas les cookies, chaque requête ressemble à une première visite depuis un nouvel appareil, ce qui est suspect. Solution : activez le support des cookies dans les paramètres du parseur. Dans Octoparse et ParseHub, cela se fait automatiquement. Si vous écrivez votre propre parseur en Python, utilisez la bibliothèque requests.Session() — elle conserve automatiquement les cookies entre les requêtes.
Erreur 3 : Parsing sans exécution de JavaScript. Les sites modernes, y compris l'EIS, utilisent activement JavaScript pour charger le contenu. Si le parseur télécharge simplement le code HTML de la page sans exécuter JavaScript, il obtiendra des données incomplètes, et le serveur enregistrera un comportement suspect. Solution : utilisez des navigateurs sans tête (Puppeteer, Selenium, Playwright) qui chargent complètement la page, exécutent JavaScript et peuvent même faire défiler la page pour charger du contenu dynamique.
Erreur 4 : Ignorer le captcha. Certaines plateformes affichent un captcha lors d'une activité suspecte. Si le parseur ne peut pas résoudre le captcha, il se bloquera et commencera à envoyer des requêtes répétées, ce qui entraînera le blocage de l'IP. Solution : utilisez des services de résolution automatique de captcha (2Captcha, Anti-Captcha) — ils coûtent environ 1 à 3 $ pour 1000 captchas résolus. La plupart des outils de parsing ont une intégration intégrée avec ces services.
Erreur 5 : Parsing pendant les heures de pointe. De 10h00 à 16h00 les jours ouvrables, l'activité des utilisateurs sur les plateformes d'appels d'offres est maximale, et les systèmes de protection fonctionnent de manière stricte. Un parsing intensif à ce moment-là entraînera plus rapidement un blocage. Solution : lancez la majorité du parsing le soir (18h00-23h00) ou la nuit. Pendant les heures de travail, effectuez uniquement des vérifications ponctuelles des nouveaux appels d'offres avec une intensité minimale.
Erreur 6 : Utilisation de proxies "sales". Certains fournisseurs de proxies bon marché vendent des IP qui ont déjà été utilisées pour du spam ou d'autres activités suspectes et se trouvent sur des listes noires. Solution : testez les proxies avant une utilisation massive. Envoyez 20 à 30 requêtes de test à la plateforme depuis chaque nouveau proxy et vérifiez s'il y a un captcha ou un blocage. Si le proxy est "sale", remplacez-le auprès du fournisseur.
Mise à l'échelle : surveillance de 10+ plateformes simultanément
Lorsque la surveillance de base d'une ou deux plateformes est configurée et fonctionne de manière stable, la question de la mise à l'échelle se pose — parsing simultané de dizaines de plateformes d'appels d'offres pour obtenir une couverture maximale du marché.
Distribution des proxies entre les plateformes. N'utilisez pas les mêmes proxies pour différentes plateformes en même temps. Créez des pools de proxies : par exemple, 10 proxies pour l'EIS, 5 pour Sberbank-AST, 5 pour RTS-tender, etc. Cela empêchera une situation où un blocage sur une plateforme affecte le fonctionnement du parseur sur une autre.
Priorisation des plateformes. Toutes les plateformes d'appels d'offres ne sont pas également importantes pour votre entreprise. Identifiez 3 à 5 plateformes clés où sont publiés le plus d'appels d'offres pertinents et allouez-leur plus de ressources : meilleurs proxies, vérifications plus fréquentes, parsing plus détaillé (y compris la collecte de documentation). Pour les autres plateformes, utilisez une surveillance de base des paramètres principaux des appels d'offres.
Automatisation du traitement des données. Lors du parsing de 10+ plateformes, vous recevrez des centaines de nouveaux appels d'offres chaque jour. Le traitement manuel est impossible. Configurez un filtrage automatique : par mots-clés dans le titre de l'appel d'offres, par région du client, par plage de prix de départ, par date de fin de soumission. Seuls les appels d'offres ayant passé tous les filtres sont ajoutés à la liste pour une vérification manuelle.
Intégration avec la CRM et les systèmes de notification. Configurez l'envoi automatique des appels d'offres filtrés vers votre système CRM ou votre messager d'entreprise (Slack, Telegram, Microsoft Teams). Les gestionnaires recevront des notifications sur les nouveaux appels d'offres pertinents en temps réel et pourront rapidement prendre une décision de participation.
Surveillance du fonctionnement des parseurs. Lors de l'utilisation de plusieurs plateformes, il est crucial de suivre le statut de chaque parseur. Configurez un tableau de bord où il est visible : quand chaque parseur a été lancé pour la dernière fois, combien d'appels d'offres ont été collectés, s'il y a eu des erreurs ou des blocages. Des outils comme Octoparse ont des tableaux de bord intégrés. Si vous utilisez vos propres scripts, vous pouvez configurer une journalisation dans Google Sheets ou des systèmes de surveillance spécialisés comme Grafana.
Exemple d'un système de surveillance à grande échelle :
Une entreprise de fourniture de matériel informatique a configuré la surveillance de 15 plateformes d'appels d'offres : EIS, Sberbank-AST, RTS-tender, 8 plateformes régionales et 4 plateformes commerciales. 50 proxies résidentiels sont utilisés, répartis en pools. Les parseurs se lancent toutes les 2 heures et collectent en moyenne 600 nouveaux appels d'offres par jour. Des filtres automatiques par mots-clés ("ordinateur", "serveur", "équipement réseau") et par région (Moscou, région de Moscou, Saint-Pétersbourg) éliminent 85 % des appels d'offres non pertinents. Les 90 appels d'offres restants sont automatiquement envoyés dans le canal Telegram du département des ventes. Résultat : le temps consacré à la surveillance des appels d'offres a été réduit de 4 heures par jour à 30 minutes, et le nombre de soumissions a augmenté de 40 %.
Conclusion
L'automatisation de la surveillance des appels d'offres publics et commerciaux via des proxies permet d'obtenir des informations sur les nouveaux achats en temps réel, d'économiser jusqu'à 4 heures par jour sur la recherche manuelle et d'augmenter le nombre de soumissions de 30 à 50 %. Les facteurs clés de succès : le choix correct du type de proxy en fonction de la plateforme, la configuration correcte de la rotation des IP et des délais entre les requêtes, l'utilisation d'outils prenant en charge JavaScript et les cookies.
Pour surveiller des plateformes protégées comme l'EIS, utilisez des proxies résidentiels ou mobiles avec des adresses IP russes — ils garantissent un niveau de confiance maximal et un risque minimal de blocages. Pour les plateformes commerciales avec une protection de base, des proxies de centre de données plus abordables conviendront. Commencez par automatiser 2-3 plateformes clés, perfectionnez les réglages, puis étendez le système à l'ensemble du marché des appels d'offres dans votre secteur.
Si vous envisagez de configurer une surveillance 24/7 des plateformes d'appels d'offres, nous vous recommandons d'utiliser des proxies résidentiels — ils assurent un fonctionnement stable des parseurs sans blocages même avec une intensité élevée de requêtes vers des plateformes gouvernementales protégées.