Le décret 2022-1299 du 7 octobre dernier indique que tout candidat PDP devra fournir dans sa documentation technique pour son dossier d’immatriculation (242nonies B, 7°, d) « des comptes-rendus de tests techniques établissant l’interopérabilité … en émission, réception et transmission avec le PPF ET une autre PDP … ». On pourrait croire que l’interopérabilité exigée par la réglementation est partielle entre PDP (exigence d’une seule relation au minimum) et complète avec le PPF, qui sera donc interopéré avec toutes les PDP.

Toutefois, l’article 242 nonies E créé par le même décret, relatif aux obligations des PDP, stipule au 4° que les PDP doivent « Assurer la transmission des factures électroniques aux plateformes de dématérialisation partenaires choisies par leurs destinataires ou au portail public de facturation, … »

On comprend ici que dans l’esprit du régulateur, les PDP sont interopérées. Facile à dire ! mais on n’y est pas.

En effet, le mode principal d’interopérabilité actuel est bilatéral, c’est-à-dire qu’une plateforme en position d’émettre établit un lien d’échange interopéré de factures électroniques avec une plateforme en position de réception, au mieux pour l’ensemble de leurs échanges interopérés, et assez souvent pour chaque lien émetteur / destinataire finaux (ce qui veut dire du travail de set up de part et d‘autre à chaque fois qu’un émetteur d’une plateforme veut transmettre des factures au destinataire de l’autre en interopérabilité). De plus, les messages de retours de statuts sont très peu interopérés, si bien que c’est souvent la plateforme du destinataire qui au mieux permet à l’émetteur des factures de venir consulter son cycle de vie sur le portail de l’acheteur ou de sa plateforme.

S’il fallait reposer sur ce seul mode d’interopérabilité bilatéral, on comprend assez vite la difficulté pour atteindre une connectivité à 100% entre PDP. Il faudrait qu’il y ait autant de connexions interopérées que de couples de PDP a minima. Pour rappeler les souvenirs de lycée, ceci donne pour « n » PDP n*(n-1)/2 couples, soit pour 10 PDP, 45 couples, pour 50 PDP 1 225 couples et 49 connexions à travailler pour chaque PDP. Et il faut aussi les maintenir, discuter des éventuels formats divers plus ou moins propriétaires à échanger, gérer les problèmes de production … Intenable.

Donc, il faudrait se contenter d’une interopérabilité partielle entre PDP. Quelle conséquence sur l’initialisation de la réforme ? Assez peu sur le choix d’une PDP destinataire, puisque la réglementation va imposer aux entreprises de pouvoir transmettre des factures électroniques et qu’au pire (ou au mieux), le PPF pourra être utilisé pour les émettre. Par contre, c’est une autre histoire pour choisir une PDP en émission. 

Mettons-nous en effet à la place d’une entreprise qui est soumise à l’obligation d’émettre. Elle a le choix entre une PDP, qui ne peut pas lui garantir d’être connectée à toutes les autres, donc à atteindre tous les destinataires, et le PPF qui est connecté à toutes les PDP. Ceci veut dire au mieux que l’entreprise doit ouvrir un compte sur le PPF pour pouvoir émettre toutes ses factures si sa ou ses PDP ne sont pas interopérées avec la PDP de certains de ses clients.
Si son prestataire PDP dispose aussi d’une offre en tant qu’OD directement connecté au PPF, et si cette entreprise a préalablement habilité sur le PPF son prestataire en tant qu’OD pour émettre des factures sur le PPF pour son compte, elle pourra alors disposer d’un canal d’émission par défaut via le PPF. Vous me suivez là ? Pas simple, non ?

En plus, l’entreprise pourrait se demander pourquoi ne pas utiliser le plus souvent le canal PPF, car accessoirement, il est gratuit, archivage compris, ce qui devrait bien se traduire sur le coût d’émission des factures. Et finalement l’entreprise pourrait être tentée d’utiliser son prestataire en tant que PDP uniquement quand le canal PPF n’est pas opérant, c’est-à-dire pour des flux existants qu’il ne faut pas perturber ou migrer, des flux où il est nécessaire d’utiliser des formats tiers et des flux de factures qui n’entrent pas dans le cadre de la réforme.

Bref, un modèle en Y marginal, 4 millions de comptes ouverts sur le PPF en émission, avec autant d‘utilisateurs. Dommage !

