Projet de Conception N 1 Automatisation d'un processus de paiement. Livrable: Étude de l'edi

Transcription

1 Projet de Conception N 1 Automatisation d'un processus de paiement Livrable: Étude de l'edi Enseignants : Y.AMGHAR, L.BRUNIE Equipe projet : R.Jeatsa Kengni, X.Lucas, L.Martin, C.Molea (CdP)

2 Avant Propos Ce document a pour but de comparer diverses solutions d'échange de données informatisées afin d'aider au choix de la solution la plus convenable dans le cadre de ce projet. PC1 Automatisation d'un processus de paiement 2/15

3 Suivi du livrable Responsable du livrable : Xavier LUCAS Validation du livrable le : 04/11/2009 Date Version Auteur Modifications 21/10/ Xavier LUCAS Création du document et traitement section /10/ Xavier LUCAS Traitement section /11/ Xavier LUCAS Traitement 1.3, 2, 3 12/11/ Cosmin MOLEA Vérification et validation PC1 Automatisation d'un processus de paiement 3/15

4 Table des matières 1. Étude de l'existant Introduction Solutions existantes Normes de message EDIFACT Protocoles et réseaux ETEBAC EBICS Swift WebEDI Alternative existante : ebxml Comparatif Pertinence des données Performances Coût de mise en place Solution retenue Annexe 1 : Structure d'un message EDIFACT...12 PC1 Automatisation d'un processus de paiement 4/15

5 1. Étude de l'existant 1.1 Introduction L'Échange de Données Informatisé (Electronic Data Interchange en anglais), plus couramment appelé EDI, est le terme générique utilisé pour désigner un échange d'informations entre deux entités par messages standardisés, de machine à machine. En effet, chaque message doit être conforme à une syntaxe et un vocabulaire respectant le standard choisi. Le but de l'edi est de réduire au maximum les interventions humaines dans le traitement de l'information, afin de pouvoir disposer de manière rapide et fiable d'une information exhaustive. Sa mise en place est indispensable dans une optique de gestion «juste à temps» qui augmente considérablement le nombre de transactions à traiter et implique donc de les traiter dans un temps toujours plus court. Dans la suite de ce document, on fera attention à comprendre qu'un EDI engendre : une norme pour les messages l'utilisation d'un réseau un protocole de communication La mise en place d'un tel système se justifie de manière évidente dans le cadre du projet qui a luimême pour but l'automatisation de certains processus. 1.2 Solutions existantes Afin de réaliser ces échanges, nous aurons le choix entre plusieurs solutions existantes à l'heure actuelle, pour chacun des sous-ensembles de l'edi cités plus précédemment Normes de message EDIFACT L'EDIFACT (Electronic Data Interchange For Administration, Commerce and Transport) est une norme principalement utilisée dans les domaines de l'administration, du commerce et du transport, mais aussi dans le secteur bancaire français. Il s'agit d'une norme qui se veut relativement générique et qui permet notamment l'échange de documents tels les factures, bons de commande, bons de livraison... Les messages sont structurés de telle manière qu'ils contiennent 3 sections : en-tête, détail, récapitulative. Le détail de ces sections est fourni pour information en annexe de ce document. Cette norme est mise à jour au moins deux fois l'an pour rajouter de nouveaux types de données et de messages. Cette norme est PC1 Automatisation d'un processus de paiement 5/15

