Le format CDJ Connect

Version courante : 1.2 — stable. Révision documentaire : 10 septembre 2026. Historique et migrations : Changelog et versions CDJ Connect.

CDJ Connect est un format d’échange commun pour créer et enrichir des dossiers dans les logiciels métier de commissaires de justice. Un prestataire émetteur transmet un lot contenant les données métier et les pièces ; le logiciel métier destinataire les valide et les intègre à son propre modèle.

Cette proposition ouverte, portée initialement par Raydocs, vise à réutiliser un même format entre études, éditeurs et prestataires. Elle décrit le contenu du lot et les règles d’import, sans imposer un protocole de transport ni remplacer les contrôles du logiciel métier.

Le flux décrit va de l’émetteur vers le logiciel métier. Il couvre l’ouverture et la mise à jour des dossiers, les intervenants, titres, pièces, créances et actions métier. Il n’impose ni synchronisation bidirectionnelle ni production d’un document métier retour.

Structure du lot

Un lot cible une étude destinataire et un seul service. Il contient un fichier lot.json et, si nécessaire, les fichiers de pièces référencés par les dossiers.

flowchart TD
  LOT["Lot CDJ Connect"] --> ENT["En-tête : émetteur et destinataire"]
  LOT --> SVC["Service destinataire unique"]
  LOT --> DOS["Dossiers"]
  DOS --> REF["Références et événements"]
  DOS --> PER["Intervenants"]
  DOS --> TIT["Titres et pièces"]
  DOS --> FIN["Créances et intérêts"]
  DOS --> ACT["Actions et informations complémentaires"]

En-tête et service destinataire

• en_tete.id_lot identifie le lot, pas un dossier. date_lot est une date-heure ISO 8601.
• environnement vaut test, recette ou production ; sens_transmission vaut EMETTEUR_VERS_ERP et type_flux vaut IMPORT_DOSSIERS.
• emetteur identifie le prestataire, notamment par son code. destinataire identifie l’étude, le logiciel métier ou le tenant cible.
• service_destinataire.code est obligatoire et non vide. Sa nomenclature est convenue par projet dans le périmètre du destinataire ; ce n’est pas une enum globale. libelle est facultatif.
• Le logiciel métier peut mapper ce code vers son service interne ou l’utiliser pour filtrer l’import. Un lot ne mélange pas plusieurs services.
• Les clés internes d’un prestataire restent dans extensions_prestataire. Ce bloc est ignorable, ne contient aucune donnée nécessaire à l’import standard et ne sert jamais à créer, mettre à jour ou rapprocher un dossier.

Données du dossier

Chaque entrée de dossiers[] décrit un dossier et les actions demandées. Les données métier non nécessaires à l’action peuvent être omises.

Références et événements

Les références identifient le dossier ; les événements indiquent ce qu’il faut lui appliquer. nature_dossier décrit le domaine métier, sans remplacer l’événement ni le service de destination. Les règles de rapprochement sont regroupées dans Règles d’import ci-dessous.

Typage, références secondaires et contexte d’événement

• Les enums canoniques sont décrites dans les référentiels. AUTRE exige le libellé correspondant. Les codes externes complètent ces enums mais ne servent pas seuls à router le lot.
• references_externes[] utilise type_reference, valeur, et éventuellement source et usage_rapprochement. Ces références ne remplacent pas les deux références principales du dossier.
• Il n’existe pas d’identifiant métier propre à un prestataire dans le socle. Les créances et parties ont leurs propres références dans leurs objets respectifs.
• Un dossier peut porter plusieurs événements. Chacun exprime une action, avec une date d’effet ou un libellé lorsque pertinent.
• evenements[].renseignements[] décrit uniquement le contexte de l’événement concerné. Les informations générales du dossier restent dans dossiers[].renseignements[].

Intervenants

intervenants[] décrit les liens du dossier avec les personnes physiques ou morales. Le role est toujours obligatoire. La liste peut contenir plusieurs intervenants d’une même famille de rôle.

Personne physique (ipp). civilite, nom, prenom, puis, lorsqu’ils sont connus : date_naissance, lieu_naissance, nationalite, profession et date_deces. Le lieu de naissance réutilise l’objet adresse, notamment ville, code_postal et pays ; il n’est pas ajouté aux domiciles. Personne morale (ipm). raison_sociale, statut_juridique et identifiants légaux facultatifs : siret, siren, numero_rcs, greffe_rcs, numero_tva, numero_rna. Le Kbis est une pièce, pas un champ d’identité.

Création, réutilisation et mise à jour d’une partie