Si on prend encore un peu plus de recul en se mettant à la place d’un régulateur qui souhaite mettre en œuvre une obligation de facture électronique avec contrôle transactionnel continu, et qui souhaite s’appuyer sur un modèle décentralisé en Y parce qu’il a compris qu’il fallait se reposer sur l’existant et l’écosystème, et permettre au marché de continuer à innover sur l’optimisation des chaines d’approvisionnement, de la commande (voire des prévisions) au règlement, pour accélérer les traitements et les paiements, y compris avec des offres de refinancement, et ainsi dégager des ressources pour les entreprises pour investir plutôt que de les affecter à du BFR . 

Or, s’il ne préexiste pas une infrastructure d’échange de factures et statuts en réseau, interopérée, permettant l’entrée d’une nouvelle plateforme à un coût marginal non proportionnel au nombre de plateformes, il ne peut y avoir de garantie que l’écosystème sera en capacité de répondre à l’obligation d’émettre 100% des factures en électronique, du seul fait d’une interopérabilité et donc connectivité partielles. La conséquence immédiate est la nécessité de créer une plateforme « par défaut », qui est connectée à toutes les autres : une Plateforme Nationale, en France le PPF.

Et je ne parle pas même pas de la nécessité de proposer une solution pour les TPE et PME à qui il va être imposé de basculer en facture électronique…

Par conséquent, il est aussi de la responsabilité des prestataires de services qui revendiquent leur rôle et leur valeur ajoutée dans l’automatisation des processus d’achat / vente, de s’organiser pour mettre en œuvre une interopérabilité native entre eux, compatible avec les exigences des États, qui, de plus en plus nombreux, mettent en œuvre des obligations de facture électronique dans un cadre de CTC (contrôle Transactionnel Continu).

Le modèle DCTCE, pour « Decentralised CTC Exchange », a posé des principes d’interopérabilité en réseau « n-coins », en intégrant la façon de répondre aux exigences CTC. Ceci repose sur un protocole d’échange ouvert permettant une découverte dynamique de la plateforme du destinataire (CEF e-delivery, implémenté par PEPPOL (Pan EuropeanPublic Procurement On Line), EIN de EESPA (European E-invoicing Service Provider Association), BPC (Business Payments Coalition), et dans le respect des recommandations du GIF : Global Interoperability Framework).

Toutefois, ce modèle, récent, reste théorique et doit passer à la phase pratique pour réellement démontrer sa capacité à adresser à la fois les besoins des entreprises sur la gestion de tous les cas d’usage qu’elles pratiquent, et une plus grande automatisation des traitements.

C’est pourquoi les équipes de PEPPOL et de l’EESPA se sont rapprochées pour travailler sur le modèle DCTCE et sur la mise en œuvre d’un POC DCTCE (Proof of Concept) pour la France, premier pays européen à avoir choisi un modèle en Y, décentralisé. Le FNFE-MPE va participer à ce POC qui a vocation à démontrer la faisabilité dans le contexte français et à montrer qu’il est possible d’organiser une interopérabilité native entre PDP, permettant d’offrir au marché une liberté de choix de PDP ou du PPF, tant en émission qu’en réception, et ce avant l’été 2023 pour ne pas arriver après la bataille.

Ceci va nécessiter quelques adaptations du modèle pour passer du concept à la faisabilité sur un pays de près de 4 millions d’entreprises adressant à la fois la facture électronique domestique B2B entre assujettis à la TVA, mais aussi le e-reporting TVA sur tout le reste (B2C, international, encaissement), une gestion du cycle de vie des factures et une liste conséquente de cas d’usage bien réels.

Vaste sujet, clé pour la réussite du modèle en Y, où il sera probablement nécessaire que les services de l’État s’impliquent aussi, par cohérence avec les textes et la volonté de s’appuyer sur l’écosystème pour déployer la facture électronique en France. 

Il sera aussi nécessaire que les prestataires de services, candidats PDP, et les promoteurs du modèle DCTCE, qui a aussi vocation à servir de référence a minima en Union Européenne, prennent conscience de l’urgence à passer du concept à sa mise en œuvre pratique et opérationnelle. Et c’est maintenant que ça se passe.

Il en va aussi de même pour les travaux d’alignement des pratiques CTC en Europe sur lesquels la Commission Européenne travaille.

#dctce #fnfempe #einvoicing #ereporting #en16931 #eespa #gif #peppol #interoperability #cefedelivery #emsfei #ferd #facturx