tag:blogger.com,1999:blog-13717023061282904252024-02-19T04:53:57.345+01:00SEPAmail, une messagerie sécuriséeNous souhaitons partager avec nos lecteurs nos réflexions sur SEPAmail.Manfred Sherlock OLMhttp://www.blogger.com/profile/09549165648881760487noreply@blogger.comBlogger88125tag:blogger.com,1999:blog-1371702306128290425.post-67773676741449960042016-10-21T11:00:00.000+02:002016-10-21T11:00:24.470+02:00Communauté SEPAmail : SEPA-ConvertirPatrick Louvet s'est mis à son compte pour éditer un client RUBIS pour les émetteurs de demandes de règlement (DRE) SEPAmail.<br />
Nous l'avons interrogé pour nous décrire sa solution.<br />
<br />
<h2>
Quand a été créé SEPA-CONVERTIR, dans quel contexte ?</h2>
<br />
Sepa-convertir a été créée en 2013 sous forme d'auto-entreprise pour aider les entreprises a passer le CAP du SEPA<br />
<br />
<h2>
Combien de collaborateurs, quels profils, quelles fonctions ?</h2>
<br />
Patrick travaille tout seul. Le profil requis est d'avoir une compétence bancaire,une compétence marketing et une compétence informatique.<br />
<br />
<h2>
Quels sont les principaux produits ou services développés et vendus ?</h2>
<br />
En mode, le site permet de convertir en ligne les virements , virements internationaux, FAE (ex virements commerciaux) ainsi que les Prélèvements tant à l'ex format CFONB que sous format CSV au format XML et vise les TPE avec un cout d'abonnement modique (7 € mois en illimité)<br />
<br />
Sur poste de travail, les fonctionnalités sont les même qu'en mode SAAS, augmentée d'une gestion complète d'une base mandat multi-banques et multi comptes et multi sociétés.<br />
<br />
La solution est un logiciel totalement compatible avec le standard SEPAmail multi ICQX adapté à tous les formats de banque participantes du standards.<br />
<br />
<h2>
Quels est le profil de vos clients, quelles sont vos références ?</h2>
Les clients sur internet sont des petites ou moyenne structures qui remettent en moyenne des remises tous les deux ou trois jours<br />
<br />
Les version sur poste de travail sont des clients comme AFP (groupe de maison de retraite), OUEST FRANCE (groupe de presse) , Vice rectorat de mayotte, ORSUD (cadeaux d'entreprise).<br />
<br />
<h2>
Quelles sont vos spécificités ?</h2>
<br />
Les traitements spécifiques tournant autour du SEPA avec réalisation de modules permettant des imports de fichier depuis les bases de données de l'informatique du client<br />
<br />
<h2>
Quel est votre implication dans la communauté SEPAmail ?</h2>
<br />
J'ai découvert SEPAmail en Juin 2016 et j'ai voulu favorisé le développement de ce nouveau produit en créant un logiciel qui permette l’accès au plus grand nombre de créanciers en "offrant" un produit à un coût raisonnable.<br />
<br />
<br />
<h2>
Quelle évolution pour la suite ?</h2>
<br />
Lorsque le module RUBIS SEPAMAIL sera opérationnel, je souhaite m'attaquer à la couche GEMME et DIAMOND.Manfred Sherlock OLMhttp://www.blogger.com/profile/09549165648881760487noreply@blogger.com0tag:blogger.com,1999:blog-1371702306128290425.post-10999396247790490062016-10-19T11:07:00.000+02:002016-10-18T22:46:25.301+02:00SEPAmail : AigueMarine ou la mobilité bancaire<style type="text/css">p.sdfootnote-western { margin-left: 0.3cm; margin-top: 0cm; margin-bottom: 0cm; font-family: "Arial (W1)",serif; line-height: 100%; page-break-before: auto; }p.sdfootnote-cjk { margin-left: 0.3cm; margin-top: 0cm; margin-bottom: 0cm; line-height: 100%; page-break-before: auto; }p.sdfootnote-ctl { margin-left: 0.3cm; margin-top: 0cm; margin-bottom: 0cm; line-height: 100%; page-break-before: auto; }p { margin-top: 0.2cm; margin-bottom: 0.2cm; direction: ltr; color: rgb(0, 0, 0); line-height: 100%; text-align: left; }p.western { font-family: "Tahoma",serif; font-size: 12pt; }p.cjk { font-size: 6pt; }a:link { color: rgb(0, 0, 255); }a.sdfootnoteanc { font-size: 57%; }</style>
<br />
<div class="western">
<h2>
<span style="font-weight: normal;">La mobilité bancaire, c'est quoi ?</span> </h2>
<br />
Il existe depuis 2004 un dispositif d’aide à la
mobilité bancaire, qui permet à des clients de se faire assister
par leur nouvelle banque (banque d’arrivée ou BA) pour rapatrier
les flux de virements et de prélèvements. Pour ce faire, il faut
réaliser auprès de chacun des émetteurs de flux un changement de
domiciliation bancaire. C’est ce processus de collecte des
informations clients et de transmission aux émetteurs qui a fait
l’objet d’une industrialisation/automatisation importante,
notamment par quelques acteurs (ISILIS, DOCAPOST, CMCIC) qui ont
proposé le service en marque blanche aux banques d’arrivée.<br />
</div>
<div class="western">
<h2>
<span style="font-weight: normal;">Le service change, comment ?</span></h2>
<h2>
<span style="font-weight: normal;"><br /></span></h2>
En 2014/2015, les lois Hamon et Macron (et leurs
décrets d’application) amènent de nouvelles obligations,
notamment pour la banque qui est quittée par son client (banque de départ ou BD) qui est obligée, sur
réception du mandat du client de la banque d’arrivée, de renvoyer,
soit un refus motivé, soit une acceptation assortie d’une extraction des
13 derniers mois:</div>
<ul>
<li>
<div class="western">
des opérations de prélèvements reçus récurrents (mandats
non caducs, non révoqués, créanciers absents de la liste noire,
hors prélèvements ponctuels)</div>
</li>
<li>
<div class="western">
des opérations de virements permanents émis (dossiers de
virements permanents, montant/périodicité/ bénéficiaire);</div>
</li>
<li>
<div class="western">
des formules de chèques non débitées issues
de chéquiers utilisés ou remis au client et non utilisés;</div>
</li>
<li>
<div class="western">
des opérations de virement reçus récurrents (SEPA et non
SEPA, récurrence s’entendant comme réception d’au moins 2
opérations du donneur d’ordre).</div>
</li>
</ul>
<div class="western">
En outre, ce procédé d’extraction des
opérations et d’information de la banque d’arrivée doit être
automatisé. La dématérialisation<a class="sdfootnoteanc" href="https://www.blogger.com/blogger.g?blogID=1371702306128290425#sdfootnote1sym" name="sdfootnote1anc"></a>,
elle, n’est pas mentionnée par la loi.</div>
<div class="western">
La place (Fédération Bancaire Française ou <a href="http://www.fbf.fr/" target="_blank">FBF</a>) a proposé (sans imposer) la
messagerie SEPAmail pour répondre au besoin exprimé et a précisé
les formats et règles d’échange dans deux guides produits par le
CFONB.</div>
<div class="western">
La place a aussi proposé un mécanisme impliquant
les banques des émetteurs de prélèvements et de virement (Banque d'émetteur ou BE) pour leur transmettre l’information de
changement de domiciliation bancaire.</div>
<div class="western">
Il y a deux procédés de collecte:</div>
<ul>
<li>
<div class="western">
extraction automatique<a class="sdfootnoteanc" href="https://www.blogger.com/blogger.g?blogID=1371702306128290425#sdfootnote2sym" name="sdfootnote2anc"></a>
des 13 dernières mois de 4 familles d’opération (à partir de
février 2017, obligatoire pour seulement certaines situations);</div>
</li>
</ul>
<ul>
<li>
<div class="western">
collecte assistée auprès du client
d’information supplémentaire (en œuvre depuis 2004).<a class="sdfootnoteanc" href="https://www.blogger.com/blogger.g?blogID=1371702306128290425#sdfootnote3sym" name="sdfootnote3anc"></a></div>
</li>
</ul>
<div class="western">
Il y a plusieurs possibilités d’opérer le
changement de domiciliation bancaire auprès des émetteurs de
virements et de prélèvements:</div>
<ul>
<li>
<div class="western">
information en direct de l’émetteur</div>
<ul>
<li>
<div class="western">
pour le compte du client;</div>
</li>
<li>
<div class="western">
pour le compte de la banque d’arrivée
du client;</div>
</li>
<li>
<div class="western">
pour le compte de l’émetteur;</div>
</li>
</ul>
</li>
<li>
<div class="western">
information en direct de la banque de
l’émetteur:</div>
<ul>
<li>
<div class="western">
pour le compte de la banque d’arrivée
du client;</div>
</li>
<li>
<div class="western">
pour le compte de l’émetteur;</div>
</li>
</ul>
</li>
</ul>
<div class="western">
Dans le cas général, la seule transmission de la
demande de changement de domiciliation bancaire ne suffit pas; il
faut, pour boucler le processus et déclarer traitée une demande,
récupérer le retour d’information de la demande (acceptée,
refusée, prise en compte du changement à la date donnée D, absence
de retour) puis informer le mandant du changement de domiciliation
bancaire de ce retour.<br />
<br />
<h2>
SEPAmail est cité, pourquoi ? </h2>
</div>
<div class="western">
La messagerie SEPAmail est un bon candidat pour accompagner l'automatisation du procédé requis par le législateur et encadré par la place bancaire:</div>
<ul>
<li>SEPAmail repose sur un échange pair à pair qui peut s'articuler point à point;</li>
<li>SEPAmail permet de traiter de grosses quantités de données via un mail classique (signé/chiffré) ou via un webservice;</li>
<li>SEPAmail propose un cadre commun pour des applications métiers différentes;</li>
<li>SEPAmail est nativement transporté sur internet mais peut basculer sur des réseaux privatifs si besoin.</li>
</ul>
L'application de SEPAmail dénommée AIGUE-MARINE a été conçue dans une première version par ISILIS et moi-même, puis reprise et largement modifiée par Eric Verroneau dans le cadre du Comité Français d'Organisation et de Normalisation Bancaire (<a href="http://www.cfonb.org/" target="_blank">CFONB</a>), dans une optique orientée "account management" segment iso20022 acmt) et non "cash management" (segment iso20022 camt).<br />
<br />
Les deux visions sont justes: il y a bien une vision "compte" avec le changement de domiciliation bancaire, mais il y a aussi le côté pratique des opérations à migrer qui est plus orienté Cash Management.<br />
<br />
Une autre vision aurait pu être celle proposée par SEPAmail en 2010, lors de la conception de la QXCard: un annuaire non centralisé privé/public bilatéral dans lequel chacun aurait du pouvoir publier à ses contrepartie une nouvelle fiche avec son nouvel identifiant public (le QXBAN). La correspondance QXBAN/IBAN se serait alors faite si besoin par la banque gérant l'IBAN, avec un risque très faible de corruption de l'IBAN.<br />
Une partie de cette solution "annuaire" est opérée dans le seul cadre de l'application RUBIS, mais elle n'est pas obligatoire pour fonctionner.<br />
<br />
<h2>
Y-a-t-il des alternatives à SEPAMail Aigue-Marine?</h2>
<br />
L'apparition de deux nouveaux acteurs dans le cadre de la Directive des Services de Paiement de 2015 (DSP2), à savoir les agrégateurs de compte (aisp) et les initiateurs de paiement (pisp), permettent d'entrevoir des solutions encore plus fluides pour les clients, alliant :<br />
<ol>
<li>interrogation des comptes, </li>
<li>calcul d'optimisation bancaire (montant, date de valeurs, coût des opérations, </li>
<li>initiation des paiements pour le compte d'un tiers bon marché et spécialiste de la mise à disposition de fond en temps et en heure, ce que ne proposent pas la plupart des conventions de services bancaires en 2016.</li>
</ol>
<div class="western">
<br /></div>
<div class="western">
<div class="western">
Dans ce cadre, il n'est plus besoin de traiter la mobilité
macron (banque de départ vers banque d'arrivée vers émetteur).<br />
En effet, l'agrégateur voit tous les flux et il a donc une vision
précise des émetteurs du moment d'un grand nombre de clients utilise le service.<br />
<br />
Si il est en même temps initiateur de paiement (instantané ou différé), il a les mains
libres pour proposer des optimisations de paiement, en date, en
montant, que ce soit vis à vis des banques comme des émetteurs.<br />
<br />
<br /></div>
La mobilité bancaire va donc complètement changer de visage dans les
prochaines années et ne sera qu'un des services des
agrégateurs/initiateurs de paiements, comme la mobilité postale, la
mobilité fournisseurs, la possibilité de grouper des achats et de
jouer l’affinitaire au delà de ce que l'on ose imaginer, tant pour
le chaland que pour le marchand.
</div>
Manfred Sherlock OLMhttp://www.blogger.com/profile/09549165648881760487noreply@blogger.com0tag:blogger.com,1999:blog-1371702306128290425.post-1399700055783856732016-10-17T14:12:00.002+02:002016-10-17T14:12:40.663+02:00Communauté SEPAmail : ALERIA SoftwareL'application de SEPAmail RUBIS connait ses premiers flux B2C et B2B.<br />
<a href="https://www.aleria-software.fr/" target="_blank">Aleria Software</a> fait partie des éditeurs proactifs qui croient dans l'ecosystème SEPAmail.<br />
J'ai interrogé son directeur commercial, Olivier Raingeval.<br />
<h2>
</h2>
<h2>
Quand a été créé ALERIA, dans quel contexte ?</h2>
Aleria a été créée en 2016 par Loïc Angibaud alors DSI d'une société de conseil en cash management dans le but avoué de profiter de son expérience sur les protocoles bancaires et SEPAmail pour proposer des solutions innovantes dans ces domaines.<br />
<h2>
</h2>
<h2>
Combien de collaborateurs, quels profils, quelles fonctions ?</h2>
Nous sommes actuellement en pleine expansion. Olivier Raingeval nous a rejoint en tant que Directeur Commercial et se sert de son expérience du monde bancaire pour développer nos marchés et suivre les très nombreux sujets du moment.<br />
<br />
Les profils qui nous rejoignent sont de deux types:<br />
<ul>
<li>Ingénieur & Développeur pour développer notre gamme et innover</li>
<li>Technicien support afin d'aider et former nos utilisateurs sur nos produits</li>
</ul>
<h2>
</h2>
<h2>
Quels sont les principaux produits ou services développés et vendus ?</h2>
<br />
Nous avons actuellement trois principaux produits :<br />
<br />
<ul>
<li>myRubis-myInvoice : Solution SaaS de facturation et paiements dématérialisés basée sur la norme SEPAmail Rubis et compatible avec toutes les banques de la place.</li>
<li>IBANSecure : Solution SaaS de fiabilisation de coordonnées bancaires fondée sur la norme SEPAmail Diamond et utilisable en WebService.</li>
<li>connectMyBanks : Outil de télétransmission bancaire EBICS sécurisé et innovant de part son niveau d'automatisation et son ergonomie.</li>
</ul>
<h2>
</h2>
<h2>
Quels est le profil de vos clients, quelles sont vos références ?</h2>
Nos clients vont des PME aux grands comptes. <br />
Les deux premiers créanciers SEPAmail Rubis du Crédit Agricole sont équipés avec myRubis.<br />
<br />
Nous avons également émis les premiers flux en production sur la place.<br />
<br />
De plus, cette solution nous a valu le label FinTech décerné par le pôle de compétitivité mondial Finance Innovation en Juin 2016.<br />
Enfin, nous sommes en relation étroite avec une grande banque française et un grand éditeur de logiciel comptable pour, respectivement, IBANSecure et connectMyBanks.<br />
<h2>
</h2>
<h2>
Quelles sont vos spécificités ?</h2>
Nous mettons en avant notre dynamisme et notre esprit startup. Le but étant de nous démarquer par la qualité de nos logiciels et leurs caractères innovants. Nos clients sont d’ailleurs impliqués dans leurs améliorations !<br />
<br />
<h2>
</h2>
<h2>
Quel est votre lien à SEPAmail ?</h2>
Nous avons établis des pilotes avec 3 banques françaises afin de valider le fonctionnement intra et interbancaire de SEPAmail Rubis. Nous avons aussi assisté le Crédit Agricole dans la mise en place de ses premiers créanciers.<br />
<br />
Nous serons également présent à la prochaine réunion du comité SEPAmail Rubis.<br />
<br />
<h2>
</h2>
<h2>
Quelle est votre implication dans la communauté SEPAmail ? Quelle évolution pour la suite ?</h2>
Nous comptons nous impliquer au plus près des initiatives locales comme à St Etienne concernant SEPAmail Rubis mais également développer Diamond qui attire beaucoup d'entreprises de part son application immédiate. Manfred Sherlock OLMhttp://www.blogger.com/profile/09549165648881760487noreply@blogger.com0tag:blogger.com,1999:blog-1371702306128290425.post-47553298040850976092015-12-03T15:36:00.002+01:002015-12-03T15:38:51.382+01:00SEPAmail, c'est de l'internet, pas du paiementJe suis étonné de lire ici ou là que SEPAmail est un moyen de paiement.<br />
<br />
Certes, l'application RUBIS de SEPAmail, appelée aussi "règlement via SEPAmail" permet d'articuler une demande de règlement et un paiement, le plus souvent par virement.<br />
RUBIS est donc une application idéale pour rendre possible le paiement de proximité à la main de celui qui doit payer.Mais ce n'est pas un paiement a proprement dit, c'est un échange d'information avant le paiement, rendant possible le paiement électronique de proximité à la main du payeur.<br />
<br />
<br />
C'est bien cette application qui pourrait être utilisée et mise en avant par l'état pour le paiement de la TVA, du "reste à charge" dans le cadre du tiers payant, ou encore du remplacement du TIP... au lieu de nous emmener vers le tout prélèvement pour tous (entreprises, particuliers, institutions).<br />
<br />
Le prélèvement apparaît la bonne solution à la plupart des grosses administrations et grosses entreprises mais il induit un désengagement supplémentaire du payeur, absolument non nécessaire et, à mon sens contre-productif pour la confiance entre les parties. <br />
<br />
Regardons de plus près le besoin d'une entreprise par rapport à la TVA, la saisie comptable, la transmission de facture...<br />
<br />
Ce besoin repose dans le fond sur de l'échange d'information authentifié avant un paiement, pour éviter la fraude ou le flou qui permet les délais de paiement à rallonge par le payeur.<br />
Il semble à l'évidence utile de dématérialiser et d'automatiser cet échange d'information.<br />
<br />
Le problème, c'est que c'est du mode "message" dont on a besoin, pas du mode "action".<br />
L'extranet est donc une mauvaise solution, comme l'articulation du paiement par celui qui veut être payé et qui est assez gros pour l'imposer.<br />
<br />
Il faut s'adapter à celui qui prépare, déclare et paie, et donc travaille pour la collecte de l'état. Il faut s'adapter à l'humain (un échange de message structuré) et non à l'action automatique à la main du plus gros, qui produit nécessairement à terme un absurde non contrôlé.<br />
<br />
C'est dans cette optique qu'un besoin de messagerie sécurisée en amont des paiement (mobilité bancaire, articulation d'un paiement, transmission d'un mandat, vérification d'identité bancaire, transmission de facture, justificatif d'un versement) a été décelé en 2008 puis mise en oeuvre dans le cadre d'un réseau de banques dès 2012.<br />
<br />
Un réseau de banques, c'est la garantie :<br />
<ul>
<li>d'un réseau quart de confiance, comme celui des médecins, des avocats, des notaires, le socle véritable de tout réseau de confiance,</li>
<li>de la confidentialité liée au secret bancaire,</li>
<li>d'une capacité à repérer les déviances de l'automatisation par le double contrôle comptable, le contrôle réglementaire, les lois anti-blanchiement et financement d'activités illégales.</li>
<li>de prix au plus juste, par la mise en concurrence possible</li>
<li>d'une articulation facile avec le monde des paiements, sans préjuger du moyen de paiement utilisé</li>
</ul>
<b><u>En conclusion</u></b><br />
<br />
SEPAmail est une bonne idée qui devrait être un peu plus regardée par tous ceux qui ne confondent pas <u>modernisation de l'état</u> avec "prélèvement de tous" et "extranets centralisés pour tous"...<br />
<br />
<br />
<br />
<br />Manfred Sherlock OLMhttp://www.blogger.com/profile/09549165648881760487noreply@blogger.com1tag:blogger.com,1999:blog-1371702306128290425.post-18534685858795755332015-06-10T09:00:00.000+02:002015-06-10T09:00:04.194+02:00Communauté SEPAmail : SkilleaNous continuons notre tour des membres de la communauté SEPAmail avec la société Skillea, dont Matthieu Dambrin, le fondateur, fut l'un des premiers à poster des commentaires sur la documentation de SEPAmail.<br />
<br />
Depuis, nous avons proposé à Matthieu de nous rejoindre parmi les rédacteurs du blog.<br />
<br />
Nous avons interrogé Matthieu, qui nous présente sa société et les compétences développées dans ce court billet.<br />
<br />
<br />
<b>Skillea</b> est une société de conseil créée en 2011 par un ex-salarié d’un grand groupe bancaire français.<br />
<div class="">
<b>Son créneau ?</b> Accompagner ses clients dans leurs projets informatiques, en maîtrise d’ouvrage ou maîtrise d’œuvre.</div>
<div class="">
<b>Ses prestations ?</b> Conseil, formation, gestion de projet, développement (forfait)</div>
<div class="">
<b>Ses spécialités ?</b> SEPAmail, les paiements, la gestion de projet et les méthodes associées.</div>
<div class="">
<b>Ses clients ?</b> Les banques, les éditeurs du monde bancaire et les entreprises.</div>
<div class="">
<b>Ses références ?</b> BNP Paribas, Natixis, Banques Populaires, Thomson Reuters.</div>
<div class="">
<br class="" /></div>
<div class="">
Skillea a rencontré SEPAmail en 2011, au cours d’une prestation pour Natixis. Ce fut le début d’une longue et fidèle histoire...</div>
<div class="">
Après
avoir accompagné Natixis sur la mise en œuvre des expérimentations
GEMME, DIAMOND et RUBIS, Skillea a prolongé (et prolonge toujours
aujourd’hui !) son partenariat avec le Groupe BPCE sur les projets de
commercialisation de RUBIS et des autres services SEPAmail.</div>
<div class="">
</div>
<div class="">
Fort
de son expérience, Skillea se positionne aujourd’hui comme un véritable
expert SEPAmail, capable d’accompagner ses clients à toutes les étapes
de leur projet. Et depuis peu, pour compléter son offre, Skillea propose
également des formations destinées aux banques, éditeurs et
entreprises.</div>
<div class="">
Pour en savoir plus, rendez-vous sur <a class="" href="http://www.skillea.fr/">www.skillea.fr</a></div>
<div class="">
</div>
Manfred Sherlock OLMhttp://www.blogger.com/profile/09549165648881760487noreply@blogger.com0tag:blogger.com,1999:blog-1371702306128290425.post-12260331366630159342015-06-05T09:00:00.000+02:002015-06-08T11:19:13.952+02:00Communauté SEPAmail : AzzanaDe nombreux acteurs sont arrivés depuis 2010 au sein de la communauté SEPAmail. Azzana Consulting fait partie de ceux qui s'intéressent à SEPAmail depuis fin 2013. J'ai rencontré et interrogé Lionel Vincke, le directeur.<br />
<br />
<h2>
Quand a été créé AZZANA, dans quel contexte ?</h2>
<div>
Azzana a été créée en 2011 à Bruxelles, et s'est établie en France en 2013, notamment pour accompagner une clientèle française de plus en plus nombreuse. Le but d'Azzana est de partager, en France, des pratiques "internationales" ou plus "anglo saxonnes" sur les moyens de paiement et la gestion de trésorerie, telles que rencontrées dans le Benelux.<br />
<br /></div>
<div>
<div bgcolor="#FFFFFF">
<h2>
Combien de collaborateurs comptez-vous, quels sont leurs profils, quelles sont leurs fonctions ?</h2>
<h2>
</h2>
</div>
</div>
<div>
Azzana compte 30 personnes, dont une majorité de consultants seniors, tous avec un domaine d'expertise donné (SEPA, cash pooling, monétique, risque de change, relation bancaire, ...). et tous avec un background particulier. <br />
<br />
<div bgcolor="#FFFFFF">
<h2>
Quels sont les principaux produits ou services développés et vendus ?</h2>
</div>
</div>
<div>
Notre credo est de proposer des solutions sur mesure.<br />
Nous n'avons donc pas l'approche d'un éditeur ou d'une SSII classique.<br />
Nous écoutons chaque client avant de lui faire une offre unique, répondant précisément à sa problématique et son contexte.</div>
<div>
Quant aux domaines que nous couvrons, il s'agit de tous ceux liés à la
trésorerie d'entreprise ou aux moyens de paiement, que vous retrouverez
sur <a href="http://azzana-consulting.com/" rel="nofollow">notre site web</a> (relation bancaire, moyens de paiement, gestion de la
liquidité et des risques, logiciels de trésorerie).</div>
<div>
<div bgcolor="#FFFFFF">
<h2>
Quels est le profil de vos clients, quelles sont vos références ?</h2>
</div>
</div>
<div bgcolor="#FFFFFF">
Nos clients sont des banques de la place et, côté entreprise, des entreprises de taille intermédiaire ou grande entreprise (CAC40, SBF120,...)<br />
<br /></div>
<div bgcolor="#FFFFFF">
</div>
<div bgcolor="#FFFFFF">
<h2>
Quelles sont vos spécificités ?</h2>
</div>
<div>
Nous mettons en avant 4 valeurs:</div>
<div>
<ul>
<li>la passion ; tous nos consultants sont réellement passionnés par notre domaine,</li>
<li>le sur mesure</li>
<li>le partage des connaissances (entre nous mais plus largement dans notre communauté)</li>
<li>une approche à long terme (<span style="color: #222222; font-family: arial,sans-serif; font-size: x-small; line-height: normal;">tant avec nos collaborateurs qu'avec nos clients</span>).</li>
</ul>
</div>
<div>
Un autre facteur différenciant pour la concurrence est notre origine et position internationale.</div>
<br />
<h2>
Quel est votre lien à SEPAmail ?</h2>
<div>
Nous avons suivi Zoomit en Belgique depuis des années, iDEAL aux pays-bas et SEPAmail en France également.</div>
<div>
Depuis notre arrivée en France, nous somme surpris du faible niveau d'automatisation et de dématérialisation des moyens de paiement (chèques, TIP, peu de référence de lettrage dans le virement,...).</div>
<div>
</div>
<div>
Nous voyons en SEPAmail un moyen pour la France d'être force de proposition innovante sur ces sujets. SEPAmail est aussi une voie pour les banques de se positionner en fournisseur de services (ou, en tout cas, comme l'un des maillons dans la chaine) alors qu'elles sont de plus en plus désintermédiées.</div>
<div>
<br /></div>
<div>
<div bgcolor="#FFFFFF">
<h2>
Quel est votre implication dans la communauté SEPAmail ? Quelle évolution pour la suite ?</h2>
</div>
</div>
<div>
Nous construisons, avec nos clients entreprises et banquiers, des "use cases" SEPAmail, c'est à dire des façons d'utiliser cet outil pour répondre à différents besoin.</div>
<div>
A chaque rencontre client, nous découvrons une nouvelle utilisation pour SEPAmail.</div>
<div>
Nous souhaitons continuer sur cette voie, en faisant découvrir les possibilités offertes par cet outil à tous et en imaginant des solutions à valeur ajoutée pour chacun et en accompagnant nos clients dans la mise en œuvre de ces solutions.</div>
Manfred Sherlock OLMhttp://www.blogger.com/profile/09549165648881760487noreply@blogger.com0tag:blogger.com,1999:blog-1371702306128290425.post-78569944235757699332015-04-01T13:14:00.000+02:002015-04-06T13:07:57.169+02:007 an déjà : un premier avril à 13h14SEPAmail est né il y a 7 ans à 13h14 un 1<sup>er</sup> avril 2008.<br />
Le concept n'avait pas ce nom, évidemment, mais il était déjà bien construit dans la tête de Cyril.<br />
<br />
Voilà comment il me l'explique : <br />
En amont et en aval du paiement, il y a de nombreux échanges d'information qui qualifient le paiement.<br />
Il y a besoin de confiance dans ces échanges; le mail n'est pas sécurisé, le courrier postal simple un peu lent, le fax en désuétude, la lettre recommandée avec accusé de réception souffre du prix et d'une image de "procédurier"...<br />
<br />
Comment sécuriser un email d'information en utilisant le plan d'adressage de SEPA, IBAN@BIC ?<br />
<br />
L'idée fit son chemin et Cyril trouva quelques fonds pour transformer son premier schéma en une spécification, livrable auquel j'ai participé.<br />
<br />
Comme je suis assez porté sur les standards d'interopérabilité, j'ai essayé de ne pas ré-inventer la roue et lui ai proposé quelques principes venant de l'email en essayant de faire aussi bien que la lettre recommandée avec accusé de réception.<br />
<br />
Ainsi est né le premier document proposant une messagerie sécurisée par les banques pour le compte de leur client.<br />
<br />
Depuis, grâce à Cyril, le concept a trouvé un cadre d'application, qui, s'il n'est pas dévoyé par l'informatique et industrialisé correctement, permet de structurer et sécuriser de nombreux dialogues entre chacune des entités économiques : ménage, entreprise, association, administration.<br />
<br />
Je fais confiance à l'industrie bancaire pour en faire bon usage et nous devrions tous profiter, dès 2015, des applications de SEPAmail : paiement à la main du client, avis d'ordre de règlement, mail sécurisé, fiabilisation d'identifiant bancaire (RIB, IBAN, PAN), message de mobilité bancaire, obligation de vigilance, paiement par carte avec dépassement de plafond, transfert entre porte-monnaie électronique, mise au coffre-fort électronique, garantie autour du paiement, etc...<br />
<br />
Les applications sont nombreuses et dépassent le cadre bancaire; je vois bien un cerfa-mail en lieu et place de nos extranets d'états de plus en plus compliqués et centralisés, un sepamail spécial telco pour sécuriser les nombreux échanges qu'ils font transiter, un sepamail pour les avocats, les comptables etc...<br />
<br />
SEPAmail a l'âge de sa première dentition; gageons qu'il atteindra sa maturité dans la prochaine septaine.<br />
<br />
<br />
<br />Manfred Sherlock OLMhttp://www.blogger.com/profile/09549165648881760487noreply@blogger.com0tag:blogger.com,1999:blog-1371702306128290425.post-14167235891224189622014-11-19T16:11:00.003+01:002014-11-19T16:18:37.407+01:00L'application JADE, le retourBien que la <a href="http://documentation.sepamail.org/wiki/Standards:SMIRK_APP1301,_l%27application_JADE" target="_blank">SMIRK</a> de l'application JADE ait été rédigée et publiée depuis longtemps déjà, elle n'a pas encore été "officiellement" validée, et n'est à ma connaissance implémentée nulle part.<br />
<br />
Il me semble toutefois intéressant de revenir sur le contenu de cette application -- telle qu'elle est définie dans cette SMIRK du moins -- sous forme d'une série de questions-réponses.<br />
<h3>
JADE, qu'est-ce que c'est ?</h3>
JADE est avant tout un avis d'ordre de paiement. Nous sommes donc dans le cas où une entité, dénommée <b>donneur d'ordre</b>, doit verser une somme d'argent à une autre entité, dénommée <b>bénéficiaire</b>. Plutôt que d'envoyer simplement un ordre de virement à sa banque (sous forme d'un message <i>pain.001</i> par exemple), le donneur d'ordre peut choisir de lui envoyer un message <i>CreditAdvise</i> de l'application JADE.<br />
<br />
Il se passe alors deux choses :<br />
<ul>
<li>dans tous les cas, le bénéficiaire est avisé du paiement, il dispose des références exactes et éventuellement des documents associés ; son accord peut être sollicité.</li>
<li>selon les accords entre le donneur d'ordre et sa banque, et le type de message JADE envoyé, le paiement peut être déclenché automatiquement</li>
</ul>
Les premiers travaux sur JADE ont été menés en commun avec des factors, mais la complexité des informations devant être acheminées par les factors, ainsi que la multiplicité des intervenants, nous a conduits à préférer définir une application JADE simple, facile à comprendre et utilisable par tous.<br />
<h3>
Dans le cas simple, comment ça marche ?</h3>
Dans le premier cas d'usage, que l'on pourrait qualifier de "basique", le donneur d'ordre n'attend pas de réponse du bénéficiaire : l'employeur virant un salaire, la CAF versant une prestation... n'ont pas besoin de réponse extra-bancaire.<br />
<br />
Il n'y a alors qu'un seul message transmis : <i>CreditAdvise</i>. Celui-ci peut être transmis à trois moments :<br />
<ol>
<li>après le paiement : "je vous ai versé, tel jour, telle somme sous telle référence".</li>
<li>simultanément au paiement : "je vous verse ce jour ..."</li>
<li>avant le paiement : "je vous verserai, tel jour ..."</li>
</ol>
Dans les cas 2 et 3, des accords entre le donneur d'ordre et sa banque peuvent déclencher l'émission automatique du paiement, conformément au message <i>pain.001</i> inclus dans le CreditAdvise. Pour le cas 1, il serait imaginable que la banque du donneur d'ordre réalise d'abord le virement, et ne transmette le message JADE qu'ultérieurement, mais ceci implique un format de communication entre la banque et son client (contenu + canal) qui dépasse le cadre de SEPAmail.<br />
<h3>
Et maintenant, si j'ai besoin d'un accord du bénéficiaire ?</h3>
Ici, le cas d'usage est différent : le donneur d'ordre veut absolument un accord du bénéficiaire avant de lui verser les sommes, par exemple :<br />
<ul>
<li>solde de tout compte moyennant signature du reçu</li>
<li>allocation nécessitant une attestation sur l'honneur</li>
</ul>
Dans ce cas, les deux messages JADE sont mis en jeu :<br />
<ul>
<li><i>CreditAdvise</i> indique les éléments du règlement (date, montant...), fournit des pièces justificatives, et indique la forme de l'accord (voir ci-dessous)</li>
<li><i>CreditReply</i> fournit la réponse du bénéficiaire</li>
</ul>
Lorsque le bénéficiaire donne une réponse positive, en d'autres termes accepte l'accord qui lui est proposé, le virement doit être automatiquement déclenché, sans qu'une nouvelle intervention du donneur d'ordre soit nécessaire. ATTENTION : ceci dépend évidemment des accords entre le donneur d'ordre et sa banque ! Il y a donc un point à prendre en compte lors de la construction d'une offre commerciale autour de ce service : pour que JADE avec réponse ait du sens, et présente une vraie plus-value pour le bénéficiaire, celui-ci doit pouvoir être certain que son accord entraînera bien le versement des sommes proposées.<br />
<h3>
Quand les sommes sont-elles versées ?</h3>
Dans le cas simple, les sommes sont versées selon la date figurant dans le <i>pain.001</i>, si l'accord entre le donneur d'ordre et sa banque le prévoit bien sûr.<br />
<br />
Dans le cas à deux messages maintenant, le sujet devient un peu délicat et mérite une explication détaillée : le message <i>CreditAdvise</i> comporte deux dates :<br />
<ol>
<li>dans le<i> pain.001</i>, la date d'exécution souhaitée par le donneur d'ordre</li>
<li>hors <i>pain.001</i>, la date limite d'accord du bénéficiaire</li>
</ol>
Les règles suivantes doivent alors s'appliquer :<br />
<ul>
<li>Si l'accord du bénéficiaire est reçu avant la date 1, le paiement interviendra à la date 1.</li>
<li>S'il est reçu après la date 1 mais avant la date 2, le paiement interviendra au plus vite</li>
<li>S'il est reçu après la date 2, aucun paiement ne doit être déclenché. Le processus est alors considéré comme abandonné, le donneur d'ordre ayant alors pu lancer une autre procédure.</li>
</ul>
<h3>
Quel accord peut-on demander au bénéficiaire ?</h3>
L'accord demandé par le donneur d'ordre peut actuellement revêtir deux formes:<br />
<ol>
<li>une simple authentification -- dans ce cas, le fait que le bénéficiaire se soit authentifié pour accepter le virement est considéré comme suffisant</li>
<li>un scellement -- dans ce cas, le bénéficiaire doit disposer d'une signature électronique lui permettant de signer effectivement un texte ou un document.</li>
</ol>
Le donneur d'ordre choisit la forme de l'accord demandé. Si la banque du destinataire ne supporte pas cette forme (typiquement, elle ne fournit pas de certificats donc la forme 2 est impossible), elle répondra par un <i>CreditReply</i> négatif dit "technique". S'il le souhaite, le donneur d'ordre pourra alors envoyer un nouveau message<i> CreditAdvise</i> en demandant une autre forme d'accord.<br />
<h3>
Avez-vous quelque chose à ajouter pour votre défense ?</h3>
Un cas d'usage particulier n'a pas été abordé ici : celui d'un paiement sur QXBAN. Il sera traité dans un article séparé.<br />
<br />
En aucun cas les messages de JADE ne représentent une garantie de paiement. Il reste de la responsabilité du bénéficiaire de s'assurer que les sommes lui sont bien parvenues, tout litige restant strictement entre le donneur d'ordre et lui.<br />
<br />
JADE est aujourd'hui définie pour les virements, mais tout a été prévu pour qu'elle puisse s'articuler sur d'autres formes de paiements : chèque ou lettre-chèque, carte bancaire. Les champs sont en place pour ceci, il ne manque réellement que l'articulation du paiement -- et un besoin métier avéré.<br />
<br />
Le but de JADE n'est pas d'acheminer des documents. Toutefois, elle en transporte, donc il est possible de l'utiliser pour envoyer des bulletins de salaire par exemple. Pour que ceci réponde aux obligations légales, il faut bien sûr que les documents transportés répondent aux normes en vigueur (PDF signés, par exemple). Ceci doit être considéré comme un effet de bord de l'application, dont l'usage est malgré tout à éviter.<br />
<h3>
Et en conclusion ?</h3>
JADE est aujourd'hui une application simple, facile à expliquer, facile à mettre en œuvre. De plus, tous les formats du message <i>pain.001</i> sont supportés, ce qui permet de l'inclure dans tous les SI existants sans modification profonde.<br />
<br />
En revanche, elle ne répond pas forcément aux cas d'usage les plus complexes. Comme pour toues les autres applications SEPAmail, l'apparition de nouveaux cas complexes justifieront certainement l'évolution de JADE vers une version 2.Anonymoushttp://www.blogger.com/profile/07188765293360333679noreply@blogger.com0tag:blogger.com,1999:blog-1371702306128290425.post-84469932812145269252014-10-06T08:29:00.002+02:002014-10-06T08:29:38.707+02:00Revue de presse Août-SeptembreVoici quelques articles sur SEPAmail publiés en aout et septembre 2014 :<br />
<ul>
<li><a href="http://www.citizencan.fr/fr/nos-services/vos-sujets-d-actualite/sepamail-facilitez-vos-echanges-avec-citizen-can">SEPAmail, facilitez vos échanges avec Citizen Can</a></li>
<li><a href="http://www.fntc.org/fr/actualites/fntc/item/113-presentation-a-la-fntc-de-sepamail-et-e-defact-de-cm-cic/">eDefact, la dématérialisation de facture proposée par le CMCIC au moyen de SEPAmail</a></li>
<li>Le règlement SEPAmail (RUBIS) est présenté par UTSIT et CMCIC un peu partout en France, par exemple à Aix, à Lyon</li>
<li><a href="http://www.axway.fr/events/event/s-minaire-strat-gie-digitale-et-sepamail">Axway présente au mois d'octobre son service autour de SEPAmail</a></li>
<li><a href="http://www.caisse-epargne.fr/logement-social/sepa-mail.aspx">La caisse d'épargne présente son service SEPAmail Creancier</a></li>
</ul>
<br />
Côté nouvelles interne à la communauté SEPAmail, le comité norme étudie et commente l'application <a href="http://documentation.sepamail.org/wiki/JADE">JADE</a>, autour de l'avis d'ordre de réglement et fait quelques retouches sur l'application DIAMOND, autour de la fiabilisation d'identifiants bancaires (notamment l'IBAN)<br />
<br />Manfred Sherlock OLMhttp://www.blogger.com/profile/09549165648881760487noreply@blogger.com0tag:blogger.com,1999:blog-1371702306128290425.post-15041753121879440512014-08-12T07:30:00.001+02:002014-08-12T07:30:46.791+02:00Revue de presse Juin-Juillet 2014Quelques articles cet été sur SEPAmail, annonçant la mise en service pour les clients. <br />
<ul>
<li>25/07/2014 Les échos <a href="http://www.lesechos.fr/journal20140725/lec2_finance_et_marches/0203663450589-une-norme-propice-aux-solutions-bancaires-de-place-1027670.php">Une norme propice aux solutions bancaires de place</a></li>
<li>12/06/2014 GFI <a href="http://www.enews.gfi.fr/?p=1273">Comment supprimer la fraude de signature au contrat</a></li>
<li>12/05/2014 Syrtals <a href="http://www.syrtals.com/fr/Avenir_de_Sepamail">le règlement de facture, l'avenir de SEPAmail</a></li>
<li>28/07/2014 Banques en lignes <a href="http://www.banques-en-ligne.fr/actualites/detail.php?idactu=1597/izly-nouveau-porte-monnaie-electronique-des-campus">Izly transporte des flux SEPAmail</a></li>
<li>juillet 2014 Google Play <a href="https://play.google.com/store/apps/details?id=com.bnpp.peps">Mon portefeuille BNP Paribas, première application android permettant le règlement via SEPAmail</a></li>
</ul>
Bon été <br />
<br />Manfred Sherlock OLMhttp://www.blogger.com/profile/09549165648881760487noreply@blogger.com0tag:blogger.com,1999:blog-1371702306128290425.post-6291210971264911872014-04-28T09:00:00.000+02:002014-04-28T12:55:29.987+02:00Se former à SEPAmailJe reçois assez souvent des questions autour de "comment se former à SEPAmail ?".<br />
<br />
Je propose alors d'intervenir dans les entreprises qui le souhaitent avec une offre variant de 1/2 journée à 3 jours et sur des sujets variés :<br />
<ul>
<li><a href="http://formation.decibi.fr/pub/presentationFormationSepamail2014_enjeux.pdf">SEPAmail, les enjeux</a> (1/2 journée)</li>
<li><a href="http://formation.decibi.fr/pub/presentationFormationSepamail2014_editeur.pdf">SEPAmail pour les éditeurs</a> (2 jours)</li>
<li><a href="http://formation.decibi.fr/pub/presentationFormationSepamail2014_rubis.pdf">revue détaillée de RUBIS@SEPAmail</a> (3 jours)</li>
<li>rédiger une SMIRK (1/2 journée)</li>
</ul>
J'utilise le logiciel open source <a href="http://scenari-platform.org/projects/scenari/fr/pres/co/">scenari</a> (et sa chaine éditoriale <a href="http://scenari-platform.org/projects/opale/fr/pres/co/">Opale</a>) pour produire un livret et une présentation cohérente et évolutive.<br />
<br />
Je ne connais pas encore d'autre offre de formation dédiée à SEPAmail, même si quelques formations SEPA parlent de SEPAmail.<br />
Cela est du, il me semble, au nombre de sachants encore peu nombreux.<br />
<br />
Mais gageons que 2014/2015 verra de nombreuses offres éclorent, offres que nous pourrions relayer dans ce blog.<br />
<br />
En attendant, je vous propose en ligne une <a href="http://formation.decibi.fr/pub/sepamail20minutes/co/module_formation_rapide.html">mini-formation intitulée "SEPAmail en 20 minutes"</a>, inspirée de mon <a href="http://sepamail.blogspot.fr/2013/01/sepamail-explique-mes-proches.html">billet de janvier 2013</a>.Manfred Sherlock OLMhttp://www.blogger.com/profile/09549165648881760487noreply@blogger.com0tag:blogger.com,1999:blog-1371702306128290425.post-9769656236151082342014-04-10T09:00:00.000+02:002014-04-10T09:14:44.136+02:00FAQ n°6 <h4>
Q6.1 : Renvoi, doit-on changer la date ?</h4>
<br />
La question peut se poser ainsi : si je renvoie une missive comme cela est possible, est-ce que je change la date ?<br />
<br />
Une réponse rapide est : NON, on ne change que l'ordre quand on renvoie une missive, en l'incrémentant de un.<br />
<br />
Voici une explication détaillée de cette réponse rapide :<br />
<br />
On trouve la règle à appliquer dans la <a href="http://documentation.sepamail.eu/wiki/Standards:IG_missive">directive d'implémentation de la missive</a> : <br />
""If the missive needs to be resent, with the same contents, this number MUST be incremented by one each time it is resent. All other missive fields, including MsvId and SndDtTm, must be unchanged."<br />
<br />
Quel est le sens de cette règle ? <br />
<br />
Pour le comprendre, il faut une petite explication :<br />
<br />
<ul>
<li>Le message SEPAmail, c'est le signifiant échangé entre les utilisateurs</li>
<li>La missive SEPAmail, c'est l'enveloppe de messagerie du réseau privé SEPAmail</li>
<li>L'enveloppe SEPAmail, c'est l'enveloppe de sécurité en cas de transport (mode flash ou canonique) sur un réseau public.</li>
</ul>
Le protocole SEPAmail, c'est un protocole qui permet :<br />
<ul>
<li>cette double encapsulation,</li>
<li>une authentification des parties par les relais,</li>
<li>un accusé de réception par l'adhérent pour le compte de son utilisateur, quelque soit le cas d'usage (l'application, le nombre d'acteurs...)</li>
<li>une forme de "garantie" pour un utilisateur émetteur que son envoi sera acquittée (renvoi, escalade, acquittement obligatoire 24/24 7/7 par l'adhérent récepteur selon la priorité)</li>
</ul>
<u>Renvoyer une missive, ce n'est pas obligatoire</u> mais une possibilité, offerte si le système émetteur chez l'adhérent considère que l'acquittement des envois précédent pour la même missive n'est pas arrivé. <br />
<br />
Par contre, <u>acquitter une missive, c'est obligatoire</u>.<br />
<br />
Quand l'émetteur renvoie une missive, voilà ce qu'il dit à son récepteur de missive : "je vous ai déjà émis une missive pour telle personne à telle heure. Comme mon système n'a pas encore enregistré d'accusé réception et que j'ai besoin de cet accusé de réception, je vous renvoie, comme j'en ai la possibilité, la même missive. Pour vous signifier que c'est un renvoi, j'incrémente de 1 l'ordre de la missive. Merci de m'acquitter, comme vous en êtes obligé en tant qu'adhérent, cette missive et les précédentes, si vous les avez reçues."<br />
<br />
Quand on raisonne sur ces sujets, il faut absolument ne pas vouloir connaître le statut précis ou le comportement précis de son interlocuteur; mais appliquer le protocole de son point de vue.<br />
<br />
Celui qui spécifie le composant qui envoie et reçoit les missives des parties, doit, bien entendu imaginer tous les cas, dont celui pour lequel la contrepartie essaie de frauder ou pour lequel la contrepartie a un système défaillant. Des systèmes de régulation de ces comportements sont présents dans SEPAmail et dépasse le simple cadre de l'acquittement des missives. Pour mémoire, ce sont l'engagement contractuel des adhérents, le procédé d'escalade, la surveillance du réseau par SEPAmail.eu.<br />
<br />
<h4>
Q6.2 : Pourquoi y a-t-il Acquittement et Aknowledgement dans les types de missives ?</h4>
<br />
Les schémas XML autour de SEPAmail sont écrits en anglais, pour pouvoir être lus par tous. Les types de missives étaient écrits en français, ce qui ne posait pas de problème pour Service, Nominal et SMAPI qui sont équivalents en anglais mais ce n'est pas le cas pour Acquittement.<br />
<br />
En 2010, le committer a donc accepté ma demande de transformer Acquittement en Aknowledgment, tout en conservant Acquittement à des fins de rétro-comptabilité. Les deux termes sont donc équivalents, comme annoncé dans la <a href="http://documentation.sepamail.eu/wiki/Standards:IG_missive#Missive_Identification">directive d'implémentation de la missive</a>.<br />
<br />
La règle implicite est donc la suivante : <br />
<br />
Tout composant mettant en œuvre le standard SEPAmail DOIT accepter en réception les types Acquittement et Aknowledgment.<br />
<br />
Mon conseil est de rajouter :<br />
<br />
Tout composant mettant en oeuvre le standard SEPAmail DEVRAIT utiliser en émission le type Aknowledgment.<br />
<br />
<h4>
Q6.3 Où peut-on trouver des exemples de flux ?</h4>
<br />
Cette question revient souvent; elle est tout à fait licite.<br />
<br />
J'ai créé en 2013 un espace communautaire pour partager nos exemples.<br />
<br />
Il se trouve sur la <a href="http://code.google.com/p/sepamail-smite/">plateforme google code et a pour petit nom SMITE</a> : SEPAmail I want TEst !<br />
<br />
L'espace pourrait être augmenté de nos exemples.<br />
<br />
Le problème de chacun est de savoir si son exemple est bien conforme à:<br />
<br />
<ul>
<li> les schémas XML</li>
<li> les directives d'implémentation</li>
<li> les règles opérationnelles entre les adhérents </li>
</ul>
<br />
Pour le premier point, c'est facile puisque tous les outils existent et les schémas sont publiés et stables.<br />
<br />
Pour le deuxième point, les directives d'implémentation sont publiées mais certaines règles semblent être encore porteuses d’ambiguïté. La démarche est donc de demander au comitter SEPAmail via l'espace communautaire son avis, soit en direct, soit par la fonctionnalité discuter du wiki.<br />
<br />
Pour le troisième point, c'est plus compliqué car ces règles ne sont pas publiées. Pour les avoir consultées, je peux vous assurer qu'il n'y a peu de règles qui touchent aux flux messages ou missive dedans (la taille maximale des flux acceptée pour le moment) mais plus des règles pour connecter entre elles les infrastructures et piloter la mise en production après expérimentation.<br />
<br />
Je propose à tous ceux qui souhaitent partager leurs exemples de les aider dans leur démarche. N'hésitez pas à me contacter.<br />
<br />
Ces pages sont également ouvertes pour ceux qui désirent partager un billet sur ces sujets.<br />
<br />
Je souhaite que nous ne faisions pas comme d'autres communautés à écrire les règles sans partager des exemples qui facilitent leur compréhension.<br />
<br />
<br />
<h4>
Q6.4 SEPAmail et RUBIS, c'est la même chose ?</h4>
<br />
SEPAmail est une messagerie sécurisée fournie par des adhérents SEPAmail à leurs clients ou leurs agents, ceux que l'on appelle des utilisateurs SEPAmail.<br />
<br />
RUBIS, comme GEMME, JADE, DIAMOND, sont des applications de SEPAmail qui répondent à un besoin précis des utilisateurs.<br />
<br />
Donc, SEPAmail et RUBIS ne sont pas la même chose. Les utilisateurs ne devraient pas entendre parler de RUBIS puisque les cinq adhérents actuels se sont entendus sur la notion de "règlement (via) SEPAmail" pour parler de RUBIS. RUBIS reste un nom de code interne à la communauté SEPAmail.<br />
<br />
<h4>
Q6.5 Quelle est la limite en taille d'un message, d'une missive, d'une enveloppe ?</h4>
<br />
C'est l'une des exceptions à ce que j'ai dit plus haut. La limite a été fixée dans les règles opérationnelles et elle est de 200kos pour l'enveloppe SEPAmail, c'est à dire trop peu. En effet, comme un fichier pdf (par exemple une facture) est encapsulé dans un message SEPAmail, puis une missive SEPAmail et enfin une enveloppe SEPAmail.<br />
<br />
<h4>
Q6.6 SEPAmail, c'est une norme, un standard, un protocole ?</h4>
<br />
SEPAmail est un protocole, puisqu'il précise un ensemble de règles pour des acteurs qui cherchent à organiser entre eux une fonctionnalité.<br />
<br />
Les français distinguent la norme du standard : la norme est un texte normalisé par un organisme de normalisation reconnue (ou officiel). Le standard est un texte utilisé par une communauté.<br />
<br />
Si on reconnait SEPAmail.eu comme un organisme de normalisation officiel, alors SEPAmail est une norme. Ce n'est à mon avis pas encore le cas. <br />
<br />
Il existe aujourd'hui une communauté de fait autour de SEPAmail, c'est donc bien un standard de fait.<br />
<br />
<br />
<h4>
Q6.7 Quel est le statut de votre blog et de vos réponses ? Puis-je m'y fier ?</h4>
<br />
Notre blog (nous sommes pour le moment deux rédacteurs) se veut un point de rassemblement de ceux qui participent à la communauté SEPAmail (les lecteurs) et de ceux qui veulent partager des points de vues et des informations sur SEPAmail (les rédacteurs, les interviewés...).<br />
<br />
Le blog n'est pas le blog officiel de SEPAmail.eu.<br />
<br />
Les éclairages amenés n'engagent donc pas SEPAmail.eu et n'engagent, d'une manière générale, que leur auteur.<br />
<br />
Il n'y a pas de comité de validation des billets rédigés.<br />
<br />
Comme le blog est lu et (de temps en temps) commenté, vous pouvez, à mon sens, vous fier à ce qui est écrit et vous forger une opinion sur son contenu.<br />
<br />
Les deux auteurs sont :<br />
<br />
<ul>
<li>Olivier Jousselin, comitter du standard de 2009 à 2013, rédacteur de la SMIRK Jade en 2013</li>
<li>Manfred Olm, co-auteur du premier draft en 2008, de quelques SMIRKs en 2011 et 2012, missionné de 2010 à 2012 pour réaliser le contrôle de cohérence entre le standard et les expérimentations ayant été réalisées.</li>
</ul>
<br />
Nous partageons ainsi avec vous le plaisir que vous avez, nous l'espérons.Manfred Sherlock OLMhttp://www.blogger.com/profile/09549165648881760487noreply@blogger.com0tag:blogger.com,1999:blog-1371702306128290425.post-23390078204412063452014-04-08T11:00:00.000+02:002014-04-08T11:08:37.644+02:00FAQ n°5<h4>
Q5.1 : RUBIS : Combien de décimales sont autorisées dans le montant à payer ?</h4>
<br />
Le montant se trouve, dans la requête RUBIS (message <a href="http://documentation.sepamail.eu/wiki/Standards_1206:IG_Rubis_ActivationRequest">ActivationRequest</a>), dans le fragment xml Amt (xpath <span style="font-size: xx-small;">/sem:ActivationRequest/sem:ReqCompl/sem:Request/pain013:PmtInf/pain013:CdtTrfTx/pain013:Amt/pain013:InstdAmt</span>).<br />
Selon le shema XML du pain013, le montant est un nombre décimal positif qui peut avoir 5 décimales au plus.<br />
Selon la directive d'implémentation RUBIS du message ActivationRequest, le montant ne peut pas être nul.<br />
Le montant minimum est donc 0.00001 et un message avec ce montant valide bien le schéma XML du message.<br />
<br />
Ce nombre de décimales permet d'effectuer la conversion entres les différentes devises sans ambigüité sur la deuxième décimale. C'est la règle générale qui a été adoptée en Europe au moment du passage des monnaies nationales à l'euro. Elle parait donc adaptée à l'univers SEPAmail et à la zone SEPA en particulier.<br />
<br />
L'EPC a précisé pour le pacs.008 puis le pain.001 une règle plus contraignante qui peut se résumer à "Format rule: The fractional part has a maximum of two digits". On retrouve cette règle par exemple pour l'échange de pain.001 entre une banque et son client (référence IG SCT Bank-Client v7.0, Instructed Amount AT-04). <br />
<br />
Certains guides du CFONB reprennent la règle ISO (5 décimales) ou la règle EPC (2 décimales).<br />
<br />
La question est donc bien licite pour RUBIS.<br />
<br />
Concernant une demande de règlement, quel est le sens de payer un montant avec 5 décimales ?<br />
Dans la plupart des usages proposés par RUBIS, cela n'a aucun sens, donc une règle d'au plus 2 décimales aurait du sens.<br />
D'un autre côté, Rubis ne propose que la demande de règlement et non le règlement lui-même, qui est articulé par la banque de débiteur selon le contrat qu'elle a avec le débiteur. Les cas d'usage qui ont été relevés lors du passage à l'euro, peuvent toujours donc se dérouler avec RUBIS.<br />
<br />
Il parait raisonnable donc, pour pouvoir s'articuler avec un règlement par virement et être compatible avec les règles EPC d'implémenter à minima les règles suivantes :<br />
<ul>
<li>un créancier DEVRAIT utiliser des montants avec au plus deux décimales s'il n'a pas besoin de conversion</li>
<li>l'adhérent du débiteur DOIT arrondir à deux décimales selon les règles d'usage des arrondis dans le monde bancaire tout montant émanant d'une demande de règlement avec plus de deux décimales avant d'initier un règlement par virement (pacs.008 ou pain.001)</li>
</ul>
<br />
<br />
<br />
<h4>
Q5.2 : Comment doit réagir un adhérent si une missive n'est pas adressée à un de ces clients ou l'émetteur n'est pas chez l'adhérent qui envoie la missive ?</h4>
Le cas est simple et se présente de temps à autre.<br />
L'adhérent émetteur de la missive envoie à un adhérent une enveloppe SEPAmail correcte contenant une missive dont :<br />
<ul>
<li>l'expéditeur (balise Snd) n'est pas un QXBAN de l'émetteur (mauvais BIC)</li>
<li>le destinataire (balise Rcv) n'est pas un QXBAN du récepteur (mauvais BIC)</li>
</ul>
La missive peut donc être acquittée puisqu'elle est valide et lue correctement.<br />
<br />
En version 1206, le relai entre les adhérents n'est pas autorisé.<br />
<ul>
<li><u>Conséquence 1 :</u> l'adhérent qui reçoit la missive NE DOIT PAS la relayer.</li>
<li><u>Conséquence 2 :</u> L'adhérent qui a envoyé la missive NE DEVAIT PAS la relayer également.</li>
</ul>
<br />
L'acquittement est donc négatif (NAK).<br />
Le code retour peut être utilisé; c'est <b>511</b> pour le premier cas (mauvais Snd) et <b>512</b> pour le second (mauvais Rcv)<br />
<br />
<h4>
Q5.3 : peut-on envoyer une missive d'ordre 0 ?</h4>
Le schéma XML de la missive (<a href="http://xsd.sepamail.eu/1206/sepamail_missive.xsd">voir ici</a>) décrit une balise MsvOrd comme un entier.<br />
Par contre, la <a href="http://documentation.sepamail.eu/wiki/Standards:IG_missive">directive d'implémentation de la missive</a> donne explicitement l'usage de cette balise : "Usage Rule : this field must be set to 1 (one) at first sending of a given missive. If the missive needs to be resent, with the same contents, this number MUST be incremented by one each time it is resent. All other missive fields, including MsvId and SndDtTm, must be unchanged.<br />
Usage Rule: for an acknowledgement missive, the order number will be the one of the missive it acknowledges."<br />
<br />
On commence à un et on incrémente de un à chaque renvoi.<br />
On acquite une missive avec le même ordre que la missive nominale acquittée.<br />
<br />
Que faire alors si on reçoit une missive nominale d'ordre 0 ?<br />
On acquitte négativement (NAK) avec un code retour 584 ( Order number error).<br />
<br />
Mais que faire pour l'ordre de la missive d'acquittement puisqu'il est dit : "Usage Rule: for an acknowledgement missive, the order number will be the one of the missive it acknowledges." ?<br />
<br />
Quitte à être non conforme à la directive, je préconise un ordre à 1 et non 0.<br />
<br />
<br />
De même, si l'ordre n'est pas un entier positif (par exemple un entier négatif), j'acquitterai négativement (NAK) avec un code retour 581 (XML syntax error, non conforming to schema) et un ordre 1.<br />
<br />
<h4>
Q5.4 est-on obligé de renvoyer une missive ?</h4>
L’émetteur d'une missive qui n'a pas reçu à temps un acquittement peut renvoyer une missive, selon la <a href="http://documentation.sepamail.eu/wiki/Standards:IG_missive">directive d'implémentation de la missive</a> et la <a href="http://documentation.sepamail.eu/wiki/Standards:SMIRK_MIS1202,_la_missive_dans_les_%C3%A9changes_interbancaires#Renvoi_d.27une_missive">SMIRK Missive</a>.<br />
La première dit "If the missive needs to be resent, with the same contents, this number MUST be incremented by one each time it is resent".<br />
La seconde dit "Un système de renvoi d'une missive peut être implémenté.[...] l'émetteur de toute missive nominale dont l'acquittement n'est pas
constaté dans un temps supérieur aux minima définis pour la priorité de
la missive peut renvoyer la missive avec un numéro d'ordre incrémenté ;
il s'interdit de le faire avant ; il n'est pas obligé de le faire"<br />
<br />
L’émetteur peut donc renvoyer une missive mais il n'est pas obligé de le faire; il n'est même pas obligé d'implémenter le système donc de proposer le service à son client. <br />
<br />Manfred Sherlock OLMhttp://www.blogger.com/profile/09549165648881760487noreply@blogger.com0tag:blogger.com,1999:blog-1371702306128290425.post-64062534208057303412014-03-24T10:00:00.000+01:002014-03-24T12:16:25.416+01:00SEPAmail et le W3CEn ce début de semaine se tient une conférence du W3C à Paris autour du futur du paiement sur le Web.<br />
<br />
Le W3C, c'est le consortium de quelques 380 entreprises, fondées en 1994 par Tim Berners-Lee, avec le leit-motiv « un seul web partout et pour tous ».<br />
Toujours piloté de Tim Berners-Lee (inventeur de HTML et HTTP) présenté souvent comme le papa du Web, le W3C est chargé de promouvoir les protocoles qui permettent une application mondiale partagée sur le réseau internet, notamment : HTML, XHTML, XML, RDF, SPARQL, CSS, PNG, SVG, SOAP... Bref, plein de protocoles utilisés par SEPAmail. <br />
<br />
La problématique, et l'agenda complet de cet évènement se trouve <a href="http://www.w3.org/2013/10/payments/agenda.html">ici</a>.<br />
<br />
<br />
Plusieurs acteurs de la communauté SEPAmail ont présenté des "prises de position" sur le sujet.<br />
<br />
L'une de ces prises de positions expose le besoin de ré-équilibrage de la relation entre le chaland (pour faire vite et imprécis, l'acheteur) et le marchand dans le paiement en général et celui à distance sur le web en particulier.<br />
<br />
Dans les pistes avancées pour ré-équilibrer par la standardisation, il y a, entre autres, SEPAmail, mais aussi des technologies dont nous avons parlées dans nos billets.<br />
<br />
Je vous livre la <a href="https://drive.google.com/file/d/0B8u_uGoZBUH2UHVjNm9Mb2JKQVE/edit?usp=sharing">version française au format pdf</a>.<br />
<br />
Jeffrey Jaffe, l'actuel directeur du W3C (CEO), est à Paris, et
devrait rencontrer aujourd'hui certains acteurs de SEPAmail. Pour quelques uns des artisans du protocole SEPAmail, c'est un peu le graal... <br />
<br />
<br />
<br />
<br />
<br />Manfred Sherlock OLMhttp://www.blogger.com/profile/09549165648881760487noreply@blogger.com1tag:blogger.com,1999:blog-1371702306128290425.post-40202775956037978352014-03-19T11:55:00.002+01:002014-03-28T10:40:06.874+01:00SEPAmail : communiqué de presse sur le lancement du service SEPAmailLundi 17 mars, les adhérents SEPAmail ont communiqué sur le succès de l’expérimentation SEPAmail en 2013 et sur le lancement du service pour leur client en 2014.<br />
Ce communiqué a été repris cette semaine dans de nombreux articles:<br />
<br />
<ul>
<li>Les échos (17/03/2014) <a href="http://www.lesechos.fr/entreprises-secteurs/finance-marches/actu/0203378996885-le-paiement-de-facture-en-un-clic-dans-les-starting-blocks-en-france-657565.php?xtor=RSS-2130">Le paiement de facture en un « clic » dans les starting-blocks en France</a></li>
<li>Les échos (18/03/2014) <a href="http://www.lesechos.fr/entreprises-secteurs/finance-marches/actu/0203379045251-le-paiement-de-facture-en-ligne-sera-une-realite-a-l-automne-2014-657739.php">Le paiement de facture en ligne sera une réalité à l'automne 2014 </a></li>
<li>01 informatique (18/03/2014) <a href="http://www.01net.com/editorial/616172/bientot-reglez-vos-factures-en-ligne-et-en-un-seul-clic/">Bientôt, réglez vos factures en ligne et en un seul clic</a></li>
<li>L'écho républicain (17/03/2014) <a href="http://www.lechorepublicain.fr/france-monde/actualites/economie-politique/eco-finances/2014/03/17/les-banques-francaises-pour-le-paiement-de-factures-en-un-clic_1920270.html">Les banques françaises pour le paiement de factures "en un clic"</a> </li>
<li>La tribune de l'assurance (17/03/2014) <a href="http://www.tribune-assurance.fr/cms/p_126547/sepamail-un-regroupement-pour-le-reglement-de-factures">SEPAmail : Un regroupement pour le règlement de factures</a></li>
<li>Chalenge (17/03/2014) <a href="http://www.challenges.fr/entreprise/20140317.CHA1637/les-banques-francaises-veulent-developper-le-paiement-en-un-clic.html">Les banques françaises veulent développer le paiement "en un clic"</a></li>
<li>CBanque (18/03/2014) <a href="http://www.cbanque.com/actu/44032/banques-francaises-le-paiement-electronique-des-factures-disponible-courant-2014">Banques françaises : le paiement électronique des factures disponible courant 2014</a></li>
<li>Cercle Finance (18/03/2014) <a href="http://www.cerclefinance.com/default.asp?pub=valactu&isin=FR0000131104&art=380047#">BNP Paribas: lance un service de règlement de factures.</a></li>
<li>Journal du Net (18/03/2014) <a href="http://www.journaldunet.com/ebusiness/le-net/paiement-en-ligne-six-banques-preparent-le-lancement-d-un-tip-numerise-0314.shtml">Paiement en ligne : six banques préparent le lancement d'un TIP numérisé</a></li>
<li>Boursier.com (18/03/2014)<a href="http://argent.boursier.com/quotidien/actualites/payer-ses-factures-en-un-clic-sera-bientot-une-realite-1368.html"> Payer ses factures en un clic sera bientôt une réalité</a></li>
<li>EduBourse (17/03/2014) <a href="http://www.edubourse.com/finance/actualites.php?actu=83695">BNP Paribas et SEPAmail</a></li>
<li>Blog de Jean-Marc Morandini (18/03/2014)<a href="http://www.jeanmarcmorandini.com/article-318263-les-banques-francaises-veulent-developper-le-paiement-de-factures-en-ligne.html"> Les banques françaises veulent développer le paiement de factures en ligne </a></li>
<li>ITespresso.com (19/03/2014) <a href="http://www.itespresso.fr/sepamail-eu-5-reseaux-bancaires-dematerialisent-reglement-factures-73846.html">Sepamail.eu : 5 réseaux bancaires dématérialisent les règlement de factures </a></li>
<li>Usine digitale (19/03/2014) <a href="http://www.usine-digitale.fr/article/six-banques-francaises-s-unisssent-pour-lancer-sepamail-eu-un-service-de-paiement-des-factures-en-ligne.N249538">Six banques françaises s’unisssent pour lancer Sepamail.eu, un service de paiement des factures en ligne</a></li>
<li>Le monéticien (18/03/2014) SepaMail – Paiement des Factures en Ligne</li>
<li>Banque-en-ligne.fr (18/03/2014) <a href="http://www.banques-en-ligne.fr/actualites/detail.php?idactu=1398/sepamail-un-clic-pour-les-factures-en-ligne">SEPAmail, un clic pour les factures en ligne </a></li>
<li>GoodInfo.eu (18/03/2014) <a href="http://www.goodinfo.eu/les-5-plus-grandes-banques-francaises-se-regroupent-dans-sepamail/1832/">Les cinq plus grandes banques se regroupent dans SEPAmail</a></li>
<li>Liberation (17/03/2014) <a href="http://www.liberation.fr/economie/2014/03/17/les-banques-francaises-pour-le-paiement-de-factures-en-un-clic_987810">Les banques françaises pour le paiement de factures «en un clic» </a></li>
<li>La tribune (18/03/2014) <a href="http://bourse.latribune.fr/actualites/toutes-les-actualites/0/bnp-paribas-lance-un-service-de-reglement-de-factures-71009b9377df36e9.html">BNP Paribas: lance un service de règlement de factures.</a></li>
<li>blog migration SEPA (18/03/2014) <a href="http://migration-sepa.blogspot.fr/2014/03/sepamail.html">SEPAmail</a></li>
<li>Responis (24/03/2014) <a href="http://www.responis.com/actualites-rachat-credits,banque,banques-optent-paiement-electronique-factures-20140325.html">Les banques optent pour le paiement électronique des factures </a></li>
<li><br /></li>
</ul>
<br />
<ul>
</ul>
<br />
<ul>
</ul>
Manfred Sherlock OLMhttp://www.blogger.com/profile/09549165648881760487noreply@blogger.com0tag:blogger.com,1999:blog-1371702306128290425.post-77156306293630879462014-03-13T10:30:00.000+01:002014-05-28T12:16:53.657+02:00Codes de retour du protocole SEPAmail au niveau de la couche MissiveLe protocole SEPAmail liste sur <a href="http://documentation.sepamail.eu/wiki/Standards_1206:IG_missive_returnCodes" target="_blank">cette page (standard en version 1206)</a> des codes en trois chiffres pour qualifier/préciser la nature de l'<a href="http://sepamail.blogspot.fr/2012/06/vocabulaire-sepamail-la-missive.html">acquittement d'une missive</a>.<br />
<br />
Nous allons, dans ce billet, successivement :<br />
<ul>
<li>reprendre la définition générale de ces codes</li>
<li>regarder l'usage de chacun des codes</li>
<li>répondre à quelques questions fréquemment posées</li>
</ul>
<h4>
Définition des codes d'acquittement</h4>
Les codes d'acquittement forment une nomenclature à chiffres [0-9]{3} sur trois positions :<br />
<ul>
<li>la classe (position 1)</li>
<li>le sujet (position 2)</li>
<li>le détail (position 3)</li>
</ul>
Cette nomenclature est similaire aux codes de statut du retour des protocoles HTTP, SMTP etc...<br />
<br />
La classe peut être :<br />
<ul>
<li><i>classe 1 = non utilisé pour le moment, information</i></li>
<li>classe 2 = succès</li>
<li><i>classe 3 = non utilisé pour le moment</i></li>
<li>classe 4 = erreur transitoire</li>
<li>classe 5 = erreur permanente</li>
</ul>
<br />
<h4>
Inventaire des codes proposés par le standard </h4>
La liste des codes d'acquittement proposés peut se schématiser en carte mentale :<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgQDHuT1j4ozw6fGkCB5h0KsBZ9O9-SGUvz1DAi3OIrUOSVyFoCR52M7B9Ke_l2ueJ0rZQp0aQFdt8QgB3-I4tr5aUij7gvR0gE1euQKzuKbefcA_54NkAkDZFt2xcqyhjk1ALit9I-kjU/s1600/returnCodesSepamail.png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgQDHuT1j4ozw6fGkCB5h0KsBZ9O9-SGUvz1DAi3OIrUOSVyFoCR52M7B9Ke_l2ueJ0rZQp0aQFdt8QgB3-I4tr5aUij7gvR0gE1euQKzuKbefcA_54NkAkDZFt2xcqyhjk1ALit9I-kjU/s1600/returnCodesSepamail.png" height="170" width="400" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Liste des codes retour proposés par la version 1206</td></tr>
</tbody></table>
<br />
Nous allons voir que de nombreux codes ne servent pas.<br />
<br />
Ils ont (malheureusement) pour seul effet de perdre ceux qui veulent comprendre le protocole.<br />
<br />
Ils sont résiduels aux expérimentations passées (et des besoins ponctuels de développeurs) et n'ont pas vocation à rester dans le standard, maintenant que l'industrialisation est en cours et les expérimentations finies.<br />
<br />
<br />
<b><u>Sujet 1 : les addresses</u></b><br />
<br />
<br />
Ce sujet permet d'acquitter une missive nominale sur les <a href="http://documentation.sepamail.eu/wiki/Standards:IG_missive#Missive_header" target="_blank">champs de l'entête</a> de missive A.5.1 (balise Snd) et A.5.4 (balise Rcv) exclusivement.<br />
<br />
<br />
<u>5.1.1 Unknown sender</u><br />
<br />
L'expéditeur de la missive, comme défini par la balise A.5.1 (Snd, balises BIC et|ou IBAN) n'est pas connu par le récepteur. Ce code est répondu en complément d'un acquittement de type NAK. Le récepteur se pose la question du BIC de l’émetteur (référentiel commun) ou de la forme de l'IBAN émis, qui est le plus généralement un <a href="http://sepamail.blogspot.fr/2012/07/vocabulaire-sepamail-le-qxban.html">QXBAN</a>.<br />
<br />
<br />
<u>5.1.2 Unknown receiver</u><br />
<br />
Le destinataire de la missive, comme défini par la balise A.5.4 (Rcv, balises BIC, IBAN, BBAN, PAN, RIS2D) n'est pas connu par le récepteur. Cela peut concerner le BIC (référentiel commun) ou un identifiant bancaire du récepteur qui n'est pas connu par le récepteur.<br />
<br />
<br />
<u>5.1.3 Receiver known but out of SEPAmail scheme or ecosystem.</u><br />
<br />
Le destinataire de la missive, comme défini par la balise A.5.4 (Rcv, balises BIC, IBAN, BBAN, PAN, RIS2D) est connu par le récepteur mais ne reçoit pas de missives SEPAmail sur cet ecosystème.<br />
Ce code sert pour préciser à l'expéditeur que ce destinataire existe mais qu'il ne reçoit pas les missives SEPAmail. Il est donc inutile d'utiliser SEPAmail avec ce destinataire pour le moment, et ce, quelque soit l'application de SEPAmail et l'expéditeur.<br />
Ce code ne sert donc pas pour refuser l'attache d'un expéditeur précis ou pour une application de SEPAmail précise.<br />
<br />
<br />
<u>2.1.9 Receiver known, missive forwarded</u><br />
<br />
C'est le code le plus utilisé, car c'est le seul code de succès de la liste utilisable avec un acquitement positif (ACK).<br />
<br />
<br />
<u><b>Sujet 2 : la boite aux lettres</b></u><br />
<br />
<br />
Ce sujet est ambigu car il adresse la couche échange d'enveloppe SEPAmail et non la structure de la missive.<br />
<br />
<br />
Il est historique à l'expérimentation : lors du passage du mode canonique au mode flash (web services), les implémenteurs de l'expérimentation ont eu besoin de ces codes retours natifs au protocole d'échange SMTP, d'où ces codes concernant les adresses mails de l'enveloppe SMTP/S-MIME et la longeur des messages autorisés, au sens message SMTP et non message SEPAmail.<br />
<br />
<br />
Mon conseil est de ne pas utiliser ce sujet dans l'acquittement d'une missive et de bien réfléchir à l'implémentation naturelle de l'échange d'enveloppe SEPAmail, quelque soit le type de contenu transporté.<br />
<br />
<br />
<u><b>Sujet 3 : les systèmes</b></u><br />
<br />
<br />
<br />
Ce sujet traite des erreurs "dites" système, c'est à dire relevant de l'infrastructure connectée.<br />
<br />
<br />
<u>N.3.1 File system full</u><br />
<br />
Ce code (431 ou 531) ne devrait pas être utilisé en acquittement de missive entre deux adhérents SEPAmail. Il n'adresse pas le contenu de la missive mais l'échange d'enveloppes. Il y a donc d'autres couches protocolaires pour décrire ce statut. <br />
<br />
<br />
<u>N.3.2 Inaccessible server</u><br />
<br />
Ce code (432 ou 532) ne devrait pas être utilisé en acquittement de missive entre deux adhérents SEPAmail. Il n'adresse pas le contenu de la missive mais l'échange d'enveloppes. Il y a donc d'autres couches protocolaires pour décrire ce statut. <br />
<br />
<br />
<u>4.3.3 Sending date+time incorrect, and outside of the margin. (Missive has not been handled).</u><br />
<br />
Ce code retour (433 ou 533) permet de traiter une incohérence d'<a href="http://documentation.sepamail.eu/wiki/Horodatage_des_missives">horodatage de la missive</a>, champs A.5.2 (balise SndDtTm) ne permettant pas d'acquitter la missive.<br />
Si la missive peut être acquittée positivement, selon les règles de réception définies dans la directive d'implémentation , alors le bon code retour est 219 avec une précision dans le champs A.6.7 (balise RtgWarn/Code à la valeur BAD_TIME) et non un code 433 ou 533. Il n'y a donc pas de code retour possible 233, comme indiqué par la mention "Missive has not been handled".<br />
<br />
<br />
<u>5.3.3 Sending date+time incorrect, and outside of the margin. (Missive has not been handled).</u><br />
<br />
Je ne vois pas de sens à ce code retour. Si quelqu'un voit un tel cas, Je suis preneur en commentaire d'un cas d'usage.<br />
<br />
<br />
<u><b>Sujet 4 Le débiteur</b></u><br />
<br />
<br />
<br />
Ce sujet est une erreur de compréhension du modèle en couche proposé par SEPAmail ainsi qu'une erreur de compréhension de la notion d'application.<br />
Il est dédié à l'application de SEPAmail RUBIS.<br />
<br />
<br />
Je suis certain qu'il ne devrait pas être utilisé.<br />
<br />
<br />
Le code 541 devrait plutôt être un code 512 ou 513.<br />
Le code 249 serait un code 219. <br />
La notion de compte de test n'a pas de sens SEPAmail et elle relève d'une confusion avec l'articulation monétique pendant l'expérimentation.<br />
<br />
<br />
<b><u>Sujet 5 La sécurité et la cryptographie</u></b><br />
<br />
<br />
<br />
Ce sujet est important pour SEPAmail; il concerne la sécurité en général et la cryptographie en particulier, telle qu'elle est utilisée dans l'enveloppe SEPAmail ou dans la missive SEPAmail. <br />
La cryptographie utilisée pour les connexions sécurisée des protocole HTTP, SMTP ou autres, n'est donc pas concernée par ces codes d'acquittement <br />
<br />
<u>5.7.2 Impossible to decrypt (key1 or key2). In fact, since the decryption of the S-MIME envelope cannot be processed, the embedded missive cannot be read and acknowledged. Thus, the proper behaviour in this case will be avoiding any response to the sender.</u><br />
<br />
Ce code n'a pas de sens au niveau missive et ne permet pas d'acquitter dans les conditions du protocole SEPAmail. Il ne peut donc pas être utilisé.<br />
<br />
<br />
<u>5.7.3 Unsupported algorithm or security function</u><br />
<br />
Ce code est utilisé quand un algorithme ou une fonction de sécurité non autorisé par le protocole SEPAmail sont utilisés pour l'enveloppe SEPAmail.<br />
Il est naturel, par exemple, si sha1 est utilisé alors que la directive d'implémentation de la cryptographie exige a minima sha256, d'acquitter toute missive enveloppée à l'aide de sha1 avec un tel code. <br />
<br />
<br />
<u>5.7.4 Integrity error</u><br />
<br />
Ce code est utilisé s'il y a une erreur d'intégrité dans l'utilisation des fonctions de sécurité. Cela peut être une somme de contrôle non intègre, une clé périmée, une signature lue, mais non référencée, une incohérence entre l'adresse mail utilisée par SMIME et l'adresse utilisé dans l'entête SMTP ou l'échange SMTP.<br />
<br />
<br />
<u><b>Sujet 8 Contenu</b></u><br />
<br />
<br />
<br />
Ce sujet traite de l'analyse du contenu de la seule missive, avec les quelques adhérences résiduelles aux couches message et enveloppe.<br />
<br />
<br />
<u>5.8.1 XML syntax error, non conforming to schema</u><br />
<br />
Ce code est utilisé quand une missive n'est pas conforme au schéma XML <a href="http://xsd.sepamail.eu/current/">sepamail_missive.xsd</a>.<br />
<br />
<br />
<u>5.8.2 Missive contents incoherent</u><br />
<br />
Ce code est utilisé quand une missive est conforme au schéma XML mais n'est pas conforme à la directive d'implémentation de la missive dans le cadre de son utilisation.<br />
C'est le code d'erreur utilisé quand une missive de type SMAPI ou de service est utilisé entre deux adhérents SEPAmail.<br />
<br />
<br />
<u>5.8.3 Invalid missive identifier</u><br />
<br />
Ce code est spécifique à l'identifiant de la missive, notamment si celui-ci est invalide comme doublon ou ne respecte pas la <a href="http://documentation.sepamail.eu/wiki/Standards:IG_missive#Missive_Identification">règle de génération de cet identifiant</a>, règle que j'ai commentée dans un <a href="http://sepamail.blogspot.fr/2014/03/faq-n4-autour-de-quelques-regles.html">précédent billet</a>.<br />
<br />
<br />
<u>5.8.4 Order number error</u><br />
<br />
Ce code est utilisé quand le champ A.3 (balise MsvOrd) n'est pas conforme à la règle d'usage. <br />
<br />
<br />
<u>5.8.5 Version not supported</u><br />
<br />
Ce code est utilisé si la version utilisée de la missive SEPAmail n'est pas mise en œuvre.<br />
<br />
<br />
<u>5.8.6 Corrupted contents or virus detected. In fact, since the detection of a corrupted content may be prior to the extraction of the embedded missive due to infrastructure constraints, this missive may not be acknowledged to the sender.</u><br />
<br />
Ce code fait l'objet d'une ambiguité portée par la protection de type pare-feu applicative des infrastructures qui ne respectent pas, la plupart du temps, le modèle en couche de la famille TCP/IP, afin de mieux protéger le système d'information. Ces systèmes ne répondent pas correctement sur les couches impactées, afin de ne pas donner lieu à des dénis de service.<br />
<br />
Voici des cas d'usage qui pourraient utiliser ce code :<br />
<ul>
<li>utilisation d'un <a href="http://documentation.sepamail.eu/wiki/Standards:IG_General_rules#Acceptable_characters">caractère UTF8 non autorisé</a> par SEPAmail</li>
<li>contenu des champs binaires (CDATA) suspect après passage d'un anti-virus</li>
<li>somme de contrôle non cohérente avec le contenu</li>
</ul>
<h4>
</h4>
<h4>
FAQ sur les codes d'acquittement </h4>
<h4>
</h4>
<u>Peut-on renvoyer un code retour ne contenant qu'une partie de l'information, par exemple un code de classe 5 sans sujet ni détail ?</u><br />
<br />
Rien n'interdit de spécifier seulement la classe, par exemple 2 ou 4 dans préciser le sujet et le détail d'un code d'acquittement.<br />
Le code d'acquittement n'est pas obligatoire.<br />
Seul l'est le statut de l'acquittement, (balise AcqSta)<br />
<br />
<u>Pourquoi ne pas supprimer les codes d'acquittement obsolètes ?</u><br />
<br />
Bonne question. Cela devrait être fait après la fin de l'expérimentation.<br />
<br />
Lors des expérimentations et avant le passage en conformité des différentes plateformes des adhérents, il a fallu composer avec différentes version logicielles des implémentations et laisser les codes d'acquittement, notamment ceux liés à RUBIS. <br />
<br />
<u>Peut-on inventer des nouveaux codes ? </u><br />
<br />
Pour votre usage interne, j'imagine que oui. <br />
<br />
Je conseille de les proposer à la communauté si vous souhaitez partager leur interprétation avec d'autres acteurs SEPAmail. <br />
<u><br />
Comment déclarer SEPAmail à la CNIL si un code d'acquittement donne de l'information sur mon client ? </u><br />
<br />
Il est difficile de répondre de façon générique à cette question. <br />
<br />
La plupart des codes proposés sont généraux. <br />
<br />
Dans une messagerie, il y a toujours une information transportée et bouclée... donc il y aura de l'information sur l'expéditeur et le destinataire partagée avec les 4 acteurs mis en jeu. <br />
<br />
L'intérêt de SEPAmail est que cette relation à 4 est couverte par des contrats clairs entre chaque partie : le contrat adhérent-utilisateur et le contrat d'adhésion SEPAmail. <br />
<br />
Il ne faut pas non plus confondre la couche SEPAmail et les applications de SEPAmail, comme RUBIS ou GEMME, qui devraient se déclarer séparément. <br />
<br />
Consulter la CNIL ou votre CIL (correspondant informatique et liberté) me paraît un bon préalable pour déclarer. <br />
<u><br />
A quoi sert le champ description de l'acquittement ? </u><br />
<br />
Ce champ sert à mettre une information permettant à l'émetteur de la missive nominale d'analyser plus finement le pourquoi d'un code retour. <br />
<br />
Il est libre et doit servir la messagerie sans desservir le client final. <br />
<br />
Il est dédié à une analyse humaine et non automate. <br />
<br />
<br />
<br />
<u>Comment peut-on acquitter plusieurs fois une missive nominale ? Si c'est le cas, comment savoir quand le processus d'émission peut-être considéré comme terminé ?</u><br />
<br />
La possibilité d’acquitter une missive en plusieurs fois est évoqué dans la <a href="http://documentation.sepamail.eu/wiki/Standards:SMIRK_MIS1202,_la_missive_dans_les_%C3%A9changes_interbancaires#L.27acquittement_d.27une_missive">SMIRK MIS1202</a> et clairement dans la directive d'implémentation de la missive, en donnant un <a href="http://documentation.sepamail.eu/wiki/Standards:IG_missive#Use_of_the_acknowledgement_missive">exemple d'acquittement multiple</a>, qui utilise de plus un code 249, code que je proscris un peu plus haut.<br />
<br />
Cet acquittement multiple provient d'une demande de pouvoir relier SEPAmail à une chaine de traitement bancaire batch pour RUBIS... là encore, il y a confusion entre les applications de SEPAmail (structurant des dialogues de messages) et la messagerie SEPAmail (mécanisme de routage, d'adressage, d'authentification des partie, de sécurité du transport).<br />
<br />
L'acquittement multiple pose aussi une problématique claire de finalisation du processus d'émission et l'implémentation de la fin du processus dépend de l'interprétation des temps de réponse pour acquitter... Est-ce un temps de réponse pour le premier acquittement ou pour le dernier ?<br />
<br />
Selon ma compréhension du protocole, l'expérience de l'implémentation, des différents usages de ce protocole,<b> le système d'acquittement devrait être simplifié en proposant clairement que les statuts ACK et NAK soient des statuts finaux (sans possibilité pour le récepteur d'acquitter de nouveau ensuite).</b><br />
<br />
Le système de renvoi sert pour l'émetteur à dire "alors, vous me répondez ?"... Certains récepteurs désirent dire : "j'ai reçu mais je n'ai pas encore traité, donc pas besoin de renvoyer."<br />
<br />
Quelqu'un m'a un jour dit qu'on ne pouvait pas vraiment distinguer si la missive n'était pas arrivée ou si le récepteur n'avait pas encore acquitté.<br />
<br />
Ce n'est pas vrai dans l'absolu et vrai dans la pratique de certains systèmes d'information.<br />
<br />
Dans l'absolu, le protocole d'échange SMTP (et par analogie d'implémentation pour HTTP+SOAP) permet bien de savoir si le système d'information du récepteur a reçu le paquet d'information... un certain nombre de codes retour sont bien prévus et implémenté par toutes les applications MTA, quand elles ne sont pas bridées par un pare-feu applicatif.<br />
<br />
Dans la pratique, les système d'information ne sont pas parfaits et leur exploitation peut perdre des messages, et ce la, pour toute sorte de raison.<br />
<br />
La proposition d'ajouter un statut d'attente (WAIT) ne résoudra pas le problème de fond. Il faut que l'acquittement soit simple à mettre en œuvre sur la couche missive, ne se confonde pas avec la couche message et applicative de la messagerie SEPAmail.<br />
<br />
Il faudrait donc (et cela sera à mon avis forcément le cas dans la version industrielle dès qu'il y aura de gros flux) que les adhérents de SEPAmail, qui mette en œuvre le réseau privé SEPAmail, s'engage à acquitter une seule fois dans les temps de la priorité de la missive.<br />
Les mécanismes de renvoi et d'escalade sont mis en œuvre pour garantir cette qualité de service. Je milite donc rester simple sans présumer des systèmes d'information mettant en œuvre le protocole SEPAmail.<br />
<br />Manfred Sherlock OLMhttp://www.blogger.com/profile/09549165648881760487noreply@blogger.com0tag:blogger.com,1999:blog-1371702306128290425.post-3366205131658046912014-03-07T09:00:00.000+01:002014-03-07T09:00:13.515+01:00FAQ n°4 : Autour de quelques règles d'implémentation SEPAmailIl n'y a pas (encore) d'implémentation de référence du protocole SEPAmail. Il n'y a pas non plus de cas d'usage et d'exemples de flux partagés par la communauté. J'ai ouvert un espace pour cela, mais il n'y a pas encore de soumission importante. Pour ceux qui veulent partager, c'est le projet <a href="http://code.google.com/p/sepamail-smite/" target="_blank">SMITE, SEPAmail, I Want Test Examples</a>.<br />
<br />
L'implémentation SMART des quatre premiers adhérents s'est construite autour d'un produit similaire (SEPAplug®, édité par StreamMind®). L'interprétation des équipes de développement de StreamMind était donc un peu un standard de fait pendant l'expérimentation initiale.<br />
<br />
Dès 2010, SEPAmail.eu m'a demandé de faire un contrôle de cohérence entre les documents spécifiant le protocole et les différentes expérimentations autour de <a href="http://sepamail.blogspot.fr/2012/06/application-sepamail-rubis.html" target="_blank">RUBIS</a> et de GEMME. Cela m'a permis de confronter les documents produit par le committer de l'époque (Olivier Jousselin) avec les différentes implémentations de composant logiciels.<br />
<br />
Un comité Norme s'est constitué en 2011 pour publier le standard SEPAmail en partenariat avec le committer. Trois versions ont vu le jour (la version 1112, 1202 et la version stable 1206, relue et validée par une quarantaine d'acteurs dont les éditeurs de l'expérimentation et tous les contributeurs).<br />
<br />
Aujourd'hui, voici la liste des documents de référence du standard :<br />
<ul>
<li><a href="http://documentation.sepamail.eu/wiki/Norme_1206_valid%C3%A9e" target="_blank">la norme en version 1206</a></li>
<li><a href="http://documentation.sepamail.eu/wiki/Errata_1206" target="_blank">la liste des erratas de la version 1206</a></li>
</ul>
Pour les adhérents, il y a aussi :<br />
<ul>
<li>un recueil de règles opérationnelles (à demander à sepamail.eu) pour se connecter au réseau SEPAmail</li>
<li>un cahier de test de conformité (à demander à sepamail.eu) pour mettre en valider la conformité de sa plate-forme ou de son implémentation</li>
</ul>
Il y a aussi, pour coopérer sur le standard :<br />
<ul>
<li><a href="http://change.sepamail.eu/" target="_blank">la liste des change request</a> (création de compte exigée) </li>
<li>le <a href="http://documentation.sepamail.eu/" target="_blank">wiki</a> et les pages de discussion</li>
</ul>
<br />
La lecture de ces documents est importante pour connaitre les questions, les remarques des implémenteurs, quand ceux-ci posent des questions à la communauté.<br />
<br />
Voici quelques unes des questions les plus souvent posées. <br />
<br />
<h4>
Pourquoi l'identifiant d'un message (balise MsgId) devrait être déduit d'un identifiant de missive (balise MsvId) alors que le message est généré avant la missive ?</h4>
La règle issue de la <a href="http://documentation.sepamail.eu/wiki/Standards:IG_message" target="_blank">directive d'implémentation des messages</a> est celle-ci : "This identifier should be equal to the missive identifier (MsvId element, see related doc.), followed by an underscore ('_') and by a number, which must be unique in a given missive. In any case, the message identifier MUST be unique for a given sender." <br />
<br />
Cette règle, si elle est interprétée de façon naturelle, pose problème. En effet : <br />
<ul>
<li> elle fait confondre la couche message et missive </li>
<li> on dénature la notion d'identifiant en essayant d'y coller un concept de classification </li>
<li> on limite à des nombres un champ déjà bien réduit par le préfixe en limitant cela à des nombres et non n'importe quel caractère</li>
</ul>
La plupart de ceux qui ont implémenté le protocole SEPAmail sont restés perplexes devant cette règle puisque le message est, a priori, généré avant la missive.<br />
<br />
La plupart s'en sont sortis en générant un identifiant de type Id1_Id2 pour le message et ils ont récupéré l'identifiant Id1 pour construire la missive.<br />
Mais ceci n'est pas satisfaisant dans une logique de protocole en couche.<br />
De plus, un certain nombre de règles implicites, pour le maitre d'ouvrage, se cachent alors derrière cette directive d'implémentation, que l'on peut résumer par les questions qu'il se pose naturellement:<br />
<ul>
<li>l'identifiant du message devant contenir l'identifiant de la missive, faut-il vérifier cette règle ? Et dans ce cas, pourquoi ne pas inclure une balise MsdId dans le message ?</li>
<li>quelle est la nature de la relation entre un message et une missive: 1-1, 1-n, n-m ?</li>
<li>est-ce à l'adhérent (le relais et/ou générateur) de gérer ces identifiants ou l'expéditeur de la missive ?</li>
<li>en construisant un identifiant signifiant, ne suis-je pas en train de donner involontairement de l'information sur mon système ?</li>
</ul>
<h4>
Comment interpréter la directive d'implémentation de l'identifiant d'une missive (balise MsvId) ?</h4>
La <a href="http://documentation.sepamail.eu/wiki/Standards:IG_missive" target="_blank">directive d'implémentation de la missive</a> pose le principe suivant "The format of this identifier is YYYYMMDDhhmmssxxx + "_" + sender_id. The first part is the creation date and time, including milliseconds The second part can be used freely by the sender."<br />
<br />
Ceci pose des problèmes à l'implémentation, notamment car cela induit en première lecture une liaison à la date de génération de l'identifiant avec une limitation sur le nombre d'identifiants que l'on peut créer.<br />
<br />
Certains verront donc le besoin d'implémenter une règle de vérification des dates.<br />
<br />
Ces problématiques d'implémentation sont venues de longues discussions sur le (soi-disant) besoin d'un identifiant unique de bout en bout pour les missives comme pour les messages. Naturellement, le problème n'est pas simple et je vous renvoie sur la notion d'<a href="http://fr.wikipedia.org/wiki/Universal_Unique_Identifier" target="_blank">uuid</a> pour en comprendre la portée et les normes concernées.<br />
<br />
Selon moi, ces problèmes ont été réglés en pratique il y a déjà longtemps par les MTA (Mail Transfert Agent) et les clients de messagerie. Un récepteur ne pouvant garantir qu'un émetteur sache identifier de façon unique un message, identifie pour lui-même tout ce qu'il reçoit. Nous devrions donc utiliser les solutions déjà trouvées par d'autres et qui, aujourd'hui, fonctionnent bien.<br />
<br />
Un implémenteur peut donc générer son propre identifiant de missive et de message à la réception et ajouter celui-ci dans l'entête de la missive et du message.<br />
<br />
Ma proposition, pour respecter la version 1206 du standard (et ne pas initier des complications dans l'implémentation) est de supposer que la "creation date and time" soit celle de SEPAmail (et non autre chose), c'est à dire le 1<sup>er</sup> avril 2008 vers 13h14 pour tous, comme cela, on en sera quitte pour un poisson d'avril. Je propose donc d'utiliser le préfixe 20080401131415926.<br />
<br />
<h4>
Pourquoi une missive doit absolument contenir un message de type SEPAmail ?</h4>
La missive peut contenir dans son corps (balise MsvBdy) zéro ou un message quelconque SEPAmail, comme indiqué dans la <a href="http://documentation.sepamail.eu/wiki/Standards:IG_missive#Missive_body" target="_blank">directive d'implémentation de la missive SEPAmail</a>.<br />
<br />
Il n'est donc pas possible d'inclure plusieurs messages.<br />
Il n'est donc pas possible d'inclure autre chose qu'un message SEPAmail.<br />
La liste des messages SEPAmail est définie dans les schémas.<br />
<br />
En 2008, le premier schéma de missive SEPAmail permettait de contenir dans le corps de la missive n'importe quelle donnée (anyType). Ceci avait le charme de permettre de vérifier la validité d'une missive sans celle du contenu de la missive.<br />
Pour l'expérimentation au sein des systèmes d'information bancaires, un responsable de la sécurité a demandé de définir tous les types des données et de ne faire qu'une validation globale de la missive contenant le message.<br />
Les schémas ont donc été changés en conséquence. Les avantages sont ceux mis en avant par le responsable de la sécurité. Comme SEPAmail cherchait à l'époque à privilégier le mode unitaire et ne pas rester dans le mode batch qui est la norme bancaire d'échange d'information, le nombre de messages par missive a été limité à un message au plus.<br />
<br />
Les inconvénients de ce choix sont nombreux s'il est respecté à la lettre: confusion de la couche missive et message, impossibilité de chiffrer le message facilement au sein d'une missive en clair, schéma xml très volumineux, balise racine du message xml non équivalente à la balise interne de la missive, etc...<br />
<br />
Une proposition d'implémentation intéressante est, à mon avis, d'utiliser un schéma simplifié (par une transformation xsl ?) pour la missive et de bien distinguer les deux couches missive et message, comme on distingue déjà la couche enveloppe.<br />
<br />
<h4>
Pourquoi inclure tous les schémas XML dans le schéma de la missive ?</h4>
Un implémenteur m'a demandé pourquoi inclure tous les schémas xsd dans la missive et non seulement ceux dont on a besoin.<br />
Pour bien comprendre de quoi on parle, je vous propose de regarder (attention à la limite mémoire de votre navigateur) ce <a href="http://xsd.sepamail.eu/1206/sepamail_missive.svg" target="_blank">schéma vectoriel représentant cette inclusion</a>.<br />
<br />
Quand un schéma est simple, la validation d'un flux xml est très rapide. Quand il est compliqué, cette validation peut être couteuse en ressource machine ou en mécanisme de cache. Le bon exemple est celui de la validation d'une missive d'acquittement qui ne nécessite aucun schéma de messages à inclure. <br />
<br />
La question est donc licite et connue de tous les programmeurs avec l'inclusion des librairies au sein de leur programme.<br />
<br />
Avec la solution préconisée du changement de schéma pour la missive (confère la question précédente), on peut implémenter une validation beaucoup plus efficace. C'est donc, selon moi, une réponse élégante à ce vrai problème.<br />
<h4>
Comment comprendre les espaces de noms SEPAmail ? </h4>
Ce sujet revient souvent sur le devant de la scène, notamment car le XML n'est vraiment pas human-readable.<br />
<br />
Pour comprendre vite, disons simplement que SEPAmail définit un espace de nom principal décliné en plusieurs schémas (un pour la missive, un pour le message générique, un par type de message, quatre pour les types partagés par les schémas précédents) et fait référence aux espaces de nom de l'iso 20022 (des pain, des camt) et de la signature de xml (dsig).<br />
<br />
Pour comprendre dans le détail, regardons la définition de la balise racine du schéma lié à la missive :<br />
<br />
<code><schema<br />
targetNamespace="http://xsd.sepamail.eu/1206/"<br />
elementFormDefault="qualified"<br />
xmlns="http://www.w3.org/2001/XMLSchema"<br />
xmlns:sem="http://xsd.sepamail.eu/1206/"<br />
xmlns:ds="http://www.w3.org/2000/09/xmldsig#"></code><br />
<br />
qui s'interprète comme suit :<br />
<ul>
<li><i>targetNameSpace</i> définit l'espace de nom du schéma, </li>
<li><i>elementFormDefault</i> précise que tous les sous-éléments sont qualifiés par défaut au sein de l'espace de nom SEPAmail (l'équivalent n'a pas été fait pour les attributs)</li>
<li><i>xmlns="http://www.w3.org/2001/XMLSchema"</i> est la référence à l'espace de nom définissant les schémas XML; cette déclaration pourrait donc être en première ligne</li>
<li><i>xmlns:sem="http://xsd.sepamail.eu/1206/"</i> permet de définir le préfixe sem pour l'espace de nom SEPAmail</li>
<li><i>xmlns:ds="http://www.w3.org/2000/09/xmldsig#"</i> permet de définir le préfixe ds pour l'espace de nom lié à la signature DSIG</li>
</ul>
On a ensuite :<br />
<br />
<code><import><br />
namespace="http://www.w3.org/2000/09/xmldsig#"<br />
schemalocation="xmldsig-core-schema.xsd"><br />
</import><br />
<include schemalocation="type_sepa.xsd" /><br />
<include schemalocation="type_sepamail_general.xsd" /><br />
<include schemalocation="type_sepamail_missive.xsd" /><br />
<include schemalocation="sepamail_message.xsd" /><br />
</code><br />
<br />
qui s'interprète comme suite :<br />
<ul>
<li>importation de l'espace de nom lié à <a href="http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/xmldsig-core-schema.xsd" target="_blank">XMLDSIG</a>, qui permet la canonisation et la signature de flux XML (standard W3C)</li>
<li>inclusion du fichier interne à l'espace de nom SEPAmail type_sepa qui comprend les types dérivés de l'iso20022 pour SEPAmail</li>
<li>inclusion du fichier interne à l'espace de nom SEPAmail type_sepamail_missive qui comprend les types liés à la couche missive</li>
<li>inclusion du fichier interne à l'espace de nom SEPAmail type_sepamail_message qui comprend les types liés à la couche message</li>
<li>inclusion du fichier interne à l'espace de nom SEPAmail sepamail_message qui comprend les types de messages SEPAmail</li>
</ul>
Pour bien comprendre les entêtes des schémas et des flux xml associés, il faut donc maîtriser l'usage des attributs <i>targetNamespace</i>, <i>schemalocation</i>, <i>namespace</i>, <i>elementFormDefault</i> et avoir compris que la référence unique d'un espace de nom est une uri qui n'a pas besoin d'exister, bref une étiquette unique.<br />
<br />
Je conseille d'installer localement un atelier xml avec les schémas et d'essayer de valider des flux pour bien comprendre les implications des espaces de noms.<br />
<br />
Je conseille aussi d'inclure dans les flux xml la référence aux espaces de nom dans la première balise utilisant l'espace et d'utiliser des préfixes courts mais signifiants.<br />
<br />
A la lecture de la question précédente, vous aurez compris que je conseille également une inclusion minimaliste selon les besoins réels de validation des flux.<br />
<h4>
Pourquoi RUBIS et GEMME ne font pas l'objet d'une SMIRK, comme Jade, Diamond, la missive, le message, la cryptographie etc. ?</h4>
La question m'a été posée récemment.<br />
RUBIS et GEMME ne font pas l'objet d'une SMIRK comme JADE ou DIAMOND alors que cela pourrait (et devrait à mon sens) être le cas.<br />
<br />
<br />
Cela serait un bon exercice de réduire la description de <a href="http://documentation.sepamail.eu/wiki/RUBIS" target="_blank">RUBIS</a> et de <a href="http://documentation.sepamail.eu/wiki/GEMME" target="_blank">GEMME</a> à un ensemble de définition et de règles, comme pour <a href="http://documentation.sepamail.eu/wiki/Standards:SMIRK_APP1301,_l%27application_JADE" target="_blank">JADE</a>.<br />
<br />
<br />
<br />Manfred Sherlock OLMhttp://www.blogger.com/profile/09549165648881760487noreply@blogger.com1tag:blogger.com,1999:blog-1371702306128290425.post-36140550318326708052014-03-05T09:00:00.000+01:002014-03-05T16:42:25.514+01:00SEPAmail : utilisation des protocoles de l'internet SMTP, SMIME, HTTP, REST, SOAP, IP, DNS...Le protocole SEPAmail peut se définir comme un ensemble de règles permettant de mettre en oeuvre une messagerie entre un expéditeur et un destinataire (appelés les utilisateurs de SEPAmail) via des relais (appelés adhérents du réseau privé SEPAmail).<br />
<br />
Ces relais sont des fournisseurs d'accès au réseau SEPAmail pour le compte de leurs clients.<br />
Le rôle de ces relais est :<br />
<ul>
<li>de relayer les messages de leur client sur le réseau SEPAmail </li>
<li>d'authentifier leurs clients quand ils émettent ou reçoivent un message SEPAmail</li>
<li>d'accuser réception des messages au nom de leur client destinataire </li>
</ul>
Pour réaliser ces fonctions en se servant d'un réseau de transport public comme internet, le protocole SEPAmail met en œuvre trois couches d'abstraction :<br />
<ul>
<li>une enveloppe SEPAmail, qui, dans l'état de l'art du moment, est une enveloppe SMTP/S-MIME</li>
<li>une missive SEPAmail qui, pour le moment, est un flux xml contenant un entête et un corps</li>
<li>un message SEPAmail qui, pour le moment, est un flux xml dérivé d'un gabarit de message générique à entête et corps.</li>
</ul>
Cette <a href="http://sepamail.blogspot.fr/2012/05/vocabulaire-sepamail-enveloppe-missive.html" target="_blank">double encapsulation</a> au sein d'une messagerie à relais permet de sécuriser la messagerie et de faire transiter des messages sur le réseau public internet d'un expéditeur à un destinataire avec un bon niveau de confiance, de confidentialité, d'intégrité.<br />
<br />
Il existe deux façons de faire transiter les enveloppes SEPAmail:<br />
<ul>
<li>le mode canonique qui est pour le moment un échange SMTP dans l'état de l'art</li>
<li>le mode flash, voulu par les premiers adhérents qui est, pour le moment, un échange web-services de serveur à serveur à l'aide du protocole SOAP sur HTTP(S) ou REST sur HTTP(S)</li>
</ul>
On peut donc schématiser l'utilisation des couches protocolaires par le schéma suivant: <br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgbC9Z_aKkWz83k6XqoTSzyHe16_-gcxtvO8sW0nwCvCPKlOalYDwckds_wOepBrH1sm66ersYOu2v_CIKBe9CI8172wVR1Bu7hUG4MSesUqUNNaQH9V8c_FpN4d3aTYf8nGYhk6PL4Oss/s1600/ProtocolesSepamail.png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgbC9Z_aKkWz83k6XqoTSzyHe16_-gcxtvO8sW0nwCvCPKlOalYDwckds_wOepBrH1sm66ersYOu2v_CIKBe9CI8172wVR1Bu7hUG4MSesUqUNNaQH9V8c_FpN4d3aTYf8nGYhk6PL4Oss/s1600/ProtocolesSepamail.png" height="283" width="400" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Les couches utilisées par le protocole SEPAmail</td></tr>
</tbody></table>
<div class="separator" style="clear: both; text-align: center;">
</div>
<div class="separator" style="clear: both; text-align: center;">
</div>
<br />
Nous retrouvons dans la colonne de gauche les couches du modèle TCP/IP, puis les couches du protocole SEPAmail et enfin les protocoles standards utilisés:<br />
<ul>
<li>S-MIME au sein de SMTP pour la couche enveloppe</li>
<li>un échange SMTP pour l'échange SEPAMail en mode canonique (le plus naturel et le moins couteux)</li>
<li>un échange SOAP sur HTTP pour l'échange SEPAmail en mode flash tel qu'implémenté pour l'expérimentation (le plus couteux et pas très naturel sauf à implémenter SEPAmail au sein d'une prise SOAP plus générale)</li>
<li>un échange REST sur HTTP pour l'échange SEPAmail en mode flash et sobre (rapide, moins couteux que SOAP, naturel car SEPAmail permet d'échanger une ressource enveloppe SEPAmail)</li>
<li>TCP comme couche transport quand il est mis en oeuvre sur le réseau à bas coût internet</li>
<li>IP et DNS pour la couche réseau</li>
</ul>
<br />
A la lecture de ce schéma, nous voyons que SEPAmail est un protocole en couches utilisant des standards du web. SEPAmail écrit que cette utilisation doit être réalisée dans l'état de l'art, ce qui, signifie, par exemple :<br />
<ul>
<li>pour la couche HTTP, l'utilisation de la version 1.1 pour les possibilités de négociation de contenu et de connexion persistante,</li>
<li>pour la couche S-MIME, l'utilisation de sha256 au minimum à la place de sha1 selon les recommandations récentes. </li>
</ul>
<br />
Les règles de l'état de l'art pour les protocoles utilisés par SEPAmail sont, si besoin, précisées dans des règles opérationnelles issus des travaux des adhérents SEPAmail et partagés entre eux.<br />
Ces règles opérationnelles précisent également les restrictions de l'utilisation de certains protocoles en expliquant dans la mesure du possible les raisons afin qu'une règle ne soit pas appliquée indéfiniment si la raison a disparu.<br />
<br />
Le standard SEPAmail n'explique donc, ni l'état de l'art des couches utilisées, ni l'utilisation de ces couches.<br />
<br />
Prenons un exemple pour bien comprendre ce que cela peut signifier pour celui qui implémente SEPAmail au sein d'un logiciel.<br />
<br />
Supposons que l'adhérent de l'expéditeur d'un message envoie une enveloppe SEPAmail en mode canonique avec un algorithme cryptographique non supporté par le système récepteur de l'adhérent du destinataire, alors, il est normal que ce système récepteur réponde un code de type 476 ou 576 (Cryptographic algorithm not supported) sur la couche SMTP, conformément à la <a href="http://tools.ietf.org/html/rfc3463" target="_blank">RFC 3463</a>.<br />
<br />
Si maintenant cette même enveloppe est conforme du point de vue SMIME avec un algorithme supporté par S-MIME et l'agent smtp (MTA) mais que l'enveloppe SEPAmail utilise un algorithme non permis par le protocole SEPAmail, une bonne façon de répondre est de répondre sur la couche SEPAmail, c'est à dire d'envoyer une missive d'acquittement avec un statut NAK et un code retour 573 (Unsupported algorithm or security function
), conformément au fonctionnement proposé par la <a href="http://documentation.sepamail.eu/wiki/Standards:SMIRK_MIS1202,_la_missive_dans_les_%C3%A9changes_interbancaires" target="_blank">SMIRK MIS 1202</a>.<br />
<br />
<br />
Le principe général est ainsi, comme le veut l'usage avec les protocoles internet, de répondre sur la bonne couche des erreurs de la couche et de ne répondre sur la couche SEPAmail que pour ce qui concerne le protocole SEPAmail.<br />
<br />
Il est important de noter que le transport d'une enveloppe SEPAmail doit s'imaginer en premier lieu par le mode canonique, c'est à dire via le protocole d'échange SMTP, puisque c'est le mode naturel de la messagerie SEPAmail.<br />
Le mode flash doit être implémenté de façon cohérente au mode canonique, que ce soit via SOAP ou REST, sujet qui fera peut-être l'objet d'un billet.<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />Manfred Sherlock OLMhttp://www.blogger.com/profile/09549165648881760487noreply@blogger.com0tag:blogger.com,1999:blog-1371702306128290425.post-80476085699212581222014-03-04T09:00:00.000+01:002014-03-04T23:44:59.349+01:00Revue de presse : février 2014Quelques parutions en février sur SEPAmail :<br />
<ul>
<li>7/02/2014 Bfinance <a href="http://www.bfinance.fr/market-intelligence/nos-publications/observatoire-de-la-migration-au-sepa-les-banques-se-preparent-au-mouvement-doptimisation-du-cash-management/" target="_blank">Observatoire de la migration SEPA</a></li>
<li>15/02/2014 CEGOS <a href="http://www.cegos.fr/formation-sepa/p-20147849-2014.htm" target="_blank">une formation parlant de SEPA et SEPAmail</a></li>
<li>28/02/2014<a href="http://www.societegenerale.com/fr/comprendre-la-banque/le-metier-de-banquier/les-nouveaux-moyens-de-paiement/les-innovations-du-paiement-en-ligne" target="_blank"> e-wallets, QR codes... les innovations du paiement en ligne et à distance</a> par la société générale</li>
</ul>
Bonne lectureManfred Sherlock OLMhttp://www.blogger.com/profile/09549165648881760487noreply@blogger.com0tag:blogger.com,1999:blog-1371702306128290425.post-53693588126194851192014-02-28T09:00:00.000+01:002014-03-28T15:41:10.982+01:00Quelques implémentations logicielles du protocole SEPAmailLa conformité des plates-formes des adhérents au protocole SEPAmail est en cours de réalisation, notamment grace à l'outil mis en oeuvre par SEPAmail.eu avec le concours des équipes de STET.<br />
<br />
Cela se passe plutôt bien et permet de confronter les interprétations des diverses implémentations logicielles entre elles et avec le standard.<br />
<br />
Ayant un peu suivi les questions qui se sont posées, je pense décliner quelques articles autour :<br />
<ul>
<li>des utilisations dans l'état de l'art des protocoles SMTP, S-MIME, HTTP etc...</li>
<li>de <a href="http://sepamail.blogspot.fr/2014/03/faq-n4-autour-de-quelques-regles.html">quelques règles d'implémentation SEPAmail</a> qui méritent d'être précisées ou discutées, notamment autour des identifiants et des dates </li>
<li>des <a href="http://sepamail.blogspot.fr/2014/03/codes-de-retour-du-protocole-sepamail.html">codes de retour</a> du protocole SEPAmail au niveau de la couche Missive</li>
</ul>
Voici la liste des implémentations logicielles dont je suis au courant (à ce jour), classées par ordre alphabétique des éditeurs :<br />
<ul>
<li>AriadNext et son implémentation partielle d'un client Android </li>
<li>Atos et son implémentation complète en cours</li>
<li>Axway et son implémentation d'un passerelle SEPAmail</li>
<li>deciBI et son implémentation partielle d'un client open source SMURF</li>
<li>deciBI et son implémentation partielle d'un client open source SMETH</li>
<li>Deny All et son implémentation SEPAmail au sein de son pare-feu applicatif </li>
<li>Elcimai et son implémentation de test d'un client ebics pour SEPAmail </li>
<li>CGI/Logica et son implémentation complète en cours</li>
<li>GFI/AriadNext et son implémentation complète d'un SMART/SMILE avec les applications RUBIS, TEST et DIAMOND</li>
<li>IBM et son implémentation SEPAmail au sein de son pare-feu applicatif Datapower</li>
<li>Lyra Networks et son implémentation complète d'un SMART/SMILE avec les application RUBIS, TEST</li>
<li>PPI et son implémentation de test d'un client ebics pour SEPAmail</li>
<li>SOPRA et son implémentation d'une application mobile m-Rubis </li>
<li>SpeedInfo et son implémentation partielle d'un client eCommerce RUBIS</li>
<li>STET et son implémentation partielle d'un SMART/SMILE avec les applications RUBIS, GEMME, TEST et une application de conformité pour le compte de SEPAmail.eu</li>
<li>StreamMind et son implémentation complète d'un SMART/SMILE avec les applications RUBIS, TEST (GEMME est obsolète, DIAMOND est en cours), en partenariat avec HP pour la partie matérielle</li>
<li>TURBO et son implémentation complète d'un client créancier et débiteur pour RUBIS</li>
</ul>
Quatre des cinq adhérents actuels ont également intégré le protocole SEPAmail au sein de leur SI, multipliant donc les implémentations logicielles partielles sur des segments fonctionnels.<br />
<br />
N'hésitez pas à rajouter toute information que vous connaitriez sur le sujet ou commenter ce billet pour toute précision sur les implémentations listées ci-dessus. <br />
<br />Manfred Sherlock OLMhttp://www.blogger.com/profile/09549165648881760487noreply@blogger.com0tag:blogger.com,1999:blog-1371702306128290425.post-77911637669806639142014-02-03T10:16:00.000+01:002014-02-28T10:17:02.203+01:00Revue de presse : janvier 2014Le mois de janvier a connu un creux de communication de SEPAmail, qui se rattrape en février, annonçant la mise en marché au début du deuxième trimestre 2014.<br />
<br />
<ul>
<li>24/01/2014 <a href="http://www.universwiftnet.com/?p=291" target="_blank">SEPAmail, la pub de natixis</a></li>
</ul>
Dans le cadre du workshop autour du Web Payment organisé le 24 mars 2014 au palais Brognard par le W3C, BPCE et Cyril Vignet ont déposé un position paper mettant en avant SEPAmail.<br />
<br />
Manfred Sherlock OLMhttp://www.blogger.com/profile/09549165648881760487noreply@blogger.com0tag:blogger.com,1999:blog-1371702306128290425.post-1590666359841181182013-12-17T22:07:00.001+01:002013-12-17T22:07:36.041+01:00Revue de presse : Novembre 2013Pas grand chose au mois de novembre sur le web et sur SEPAmail... on sent toute la profession rivée sur le passage au SEPA d'ici février 2014... <br />
<br />
HP et GFI parlent tout de même de SEPAmail :<br />
<br />
<ul>
<li><a href="http://www8.hp.com/fr/fr/campaigns/sepamail/overview.html" target="_blank">partenariat HP et StreamMind autour de SEPAmail</a></li>
<li><a href="http://www.gfi.fr/paystream/conseil-expert-paystream.php?id=10" target="_blank">GFI parle des flux résiduels MINOS et pose une vraie question</a> </li>
</ul>
<br />
<br />
SEPAmail a été présenté en début de journée <span style="color: black;">e-Entreprise à <a href="http://www.belfort.cci.fr/fr/accueil.html?no_cache=1&uid=671&contenu=AgendaSingle" target="_blank">Belfort le 18 novembre par la banque populaire Bourgogne Franche-Comté</a></span><br />
<span style="color: black;"><br /></span>Manfred Sherlock OLMhttp://www.blogger.com/profile/09549165648881760487noreply@blogger.com0tag:blogger.com,1999:blog-1371702306128290425.post-64858144000753938772013-11-21T20:51:00.001+01:002013-11-21T20:51:58.218+01:00Foire aux questions n°3Voici les questions qui me sont posées fréquemment ces temps-ci sur SEPAmail.<br />
Si vous avez vous-même des questions, n'hésitez pas à me contacter par la zone commentaire de ce billet ou via les réseaux sociaux <a href="http://fr.viadeo.com/fr/profile/manfred.olm" target="_blank">viadeo</a> ou <a href="http://www.linkedin.com/pub/manfred-olm/29/ab9/a55" target="_blank">linkedIn</a>. <br />
<br />
<br />
<h2>
SEPAmail pour tous, c'est pour quand ?</h2>
En ce moment, le protocole SEPAmail est bien mis en oeuvre entre des particuliers, des entreprises et des professionnels dans au moins 3 des 5 banques ayant adhéré au réseau.<br />
Par exemple, j'ai payé une facture d'un opérateur de télécom avec l'application de SEPAmail RUBIS et je rembourse l'un de mes clients quand il paie au restaurant.<br />
Cependant, mon épouse, mes enfants et mes parents n'utilisent pas encore SEPAmail, et notamment RUBIS. Pourquoi ?<br />
Parce que le lancement est prévu courant 2014... vers mars pour les premiers prêts, avant l'été pour les autres.<br />
Donc, une fois le SEPA dernière nous (février 2014), SEPAmail devrait être accessible au plus grand nombre, notamment sur le sol français.<br />
<br />
<h2>
SEPAmail est un réseau de messagerie privée ou publique ?</h2>
SEPAmail est un <a href="http://sepamail.blogspot.fr/2012/06/sepamail-est-une-messagerie-structuree.html" target="_blank">réseau de messagerie</a> privée, utilisable par les clients des adhérents de SEPAmail qui deviennent ainsi des fournisseurs d'accès à SEPAmail et ses applications.<br />
SEPAmail permet de faire transiter de<a href="http://sepamail.blogspot.fr/2012/05/sepamail-est-une-messagerie-securisee.html" target="_blank"> façon sécurisée l'information</a> sur un réseau public comme internet, entre tous les points d'articulation de la messagerie.<br />
Voilà pourquoi la réponse à cette question peut être ambiguë pour certains qui ne se sont pas plongés dans le standard, qui lui, est ouvert et public. <br />
<br />
<h2>
C'est quoi le règlement (via) SEPAmail ?</h2>
Le règlement (via) SEPAmail, c'est le nom générique de l'application de SEPAmail dont le nom de code entre ses concepteurs est <a href="http://sepamail.blogspot.fr/2012/06/application-sepamail-rubis.html" target="_blank">RUBIS</a>.<br />
<br />
J'ai déjà <a href="http://sepamail.blogspot.fr/2012/05/actualite-un-rapport-sur-les-moyens-de.html" target="_blank">écrit que SEPAmail n'était pas un nouveau moyen de paiement</a>.<br />
C'est une messagerie qui permet entre autres de s'envoyer entre deux entités économiques (particulier, entreprise, professionnel, institution, administration, association.... ) une demande de règlement et d'y répondre par une acceptation ou un refus, voire de ne pas y répondre.<br />
La demande et la réponse passe par la messagerie SEPAmail. Elles sont complètement dématérialisées, automatisées, articulées.<br />
Quand la réponse est positive, une initiation de paiement peut être articulée en même temps, ce qui est le comportement par défaut adopté par les adhérents. La réponse positive vaut donc initiation de paiement donc un règlement "dit" SEPAmail.<br />
La plupart des banques mettant en œuvre RUBIS ont articulé un virement, ce qui permet au passage de répondre à la demande de virement de proximité.<br />
<br />
<h2>
L'application DIAMOND est-elle bien 4-coins ?</h2>
L'application de SEPAmail DIAMOND permet à un gros remettant d'ordre (prélèvement ou virement) de vérifier un identifiant bancaire avant la remise.<br />
Par exemple, un opérateur d'énergie va vérifier avant d'envoyer un remboursement l'IBAN de son client en correspondance avec le nom et le prénom. Le score rendu avec DIAMOND par la banque de son client permet à cet opérateur de prendre une décision de virement automatique (par exemple via JADE) ou de matérialisation d'une lettre chèque.<br />
<br />
Si le client remboursé (ou prélevé) n'est pas au courant qu'il y a des demandes de vérification de son identifiant bancaire, l'application n'est pas vraiment <a href="http://sepamail.blogspot.fr/2012/06/le-modele-4-coins.html" target="_blank">4 coins</a>.<br />
Si le client est au courant à chaque demande, il peut ne plus se fier à cette information récurrente, voire considérer cette information comme une pollution. <br />
Par contre, si ce client peut décider de son niveau d'information et agir en cas de suspicion d'abus de demande de de vérification, alors, nous somme bien dans un modèle 4 coins vertueux.<br />
C'est ce troisième cas qu'est en train de finaliser le scheme SEPAmail.<br />
<br />
<h2>
</h2>
<h2>
Pourquoi il n'y a plus de billets chaque semaine sur ce blog depuis quelques mois ?</h2>
<br />
La question m'est souvent posée ;-)<br />
<br />
Il y a plusieurs réponses à cela.<br />
<br />
Tout d'abord, SEPAmail n'est pas généralisé et les banques ne communiquent pas beaucoup en ces temps d'<a href="http://sepamail.blogspot.fr/2013/05/passer-au-sepa-et-sepamail-dans-le-meme.html" target="_blank">urgence SEPA</a>.<br />
<br />
Ensuite, je suis sollicité sur plein de sujets par plusieurs acteurs mettant en oeuvre SEPAmail mais je suis plutôt sous Non Disclosure Agreement avec eux... donc, en ce moment, je ne partage pas avec tous mes bonnes idées, car je ne sais pas toujours si elles ne sont pas un peu issues de mes travaux confidentiels. <br />
<br />
Enfin, je préfère attendre d'avoir du contenu intéressant pour vous et moi, plutôt que de vous abreuver de contenu en retard ou trop en avance sur le temps SEPAmail.<br />
<br />
N'hésitez pas à me contacter ou à participer au blog si vous avez des idées.<br />
<br />
Dans les tuyaux, il y a à venir :<br />
<ul>
<li>un billet sur la SMIRK JADE qui est en voie de diffusion</li>
<li>un billet sur la gestion des dates dans RUBIS et notamment des précisions sur la "date souhaitée de paiement" et la "date d'expiration" de tout message</li>
<li>une série de billets sur des produits dans le même champ fonctionnel : MyBank, StarMail, Zoomit...</li>
<li>un billet sur la gestion de la volumétrie</li>
</ul>
<br />
<br />
Bonne lecture...Manfred Sherlock OLMhttp://www.blogger.com/profile/09549165648881760487noreply@blogger.com0tag:blogger.com,1999:blog-1371702306128290425.post-21918845567043958772013-11-13T11:20:00.001+01:002013-11-13T11:25:30.713+01:00Revue de presse : Octobre 2013Voici les articles trouvés en octobre 2013 sur internet :<br />
<br />
<ul>
<li>7/11/2013 le <a href="http://www.euroinvestor.fr/actualites/2013/11/07/gfi-informatique-chiffre-daffaires-du-3eme-trimestre-2013/12568011" target="_blank">compte-rendu du troisième trimestre 2013</a> de GFI qui cite sepamail</li>
<li>29/10/2013 <a href="http://www.bobsguide.com/guide/news/2013/Oct/29/all-set-for-sepa-or-time-for-plan-b.html" target="_blank">"All set for SEPA or Time for Plan B"</a>, Gary Young, CGI</li>
<li>le <a href="http://www.sepamail.eu/" target="_blank">nouveau site de SEPAmail</a></li>
</ul>
Ainsi que le lien pour l'application Android d'AriadNext qui permet de lire un Relevé d'identité SEPAmail :<br />
<br />
<ul>
<li><a href="https://play.google.com/store/apps/details?id=com.ariadnext.deuxddocreader&hl=fr" target="_blank">2D Doc Reader</a></li>
</ul>
<br />
Pour ceux qui voudraient faire un test, je peux vous transférer mon relevé d'identité SEPAmail.Manfred Sherlock OLMhttp://www.blogger.com/profile/09549165648881760487noreply@blogger.com0tag:blogger.com,1999:blog-1371702306128290425.post-60301842665391371572013-10-02T16:58:00.002+02:002013-10-02T16:58:50.823+02:00Revue de presse : Septembre 2013Voici les liens relevés lors de cette rentrée 2013 : <br />
<br />
<ul>
<li>06/09/2013 <a href="http://www.lejournaldesentreprises.com/chutier/lyra-network-la-pme-a-integre-son-siege-social-06-09-2013-202304.php" target="_blank">Lyra parle de SEPAmail dans le journal des entreprises</a></li>
<li>04/09/2013 <a href="http://www.rencontres-competitivite-numerique.com/moyens-paiement-partenaire-cic/" target="_blank">Claude Brun, CM-CIC sera présent le 6 novembre 2013 aux rencontres de la compétitivité numérique</a></li>
<li>20/09/2013 <a href="https://play.google.com/store/apps/details?id=com.ariadnext.deuxddocreader&hl=fr" target="_blank">une application android éditée par AriadNext pour lire les codes barres 2D et les relevés d'identité SEPAmail</a></li>
<li>20/09/2013 <a href="http://score-advisor.com/swift-la-vraie-revolution-des-paiements/#more-1607" target="_blank">swift parle du paiement documentaire</a></li>
<li>20/09/2013 <a href="http://worldline.com/ext/download/Brochure-Factsheet/SEPA_EN-LD.pdf" target="_blank">atos-wordline parle à l'international de SEPAmail</a></li>
</ul>
Bonne lecture.<br />
<br />
<br />
<br />Manfred Sherlock OLMhttp://www.blogger.com/profile/09549165648881760487noreply@blogger.com0