Analyse automatique depuis Chrome

L’analyse exacte d’un domaine est une surface différente du classement public. La route api/extension/analyze ne fait que METTRE EN FILE : l’extension ne transmet aucune donnée, elle demande à la plateforme de collecter un domaine inconnu, et la collecte tourne en arrière-plan. La session est obligatoire (l’extension exige un compte BoostEcom) ; le corps ne contient que domain (un storeId hérité est accepté et ignoré). Les écritures passent par le contrôle d’origine de withSessionAuth, qui accepte l’origine de la plateforme et l’origine exacte de l’extension publiée (chrome-extension://<EXTENSION_ID>, aucune autre, aucun joker) : le service worker peut donc mettre en file sans onglet plateforme ouvert. Ce n’est pas une authentification, le cookie de session reste exigé. Appel côté extension : fetch(url, { method: "POST", credentials: "include", headers: { "Content-Type": "application/json" }, body: JSON.stringify({ domain }) }) ; le GET de lecture n’est pas soumis au contrôle d’origine et n’a besoin que de credentials: "include".

extension-analysis.ts lit seulement l’état : fiche PUBLIC (colonne de visibilité, sans le blob du record), préférence de la boutique propriétaire (Store.intelligenceVisibility), suppressions et tombstones. Il ne renvoie jamais de fiche. Quand la fiche est lisible, la route la sert via redactHubStore puis applyReadBudget, comme le lookup (access.reason: "daily_read_budget" quand le budget du jour est épuisé).

Les absences et rafraîchissements alimentent IntelligenceDiscoveryCandidate. La réservation atomique exclut le cron et les requêtes simultanées. Le job signé intelligence-scan-store délègue les claims d’origine extension-analysis au worker dédié. Celui-ci vérifie la réservation, contrôle le site indépendamment du navigateur, réserve les budgets existants puis exécute les sondes publiques sans connecteur marchand. Les sources marquées comme nécessitant un contournement anti-bot sont refusées dans ce contexte automatique.

L’état analyzed garde un résultat 24 heures avant un nouveau passage ; les sondes ont leurs propres règles de fraîcheur. analysis_waiting rend un candidat de nouveau dû après une minute pour récupérer un run fournisseur en cours. Les autres erreurs utilisent le backoff existant. Une expiration de réservation remet les crashs dans le parcours du cron de découverte. Une publication QStash réussie n’est jamais assimilée à une collecte terminée.

L’extension rend ses observations locales avant cette opération, puis lit l’état sans relancer le scan. L’authentification passe par un onglet plateforme de même origine, existant ou temporaire inactif. Le document /api/extension/bridge ne contient ni script, ni session, ni donnée de compte. Il ne modifie rien par GET.

Contrat de la route

POST /api/extension/analyze avec { "domain": "store.example" } met en file ; GET /api/extension/analyze?domain=… lit l’état sans rien mettre en file. Réponse :

Erreurs : 400 invalid_body, 400 invalid_domain (nom d’hôte seul : ni IP, ni localhost, ni TLD réservé ou numérique, ni port, chemin ou identifiants), 401, 429.

Bornes

• Par utilisateur : 30 écritures et 120 lectures par minute ; 300 nouveaux domaines par jour (clé user:<id>).
• Par adresse (le /64 en IPv6) : 2 000 nouveaux domaines par jour, une couche grossière pour une sortie partagée.
• Un seul bail par domaine et par jour : une demande répétée est gratuite et ne consomme aucun budget.
• Budget AUTOMATIQUE de collecte (lib/hub/scan-capacity.ts) : 1 500 collectes par jour, comptées aussi dans le plafond global de 5 000. L’extension ne peut donc jamais prendre la réserve interactive (au moins 3 500 par jour pour la recherche web et les clics explicites) ; elle est la première à recevoir un refus. Le scan Hub applique le même budget quand le client envoie X-Boost-Scan-Trigger: auto.
• Disjoncteur : aucun nouveau domaine n’est accepté tant que la file contient 20 000 candidats dus ou plus (le seuil où le tick de découverte suspend la moisson).
• Aucune variable d’environnement : ce sont des constantes.

Qui collecte, et en combien de temps

La route ne collecte rien. Elle crée le candidat (source = extension-analysis) avec une réservation de 10 minutes puis publie le job intelligence-scan-store sur QStash. Le worker vérifie le site indépendamment du navigateur (vivacité, redirections, garde SSRF, opt-out, propriétaire), puis lance les sondes publiques sous les plafonds existants de on-demand-budget.ts.

• Avec QStash : le worker démarre en quelques secondes et un scan complet dure de quelques dizaines de secondes à quelques minutes ; la fiche apparaît dans le lookup à l’ouverture suivante, en général dans les deux minutes.
• Les runs fournisseurs asynchrones (publicités, trafic) sont récupérés par le tick discovery-harvest-tick (toutes les 15 minutes : 7,22,37,52), donc jusqu’à un quart d’heure de plus pour ces champs.
• Sans QStash ou file indisponible : le candidat est différé de 15 minutes et le même tick le reprend ; compter 15 à 30 minutes. Ce tick sert aussi la moisson de découverte, plus ancienne dans la file : en cas de panne prolongée de QStash, la reprise peut être plus lente.

Cette route ne remplace pas le scan public existant, les connexions privées ou les règles de sélection de la liste. Elle ne garantit pas la disponibilité de trafic ou de publicités pour chaque domaine. Voir l’audit et les sources.