• Sans identifiant destinataire, fournir exactement un bloc ipp ou ipm. Si aucune référence client n’est fournie, le logiciel métier crée l’intervenant sans référence externe.
• Avec reference_intervenant_destinataire, le logiciel métier réutilise et lie la fiche existante. Une référence introuvable produit une anomalie ou un rejet, jamais une création silencieuse.
• Si les deux références sont fournies, elles doivent désigner la même personne. ipp et ipm ne sont jamais fournis ensemble.
• Les données jointes à un identifiant destinataire ne doivent pas écraser automatiquement la fiche maître.
• Les intervenants absents d’une mise à jour restent inchangés. Un intervenant du logiciel métier peut porter des rôles différents selon les dossiers ; les suffixes des rôles distinguent les occurrences si utile.
• Nationalité et profession sont des textes, sans nomenclature imposée. Ne pas déduire la nationalité du pays de naissance.
• Les dates sont exactes : ne pas transformer une année seule en date fictive. Les mentions partielles peuvent rester dans un renseignement adapté ou un complément convenu. date_deces ne clôture pas automatiquement le dossier.
• Les identifiants légaux et le RG utilisent leurs champs dédiés, pas renseignements[]. RCS et greffe sont renseignés ensemble lorsqu’ils sont connus.

Adresses, contacts et coordonnées bancaires

• Une adresse utilise ligne1, ligne2, ligne3, code_postal, ville, pays, avec type, label et principal facultatifs. Au moins une ligne, une ville, un code postal ou un pays doit être non vide ; aucune rue n’est obligatoire.
• Le pays au format ISO 3166-1 alpha-2 est recommandé, par exemple FR. Le type d’adresse est un code libre convenu par projet.
• Plusieurs adresses ou contacts sont possibles. TEL couvre les fixes et les mobiles.
• Un compte bancaire exige un iban ; bic, titulaire, domiciliation, reference_compte_bancaire et principal sont facultatifs. La référence de compte est recommandée pour les mises à jour.
• IBAN et BIC sont normalisés sans espaces et en majuscules ; le logiciel métier valide les coordonnées avant création ou mise à jour.
• Une seule adresse et un seul compte devraient être marqués principaux par intervenant pour chaque type d’objet. Les adresses et coordonnées bancaires ne sont jamais des clés de rapprochement dossier.

Titres et décisions

titres[] rattache au dossier des décisions ou autres titres, avec leurs dates connues et leurs documents. Sa présence ne certifie pas le caractère exécutoire et ne déclenche pas automatiquement un acte.

Les dates peuvent être connues dès l’ouverture informatique du dossier ou transmises ultérieurement. Chaque document pointe vers une pièce déclarée dans pieces_jointes[] du même dossier ; le fichier reste localisé par le chemin de cette pièce.

Qualification, dates et mise à jour d’un titre

• Le type décrit le document, pas une matrice locale ni une catégorie de procédure. Une simple requête n’est pas une ORDONNANCE_IP. Référé ou sur requête peut être précisé dans le libellé d’une ORDONNANCE.
• Une autre nature identifiée utilise AUTRE avec un libellé. Une nature inconnue est omise plutôt qu’inventée. Une référence documentaire non qualifiée peut utiliser reference_externe.type_reference=AUTRE ; elle ne remplace ni reference_titre ni le RG du dossier.
• Date de formule, date d’expédition, date de signification et date à laquelle l’exécution devient possible ne sont pas interchangeables. Ne pas qualifier une date à partir d’un cachet ambigu.
• Ne pas utiliser la date de signification à avocat pour une simple date d’envoi non qualifiée. Les deux champs de signification décrivent des faits distincts ; ils n’affirment pas que tous les destinataires ont été signifiés le même jour.
• Plusieurs faits distincts ne sont pas écrasés dans une seule date : le détail relève alors d’une convention d’intégration documentée. Ces dates sont des faits constatés, pas des échéances d’action.
• Sans usage, l’usage documentaire est non précisé, pas implicitement complet. Plusieurs documents sont possibles ; une mise à jour de titre peut ne joindre aucun nouveau PDF.
• OUVERTURE_DOSSIER peut inclure des titres. MISE_A_JOUR_DOSSIER permet leur ajout ou leur ciblage par référence ; les titres et champs absents restent inchangés. Un titre supplémentaire ne crée pas automatiquement une nouvelle créance.

Créances, montants et intérêts

elements_financiers[] contient les créances. Chaque élément exige une reference_element_financier stable ; nature_creance décrit sa nature globale et reste facultative mais recommandée.

Lignes de montant

montant_details[] décrit les postes, paiements et montants globaux.

Un montant global non ventilé n’est pas nécessairement le total du dossier. Il ne doit jamais être additionné automatiquement aux lignes susceptibles d’y être incluses. La totalisation nécessite une convention explicite ou une vérification métier.

