Catalogue public autonome, qualification et mesures de trafic

La décision 0036 remplace le préalable de plan connecté de la décision 0035, après clarification. Les boutiques clientes sont privées par défaut ; elles ne constituent ni la source ni le préalable du catalogue concurrentiel. Le moteur utilise ses propres collecteurs. Il ne dépend d'aucun catalogue tiers.

Trois populations distinctes

Le corpus peut conserver les anciennes observations et les boutiques devenues inactives sans les recommander. Une suppression opérateur demeure prioritaire. Une source publique redirigée vers une identité PRIVATE, UNLISTED ou ANONYMIZED ne déclenche pas d'enrichissement public de cette identité.

Admission et pertinence

Une boutique externe active peut donc entrer sans connexion Shopify. Un thème payant, du trafic ou des pixels ne sont pas des preuves de facturation Shopify. Les métadonnées de plan authentifiées restent disponibles pour les boutiques connectées, indépendamment de la qualification publique.

La qualification élimine les vitrines fermées, protégées, vides ou non confirmées. Le classement existant exploite ensuite les signaux réellement disponibles (trafic, publicités, croissance et couverture), sans inventer les données absentes. Une qualification active ne signifie pas « meilleure boutique au monde » ni rentabilité démontrée. Les boutiques headless sans catalogue public compatible peuvent rester inconnues ; aucune couverture de tout l'e-commerce n'est revendiquée.

Alimentation automatique et reprise

Le cron discovery-harvest-tick est programmé aux minutes 7, 22, 37 et 52. Il collecte des fenêtres bornées, les écrit dans la file persistante, puis avance les curseurs enregistrés dans CronExecution. Une page rejouée est dédupliquée sans réinitialiser les délais de réessai ou le verrou d'un travail en cours.

• Common Crawl : index et numéro de page conservés pendant un parcours, même pageSize pour la métadonnée et la lecture, curseur interne quand une page contient plus de candidats que la fenêtre. L'index suivant est choisi après la fin du parcours. Les requêtes d'index sont espacées et séquentielles.
• crt.sh : partitions de préfixes, puis curseur interne trié ; les certificats signalent des candidats, jamais une activité commerciale prouvée.
• Lectures directes bornées en durée et taille, sans proxy ni repli payant. Les réponses 429/503 suspendent la source. Une erreur ne valide pas une page vide.
• Au-delà de 20 000 candidats actuellement dus, les sources sont suspendues et la file continue d'être traitée. Les imports ne suppriment pas le reste à traiter.
• Chaque passage réserve au plus 400 candidats par une requête SQL atomique avec SKIP LOCKED. Le bail expire après dix minutes en cas d'arrêt du processus. Un ancien détenteur du bail ne peut plus terminer un travail repris ailleurs.
• Vérification de vitrine avant enrichissement, au plus douze en parallèle. Résolution des domaines canoniques, relecture de confidentialité et suppressions, déduplication des envois quotidiens par domaine.
• Envois QStash et réessais persistants. Si la file distante n'est pas prête, le repli est borné à douze vérifications et trois tentatives de scan par passage. Un échec d'envoi reste à reprendre ; il n'est pas compté comme enrichissement réussi.

Les crons de bootstrap et les tâches publiques automatisées utilisent le même contrôle d'activité et de confidentialité avant scan. Les enrichisseurs existants pour publicités, pages et contacts publics conservent leurs règles de source, de couverture et de budget. Ce lot ne crée pas de fournisseur pour des millions d'emails, de publicités ou de landing pages et n'augmente pas les budgets payants.

La file de candidats conserve ces états ; ils ne deviennent pas des fiches publiques inutiles. Les anciennes fiches canoniques restent suivies par le balayage de disponibilité distinct et son archivage réversible.

Actualisation et historique

La disponibilité se contrôle toutes les quinze minutes, sur les observations âgées de plus de dix-huit heures, par lots adaptés à la population et bornés à 5 000. Les preuves expirent aussi à la lecture si le cron s'arrête. Les requêtes et corps de réponse sont bornés ; une erreur réseau ne fabrique pas une fermeture. Les écritures datées empêchent une réponse lente d'écraser une observation récente. Trois échecs confirmés rendent isAlive faux ; l'archivage après trente jours conserve l'historique. Une reprise positive ne change pas une visibilité privée.

