Collisions de `uid` : marchés distincts partageant le même acheteur_id + id

[ColinMaudry]

Problème

Le uid d'un marché est construit ainsi (src/tasks/clean.py:48) :

lf = lf.with_columns((pl.col("acheteur_id") + pl.col("id")).alias("uid"))

uid = acheteur_id + id. Or le champ id publié par les acheteurs n'est pas garanti unique : un même acheteur peut réutiliser le même id pour deux marchés différents. Le uid n'est donc pas un identifiant fiable d'un marché.

Exemple concret

Acheteur 21310555400017 (Ville de Toulouse), deux contrats distincts publiés avec id = "2023V" → même uid = 213105554000172023V :

	marché A	marché B
objet	22V0320AO — extension groupe scolaire Jolimont	23V0141MN — LOT 9 électricité CFO-CFA
codeCPV	45210000 (bâtiment)	45311200 (électricité)
procédure	Appel d'offres ouvert	Sans publicité ni mise en concurrence
dureeMois	31	52
lieuExecution	31500	31000

Mêmes acheteur_id, id, uid et dateNotification — mais deux contrats réellement différents.

Conséquences

Comme modification_id est un rang dense de dateNotification sur uid (sort_modifications, src/tasks/transform.py:97), les deux contrats se retrouvent avec le même (uid, modification_id), avec plusieurs impacts :

1. modification_id corrompu : deux contrats indépendants sont fusionnés dans l'historique de modifications d'un seul marché.
2. Perte de données silencieuse dans la table marches publiée : src/tasks/output.py:216 fait unique(subset=["uid", "modification_id"]) → pour chaque paire en collision, un des deux marchés réels est supprimé de la sortie finale.
3. Démultiplication (fan-out) dans detect_montant_anomalies : la fonction regroupe par toutes les colonnes non-titulaire (donc les 2 contrats restent séparés) puis rejoint les titulaires sur (uid, modification_id) seul → produit cartésien des titulaires entre les deux contrats. Symptôme visible : les deux logs height df diffèrent (~3,12 M en entrée vs ~3,18 M en sortie).

Ampleur

Sur un run complet (~2,52 M de couples (uid, modification_id)) :

• 5 806 couples (uid, modification_id) couvrent plus d'un objet distinct
• 3 374 couples couvrent plus d'un codeCPV distinct

Soit ~0,2 % des marché-versions, mais avec perte de données réelle à la publication.

Pistes de correction

• Rendre le uid réellement unique (intégrer p. ex. un hash de objet/codeCPV/dateNotification, ou un suffixe de désambiguïsation). ⚠️ modifie les valeurs de uid publiées → changement cassant pour les consommateurs.
• Vérifier au préalable si le id non-unique est un problème de donnée source ou de parsing (le vrai id du marché semble être 22V0320AO / 23V0141MN, présent dans objet, alors que le id extrait vaut 2023V — possible troncature/mauvais champ).

Note

Bug préexistant, indépendant des optimisations de performance récentes. Mis en évidence par les logs de height restaurés dans detect_montant_anomalies.

[ColinMaudry]

Exemples de collisions résiduelles avec uid + "_" + codeCPV

Piste envisagée : rendre le uid unique via uid = acheteur_id + id + "_" + codeCPV. Sur un run complet, cette clé sépare ~65 % des uid ayant plus d'un objet distinct, mais un résidu subsiste (même uid et même codeCPV, objets différents). Deux exemples :

Exemple 1 — uid=229102280000182023270210000, cpv=38652120

• Fourniture de matériels de vidéoprojection, de sonorisation et prestations associées
• 23_2702_1_00 Fourniture de matériels de vidéo projection, de sonorisation et prestations associées

⚠️ Ce n'est pas une vraie collision : il s'agit du même marché, avec seulement du bruit de texte sur objet (« vidéoprojection » vs « vidéo projection », plus un préfixe de référence 23_2702_1_00). Ces cas gonflent artificiellement le décompte de « collisions » basé sur objet distinct — ils ne doivent surtout pas être séparés.

Exemple 2 — uid=778770198000272024TX00, cpv=45210000

• ... construction neuve de 5 logements ... GEISPOLSHEIM ... lot 7 Plâtrerie
• Reconsultation des lots n°3 et 18 ... Lotissement Chopin 2 à LIPSHEIM
• ... lot n°8 Plâtrerie ... ESCHAU
• Consultation des lots n°9, 12, 16 et 21 ... LIPSHEIM
• Relance Lot 11 Carrelage Faïence ... GEISPOLSHEIM

✅ Vraie collision : 5 lots/opérations réellement distincts partageant id = "2024TX00" et le même CPV 45210000. Le CPV ne peut pas les séparer.

Conséquences pour le choix de clé

