Le format CDJ Connect

Archive figée de la version 1.1 — snapshot du 10 septembre 2026 avant publication de la 1.2. Le contenu ci-dessous reproduit la version alors publiée ; ses indications de version et de révision sont historiques. Les liens internes à la spécification, au schéma, aux référentiels et aux exemples pointent vers leurs copies archivées.

Version publiée : 1.1 — stable. Cette URL présente toujours la dernière version publiée du standard. Révision documentaire : 7 septembre 2026. Consulter le changelog et les versions archivées.

CDJ Connect est une proposition ouverte de format EDI commun pour les logiciels métier de commissaires de justice. Cette proposition est portée initialement par Raydocs, société qui développe des outils IA pour les études: création de dossiers, mise à jour de dossiers, analyse de pièces et enrichissement de données métier.

Pourquoi CDJ Connect

Les études dépendent aujourd'hui fortement de leurs logiciel métier pour mettre en place de nouveaux flux EDI, intégrer des données externes ou automatiser des traitements métier. Chaque nouveau donneur d'ordre, prestataire ou outil spécialisé entraîne souvent une intégration spécifique, coûteuse à cadrer et difficile à mutualiser entre les logiciels métier. CDJ Connect vise d'abord à définir un modèle de données commun pour représenter un dossier de commissaire de justice, indépendamment du logiciel métier utilisé par l'étude. Ce modèle couvre notamment les références dossier, intervenants, adresses, contacts, pièces, créances, montants, intérêts, actes, mesures, agenda et événements métier. En standardisant cette représentation, CDJ Connect facilite l'interopérabilité entre les écosystèmes logiciel métier: chaque éditeur peut mapper ce modèle pivot vers son modèle interne, tandis que les prestataires validés peuvent produire un format unique plutôt qu'un format différent par logiciel métier. L'objectif est d'harmoniser les efforts d'intégration, d'élargir le champ des outils pouvant aider les commissaires de justice, et de réduire le coût de mise en place de nouveaux imports de données. Le principe est volontairement pragmatique: CDJ Connect ne remplace pas les logiciels métier et ne contourne pas leurs contrôles. Il s'appuie au contraire sur l'infrastructure EDI existante côté logiciel métier: dépôt de fichiers, import contrôlé, traçabilité, validation humaine, gestion des anomalies et rejets.

Statut de la proposition

Cette spécification est une proposition ouverte. Elle peut servir de base commune de discussion entre éditeurs logiciel métier, chambres, études et prestataires techniques. Point important: cette page décrit d'abord un modèle de données et un format d'échange, pas un protocole de transport complet. Elle fixe le contrat que doit respecter un lot CDJ Connect: structure du ZIP, fichier lot.json, champs métier, référentiels, règles de validation et principes de rejet. Les modalités exactes de dépôt, supervision, ordonnancement, archivage ou exploitation interne restent adaptables par chaque logiciel métier ou par chaque projet. En v1, le format décrit uniquement un sens fonctionnel entrant vers logiciel métier. Un prestataire émetteur produit un lot ZIP structuré, puis le logiciel métier destinataire importe ce lot depuis une arborescence dédiée.

Acteurs

Périmètre V1

Le sens fonctionnel attendu est:

Prestataire émetteur
  -> produit un ZIP CDJ Connect
  -> dépose/transmet le ZIP dans CDJCONNECT/IN/
  -> le logiciel métier importe le ZIP

Cette séquence illustre le fonctionnement cible, mais le coeur de la spécification reste le format du lot importable. Inclus en v1:

• création de dossier;
• mise à jour de dossier existant;
• ajout de pièces documentaires: images, PDF, Word, Excel et EML;
• transmission d'intervenants;
• transmission d'éléments financiers;
• transmission d'actes, mesures et actions agenda;
• typage métier par référentiels communs;
• rejet global ou partiel d'un lot. Hors périmètre v1:
• flux métier logiciel métier vers prestataire;
• synchronisation bidirectionnelle temps réel;
• obligation pour le logiciel métier de produire un document métier retour;
• remplacement des circuits de validation humaine existants.

Répertoires du logiciel métier

L'arborescence suivante est une convention minimale recommandée pour déposer et classer les lots CDJ Connect:

CDJCONNECT/
  IN/
  EN_COURS/
  ARCHIVE/
  REJET/

Règles:

