Si la newsletter ne s'affiche pas bien, cliquez ici.

Lettre n°39 juin 2009/
Lettre n°39 juin 2009

ImprimerImprimer

Focus

ETEBAC est mort! Vive... SWIFTNet? EBICS? Internet Bancaire?


Arnaud BRUNETON, Manager Senior
Au-delà des nouveaux moyens de paiement, la mise en place de SEPA(Single Euro Payments Area) soulève la question des formats d’échange de fichiers entre banques et entre les banques et leurs clients. De nouveaux formats sont en effet imposés par SEPA, plus connus sous le nom d’ISO 20022. L’interrogation sur le changement de format pose mécaniquement la question du protocole qui le véhicule. Mécaniquement encore, la remise en cause du protocole pose à son tour la question de la sécurité de l’information et de la signature des fichiers échangés.

Aujourd’hui, 90 000 entreprises utilisent le protocole ETEBAC 3 et 3 000 entreprises utilisent ETEBAC 5. ETEBAC est donc un pilier de la communication bancaire en France, les autres entreprises utilisant pour un faible nombre SWIFTNet et les autres de l’Internet bancaire. Les évolutions liées à SEPA impactent fortement ce protocole, constituant un enjeu important pour les entreprises. Mais qu’en est-il exactement d’ETEBAC, de son avenir, des alternatives, et des modalités de migration ?
L'utilisation actuelle du protocole ETEBAC
__________________________________

Le protocole ETEBAC est utilisé depuis une vingtaine d’années dans le cadre des échanges de fichiers entre les banques et les entreprises. Plusieurs versions ont existé mais uniquement deux sont encore utilisées aujourd’hui : ETEBAC 3 et ETEBAC 5. Son périmètre d’utilisation est toutefois limité au territoire national.

ETEBAC 3