6 un standard très utilisé à l'heure actuelle dans le secteur bancaire Protocoles et réseaux ETEBAC ETEBAC (Échange Télématique Banque-Clients) est une norme d'échange dictée par le CFONB (Comité Français d'organisation et de Normalisation Bancaires). Elle possède plusieurs versions, 5 au total dont 3 complétement caduques. Seules ETEBAC 3 et ETEBAC 5 sont utilisées à l'heure actuelle. La différence entre ces deux normes réside dans le fait que la première n'est pas sécurisée (demande de confirmation du client) tandis que la deuxième oui (authentification par carte à puce). Ces deux normes permettent l'échange de messages de types virements, prélèvements, relevés, etc. Le réseau utilisé par les banques pour faire transiter les données grâce à ce protocole est le réseau X25 (Transpac). Mais France Télécom prévoit l'arrêt de la maintenance de ce réseau d'ici fin 2010 début 2011 suite à l'émergence du réseau internet offrant plus de possibilités. En remplacement, le protocole allemand EBICS est mis en place progressivement EBICS EBICS (Electronic Banking Internet Communication Standard) est un protocole de communication sécurisé permettant l'échange de données banque-client. Ce protocole d'origine allemande à été conçu par le ZKA (Zentrale Kreditausschuss) et est maintenant préconisé par le CFONB. Sous sa tutelle, il a un fonctionnement analogue à ETEBAC qu'il remplace. Un avantage important de ce protocole est sa capacité à transporter des volumes importants en conservant un niveau de sécurité élevé. Il utilise le réseau internet et s'appuie sur le protocole TCP/IP Swift L'utilisation de SWIFT peut se faire : directement grâce à la mise en place du côté de l'entreprise de sa plateforme de communication à travers le réseau SWIFTNet indirectement en transitant par un Service Bureau en utilisant un VPN Le protocole utilisé par SWIFT est un protocole IP normalisé. Bien entendu, aucune information ne passe par internet puisque c'est le réseau privé SWIFTNet qui est utilisé. L'utilisation de Swift en accès direct permet l'accès à un très grand nombre de services qui peuvent s'avérer vitaux tel FIN qui permet la récupération de grands volumes de messages perdus respectant la norme SWIFT FIN Message WebEDI EDI ayant émergé récemment avec la bulle internet, le WebEDI permet, via PC1 Automatisation d'un processus de paiement 6/15

7 l'utilisation du réseau internet, l'échange d'information entre des formulaires internet et une autre entreprise possédant des traitements d'échange automatisés. Le WebEDI s'appuie dans sa conception sur les standards EDI. Il a été mis en place dans le but principal de mettre à disposition des PME une capacité d'interaction avec d'autres EDI, permettant l'ouverture de ceux-ci à des entreprises de tailles réduites. 1.3 Alternative existante : ebxml Il existe une principale alternative sensée remplacer l'edi, il s'agit d'ebxml. Il s'agit d'un projet se voulant plus haut niveau : il a pour but non pas seulement de remplacer la standardisation assez rigide des messages et les réseaux privés utilisés par les exploitants d'edi, mais aussi de permettre aux entreprises de définir elles-même les messages qu'elles souhaitent échanger avec leur partenaires, leurs propres processus d'affaires, etc. Pour ce faire, il existe une bibliothèque d'objet dans laquelle l'entreprise peut choisir ceux qui l'intéresse pour préciser les données nécessaires à la transaction. Puis c'est aux partenaires de mettre en place des répertoires et référentiels dans lesquels seront stockés les structures de données et les processus ainsi que mettre en place les droits d'accès. Tout ceci en conservant une sécurité des données tout au long des étapes de l'échange. PC1 Automatisation d'un processus de paiement 7/15

8 2. Comparatif 2.1 Pertinence des données Pour évaluer la pertinence des messages échangés, nous avons suivi plusieurs critères : conformité de la gamme existante, évolutivité de la gamme et tendance de la gamme de messages (c'est à dire si celle-ci est utilisée de manière importante ou non, si il s'agit d'une norme reconnue). Vis à vis de la gamme de messages, on peut constater que suivant chaque critère, on a des positions très différentes. En effet, EBICS se veut très conforme et en vogue grâce à son support du format européen SEPA (Single Euro Payment Area) qui permet la dématérialisation des échanges entre banques et entreprises, mais peut évolutif du fait des validations de différents comités nécessaires avant l'ajout d'un répertoire. Ce qui n'est absolument pas le cas des WebEDI et de l'ebxml, ce dernier permettant à l'entreprise de choisir elle même les données qu'elle veut transporter dans ses messages. Ce qui explique un conformisme un peu amoindri vis à vis des EDI tels que SWIFT destinés aux échanges entre entreprises de grandes tailles puisque par exemple ebxml est tout juste en train de mûrir sur le plan du vocabulaire métier utilisé. EBICS et SWIFT sont toujours très utilisés de nos jours et dégagent des normes très suivies. PC1 Automatisation d'un processus de paiement 8/15

9 2.2 Performances Afin d'avoir une vue d'ensemble des avantages de l'exploitation d'un EDI, est présenté cidessous un graphiques représentant les performances des EDI proposés dans ce dossier, suivant les critères : sécurité des échanges, capacité à gérer des densités importantes d'échanges, rapidité et efficacité de la maintenance. Grâce à sa séparation physique avec le réseau internet, SWIFT se démarque grâce à l'utilisation de son réseau privé SWIFTNet, ce qui offre bien évidemment une sécurité accrue des échanges de l'edi. Il faudra tout de même noter que, après les scandales d'espionnage de transactions par la CIA, il est admis que cet organisme vérifie toutes les transactions transitant par ce réseau. En effet il existe toujours un risque potentiel de corruption des données si celles-ci transitent par le réseau internet. Juste derrière, EBICS se veut également bien sécurisé grâce à son utilisation dédiée aux données interbancaires qui utilise des certificats. Pour ce qui est de la capacité de l'edi à supporter un grand nombre de transactions, SWIFT reste leader. En effet il est principalement dédié aux grandes entreprises effectuant un grand nombre d'échanges par jour, et c'est de cette manière qu'il devient rentable. EBICS est également capable de supporter un grand nombre d'échange bien qu'un peu moins robuste dans le cas d'une fréquence extrême. Les WebEDI et ebxml sont eux moins apte à traiter un nombre élevé de transactions mais se démarquent par la possibilité de maintenance rapide offerte grâce à l'utilisation d'internet. Pour ce critère, SWIFT dispose de nombreux services auxquels il est possible de souscrire et permettant une la récupération d'un très grand nombre de transactions rapidement grâce à leur conservation et la gestion automatique des incidents de transactions de manière générale. PC1 Automatisation d'un processus de paiement 9/15

10 2.3 Coût de mise en place Autre élément important, le coût de mise en place d'un EDI. C'est un élément clé pour savoir si les performances énoncées ci-dessus sont par exemple rentables. Bien que très performant, SWIFT est l'edi le plus cher à mettre en place. Ceci s'explique par la nécessité de raccordement au réseau privé SWIFTNet exploité par les plus grandes entreprises internationales et c'est cette ouverture qui peut justifier son prix. EBICS est aussi plus coûteux à mettre en place qu'une solution WebEDI ou ebxml qui elles ont justement pour vocation de minimiser les coût auprès des entreprises et de suivre la philosophie «qui que ce soit, n'importe où, pourra commercer avec n'importe qui d'autre» bien que ebxml nécessite un investissement plus conséquent. PC1 Automatisation d'un processus de paiement 10/15

11 3. Solution retenue Parmi l'ensemble des solution évoquées, on peut noter que EBICS et SWIFT, au-delà de leur préconisation par le CFONB comme solutions de remplacement à ETEBAC, disposent d'atouts importants vis à vis de solutions qui semblent moins adaptées aux échanges de données bancaires. On pourrait privilégier la performance de SWIFT afin de répondre aux besoins de robustesse et de fiabilité, mais EBICS semble un choix très équilibré vis à vis de l'utilisation susceptible d'être faite de cet EDI. En effet il permet de supporter un nombre de transactions suffisant et a l'avantage d'être compatible avec la norme Européenne SEPA, ce qui permettra probablement de tirer bénéfice des échanges vers la banque. De plus son coût de mise en œuvre reste moindre et ne nécessite pas l'asservissement à un réseau totalement privé et aux nombreux services auxquels il faudrait probablement envisager de souscrire pour se mettre en conformité avec les exigences fonctionnelles mises en avant au cours de ce projet. Enfin, il sera également fortement probable que la banque partenaire nous propose une solution implémentant cet EDI particulièrement utilisé dans ce milieu. PC1 Automatisation d'un processus de paiement 11/15

12 4. Annexe 1 : Structure d'un message EDIFACT La section En-tête contient les segments : UNH :segment de service commence le message et permet d identifier de manière univoque BGM :début de message sert à identifier de manière univoque le numéro, la date et le type de la facture RFF :références, contient les références des documents relatifs à l ensemble du message CTA :contacts, sert à désigner les correspondants Le groupe de segments 1 contenant les segments : NAD :nom et adresse LOC :indication du lieu RFF :références concernant la partie désignée dans le segment NAD DOC :documents requis CTA :contacts donne des renseignements complémentaires concernant les contacts à établir avec la partie désignée dans le segment NAD FII :coordonnées bancaires désignant l établissement financier et les numéros des comptes du vendeur, de l acheteur et autres parties DTM :date et heure Le groupe de segments 2 contenant les segments : TRI :informations d ordre fiscal indiquant le type de taxe à appliquer LOC :indication du lieu où s applique la taxe Le groupe de segments 3 contenant les segments : CUX :monnaies requises dans la factures, devises DTM :date et période et heure auxquelles s appliquent les informations monétaires contenues dans le groupe 3 PAT :base de conditions de paiement PAI :instructions de paiement PC1 Automatisation d'un processus de paiement 12/15

13 ALI :informations complémentaires, conditions spéciales FTX :texte libre Les groupes de segments 4 et 5 contiennent les segments : TDT :précision concernant le transport LOC :indication de lieu DTM :précision de la date et l heure de départ et/ou d arrivée pour le transport effectué dans TDT TOD :conditions de livraison Le groupe de segments 6 contient les segments : PAC :colis, contenant le nombre d articles par colis, la taille de la palette... MEA :dimensions des colis décrits dans le segment PAC PCI :identification ds colis UNS :contrôle de section La section détails contient les groupes de segments : Groupe 7 : LIN :article, indications détaillées sur le produit RFF :références sur les documents concernant l article PIA :identification complémentaire du produit IMD :description de l article Groupe 8 : PAC :Voir le groupe 6 MEA :Voir le groupe 6 PCI :Voir le groupe 6 Groupe 9 : TRI :Voir le groupe 2 LOC :Voir le groupe 2 PC1 Automatisation d'un processus de paiement 13/15

14 Groupe 10 :Voir le groupe 1 pour le détail des segments NAD :noms et adresse LOC :localisation RFF :référence DOC :documents CTA :contact Groupe 11 : ALC :abattements et frais ALI :Voir le groupe 3 TRI :Voir le groupe 9 ACA :Voir le groupe 10 FTX :Texte libre Groupe 12 : API :informations complémentaires sur le prix FTX :Texte libre Groupe 13 et 14 : TDT :Voir le groupe 4 LOC :Voir le groupe 4 DTM :Voir le groupe 5 Groupe 15 : SID : précision sur les composantes de l article La section récapitulative contient les segments et groupes de segments suivant : TMA :montant de la facture ACT :montant total dans la monnaie de remplacement Les groupes 16 à 22 existent aussi mais ne sont pas développés ici. PC1 Automatisation d'un processus de paiement 14/15

15 Groupe de segments 23 : ALI :Voir le groupe 3 TRI :Voir le groupe 9 ACA :Voir le groupe 10 TXS :taxes, totaux partiels VAL :évaluation Groupe de segments 24 : PRP :prépaiement, indique le montant à payer d avance CNT :totaux de contrôle UNT :fin de message PC1 Automatisation d'un processus de paiement 15/15