Les priorités d'enrichissement utilisent lastEnrichmentAttemptAt, indépendant d'updatedAt et de la disponibilité. Les échecs avancent aussi cette date pour éviter qu'un domaine défaillant monopolise les lots. Les voies publiques appliquent activité, confidentialité, demande et cooldown dans SQL avant LIMIT, sur toute la population admissible. Elles ne filtrent plus seulement un petit échantillon répété. Les voies HOT des propriétaires et les plafonds des scans payants restent séparés du catalogue public.

Débit et limites mesurables

Le plafond de sélection de découverte est 400 × 96 = 38 400 candidats par jour, avant latences, reprises et limites des fournisseurs. Ce n'est pas un nombre de nouvelles fiches ni un débit de production mesuré. Le balayage de disponibilité a un autre plafond ; il ne remplace pas l'enrichissement complet des fiches.

CronExecution expose les curseurs, sourcePaused, sourceFailures, staged, dueBefore, dueRemaining, selected, rejected, hidden, enqueued, inlineAttempted, inlineScanned, deferred et elapsedMs. Pour la disponibilité, surveiller aussi truncated, persisted, persistenceFailed, unknown et l'âge des preuves. Mesurer l'âge du plus ancien candidat dû, les fiches qualifiées réellement nouvelles, le coût par fiche, les doublons canoniques et les retards des enrichissements.

Common Crawl et crt.sh ne constituent pas un inventaire exhaustif ni une garantie de disponibilité. Pour des imports massifs, Common Crawl recommande son index en colonnes plutôt que de saturer CDX ; ses limites d'accès restent applicables. La pagination suit le contrat CDX. Une alimentation à plusieurs millions nécessite des sources autorisées adaptées, une capacité de travailleurs mesurée et un budget d'enrichissement dimensionné. Ces volumes n'ont pas été exécutés ou validés dans cette PR.

Trafic : conservation et unités

Deux feuilles additives traversent adaptateur, émission, template et projection :

• channel_breakdown conserve les canaux, valeurs, unité, période, appareil, pays et total compatible lorsqu’ils existent.
• engagement conserve le rebond en ratio et les pages par visite, avec leur périmètre.

Les réponses partielles restent utilisables sans total de visites. Un vrai zéro reste zéro ; une cellule vide reste inconnue. Les canaux partiels ou susceptibles de se recouper ne sont jamais forcés à former 100 %. Une unité fournisseur ambiguë est conservée comme provider_value, sans conversion en visites ou pourcentage.

Similarweb utilise le chemin documenté overview-share, sur le dernier mois complet, avec périmètre desktop. Le total tous appareils n’est pas utilisé comme dénominateur. Les formes historiques non datées restent explicitement de périmètre inconnu. Les URL authentifiées ne passent plus par un service proxy de secours.

Semrush utilise le summary Trends v3 avec targets et une date YYYY-MM-01. Le précédent endpoint et export_dates ne correspondaient pas au contrat documenté. Une requête demande un mois ; aucune boucle payante de douze appels n’est ajoutée. Les observations mensuelles conservées forment progressivement l’historique. Les colonnes de canaux, dont ai_assistants et ai_search, et les deux mesures d’engagement proviennent de cette même réponse. Leur disponibilité dépend de la couverture et des droits du fournisseur. Ce sont des estimations de trafic, distinctes des mentions dans les réponses d’un modèle IA.

Le parsing public conserve les deux mesures d’engagement déjà présentes dans la fixture existante et ignore les sous-arbres concurrents. Une période ou un appareil non déclaré reste inconnu. La projection écarte les feuilles expirées.

Déploiement et validation

1. Faire passer les gates du dépôt complet ; le checkout de travail est partiel.
2. Appliquer le schéma additif et le schema guard habituel avant d'activer les lecteurs et producteurs de la nouvelle file. Ne pas supprimer les anciennes colonnes.
3. Vérifier la configuration QStash, les routes planifiées et les fournisseurs.
4. Observer plusieurs cycles et vérifier les états privés, actifs, protégés, inconnus, supprimés, les reprises après interruption et les délais d'attente.
5. Ajuster capacité et budgets depuis le débit réel ; comparer un échantillon daté à une référence avant d'affirmer une supériorité de qualité ou de couverture.

Les tests déterministes et SQL hors ligne n'appellent ni fournisseur payant ni base de production. Le code et la PR ne constituent pas un déploiement. Le retour arrière peut conserver la table et les colonnes additives ; les lecteurs de la version 0035 imposaient un plan connecté et réduiraient à nouveau la couverture. Les corrections d'affichage et de trafic de l'extension restent dans le ZIP review12.