From bedae23368498af8b377edcfe670a64e6a4d14c0 Mon Sep 17 00:00:00 2001 From: bolbol Date: Tue, 11 Aug 2026 16:55:14 +0000 Subject: [PATCH] PROTOCOL-INFRA: identifiant de dedup et instant de collecte, comptage vs identification, troncature OWA, critere de test discriminant (11/08/2026) --- common/PROTOCOL-INFRA.md | 56 ++++++++++++++++++++++++++++++++++++++++ 1 file changed, 56 insertions(+) diff --git a/common/PROTOCOL-INFRA.md b/common/PROTOCOL-INFRA.md index 25a1336..9e2fa5a 100644 --- a/common/PROTOCOL-INFRA.md +++ b/common/PROTOCOL-INFRA.md @@ -358,3 +358,59 @@ precedent, ce qui imitait parfaitement un echec du correctif en cours de validat REFLEXE : lancer ces batteries sous `flock -n`, verifier `ps aux` avant de conclure, et se mefier d'un resultat qui "pointe vers le dossier d'a cote" plutot que vers un dossier arbitraire. + +## REGLE -- un identifiant de deduplication ne doit jamais dependre d'un champ derive de l'instant de collecte (2026-08-11) + +`nyora-notes-tt` deduplique sur un hash incluant `received_date`. Or `normaliser_date_owa` renvoie +`date.today()` pour un message affiche en heure seule ("09:01") : pour tout message recent, la date +stockee est une fonction du JOUR DE SCRAPE, pas du message. Le meme mail re-scrape deux jours de +suite produisait donc deux identifiants -- 4 notes creees la ou il en fallait 0 lors du re-scan du +lot pilote. Deux tentatives successives de fiabiliser le PARSING de la date avaient echoue : le +defaut n'etait pas dans le parsing, il etait dans le choix du champ. + +REFLEXE : avant d'inclure un champ dans une cle d'identite, se demander non pas "est-il correct ?" +mais "vaudra-t-il la meme chose si je recollecte la meme donnee dans six mois ?". Tout champ dont +la valeur depend de l'instant, du rendu ou du contexte de lecture est disqualifie, meme si son +extraction est parfaite. Corollaire : une extraction par POSITION contamine les champs voisins -- +ici l'objet etait derive de l'indice de la date, donc indirectement instable lui aussi. Extraire +par MOTIF, jamais par indice, quand la structure n'est pas garantie. + +## REGLE -- quand aucune cle ne peut separer deux elements, compter plutot qu'identifier (2026-08-11) + +Corollaire du precedent. Certains mails "gabarit" (accuses de reception, newsletters, relances d'un +meme fil) sont STRICTEMENT indiscernables au niveau de la ligne de liste OWA : meme expediteur, +meme objet, meme debut de corps -- seule la date les separe, et elle est inutilisable. Toute cle +calculee sur ces champs fusionne donc des messages reels, ce qui est une PERTE SILENCIEUSE, bien +pire qu'un doublon visible sur une archive. La solution n'a pas ete une meilleure cle, mais un +changement de question : comparer le NOMBRE d'elements portant la cle dans la source (N) au nombre +deja en base (M), et ingerer la difference. + +REFLEXE : quand une identification exacte exige d'ouvrir la ressource complete (ici : ouvrir chaque +mail), verifier d'abord si un comptage sur une cle approximative ne suffit pas. Ici cela a +transforme un re-scan de 83 messages de ~50 min (une ouverture par message) en ~110 s, tout en +supprimant le risque de perte. Une cle qui admet des collisions est acceptable DES LORS que la +decision ne repose pas sur son unicite. + +## PIEGE -- la troncature de previsualisation d'OWA n'est pas stable, et un test sur donnees anciennes ne le voit pas (2026-08-11) + +Mesure initiale sur un dossier de 35 messages, deux passes entrecoupees d'une navigation : texte +identique a 100 %, conclusion "troncature stable par message". Faux. Le test ne portait que sur des +messages ANCIENS. Sur un message du jour, les deux rendus du meme mail differaient par le seul +marqueur de troncature : + '... Extrait de commentaires Web :…' puis '... Extrait de commentaires Web :' +Un caractere suffit a changer un hash, donc a creer un doublon. + +REFLEXE : un test de stabilite temporelle doit inclure des donnees FRAICHES -- c'est sur elles que +le rendu bouge, precisement parce que l'interface les affiche differemment selon leur age. Et se +premunir en normalisant les marqueurs de troncature ET en bornant le texte hache en deca de la zone +qui varie. + +## PIEGE -- un test dont l'echec produit le meme chiffre que le succes ne valide rien (2026-08-11) + +Le script de validation du correctif de dedup verifiait `processed_new == 0` apres re-scan. Un +dossier tombe en erreur (navigateur sature, HTTP 500) renvoie lui aussi `processed_new == 0`, faute +d'avoir rien lu : le premier rapport a donc affiche "[OK]" sur une panne complete du navigateur. + +REFLEXE : verifier que le critere de succes est DISCRIMINANT vis-a-vis des modes d'echec connus. +Ici il a fallu exiger `status == 'done'` en plus du compteur, et prevoir un verdict distinct +"NON CONCLUANT" -- ni succes, ni anomalie -- pour ce qui n'a pas ete mesure.