Comment instruire les exigences spécifiques d’une autorité PEPPOL, et selon quelle procédure s’imposent-elles une fois approuvées par OpenPEPPOL ?
TACD CARTENA se penche sur cette demande et ses conséquences dans le cadre des tous derniers développements d’OpenPEPPOL et des évolutions récentes du réseau.
L’extension mondiale de PEPPOL justifie le choix d’OpenPEPPOL de déléguer la régulation locale de son réseau à d’autres autorités que la sienne. OpenPEPPOL reconnaît ainsi à ces autorités, le droit d’édicter certaines exigences valables dans les limites de leur propre juridiction. Ces exigences peuvent être liées à un contexte particulier ou à certaines règles fixées par l’autorité elle-même. Elles sont de nature légales, fiscales ou déterminées par la volonté de mieux gérer l’e-Procurement. Un exemple, celles de l’autorité italienne portant sur la notification des bons de commandes électroniques via le système NSO et le dépôt des factures dans le portail national SDI .
Pratiquement, pour cette demande de changement, un RFC[1] doit être initié sous la forme d’un document PASR[2] adressé au service desk OpenPEPPOL. Ce document porte sur les points suivants :
- Identifiant ou schéma d’identification applicable
- Sécurité système d’information (par exemple, certification ISO 27001)
- Obligation de rapport statistique sur les utilisateurs connectés et les transactions
- Utilisation obligatoire de services centralisés et de spécifications globales
- Exigences de niveaux de services
- Utilisation des spécifications locales d’interopérabilité
- Accréditation des opérateurs de services (par exemple, en tant que PDP)
Vous trouverez ici les PASR de 17 autorités PEPPOL parmi lesquelles, Australie, Belgique, Allemagne etc..
Cette demande doit être approuvée par OpenPEPPOL avant d’être publiée et applicable à l’ensemble du réseau. En effet, un sous-réseau ne peut s’envisager isolé, mais comme un sous-ensemble du réseau général. Le risque est que ce changement contrarie les mécanismes d’interopérabilité entre les opérateurs. C’est pourquoi, toute demande notifiée donnera lieu à une première analyse afin de vérifier que ces modifications n’affectent pas le fonctionnement du réseau en général. Si certains écarts sont détectés, l’équipe technique constituée d’experts OpenPEPPOL (l’APP CMB)[3] va ensuite aider l’autorité à résoudre les problèmes identifiés. Si nécessaire, elle organisera une rencontre avec l’autorité avant d’engager son analyse de conformité, puis procédera à l’évaluation des conflits éventuels avec la politique générale ou affectant la responsabilité de PEPPOL, en veillant en premier lieu à préserver, l’intégrité du réseau, la sécurité et l’interopérabilité.
L’autorité peut toujours décider de passer outre cette décision sans attendre la position définitive de l’équipe de conformité. C’est pourquoi avec le développement du e-Reporting qui comporte souvent ses propres règles (même si le DRR[4] européen et ViDA prônent la convergence), OpenPEPPOL penche de plus en plus pour la création d’un environnement multi-domaines au sein desquels les autorités seront libres de gérer leurs annuaires et d’édicter leurs propres règles pour autant que celles-ci n’enfreignent pas celles de PEPPOL. Prenons l’exemple de la France : l’autorité PEPPOL pourrait demain créer un espace unique constitué du réseau des PDP, véritable sous-ensemble du réseau PEPPOL mais au sein duquel seules les opérateurs accrédités (immatriculés) peuvent interagir. Les autres ne pourront atteindre un destinataire que par l’intermédiation d’une PDP.
Cette disposition obligatoire pour les entités fiscalement assujetties, ne s’impose aux non assujettis que dans la limite d’utilisation obligatoire de services centralisés (portail national) ou de spécifications générales. Elle devrait aussi conduire l’autorité à considérer les coûts induits par ces dispositions et les impacts techniques pour les opérateurs de services qui doivent gérer plusieurs environnements.
A l’issue de la procédure, OpenPEPPOL soumettra la décision d’une autorité aux autres autorités afin de leur permettre de commenter cette décision ou d’émettre d’éventuelles réserves, si ces dispositions venaient à affecter leur fonctionnement interne ou contraindre leurs propres assujettis. Par exemple, exiger un identifiant ou un préenregistrement dans un registre national particulier pour des opérateurs non assujettis pourrait constituer une entrave pour l’autorité concernée.
On voit bien les limites de cette stratégie, d’un côté OpenPEPPOL se doit d’ouvrir la porte à un certain niveau de customisation indispensable à l’adoption de PEPPOL dans le Monde, d’un autre ne pas se montrer trop souple au risque de tordre le bras aux principes d’un quasi standard unique et universel. Lors de la dernière AG d’OpenPEPPOL, Elly Stinchcombe, représentante de l’ATO australienne et Community leader des Autorités PEPPOL au sein d’OpenPEPPOL a déclaré que les efforts en 2024 devront porter sur la révision des conditions d’application des règles spécifiques à chaque pays.
[1] RFC, Request For Change
[2] PASR, Peppol Authority Specific Requirement
[3] APP CMB- Agreements, Policies and Procedures Change Management Board
[4] DRR, Digital Reporting Requirement (ViDA « VAT in Digital Age)