Comment fonctionne la surveillance

Page Deltas exécute vos surveillances selon un planning adaptatif, récupère chaque page avec la méthode la plus légère qui fonctionne, et utilise un filtre LLM pour que vous ne receviez que les alertes qui comptent.

Le cycle de vie d'une vérification

1. Planification. Un planificateur central sélectionne les surveillances dont next_check_at est arrivé à échéance et place les tâches dans une file Postgres.
2. Récupération. Un worker prend la tâche et récupère la page (HTTP simple, puis un navigateur headless via un proxy datacenter, puis via un proxy résidentiel — voir ci-dessous).
3. Extraction. Le HTML est réduit à son contenu textuel principal. Les éléments répétitifs (navigation, pied de page, publicités) sont supprimés.
4. Hachage et comparaison. Un hachage normalisé est comparé à la dernière vérification. S'ils sont identiques, l'exécution s'arrête ici — pas d'appel au LLM.
5. Filtre LLM. Si le hachage a changé, le comparatif et votre description sont envoyés à un LLM qui détermine si le changement est pertinent.
6. Alerte. Les changements pertinents sont enregistrés dans monitor_changes et mis en file pour être distribués à chaque canal associé à la surveillance.

Planification adaptative

Vous ne définissez pas de fréquence de vérification. Le planificateur observe la fréquence réelle des changements d'une page et ajuste next_check_at en conséquence — plus vite quand des changements surviennent, plus lentement quand la page est inactive. Votre offre influence aussi la cadence : les offres supérieures bénéficient d'une priorité de planification plus élevée. Votre utilisation reste ainsi proportionnelle à la valeur que vous en retirez.

Escalade du récupérateur

Chaque vérification démarre de manière économique et n'escalade que si nécessaire :

1. HTTP simple. Pas de JavaScript, pas de navigateur. Rapide et économique. Fonctionne pour la plupart des pages rendues côté serveur et des endpoints JSON.
2. Navigateur headless via proxy datacenter. Utilisé quand la page est rendue côté client ou quand la récupération simple est bloquée. Nous effectuons le rendu avec Camoufox — un Firefox furtif qui contourne la plupart des techniques de fingerprinting — routé via un proxy datacenter Oxylabs.
3. Navigateur headless via proxy résidentiel. Utilisé quand la récupération via proxy datacenter reste bloquée. Achemine la même requête du navigateur via des IP résidentielles Oxylabs.

Les octets acheminés via le proxy résidentiel sont comptabilisés par organisation, à titre de mesure de maîtrise des coûts.

Le filtre LLM

Quand le hachage du texte de la page change, nous n'alertons pas immédiatement. Nous envoyons d'abord le comparatif et la description de votre surveillance à un LLM avec une seule question : compte tenu de cette description, ce changement est-il pertinent ?

Ce que cela détecte

• Les changements de prix sur la page de tarifs d'un concurrent.
• Les lancements de nouveaux produits sur une feuille de route ou un changelog.
• Les changements d'offres d'emploi sur une page carrières que vous surveillez.

Ce que cela ignore

Les espaces et les éléments répétitifs (navigation, pied de page, publicités) sont supprimés avant le hachage : ils n'atteignent donc jamais le LLM. En plus de cela, le classifieur est paramétré pour considérer ce qui suit comme non pertinent :

• Les témoignages qui défilent, les publicités, les horodatages du type « ajouté il y a 3 jours » et les compteurs de vues.
• Les réorganisations sans changement de sens.
• Les hachages de build et les identifiants de session.