PROTOCOL-INFRA: identifiant de dedup et instant de collecte, comptage vs identification, troncature OWA, critere de test discriminant (11/08/2026)

2026-08-11 16:55:14 +00:00
parent 0c109afccd
commit bedae23368
1 changed files with 56 additions and 0 deletions
@@ -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.