dateNotification : dates JJ-MM-AA interprétées comme AAAA-MM-JJ (730 marchés)

[LucetteZANOU]

Bonjour,

Je construis un outil de contrôles d'audit qui consomme le fichier consolidé
decp.parquet. En profilant les données j'ai isolé un défaut de date qui semble venir
d'une conversion, et qui n'est pas couvert par le mécanisme montant_anomalie.

Tous les chiffres ci-dessous portent sur le fichier publié tel quel, soit 3 250 932 lignes.

Constat

730 marchés portent une dateNotification dont l'année est comprise entre 0001 et 0031.

Exemples tels quels dans le fichier :

uid	dateNotification	sourceDataset
200071397000182021000902_38420000	0031-05-22	pes_marche_legacy
213502362000142021210101_09000000	0030-11-22	pes_marche_legacy
21830112500017202121623ST0302_45321000	0030-11-22	decp_colmo

Diagnostic proposé

Le format source semble être JJ-MM-AA, lu comme AAAA-MM-JJ. 0031-05-22
correspondrait donc au 31 mai 2022.

Deux éléments appuient l'hypothèse :

• le composant lu comme année ne prend aucune valeur hors de l'intervalle 1–31,
  soit exactement la plage d'un jour du mois ;
• le composant lu comme jour vaut 22 dans 528 cas sur 730, puis 25, 24 et 20, ce qui
  correspondrait aux années 2022, 2025, 2024 et 2020.

Dix sourceDataset sont concernés, en tête pes_marche_legacy (387), decp_colmo (110),
scrap_marches-securises.fr (98) et pes_marche_2024 (97). Cette répartition fait plutôt
penser à une fonction de conversion partagée qu'à un connecteur particulier.

Effets de bord

• 96 582 marchés ont une datePublicationDonnees antérieure à leur dateNotification,
  avec un écart minimal de −732 656 jours
• 610 dates de publication sont antérieures à 2018

Reproduction

import pandas as pd

df = pd.read_parquet("decp.parquet", columns=["uid", "dateNotification", "sourceDataset"])
annee = pd.to_datetime(df.dateNotification, errors="coerce").dt.year
suspects = df[annee.between(1, 31)]

print(len(suspects))
print(suspects.sourceDataset.value_counts())

Version testée : decp.parquet publié le 2026-08-27, SHA-1
3d1a1ab76a4e2eff7799ff8d4f4fd5637a29bbb8.

Question

Les anomalies de montant sont signalées via montant_anomalie, mais seuls 34 des 730
marchés concernés y apparaissent. Serait-il envisageable d'étendre ce mécanisme aux dates,
avec une colonne date_anomalie ?

Je peux proposer une PR si la piste vous paraît juste — dites-moi simplement où se situe la
conversion des dates dans la chaîne.

Merci pour ce jeu de données, qui est par ailleurs remarquablement propre sur les montants :
1 251 des 1 252 montants supérieurs à 10 Md€ et 623 des 628 montants négatifs sont déjà correctement signalés.

[ColinMaudry]

Merci beaucoup pour cet issue !

Effectivement une PR est bienvenue en insérant une expression Polars à cet endroit (lf = ...), à la suite des autres tentatives de redressement des dates : https://github.com/ColinMaudry/decp-processing/blob/main/src/tasks/clean.py#L125.

Basez-vous sur la branche dev.

[LucetteZANOU]

Merci, je pars sur dev.

Avant d'écrire la PR, je reviens sur mon diagnostic : je n'arrive pas à confirmer l'inversion.

J'ai comparé la reconstruction JJ-MM-AA aux dates de publication, sur les 268 lignes qui en ont une. 9 % seulement donnent un délai plausible, alors que le délai médian du fichier est de 17 jours. J'ai aussi testé l'année contenue dans l'uid après le SIRET : ça ne colle pas non plus, une fois sur deux.

Donc la date d'origine n'est pas récupérable de façon fiable.

En regardant date_replacements, je vois que sur dix entrées, cinq redressent et cinq annulent. Vous annulez déjà quand vous ne pouvez pas trancher.

Je propose de systématiser ça : annuler toute date dont l'année sort d'une plage plausible. date_replacements ne garde alors que les cas que vous avez pu redresser.

annee_max = datetime.date.today().year + 1

