Le format CDJ Connect

Archive figée — version 1.0. Snapshot créé le 22 juillet 2026. Cette page ne doit plus être modifiée. La version publiée la plus récente reste CDJ Connect - Standard EDI logiciel métier.

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

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

Champs racine:

en_tete

Références utiles: JSON Schema CDJ Connect v1 · 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 · 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 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 · 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,
  "evenements": [],
  "renseignements": [],
  "intervenants": [],
  "elements_financiers": [],
  "mesures": [],
  "actes": [],
  "agenda": [],
  "pieces_jointes": []
}

Champs principaux:

Identification et rapprochement dossier

Références utiles: JSON Schema CDJ Connect v1 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_intervenant;
• 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 v1nature_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 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.

Objets métier

Intervenants

Références utiles: Référentiels CDJ Connect · JSON Schema CDJ Connect v1intervenants[] peut contenir autant d'intervenants que nécessaire. Chaque entrée représente le lien entre le dossier et une personne physique ou morale. Règles:

• chaque intervenant doit avoir une reference_intervenant stable dans le dossier;
• chaque intervenant doit avoir un role;
• un intervenant contient exactement un bloc ipp ou ipm;
• contacts[] est optionnel et peut porter un ou plusieurs emails, téléphones fixes, mobiles ou fax;
• plusieurs intervenants peuvent avoir la même famille de rôle;
• les suffixes numériques des rôles permettent de distinguer les occurrences quand c'est utile, par exemple DEF01, DEF02, DEF03.

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

Contacts, adresses et comptes bancaires

Références utiles: Référentiels CDJ Connect · JSON Schema CDJ Connect v1 Les contacts se portent sur l'objet intervenant: chaque contact a un type (EMAIL, TEL, GSM, FAX) et une valeur. 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 Les montants sont transmis sous forme de chaînes décimales avec . comme séparateur.

{
  "reference_element_financier": "CREANCE-123",
  "montant_details": [],
  "interets": [],
  "renseignements": []
}

Agenda

Références utiles: Référentiels CDJ Connect · JSON Schema CDJ Connect v1agenda[] 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

{
  "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;
• 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 internes aux objets identifient les éléments dans ce dossier: reference_intervenant, reference_piece, reference_acte, etc. Matrice de comportement recommandée:

Validation

Références utiles: JSON Schema CDJ Connect v1 · 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 une reference_intervenant, un role, et exactement un bloc ipp ou ipm.
• Chaque contact d'intervenant, s'il est transmis, doit avoir un type et une valeur.
• 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.

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 Connect — archive v1.0JSON Schema CDJ Connect — archive v1.0Exemples CDJ Connect — archive v1.0