Qlik : données contrôlées avant écriture et récupération plus fiable

Fiabilité des données
- Contrôle de plausibilité avant d'écrire le cache (lib/qlik-validation.ts) :
  extraction refusée, cache inchangé, si le dernier mois pèse moins de 40 %
  des 3 précédents dans les 10 premiers jours du mois (mois pas encore
  chargé dans Qlik), ou si plus de la moitié des séries vendues ont la même
  valeur 12 mois (mesure insensible au mois).
- Valeurs impossibles corrigées (NaN, infini, nombre de magasins négatif).

Récupération
- Chromium relancé s'il est tombé : un navigateur déconnecté faisait échouer
  toutes les extractions jusqu'au redémarrage du serveur.
- Une seule session Qlik à la fois (extraction de nuit, synchro manuelle,
  recherche produit) : en parallèle, le serveur Qlik abandonnait les deux.
- Planificateur : un échec est retenté la nuit suivante (au lieu de 7 jours)
  et les données d'avant le mois en cours sont rafraîchies sans attendre le
  délai de fraîcheur. Page Synchronisation mise à jour.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015MouZgPPAuEZjHXXifW7bm

src/features/admin/api/sync-scheduler.ts

@@ -140,19 +140,36 @@ async function prochainSql(depuis: Date) {
     return row ?? null;
 }
 
+/** Délai avant de retenter un fournisseur Qlik en échec : la nuit suivante. */
+const QLIK_REPRISE_ECHEC_MS = 18 * 3600 * 1000;
+
 /**
- * Le plus ancien fournisseur Qlik dont les données dépassent `qlikMinJours`.
- * Le seuil en jours, plutôt que la fenêtre courante, évite de relancer chaque
- * nuit une extraction de plusieurs minutes pour des agrégats mensuels.
+ * Le plus ancien fournisseur Qlik à rafraîchir. Il l'est si :
+ *  - ses données dépassent `qlikMinJours` (agrégats mensuels : inutile de
+ *    relancer chaque nuit une extraction de plusieurs minutes) ;
+ *  - ou elles datent d'avant le mois en cours : la fenêtre de 12 mois a glissé,
+ *    son dernier mois manque, sa tendance n'est plus à jour ;
+ *  - ou sa dernière extraction a échoué il y a plus de 18 h. Un échec attendait
+ *    jusqu'ici `qlikMinJours` (7 jours) avant un nouvel essai, alors que la
+ *    plupart sont passagers (serveur Qlik chargé, dernier mois pas encore
+ *    chargé). Le plus ancien passant en premier, un fournisseur qui échoue à
+ *    chaque fois repart en fin de file et ne bloque personne.
  */
 async function prochainQlik(qlikMinJours: number, maintenant: Date) {
-    const seuil = new Date(maintenant.getTime() - qlikMinJours * 24 * 3600 * 1000);
+    const seuilAge = new Date(maintenant.getTime() - qlikMinJours * 24 * 3600 * 1000);
+    const debutMois = new Date(maintenant.getFullYear(), maintenant.getMonth(), 1);
+    const seuil = seuilAge > debutMois ? seuilAge : debutMois;
+    const seuilEchec = new Date(maintenant.getTime() - QLIK_REPRISE_ECHEC_MS);
     const [row] = await db
         .select()
         .from(syncFournisseurs)
         .where(and(
             eq(syncFournisseurs.actifQlik, true),
-            or(isNull(syncFournisseurs.dernierQlikAt), lt(syncFournisseurs.dernierQlikAt, seuil)) as SQL,
+            or(
+                isNull(syncFournisseurs.dernierQlikAt),
+                lt(syncFournisseurs.dernierQlikAt, seuil),
+                and(eq(syncFournisseurs.dernierQlikStatut, "echec"), lt(syncFournisseurs.dernierQlikAt, seuilEchec)),
+            ) as SQL,
         ))
         .orderBy(asc(sql`${syncFournisseurs.dernierQlikAt} nulls first`))
         .limit(1);