Qualification des postes, états et agrégats

• Le libellé est libre et facultatif, sauf pour qualification_poste=autre. Il n’est pas une clé machine universelle.
• La qualification précise le poste sans remplacer le type large, la classe ou le code local de rubrique. Les montants sont des chaînes décimales avec . comme séparateur.
• Lorsqu’un état est présent, le poste est identifié par qualification_poste, ou la ligne par nature_ligne=agregat_non_ventile.
• rejete ne distingue pas, à lui seul, le rejet exprès d’un poste demandé mais non repris. Une simple absence non qualifiée ne suffit pas à l’inférer. Aucun état ne constitue un ordre de suppression d’écriture.
• Sans état, le comportement des lignes numériques ordinaires est conservé ; absence ne signifie ni rejet ni inconnue.
• Un agrégat n’a pas de qualification_poste. Son type, s’il est transmis, vaut autre. perimetre n’est autorisé que sur un agrégat explicite ; absent, il signifie non précisé. Ne pas inventer la portée du global.
• Le connecteur documente le ciblage des postes et le traitement des états lors d’une mise à jour. L’ordre du tableau ou le libellé n’est pas une clé universelle de remplacement.

Intérêts et mécanismes variables

interets[] décrit les intérêts, majorations ou pénalités variables associés à une créance.

La nature du mécanisme et son fondement sont distincts. Une période absente n’autorise pas à supposer un taux annuel ; une valeur inconnue ne doit pas être remplacée par zéro.

Cohérence du calcul

• taux est la valeur explicite du pourcentage, pas le résultat d’un calcul ni un coefficient.
• Lorsque le taux est transmis, préciser sa période si elle est connue. Sans période déterminée, ne pas calculer automatiquement.
• Les valeurs doivent être cohérentes avec le type et le mode de taux déclarés ; ces contrôles restent métier.
• periodicite et coefficient conservent le sens convenu pour le mécanisme ; aucune conversion implicite n’est autorisée.
• La nature du mécanisme peut être omise ; elle ne change alors pas la lecture des intérêts existants. Le socle ne définit ni sélection de familles d’assiette ni départ événementiel.

Pièces jointes

pieces_jointes[] déclare les fichiers du dossier. Un même mécanisme est utilisé pour les pièces générales, les documents de titre et les pièces référencées par les actes.

Les catégories exactes sont définies dans les référentiels. Les pièces EML utilisent message/rfc822 lorsque le type MIME est renseigné ; l’empreinte suit sha256:<hex>. Le fichier n’est jamais encodé en base64 dans le JSON.

Mesures, actes et agenda

L’événement demandé et le mapping du logiciel métier déterminent le traitement. Les codes AUTRE de mesure et d’acte exigent leur libellé correspondant ; un code externe complète le typage mais ne s’y substitue pas.

Renseignements et compléments

Dans les renseignements, type est la clé stable de mapping ; l’ordre du tableau n’a pas de sens. Un logiciel métier peut mapper un type vers un champ, une variable ou une note. Renseignements et compléments ne remplacent ni ne contredisent les champs canoniques.

Règles des informations complémentaires

• Les types de renseignements sont documentés dans les référentiels. Un type inconnu peut être ignoré sans bloquer l’import ; l’absence d’un renseignement ne supprime pas une valeur existante.
• Ne pas convertir automatiquement tous les renseignements en notes visibles : certains types sont structurants et doivent être mappés autrement.
• Les clés et le contenu de complements sont convenus entre émetteur et destinataire ; aucune structure interne ni enveloppe de version par entrée n’est imposée par le standard.
• Une donnée ciblant une entité utilise une référence stable, jamais son index dans un tableau. Selon le contexte : référence d’intervenant, de titre, de pièce, ou références de créance et d’intérêt.
• Si un complément est indispensable au traitement, le destinataire doit l’interpréter avant la mutation concernée ou signaler explicitement l’impossibilité de traitement. Il ne peut pas déclarer un succès complet en ignorant cette donnée.
• Si le complément est facultatif, la convention précise sa conservation ou son ignorance ; le format ne présume pas que le logiciel métier stocke du JSON libre.
• L’absence d’un complément n’efface rien. Son contenu représente des données, pas du code à exécuter.

Règles d’import

Retrouver le dossier et appliquer l’action

Le rapprochement reste limité au destinataire et au service du lot. Deux références sont utilisables : la référence métier externe reference_client et l’identifiant du logiciel métier reference_dossier_destinataire.

Ordre de recherche et mises à jour ciblées

