fix: relecture des dates de notification mal converties #191

[LucetteZANOU]

Corrige les dateNotification issues d'une conversion source ratée, à l'endroit
indiqué dans l'issue #191, juste après la suppression des suffixes de fuseau horaire.

Deux formats source distincts produisent une année antérieure à 2000, et le détail de
l'analyse est dans l'issue :

• JJ-MM-AA lu comme AAAA-MM-JJ : 31-05-22 donne l'an 31. Dominant dans
  pes_marche_legacy, où le composant lu comme jour vaut 22 dans 359 cas sur 387.
• ordre ISO avec une année sur deux chiffres : 22-05-13 donne l'an 22. Dominant dans
  scrap_marches-securises.fr, decp_colmo et e-marchespublics.com_dematis.

Les deux relectures sont mises en concurrence et départagées par la
datePublicationDonnees, que la notification doit précéder, puis à défaut par le
millésime lisible dans l'identifiant du marché. Sans départage net, la date est laissée
telle quelle.

Effet sur le fichier du 27 août

Sur les 730 lignes signalées dans l'issue :

	lignes
relues	607
non tranchées, laissées telles quelles	123

S'y ajoutent 224 lignes d'année comprise entre 32 et 1999, qui relèvent d'autre chose et
auxquelles je ne touche pas : le fichier compte donc encore 347 dateNotification
antérieures à 2000 après passage.

Aucune relecture ne produit de date postérieure à aujourd'hui, ni de notification
postérieure à sa propre publication : le nombre d'incohérences entre les deux dates
reste identique, à 96 582.

Choix d'implémentation

L'expression est placée après date_replacements, qui reste prioritaire et intacte :
elle agit sur la chaîne brute et encode des cas que la règle ne couvre pas, comme
"0021-12-05": "2022-12-05" qui ne correspond à aucune des deux relectures.

La colonne reste une chaîne, le typage est inchangé dans fix_data_types.

Les seuils sont dans src/config.py et surchargeables par variable d'environnement :
DATE_ANNEE_MIN, DATE_ECART_PUBLICATION_MAX_JOURS, DATE_ECART_MILLESIME_MAX_ANNEES.

Tests

Neuf cas dans tests/test_clean.py : départage par la publication pour chacun des deux
formats, départage par le millésime, et les cinq refus (deux lectures plausibles,
millésime trop éloigné, millésime équidistant, relecture démentie par la publication,
relecture dans le futur).

Reste ouverte la question posée dans l'issue : faut-il annuler les 347 dates qu'aucun
arbitre ne tranche, comme le fait déjà la moitié des entrées de date_replacements ?

[ColinMaudry]

Merci pour votre PR, mais compte tenu du faible nombre de marchés impacté vous proposez une solution beaucoup trop complexe que je devrai ensuite maintenir.

Une simple détection du format de la date (commence par 00) avec vérification de la validité de chaque partie (jour compris entre 01 et 31, mois compris entre 01 et 12, année comprise entre 2018 et l'année courante) suffit.

[ColinMaudry]

Et s'il vous plaît tapez vous-même vos commentaires, votre IA en génère des trop longs qui ne vont pas à l'essentiel, ils sont trop verbeux.

[ColinMaudry]

Et dernière requête : s'il vous plaît attendez d'avoir cadré le besoin avec moi avant de coder et soumettre une PR, au risque de brûler des tokens pour rien.

[LucetteZANOU]

Compris pour les trois points.
Je passe la PR en brouillon en attendant.
Je reviens vers vous pour cadrer le périmètre.