Peppol pour les développeurs : Rationalisation des transactions B2B ou nouveau fardeau informatique ?

Peppol gagne incontestablement du terrain dans le monde de la messagerie d'entreprise. Les entreprises et les gouvernements sont de plus en plus nombreux à migrer la messagerie commerciale - factures, E-commandes, et autres flux de transactions - des anciennes technologies vers cette nouvelle norme ouverte.

De nombreux articles donnent une vue d'ensemble des principes de base de Peppol, nous n'en parlerons donc pas ici. Pour un résumé de son historique, consultez ce billet sur l'histoire de Peppol. Je vais plutôt approfondir ses caractéristiques, ses capacités techniques et son infrastructure du point de vue d'un développeur et expliquer pourquoi il est devenu un nouveau paradigme dans le B2B.

Dans le domaine des technologies de l'information, le terme "business-to-business" (B2B) désigne l'échange électronique de messages commerciaux entre entreprises. La communication électronique interentreprises existe depuis longtemps et a été l'un des facteurs déterminants dans le développement d'un réseau mondial stable et sûr - ce que nous connaissons aujourd'hui sous le nom d'internet.

Dans le domaine des technologies de l'information, le terme "business-to-business" (B2B) désigne l'échange électronique de messages commerciaux entre entreprises. La communication électronique interentreprises existe depuis longtemps et a été l'un des facteurs déterminants dans le développement d'un réseau mondial stable et sûr - ce que nous connaissons aujourd'hui sous le nom d'internet.

La raison en est simple. Les entreprises ont compris qu'avec l'introduction des ordinateurs, elles devaient partager des données pour exploiter pleinement leur potentiel. C'est de ce besoin qu'est né le B2B.

Lorsque le B2B a débuté à la fin des années 70, il n'y avait pas de réseaux entre les entreprises et les données (stockage) étaient incroyablement chères, de sorte que tout le monde faisait de son mieux pour minimiser les modèles de données.

Dès le début, deux formats principaux ont vu le jour : ANSI X12 (1979) aux États-Unis et EDIFACT (1984) en Europe. Ces deux formats étaient destinés à servir de norme aux entreprises et à enregistrer les données de la manière la plus comprimée possible.

Des décennies plus tard, ces formats sont toujours largement utilisés dans le monde entier. X12 est peu répandu en dehors des États-Unis, mais EDIFACT est largement répandu.

EDIFACT est également à la base de l'UBL, l'élément constitutif du XML de Peppol.

Le B2B est utilisé par presque toutes les entreprises aujourd'hui, car tout le monde a besoin de communiquer numériquement pour faire des affaires.

Au fur et à mesure que le B2B s'est répandu, en particulier à partir du milieu des années 90 avec l'essor de l'internet, de nombreuses entreprises ont commencé à établir des connexions "point à point" (P2P) avec leurs partenaires commerciaux, car il n'y avait pas d'autres solutions pour partager leurs données B2B.

Quelque temps plus tard, les premiers services de réseaux à valeur ajoutée (VAN) ont été développés pour atténuer les problèmes de croissance des connexions P2P. Les entreprises pouvaient se connecter à un fournisseur de services VAN qui, à son tour, se connectait à tous les autres collaborateurs, formant ainsi un réseau d'opérateurs B2B. Ces fournisseurs de services sont communément appelés opérateurs (OP).

De plus en plus d'OP ont été créés - certains locaux, pour une région ou un pays spécifique, et d'autres avec une portée mondiale. Le nombre de connexions B2B a augmenté rapidement et, dans le même temps, de plus en plus de systèmes ont été introduits sur le marché.

Il en est résulté une explosion des types et des formats de messages, les systèmes d'appui ne disposant pas de normes communes.

Les fournisseurs de services B2B se sont rapidement rendu compte qu'ils avaient besoin de transformations (conversions de formats de données entre les systèmes des clients et leurs partenaires commerciaux), ce qui a conduit au développement d'autres solutions, de logiciels de transformation pour les entreprises et de services de transformation proposés par les fournisseurs VAN .

