Types d’ordres et paramètres de format – les différentes variantes d’EBICS

En dépit de l’existence d’une seule et unique spécification, EBICS est mis en œuvre de manières différentes en Europe pour la présentation d’ordres de paiement et leur authentification par les banques. En Allemagne, l’on utilise par exemple exclusivement les types d’ordres, alors qu’en France l’on emploie les paramètres de format de fichier. Mais le client doit-il vraiment connaître ces différences? Comme je l’annonçais dans mon dernier article, voici quelques informations supplémentaires.


Par le biais du type d’ordre EBICS, le client indique la nature de la transaction qu’il souhaite transmettre au serveur bancaire. Si le type d’ordre est connu du serveur et que la personne à l’origine de la demande dispose des autorisations requises, le traitement est exécuté en appliquant le format spécifique à ce type d’ordre.

S’agissant des trigrammes des types d’ordres, EBICS fait systématiquement la différence entre l’initialisation d’un envoi de fichier et celle d’une récupération de fichier. Le standard établit en outre une distinction entre types d’ordres de production et d’administration. Les types d’ordres d’administration sont ceux permettant de piloter le protocole EBICS en soi, comme HIA et INI pour l’échange de clés ou encore HVU pour l’obtention de la signature électronique distribuée (ou VEU). Les types d’ordres de production quant à eux décrivent le contenu d’un transfert de fichier, comme CCT pour les paiements au format SEPA Credit Transfer. Les types d’ordres de production déterminent donc le format de traitement spécifique à appliquer.

EBICS établit une liste des types d’ordres de production à utiliser, ainsi que des transactions et des formats concernés. Ces types d’ordres de production sont pour l’heure principalement mis en œuvre en Allemagne.

En France et indépendamment du contenu du fichier, l’on utilise pour chaque ordre de production un type d’ordre déterminé pour les envois (FUL) et les récupérations (FDL). Pour fournir au serveur bancaire les données requises concernant le format, le type d’ordre reçoit côté client un paramètre de format de fichier (FileFormat) pouvant comprendre jusqu’à 40 caractères. La structure de ce paramètre est également spécifiée par EBICS.

Qu’en est-il de la compréhension mutuelle entre serveur bancaire et logiciel client?

Tant la variante allemande que celle utilisée en France en matière de types d’ordres permettent d’instaurer des contrôles d’authentification spécifiques à chaque format côté banque. Les paramètres de format de fichier rendent ici possible une convention plus détaillée entre le client et la banque sur le type de contenus à échanger (par exemple la version SEPA, les spécificités propres au pays). Ceci dit, les types d’ordres peuvent se révéler plus faciles à mettre en œuvre pour le client, car il n’a alors pas besoin de se poser de question sur les détails de format dans EBICS. Seul impératif : les serveurs bancaires EBICS et les logiciels client doivent se comprendre. Pour ce faire, le client doit absolument connaître le langage parlé par le serveur bancaire en face de lui.

Les deux modes d’échange de données de production entre logiciel client EBICS et serveur bancaire EBICS ont leurs avantages et leurs inconvénients. En définitive, la décision revient à l’entreprise cliente qui détient peut-être des comptes auprès de différentes institutions bancaires dans divers pays. Ce client exigera alors sans doute un standard unique. Le succès d’EBICS dépendra par conséquent également de l’homogénéité de son utilisation, ou de l’interopérabilité de ses différentes variantes. Une tâche pour les spécificateurs. Comme indiqué dans l’article de Carsten Miehling du 9.9.2014, le processus est déjà en marche.

Michael Lembcke

En savoir plus

Renouvellement des certificats EBICS serveurs

Écrit par Christophe Garnier – Directeur technique PPI FRANCE

La très grande majorité des serveurs EBICS, pour la version française de ce protocole, ont été mis en production fin 2009 et courant 2010. Bon nombre d’entre eux utilisent des certificats X.509 auto-signés d’une durée de vie de 5 ans, un certain nombre d’établissements ont donc déjà procédé à leur renouvellement et d’autres s’y préparent.


