Synchronisation Cart@DS ↔ PLAT’AU — Mairie de Montrouge

Contexte & enjeux

La Ville voulait fluidifier et fiabiliser le traitement des autorisations d’urbanisme en synchronisant Cart@DS (outil local) avec PLAT’AU (État), tout en réduisant les ressaisies, les erreurs de pièces et en améliorant la traçabilité.

MOAUrbanismeIntégration IdempotenceRejeuSupervision RGPD
  • Rôle : MOA / Chef de projet (cadrage, pilotage, recette, RUN)
  • Objectifs : synchro statuts/méta, contrôle pièces, traçabilité & rejeu sans doublon
  • Livrables : mapping statuts, specs fonctionnelles, plan de tests, runbook
1) Contexte & rôle (MOA) ▼

Enjeux : ressaisies, erreurs de pièces, suivi morcelé, traçabilité faible.

  • Cadrage fonctionnel : besoin, périmètre, règles de gestion.
  • Pilotage : ateliers Urbanisme/SI/éditeur, planning, risques.
  • Qualité : plan de tests, jeux d’essai, UAT, go/no-go.
  • Déploiement & change : com agents, accompagnement, passage en RUN.
2) Objectifs & périmètre livré ▼
  • Synchroniser statuts & métadonnées Cart@DS ↔ PLAT’AU.
  • Transmettre les pièces avec contrôles (formats/tailles) + messages utiles.
  • Assurer traçabilité complète & rejeu idempotent (sans doublon).

Livré : échanges bidirectionnels sur le cycle de vie (dépôt → décision), journal d’échanges exploitable, procédures d’exploitation (supervision, retry/rejeu, escalade N1→N2→éditeur).

3) Architecture (vue simple) ▼ 
Cart@DS  →  Adaptateur d’échanges  →  PLAT’AU
              └─ normalisation
              └─ contrôles (formats/poids)
              └─ idempotence (anti-doublon)
              └─ file + retry + rejeu
              └─ journalisation (horodatage, statut, motif)

L’adaptateur centralise logique de contrôle, mapping et reprise, tout en laissant Cart@DS et PLAT’AU découplés.

4) Démarche & étapes clés ▼

Cadrage

  • Ateliers “parcours dossier” (qui/quoi/quand, événements déclencheurs).
  • Mapping des statuts validé avec le métier (aller-retours sur cas limites).
  • Périmètre pilote → généralisation par vagues.

Spécifications fonctionnelles

  • Data-mapping : identifiants, adresses, typologies de pièces, métadonnées.
  • Règles d’erreur claires (motifs d’incomplet, formats refusés) → messages agents.
  • Idempotence : mêmes identifiants fonctionnels ⇒ pas de doublon en rejeu.

Pré-intégration technique (extraits représentatifs)

Statuts (exemples) :
Cart@DS = Déposé            ↔ PLAT’AU = Dépôt reçu
Cart@DS = Dossier incomplet  ↔ PLAT’AU = Incomplet (motifs normalisés)
Cart@DS = Décision notifiée  ↔ PLAT’AU = Décision communiquée

Pièces jointes :
- Contrôles format/poids ; rejet explicite + message opérable pour l’agent.

Indisponibilité PLAT’AU :
- Mise en file + retry automatique ; information métier ; rejeu une fois rétabli.
5) Recette métier (UAT) — cas joués & critères d’acceptation ▼

Cas nominaux

  • Dépôt complet → statuts alignés jusqu’à la décision ; pièces OK.

Cas non-nominaux

  • Dossier incomplet (motifs), pièce non conforme, indisponibilité PLAT’AU (retry + rejeu).

Acceptation

  • Statuts cohérents Cart@DS ↔ PLAT’AU, messages utiles aux agents, rejeu sans doublon, trace exploitable.
6) Déploiement & conduite du changement ▼
  • Pilote sur périmètre restreint (types de dossiers + agents volontaires).
  • Montée en charge par vagues avec REX.
  • Kit agents : pas-à-pas, FAQ, trames de réponse usagers.
  • Plan de retour arrière documenté (points de coupure, purge de file, rollback).
7) RUN & supervision (exploitation) ▼
  • Suivi des échanges OK/KO, délais, files d’attente.
  • Escalade : N1 (qualification) → N2 (analyse payload/journal) → N3 (éditeur).
  • RGPD : journaux utiles, minimisation des données, rétention maîtrisée.
8) Principales difficultés & solutions apportées ▼
  • Divergences de statuts/champs → ateliers de mapping + exemples réels.
  • Erreurs de pièces → contrôles en amont + messages explicites pour agents.
  • Pics d’indisponibilité PLAT’AU → file d’attente, retry, rejeu au rétablissement.
  • Logs vs confidentialité → traçabilité suffisante sans données sensibles.
9) Résultats (qualitatifs observés) ▼
  • Moins de manipulations manuelles ; cohérence accrue des statuts entre Ville & État.
  • Traçabilité claire des échanges & reprise simple en incident.
  • Agents rassurés : messages compréhensibles, rejeu guidé, support outillé.
10) Livrables clés remis/validés ▼
  • Note de cadrage & périmètre.
  • Spécifications fonctionnelles (règles, mapping, messages).
  • Plan de tests / jeux d’essai & PV de recette.
  • Mode opératoire de déploiement & kit agents.
  • Procédures RUN (supervision, retry/rejeu, escalade, rétention logs).