📚Wiki Data Studio

Étapes

1. 1

   WDS (Wiki Data Studio) collecte les métadonnées de pages Wikipédia, leurs pageviews, leurs révisions, leur wikitexte et leurs contributeurs, puis calcule un baromètre de sensibilité / risque de manipulation, par page et par jour.

2. 2

   WDS n'est pas une autre plateforme : c'est un second namespace du même API Gateway. `https://api.socialdata.studio/api/v1/wds` face à `/api/v1/sds`, avec la même authentification Firebase. Le token utilisé pour SDS fonctionne tel quel sur WDS.

3. 3

   La hiérarchie WDS est plus courte que celle de SDS : projet → collection → pages Wikipédia → baromètres. Il n'y a pas de niveau client (customer), et l'équivalent d'une importation est la collection.

4. 4

   Conséquence pratique : `collection_id` joue pour WDS le rôle que `importation_id` joue pour SDS. C'est la clé de tous les jobs Wikipedia et de tous les payloads de scheduler. La liste des collections l'affiche en clair pour cette raison.

Schéma

Prérequis

• Être authentifié (le token Firebase de SDS-manager suffit).

Étapes

1. 1

   Dans Wiki Data Studio → Projets & collections, onglet Projets, cliquez sur Nouveau projet et renseignez les champs.

   Champ	Description	Exemple
   name	Nom interne du projet, seul champ obligatoire. Sert d'identifiant lisible.	barometre-sante
   tab_title	Titre affiché dans l'interface publique WDS.	Baromètre Santé
   category	Catégorie de regroupement, libre. Utilisée pour filtrer et trier la liste.	opsci
   description	Périmètre et objectifs du projet.	Suivi des pages santé publique sur fr.wikipedia.org
   is_visible	Visibilité dans les interfaces WDS. Décoché, le projet est archivé : masqué du dashboard public, sans aucune perte de données.	true

