E-invoicing : Et si on allait plus loin que la facture électronique ?

La réforme visant à généraliser la facture électronique en France porte une ambition claire : digitaliser, moderniser, automatiser et optimiser les relations interentreprises. En ce sens, la facture occupe une place centrale. Elle représente la synthèse d’une transaction : un document pivot, qui cristallise toutes les étapes du processus d’achat, depuis parfois l’appel d’offres jusqu’à la livraison.

Mais la facture n’est que la partie émergée de l’iceberg. D’autres documents jalonnent les relations interentreprises : contrats, plannings d’approvisionnement (purchase schedules), bons de commande, avis de livraison, avis de réception, ainsi que des éléments plus transverses comme les référentiels tiers (clients, fournisseurs).

Dès lors, une question se pose : comment aller au-delà de la simple facture électronique pour digitaliser l’ensemble des processus interentreprises ?

1. Les limites du modèle de flux de la facture électronique

La facture électronique repose sur un modèle de flux : le document est émis par le système du fournisseur, puis transmis au système du client via des plateformes intermédiaires (PDP ou PPF). Ce dispositif, bien que puissant, est complexe, rigide, et coûteux à généraliser.

La mise en œuvre nationale de l’e-invoicing en France a nécessité près de cinq ans de préparation, et trois reports successifs. Répliquer cet effort pour chaque type de document interentreprise — commande, contrat, avis de réception… — serait totalement irréaliste.

De plus, seule la facture est universelle : toutes les entreprises, quels que soient leur secteur (industrie, services, secteur public…), émettent ou reçoivent des factures. Ce n’est pas le cas des autres documents : un purchase schedule est typique de l’aéronautique ou de l’automobile, une situation de travaux est propre au BTP.

Il faut donc envisager un autre modèle pour digitaliser ces documents.

2. Le modèle de stock : une alternative scalable

À l’inverse du modèle de flux, le modèle de stock repose sur une approche centralisée côté émetteur : les documents sont stockés dans un système auquel les destinataires peuvent accéder via un mécanisme d’authentification sécurisé. Il n’y a pas de flux documentaire à proprement parler.

Cette approche supprime les contraintes d’interopérabilité, de latence ou de volumétrie, et permet une mise en œuvre plus simple, plus rapide, et plus souple, notamment pour les documents non normés ou spécifiques à certains métiers.

3. L’enjeu de l’authentification dans le modèle de stock

Pour garantir la sécurité de ce modèle, il est essentiel que chaque utilisateur puisse accéder uniquement aux documents qui lui sont destinés, sans que cela ne crée une charge technique excessive pour l’émetteur.

Une solution réaliste consisterait à s’appuyer sur les SIREN_XX de l’annuaire et sur les utilisateurs liés aux SIREN_XX gérés dans les PDP : chaque document serait assigné à un SIRET, et l’accès serait géré via un système d’authentification universel.

Par exemple, si une entreprise souhaite partager un document avec un fournisseur, elle pourrait reconnaître l'identité de ce fournisseur via sa PDP, sans devoir gérer elle-même les comptes utilisateurs.

4. OAuth2 : l’outil clé d’un accès sécurisé et universel

Le protocole OAuth2 est aujourd’hui le standard de l’authentification sécurisée sur le web. Il peut fonctionner selon deux modes :

• "Two-legged OAuth" : un système à deux acteurs, basé sur l’échange d’un jeton (bearer token), sans interaction manuelle. C’est le modèle actuellement en vigueur dans le e-invoicing.

• "Three-legged OAuth" : un système à trois acteurs (utilisateur, client, fournisseur d’identité), impliquant une authentification manuelle par l’utilisateur. C’est ce modèle qui rend possible l’accès sécurisé à des ressources à la demande, comme dans un modèle de stock.

Si chaque PDP adoptait un OAuth2 en mode “three-legged”, il deviendrait possible de bâtir un écosystème d’applications interentreprises sécurisées, capables de s’intégrer simplement aux PDP et d’utiliser leur mécanisme d’identification.

5. L’état actuel des spécifications API et perspectives d’évolution

La spécification Z12-013 définit l’architecture API harmonisée pour l’e-invoicing. Elle encourage l’usage d’un cadre commun, notamment en matière d’authentification.

Mais elle ne prévoit actuellement que l’usage d’OAuth2 en mode “two-legged”, limitant les interactions au seul modèle de flux. Cela freine la mise en œuvre d’outils plus avancés de gestion documentaire.

Espérons que les futures versions de cette norme ouvrent la voie à un deuxième type de connexion, en “three-legged”, pour permettre le développement d’applications s’appuyant sur un modèle de stock sécurisé. Cela constituerait le socle technique nécessaire pour digitaliser à grande échelle l’ensemble des processus interentreprises, et faire passer l’économie française dans une nouvelle ère de dématérialisation.