mardi 18 septembre 2012

SEPAmail: onze principes


Voici quelques principes qui, à mon sens, fondent l'approche SEPAmail et structurent le standard:
  • SEPAmail est une messagerie au minimum 4 coins, 2 utilisateurs, 2 adhérents, couverts par au moins trois contrats
  • SEPAmail permet des échanges de dialogues structurés formalisés au sein d'applications, qui, lorsqu'elles sont éditées par la norme, ont une portée globale (à tous les adhérents)
  • SEPAmail met en œuvre un procédé d’accusé de réception systématique (l'acquittement) qui est garanti par les adhérents. Cet accusé de réception induit l'authentification des adhérents et l'intégrité des messages échangés
  • SEPAmail permet de garantir l'authentification des personnes physiques liés à un identifiant (le qxban). Le transcodage entre un IBAN et un QXBAN est toujours assuré par l'adhérent émetteur du QXBAN. L'IBAN est ainsi protégé dans le dialogue entre les utilisateurs, même lorsque un message articule un paiement
  • SEPAmail permet, par la vertu du modèle 4 coins et de la chaîne contractuelle, à un adhérent de proposer à son client, l'utilisateur SEPAmail, des services autour du flux quand ce flux est vu par l’adhérent : enrichissement du flux, vérification, articulation d'un paiement (le rôle des établissements de paiement est un plus pour l'utilisateur)
  • SEPAmail garantit à l'utilisateur que l'adhérent doit respecter des règles et qu'il y a un juge arbitre de ces règles quand le protocole ne permet pas d'exclure intrinsèquement les tricheurs. Le juge arbitre est la Banque de France quand on parle de la loi française et c'est le scheme quand on parle de la charte des adhérents SEPAmail.
  • tous les messages constitutifs d'une application sont autoporteurs de l'information pour qu'une partie du dialogue permette de réaliser l'action suivante
  • SEPAmail ne présume pas le canal d'échange de l'information entre un adhérent et son client, l'utilisateur et notamment le moyen de l'authentification de l'utilisateur par l'adhérent
  • l'extension de norme à la relation "pair à pair" doit être possible
  • le modèle 4 coins peut devenir un modèle 5,6 coins ou plus mais pas un modèle 2 ou 3 coins dans le cadre communautaire, car c'est lui qui garantit beaucoup des principes ci-dessus et ces modèles qui rendent la confiance à l'utilisateur (les avocats, les médecins, les notaires) et oblige à un juge arbitre clair protégeant les utilisateurs
  • sepamail doit pouvoir fonctionner nativement en mode canonique avec les infrastructures et les protocoles de messageries électroniques standards

jeudi 13 septembre 2012

Communauté SEPAmail : SMURF

SMURF est l'acronyme de Sepa Mail Universal Resource Formater.

A quoi cela sert ?

Supposons qu'un utilisateur SEPAmail, client créancier, dispose d'un logiciel ERP qui lui permet de consulter la fiche de chacun de ses clients. Pour utiliser le service RUBIS, il a besoin de pouvoir envoyer ses demandes de règlement au format RUBIS sur la prise SMILE de sa banque.
Le composant SMURF va lui permettre de générer automatiquement le document pdf au format SEPAmail qu'il peut ensuite envoyer sur la prise bancaire SEPAmail SMILE, soit directement (canal web service), soit via un client de messagerie S/Mime (canal messagerie).

Où le trouver ?

Smurf a été publié sur la plate-forme google code sous le nom de code sepamail-smurf.
La page du projet se trouve ici.

Comment le tester ?

Pour tester SMURF, le plus simple est de télécharger la dernière version exécutable ici puis de décompresser l'archive quelque part sur votre système puis de lancer Smurf.sh (pour MacOs ou GNU/Linux) ou Smurf.exe (pour WinOS).

Pour le tester depuis les sources, il faut récupérer le projet sur le gestionnaire de version de la plate-forme google, puis exécuter avec ant (par exemple) le fichier build à la racine du projet. Un environnement java 1.7+ est requis.
Remarque : la visualisation des pdf dans SMURF ne fonctionne qu'avec un environnement d'exécution sun/oracle 1.7 (incompatibilité de la visionneuse jpeg dans le projet icedtea avec openjdk, en cours d'analyse pour résolution)

A-t-on le droit de l'utiliser ?

Le logiciel a été développé dans le cadre d'une mission autour de SEPAmail en langage java sous une licence d'utilisation open source (GPLv3).
Il utilise des composants et des bibliothèques qui sont toutes sous une licence open source comme décrit dans ce fichier.
Les créanciers peuvent donc utiliser tout ou partie de SMURF sous les conditions des licences d'utilisation, notamment en respectant le droit des auteurs

Où peut-on trouver de la documentation ?

Plusieurs documents se trouvent dans l'espace google code :
  • une documentation orientée intégrateur
  • une documentation orientée développeur
  • les spécifications des différentes versions du composant

Ce composant fait-il partie du standard de SEPAmail ?

Le standard n'a pas vocation à inclure des implémentations logicielles.
Donc ce composant ne fait pas partie du standard.
Cependant, c'est une implémentation au code source ouvert et ré-utilisable, faisant référence pour la communauté des adhérents et utilisateurs de SEPAmail.

Existent-t-ils d'autres composants comme SMURF ?


Oui.
  • SMIC est un composant de conversion croisée entre les deux formats missive (xml) et pdf (guide du créancier)
  • SMOC est un composant qui constitue une enveloppe SEPAmail, l'envoie et se synchronise avec un compte IMAP