Nous avons développé un framework en Java qui implémente un client EBICS (version 2.4, EBICS pour Electronic Banking Internet Communication Standard). EBICS étant le nouveau protocole destiné à remplacer le protocole actuel de communication bancaire ETEBAC dont l'arrêt est prévu fin Juin 2012 en France.
Ce framework permet aux applications Java d'échanger, en toute sécurité, les transactions bancaires sous forme de fichiers via Internet. Il n'existait apparemment pas d'initiative en libre, ce pourquoi nous en proposons une.
Des tests de qualification sur www.qualif-ebics.fr ont permis de s'assurer du bon fonctionnement de notre framework.
Nous serons ravis si vous participez à l'amélioration du client pour le rendre le premier client EBICS java libre et performant. Nous sommes à votre disposition pour tout type d'aide.
NdM: le logiciel est sous licence LGPL 2.1
En fait EBICS est un standard allemand, adopté en 2008, pour effectuer des transactions bancaires. Ce standard va remplacer le standard ETEBAC. La passation devrait se faire avant fin juin 2012.
Ceci nous a donné l'idée de faire un client java EBICS qui pourrait s'intégrer dans des applications. C'est le premier client libre et les solutions existantes sont toujours payantes.
Nous avons aussi remarqué lors du développement de ce module qu'il existe plein de gens qui cherchent un client libre. Ceci nous a poussé à donner notre client en libre pour avoir la possibilité d'améliorer le code et pourquoi pas arriver à une station EBICS qui sera libre et performante qui possède aussi une communauté très forte.
Aller plus loin
- Page officielle sourceforge du projet (3263 clics)
- Site de qualification des stations EBICS (934 clics)
# À suivre...
Posté par Pinaraf . Évalué à 5. Dernière modification le 14 mars 2012 à 00:32.
Je suis tombé sur ce logiciel par hasard il y a deux jours, j'étais surpris de ne pas trouver de client EBICS libre, ça remplit un besoin réel.
Par contre, le non-site web et la mauvaise organisation du code donnent un côté brouillon au projet : le fichier ebics.jar de 9Mo contient à la fois le code source du projet, les fichiers compilés, les dépendances externes, un ensemble pour compiler en Makefile et en ant (pour pas faire de jaloux ?)… Heureusement, le dépôt SVN est plus propre (à l'exception des dépendances externes).
Après, je ne suis pas fan de Java outre mesure, mais c'est une première notable et cela peut servir de point de départ pour comprendre et implémenter la norme EBICS dans d'autres langages.
À noter également, dans la dépêche : «En fait EBICS est un standard Allemand, adopté en 2008, pour effectuer des transactions bancaire.»
Ce n'est pas tout à fait vrai : EBICS est un protocole de transmission de fichiers sécurisé avec la banque. Il permet d'envoyer des ordres de prélèvement ou de virement, mais aussi de demander des relevés de compte par exemple.
[^] # Re: À suivre...
Posté par claudex . Évalué à 5.
En parlant du code, je n'ai pas vu de fichier LICENCE ou COPYING avec le texte de la LGPL comme il est d'usage (et il est requis que le texte soit distribuer avec les sources il me semble).
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: À suivre...
Posté par hacheni . Évalué à 4.
Oui vous avez raison. Nous allons ajouter ça et pourquoi pas faire deux archives pour les binaires et les sources. ça sera mieux organisé.
[^] # Re: À suivre...
Posté par djano . Évalué à 2.
Vous pouvez utiliser Maven avec lequel il est facile de faire une séparation propre, surtout sur une projet standalone comme celui-ci.
En plus vous n'aurez pas besoin de mettre les jars externes (Xalan, commons, etc.) dans votre jar.
Au fait, pourquoi ne pas utiliser SLF4J pour le logging ?
[^] # Re: À suivre...
Posté par hacheni . Évalué à 3.
En fait pour l'organisation du code, comme c'est destinée à être intégré dans une application, Il vaut mieux avoir les sources dans le même panier surtout quand il s'agit d'un IDE comme eclipse ou netbeans. C'est donc plus facile qu'attacher l'archive des sources aux binaires.
Pour le ant et le makefile c'est pour être utilisée sur Windows ou Linux au choix. Il vaut mieux faire pour les gens pour utilisations directe.
Oui vous avez raison en ce qui concerne les transactions bancaires. En fait vous avez bien expliqué ce que je voulais dire par une transaction bancaire.
[^] # Re: À suivre...
Posté par alice . Évalué à 1.
ant et make sont disponibles pour Windows et Linux, pourquoi s'embêter à maintenir deux scripts?
[^] # Re: À suivre...
Posté par Miguel Moquillon (site web personnel) . Évalué à 5.
Si c'est un framework, en effet, il est destiné à être intégré dans d'autres projets Java nécessitant ses fonctionnalités. Et sur ce point, le choix du Makefile ou du Ant me laisse encore plus perplexe.
En effet, ils ont a un goût prononcé de retour dans le passé.
Il existe maintenant des outils qui permettent de gérer le cycle de vie d'un projet Java, ainsi que ces dépendances, et de le mettre à disposition dans des dépôts sur Internet. Je pense en l'occurrence à Maven pour lequel les dépôts de projets Java sont utilisés même par ses concurrents.
Et Maven est supporté par l'ensemble des IDE pour Java (Netbeans, IntelliJ IDEA, Eclipse) et exécutable aussi en ligne de commande aussi bien sur les Unix que sur le Windows.
[^] # Re: À suivre...
Posté par hacheni . Évalué à 2.
Oui vous avez raison, mais ce n'est qu'un début. Si le projet aura un sucées on va bien sûr opter pour des solution plus performantes et récentes notamment maven. Mais il fallait commencer par un truc simple compréhensible et utilisable même pour les simples utilisateurs c'est pour ça qu'on a opté pour ant et Makefile.
[^] # Re: À suivre...
Posté par Franck Routier (Mastodon) . Évalué à 2.
Je fais du java tous les jours, et j'ai toujours du mal avec Maven… J'y vois surtout des inconvénients : non maîtrise de la reproductibilité des build, force dépendance à internet, délais importants de compilation (notamment au début, quand il commence par télécharger internet), lourdeur de la configuration, surtout si on veut s'abstraire de ces inconvénients, et donc monter des dépôts locaux… Bon, ok, mais pour les avantages ? Quelqu'un peut-il m'éclairer d'une expérience concrète et réussie de l'utilisation de Maven ?
[^] # Re: À suivre...
Posté par Emmanuel Hugonnet (site web personnel) . Évalué à 5.
Apache Maven c'est justement un build maitrisé à la différence d'un script Apache Ant ou d'un build via l'IDE.
Si tu as une forte dépendance à internet c'est pour télécharger les libs, mais c'est valable pour tout projet ayant des dépendances tierces, il faut bien les récupérer un jour. Il existe l'option -o pour le mode offline une fois que tu as tout.
A ce moment là ta Debian dépend d'Inernet quand tu fais un apt-get dist-upgrade ….
Dans un contexte d'entreprise vous devez sûrement avoir installé un gestionnaire de dépot à la Sonatype Nexus ou Artifactory.
Avantages : un modèle unifié de projet qui lui assure un bon support dans tous les IDEs.
Build reproductible
Dépendances explicites et correctement gérées et versionnées.
Gestion propre des releases et des branches de dev (notamment sous Git).
Simple exemple nous sommes passés d'un build Ant + déploiement durant 4 H à un build Maven + déploiement de 15 minutes (avec des tests unitaires n’existant pas du temps de Ant). Donc question performances ….
Bref une migration qu'on ne regrette pas.
[^] # Re: À suivre...
Posté par Guillaume Smet (site web personnel) . Évalué à 3.
C'est comme tout, ça demande une prise en main.
Clairement, en entreprise, il faut vraiment se caler un proxy local. Mais vu que Nexus s'installe en 2 minutes, c'est parfaitement gérable.
Concernant les avantages, je dirai :
- mise au carré de tous les processus de build, livraison…
- capacité à centraliser les numéros de versions via des pom parents pour que tout soit homogène
- pas à galérer à récupérer des libs sur Internet / pas de répertoire lib commité dans les sources - sur des gros projets avec plein de libs, ça fait vite des énormes repositories - multiplié par plein de projets, c'est vite ingérable au niveau boîte. Le proxy Nexus sécurise les builds et conserve l'ensemble des artifacts utilisés de manière centralisée.
- le maven-release-plugin qui permet de poser les tags, construire les artifacts, monter les versions automatiquement etc… Une release propre se fait en deux commandes Maven, manipulations SCM comprises (tags, branches, mise à jour des versions dans les fichiers et commits des fichiers au bon moment pour que tout soit cohérent).
- pas mal de plugins vraiment utiles notamment pour la gestion des annotation processors (pour JPA, QueryDSL…), la construction de packages (maven-release-plugin, maven-assembly-plugin)
- une intégration Eclipse qui, maintenant, tient plutôt bien la route et aide pas mal à régler les soucis de dépendance (ah l'onglet Dependency hierarchy du pom.xml…)
On a un peu galéré au début mais cela fait quelques années que tous nos projets sortent comme cela et je ne regrette clairement pas l'investissement initial. Pour récupérer un projet, on se limite à :
- déclarer le repository SVN/Git dans Eclipse ;
- faire un Checkout as Maven projects ;
- Fin : ça builde, tout est là, je peux faire des releases avec les mêmes commandes que sur tous mes autres projets…
Par contre, je suis d'accord qu'il y a quelques années, quand on bidouillait et qu'on n'avait pas industrialisé le truc, c'était plutôt pénible. Le passage à Maven 3 a bien aidé aussi.
En conclusion, je dirai que ce n'est pas parfait, mais ça fait quand même bien le boulot une fois qu'on sait s'en servir et qu'on a mis en place les outils qui vont bien.
[^] # Re: À suivre...
Posté par Guillaume Smet (site web personnel) . Évalué à 3.
Et, j'oubliais, vu que c'est beaucoup plus normalisé que du ant, les intégrations dans les outils tierces sont beaucoup plus industrielles aussi.
Typiquement, l'intégration dans Sonar ou Jenkins ne demande quasiment aucune configuration. C'est plutôt pratique quand on gère pas mal de projets.
Le fait que tu retrouves toujours la même arborescence est vraiment un plus aussi.
[^] # Re: À suivre...
Posté par barmic . Évalué à 2.
Jamais eu ce genre de problème. Ça viens de quoi ?
Ce n'est dépendant d'internet que si tu ajoute des dépendances à ton projet et que tu souhaite qu'il te les télécharge (ou si tu veux utiliser un archetype). Tu as une option pour l'en empêcher.
C'est un défaut de maven. gradle apporte une solution sympa à ce genre de problème avec la création d'un deamon (mais du coup c'est une solution pour gradle pas maven).
On a une dépêche qui parlait un peu de maven :
https://linuxfr.org/news/petit-%C3%A9ventail-des-outils-de-construction-builder-libres#toc_7
Sinon à Bull Service (là où je travail) maven est utilisé sans problème notable. On ne fait pas de pur maven, il reste du script à certains endroit mais on est très content de pouvoir générer des dizaines d'archives sans prise de tête et sans recopier des scripts qu'il faut toujours un peu retoucher. Là où je travaillais avant à ST, j'utilisais maven et il me permettais de gérer l'ensemble du cycle de vie de l'application déploiement sur tomcat compris (sans dépendre d'un IDE, ni d'un OS).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: À suivre...
Posté par Mimoza . Évalué à 2.
J'ai fait beaucoup de projet avec eclipse et ANT et dernièrement on a mis Maven en place sur mon dernier projet en date
Les premiers avantages qui se sont imposé à moi sont :
-- Pas d'écriture de fichier Ant (souvent long et prise de tête, pour obtenir une script difficilement maintenable au bout de quelques temps, surtout si plusieurs ressources sont passé sur le projet)
-- Uniformisation des cycles d'intégration (chaque projet n'a plus sont propre cycle, donc cela facilite le "prêt" de ressources à court terme)
-- MAJ des librairie automatiquement (1 fichier gérer par l'archi permet d'être certain que tous les dev ayant MAJ ce fichiers ont bien les bonne libs)
-- Indépendance de la plateforme de dev (sur SVN il est très courant de rencontrer des workspace entier pour les projets, avec les fichiers de configurations spécifique à 1'IDE. Là 1 seul fichier permet de mettre en place un environnement correcte sur n'importe quel IDE Java)
Et il y en a surement d'autre …
# 3615 mavie
Posté par ymorin . Évalué à 4. Dernière modification le 14 mars 2012 à 00:36.
Cela veut-il dire que je vais pouvoir faire mes transactions bancaires en ligne, sans passer par le site de ma banque?
Par exemple, dans mon gestionnaire de compte, qui utilise cette librairie, je fais un virement de compte-à-compte, et ce virement est propagé pour de vrai vers mes vrais comptes ? Même pour des comptes tiers ?
Ce qui m'inquiète sur ce point, c'est que le site officiel de EBICS ne parle que de clients professionnels (
corporate customers), ce qui semble exclure toute utilisation à la maison. Plus de précisions sur ce point ?Standard ouvert, certes. Mais s'il faut taxer (cher, j'imagine) pour avoir sa clé et son certificat acceptés par la banque… Pas glop, pas glop… :-/
Hop,
Moi.
[^] # Re: 3615 mavie
Posté par Pinaraf . Évalué à 6.
Standard ouvert, certes. Mais s'il faut taxer (cher, j'imagine) pour avoir sa clé et son certificat acceptés par la banque… Pas glop, pas glop… :-/
Tu as tout compris ! :/
Quand on est un particulier, on pleure devant les sites moisis de nos banques… Quand tu touches à des outils pros, tu découvres qu'il y a plein de clients qui marchent partout, mais il faut aligner un bon chèque pour avoir les accès…
À titre de comparaison, en Allemagne, les banques implémentent toutes (ou presque ?) le protocole HBCI, et ça semble suffisamment ouvert aux clients pour que des logiciels libres comme aqbanking soient utilisables par des particuliers.
[^] # Re: 3615 mavie
Posté par Enzo Bricolo 🛠⚙🛠 . Évalué à 1.
Sans passer par le site de ta banque ?
Le module Ebics est un "client" qui adresse le site de ta banque en https.
Donc vu de ton banquier, c'est comme si tu te connectais sur leur portail,
sauf qu'ils vont te mettre un coup de fusil pour la gestion des certificats.
[^] # Re: 3615 mavie
Posté par hacheni . Évalué à 1.
Oui vous avez raison. c'est une connexion https avec le portail de la banque. Mais le flux des requêtes en lui même n'est pas crypté. Se sont les données qui contenues dans la requête qui sont signées par les certificats utilisateurs.
[^] # Re: 3615 mavie
Posté par ymorin . Évalué à 2.
Je voulais dire : sans lancer mon butineur et me farcir leur site ouaib moisi…
Hop,
Moi.
# Formats de fichiers supportés ?
Posté par herodiade . Évalué à 2.
Ça comble effectivement un manque important dans le monde du logiciel libre, et à point nommé. Merci !
Est-ce que le logiciel permet les échanges de fichiers de formats arbitraires (sans vérification), ou uniquement des fichiers dans des formats normalisés type CFONB ou SEPA ?
[^] # Re: Formats de fichiers supportés ?
Posté par hacheni . Évalué à 2.
Vous pouvez envoyer et recevoir des fichiers de type arbitraires. Il n'existe pas de vérification aux formats envoyés. Mais ceci dépend aussi du serveur EBICS contacté. La station que nous avons utilisé pour les tests permet l'upload et le download de fichiers de type arbitraire.
N'hésitez pas si vous avez besoin d'aide.
[^] # Re: Formats de fichiers supportés ?
Posté par Enzo Bricolo 🛠⚙🛠 . Évalué à 1.
Oui mais non, tu es censé donné le type de message (qui est censé être normé
CFONB, SWIFT, SEPA, etc.) dans le flux.
pain.xxx.cfonb160.ict
pain.001.001.02.sct
pacs.002.001.02SCL
[^] # Re: Formats de fichiers supportés ?
Posté par hacheni . Évalué à 2.
Mais ça c'est spécifié dans le XSD de EBICS car le format du fichier est obligatoire. Vous pouvez étendre le framworke et implémenter l'envoie dans un ordre de type FTB qui va vous permettre de télécharger des fichiers binaires. La plateforme XML est déjà prête pour implémenter n'importe quel type d'ordre. Vous pouvez vous inspirer des implémentations existantes. C'est le même principe.
# EBICS TS
Posté par gattaz olivier (site web personnel) . Évalué à 0.
Est ce que ce client EBICS gère les signatures numériques (EBICS TS) notamment celles produites avec les clés gemalto ?
[^] # Re: EBICS TS
Posté par hacheni . Évalué à 2.
Non, les signatures gérées sont pour EBICS T pour remplacement ETEBAC 3
# EBICS
Posté par NumOpen . Évalué à 1.
Un article à ce sujet avait déjà été posté : http://linuxfr.org/users/tagada/journaux/transmissions-bancaires-toujours-pas-dans-un-format-ouvert-et-encore-plus-cher
Dans mon entreprise, nous sommes passés à EBICS. On avait le choix d'acheter un module EBICS intégré au logiciel de comptabilité (pratique, on fait les virements depuis le logiciel de comptabilité) ou de s'abonner à un portail Web d'une banque. Dans les 2 cas, il faut en plus souscrire un abonnement annuel pour accéder au serveur EBICS de chaque banque à laquelle on transmets des ordres de virement.
Nous avons choisi le portail Web pour séparer la partie bancaire de la partie comptable (au cas où on change de logiciel de comptabilité) et pour ne pas avoir à installer quelque chose sur le poste de l'utilisateur. Le portail de la BNP avait l'air bien car écrit en PHP, donc compatible Firefox+Linux. Mais la BNP a eu tellement de mal à répondre à nos question et à tellement traîné avec les contrats qu'on a dû se rabattre sur le portail Web du CIC. Et là, c'est la catastrophe. ils nous avaient promis la compatibilité Firefox/linux et nada! C'est une application riche à installer avec Silverlight! C'est compatible uniquement avec l'ancêtre IE et que sur Windows. J'ai testé avec Moonlight sous Ubuntu, ça plante à mort. Résultat, on se retrouve avec un système pas portable du tout et en plus archi-lent, j'ai découvert que les applications écrites en Silverlight rament à mort.
Seule consolation, toutes les banques louent un système d'authentification par CAB (une petite calculette qui génère les codes d'authentification au portail), qui évite donc d'utiliser des clés USB non reconnues par Linux et avec des certificats incompatibles avec Firefox.
Prochaine étape, la migration CFONB->SEPA.
[^] # Re: EBICS
Posté par claudex . Évalué à 4.
Je ne vois pas bien le rapport.
Je ne connais pas Silverlight mais des applications qui rame, je peux t'en écrire dans n'importe quel langage, j'accuse plus facilement le développement que l'outil quand ça rame.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: EBICS
Posté par NumOpen . Évalué à 0.
Silverlight n'est pas compatible avec Firefox ni Silverlight. PHP l'est.
Silverlight est lent quelle que soit la façon dont tu codes.
[^] # Re: EBICS
Posté par claudex . Évalué à 2.
PHP n'est pas compatible avec Firefox, tu peux très bien utiliser PHP pour écrire autre chose qu'un site web. Et même si on génère du HTML avec PHP, il y a moyen qu'il ne soit uniquement compatible qu'avec IE.
PHP aussi. http://shootout.alioth.debian.org/u64q/which-programming-languages-are-fastest.php?calc=chart&gcc=on&gpp=on&csharp=on&php=on . Ça ne veut pas dire grand chose.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: EBICS
Posté par NumOpen . Évalué à 0.
Silverlight n'est pas compatible avec Firefox car c'est pour faire des applications "client riche" qui ne fonctionnent qu'avec IE, pas avec d'autres navigateurs. Sinon, il faut installer le module Moonlight mais ça marche rarement.
Silverlight est lent car tu exécute ton application riche côté navigateur, il n'y a pas de traitement côté serveur. Voir http://fr.wikipedia.org/wiki/Silverlight
[^] # Re: EBICS
Posté par claudex . Évalué à 3.
Sur la page que tu cite, je vois une compatibilité pour Firefox, Moonlight, est nécessaire pour Linux uniquement.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: EBICS
Posté par fry . Évalué à 1.
"Prochaine étape, la migration CFONB->SEPA."
Oui en 2014 mais uniquement pour les virements et les prélèvements … le reste (notamment les rejets de prélèvements) restera en CFONB.
Sinon, je pense que je vais suivre ce projet. Actuellement nous utilisons le module SCB de Sage.
Le gros défaut que je trouve à SCB c'est qu'on ne fait pas qu'envoyer les fichiers, on est obligé de les intégrer dans Sage avant de pouvoir les livrer à SCB qui lui va les transmettre à la banque.
L'intérêt ? Si on paramètre bien notre import de fichier, on peut faire un contrôle sur la cohérence des données avant l'envoi.
Un fichier de virements ou de prélèvements comportant un RIB incomplet sera rejeté lors de l'import ; ce qui évite d'avoir un fichier rejeté par la banque et donc des échéances de prélèvements ou de virements non respectées …
Espérons qu'on puisse retrouver ce type de comportement dans ce client EBICS libre.
# Implémentation dans d'autres langages
Posté par NumOpen . Évalué à 1.
C'est vrai que ce serait bien d'avoir cela en PHP et dans d'autres langages. Les ERP, les logiciels de comptabilité et de paie libres seront ainsi mieux acceptés par les entreprises.
[^] # Re: Implémentation dans d'autres langages
Posté par djano . Évalué à 2.
Il me semblait que PHP5 permettait d'utiliser les bibliothèques java depuis du code PHP?
[^] # Re: Implémentation dans d'autres langages
Posté par hacheni . Évalué à 1.
Oui c'est une bonne idée et pourquoi pas essayer. Quelqu'un a t-il commencé?
# Oups
Posté par Guillaume Maillard (site web personnel) . Évalué à 3.
Super initiative, dommage que nos efforts n'aient pas pu être mis en commun…
car OpenConcerto (ERP opensource) à déjà publié il y a quelques semaines une version libre d'un client EBICS en Java!
Pour l'avoir codé depuis zéro, je vous tire mon chapeau! C'est des semaines de boulot pour valider une telle implémentation de ce "standard" obscur.
Dès que j'aurais un peu de temps je regarderai les différences d'approches.
[^] # Re: Oups
Posté par hacheni . Évalué à 3.
Je pense aussi que ça sera si important de regarder votre code aussi. Pourquoi pas faire une communauté qui aidera à améliorer nos implémentations et mettre en communs nos efforts pour faite l'un des plus fiables client EBICS libre.
[^] # Re: Oups
Posté par djano . Évalué à 2.
J'imagine que vous avez chacun vos suites de tests, donc utiliser les deux suites de tests pour tester les deux librairies permettra de mieux valider le code.
Un merge est-il envisageable?
[^] # Re: Oups
Posté par hacheni . Évalué à 2. Dernière modification le 16 mars 2012 à 12:20.
Un merge du code est envisageable puisque les deux implémentations pourraient se compléter.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.