ETEBAC 3 propose des échanges de fichiers en émission (à destination de la banque) et en réception (fichiers en provenance de la banque). Les caractéristiques de ce protocole sont les suivantes:

  • Il est utilisé par les entreprises pour l'envoi des virements fournisseurs et de la paie, et la réception des relevés de comptes.
  • Il véhicule les formats CFONB (Comité Français d'Organisation et de Normalisation Bancaire), qui sont de longeur fixe, i.e chaque mouvement bancaire figure sur une ligne de 120 caractères et chaque virement est indiqué sur une ligne de 160 ou 230 caractères selon que le virement à lieu au niveau national ou international.
  • D'un point de vue transport et dans le sens de l'émission de fichiers vers la banque, ETEBAC 3 fonctionne de la manière suivante: l'entreprise émet le fichier à la banque et envoie paralèllement une confirmation papier dûment signée récapitulant le nombre de virements et leur montant global. Autant dire que cette solution n'est pas la plus sécurisée, ni la plus automatisée.
  • Enfin, la facturation des échanges sous ETEBAC 3 se fait généralement sous forme d'un abonnement mensuel et d'une facturation par fichier sous conditions de volumes.
ETEBAC 5

De son coté, ETEBAC 5 propose d'émettre des ordres de virements vers les banques en utilisant le format Edifact. Ses cractéristiques sont les suivantes:

  • Les entreprises l'utilisent aujourd'hui pour les virements unitaires (d'équilibrage) ou de masse (fournisseurs, paie).
  • Edifact est un format dit variable, dans la mesure où les différents ordres de virements sont enregistrés "à la chaine" dans le fichier (passer un ordre de 1 000 000 EUR ou 1 000 EUR modifie la lecture des données de 3 caractères seulement).
  • Du point de vue du fonctionnement du protocole, la sécurisation est optimale et bien plus importante que pour ETEBAC 3: chaque fichier est signé électroniquement et de manière personnelle grâce à une carte à puce délivrée par le GIE Carte Bancaire.. Ces cartes véhiculent un certificat grâce auquel ETEBAC 5 assure l’authentification réciproque des partenaires qui échangent, l’intégrité des fichiers transportés, la non-répudiation des transferts (signature personnelle, accusé de réception composé des sceaux et de l’horodatage, signés par le destinataire), la confidentialité des informations transportées (chiffrement avec la clé du destinataire). Chaque carte a préalablement une habilitation pour signer, transporter ou transporter et signer les fichiers.
  • Une des particularités du contrat de télétransmission via ETEBAC 5 est que l’entreprise y précise la liste des comptes qui peuvent être débités dans le cadre du contrat, mais aussi ceux qui peuvent être crédités. Le coût de ce protocole est plus élevé que pour ETEBAC 3 : la facturation se fait par un abonnement mensuel et par virement.
Le protocole ETEBAC est donc, comme mentionné en introduction, au centre des échanges clients-banques. Il répond aux attentes de la grande majorité des entreprises.
Quel avenir SEPA offre-t-il à ETEBAC?
______________________________

Actuellement, deux facteurs vont avoir pour conséquence une remise en cause de l’utilisation d’ETEBAC : le premier est d’ordre technique et le second relève d’une considération réglementaire.

La contrainte technique

Le premier facteur relève d’une contrainte technique. ETEBAC repose en effet sur l’utilisation du réseau des lignes X25 d’Orange Business Services. Or ce réseau fait appel à une technologie vieillissante pour laquelle les compétences se font rares et la maintenance coûteuse.Cette situation s'est traduite en 2008 par une révision. Cette situation s’est traduite en 2008 par une révision des tarifs à la hausse et l’arrêt de la commercialisation de certains accès à bas débit. Ces éléments constituent le début de l’arrêt complet du réseau X25, planifié selon le calendrier suivant :

  • 1er avril 2009 : Arrêt de la commercialisation de tous les accès sauf 64k, 1920k et canal D
  • 1er janvier 2010 : Arrêt technique de tous les accès sauf 64k, 1920k et canal D – Arrêt de la commercialisation des autres accès
  • 1er juillet 2011 : Arrêt technique X25
L’arrêt du réseau X25 remet en cause l'utilisation du protocole ETEBAC. Pour pallier cette fin programmée, certaines banques proposent d’utiliser le protocole ETEBAC 5 sous adresse IP, c'est-à-dire par Internet. Cette solution touche une faible proportion des entreprises qui utilisent ETEBAC et par ailleurs, elle ne résout pas la question du rapatriement des relevés de comptes.

La contrainte réglementaire


L’autre facteur remettant en cause l’utilisation d’ETEBAC est d’ordre réglementaire. Les formats ISO 20022, imposés dans le cadre de SEPA, sont fondés sur une syntaxe XML et sont de longueur variable. Les fichiers CFONB habituellement utilisés, étant de longueur fixe, ne peuvent plus l’être dans le cadre de SEPA.

Finalement, les aspects technique et réglementaire sonnent le glas d’ETEBAC, même si le CFONB s’assure de la pérennité des infrastructures et logiciels pour la personnalisation des cartes via des actions de maintenance, et ce jusqu’en 2011. Les entreprises utilisatrices d’ETEBAC disposent donc de deux ans pour étudier, choisir et mettre en place un nouveau protocole de communication bancaire. Ce délai est par ailleurs en phase avec le calendrier de mise en place de SEPA.

Quelles sont les alternatives à ETEBAC
___________________________________

Il existe plusieurs alternatives à ETEBAC, provenant du monde bancaire : SWIFTNet, EBICS et l’électronique bancaire.

SWIFT (Society for Worldwide Interbank Financial Telecommunication) a été créé en 1973 par des banques et des institutions financières. Son but était le développement et la standardisation de messages véhiculant de l’information financière entre ses membres. Aujourd’hui, SWIFT intervient auprès de plus de 8 700 institutions dans 209 pays, et propose un accès standardisé et sécurisé, unique pour toutes les banques dans le monde. SWIFTNet est un canal de communication bancaire ouvert aux entreprises depuis plusieurs années.



Chaque nouvelle offre de Swift à destination des entreprises est allée dans le sens de la simplification de l’accès à SWIFT pour les entreprises. Au niveau mondial, plus de 300 groupes sont aujourd’hui connectés à Swift (une trentaine en France).

Il est important de signaler que SWIFT correspond à la fois à:
un réseau, des services et des solutions.

Le
réseau SWIFT, ou SWIFTNet, présente des avantages en adéquation avec la sécurisation des échanges :
  • La garantie de livraison : une fois le message émis, SwiftNet a obligation de le délivrer à son destinataire. Cette obligation comporte une responsabilité financière.
  • L’obligation d’action : les procédures internes à SWIFTNet assurent que dès qu’un message est reçu, SWIFTNet a une obligation d’action et se doit de traiter le message.
  • *La non-répudiation : le haut degré d’identification et d’intégrité ainsi que le stockage de longue période des messages permettent d’arbitrer très rapidement un litige et donc de prémunir le destinataire d’un message d’un risque de répudiation de la part de l’émetteur.
  • La résilience : une présence géographique multiple, dont plusieurs sites de back-up, ainsi que des exercices réguliers de « disaster recovery » permettent à Swift de se prémunir contre les risques d’interruption de service.
Il existe plusieurs manières de se connecter à SWIFTNet :
  • La connexion directe, mode de connexion historique.
  • La connexion partagée et mutualisée, proposée par des Services Bureau.
  • La connexion légère, par le biais d’Internet, appelée Alliance Lite.
La connexion directe consiste pour une entreprise à installer dans ses locaux tous les éléments nécessaires à la connexion à Swift, comme le font les banques. Si cette solution avait été adoptée par quelques groupes français initialement, elle est progressivement abandonnée car coûteuse et lourde à administrer.

Dans le cadre d’une connexion via un Service Bureau, la connexion à Swift est souscrite par le prestataire. Il met cette connexion à disposition de ses différents clients, qui partage ainsi les coûts.

Swift Alliance Lite est une messagerie unitaire et fichier, qui gère tous les formats, fondée sur l’utilisation d’Internet. Elle s’adresse à tout type de clientèle, mais vise en particulier les entités qui gèrent moins de 200 messages par jour (en entrée et en sortie). Son fonctionnement repose sur l’utilisation d’une clé USB incluant une partie logiciel, qui réalise une authentification vis-à-vis de SWIFTNet, chiffre et signe les fichiers jusqu’au serveur chez SWIFT. Les premiers tests de Swift Alliance Lite sont prévus dès le début du 2nd trimestre 2009, pour un déploiement généralisé à partir du 4ème trimestre 2009. Ce déploiement pourra être assuré par les banques ou par les éditeurs.

Les différents services proposés par Swift sont :

  • La messagerie traditionnelle FIN, qui utilise les formats de type MTXXX, utilisés dans le cadre des paiements, des opérations de titres, de change, etc. FIN concerne des messages unitaires.
  • Le service de messagerie FileAct, qui permet d’échanger et de transmettre des fichiers dans un environnement fiable et sécurisé. Les fichiers concernent des virements, des prélèvements, des LCR (Lettre de Change Relevée). Ce type de service sert essentiellement à traiter des informations de masse et la variété des formats traités est très large.

SWIFTNet Accord est une solution de réconciliation automatique des confirmations d’opérations de marchés, limitée aux opérations les plus courantes de change et de taux.

SWIFT a été choisi par l’ISO pour être l’autorité d’enregistrement des codes BIC, IBAN et des messages XML ISO 20022.

A propos de la tarification, les connexions à SWIFT et les coûts d’utilisation sont de plus en plus abordables. Les modes de connexions sont de plus en plus directs et simples à mettre en oeuvre, engendrant des sources d’économie. L’accrois-sement des volumes de transactions passées par le réseau SWIFT permet cette diminution des coûts unitaires.

EBICS

EBICS (Electronic Banking Internet Communication Standard)) est un protocole allemand de plus en plus étudié en France. Il constitue depuis janvier 2008 le standard de communication bancaire sous IP en Allemagne. La migration des entreprises allemandes est en cours. Il permet de véhiculer tous les types de format et à ce titre, est prêt pour les formats SEPA. La communication est sécurisée grâce à l’utilisation d’un site Internet sécurisé. Ce protocole permet de signer électroniquement et de façon sécurisée à distance.

Dans sa version actuelle (version 2.3), EBICS propose presque les mêmes caractéristiques de sécurité qu’ETEBAC 5, à savoir l’authentification du serveur (donc de l’entreprise), le chiffrement des données, la signature électronique de transport garantissant l’intégrité du message. La signature électronique personnelle jointe est une option.

EBICS se limite aux échanges de fichiers, et n’offre pas de services interactifs comme le fait Swift. Sa mise en œuvre est par ailleurs très simple.

La version actuelle (v 2.3) nécessite des adaptations afin de pouvoir être utilisée en France :

  • L’extension de la longueur des champs d’identification à 35 caractères comme SEPA le stipule,
  • L’utilisation de certificats électroniques X509 (pour l’authentification, le chiffrement et la signature).
Le CFONB et son homologue allemand Zentraler Kreditaus schuss (ZKA) ont signé un accord en novembre 2008, instaurant des modalités de coopération sur EBICS. La première étape est constituée par un accord pour une utilisation commune des spécifications de la version 2.4 entre le CFONB et les cinq Associations de banques allemandes. Le souhait est de créer une entité commune pour gérer le protocole EBICS et sa diffusion, d’abord en Allemagne et en France, puis dans d’autres pays européens.



Le CFONB a communiqué des informations sur l’organisation en cours d’un processus d’homologation des logiciels EBICS. Les éditeurs de logiciels de communication sont maintenant à pied d’oeuvre afin d’inclure ce protocole dans leur offre. Ils ne prévoient cependant pas de lancement avant l’automne 2009.

EBICS a d’ores et déjà prévu une migration en deux phases selon les besoins ou les choix des utilisateurs :

  • Un démarrage prévu au quatrième trimestre 2009 pour les utilisateurs d’ETEBAC 3, prévoyant toujours une signature disjointe du fichier et transmise par un autre canal de communication,
  • Un démarrage prévu au second semestre 2010 pour les utilisateurs d’ETEBAC 5, incluant la transmission de la signature personnelle par le protocole.

SWIFTNet et EBICS sont recommandés par le CFONB depuis novembre 2008 pour le remplacement d’ETEBAC. La démarche du CFONB va dans le sens de la généralisation de la signature électronique et de l’accélération de l’adoption des moyens de paiement SEPA. Les arguments en faveur de ces deux protocoles sont : des investissements limités et des solutions accessibles à toutes les entreprises, quelle que soit leur taille. Le CFONB a fixé un objectif de migration pour ces deux protocoles entre fin 2009 et fin 2011, en cohérence avec l’obsolescence d’ETEBAC.

SWIFT ambitionne de servir le haut du marché des entreprises, c'est-à-dire les groupes internationaux de grande taille. De son côté, EBICS a pour cible les grandes entreprises et les grosses PME. Ces deux protocoles ne devraient donc pas se faire trop concurrence.

Web Banking

L’électronique bancaire, ou web banking, correspond aux offres de e-banking des banques, dotées de fonctionnalités de transfert de fichiers sur un site Internet sécurisé ou de saisie portail. Ces solutions permettent un travail interactif avec le serveur de la banque, tant pour la consultation des relevés que pour la saisie et la validation des ordres.

Jusqu’à présent, le web banking a souvent induit l’utilisation de formats propriétaires ou standards personnalisés par la banque. La gestion d’un format par banque n’étant pas simple pour les entreprises, le web banking était davantage utilisé par les entreprises intervenant au niveau national et auprès d’une seule banque. L’avènement d’un format standard européen pour les échanges en euros peut avoir un impact sur les formats demandés par les banques et ainsi séduire les entreprises. Par ailleurs, certaines entreprises faisant appel à plusieurs banques pourraient choisir le web banking comme solution d’appoint ou de dépannage du
protocole utilisé habituellement.
Comment envisager la migration vers un nouveau protocole?
__________________________________________________

En matière de migration, les trois solutions alternatives à ETEBAC présentées ci-dessus trouveront preneurs. Elles se distinguent par :
  • Les délais de mise en place,
  • Le coût d’implémentation et d’utilisation,
  • La profondeur de l’offre.
De manière caricaturale, les grands groupes internationaux qui, en plus des relevés de comptes, des prélèvements et des virements, souhaitent confirmer leurs opérations financières électroniquement ainsi que leurs rapprochements choisiront SWIFT ; les entreprises nationales ou internationales faisant appel à peu de banques pourront être intéressées par EBICS ; enfin les PME se satisferont du web banking, notamment pour sa souplesse de mise en place.

Certaines entreprises sont satisfaites par les solutions en place et ne voient aucune raison d’en changer, outre la contrainte technique. Pour ces entreprises, le choix du protocole compatible avec SEPA se fondera sur les informations fournies tant par les banques que par les éditeurs de logiciels et visera une solution simple, rapidement opérationnelle et assurant un changement à iso fonctionnalités.

D’autres entreprises perçoivent dans SEPA et son effet induit sur ETEBAC une occasion de revoir leur organisation. Le changement de protocole de communication bancaire est à la fois l’occasion de lancer le projet SEPA, et aussi de revoir l’organisation interne sur les moyens de paiement. Le changement de protocole peut par exemple permettre de repenser l’organisation existante de la communication bancaire au sein de l’entreprise (la gestion des fichiers et leur validation pour mettre en place un point de sortie unique, au lieu de plusieurs points de sortie).

Il n’y a pas de modèle unique d’abandon d’ETEBAC. D’une entreprise à l’autre, les facteurs à prendre en compte peuvent varier : l’organisation de l’entreprise, le nombre de banques, les localisations, les types de flux actuels et futurs, l’approche mono ou multi-métiers, le budget, etc.

La migration nécessite la contribution des éditeurs et des banques a minima. L’accompagnement par un cabinet de conseil apporte une valeur ajoutée sur plusieurs aspects :
  • La coordination des travaux entre les différents services impactés,
  • L’étude des protocoles en vue de remplacer ETEBAC,
  • L’analyse des offres bancaires pour l’ibanisation du référentiel ou pour les services complémentaires proposés...
La meilleure stratégie pour envisager l’abandon d’ETEBAC consiste à mener une réflexion de fond sur les différents processus métiers impactés (évaluation des transformations organisationnelles et contextuelles, et des impacts sur le système d’information) et à ne pas surdimensionner le projet, en essayant de partir de l’existant (faire un bilan en interne des outils utilisés et des besoins actuels et futurs, avoir une bonne vision de l’offre du marché).

Dans le cadre de mise en oeuvre du nouveau protocole, le plan de conduite du changement est primordial. Il prévient les risques organisationnels et humains de la migration vers le nouveau protocole. Il doit également aborder la révision des documents contractuels avec les banques.
Conclusion
_________

La fin d’ETEBAC a soulevé des inquiétudes parmi les entreprises utilisant ce protocole. Les réponses aujourd’hui disponibles ont de quoi rassurer les entreprises, quelle que soit leur taille. Le changement de protocole est aussi l’occasion d’étudier l’organisation en place, ses possibles changements et/ou optimisations, et de formaliser les besoins dans l’attente de la mise à disposition des nouvelles solutions proposées tant par les éditeurs que par les banques.

Le changement de protocole remet en question la sécurité des échanges. Chaque solution présentée a ou va avoir des réponses satisfaisantes sur le sujet. La signature des fichiers soulève une autre question qui fait aujourd’hui l’objet d’un débat et présente plusieurs solutions possibles. La solution retenue n’est toujours pas connue.
Retour retour aux articles