lf = lf.with_columns(
pl.when(
pl.col(["datePublicationDonnees", "dateNotification"])
.str.slice(0, 4)
.cast(pl.Int32, strict=False)
.is_between(1990, annee_max)
)
.then(pl.col(["datePublicationDonnees", "dateNotification"]))
.otherwise(None)
.name.keep()
)
Sur le fichier du 27 août, ça annule 974 valeurs : 946 dateNotification et 28 datePublicationDonnees. Soit 0,015 % des dates.

Est-ce que ça vous va?

[LucetteZANOU]

Je reviens sur mon message précédent : ma conclusion était trop rapide, et je la corrige.

Je concluais à l'irrécupérable parce que je n'avais testé qu'une seule reconstruction.
Il y a en réalité deux défauts de conversion distincts, dans des sources
différentes, qui produisent le même symptôme.

Ce que j'avais testé

JJ-MM-AA lu comme AAAA-MM-JJ. Sur les 268 lignes qui ont une date de publication,
cette lecture seule ne donne un délai plausible que dans 6 % des cas à 60 jours. Mon
constat tenait donc.

Ce que je n'avais pas testé

AA-MM-JJ : ordre ISO respecté, mais année sur deux chiffres. 22-05-13 donne l'an 22.
Cette lecture donne un délai plausible dans 40 % des cas à 60 jours. En acceptant
l'une ou l'autre : 44 % à 60 jours, 82 % à cinq ans.

Mon second test tombe pour la même raison. Comparer le millésime de l'identifiant à la
seule reconstruction JJ-MM-AA échoue une fois sur deux, précisément pour les lignes
qui suivent l'autre format.

Le partage se lit source par source. Sur pes_marche_legacy (387 lignes), le composant
lu comme jour vaut 22 dans 359 cas, 25 dans 18, 24 dans 5 : ce composant porte une
année, c'est JJ-MM-AA. Sur scrap_marches-securises.fr (98 lignes), le profil est
inverse, le composant lu comme jour se répartit sur de vrais jours du mois et c'est
celui lu comme année qui se concentre sur 21, 22, 23, 24 : c'est AA-MM-JJ.

Votre table date_replacements contient d'ailleurs déjà une occurrence de ce second
cas : "0022-04-29": "2022-04-29" conserve le mois et le jour et n'ajoute que le
siècle.

Départager ligne à ligne

Deux arbitres, dans cet ordre.

La datePublicationDonnees, que la notification doit précéder.

Le millésime lisible dans l'identifiant du marché, à défaut. La relecture retenue
est celle dont l'année en est la plus proche, à deux ans près. Signal que vous utilisez
déjà à la main : votre "0021-12-05": "2022-12-05" est annotée 20222022/1400.

J'ai validé le second arbitre contre le premier avant de m'en servir. Sur les lignes où
les deux sont disponibles et où la publication tranche, ils donnent le même verdict
150 fois sur 150 avec une tolérance de cinq ans, et 89 fois sur 92 avec une tolérance
de 60 jours. L'accord n'est donc pas parfait à toutes les fenêtres, mais il reste entre
97 et 100 %.

Résultat sur le fichier du 27 août

Sur les 730 lignes de mon signalement initial :

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

S'y ajoutent 224 lignes dont l'année tombe entre 32 et 1999, qui relèvent d'autre chose
que ces deux formats et auxquelles je ne touche pas. Le fichier compte donc encore 347
dateNotification d'année antérieure à 2000 après passage.

pes_marche_legacy passe de 0 à 334 lignes relues, alors qu'elle n'a quasiment aucune
date de publication exploitable (384 nulles sur 387).

Aucune relecture ne produit de date postérieure à aujourd'hui, ni de notification
postérieure à sa propre publication : les 96 582 incohérences du fichier restent à
96 582, la relecture n'en crée aucune.

La PR

Une seule expression Polars, à l'endroit que vous indiquez, juste après la suppression
des suffixes de fuseau horaire. Elle laisse la colonne en chaîne, le typage reste dans
fix_data_types. date_replacements agit avant et reste prioritaire : je n'y touche
pas, elle encode du jugement que la règle ne remplacera pas, votre "0021-12-05" ne
correspondant à aucune des deux relectures.

Reste la question que je posais dans mon message précédent, sur les 347 dates dont
l'année reste antérieure à 2000 après passage. Faut-il les annuler, comme le fait déjà
la moitié des entrées de votre table, ou les laisser visibles ? Je n'ai pas tranché à
votre place, c'est une ligne à ajouter ou non.
Version testée : decp.parquet publié le 2026-08-27, SHA-1
3d1a1ab76a4e2eff7799ff8d4f4fd5637a29bbb8.