1. Lire le code_evenement pour déterminer l’action attendue.
2. Si un identifiant du logiciel métier est fourni, chercher le dossier dans le destinataire et le service du lot.
3. Si aucun dossier n’est trouvé et qu’une référence client est fournie, chercher sa correspondance dans le même périmètre.
4. Lorsque les deux références sont fournies, elles doivent désigner le même dossier. Un identifiant appartenant à un autre service est rejeté.
5. Appliquer l’ouverture ou la mise à jour selon le résultat et l’événement. Une référence client n’est pas obligatoire si l’identifiant du logiciel métier suffit à une mise à jour. Les champs et collections absents restent inchangés. Les objets transmis sont ajoutés, rattachés ou ciblés par leurs références stables ; une suppression, un remplacement complet ou une annulation exige un événement explicite.

• AJOUT_PIECE rattache les pièces nouvelles sans doublon de reference_piece ; les pièces absentes restent en place.
• ACTE_A_SIGNIFIER cible reference_acte sans recréer un acte déjà connu.
• MISE_A_JOUR_CREANCE crée ou met à jour les éléments ciblés par reference_element_financier.
• Les règles de réutilisation des parties et de mise à jour des titres sont précisées avec ces objets ci-dessus.
• Le logiciel métier peut recevoir un lot rejoué ou de nouveaux lots visant le même dossier ; le traitement doit respecter les références stables et la politique de rejeu.

Valider et signaler les erreurs

Valider lot.json contre le JSON Schema correspondant à version_format, puis effectuer les contrôles métier et documentaires. La validation structurelle ne certifie pas que le connecteur sait appliquer toutes les données.

Un succès partiel est possible seulement si le logiciel métier trace précisément les objets appliqués et ceux rejetés. À défaut, il rejette le lot complet. Le rapport de traitement est recommandé ; son format et les codes d’erreur figurent dans les sous-pages de documentation.

Données absentes, fonctionnalités non prises en charge et rejets

• Un JSON Schema versionné est maintenu. Les codes canoniques sont ceux des référentiels ; un connecteur les mappe vers ses valeurs internes sans inventer des valeurs dans le flux.
• Les champs facultatifs peuvent être omis. Omission, null, faux et zéro ne sont pas interchangeables : les valeurs autorisées sont celles de la définition de chaque champ. Les dates typées n’acceptent pas une date approximative.
• Les champs inconnus non nécessaires au traitement peuvent être ignorés ; un projet peut choisir un mode de validation plus strict.
• Une donnée essentielle non prise en charge doit produire une anomalie explicite avant mutation. Reconnaître le numéro de version n’est pas une preuve de prise en charge de toutes ses fonctionnalités.
• Les événements non supportés sont mis en anomalie ou rejetés selon le mapping. Les logiciels métier conservent leurs contrôles métier et circuits de validation humaine.
• ZIP illisible, JSON absent ou invalide, schéma invalide, pièce obligatoire introuvable, chemin interdit ou erreur de sécurité sont des motifs de rejet bloquant.
• Le rapport de rejet est optionnel mais recommandé, en particulier pour tout traitement partiel. Un lot corrigé porte un nouvel en_tete.id_lot.
• Le format décrit un contrat de données ; les adaptations d’un connecteur et les évolutions du contrat sont documentées séparément dans le changelog et les conventions d’intégration.

Livraison du lot

Le fichier est une archive .zip avec lot.json à la racine. Les pièces sont facultatives ; leur arborescence interne n’a pas de sémantique métier obligatoire.

<nom_unique>.zip
  lot.json
  pieces/
    decision.pdf
    justificatif.pdf

Le nom du ZIP doit être unique dans le répertoire d’entrée, sans être interprété pour déterminer le contenu métier. Tous les chemins de pièces sont relatifs au ZIP ; chemins absolus et séquences ../ sont interdits. Les tailles maximales, le nombre de pièces et les contrôles de sécurité supplémentaires sont convenus par projet.

Convention de dépôt et classement côté logiciel métier

Le dépôt peut utiliser l’arborescence dédiée suivante, séparée des autres circuits EDI :

CDJCONNECT/
  IN/         lots à traiter
  EN_COURS/   traitement en cours, si utilisé
  ARCHIVE/    lots traités, y compris partiels tracés
  REJET/      lots rejetés

Le prestataire est identifié dans le JSON, pas dans le chemin. Les modalités de dépôt, de supervision, d’ordonnancement et d’archivage sont adaptables au projet ; cette arborescence est une convention recommandée, pas un protocole de transport imposé. Un succès complet classe le lot en archive ; un échec bloquant le classe en rejet. Un partiel autorisé est archivé avec une traçabilité de son résultat. Le destinataire peut rejeter un lot dépassant les limites ou contrôles de sécurité convenus.

Ressources

JSON Schema CDJ Connect v1.2Référentiels CDJ ConnectExemples CDJ ConnectChangelog et versions CDJ Connect