processing-sitadel

Publie les données Sitadel (autorisations d'urbanisme, SDES) dans data-fair, en y ajoutant leur géoréférencement cadastral.

Un traitement par fichier source, via processFile : logements, locaux, amenager, demolir.

Ce que fait le traitement

1. lib/download.ts — retrouve l'identifiant du « datafile » DiDo depuis l'API data.gouv, puis télécharge le CSV complet. Échoue si plusieurs ressources correspondent au type demandé, plutôt que de n'en garder qu'une silencieusement.
2. lib/execute.ts — compare l'en-tête téléchargée au schéma embarqué et signale les colonnes disparues ou apparues, puis enchaîne les étapes.
3. lib/process.ts — pour chaque commune :
   • géocode les adresses par paquets de 10 000 via api-adresse.data.gouv.fr ;
   • interroge le jeu des parcelles cadastrales avec une regex code:/{codeCommune}.{5}({numéros})/ — le joker couvre le préfixe cadastral, que Sitadel ne fournit pas ;
   • filtre les candidates par section, et quand plusieurs subsistent, retient la plus proche du point géocodé ;
   • ajoute latitude, longitude, parcelle, parcel_confidence. Le géocodage lui-même n'est pas conservé, il ne sert qu'à cet arbitrage.
4. lib/upload.ts — envoie le CSV et, si forceUpdate, le schéma lib/schemas/<processFile>.json.

L'apport réel du traitement, ce sont ces 4 colonnes. Tout le reste est du passe-plat sur un fichier source déjà public et exploitable.

Ce n'est pas remplaçable par un enrichissement data-fair : les deux services cadastre disponibles (cadastre-koumoul/findParcellesBulk et le bulkSearch parcelle-coords) exigent le code parcelle complet en correspondance exacte (commune 5 + préfixe 3 + section 2 + numéro 4). Reconstruire ce code naïvement en supposant le préfixe 000 ne retombe juste que dans 87 % des cas, contre 97 % de parcelles résolues par le traitement (mesuré sur 1 500 lignes de l'Ain, août 2026).

Historique : l'incident d'avril → août 2026

sitadel-locaux est resté figé au 2026-03-05 pendant cinq mois sans qu'aucune alerte ne remonte (work item 71).

En avril 2026 le SDES a modifié le fichier locaux : suppression de DPC_PREM, ADR_TYPEVOIE_TER et des cinq SURF_ART_* (l'artisanat n'est plus une destination autonome, il est fondu dans SURF_COM_* — « Commerce et activités de service », art. R. 151-27 — rétroactivement sur tout l'historique), ajout de DR_DEPOT. La colonne calculée surf_art_projet du jeu de données n'avait donc plus aucune de ses variables. Or côté data-fair les échecs exprEval sont marqués mandatory: true en dur : le brouillon échouait sur 100 % des lignes et n'a plus jamais été validé, pendant que les runs mensuels se terminaient en finished.

Le garde-fou correspondant est maintenant en place : checkSchemaDrift compare l'en-tête de la source au schéma embarqué à chaque passage et émet un log.warning nominatif sur les colonnes disparues et apparues.

Améliorations restant à prévoir

1. Déplacer les colonnes calculées SURF_*_PROJET dans le traitement. C'est de l'arithmétique sur des colonnes déjà présentes dans le fichier (SURF_X_AVANT - SURF_X_DEMOLIE + SURF_X_ISSUE_TRANSFO - SURF_X_TRANSFORMEE + SURF_X_CREEE). Les garder en extensions exprEval côté data-fair est la cause directe du gel : calculées dans lib/process.ts, une colonne source disparue produirait simplement une colonne en moins, pas un blocage. Retirer les extensions du jeu dans le même déploiement, sinon les colonnes existent en double. _infos_commune reste légitimement côté data-fair : c'est une jointure sur un référentiel vivant, et elle est non bloquante.

2. Reprendre lib/schemas/amenager.json et demolir.json. Ceux de locaux et logements ont été repris en août 2026 : ordre, x-group, titres, descriptions, concepts et surcharges de type. Les deux autres sont restés dans leur état d'origine, avec des clés qui ne correspondent plus à la source (REG, Num_DAU, sec_cadastre1… alors qu'elle est passée en majuscules).

3. Aplatir dataset en datasetTitle dans la branche « création » du schéma de configuration, conformément au template. Non fait volontairement : renommer une propriété fait perdre sa valeur aux configurations existantes (removeAdditional), et aucune ne devait être cassée lors de la migration.

Surcharger un type détecté

Déclarer "type" dans le schéma d'un jeu de données ne suffit pas : cleanSchema (api/src/datasets/utils/data-schema.ts de data-fair) écrase le type déclaré par celui détecté dans le fichier. Deux leviers seulement, appliqués dans cet ordre :

• "x-transform": { "type": "string" } — le remplaçant de ignoreDetection, déprécié et supprimé par l'upgrade 4.34.0 ;
• un x-refersTo dont le concept est de type string dans api/contract/vocabulary.js, qui force la conversion (c'est ce qui préserve les zéros de tête de COMM).

Sans cela, une colonne de codes numériques est stockée en integer et perd ses zéros de tête — c'était le cas de REG_CODE, où les régions d'outre-mer étaient enregistrées 1, 2, 3, 4, 6 au lieu de 01, 02, 03, 04, 06.

Configuration

Voir processing-config-schema.json.

Points d'attention :

• forceUpdate: true (config de production pour locaux) réécrit le schéma du jeu à chaque passage et désactive le contrôle de cohérence de l'en-tête. Toute personnalisation faite à la main sur le schéma du jeu est alors écrasée.
• clearFiles vide le répertoire de travail en fin de passage.
• urlLimit (2000 par défaut) borne la longueur des requêtes parcelles. Ce paramètre était auparavant dans un plugin-config-schema.json réservé aux super-admins ; ce mécanisme est déprécié et disparaît en processings 7.0.

Développement

Le plugin s'exécute en TypeScript natif sur Node 24 (--experimental-strip-types), sans étape de compilation.

npm install
npm run build-types    # après toute modification de processing-config-schema.json
npm run lint
npm test

Les tests d'intégration réels nécessitent un config/local-test.mjs (gitignoré) contenant dataFairUrl et dataFairAPIKey.

Ne pas toucher au champ version de package.json : les publications sont automatisées (push sur main → registre de staging, tag v* → production).