Pourquoi faut-il une autorité PEPPOL en France ?

Alors que la décision de créer une autorité PEPPOL est en cours d’instruction par la DGFiP, il est bon de rappeler à quoi sert et quels sont les avantages d’une autorité PEPPOL. TACD CARTENA se penche sur cette question alors que notre responsabilité dans le développement de PEPPOL en France nous conduisait déjà, il y a dix ans, à soutenir cette idée.

Créer une autorité PEPPOL en France n’est pas nouveau. La France fût même quelques temps autorité PEPPOL en 2012 sous l’égide de l’ADETEF[1]. En tant que chefs de projet PEPPOL, convaincus que créer une autorité permettrait de conserver la maîtrise du réseau, nous avons œuvré, mon collègue Nicolas Botton et moi, avec l’AIFE à l’interconnexion PEPPOL du portail public qui n’était pas encore, à l’époque, CHORUS PRO.

Une autorité PEPPOL peut imposer certaines exigences au sein d’un réseau ou s’exerce son autorité. Ces règles PASR[2] s’appliquent alors en premier lieu aux opérateurs de services qui opèrent au sein de ce réseau comme à leurs clients destinataires ou émetteurs de factures mais aussi aux opérateurs extérieurs dès qu’ils veulent échanger avec ce réseau. Juridiquement, cela revient à publier des dispositions et les rendre opposables à l’ensemble de la communauté.

Techniquement, une autorité PEPPOL est tenue de respecter le standard et la norme de facturation. Elle utilisera alors ce canal pour publier ses exigences,  une spécification d’usage CIUS [3] restriction ou bien, à l’inverse, une extension de la norme [4]. A l’aide du service de métadonnée SMP/SML du réseau PEPPOL de propager instantanément ces exigences à l’ensemble du réseau  global et aux SMP des opérateurs de services qui devront s’y conformer s’ils veulent s’interopérer avec les destinataires situés dans cette juridiction.

Plus précisément les PASR permettent de définir :

  1. les règles applicables en matière d’identifiants ou de schéma d’identification
  2. les exigences de sécurité
  3. le partage éventuel d’informations ou de données avec l’autorité
  4. l’utilisation obligatoire de services centralisés
  5. Les exigences de niveau de service
  6. Les spécifications locales d’interopérabilité
  7. L’accréditation éventuelle des opérateurs de services

 

C’est ainsi que l’autorité allemande KoSIT[5] rend obligatoire un identifiant de routage « Leitweg ID » pour l’acheminement des factures à ses administrations ; En Belgique, le participant doit être identifié dans l’annuaire avec son numéro de la Banque Carrefour des Entreprises [6]. Le ministère néerlandais de l’intérieur impose aux opérateurs de services qu’ils soient certifiés ISO 27001 ou à défaut, fournissent un rapport d’audit d’une autorité indépendante. L’autorité australienne demande aux opérateurs de services qu’ils rendent compte des participants et de leurs transactions par type de document. L’autorité italienne AGiD définit pour sa part, la méthode de routage via un SMP[7] central intégré au registre national iPA [8]. Elle prévoit aussi des spécifications locales d’interopérabilité des messages commande, réponse commande et avis d’expédition etc…

 

Une autorité PEPPOL française est donc souhaitable à la bonne gouvernance d’un réseau qui devra jongler entre plateforme de dématérialisation partenaire, PEPPOL ou non. L’expérimentation en cours DCTCE « Decentralised CTC Exchange » [9] visant à rendre interopérables les plateformes partenaires PDP grâce à PEPPOL, nous rappelle l’importance d’un maître du jeu. Etre autorité,  permet d’édicter des exigences de conformité, de faire évoluer ces règles au fil du temps si nécessaire et de les rendre opposables en les propageant automatiquement à l’ensemble du réseau grâce au système SMP/SML. Finalement, comme l’indique l’agence italienne AGiD dans ses PASR, le SMP National permet à l’Autorité PEPPOL de mieux gérer les acteurs au sein du réseau avec un meilleur contrôle et une visibilité accrue sur les transactions.

[1] ADETEF l’ex agence de développement du ministère des finances fût intégrée à Expertise France en 2015

[2] PASR “Peppol Authority Specific Requirement” peuvent être consultés  ici

[3] CIUS “Core Invoice Usage Specification”

[4] EN 16931

[5] KoSIT (Koordierungstelle für IT-standarts)

[6] PEPPOL ICD code list : 0208   https://docs.peppol.eu/poacc/billing/3.0/codelist/ICD/

[7] PEPPOL SMP permet l’interconnexion quatre coins  des opérateurs en fournissant un service de métadonnées

[8] indice PA https://www.agid.gov.it/it/dati/basi-dati-interesse-nazionale/indice-pa

[9] DCTCE « Decentralised CTC Exchange »