• CDJCONNECT/ est le répertoire racine dédié au format CDJ Connect;
• CDJCONNECT/IN/ reçoit les ZIP à traiter;
• CDJCONNECT/EN_COURS/ peut être utilisé par le logiciel métier pendant le traitement;
• CDJCONNECT/ARCHIVE/ reçoit les lots traités avec succès;
• CDJCONNECT/REJET/ reçoit les lots non traités ou traités en erreur;
• le prestataire n'est pas codé dans le chemin, il est identifié dans lot.json. Le répertoire CDJCONNECT/ doit être séparé de toute arborescence EDI déjà utilisée par un autre connecteur, afin d'éviter qu'un traitement externe prenne un lot CDJ Connect en charge par erreur.

Format du ZIP

Nom du fichier

Le nom du ZIP doit seulement être unique dans CDJCONNECT/IN/.

<nom_unique>.zip

Exemples:

20260520-103000-7f3a9c.zip
lot-01HXABC123.zip
cdjconnect-20260520-0001.zip

Règles:

• le fichier doit avoir l'extension .zip;
• le nom doit être unique pour éviter les collisions;
• le logiciel métier ne doit pas parser le nom du ZIP pour comprendre le contenu métier;
• la source de vérité est lot.json, notamment en_tete.id_lot.

Contenu du ZIP

lot.json
pieces/
  <nom_fichier_unique>.<extension>

Règles:

• lot.json est obligatoire et doit être à la racine du ZIP;
• les pièces sont optionnelles;
• les pièces sont référencées depuis le JSON par piece_jointe.chemin;
• les chemins doivent être relatifs au ZIP;
• les chemins absolus et les séquences ../ sont interdits;
• les fichiers de pièces ne doivent pas être encodés en base64 dans le JSON;
• l'arborescence pieces/ ne porte aucune sémantique métier obligatoire.

Exemple d'arborescence ZIP

lot-01HXABC123.zip
  lot.json
  pieces/
    piece-001.pdf
    piece-002.pdf

Dans cet exemple, le rattachement des fichiers aux dossiers ne vient pas du dossier pieces/. Il vient des objets pieces_jointes[] dans lot.json.

Structure JSON

Références utiles: JSON Schema CDJ Connect v1.1

{
  "version_format": "1.1",
  "en_tete": {},
  "service_destinataire": {},
  "dossiers": []
}

Champs racine:

en_tete

Références utiles: JSON Schema CDJ Connect v1.1 · Référentiels CDJ Connect

{
  "id_lot": "LOT-20260520-0001",
  "date_lot": "2026-05-20T10:30:00+02:00",
  "environnement": "production",
  "sens_transmission": "EMETTEUR_VERS_ERP",
  "type_flux": "IMPORT_DOSSIERS",
  "emetteur": {
    "type": "PRESTATAIRE",
    "code": "RAYDOCS",
    "nom": "Raydocs"
  },
  "destinataire": {
    "type": "ERP",
    "code": "ETUDE_DUPONT",
    "nom": "SCP Dupont",
    "logiciel": "LOGICIEL_METIER"
  }
}

Règles:

• id_lot identifie le lot ZIP, pas un dossier;
• sens_transmission vaut EMETTEUR_VERS_ERP en v1;
• type_flux vaut IMPORT_DOSSIERS en v1;
• emetteur.code identifie le prestataire émetteur, par exemple RAYDOCS;
• destinataire identifie l'étude, le logiciel métier ou le tenant cible;
• les traces techniques internes d'un prestataire ne font pas partie du coeur du modèle CDJ Connect;
• si un projet en a besoin, ces traces peuvent être transmises dans extensions_prestataire, sans valeur métier standard;
• aucune extension prestataire ne doit servir au rapprochement métier.

service_destinataire

Références utiles: JSON Schema CDJ Connect v1.1 · Référentiels CDJ Connect

{
  "code": "SVC-CONTENTIEUX",
  "libelle": "Contentieux"
}

Règles:

• service_destinataire est obligatoire au niveau racine du lot;
• tous les dossiers du ZIP sont destinés à ce même service;
• un même ZIP ne doit pas mélanger plusieurs services;
• service_destinataire.code est scoped au destinataire et convenu par projet;
• service_destinataire.code n'est pas une enum globale CDJ Connect;
• le logiciel métier peut utiliser ce code pour choisir, mapper ou filtrer le numéro de service interne à importer.

Extensions prestataire optionnelles

