1. Introduction et champ d’application
L’article 3, point 9), du règlement (UE) 2022/850 relatif à un système informatisé pour l’échange électronique transfrontière de données dans le domaine de la coopération judiciaire en matière civile et pénale (système e-CODEX) définit la «norme de procédure numérique» comme les spécifications techniques relatives aux modèles de processus opérationnel et aux schémas de données qui énoncent la structure électronique des données échangées par l’intermédiaire des points d’accès e-CODEX. Le modèle de processus opérationnel est élaboré, maintenu et mis à jour en appliquant le Business Process Model and Notation (BPMN) ou d’autres normes sectorielles pour la modélisation des processus opérationnels.
Les schémas de données permettent des échanges de données interopérables par l’intermédiaire de-CODEX.
Par conséquent, aux fins de la numérisation du règlement (CE) no 1896/2006, la présente annexe définit les spécifications techniques pour:
a) les modèles de processus opérationnel;
b) les schémas de données.
2. Spécifications techniques relatives aux modèles de processus opérationnel au titre du règlement (CE) no 1896/2006
Les spécifications techniques relatives aux modèles de processus opérationnel sont considérées comme des spécifications minimales et définissent les principaux aspects nécessaires pour permettre la communication électronique aux fins du règlement (CE) no 1896/2006 par l’intermédiaire du système informatique décentralisé, et couvrent à la fois les situations de communication transfrontière et, lorsque les États membres choisissent d’utiliser le système informatique décentralisé à cette fin, les communications entre acteurs nationaux (par exemple, en cas de transmission à une autre juridiction ou autorité compétente).
Elles doivent être comme suit:
Demande de procédure européenne d’injonction de payer
— Introduction d’une demande — Le demandeur envoie le formulaire A à la juridiction.
— Demande de la juridiction, adressée au demandeur, de compléter et/ou de rectifier le formulaire de demande — La juridiction envoie le formulaire B au demandeur.
— Proposition, adressée au demandeur, de modification de la demande d’injonction de payer européenne — La juridiction envoie le formulaire C au demandeur.
— La juridiction rejette la demande — La juridiction envoie le formulaire D au demandeur.
— Le demandeur retire sa demande — Le demandeur informe la juridiction que la demande est retirée.
— Paiements — Les parties et la juridiction communiquent au sujet du paiement des frais.
— Transmission à la juridiction compétente — La juridiction transmet la requête à la juridiction compétente.
Traitement de la procédure européenne d’injonction de payer
— Prorogation d’un délai — Le demandeur et/ou le défendeur demandent la prorogation d’un délai fixé par la juridiction et la juridiction communique sa décision concernant cette demande.
— La juridiction délivre et notifie l’injonction de payer européenne au défendeur — La juridiction délivre et notifie l’injonction de payer européenne (formulaire E) au défendeur.
— Le défendeur s’oppose à l’injonction de payer européenne — Le défendeur soumet à la juridiction une déclaration d’opposition à l’injonction de payer européenne (formulaire F).
Après l’injonction de payer européenne
— La juridiction envoie au demandeur la déclaration constatant la force exécutoire de l’injonction de payer européenne — La juridiction envoie au demandeur la déclaration constatant la force exécutoire (formulaire G).
— Recours — Si le droit national le permet, le demandeur ou le défendeur peut former un recours.
— Réexamen — Le défendeur demande un réexamen dans des cas exceptionnels.
3. Spécifications techniques relatives aux schémas de données
Les points suivants exposent les dispositions relatives aux spécifications techniques qui serviront de base à l’élaboration des définitions des schémas XML (XSD). Ces spécifications définissent les éléments clés et toute autre information utile afin de fournir une description complète pour les besoins de la création desdits schémas.
La description se veut générique afin que les XSD créés puissent être modifiés et étendus sans qu’il soit nécessaire d’apporter des modifications à ces spécifications.
Ces spécifications s’appliquent aux formulaires réglementaires, aux messages prédéfinis ou aux messages à contenu libre utilisés dans les échanges effectués au titre du règlement (CE) no 1896/2006.
3. 1. Généralités
Pour tous les schémas à fournir, les dispositions suivantes s’appliquent:
Versions
Un attribut de version doit être inclus pour faciliter la gestion des versions de schéma. Cela permettra de mettre à jour le schéma dans les versions ultérieures conformément aux exigences opérationnelles, en indiquant si la nouvelle version est rétrocompatible lors de l’introduction de nouvelles fonctionnalités ou d’améliorations.
Déclaration de schéma et métadonnées
Le cas échéant, le schéma utilise les normes ou vocabulaires pertinents, appliqués par e-CODEX pour garantir l’interopérabilité, qui sont nécessaires à la validation correcte des éléments et types définis dans le schéma en question. Ces normes ou vocabulaires peuvent inclure:
— le vocabulaire de base e-Justice de l’Union,
— des types de données non qualifiés,
— une liste de codes pour les codes linguistiques de l’Union européenne.
En outre, le cas échéant, le schéma peut intégrer des normes ETSI pertinentes pour utiliser leurs définitions.
Annotations et documentation
Annotations: chaque élément du schéma est généralement accompagné d’annotations. Elles fournissent des informations lisibles par l’homme au sujet de l’élément, en définissant souvent la finalité ou l’utilisation de celui-ci de manière claire et concise.
Utilisation et adaptabilité
Structure modulaire: chaque section est conçue pour remplir une fonctionnalité spécifique et peut être réutilisée ou adaptée de manière indépendante. Cela facilite l’adaptation du schéma à des cas d’utilisation divers.
Extensibilité: le schéma est conçu de manière à prendre en charge l’incorporation d’éléments ou d’attributs nouveaux si des informations complémentaires s’avèrent nécessaires par la suite. Ce résultat est obtenu à l’aide d’éléments et de séquences facultatifs, pouvant être complétés sans casser les implémentations existantes.
Structure adaptable: le schéma est conçu de manière à permettre l’ajout ou la modification d’éléments ou de types de données, selon les besoins. La structure du formulaire peut s’adapter aux changements dans les exigences sans nécessiter de remaniements majeurs.
Éléments facultatifs: des éléments d’un formulaire peuvent être désignés comme facultatifs, ce qui signifie qu’ils peuvent être inclus ou omis selon les circonstances particulières.
Le schéma est conçu de manière à prendre en charge la collecte de données structurées pour répondre à des demandes spécifiques.
Modifications
La conception du schéma se caractérise par sa flexibilité, sa modularité et sa facilité d’adaptation. L’utilisation de types complexes et d’éléments facultatifs garantit qu’il permet de gérer des scénarios divers tout en restant facile à modifier et à compléter.
3. 2. Formulaires réglementaires
Les spécifications techniques relatives aux schémas de données définissent un cadre structuré pour la représentation des formulaires, tels qu’établis par le règlement (CE) no 1896/2006, au format XML.
3. 3. Messages prédéfinis
Les messages prédéfinis sont des représentations d’échanges qui sont institués par le règlement, mais pour lesquels l’acte juridique ne prévoit aucune forme particulière. Leurs types et leur nombre seront déterminés lors de l’analyse opérationnelle et technique.
Leurs schémas sont conçus de manière à définir une structure de définitions des schémas XML (XSD) garantissant la cohérence, la structure et la conformité avec les besoins opérationnels.
Les grandes lignes des principaux éléments de ces schémas sont les suivantes:
— la section de premier niveau du schéma est nommée d’après le type de message spécifique qui est défini,
— les champs obligatoires pour le type de message spécifique sont ajoutés et définis à l’intérieur de cette structure, de manière à garantir une représentation adéquate des éléments de données.
3. 4. Messages à contenu libre
Les messages à contenu libre sont des représentations d’échanges permettant l’insertion de contenus non structurés ou partiellement structurés, conciliant une certaine souplesse avec le respect des exigences réglementaires et opérationnelles. Ce schéma est conçu de manière à définir la structure des définitions des schémas XML (XSD) pour ces messages, en garantissant la cohérence et le formatage adéquat.
Les grandes lignes des principaux éléments de ces schémas sont les suivantes:
— la section de premier niveau de ce schéma est nommée d’après le type de message à contenu libre spécifique qui est défini,
— le schéma définit la structure nécessaire au message à contenu libre tout en permettant un ordonnancement adéquat des éléments, en fonction des besoins,
— les champs obligatoires pour le type de message à contenu libre spécifique seront ajoutés et définis à l’intérieur de cette structure, de manière à garantir une représentation adéquate des éléments de données.