• Le décompte de collisions basé sur objet distinct surestime le problème (faux positifs comme l'exemple 1 = même marché, texte bruité).
• uid_cpv corrige donc probablement une part plus grande des vraies collisions que les 65 % bruts.
• Mais un résidu comme l'exemple 2 restera fusionné quel que soit le CPV → aucune clé structurée simple ne le résout ; il faudrait descendre au niveau d'une référence de marché fiable (souvent absente ou non normalisée dans la source).

[ColinMaudry]

Quantification & cadrage « marché vs version »

Ce qu'on apprend de l'exemple 1

Les deux lignes ne diffèrent pas que par l'objet : elles diffèrent par leur complétude selon le dataset.

dataset	objet	titulaire
pes_marche_legacy	23_2702_1_00 Fourniture…	null
scrap_marches-publics.info	Fourniture…	34926480400049 (SIRET)

Reste identique : dateNotification (2023-08-03), montant (4,8 M), dureeMois (48), modification_id (0). C'est pourquoi le dédoublonnage existant transform.py:164 (subset incluant titulaire_id) ne les fusionne pas : null ≠ SIRET.

Quantification (grain version de marché = (uid, modification_id))

Collisions = versions avec plus d'un objet distinct : 5 782

• ✅ 2 974 (51 %) résolues par une consolidation inter-dataset — toute la multiplicité vient du croisement de datasets (aucun dataset seul n'a >1 objet pour la version). Cas exemple 1.
• ❌ 2 808 (49 %) restantes — un même dataset contient déjà >1 objet pour la version = vraie collision intra-dataset (type ci-dessous).
  • dont 2 088 séparables par codeCPV → adressables via uid + "_" + codeCPV.
  • dont 720 irréductibles (même acheteur + id + codeCPV + dataset, contrats réellement distincts) → nécessiteraient une vraie référence de marché, absente/non normalisée dans la source.

Couverture combinée consolidation inter-dataset + uid_cpv ≈ 5 062 / 5 782 ≈ 88 %. Noyau dur résiduel : 720.

Exemple de noyau dur — uid=778770198000272024TX00, cpv=45210000, id="2024TX00" réutilisé pour 5 lots/opérations distincts (Geispolsheim, Lipsheim, Eschau…).

Note : le uid 213105554000172023V agrège à lui seul 89 modification_id (un id="2023V" réutilisé massivement), ce qui illustre l'ampleur des collisions d'id côté source.

Cadrage : la clé identifie une version de marché, pas un marché

La consolidation inter-dataset supprime la même version (même modification_id/dateNotification) rapportée par plusieurs datasets. On garde toutes les versions distinctes (les modifications sont de la vraie donnée), on ne fait que dé-dupliquer une version entre datasets.

rôle	champs	justification
identité (clé)	uid, dateNotification, codeCPV	dateNotification = discriminant de version (= modification_id) ; codeCPV = discriminant de contrat stable pour survivre aux collisions d'uid
payload (à coalescer)	montant, dureeMois, titulaires, objet, …	changent entre versions et varient par bruit/complétude entre datasets ; le titulaire null vs SIRET est précisément à coalescer, pas à mettre en clé

Réserve : si la dateNotification d'une même version est bruitée d'un dataset à l'autre, la clé ne fusionnera pas — à surveiller.

Source des marchés consolidés

Un marché consolidé par coalesce est un mélange de plusieurs datasets ; on ne peut pas honnêtement conserver un sourceDataset initial. Ces lignes reçoivent une nouvelle source :

• sourceDataset = decp_colmo
• ressource : https://www.data.gouv.fr/api/1/datasets/r/11cea8e8-df3e-4ed1-932b-781e2635e432

[ColinMaudry]

État après implémentation — résidu irréductible (~720), non traité

Deux mitigations sont désormais en place :

1. Consolidation inter-dataset (consolidate_across_datasets) — fusionne une même version de marché rapportée par plusieurs datasets (coalesce complétude→récence, union des titulaires, source decp_colmo), avec un garde-fou anti perte de données.
2. Code CPV dans l'uid — uid = acheteur_id + id + "_" + codeCPV, ce qui sépare les contrats distincts partageant le même id acheteur mais de CPV différents.

Ce qui reste : les collisions « irréductibles » (~720)

Il subsiste des contrats réellement distincts partageant toutes les clés disponibles : même acheteur_id, même id, même codeCPV, même dateNotification, et présents dans un même dataset. Ni le CPV dans l'uid ni la consolidation ne peuvent les distinguer — ils partagent le même (uid, modification_id).

• La consolidation les préserve (le garde-fou _max_obj_per_ds détecte qu'un même dataset porte plusieurs objet pour la version → pas de fusion, pas de perte à cette étape).
• Mais ils se télescopent au final : normalize_tables (src/tasks/output.py:216) déduplique la table marches sur unique(["uid", "modification_id"]) → un des contrats en collision est supprimé de la sortie publiée.

Ordre de grandeur : ~720 versions concernées (mesure approximative, grain (uid, modification_id), basée sur la multiplicité d'objet).

Exemple

uid=778770198000272024TX00 (avant ajout du CPV), acheteur ayant réutilisé id="2024TX00" pour de nombreux lots. Au 2025-11-17, codeCPV=45210000, dans le dataset aws_marches-publics.info, deux lots distincts :

• Consultation des lots n°9, 12, 16 et 21 …
• Reconsultation des lots n°3 et 18 …

Même acheteur, même id, même CPV, même date, même dataset → indistinguables par les clés structurées.

Pistes (non retenues pour l'instant, complexe)

Il faudrait une référence de marché fiable propre à chaque contrat (ex. 22V0320AO, 23V0141MN qu'on retrouve parfois dans l'objet), mais :

• elle est souvent absente ou non normalisée dans la source ;
• l'extraire de l'objet (texte libre, bruité) serait fragile et risquerait de sur-découper les vrais doublons.

Décision : pas de traitement pour l'instant. Documenté ici comme limitation connue.

[ColinMaudry]

Exemple avec Le Mans Métropole :

marches_247200132000142024559.csv