Références utiles: JSON Schema CDJ Connect v1.1 Le coeur du format CDJ Connect doit rester indépendant d'un prestataire particulier. Les identifiants internes d'exécution, de workflow, de traitement IA ou de support ne doivent donc pas être ajoutés dans les champs standard. Si un prestataire a besoin de transmettre une trace technique utile au support, il peut utiliser extensions_prestataire. Ces données sont optionnelles, non métier, et ignorables par le logiciel métier si elles ne sont pas prévues par le projet.

{
  "extensions_prestataire": {
    "RAYDOCS": {
      "workflow_run_uuid": "018f4b4e-7f8a-7b9b-9d4b-1c2d3e4f5a6b"
    }
  }
}

Règles:

• extensions_prestataire ne doit pas contenir de donnée nécessaire à l'import standard;
• le logiciel métier peut ignorer entièrement ce bloc;
• aucune clé d'extension ne doit être utilisée pour créer, mettre à jour ou rapprocher un dossier;
• les champs utiles au contrat commun doivent être ajoutés au modèle CDJ Connect plutôt que cachés dans une extension.

dossiers

Références utiles: JSON Schema CDJ Connect v1.1 · Référentiels CDJ Connect Un dossier correspond à un dossier métier géré par le logiciel métier.

{
  "reference_client": "CLI-12345",
  "reference_dossier_destinataire": null,
  "references_externes": [],
  "nature_dossier": "INJONCTION_DE_PAYER",
  "libelle_nature_dossier": "Injonction de payer",
  "code_nature_dossier_externe": null,
  "source_code_nature_dossier": null,
  "numero_rg": null,
  "evenements": [],
  "renseignements": [],
  "intervenants": [],
  "elements_financiers": [],
  "mesures": [],
  "actes": [],
  "agenda": [],
  "pieces_jointes": []
}

Champs principaux:

Identifiants de personne morale et numéro RG

intervenants[].ipm porte identifiants légaux de la personne morale : siret, siren, numero_rcs, greffe_rcs, numero_tva et numero_rna. Ils sont tous optionnels; siret reste le champ existant. dossiers[].numero_rg est une référence de procédure optionnelle portée directement par le dossier. Le Kbis est une pièce documentaire et utilise pieces_jointes[].categorie: KBIS; il n'est pas un champ d'identification de ipm. Ces valeurs ne doivent pas être transmises dans renseignements[].

Identification et rapprochement dossier

Références utiles: JSON Schema CDJ Connect v1.1 Le rapprochement d'un dossier se fait toujours dans le périmètre du destinataire et du service_destinataire.code du lot. Deux clés de rapprochement sont supportées:

• service_destinataire.code + reference_client, référence métier externe stable;
• service_destinataire.code + reference_dossier_destinataire, identifiant du dossier déjà connu dans le logiciel métier. Règles:
• service_destinataire est obligatoire au niveau du lot pour router tous les dossiers du ZIP vers le bon service, pôle ou portefeuille du logiciel métier;
• pour OUVERTURE_DOSSIER, reference_client est obligatoire afin de créer une référence externe stable;
• pour MISE_A_JOUR_DOSSIER, AJOUT_PIECE, MISE_A_JOUR_CREANCE, ACTE_A_SIGNIFIER, AJOUT_ACTION_AGENDA ou tout autre événement appliqué à un dossier existant, reference_dossier_destinataire peut suffire si le dossier existe dans le service du lot;
• si reference_client et reference_dossier_destinataire sont tous les deux renseignés, ils doivent pointer vers le même dossier dans le même service;
• si reference_dossier_destinataire existe mais appartient à un autre service, le dossier doit être rejeté;
• si aucune des deux références ne permet de retrouver le dossier pour un événement de mise à jour, le dossier doit être rejeté;
• lors d'une ouverture avec reference_client, le logiciel métier doit enregistrer la correspondance destinataire + service_destinataire.code + reference_client -> dossier du logiciel métier;
• references_externes[] sert aux références secondaires et ne remplace ni reference_client, ni reference_dossier_destinataire;
• les anciens identifiants plats de type identifiant_creance ou identifiant_defendeur ne font pas partie du coeur du modèle: utiliser elements_financiers[].reference_element_financier et intervenants[].reference_client;
• il n'existe pas de référence métier propre à Raydocs ou à un autre prestataire dans le format;
• en_tete.id_lot identifie le ZIP, pas le dossier;
• les extensions prestataire éventuelles sont des traces techniques ignorables et ne participent jamais au rapprochement. Algorithme recommandé côté logiciel métier:

1. lire le code_evenement principal du dossier pour connaître l'action attendue;
2. si reference_dossier_destinataire est renseignée, chercher ce dossier dans destinataire + service_destinataire.code;
3. si aucun dossier n'est trouvé par reference_dossier_destinataire et que reference_client est renseignée, chercher une correspondance déjà importée pour destinataire + service_destinataire.code + reference_client;
4. si les deux références sont renseignées et pointent vers deux dossiers différents, rejeter le dossier;
5. si code_evenement = OUVERTURE_DOSSIER et qu'aucun dossier n'existe, créer le dossier et mémoriser la correspondance service_destinataire.code + reference_client -> dossier du logiciel métier;
6. si code_evenement = OUVERTURE_DOSSIER et que le dossier existe déjà, traiter comme un rejeu ou un doublon selon la politique projet, sans créer de second dossier;
7. si l'événement suppose un dossier existant et qu'aucun dossier n'est retrouvé, rejeter le dossier ou le lot selon la stratégie d'import;
8. si un dossier existant est retrouvé, appliquer l'événement de manière ciblée sur ce dossier.

Typage métier du dossier

Références utiles: Référentiels CDJ Connect · JSON Schema CDJ Connect v1.1nature_dossier, mesures[] et actes[] servent au routage métier. Ils complètent evenements[]: l'événement indique le traitement à appliquer, tandis que le typage décrit le domaine fonctionnel du dossier. Règles:

• utiliser les enums CDJ Connect quand elles couvrent le cas;
• utiliser AUTRE avec un libelle_* explicite quand le cas n'est pas couvert;
• utiliser code_*_externe et source_code_* pour porter une nomenclature logiciel métier, client ou métier plus précise;
• le logiciel métier ne doit pas remplacer les enums CDJ Connect par les seuls codes externes: les codes externes servent au mapping fin.

evenements

Références utiles: Référentiels CDJ Connect · JSON Schema CDJ Connect v1.1 Les evenements[] indiquent au logiciel métier quel traitement métier appliquer au dossier. En v1, un lot contient généralement un événement principal par dossier, mais le format accepte une liste pour les cas où plusieurs actions doivent être transmises ensemble.

{
  "code_evenement": "OUVERTURE_DOSSIER",
  "date_effet": "2026-05-20",
  "libelle": "Ouverture dossier",
  "renseignements": []
}

code_evenement porte l'intention d'import: ouvrir un dossier, mettre à jour un dossier existant, ajouter une pièce, créer ou préparer un acte, mettre à jour une créance, etc. Les codes d'événement sont des codes CDJ Connect: lisibles, stables et mappables par le logiciel métier. Ils expriment une intention métier, pas une implémentation technique interne.

Renseignements typés

Les renseignements[] permettent de transmettre des variables métier et du contexte sans détourner les champs canoniques du format. Règles:

• type est la clé stable d'identification et de mapping; l'ordre du tableau n'a aucune sémantique;
• dossiers[].renseignements[] est l'emplacement canonique des variables métier qui décrivent le dossier;
• dossiers[].evenements[].renseignements[] décrit uniquement le contexte de l'événement concerné;
• un logiciel métier peut mapper un type vers une variable, un champ ou une note selon sa configuration;
• un type inconnu peut être ignoré sans bloquer l'import;
• l'absence d'un renseignement dans une mise à jour ne supprime aucune valeur existante;
• les renseignements ne remplacent pas les champs canoniques tels que nature_creance, numero_rg ou les identifiants de ipm.

{
  "renseignements": [
    {
      "type": "synthese_dossier",
      "valeur": "Impayés portant sur trois factures d'électricité."
    }
  ],
  "evenements": [
    {
      "code_evenement": "MISE_A_JOUR_DOSSIER",
      "date_effet": "2026-07-23",
      "renseignements": [
        {
          "type": "commentaire",
          "valeur": "Le créancier confirme la mise à jour transmise."
        }
      ]
    }
  ]
}

Objets métier

Intervenants

Références utiles: Référentiels CDJ Connect · JSON Schema CDJ Connect v1.1intervenants[] peut contenir autant d'intervenants que nécessaire. Chaque entrée représente le lien entre le dossier et une personne physique ou morale. Le role est toujours obligatoire car il décrit la relation de l'intervenant avec ce dossier. Deux références distinctes sont prévues:

• dossiers[].intervenants[].reference_client est la référence stable attribuée par le client ou le système source;
• dossiers[].intervenants[].reference_intervenant_destinataire est l'identifiant d'une fiche déjà connue dans le logiciel métier destinataire. La nomenclature complète est donc:
• dossiers[].reference_client;
• dossiers[].reference_dossier_destinataire;
• dossiers[].intervenants[].reference_client;
• dossiers[].intervenants[].reference_intervenant_destinataire. Règles de création et de réutilisation:
• sans reference_intervenant_destinataire, exactement un objet parmi ipp ou ipm est obligatoire; reference_client est optionnelle;
• si ni reference_client ni reference_intervenant_destinataire n'est renseignée, le logiciel métier crée un nouvel intervenant à partir de ipp ou ipm, sans référence externe;
• avec reference_intervenant_destinataire, ipp et ipm ne sont pas requis: le logiciel métier doit réutiliser et lier la fiche existante sans créer de doublon;
• si la référence destinataire est fournie mais introuvable, le logiciel métier doit rejeter l'objet ou signaler une anomalie, sans création silencieuse;
• si reference_client et reference_intervenant_destinataire sont fournis ensemble, ils doivent correspondre au même intervenant;
• les données d'identité éventuellement fournies avec l'identifiant destinataire ne doivent pas écraser automatiquement la fiche maître du logiciel métier;
• lors d'une MISE_A_JOUR_DOSSIER, chaque intervenant présent dans intervenants[] est ajouté ou ciblé; les autres intervenants du dossier restent inchangés;
• un même intervenant du logiciel métier peut porter des rôles différents selon les dossiers;
• il est interdit de fournir simultanément ipp et ipm;
• plusieurs intervenants peuvent avoir la même famille de rôle; les suffixes numériques distinguent les occurrences quand c'est utile, par exemple DEF01, DEF02, DEF03. Création d'un intervenant:

{
  "reference_client": "DEF-001",
  "role": "DEF01",
  "ipp": {
    "civilite": "M",
    "nom": "DUPONT",
    "prenom": "Jean"
  },
  "contacts": [
    {
      "type": "EMAIL",
      "valeur": "jean.dupont@example.com"
    },
    {
      "type": "TEL",
      "valeur": "+33601020304"
    }
  ]
}

Réutilisation d'un intervenant déjà connu dans le logiciel métier:

{
  "reference_intervenant_destinataire": "ERP-INTERV-10",
  "role": "CRE01"
}

Identifiants de personne morale

Les identifiants légaux sont portés dans ipm: siret, siren, numero_rcs, greffe_rcs, numero_tva et numero_rna. numero_rcs et greffe_rcs sont à renseigner ensemble lorsqu'ils sont connus.

{
  "ipm": {
    "raison_sociale": "Exemple SAS",
    "siret": "12345678901234",
    "siren": "123456789",
    "numero_rcs": "123456789",
    "greffe_rcs": "Lyon",
    "numero_tva": "FR12345678901",
    "numero_rna": "W123456789"
  }
}

Contacts, adresses et comptes bancaires

Références utiles: Référentiels CDJ Connect · JSON Schema CDJ Connect v1.1 Les contacts se portent sur l'objet intervenant: chaque contact a un type (EMAIL, TEL, FAX) et une valeur. TEL couvre les numéros fixes et mobiles; plusieurs contacts TEL peuvent être transmis pour un même intervenant. Les adresses se portent dans ipp.adresses[] ou ipm.adresses[]. Chaque adresse contient les champs usuels ligne1, ligne2, ligne3, code_postal, ville et pays. Les champs type, label et principal sont optionnels: ils servent seulement à qualifier l'adresse si le projet en a besoin, sans imposer d'enum globale. Les comptes bancaires se portent dans ipp.comptes_bancaires[] ou ipm.comptes_bancaires[]. Chaque compte bancaire doit avoir un iban. Le bic, le titulaire, la domiciliation, principal et reference_compte_bancaire sont optionnels. L'IBAN et le BIC doivent être normalisés en majuscules et sans espaces. Les adresses et coordonnées bancaires ne participent jamais au rapprochement dossier.

Éléments financiers