2. 2

   ⚠️ La création est un get-or-create. Si un projet avec les mêmes `name` + `tab_title` + `category` existe déjà, le backend renvoie la ligne existante au lieu d'une erreur. L'interface le signale explicitement (« existait déjà (#id) — aucun nouveau projet n'a été créé ») plutôt que d'annoncer une création qui n'a pas eu lieu.

3. 3

   L'édition envoie uniquement les champs modifiés. C'est volontaire : le verbe HTTP est `PUT` mais la sémantique côté backend est celle d'un `PATCH`, et envoyer un `name` vide écraserait une colonne NOT NULL.

Erreurs fréquentes

Prérequis

• Avoir au moins un projet WDS.

Étapes

1. 1

   Dans Wiki Data Studio → Projets & collections, onglet Collections, cliquez sur Nouvelle collection.

   Champ	Description	Exemple
   project_id	Projet parent, obligatoire. Non modifiable après création (voir ci-dessous).	12
   name	Nom de la collection, obligatoire.	Personnalités politiques
   description	Périmètre et critères de sélection des pages.	Députés et sénateurs en exercice
   is_visible	Visibilité. Décochée, la collection est archivée.	true

2. 2

   Le projet parent n'est pas modifiable après création. Reparenter une collection dissocierait ses baromètres déjà calculés du projet qui les a produits. Le champ est donc désactivé en édition, et `project_id` est absent du schéma de mise à jour côté backend.

3. 3

   Le `collection_id` est affiché en clair dans la liste. C'est la valeur à reporter dans les payloads des jobs Wikipedia et des schedulers.

4. 4

   Comme pour les projets, la création est un get-or-create : une collection de même `name` dans le même projet est renvoyée telle quelle.

Étapes

1. 1

   ⚠️ Les suppressions WDS cascadent en base. Les clés étrangères portent `ondelete='CASCADE'` : supprimer un projet détruit ses collections, leurs pages Wikipédia, leurs révisions, leurs pageviews, leurs watchers et tout l'historique de baromètre.

2. 2

   Ces données ne se reconstituent qu'en rejouant les 6 jobs Wikipedia — plusieurs heures de Cloud Tasks — et l'historique de pageviews n'est pas toujours re-récupérable auprès de l'API MediaWiki.

3. 3

   C'est pourquoi l'interface met Archiver en avant. L'archivage bascule `is_visible` à `false` : le projet ou la collection disparaît du dashboard public WDS (qui filtre sur `visible_only`) sans perdre une ligne. L'action est réversible d'un clic (Restaurer).

4. 4

   La suppression définitive existe mais exige de retaper le nom exact de l'objet dans la modale de confirmation. Un `confirm()` natif serait trop léger pour une opération de cette portée.

5. 5

   Pour retrouver un objet archivé, activez Afficher les archivés au-dessus de la liste.

Prérequis

• Avoir une collection non archivée.

Étapes

1. 1

   La rubrique Wiki Data Studio → Infos des pages appelle `POST /api/v1/wds/jobs/wikipedia/pageinfos`. Deux modes, mutuellement exclusifs, parce que le backend applique une priorité stricte entre ses scénarios : dès que `urls` est non vide, tous les autres modes sont silencieusement ignorés.

   Champ	Description	Exemple
   Insérer des pages depuis des URLs	Ajoute de nouvelles pages à la collection. Envoie `urls[]`. C'est le mode d'amorçage d'une collection.	{ collection_id, urls[], props[], inprop[], batch_size }
   Rafraîchir les pages de la collection	N'envoie AUCUNE URL : le backend reprend toutes les pages déjà en base, filtrées par `page_type`. C'est le seul scénario qui lit `page_type`, et le seul qui ait du sens en récurrent.	{ collection_id, page_type, props[], inprop[], batch_size }

2. 2

   Saisie des URLs : une par ligne, ou séparées par des virgules. Attention, une virgule est légale dans un titre Wikipédia — environ une URL sur six du projet en contient une (articles électoraux roumains, convention russe « Nom, Prénom »). Le champ ne traite donc une virgule comme séparateur que si elle est suivie d'un `http`, ce qui préserve `.../wiki/Alegeri_locale_în_România,_2020`.

3. 3

   Les deux formes d'URL reconnues, comme côté backend :

   Champ	Description	Exemple
   Titre	Chemin `/wiki/<titre>`. Les séquences `%XX` sont décodées et les espaces convertis en underscores.	https://fr.wikipedia.org/wiki/Jos%C3%A9_Bov%C3%A9
   curid	Paramètre `?curid=<entier>`. Prioritaire sur le titre si les deux sont présents.	https://fr.wikipedia.org/w/index.php?curid=12345

4. 4

   La langue est déduite du sous-domaine (`fr.`, `en.`, `simple.`, `zh-yue.`, `fr.m.`…) et détermine le Wikipédia interrogé. L'interface refuse les hôtes sans langue explicite (`wikipedia.org`, `www.`, `m.`) : le backend les ferait silencieusement retomber sur `fr`, ce qui collecterait la mauvaise édition. Elle refuse aussi les domaines usurpés du type `fr.wikipedia.org.exemple.com`, que le backend accepterait puisqu'il ne teste qu'une sous-chaîne.

5. 5

   Avant lancement, un encart résume ce que le backend va réellement faire : nombre d'URLs à traiter, rejets avec leur motif, doublons écartés, répartition par langue, partage titres / curids, et nombre de tâches Cloud Tasks (lots de `batch_size`, par couple langue × type). Le lancement est bloqué tant qu'une URL est invalide — le backend, lui, ne signale les rejets que si aucune URL n'est valide ; sinon il les écarte en silence.

6. 6

   Paramètres avancés (repliés, valeurs par défaut du backend). Les valeurs proposées sont celles que le code accepte réellement, qui sont moins nombreuses que celles annoncées par le spec du gateway.

   Champ	Description	Exemple
   props	Propriétés MediaWiki. Deux valeurs seulement, malgré les 12 annoncées par le gateway.	info, pageprops
   inprop	Sous-propriétés de `info`. Six valeurs. `url`, `talkid` et `subjectid` sont de toute façon forcés côté backend dès que `info` est demandé.	subjectid, talkid, watchers, visitingwatchers, protection, url
   page_type	Mode Rafraîchir uniquement. Deux valeurs — le gateway annonce aussi `tous`, que le backend refuse avec un 400.	article, discussion
   batch_size	Taille des lots Cloud Tasks. À réduire en cas de `Rate exceeded` sur l'API MediaWiki.	50

7. 7

   La récurrence planifie toujours un rafraîchissement, jamais la liste d'URLs. C'est le cas d'usage courant : on amorce une collection avec une liste d'URLs, et on veut ensuite que les métadonnées de ces pages soient remises à jour régulièrement. En mode « Insérer », le lancement immédiat porte donc les `urls` (scénario 1) tandis que le scheduler n'en porte aucune (scénario 3), avec `is_reactiometer: true` et `maturity_threshold`. Rejouer la liste chaque nuit n'apporterait rien, l'insertion étant un upsert.

8. 8

   Après lancement, le `job_id` est affiché et un lien renvoie vers le Monitoring : les tâches sont nommées `c{collection_id}-j{job_id}-t{task_id}`, donc une recherche sur le préfixe `c{collection_id}` pour le service `wds-pageinfos` les remonte.

Erreurs fréquentes

Prérequis

• Avoir une collection contenant déjà des pages (voir « Collecter les infos de pages »).

Étapes

1. 1

   La rubrique appelle `POST /api/v1/wds/jobs/wikipedia/pageviews`, qui interroge l'API REST de Wikimedia (`metrics/pageviews/per-article`) et upserte une ligne par page et par jour.

2. 2

   La sélection est multiple. Le job ne prend qu'un `collection_id` à la fois : l'interface émet donc un appel par collection cochée, et affiche un verdict par collection. Une collection en échec n'interrompt pas les suivantes.

   Champ	Description	Exemple
   collection_id	Obligatoire, un par appel. Le sélecteur permet d'en cocher plusieurs, ou d'utiliser « Tout sélectionner ».	36, 37, 38…
   start_date	Début de la fenêtre. **De fait obligatoire** pour une exécution ponctuelle (voir l'avertissement ci-dessous).	2026-01-01T00:00:00
   end_date	Fin de la fenêtre. Laissée vide, le backend prend l'instant courant.	2026-07-16T23:59:59
   batch_size	Paramètre avancé. Le découpage en tâches Cloud Tasks n'a lieu qu'au-delà de ce seuil, ou dès que la collection mêle plusieurs langues.	50

3. 3

   ⚠️ Sans date de début, le job réussit sans rien collecter. `fetch_pageviews` retourne un résultat vide dès que l'une des deux bornes manque, et le job répond malgré tout `200` avec « 0 pages upsertées ». Le schéma la déclare optionnelle, mais elle ne l'est pas en pratique : l'interface la rend obligatoire et l'annonce explicitement.

4. 4

   ⚠️ Techniquement, `start_date` et `end_date` sont annotés `datetime` sans être optionnels, avec un défaut à `None` : transmettre `null` échoue à la validation alors qu'omettre la clé fonctionne. L'interface omet donc les dates vides au lieu de les envoyer nulles.

5. 5

   En récurrent, la fenêtre saisie est ignorée. Avec `is_reactiometer: true`, le backend écrase les deux dates par « maintenant moins l'historique de données » → « maintenant ». C'est ce qui permet à un cron de ne collecter que le delta plutôt que de rejouer la même fenêtre figée. L'historique se règle via le champ « historique de données » du bloc de planification (`maturity_threshold`, 2 jours par défaut).

6. 6

   Quand plusieurs collections sont sélectionnées et qu'une planification récurrente est demandée, un scheduler distinct est créé par collection, suffixé `-c<collection_id>` : un `job_id` Cloud Scheduler doit rester unique. C'est précisément le piège du notebook, dont les 6 schedulers partagent un même payload muté et pointent tous sur la dernière collection de la boucle.

7. 7

   Les tâches sont nommées `c{collection_id}-j{job_id}-t{task_id}` : le Monitoring les retrouve sur le service `wds-pageviews` avec le préfixe `c{collection_id}`.

Erreurs fréquentes

Prérequis

• Avoir une collection contenant déjà des pages.

Étapes

1. 1

   La rubrique appelle `POST /api/v1/wds/jobs/wikipedia/revisions`, qui interroge MediaWiki et peuple les tables `revisions` et `users`. Comme pour les pages vues, la sélection est multiple : un appel par collection, avec un verdict par collection.

2. 2

   Trois actions, exclusives. Les deux dernières travaillent sur les révisions déjà en base et n'appellent pas MediaWiki pour en chercher de nouvelles.

   Champ	Description	Exemple
   Collecter les révisions	Mode par défaut (aucun champ `action` envoyé). Lit la fenêtre de dates et les options ci-dessous.	{ collection_id, start_date, end_date, rvprop, … }
   Recalculer le sizediff	Recalcule la variation de taille des révisions existantes. Synchrone, sans fan-out.	{ collection_id, action: 'compute_sizediff', force }
   Recalculer le revert risk	Recalcule le score de risque de revert via l'API Wikimedia, sur l'existant.	{ collection_id, action: 'compute_revert_risk', force }

3. 3

   Options de collecte.

   Champ	Description	Exemple
   enrich_revert_risk	Ajoute le score de risque de revert pendant la collecte. Un appel Wikimedia supplémentaire par révision : nettement plus lent.	true
   enqueue_wikitext	Empile dans la foulée des tâches sur la file `wds-wikitext` pour récupérer le texte des révisions.	false
   force_new_tasks	Contourne la déduplication Cloud Tasks en suffixant les noms de tâches. Sans cette option, relancer la même collecte peu après reste sans effet.	true
   rvprop	Paramètre avancé. Propriétés MediaWiki demandées.	ids|timestamp|size|comment|user|flags
   freshness_threshold	Paramètre avancé, en secondes. Une page collectée depuis moins longtemps est sautée. 6 h par défaut.	21600

4. 4

   ⚠️ Le fan-out crée une tâche Cloud Tasks par page (`batch_size = 1`). Une collection de 500 pages génère 500 tâches. C'est aussi pourquoi l'interface intercale 2 secondes entre deux collections lors d'un lancement immédiat, comme le fait le notebook.

5. 5

   ⚠️ Une date de début dans le futur ne collecte rien. Le job répond `200` avec `status: "scheduled"` et s'arrête — c'est prévu pour préparer une collecte à l'avance. L'interface bloque le cas pour éviter le faux positif.

6. 6

   En récurrent, `is_reactiometer` fait calculer la date de début par le backend (« maintenant moins l'historique de données »). Nuance par rapport aux pages vues : ici une `start_date` explicite plus récente que ce calcul serait conservée. L'interface n'en envoie donc aucune en mode récurrent.

7. 7

   La planification récurrente n'est proposée que sur « Collecter les révisions » : un recalcul est ponctuel par nature.

Erreurs fréquentes

Prérequis

• Avoir collecté les révisions de la collection — sans elles, il n'y a rien à texturer.

Étapes

1. 1

   La rubrique appelle `POST /api/v1/wds/jobs/wikipedia/wikitext`. Le job récupère le wikitexte de chaque révision via MediaWiki, puis alimente la table `references` par extraction des citations. Sélection multiple, un appel par collection.

2. 2

   Le job est naturellement incrémental. Sa requête de sélection filtre sur `Revision.wikitext IS NULL` : seules les révisions dont le texte manque encore sont reprises. Le relancer ne refait aucun travail déjà accompli, et laisser les deux dates vides rattrape simplement tout le retard de la collection.

3. 3

   Paramètres.

   Champ	Description	Exemple
   collection_id	Techniquement optionnel côté schéma, mais exigé par l'interface : sans lui la sélection porterait sur toute la base, et le nom des tâches retomberait sur le préfixe littéral `wikitext` au lieu de `c{collection_id}` — le suivi par collection dans le Monitoring serait perdu.	36
   start_date / end_date	Bornes facultatives sur l'horodatage des révisions. Sans date de fin, le backend prend l'instant courant.	2026-01-01T00:00:00
   batch_size	Paramètre avancé. Nombre de révisions par tâche Cloud Tasks. 250 par défaut côté interface — le backend retiendrait 500 si la clé était absente, mais elle est toujours transmise.	100

4. 4

   ⚠️ `batch_size` ne règle pas la cadence des appels MediaWiki. Il ne fait que découper le travail en tâches ; à l'intérieur d'une tâche, le worker interroge MediaWiki par sous-lots de 50 avec une pause fixe. En cas de « Rate exceeded », réduire `batch_size` étale la charge sur davantage de tâches — c'est le seul levier disponible depuis l'interface.

5. 5

   Deux champs du schéma ne sont pas exposés, parce qu'ils sont déclarés mais jamais lus par la fonction : `limit` et `sleep_time`. Les proposer donnerait des réglages sans effet.

6. 6

   Comme pour les pages vues, `is_reactiometer` écrase les deux bornes en mode récurrent (« maintenant moins l'historique de données » → « maintenant »). L'interface n'envoie donc aucune date dans ce cas.

7. 7

   Les collections sont traitées l'une après l'autre avec 2 secondes d'écart en lancement immédiat, comme dans le notebook : c'est précisément le scénario qui a produit des « Rate exceeded ».

Erreurs fréquentes

Prérequis

• Avoir collecté les révisions : ce sont elles qui révèlent les contributeurs.

Étapes

1. 1

   La rubrique appelle `POST /api/v1/wds/jobs/wikipedia/users`. Le job sélectionne les contributeurs enregistrés ayant au moins une révision sur une page de la collection, puis complète leur fiche via MediaWiki (date d'inscription, groupes).

2. 2

   ⚠️ Ce job n'a pas de fenêtre de dates. `start_date` et `end_date` n'existent pas dans son schéma : le notebook les envoie, Pydantic les jette silencieusement. Le périmètre se règle autrement.

   Champ	Description	Exemple
   only_incomplete	Ne traite que les fiches sans date d'inscription. Activé par défaut. Ignoré en mode récurrent, où le backend le force à false.	true
   freshness_threshold	Ne retraite pas une fiche mise à jour depuis moins de 6 h. La case « Ignorer la fraîcheur » envoie `null`, ce qui retire le filtre — c'est ce que fait le notebook.	null
   limit	Plafond appliqué **en SQL**, avant tout découpage. 500 par défaut : sur une grosse collection, le laisser tel quel ne traite que les 500 premiers contributeurs. Le notebook met 9999999 pour tout couvrir.	9999999
   force	Traite tous les contributeurs sélectionnés sans considération de fraîcheur.	false

3. 3

   En récurrent, `is_reactiometer` change la logique de sélection : `only_incomplete` est forcé à false et le job reprend les fiches dont la dernière mise à jour dépasse l'historique de données. Celui-ci vaut 7 jours par défaut pour ce job, contre 2 pour les autres.

Erreurs fréquentes

Prérequis

• Avoir collecté révisions et contributeurs : ce sont eux qui déterminent le périmètre.

Étapes

1. 1

   Pourquoi cette étape existe. La métrique `expertise_deficit` joint chaque révision au groupe valide à sa date : `uwg.since <= r.timestamp AND (uwg.until IS NULL OR uwg.until > r.timestamp)`. Or le job `users` enregistre `since` = date d'observation, et non la date réelle d'attribution du droit. Les révisions antérieures au passage du job tombent donc hors fenêtre et la métrique reste vide. Même logique pour `join_page_protection.timestamp`, lu par la métrique `protection`.

2. 2

   La rubrique appelle `POST /api/v1/wds/data/admin/observation-windows`. Contrairement aux six pages de collecte, ce n'est pas un job Wikipedia : c'est une opération de maintenance qui écrit directement en base, servie par `wds-backend`.

   Champ	Description	Exemple
   collection_ids	Collections concernées, au moins une. Dédupliquées côté backend.	[36, 37, 38]
   start_date	Écrite dans `user_wiki_groups.since` et `join_page_protection.timestamp`.	2026-01-01
   end_date	Écrite dans `user_wiki_groups.until`. Requise si `close_until` est vrai.	2026-07-16
   close_until	Pose `until`. Décoché, `until` reste inchangé — plus permissif, puisqu'un `until` à NULL signifie « toujours actif ».	true
   dry_run	Ne compte que les lignes concernées, sans rien écrire. Vrai par défaut, côté API comme dans l'interface.	true

3. 3

   ⚠️ Écriture destructive et irréversible. Les valeurs précédentes de `since`, `until` et `timestamp` ne sont pas conservées. L'interface impose donc un aperçu avant d'autoriser l'écriture, et invalide cet aperçu dès que le périmètre ou la période change.

4. 4

   ⚠️ Fermer la fenêtre a un coût. Poser `until = end_date` fait passer un groupe encore détenu de « toujours actif » à « révoqué à cette date » : les révisions postérieures cesseront de compter dans `expertise_deficit`. C'est un choix explicite, pas un défaut anodin.

5. 5

   Deux garde-fous côté serveur. L'aperçu rapporte le total de la table `join_page_protection` à côté du nombre de lignes visées : un écart massif entre les deux signale une requête mal cadrée. Et si un UPDATE touche plus de lignes que le décompte préalable, la transaction est annulée et l'API répond 409 sans rien conserver.

6. 6

   Ces garde-fous ne sont pas théoriques : une version antérieure de ce traitement, dans le notebook, écrasait toutes les lignes de `join_page_protection` (58) au lieu des seules lignes visées (1), faute de corrélation dans l'`UPDATE ... FROM`. Le décompte affiché paraissait plausible, et rien ne le signalait.

Erreurs fréquentes

Prérequis

• Avoir collecté pages, pageviews, révisions, wikitextes et contributeurs : le baromètre est le dernier maillon de la chaîne.

Étapes

1. 1

   La rubrique appelle `POST /api/v1/wds/jobs/wikipedia/barometer_compute`. Le job agrège une vingtaine de métriques (pics de vues et d'éditions, guerre d'édition, intensité des discussions, densité de citations, sockpuppets, anonymat, concentration des contributeurs…) en scores de chaleur, qualité et comportement.

2. 2

   ⚠️ Les deux dates sont obligatoires hors mode récurrent. Le backend renvoie un `400 "start_date and end_date are required when is_reactiometer is false"`. C'est la seule validation explicite des six jobs — ailleurs une date manquante donne un no-op silencieux.

3. 3

   ⚠️ Le calcul est synchrone, sans découpage en tâches Cloud Tasks — il n'existe d'ailleurs aucune file `wds-barometer`. Sur une période large, la requête dépasse le délai du proxy et remonte une erreur alors que le calcul se poursuit côté serveur. C'est ce qu'a rencontré le notebook (504/524). Découper en périodes plus courtes est le remède, et il n'y a rien à suivre dans le Monitoring pour ce job.

4. 4

   Paramètres.

   Champ	Description	Exemple
   start_date / end_date	Bornes de la période à calculer. Obligatoires.	2026-01-01T00:00:00 → 2026-07-16T23:59:59
   watchers_magic_number	Paramètre avancé. Constante de normalisation du score de watchers, qui ramène le nombre de suiveurs sur une échelle comparable entre pages. La modifier change le score de watchers, donc le baromètre global.	100

5. 5

   ⚠️ La cible du scheduler s'appelle `wds-barometer`, alors que l'endpoint est `barometer_compute`. C'est le seul job où les deux noms diffèrent — utile à savoir en cherchant les schedulers.

Erreurs fréquentes

Prérequis

• Avoir une collection avec son `collection_id`.

Étapes

1. 1

   WDS expose 6 jobs de collecte, tous en `POST` sur `/api/v1/wds/jobs/wikipedia/…` et tous pilotés par un `collection_id`.

   Champ	Description	Exemple
   pageinfos	Métadonnées des pages via l'API MediaWiki (watchers, protections), et insertion des pages dans une collection. Dispose de son propre formulaire — voir « Collecter les infos de pages » ci-dessus.	{ collection_id, urls[], props[], inprop[], batch_size }
   pageviews	Vues par page et par jour. Dispose de son propre formulaire — voir « Collecter les pages vues » ci-dessus.	{ collection_id, start_date, end_date }
   revisions	Historique des révisions, avec estimation du risque de revert. Dispose de son propre formulaire — voir « Collecter les révisions » ci-dessus.	{ collection_id, start_date, end_date, enrich_revert_risk }
   wikitext	Wikitexte des révisions, dont l'extraction des références. Dispose de son propre formulaire — voir « Collecter les wikitextes » ci-dessus.	{ collection_id, batch_size, start_date, end_date }
   users	Contributeurs et leurs groupes. Dispose de son propre formulaire — voir « Enrichir les contributeurs » ci-dessus.	{ collection_id, only_incomplete, limit }
   barometer_compute	Calcul du baromètre. Synchrone (pas de Cloud Tasks), donc sensible au timeout. Dispose de son propre formulaire — voir « Calculer le baromètre » ci-dessus.	{ collection_id, start_date, end_date, watchers_magic_number }

2. 2

   Les schedulers WDS passent par l'endpoint SDS. Il n'existe aucun `/wds/jobs/admin/*` : la planification se fait via `POST /api/v1/sds/jobs/admin/scheduler` avec un `target` de la forme `wds-*`. C'est pourquoi les targets WDS apparaissent dans Tâches planifiées aux côtés des targets SDS.

   Champ	Description	Exemple
   target	Cible du scheduler. Six valeurs WDS autorisées. Noter que le baromètre s'appelle `wds-barometer` en target, alors que son endpoint est `barometer_compute`.	wds-pageinfos, wds-pageviews, wds-revisions, wds-wikitext, wds-users, wds-barometer
   payload	Corps transmis au job. Pour un scheduler récurrent, on retire `start_date` / `end_date` et on active le mode incrémental.	{ collection_id, is_reactiometer: true, maturity_threshold: 172800 }

3. 3

   Le mode `is_reactiometer` est propre à WDS : il remplace la fenêtre `start_date` / `end_date` par une collecte incrémentale, bornée par `maturity_threshold` (en secondes). C'est le couple à utiliser sur tout scheduler récurrent, faute de quoi la tâche rejouerait indéfiniment la même fenêtre figée.

4. 4

   Côté Monitoring, la section « État global des files » couvre 5 files WDS : `wds-pageinfos`, `wds-pageviews`, `wds-revisions`, `wds-wikitext`, `wds-users`. La recherche par entité (`i{importation_id}` / `a{analyse_id}`) ne s'applique pas à WDS : les fonctions WDS n'apposent pas de préfixe métier sur leurs task IDs.

Erreurs fréquentes