Si pour le renouvellement des certificats côté clients le protocole prévoit des messages dédiés (messages PUB, HCA et HCS) et une cinématique supprimant les interventions manuelles (messages signés ne nécessitant pas de validation complémentaire), il n’en est pas de même en ce qui concerne le renouvellement côté serveur. Le seul message HPB est disponible et la validation des certificats reçus inclut une étape manuelle : le rapprochement avec leur empreinte numérique. Une autre différence notable est la portée de l’opération qui peut concerner plusieurs milliers d’accès clients simultanément.

Il apparait donc évident qu’un minimum d’organisation et de précautions sont nécessaires pour faciliter cette intervention.

Fort de notre savoir-faire dans le développement et la mise en œuvre de logiciels EBICS tant du côté client que du côté serveur, nous avons pu tirer des enseignements des premières expériences de renouvellements de ces certificats, et nous nous permettons donc de faire les recommandations suivantes aux personnes en charge de l’administration des serveurs EBICS:

- S’enquérir auprès de son fournisseur du mode opératoire de génération et de mise à jour des certificats.

- Bien choisir la date et l’heure en évitant les périodes habituelles de stress (fin de mois, cut-off, …) ou de faible disponibilité des intervenants côté clients (fin de soirée, nuit, week-end, congés scolaires, …).  Eu égard aux dates de fin de validité des certificats, il est bien sûr possible d’anticiper leur renouvellement, ce qui offre un peu plus de latitude.

- Informer les clients, avec un délai significatif, de la date et de l’heure retenues pour la mise en place des nouveaux certificats. Il nous semble judicieux de prévoir l’envoi d’un courrier de rappel quelques jours auparavant. Voici quelques éléments que nous pensons utiles d’intégrer dans cette communication:

• Inciter le client à prendre contact avec son fournisseur pour s’assurer que son logiciel supporte le renouvellement des certificats EBICS du serveur et en obtenir le mode opératoire s’il n’est pas déjà en sa possession. A noter que nous avons identifié deux logiciels clients distincts ne permettant pas de réaliser cette opération. Dans les deux cas, les clients ont été dans l’obligation de recréer complètement leurs accès.
• Inviter le client à transmettre le courrier à d’éventuels prestataires auxquels il aurait délégué un accès de télétransmission. Le point précédent s’appliquant aussi à eux.
• L’empreinte numérique (pour une meilleure compréhension nous conseillons d’ailleurs de mentionner également les autres dénominations couramment employées: condensat et hash) de chaque nouveau certificat doit bien sûr être indiquée dans le courrier pour en permettre la validation par rapprochement. La présentation habituelle sous forme d’une matrice de 4 lignes de 8 octets peut être complétée par une présentation linéaire (les 32 octets sur une même ligne sans caractère séparateur) afin d’en faciliter le copier-coller dans le logiciel du client.
• Indiquer au client que s’il omet de mettre à jour à temps son paramétrage, le premier transfert échouera avec un code d’erreur réservé de valeur 091008 et de libellé EBICS_BANK_PUBKEY_UPDATE_REQUIRED. Il devra alors récupérer les nouveaux certificats avant de relancer le ou les transferts en échec.
• Un dernier point peut aussi mentionner les empreintes numériques des certificats en cours pour permettre aux clients qui le souhaiteraient de se familiariser avec les actions à réaliser dans leur logiciel en faisant une simulation sur la base de ces certificats. Cela permettrait au client de détecter à l’avance un éventuel dysfonctionnement de la procédure de renouvellement dans son logiciel, et dans ce cas de solliciter son fournisseur sur le champ, dans un contexte moins stressant.

La gestion du renouvellement des certificats EBICS serveurs est l’un des derniers éléments du protocole manquant de fluidité. Gageons que comme pour l’OrderID, la société EBICS saura y remédier d’ici les 5 prochaines années en faisant évoluer le standard.

Marc Dutech

En savoir plus