Comme vous pouvez probablement l'imaginer, cela a causé un désordre dans le trafic B2B. Cependant, pour les opérateurs de VAN , cette configuration était très rentable ; ils pouvaient facturer à la fois l'expéditeur et le destinataire, et pour couronner le tout, ils pouvaient facturer des frais supplémentaires pour les transformations !

Bien sûr, "effondrement" est peut-être une façon radicale de présenter les choses. Néanmoins, alors que le nombre de formats augmentait sans coordination centrale, que l'internet se répandait rapidement et que les prix de stockage et de transfert des données ne cessaient de baisser, le point de rupture était imminent.

Les opérateurs de VAN étaient cependant satisfaits. Tout participant à un réseau d'opérateurs était étroitement coincé et n'avait d'autre choix que de continuer à payer les factures des fournisseurs de VAN pour poursuivre ses activités.

Lorsque les coûts sont devenus douloureusement élevés, les entreprises ont commencé à chercher à ramener la fonctionnalité B2B à la maison ; l'intégration plateforme est apparue au grand jour pour la première fois.

Des plates-formes d'intégration ont été développées pour remplacer les fonctionnalités de nombreux fournisseurs de VAN en matière de traitement des transports, de transformation et de routage. Ceux qui ont quelques années d'expérience dans ce domaine se souviennent de cette époque comme de l'ère de la SOA (et nous sommes aujourd'hui aux alentours de 2004-2008). Depuis lors, l'architecture SOA s'est développée, ou s'est en quelque sorte transformée, pour devenir la norme des microservices. Dans l'ensemble, il s'agit d'un excellent résultat.

Cependant, les entreprises se voyaient souvent imposer des frais de licence substantiels par les fournisseurs de logiciels d'intégration au lieu de payer le fournisseur VAN . En outre, la flexibilité des logiciels d'intégration a encore aggravé la complexité, car les entreprises pouvaient désormais s'adapter à pratiquement n'importe quoi et le traiter dans leurs systèmes, moyennant toutefois un coût fixe élevé ainsi que des frais de consultants, de traitement manuel et de construction d'intégrations. Nous souffrons toujours de ce désordre : les spaghettis de l'intégration. Le nombre de formats, de protocoles de communication et de connexions P2P est écrasant.

La solution à cette situation inefficace, mais malheureusement en pleine expansion, est apparue de manière inattendue. Comme les pays, les régions et les systèmes avaient leurs propres formats et protocoles, l'Union européenne a identifié le problème comme un obstacle à un marché intérieur efficace. L'UE a commencé à développer Peppol afin de disposer d'un réseau de collaboration avec une norme précise et contrôlée.

Cela s'est fait indépendamment de l'effondrement du B2B, mais l'UE avait besoin d'une forme de norme de communication commune et efficace, car il n'en existait pas sur le marché.

Cela n'a pas plu à tout le monde. Les fournisseurs de VAN ont compris que la simplicité d'une norme commune réduirait radicalement le montant des frais ou des redevances perçus, supprimant ainsi une importante source de revenus.

Finalement, avec l'aide ferme des décideurs européens et l'adoption continue de Peppol par les gouvernements et les entreprises, la plupart des fournisseurs de VAN ont réalisé que le maintien d'une norme unique était plus rentable à long terme. La gestion du désordre B2B et des spaghettis d'intégration ne suffisait plus. Le soutien des opérateurs de VAN a permis à Peppol de décoller.

Les entreprises qui ont investi massivement dans une intégration plateforme et qui traitent toutes les communications B2B en interne n'ont pas non plus été submergées par la joie. Peppol exige l'utilisation d'un point d'accès (PA) Peppol, également appelé fournisseur de services Peppol, comme seul moyen d'échanger des messages par l'intermédiaire de Peppol. Cette interface unique avec le réseau rend redondantes les connexions P2P existantes et la capacité de gérer de nombreux protocoles de transfert.

Les utilisateurs de l'intégration plateforme sont arrivés à la même conclusion que les opérateurs VAN . Du moins, ils commencent à s'en rendre compte : l'utilisation d'une norme unique permet de régler une grande partie du problème. Simultanément, un nombre croissant de fournisseurs de logiciels, par exemple les ERP tels que SAP, ajoutent un support natif pour Peppol, éliminant ainsi le besoin de transformations complexes.