Références utiles: Référentiels CDJ Connect · JSON Schema CDJ Connect v1.1reference_element_financier reste l'identifiant stable de la créance. nature_creance décrit sa nature métier globale; ce champ est optionnel mais recommandé lorsqu'il est connu. Le champ libelle de chaque ligne de montant_details[] est optionnel. Lorsqu'il est transmis, il décrit la ligne de montant. L'ancien champ non défini nature ne doit pas être utilisé sur les lignes de montant. Les montants sont transmis sous forme de chaînes décimales avec . comme séparateur.

{
  "reference_element_financier": "CREANCE-123",
  "nature_creance": "Factures d'électricité impayées",
  "montant_details": [
    {
      "type": "principal",
      "libelle": "Facture n°12 — février 2025",
      "classe": "CRE",
      "devise": "EUR",
      "signe": "+",
      "montant": "177.82",
      "date": "2025-02-28"
    }
  ],
  "interets": []
}

Agenda

Références utiles: Référentiels CDJ Connect · JSON Schema CDJ Connect v1.1agenda[] sert aux tâches, rappels, rendez-vous ou actions opérationnelles à créer dans le logiciel métier. Ce bloc est distinct de evenements[].

Pièces jointes

Références utiles: Référentiels CDJ Connect · JSON Schema CDJ Connect v1.1

{
  "reference_piece": "DOC-BAIL",
  "nom": "bail.pdf",
  "chemin": "pieces/piece-001.pdf",
  "date_piece": "2024-10-02",
  "categorie": "BAIL",
  "type": "PDF",
  "mime_type": "application/pdf",
  "hash": "sha256:abcdef..."
}

Règles:

• chemin est le chemin relatif du fichier dans le ZIP;
• chemin est la seule source de vérité pour localiser le fichier;
• type indique la famille de pièce supportée: IMAGE, PDF, WORD, EXCEL ou EML;
• categorie, lorsqu'elle est renseignée, est une valeur de l'enum CDJ Connect défini dans les référentiels;
• mime_type est optionnel mais recommandé pour contrôler le format réel du fichier;
• pour une pièce EML, mime_type doit valoir message/rfc822 quand il est renseigné;
• hash est optionnel, format recommandé sha256:<hex>.

Traitement et rejets

Références utiles: Référentiels CDJ Connect · Exemples CDJ Connect Le logiciel métier traite chaque ZIP comme une unité de traitement. Il peut déplacer le ZIP dans CDJCONNECT/EN_COURS/ pendant l'import, puis le déplacer dans le répertoire final selon le résultat.

flowchart LR
  A["CDJCONNECT/IN/<lot>.zip"] --> B["Contrôle ZIP + lot.json"]
  B --> C["Import logiciel métier"]
  C -->|Succès complet| D["CDJCONNECT/ARCHIVE/"]
  C -->|Échec bloquant| E["CDJCONNECT/REJET/"]
  C -->|Partiel autorisé| F["CDJCONNECT/ARCHIVE/ + rapport"]

Règles:

• un succès complet déplace le ZIP vers CDJCONNECT/ARCHIVE/;
• un échec bloquant déplace le ZIP vers CDJCONNECT/REJET/;
• un échec bloquant inclut notamment ZIP illisible, lot.json absent ou invalide, schéma invalide, pièce obligatoire introuvable, chemin interdit ou erreur de sécurité;
• l'acceptation partielle est autorisée seulement si le logiciel métier sait tracer les objets importés et les objets rejetés;
• si le logiciel métier ne sait pas gérer proprement l'acceptation partielle, il doit rejeter le lot complet;
• un rapport de rejet est optionnel, mais recommandé pour tout rejet ou partiel;
• ce rapport sert notamment à l'étude pour identifier les dossiers en problème et au support pour diagnostiquer;
• un lot corrigé doit être renvoyé avec un nouvel en_tete.id_lot. Le format recommandé du rapport est documenté dans la sous-page d'exemples.

Rejeu et mise à jour sans doublons

Le logiciel métier peut recevoir deux fois le même ZIP, ou recevoir plus tard un nouveau lot qui parle du même dossier. Dans ces cas, il doit retrouver les objets déjà importés grâce aux références stables, puis appliquer l'action demandée par code_evenement sans créer de doublons. Principe:

• en_tete.id_lot identifie le lot ZIP;
• le dossier est retrouvé par service_destinataire.code + reference_client ou par service_destinataire.code + reference_dossier_destinataire;
• code_evenement indique l'action à appliquer;
• une mise à jour CDJ Connect est un append ciblé: les champs et collections absents ne suppriment rien dans le logiciel métier;
• seuls les objets transmis dans le lot sont à créer, rattacher ou mettre à jour selon l'événement;
• une suppression, un remplacement complet ou une annulation doivent être exprimés par un événement explicite, pas par l'absence d'un champ;
• les références stables identifient les objets concernés: intervenants[].reference_client, intervenants[].reference_intervenant_destinataire, reference_piece, reference_acte, etc. Matrice de comportement recommandée:

Validation

Références utiles: JSON Schema CDJ Connect v1.1 · Référentiels CDJ Connect

• lot.json doit être présent à la racine du ZIP.
• Le lot doit avoir un service_destinataire.code non vide.
• Chaque dossier doit avoir au moins une référence de rapprochement: reference_client ou reference_dossier_destinataire.
• reference_client est obligatoire pour une ouverture de dossier.
• Chaque dossier doit avoir au moins un evenements[].
• Chaque intervenant doit avoir un role et respecter l'une des deux branches: reference_intervenant_destinataire, ou exactement un bloc ipp ou ipm. reference_client est optionnelle dans la seconde branche.
• ipp et ipm ne peuvent jamais être fournis simultanément.
• Chaque contact d'intervenant, s'il est transmis, doit avoir un type parmi EMAIL, TEL ou FAX, et une valeur.
• Le champ libelle est optionnel dans chaque ligne de montant_details[]; lorsqu'il est transmis, il peut être utilisé comme libellé lisible de la ligne.
• nature_creance est optionnel mais recommandé sur chaque élément financier lorsqu'il est connu.
• Chaque adresse d'intervenant, si elle est transmise, doit contenir au moins une ligne, une ville, un code postal ou un pays.
• Chaque compte bancaire d'intervenant, s'il est transmis, doit avoir un iban non vide.
• Le logiciel métier doit valider les coordonnées bancaires avant création ou mise à jour.
• Les extensions prestataire éventuelles doivent rester optionnelles et ignorables.
• Chaque piece_jointe.chemin doit pointer vers un fichier existant dans le ZIP.
• Les chemins doivent être relatifs, jamais absolus.
• Les chemins ne doivent pas contenir ../.
• Le type de pièce doit être l'un des types supportés: IMAGE, PDF, WORD, EXCEL ou EML.
• Les fichiers de pièces ne doivent pas être encodés dans le JSON.
• Les montants doivent être des chaînes décimales avec . comme séparateur.
• Les dates simples doivent être en YYYY-MM-DD.
• Les dates et heures doivent être en ISO 8601.
• Le logiciel métier doit mettre en anomalie ou rejeter un événement dont le code_evenement n'est pas supporté par son mapping.
• Si nature_dossier, type_mesure ou type_acte vaut AUTRE, le libelle_* correspondant doit être renseigné.
• Les codes externes ne doivent pas être utilisés seuls pour router le lot: ils complètent les enums CDJ Connect.

Versioning et gouvernance

• version_format est obligatoire.
• Une version mineure peut ajouter des champs optionnels sans changer le sens des champs existants.
• Un changement de sens, de structure obligatoire ou de comportement incompatible impose une nouvelle version majeure.
• Par défaut, le logiciel métier doit ignorer les champs inconnus qu'il ne supporte pas.
• Un mode de validation stricte peut rejeter les champs inconnus si le projet le demande.
• Les nouveaux codes de référentiel doivent être ajoutés sans casser les codes existants.
• Les prestataires émetteurs doivent être identifiés dans en_tete.emetteur.
• Les extensions prestataire peuvent être ajoutées pour des besoins techniques locaux, mais ne doivent pas modifier le contrat standard.
• Les logiciels métier restent responsables de leurs contrôles métier internes.
• Un JSON Schema versionné est maintenu dans la sous-page JSON Schema CDJ Connect v1.1.

Contraintes de sécurité minimales

Cette spécification ne dicte pas la politique de sécurité interne de chaque logiciel métier. Elle impose seulement les contraintes de contrat suivantes:

• chemins relatifs uniquement;
• chemins absolus interdits;
• séquences ../ interdites;
• formats attendus pour les pièces limités aux types supportés: images, PDF, Word, Excel et EML;
• tailles maximales de ZIP, fichiers et nombre de pièces à convenir par projet;
• le récepteur peut rejeter un lot pour raison de sécurité ou dépassement de limites.

Ressources

Référentiels CDJ ConnectJSON Schema CDJ Connect v1.1Exemples CDJ ConnectChangelog et versions CDJ Connect