Analyseur d'appel d'offres avec ETP (rendu JS, antibot) avec normalisation et téléchargement vers les alertes PostgreSQL et Telegram

Situation initiale : la direction des achats suit quotidiennement les nouveaux appels d'offres sur 6 plateformes de négociation électronique (ETP). Actuellement, cela se fait manuellement dans un navigateur avec des filtres, c'est pourquoi certains achats pertinents sont manqués et les données des différents ETP ne sont pas regroupées sous une forme unique.

Environnement technique et limitations : serveur Linux (Ubuntu 22.04), accès via SSH. Autorisé à utiliser Python 3.11, Playwright ou Selenium, requêtes/httpx, PostgreSQL 14 (la base de données existe déjà). Docker est possible, mais pas obligatoire. Vous ne pouvez pas utiliser de services anti-captcha payants et vous ne pouvez pas stocker les informations d'identification des comptes personnels en texte clair. Accès à ETP uniquement en tant qu'invité, sans autorisation. Certains sites chargent du contenu avec JavaScript, disposent d'une protection anti-bot et de limites sur la fréquence des requêtes.

Domaine : appels d'offres/achats. Il est nécessaire de collecter les cartes d'achat et les lots, de normaliser les catégories et les montants et de sauvegarder un historique des modifications.

Ce qui devrait arriver : un analyseur autonome qui collecte des données selon un calendrier à partir de 6 ETP spécifiés (je fournirai une liste de domaines et des exemples de liens vers les résultats de recherche), les amène à un schéma commun et les ajoute à PostgreSQL, et envoie également des notifications à Telegram lorsque de nouveaux achats pertinents apparaissent.

Étapes et exigences clés :
1) Analyse des sources - pour chaque ETP, déterminer la méthode de chargement (rendu XHR/GraphQL/HTML/JS), les points d'entrée pour l'émission et les cartes, un ensemble de champs, les limites de vitesse.
2) Implémentation de l'assembleur - modules adaptateurs séparés pour chaque source avec une seule interface. Les replays, les backoffs, les délais d'attente, la limitation de concurrence, la rotation User-Agent, le travail via un proxy (je fournirai un proxy) et la résistance aux pannes partielles doivent être pris en charge.
3) Normalisation des données - un modèle unique dans la base de données : achat, lot, client, région, dates (publication/fin), NMC/devise, statut, lien, site, description textuelle, CPV/OKPD2 (le cas échéant), ainsi qu'un champ de pertinence calculé pour les mots-clés et les mots d'exclusion (je fournirai une liste). Réduisez les montants en chiffres, les dates en UTC, supprimez les publicités en double entre les ETP à l'aide d'un ensemble d'heuristiques (TIN du client + montant + dates + similitude de nom).
4) Stockage de l'historique - lorsque le statut ou la date de fin change, une nouvelle entrée dans la table d'historique avec un horodatage et des champs modifiés doit être enregistrée.
5) Notifications - Le bot Telegram envoie un message concernant les nouveaux achats pertinents, pas plus d'une notification par achat, avec des champs courts et un lien. La commande /health renvoie également des statistiques de la dernière exécution (combien a été collecté par source, combien d'erreurs, heure).
6) Fonctionnement - lancement via cron ou systemd timer, connexion à un fichier, effacement des messages d'erreur pour chaque source.

Sortie spécifique : un référentiel avec le code source, la configuration (env/ini/yaml), les migrations de schéma SQL, les instructions d'exécution sur Ubuntu et un exemple de configuration de filtre de pertinence.

Critères d'acceptation mesurables :
- Lors d'un test, dans les 24 heures, l'analyseur collecte au moins 95% des annonces des résultats de recherche pour chaque source dans les 3 premières pages (vérifié par calcul manuel sur un échantillon de 30 annonces par source).
- Les doublons dans la base de données ne dépassent pas 2% du nombre total d'enregistrements par exécution (vérification à l'aide d'une clé unique et heuristiques de déduplication).
- Les lancements répétés sur les mêmes filtres ne créent pas de nouveaux enregistrements d'achat s'il n'y a pas de changement dans les sources, et l'historique n'est mis à jour que lorsque les champs sont réellement modifiés.
- La durée d'exécution complète pour toutes les sources ne dépasse pas 45 minutes sur un serveur de 2 vCPU/4 Go de RAM avec une limite de 3 tâches parallèles maximum.
- Les journaux contiennent des statistiques distinctes par code source et motif d'erreur (délai d'expiration, blocage, analyse, structure modifiée).

De plus : je fournirai une liste d'ETP, des exemples d'URL, des mots-clés et un accès à la base de données de test après avoir convenu de l'approche et de la structure des données.