De nombreuses plateformes d'intégration et les opérateurs de VAN ont compris que le modèle Peppol était très avantageux.

L'AP garantit la livraison des messages ; le protocole et la norme sont hautement structurés et validés, et tout message reçu par le réseau est entièrement validé et toujours correct à 100 % du point de vue de la syntaxe et des règles de validation.

Ces contrôles et équilibres offerts par le réseau Peppol peuvent réduire de manière significative le besoin de traitement et de suivi des erreurs, ce qui permet d'économiser de l'argent à long terme. Le personnel peut être affecté à d'autres tâches, et les licences de logiciels et les systèmes peuvent être réduits.

Lorsque j'ai commencé à travailler dans l'informatique et le B2B, l'une de mes premières missions a consisté à mettre à niveau un flux d'EDIFACT D.93A vers le tout nouveau D.96A (ceux qui connaissent EDIFACT savent peut-être que le D.96A a été publié en 1996) et ma première pensée a été la suivante : "Qu'est-ce que c'est que ça ? "Qui, au nom de Dieu, a eu l'idée de ce format ?Puis j'ai réalisé qu'il s'agissait des Nations unies, et j'ai donc accepté la situation.

Peppol a choisi l'UBL comme norme sous-jacente, basée sur EDIFACT. Il s'agit d'une base bien utilisée et éprouvée qui répond aux besoins de la plupart des entreprises.

Les messages UBL sont envoyés par AS4 (ebMS) sous forme de données signées et cryptées, ce qui sécurise le message et le transport et fait de Peppol une méthode de communication sûre et fiable. Peppol est géré comme une norme ouverte, avec un comité et des membres qui définissent la norme et apportent des modifications et des ajouts. Chaque pays adhérent dispose d'une ou plusieurs autorités Peppol qui régissent les membres dans chaque pays.

Consultez cet article pour vous familiariser avec la terminologie de Peppol.

Peppol est un ensemble de normes et d'infrastructures conçues pour simplifier les processus de passation électronique des marchés publics en Europe et au-delà. Son adoption a été motivée par la nécessité de disposer de solutions normalisées et interopérables en matière de marchés publics électroniques afin d'améliorer l'efficacité, de réduire les coûts et de favoriser le commerce international.

Points clés concernant l'adoption de Peppol :

Dans l'ensemble, l'adoption de Peppol représente une avancée significative dans la numérisation des processus de passation de marchés, favorisant une plus grande efficacité, un meilleur rapport coût-efficacité et l'intégration du commerce mondial.

Et ses défis ?

L'adoption de Peppol, bien qu'avantageuse, peut se heurter à plusieurs obstacles. Je suis un peu brutal ici - il est essentiel d'envisager Peppol avec les yeux bien ouverts :

Pour surmonter ces obstacles, il faut une planification stratégique, des ressources adéquates et un engagement fort des parties prenantes afin d'adopter et d'exploiter avec succès les avantages de Peppol.

Peppol se développe. La communauté fait de son mieux pour combiner les ressources afin de répondre aux besoins de chacun.

La norme s'est scindée en Peppol BIS, utilisé principalement en Europe, et en Peppol PINT, utilisé au niveau international. C'est probablement une bonne chose, car les réglementations et les exigences en matière de TVA ne peuvent être satisfaites dans un format unique, mais la correspondance (transformation) entre les deux est clairement définie.

En repensant aux spaghettis dont nous avons souffert il y a quelques années, il est prouvé que Peppol peut résoudre les complexités, aider à réduire les coûts, diminuer les erreurs et fournir des données de meilleure qualité. Même s'il existe des défis valables qui peuvent s'avérer difficiles à surmonter pour certains, il est évident que Peppol continuera à se développer. Dans les années à venir, nous verrons un soutien accru de la part des systèmes et des services, par exemple les ERP, ajoutant un support pour les formats XML de Peppol, plus de comtés se joignant, et une augmentation continue des transactions et des utilisateurs.