Michel Costandi
Un récent sondage (1) du magazine CIO Online dédié aux DSI (http://www.cio-online.com) montre non seulement que moins de 9% des votants estiment leur système d'information adapté aux nouvelles règles de paiements dématérialisés, mais que plus de 40% d'entre eux ne sait même pas en quoi consiste un échange SEPA (Single Euro Payments Area). Et il y a fort à parier que parmi ceux qui s'estiment prêts, une bonne partie a totalement sous-estimé ce projet et va au-devant d'adaptations et de réajustements d'urgence.
La conjonction du démantèlement du réseau X25 et de la normalisation européenne des instruments de paiement (virements, prélèvements et paiements par cartes) induit des changements profonds dans une grande partie du système d'information. Les échéances proches (fin novembre 2011 pour l'arrêt de X25, fin 2011 pour les virements SEPA et fin 2012 pour les prélèvements SEPA) et le fait que ces deux chantiers touchent les mêmes canaux de transmission encourage à considérer les deux projets lors des décisions d'investissement. Ces changements et leurs multiples impacts font l'objet d'appréciations plus ou moins évidentes car ils interviennent dans des couches, des progiciels et des fonctions métier différentes. Ceux qui ont mis en place une cellule transversale sur le sujet l'ont bien compris. Encore faut-il que cette cellule soit dotée des moyens de travailler avec un même niveau de compétence sur toutes ces parcelles du système :
La couche de transport
Les télétransmissions bancaires actuelles s'appuient majoritairement sur des liaisons X25. L'arrêt programmé de Transpac par France Telecom, annoncé pour fin septembre 2011, oblige banques et entreprises à se tourner d'ici-là vers des protocoles de transmission basés sur internet (IP) ou sur des réseaux spécialisés tels que SWIFTNet.
Le protocole de transmission
Pour plus de 90 000 entreprises en France, la télétransmission de fichiers entre l'entreprise et ses banques repose sur les protocoles ETEBAC (Echanges Télématiques Banques-Clients). Or ces protocoles sont d'une part liés au réseau X25 et d'autre part prévus pour véhiculer des fichiers comportant des enregistrements de longueur fixe, ce qui ne convient plus au transport des fichiers XML imposés par le SEPA. Les protocoles qui se mettent en place sont principalement EBICS (Electronic Banking Internet Communication Standard) ou SWIFTNet.
Les formats de fichiers
Les formats actuels des flux échangés entre les entreprises et les banques suivent des normes nationales (CFONB en France, normalisés par le Comité Français d'Organisation et de Normalisation Bancaires). Le SEPA impose le format XML (eXtended Markup Language), normalisé par ISO (Organisation Internationale de Normalisation) selon la norme ISO 20022. Les applications qui génèrent des ordres de virements et de prélèvements doivent donc prendre en charge ces nouveaux formats. Par ailleurs, la présence dans ces nouveaux formats de champs pouvant recevoir des informations destinées à faciliter le rapprochement suppose que ces libellés enrichis, identifiants de bout en bout et autres références comptables soient dûment alimentés.
Des références de bout en bout n'ont d'intérêt que si elles sont effectivement gérées de bout en bout. La qualité du rapprochement peut être grandement améliorée si les avis d'opérés, les relevés de comptes reçus des banques comportent les références initialement insérées dans les ordres de virements et de prélèvements. Les outils de rapprochement doivent de plus être en mesure d'exploiter ces nouveaux champs présents dans les nouveaux formats.
Les identifiants de comptes bancaires
L'élargissement du critère de domesticité à la zone SEPA (32 pays d'Europe) s'accompagne d'une homogénéisation de la codification des comptes et des établissements bancaires. Le RIB français, comme les identifiants nationaux de chaque pays (BBAN ou Basic Bank Account Number) sont remplacés par une codification internationale des numéros de comptes (IBAN, International Bank Account Number) et une codification internationale des établissements bancaires (BIC, Bank Identifier Code). Le simple remplacement du RIB par des codes IBAN et BIC est en réalité un chantier comparable à ceux de l'euro ou de l'an 2000. Il faut désormais saisir, stocker et exploiter des codes de respectivement 34 et 11 caractères partout où il y avait des RIB sur 21 caractères : Fournisseurs, clients, salariés, organismes sociaux ou gouvernementaux et autres partenaires. On touche ainsi à la structure des référentiels du système d'information.
Une fois ces champs présents il reste à les renseigner. Considérer ce changement comme une simple moulinette à usage unique que l'on peut sous-traiter puis oublier c'est ne pas prendre en compte le cycle de vie des BIC. Ceux-ci sont en effet liés à la structure organisationnelle et géographique de chaque banque. Un répertoire mondial est géré par SWIFT et sa mise à jour est mensuelle. Pour la France, la Banque de France met à disposition le Fichier des Guichets Domiciliataires (FGD).
Lire à ce sujet mon article "BIC/IBAN, la réalité de la mise à jour des références bancaires dans vos bases de données" paru dans La Lettre du Trésorier Numéro 263
Difficulté à adapter simultanément tous les progiciels
Tous ces changements impliquent des montées de versions ou des développements dans plusieurs applications du système d’information. Il existe heureusement une alternative à ce « big bang », l'intergiciel. Inséré entre les applications financières et la plateforme de communication bancaire, il prend en charge les transcodifications et les reformatages (CFONB vers SEPA) en liaison avec les différentes applications et gère un référentiel unique IBAN/BIC. Il devient ainsi possible de conserver les applications existantes inchangées tout en gérant des flux SEPA bidirectionnels avec les banques, et ce, le temps nécessaire pour adapter ou migrer ses progiciels financiers vers des versions compatibles SEPA.
Lire à ce sujet l'article "SEPA, IBAN/BIC, ETEBAC : Comment migrer sans tout changer en même temps" sur mon blog :
Un nombre important de chantiers
Enfin, avec plus de 90 000 entreprises qui doivent lâcher ETEBAC pour EBICS ou SwiftNet d'ici un an, les éditeurs de logiciels et les sociétés de services pourront-ils répondre convenablement à toutes les demandes dans les délais impartis ?
Autre goulet d'étranglement, les banques, qui doivent elles-mêmes adapter leurs systèmes et avec lesquelles les entreprises devront établir de nouveaux contrats de télé-transmission, adapter les mandats de prélèvements, revoir les pouvoirs bancaires, mettre en place les certificats et autres signatures électroniques, tester les connexions et valider les fichiers transmis.
Les banques devront sans doute supporter quelques temps les formats actuels, quitte à réaliser les conversions pour le compte (ou aux frais) de leurs clients. A moins que le parlement européen n'accorde un sursis…
(1) Sondage CIO Online :
La conjonction du démantèlement du réseau X25 et de la normalisation européenne des instruments de paiement (virements, prélèvements et paiements par cartes) induit des changements profonds dans une grande partie du système d'information. Les échéances proches (fin novembre 2011 pour l'arrêt de X25, fin 2011 pour les virements SEPA et fin 2012 pour les prélèvements SEPA) et le fait que ces deux chantiers touchent les mêmes canaux de transmission encourage à considérer les deux projets lors des décisions d'investissement. Ces changements et leurs multiples impacts font l'objet d'appréciations plus ou moins évidentes car ils interviennent dans des couches, des progiciels et des fonctions métier différentes. Ceux qui ont mis en place une cellule transversale sur le sujet l'ont bien compris. Encore faut-il que cette cellule soit dotée des moyens de travailler avec un même niveau de compétence sur toutes ces parcelles du système :
La couche de transport
Les télétransmissions bancaires actuelles s'appuient majoritairement sur des liaisons X25. L'arrêt programmé de Transpac par France Telecom, annoncé pour fin septembre 2011, oblige banques et entreprises à se tourner d'ici-là vers des protocoles de transmission basés sur internet (IP) ou sur des réseaux spécialisés tels que SWIFTNet.
Le protocole de transmission
Pour plus de 90 000 entreprises en France, la télétransmission de fichiers entre l'entreprise et ses banques repose sur les protocoles ETEBAC (Echanges Télématiques Banques-Clients). Or ces protocoles sont d'une part liés au réseau X25 et d'autre part prévus pour véhiculer des fichiers comportant des enregistrements de longueur fixe, ce qui ne convient plus au transport des fichiers XML imposés par le SEPA. Les protocoles qui se mettent en place sont principalement EBICS (Electronic Banking Internet Communication Standard) ou SWIFTNet.
Les formats de fichiers
Les formats actuels des flux échangés entre les entreprises et les banques suivent des normes nationales (CFONB en France, normalisés par le Comité Français d'Organisation et de Normalisation Bancaires). Le SEPA impose le format XML (eXtended Markup Language), normalisé par ISO (Organisation Internationale de Normalisation) selon la norme ISO 20022. Les applications qui génèrent des ordres de virements et de prélèvements doivent donc prendre en charge ces nouveaux formats. Par ailleurs, la présence dans ces nouveaux formats de champs pouvant recevoir des informations destinées à faciliter le rapprochement suppose que ces libellés enrichis, identifiants de bout en bout et autres références comptables soient dûment alimentés.
Des références de bout en bout n'ont d'intérêt que si elles sont effectivement gérées de bout en bout. La qualité du rapprochement peut être grandement améliorée si les avis d'opérés, les relevés de comptes reçus des banques comportent les références initialement insérées dans les ordres de virements et de prélèvements. Les outils de rapprochement doivent de plus être en mesure d'exploiter ces nouveaux champs présents dans les nouveaux formats.
Les identifiants de comptes bancaires
L'élargissement du critère de domesticité à la zone SEPA (32 pays d'Europe) s'accompagne d'une homogénéisation de la codification des comptes et des établissements bancaires. Le RIB français, comme les identifiants nationaux de chaque pays (BBAN ou Basic Bank Account Number) sont remplacés par une codification internationale des numéros de comptes (IBAN, International Bank Account Number) et une codification internationale des établissements bancaires (BIC, Bank Identifier Code). Le simple remplacement du RIB par des codes IBAN et BIC est en réalité un chantier comparable à ceux de l'euro ou de l'an 2000. Il faut désormais saisir, stocker et exploiter des codes de respectivement 34 et 11 caractères partout où il y avait des RIB sur 21 caractères : Fournisseurs, clients, salariés, organismes sociaux ou gouvernementaux et autres partenaires. On touche ainsi à la structure des référentiels du système d'information.
Une fois ces champs présents il reste à les renseigner. Considérer ce changement comme une simple moulinette à usage unique que l'on peut sous-traiter puis oublier c'est ne pas prendre en compte le cycle de vie des BIC. Ceux-ci sont en effet liés à la structure organisationnelle et géographique de chaque banque. Un répertoire mondial est géré par SWIFT et sa mise à jour est mensuelle. Pour la France, la Banque de France met à disposition le Fichier des Guichets Domiciliataires (FGD).
Lire à ce sujet mon article "BIC/IBAN, la réalité de la mise à jour des références bancaires dans vos bases de données" paru dans La Lettre du Trésorier Numéro 263
Difficulté à adapter simultanément tous les progiciels
Tous ces changements impliquent des montées de versions ou des développements dans plusieurs applications du système d’information. Il existe heureusement une alternative à ce « big bang », l'intergiciel. Inséré entre les applications financières et la plateforme de communication bancaire, il prend en charge les transcodifications et les reformatages (CFONB vers SEPA) en liaison avec les différentes applications et gère un référentiel unique IBAN/BIC. Il devient ainsi possible de conserver les applications existantes inchangées tout en gérant des flux SEPA bidirectionnels avec les banques, et ce, le temps nécessaire pour adapter ou migrer ses progiciels financiers vers des versions compatibles SEPA.
Lire à ce sujet l'article "SEPA, IBAN/BIC, ETEBAC : Comment migrer sans tout changer en même temps" sur mon blog :
Un nombre important de chantiers
Enfin, avec plus de 90 000 entreprises qui doivent lâcher ETEBAC pour EBICS ou SwiftNet d'ici un an, les éditeurs de logiciels et les sociétés de services pourront-ils répondre convenablement à toutes les demandes dans les délais impartis ?
Autre goulet d'étranglement, les banques, qui doivent elles-mêmes adapter leurs systèmes et avec lesquelles les entreprises devront établir de nouveaux contrats de télé-transmission, adapter les mandats de prélèvements, revoir les pouvoirs bancaires, mettre en place les certificats et autres signatures électroniques, tester les connexions et valider les fichiers transmis.
Les banques devront sans doute supporter quelques temps les formats actuels, quitte à réaliser les conversions pour le compte (ou aux frais) de leurs clients. A moins que le parlement européen n'accorde un sursis…
(1) Sondage CIO Online :
Source : CIO Online du 27/09/10
Michel COSTANDI
Consultant, chef de projets chez NEOFI Solutions http://www.neofi-solutions.com
Retrouvez toute l’actualité du SEPA sur son blog http://michelcostandi.blogspot.com
Michel COSTANDI
Consultant, chef de projets chez NEOFI Solutions http://www.neofi-solutions.com
Retrouvez toute l’actualité du SEPA sur son blog http://michelcostandi.blogspot.com
Autres articles
-
Les professionnels ont besoin d’être davantage aiguillés dans l’implémentation de la DSP et du SEPA
-
La sanction du taux effectif global (TEG) erroné
-
Stock-options : un anathème de plus !
-
Rapport 2010 du C.O.D - Conseil d’Orientation de la Déontologie des Dirigeants Salariés
-
L’optimisme des CFO belges se traduit par de bons résultats
Imprimer
Partager