mardi 17 décembre 2013

Revue de presse : Novembre 2013

Pas 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...

HP et GFI parlent tout de même de SEPAmail :



SEPAmail a été présenté en début de journée  e-Entreprise à Belfort le 18 novembre par la banque populaire Bourgogne Franche-Comté

jeudi 21 novembre 2013

Foire aux questions n°3

Voici les questions qui me sont posées fréquemment ces temps-ci sur SEPAmail.
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 viadeo ou linkedIn.


SEPAmail pour tous, c'est pour quand ?

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.
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.
Cependant, mon épouse, mes enfants et mes parents n'utilisent pas encore SEPAmail, et notamment RUBIS. Pourquoi ?
Parce que le lancement est prévu courant 2014... vers mars pour les premiers prêts, avant l'été pour les autres.
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.

SEPAmail est un réseau de messagerie privée ou publique ?

SEPAmail est un réseau de messagerie privée, utilisable par les clients des adhérents de SEPAmail qui deviennent ainsi des fournisseurs d'accès à SEPAmail et ses applications.
SEPAmail permet de faire transiter de façon sécurisée l'information sur un réseau public comme internet, entre tous les points d'articulation de la messagerie.
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.

C'est quoi le règlement (via) SEPAmail ?

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 RUBIS.

J'ai déjà écrit que SEPAmail n'était pas un nouveau moyen de paiement.
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.
La demande et la réponse passe par la messagerie SEPAmail. Elles sont complètement dématérialisées, automatisées, articulées.
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.
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é.

L'application DIAMOND est-elle bien 4-coins ?

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.
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.

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 4 coins.
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.
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.
C'est ce troisième cas qu'est en train de finaliser le scheme SEPAmail.

 

Pourquoi il n'y a plus de billets chaque semaine sur ce blog depuis quelques mois ?


La question m'est souvent posée ;-)

Il y a plusieurs réponses à cela.

Tout d'abord, SEPAmail n'est pas généralisé et les banques ne communiquent pas beaucoup en ces temps d'urgence SEPA.

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.

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.

N'hésitez pas à me contacter ou à participer au blog si vous avez des idées.

Dans les tuyaux, il y a à venir :
  • un billet sur la SMIRK JADE qui est en voie de diffusion
  • 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
  • une série de billets sur des produits dans le même champ fonctionnel : MyBank, StarMail, Zoomit...
  • un billet sur la gestion de la volumétrie


Bonne lecture...

mercredi 13 novembre 2013

Revue de presse : Octobre 2013

Voici les articles trouvés en  octobre 2013 sur internet :

Ainsi que le lien pour l'application Android d'AriadNext qui permet de lire un Relevé d'identité SEPAmail :


Pour ceux qui voudraient faire un test, je peux vous transférer mon relevé d'identité SEPAmail.

lundi 9 septembre 2013

Revue de presse : Juillet et aout 2013

Cet été, l'actualité SEPAmail n'a pas été fortement relayée sur le net et dans la presse.

Voici les liens  relevés :

Bonne lecture et bonne rentrée

vendredi 19 juillet 2013

Communauté SEPAmail : PPI


Nous continuons notre tour des entreprises de la communauté SEPAmail avec la société PPI France, spécialiste des échanges de données informatiques financières, notamment dans le cadre de l'échange ebics.
J'ai rencontré et interrogé Marc Dutech, directeur général.

Quand a été créé PPI, dans quel contexte ?


PPI France, créée en 2010, est la filiale française de PPI AG, leader européen dans le domaine des transactions financières et des EDI financiers. PPI France propose les produits de la gamme TRAVIC, suite complète et modulaire d’Electronic-Banking dédiée aux Banques, Entreprises, Prestataires pour la dématérialisation de leurs flux financiers. PPI France fournit également des composants permettant aux éditeurs de logiciels d’implémenter rapidement la gestion du protocole EBICS au sein de leurs applications.


Combien PPI comptent de collaborateurs ?


PPI France compte 6 collaborateurs et fait appel fréquemment aux ressources humaines de PPI AG forte d’un effectif de 350 employés. Les collaborateurs de PPI France se consacrent à la localisation de l’offre TRAVIC pour ses marchés (France, Péninsule Ibérique, Pays d’Afrique francophone), à leur commercialisation, à leur déploiement et à leur support de premier niveau.

Quels sont vos principaux produits ?


La suite TRAVIC se compose de plusieurs logiciels :
  • TRAVIC-Corporate : serveur multi-protocolaire utilisé par les Banques et Prestataires pour les échanges télématiques avec leur clientèle Entreprise et avec d’autres institutions financières dans le cadre d’échanges interbancaires,
  • TRAVIC-Link : solution d’automatisation des échanges et des traitements des flux financiers particulièrement bien adapté aux Entreprises ayant des volumétries conséquentes à traiter,
  • TRAVIC-Port : solution permettant de mettre en œuvre rapidement un portail de Coporate-Banking sur Internet,
  • EBICS-Kernel : composant logiciel destiné à être intégré au sein d’application tierces pour la gestion du protocole EBICS toutes versions,
PPI fournit l’assistance au déploiement et à la mise en production de TRAVIC ainsi que son support après-vente. PPI propose également des prestations de conseil métier et IT dans les domaines ayant trait aux échanges de flux financiers.

Quels est le profil de vos clients, quelles sont vos références ?


Les clients de PPI sont des Banques de toute taille (Crédit Mutuel/CIC, Caisses d’Epargne Allemande, Commerzbank, Deutsche Bank, Banque Delubac,…) des Prestataires et Opérateurs (Docapost, Atos Worldline, GAD,EBA Clearing,…), des Entreprises (ADP GSI, AMB Generali,…) et des éditeurs de logiciel (Datalog Finance, CPI Software, Kyriba, Alsyon,…).

Quelles sont vos spécificités ?


 
Dès 2008 PPI a fait le pari qu’EBICS deviendrait un protocole couramment utilisé non seulement en France et en Allemagne mais aussi dans d’autres pays d’Europe et du reste du monde. De même qu’elle a prévu son utilisation à grande échelle non seulement dans le cadre des échanges Banque-Entreprise mais également dans le cadre des échanges interbancaires et B2B.
PPI a donc consacré une part importante de son effort R&D au développement d’applications basées sur le protocole EBICS afin de proposer des applications innovantes, robustes et performantes. A ce jour, plus de 70 employés sont dédiés au développement et au support de ces applications, faisant de PPI un acteur unanimement reconnu pour la qualité de ses logiciels et leur adéquation aux besoins de tous les marchés dans lesquels elle est présente.
Le pari fait en 2008 est en train de se réaliser et PPI y contribue largement, d’une part en proposant des prestations de conseil et une offre produit efficientes et d’autres part en participant activement à la promotion d’EBICS au niveau international.

Quel est votre lien à SEPAmail ?


PPI a proposé ses connaissances et ses produits pour tester la capacité d’EBICS à échanger des flux SEPAmail.
Ces tests, réalisés début 2013, se sont avérés concluants.

Quel est votre implication dans la communauté SEPAmail ?


Outre le fait que PPI continue à proposer ses services pour d’éventuels tests ou expérimentations supplémentaires, PPI entend informer ses clients et son marché de l’adéquation du protocole EBICS et de ses logiciels à l’échange des flux SEPAmail.




lundi 8 juillet 2013

SEPAmail : la portée de l'acquitement

Le protocole de messagerie SEPAmail comprend un acquittement des messages échangés. Cet acquittement est réalisé par le fournisseur de l'accès à SEPAmail (l'adhérent) pour le compte du destinataire dès réception du message.
Cet acquittement est obligatoire dans tous les cas pour tous les fournisseurs d'accès à SEPAmail, quel que soit l'expéditeur et le destinataire, dans les cas où l'acquittement est possible.

Ces règles sont décrites dans la directive d'implémentation de la missive.

Cet acquittement permet à l'expéditeur du message, ainsi qu'à son fournisseur d'accès à SEPAmail d'être assuré :
  • de la bonne réception du message émis (contenu dans une missive nominale), réception, horodatage, validité, authentification des fournisseurs d'accès et de sécurité SEPAmail
  • du routage qui sera réalisé vers le destinataire du message (défini par l'entête de la missive)
  • de la capacité de distribution du message au destinataire
On remarque que la prise en charge des fonctionnalités autour du message ne fait pas partie de la fonction de l'acquittement.


L'acquittement se présente sous la forme d'un statut succès (ACK) ou échec (NAK) avec, facultativement, un code de retour pour expliquer le statut. Ces codes retour sont décrits ici et sont tous valides sauf ceux correspondant au sujet 4, à savoir les codes 541, 248, 249 (ces trois codes ont été utilisés dans le cadre de l'expérimentation mais ils ne correspondent pas à des retours possibles pour une messagerie; ils sont liés à l'application de SEPAmail RUBIS).

Comme pour tout protocole en couche, il est important que la messagerie SEPAmail ne se substitue pas aux couches au dessus et en dessous (en amont et en aval du traitement) pour son action.

Prenons un exemple dans le cadre d'une demande de règlement RUBIS pour bien comprendre la portée de l'acquittement.

Supposons qu'une personne A veuille transmettre à une personne B une demande de règlement.
Les fournisseur d'accès a SEPAMail de A (FasA) et B (FasB) leur proposent le service RUBIS.

Voici trois cas d'usage de réception par FasB de la missive nominale contenant la demande de réglement :
  • cas 1 : l'enveloppe SEPAmail contient une missive nominale avec un message PaymentActivationRequest n'étant pas conforme au schéma XML
  • cas 2 : l'enveloppe SEPAmail contient une missive nominale avec un message PaymentActivationRequest conforme au schéma mais pas à la directive d'implémentation RUBIS de ce message
  • cas 3 : l'enveloppe SEPAmail contient une missive nominale avec un message PaymentActivtationRequest conforme au schéma et à la directive d'implémentation RUBIS du message avec une seule demande de paiement en trois fois que FasB ne propose pas à son client B
Le cas 1 est le plus simple à comprendre et l'acquittement SEPAmail permet de traiter ce cas quelque soit le message contenu dans une missive nominale, c'est un acquittement NAK avec un code retour de sujet contenu et de code 581 "XML syntax error, non conforming to schema".
Remarque : on voit par ce retour que SEPAmail permet d'acquitter la présence d'un message conforme (au sens des schéma XML) au sein de la missive, ce qui dépasse en fontionnalité l'accusé de réception postal.

Le cas 2 pourrait être, par exemple, un champ  PaymentMethod à CHQ alors que ce champs, au sein du pain.013 est annoncé dans la directive d'implémentation comme "Mandatory. The only value currently accepted here is "TRF". Note : if the OtherPmtMtd field, in the non-ISO part, is used, this field will be ignored"ou un élément ChargeBearer qui ne serait pas à la valeur "SLEV" comme exigé par l'implémentation de RUBIS.
Ce cas ne relève pas de la messagerie SEPAmail puisque le message PaymentActivationRequest est intègre du point de vue de son schéma.
C'est l'application RUBIS de SEPAmail qui doit (ou peut) répondre. Si FasB pense que c'est une bonne idée dans sa relation avec FasA de boucler le processus, FasB devrait donc préparer un PaymentActivationReport négatif avec une mention de non prise en charge des ces options de la demande de règlement pour non conformité à la norme RUBIS.

Le cas 3 est cas de conformité à la norme SEPAmail et à la norme RUBIS non pris en charge par FasB. FasB est donc peut-être dans l'impossibilité de transmettre le message et prendre en charge la demande fonctionnelle associée à ce message.
Selon les cas de la relation et du contrat que FasB et B ont signé, FasB peut:
  • transmettre le message pour seule prise en compte du signifiant,
  • répondre pour le compte de son client de façon négative en motivant le refus
  • ne rien faire

Dans les cas 2 et 3, la missive nominale a été acquittée normalement (code retour 219) car la missive a bien été reçue conforme et relayée en terme de messagerie.

Certains sont tentés de reporter l'impossibilité fonctionnelle du fournisseur d'accès à SEPAmail de transmettre le message (ce message ne répond pas à la norme RUBIS ou le cas n'est pas traité par le fournisseur d'accès du destinataire) au sein de l'acquittement de la messagerie.
Il ne faut pas céder à cette tentation, au risque de confondre la couche SEPAmail (messagerie) et la couche RUBIS (application de SEPAmail). En faisant cela, on dénature l'acquittement et son intérêt en terme d'accusé réception.

SEPAmail.eu pourrait, à mon sens, pour lever les ambiguités sur ce sujet :
  • préciser des cas d'usage, pour bien expliquer l'interprétation qui doit être faite de la norme autour de l'acquittement
  • séparer la norme de messagerie SEPAmail de chacune des normes des applications utilisant SEPAmail
  • enlever les scories due à l'expérimentation, comme les codes retour d’acquittement de sujet 4
     







mercredi 3 juillet 2013

Revue de presse : Juin 2013

Voici quelques articles sur le net et dans la presse pour le mois de Juin :

 Bonne lecture.

jeudi 27 juin 2013

Communauté SEPAmail : Lyra Network

Nous continuons notre tour des entreprises de la communauté SEPAmail avec la société Lyra Network.

J'ai rencontré et interrogé Christophe Mariette, directeur commercial.


Quand a été créé Lyra Network, dans quel contexte ?

Lyra Network a été créée en janvier 2001 à Toulouse (où se situe son siège social) par Alain Lacour et André Malbert alors que l’industrie monétique était en pleine croissance.
Profitant de la libéralisation des Telecom, Lyra Network s'est rapidement imposée comme leader en France sur le marché de la transaction monétique en privilégiant l’innovation et la recherche de solutions fiables et performantes.
Elle s’est d’abord développée sur le paiement de proximité pour élargir son périmètre au paiement à distance depuis 2009
Aujourd’hui, l’entreprise est présente sur quatre continents (Europe, Afrique, Asie, Amérique Latine), elle réalise +50 millions de chiffre d’affaires et effectue plus de 2,5 milliards de connexions par an.

Combien de collaborateurs compte l'entreprise, quels sont leurs profils et leurs fonctions ?


Aujourd’hui l’entreprise compte une centaine de personnes de formations et d’expériences différentes:

  • au service commercial, communication et marketing, support : ingénieurs, MBA en administration des entreprises, master de finance, expérience en développement marketing produit, profils internationaux.
  • au service développement :  ingénieurs en informatique , télécom, informatique financière, gestion de l’entreprise, profils plus ou moins internationaux.
Notre organisation repose sur une centaine de collaborateurs dont une majorité de développeurs informatiques pilotés par :
  • un directeur général et un président co-fondateurs : Alain Lacour et André Malbert
  • un directeur commercial et marketing : Christophe Mariette
  • un directeur Développement : Grégory Estrade
  • un directeur Technique (Exploitation) : Jean Luc Lledos
  • une directrice administrative et financière Clothilde Leclerc
  • des directeurs régionaux
    • Brésil : Thierry Coste
    • Inde : Rajesh Desai
    • Allemagne : Rainer Zettl

Quels sont les principaux produits ou services développés et vendus ?


Lyra Network est un opérateur monétique international qui offre un réseau fiable et sécurisé pour connecter tous types de solution de paiements.

Paiement de proximité : RTC, GPRS, IP, monétique intégrée
Lyra Network connecte les terminaux de paiements électroniques aux institutions bancaires et achemine les transactions de manière sécurisée.
Aujourd'hui, Lyra Network est reconnue comme le premier fournisseur français indépendant pour l'acheminement de transactions depuis les terminaux de paiement électroniques.

Paiement à distance : Plateforme de paiement sécurisées sur internet (Payzen)
Lyra Network propose une solution de paiement à distance pour les e-commerçants. Elle met à disposition de ses clients des outils de gestion et de suivi des transactions en direct via un back office.

Quels est le profil de vos clients, quelles sont vos références ?


Le profil de nos clients peut varier de façon très large pour le paiement à proximité, ce sont :

  • Banques Groupe BPCE, La Banque Postale, Crédit Agricole, Banque Edel…
  • Grande distribution, sociétés pétrolières : Total ; Ikea ; Leclerc, Carrefour ; Eram ;
  • Sociétés de crédit à la consommation Cetelem, Cofinoga,Oney….
  • Opérateurs télécom (prestataires de services aux banques) : Bouygues, SFR, Orange, O2, Vodafone…
  •  Sociétés de maintenance

Les plus grands réseaux de banque, de crédit et pétroliers, ont choisi Lyra Network pour acheminer, gérer et superviser leurs flux monétiques en RTC, IP ou GPRS.

Pour le paiement à distance, nos clients sont :
  • En marque Blanche : Banque Populaire, Caisse d’Epargne, BRED, Banque Edel, OSB,….
  • Quelques exemple de clients : Leclerc Drive, UFC Que choisir, Allo Resto, Agapes, Vente du diable… 

    Quelles sont vos spécificités ?



    Lyra Network se distingue de ses concurrents par :
    • son avancée technologique (fiabilité et performance des solutions),
    • la redondance complète en exploitation (2 sites, multi opérateurs…)
    • une offre complète dans le paiement (paiement par carte de proximité et à distance, sepamail…
    • des solutions faciles à intégrer pour les clients, évolutives
    • un extranet de gestion de en Web 2.0 egonomique
    • un monotoring temps réel des transactions monétiques
    • une traçabilité des flux bancaires et privatifs des terminaux de paiement
    • un haut niveau de sécurité (Certification PCI DSS, contrôle de fraude, 3D Secure…)
    • un support technique (24/7) ses valeurs
    Ainsi que nos compétences : 
    • des ingénieurs informatiques et télécom qualifiés
    • ensemble des développements effectués en France
    • des plateformes de traitement des transactions situées localement et administrées par les équipes techniques locales
    Et notre développement : des projets de paiement développés sur demande des acquéreurs en des temps reccords.
    Face à l’évolution des solutions de connexion des terminaux de paiement, Lyra Network fait évoluer son offre de façon permanente afin de s’adapter aux besoins du marché. 

    Quel est votre lien avec le standard SEPAmail ?

    SEPAmail est une messagerie à valeur ajoutée, orientée paiement, qui, par ses différentes applications, permet à des entités économiques d’échanger entre elles des factures et d’effectuer des paiements.

    Lyra Network intervient alors pour gérer et sécuriser la transmission du message ainsi que la transaction qui en découle, entre l’entité économique sujette au paiement et la banque qui a préalablement installé l’application SEPAmail.

    Quelle est votre implication dans la communauté SEPAmail ? Quelle évolution pour la suite ?


    Lyra Network ambitionne de devenir un des importants acteurs dans SepaMail en sécurisant les échanges et en développant des services à valeur ajoutée.

    lundi 20 mai 2013

    Passer au SEPA et SEPAmail dans le même mouvement ?

    Il est possible de passer au SEPA et à SEPAmail en même temps.

    Certains y voient même des gains importants.
    Nous allons expliquer pourquoi.

    L'espace unique de paiement en euro (SEPA) est mis en place par les banques membres de l'EPC (European Payments Council) en réponse à la demande de la commission européenne.
    L'objectif est d'harmoniser les moyens de paiement en euro, à savoir les virements, les prélèvement et la carte bancaire.
    A l'intérieur de la zone SEPA, un paiement transfrontalier doit être traité avec la même rapidité, la même sécurité et les même conditions qu'un paiement domestique.
    La mise en place des moyens de paiement SEPA est encadrée par la directive sur les services de paiement du 5 décembre 2007 (DSP).

    Concrètement, la mise en place de ces trois moyens de paiement passe par des messages normalisés entre la banque et son client dans le standard UNIFI (iso 20022) :
    • le SEPA Credit Transfert (SCT) ou virement, via les messages iso pain.001 mais aussi induit par un pain.014 et un pain.013
    • le SEPA Direct Debit (SDD) ou prélèvement, via les messages iso pain.008, pain.009, pain.010, pain.011, pain.012
    • le SEPA Card Payment (SCD) ou le paiement électronique et par carte bancaire, est adressé via un environnement de travail commun et intéropérable, le Sepa Card Framework (SCF) qui met en avant le standard Eurocard,Mastercard,Visa (EMV)
    SEPAmail encapsule des messages SEPA au sein de dialogues applicatifs en apportant des fonctionnalités supplémentaires :
    • le routage de n'importe quelle entité économique à une autre
    • la confidentialité
    • la sécurité de l'échange avec un accusé de réception systématique
    • la possibilité de joindre des informations non présentes dans les messages SEPA, et notamment des pièces jointes
    • une articulation vers un paiement selon le mandat de sa banque
    • des messages autoporteurs de toute l'information, notamment des références initiales, ce qui permet de boucler correctement tout procédés d'émission d'informations
    • des dialogues applicatifs sobres et efficaces, dont la mise en oeuvre peut s'étendre à d'autres sujets que le seul SEPA : la signature de document, la transmission de factures complexes, l'envoi simple d'information, la vérification d'identité
    • une vision symétrique de type messagerie des échanges d'information, ne présumant donc pas de la taille et de l'informatisation d'un créancier ou d'un débiteur
    • le transport des échanges par courriel (mode canonique) ou services web (mode flash)
    • la standardisation, l'ouverture et la gratuité du protocole décidées par de grandes banques de l'EPC
    SEPAmail utilisant des messages SEPA, le travail à réaliser pour le mettre en œuvre peut être factorisé avec celui de SEPA.
    SEPA, par les champs qu'il ajoute aux flux actuels, demande à revisiter les processus de l'entreprise. C'est pourquoi la migration n'est pas forcément triviale. SEPAmail ajoute une pièce jointe, une enveloppe dédiée au routage dans le réseau et permet d'unifier le processus d'envoi d'information SCT ou SDD à sa banque au sein du processus plus large de l'émission d'une demande de règlement ou d'une notification d'échéance, par exemple.
    C'est pour toutes ces raisons, et notamment la possibilité de joindre un document à un flux SEPA, que certains acteurs réfléchissent à une migration conjointe SEPA et SEPAmail.

    SEPAmail ne permet pas seulement un échange via les banques du créancier et du débiteur mais peut se concevoir également en relation pair à pair. Cela permet, par exemple, d'imaginer des dialogues avec ses fournisseurs et/ou ses clients en mode message au lieu et place des extranets, quand ceux-ci ne sont pas adaptés.

    Le scheme SEPAmail a aujourd'hui défini les dialogues applicatifs suivants :
    • RUBIS, autour de la demande de règlement : un créancier émet une demande de règlement à la quelle le débiteur répond par oui ou non, le banquier du débiteur articulant un paiement le plus souvent de type virement (SCT).
    • GEMME, autour du mandat de prélèvement : un créancier émet une requête de mandat de prélèvement (SDD), une notification d'échéance; le débiteur autorise ou annule un mandat, demande une copie des échéances.
    • DIAMOND, autour de la vérification d'identité : un créancier émet une demande de vérification d'un identifiant bancaire; le débiteur est informé et selon le mandat de sa banque, cette dernière donne une réponse au créancier.
    • SAPPHIRE, autour de l'échange d'éléments de sécurité : authentification par rebond, niveau gradué orienté utilisateur de sécurité
    La communauté SEPAmail propose les dialogues applicatifs suivants :
    • JADE, autour de l'avis de règlement : un débiteur émet un avis de règlement à un créancier, que le créancier peut facultativement autoriser, et la banque du débiteur articule le plus souvent un virement à la date demandée (cas d'usage : fiches de salaire, dématérialisation du ticket carte, remboursement assurances, solde de tout compte, succession, argent de poche...)
    • IOLITE , autour de la transmission de facture complexe : acompte, avoir, solde, affacturage etc... et son acceptation par le débiteur.
    • AGATE, autour de la transmission d'informations (sms, mms, mail)
    • JASPE, autour de la signature de documents et notamment les parcours de signature complexes
    Le protocole est scalable et d'autres applications de SEPAmail sont en discussion : PEPITE, GRENAT, ONYX, OPALE, CORAIL, QUARTZ, EMERAUDE, TOPAZE, RUTILE, CRISTAL, CITRINE...

    Quelques acteurs, de plus en plus nombreux, proposent leur composant ou leur conseil pour faciliter la mise en place de SEPAmail conjointement à SEPA.
    Sur ce blog, nous avons déjà interrogé plusieurs d'entre eux. Les billets d'interview sont tous notés "Communauté SEPAmail".
    Pour ceux que je n'ai pas encore interrogés, n'hésitez pas à me joindre ou à vous mettre en commentaire de ce billet.

    jeudi 2 mai 2013

    Revue de presse: avril 2013

    Voici quelques articles sur le net et dans la presse pour le mois d'Avril :

     Bonne lecture.

    lundi 22 avril 2013

    SEPAmail : quel sera le coût pour l'utilisateur ?

    Une question m'est souvent posée : quel est/sera le coût de SEPAmail pour l'utilisateur ?
    En cette période de constitution de l'offre par les différents fournisseurs du service SEPAmail, je ne peux pas, bien entendu, vous donner les tarifs exhaustifs de la messagerie, ainsi qu'un ordre de grandeur des coûts de chacune des applications prévues de SEPAmail : les services RUBIS (autour de la demande de règlement), GEMME (autour du mandat de prélèvement), DIAMOND (autour de la vérification d'identifiants bancaires).

    Chacun des acteurs sortira sa grille de tarifs lors de la commercialisation de SEPAmail, suite à l'expérimentation en cours.

    Je peux toutefois avancer quelques pistes utiles pour la compréhension du contexte, des segments, des approches et des enjeux autour de cette tarification.

    Le contexte

    SEPAmail met en jeu trois volets :
    • la messagerie, proche du mail classique, si ce n'est qu'il est sécurisé dans son transport et pour l'authentification du destinataire et de l'expéditeur
    • l'information échangée, au travers de dialogues de flux applicatifs
    • l'articulation sur un paiement
    SEPAmail amène un changement de paradigme important sur l'échange d'information et sa sécurité, puisqu'il valorise un échange pair à pair [1], ce qui pourrait restaurer la confiance dans certains échanges [2].

    Comme tout changement de paradigme, il est assez compliqué de partager une vision sur son besoin de financement.

    Souvenons-nous de la messagerie électronique, internet, la téléphonie mobile, le SMS, la téléphonie sur IP et plus récemment l'échange de données en mobilité.

    Chacun de ces usages a vu un modèle de tarification différent, avec du financement par la puissance publique pour des aspects infrastructure et d'interopérabilité de standards, avec des tarifications à l'usage, au forfait, au segment de l'usager etc...

    Pour chacun de ces usages la masse critique du nombre d'utilisateurs a été un enjeu important tout au long de l'appropriation et cette masse critique a été atteinte grâce à des segments d'utilisateurs complètement différents : les travailleurs, le grand public, les jeunes, les geeks, les petites et moyennes entreprises, les institutions.

    Chacun attend de son fournisseur SEPAmail un coût adapté à son besoin immédiat. Quand on interroge le futur utilisateur, ce coût devrait être le plus bas possible, voire gratuit, comme le mail.
    Mais est-ce vraiment le cas ? N'est-il pas prêt à payer pour un service qu'il n'a pas aujourd'hui

    Les segments

    Voici les quelques segments d'utilisateurs que j'ai recensés, suffisamment différents pour qu'une analyse spécifique soit menée.


    Les particuliers.

    Ce sont les membres des ménages qui désirent pouvoir utiliser des applications de SEPAmail, comme les demandes de règlement (RUBIS) ou les avis de règlement (JADE) ou plus simplement un mail authentifié (AGATE). Ce particuliers sont aujourd'hui équipé en téléphone mobile et matériel informatique relié à internet; ils sont habitués pour la plupart à utiliser le canal internet, mobile, agence, centre d'appel et GAB/DAB. On voit plein de cas d'usages, qui sont liés aux échanges d'information et d'initiation de paiement au sein de la tribu (familiale, amicale, associative).


    Les entreprises avec un système d'information organisé et piloté.

    Ce sont toutes ces entreprises (au sens large, du secteur privé, public ou institutionnel) qui possède un système d'information organisé et piloté. Ces entreprises peuvent être petites ou grandes. Elles se distinguent par un fort niveau d'automatisation des échanges et d'articulation des flux d'information et de paiement.
    Ce sont les entreprises dotés d'une application ERP, de points de vente électroniques, de points de vente physiques doté d'une application électronique; elles sont habituées au canaux d'échanges de données informatiques via internet ou la téléphonie mobile.
    Ces entreprises ont plein de cas d'usage de l'utilisation de SEPAmail; elles cherchent cependant à ne pas multiplier les canaux et les formats de données et à optimiser leur filière matérialisée et couteuse. Pour avoir réalisé des automatisations, elles savent que l'automatisation à 100% n'existe pas et qu'il faut également piloter et contrôler de façon fine les flux pour éviter les arrêts de service et la fraude.


    Les entreprises sans système d'information connu

    Les entreprises dont le fournisseur d'accès à SEPAmail ne connait pas le système d'information, sont assez méconnues.
    Elles ont un profil d'utilisation de canal d'échange assez proche des particuliers. Pour antant, elle sont, en général, assez intéressée pour simplifier leur organisation autour de flux couteux en organisation et prête à payer ce service.
    Fondées sur un cœur de métier sur lequel elles apportent une forte valeur ajoutée à leurs propres clients, ces entreprises sont sensibles à obtenir le même service de la part de leur fournisseur.
    Ces entreprises ne sont pas à négliger car elles constituent la grande part des clients potentiels de SEPAmail et sont prêtes, pour une très grande majorité d'entre elles, à payer un service à valeur ajoutée, que ce soit directement auprès de leur banque, ou par l'intermédiaire de leur comptable, leur avocat, un autre fournisseur de service de l'entreprise.
    Ces entreprises sont habituées à s'adapter au système d'information des institutions et des grandes entreprises fortement organisées, même si elles dénoncent la diversité de ces organisations.
    C'est ce segment qui a permis à la messagerie électronique (le mail) d'atteindre sa masse critique en Europe dans les années 1995 en ré-organisant la communication en interne et en externe autour de ce média, à la place du fax, du courrier et des tournées internes.

    Les grands remettants

    Les grands remettants sont les grandes entreprises qui mettent en œuvre des usines d'émission et de réception de flux. Ces grands remettants ont optimisé depuis l'avènement de l'informatique ces flux, notamment autour du prélèvement en France.
    Fortement impactés par la migration des moyens de paiement à la norme européenne(SEPA), ils essaient aujourd'hui de réduire le coût du chèque et de remplacer à son terme le TIP (2016) [3][4]. 
    Les grands remettants cherchent à :
    • atteindre le plus de destinataires possibles sans avoir à s'occuper du routage de l'information
    • utiliser des normes pour ne pas dépendre de son fournisseur bancaire
    • réduire le nombre de procédés d'échanges et de paiement sur leurs clients captifs afin de réduire les coûts
    Les grands remettants sont souvent cités comme ceux qui permettent d'atteindre la masse critique des utilisateurs mais, en regardant en arrière sur les vingt dernières années et les usages déjà cités, cela a été rarement le cas. Ils sont plutôt en attente du marché et des usages avant de développer une nouvelle chaîne.

    Les groupements d'intérêt pour un échange organisé d'information

    Par groupement d'intérêt pour un échange organisé d'information, j'entends par exemple :
    • une grande entreprise avec ses fournisseurs
    • les utilisateurs d'une même application informatique
    • un grande entreprise et ses différents services
    • etc...
    Ces groupements disposent déjà d'une organisation et d'une infrastructure pour échanger de l'information, souvent afin d'éviter une saisie ou un contrôle fastidieux. Ainsi, de nombreux extranet ont vu le jour pour profiter de la logique client/serveur en temps court sur un réseau peu couteux entre des acteurs.
    Ces groupements d'intérêts cherchent, pour certains, à proposer des organisations de type pair à pair, afin de ne pas concentrer trop d'information en un endroit.
    Elles cherchent aussi à sécuriser sans rassembler des authentifications diversifiées. La plupart essaie d'automatiser et de dématérialiser en dépassant la seule saisie, c'est à dire en articulant un flux d'information traitable par des automates et vérifiables par des êtres humains organisés.

    En guise de conclusion sur les segments

    Les banques qui ont lancé l'expérimentation SEPAmail, sont plus habituées à raisonner en terme de particulier/entreprises/institutions ou créancier/débteur sur ces sujets.

    Au sein de leur organisation, la monétique, les flux et la messagerie sont rarement gérés par les mêmes entités.

    SEPAmail touche ces trois secteurs.

    Fournir un accès à SEPAmail demande donc peut-être de raisonner sur de nouveaux segments, ceux-là même que les géants de l'internet ont réussi à adresser.

    Les approches


    Plusieurs approches sont possibles. Gageons que les premiers fournisseurs d'accès à SEPAmail vont adopter plusieurs approches différentes.

    Il est possible d'adopter une approche tarifaire par application de SEPAmail et raisonner sur le modèle métier d'une demande de réglement, d'un avis de réglement, d'un échange de pièce jointe ou de message court, de transmission d'un document à signer...

    Il est possible d'adopter une approche tarifaire par segment et raisonner sur le segment de clientèle, ses canaux habituels et un mode tarifaire connu et raisonnable.

    L'approche par réduction des coûts vise à connaître le cout actuel d'une chaine de traitement et son contentieux afin de proposer une solution optimisée à moindre coût. C'est cette démarche qui s'intéresse donc au prix d'un timbre, d'une lettre recommandée, d'un email en réception ou en émission, d'un web-service en réception ou en émission pour affiner le fenêtre de tarification possible pour un échange de flux.

    L'approche par les flux vise à faire payer une quotité commissionnaire sur la quantité et/ou la valeur des flux, ce qui fonctionne assez bien pour les entreprises d'intermédiation qui cherche à rendre les coûts relatifs.

    L'approche par le niveau de service s'intéresse au service selon son niveau, par exemple, pour SEPAmail, le traitement de type asynchrone comme le mail (mode canonique de SEPAmail) ou le traitement de type synchrone comme le service web (mode flash de SEPAmail)

    L'approche par service public vise à faire financer les investissement des coûts d'infrastructure par la puissance publique afin de permettre une utilisation mutualisée de ces infrastructures et financer l'accès au plus grand nombre.

    Les enjeux


    Les enjeux pour les adhérents du réseau SEPAmail dans la tarification à leurs clients utilisateurs sont multiples :
    • il leur faut répondre à un besoin client sans décevoir ce client,
    • il faut atteindre une masse critique pour que les coûts d'infrastructure soient amortis plus rapidement et que le service soit intéressant pour le client,
    • il faut respecter le principe de concurrence saine entre les banques et entre les entités en capacité de fournir un accès au service de messagerie SEPAmail,
    • il faut rentabiliser le service rapidement


    L'objectif

    L'objectif pour chaque adhérent fournisseur d'accès à SEPAmail est donc de faire payer tous les utilisateurs à un prix permettant :
    • de vendre le service,
    • de valoriser la valeur ajoutée du fournisseur,
    • de faire jouer une concurrence saine, donc non déloyale

    Références 




    mardi 9 avril 2013

    Revue de presse: mars 2013

    Voici les quelques articles que j'ai trouvés en mars 2013 sur SEPAmail :
    Bonne lecture.
      

    jeudi 4 avril 2013

    En marge de SEPAmail : 2DDoc

    Au fil du projet SEPAmail, il y a des idées (portées par des hommes) qui sont simples et réalisables... moins brillantes peut-être que les dogmes de quelques experts mais elles m'ont séduit car je crois en leur potentiel de métamorphose du sujet qu'elle traite.

    Je continue cette série par le standard récent 2DDoc, inventé par la société AriadNext et porté par Cyril Murié de l'Agence Nationale des Titres Sécurisés (ANTS).

    Les concepteurs de ce standard le présente ainsi : "Le standard à codes barres bidimensionnel 2D-Doc consiste en la sécurisation de données dans un code à barres signé électroniquement par la clé privée correspondant à une clé publique placée dans un certificat du type cachet serveur."

    Premier constat : la fraude documentaire est facile à réaliser.
    Un cas d'usage consiste à retoucher à l'aide d'une application la numérisation d'un document utilisé à des fins officielles afin de changer un élément important de ce document : une adresse, un nom, une date... tout en conservant un aspect "authentique" au document sans que cela soit facile à démontrer.


    Deuxième constat : la numérisation ne veut pas dire dématérialisation et encore moins automatisation.


    Beaucoup d'entreprises numérisent les documents qu'elles manipulent afin de les stocker, les reproduire, les sauvegarder plus facilement.
    En sus de la numérisation, il est souvent configuré une reconnaissance de caractères afin de permettre des choix sur reconnaissance d'étiquettes  identifiants, références, etc...
    Cependant, numériser et la reconnaissance de caractères ne signifie pas qu'il est plus facile d'automatiser des procédés. La notion d'encodage sous forme de code barre permet une lecture plus fiable et souvent plus facile.
    Pour automatiser les procédés à la réception d'un document matérialisés ou numérisés, la présence de code barre permet une meilleure réussite et moins de cas à traiter avec un agent humain.

    Troisième constat : pour dématérialiser de façon efficace une chaîne complète de traitement, il faut pouvoir articuler un tronçon matérialisé.
    Quand on pense dématérialisation, on doit aussi penser à rester interopérable avec des agents qui ne disposent pas de la possibilité de lire ou écrire un support dématérialisé.
    Ceci est connu des éditeurs de billets électroniques. Il faut pouvoir aussi imprimer ce billet dans certains cas.

    Fort de ces trois constats, la société AriadNext a proposé d'encoder dans un code à barre 2D les informations utiles du document pour un automate, comme le nom, le montant, la date, l'adresse etc..., signées cryptographiquement par l'éditeur du document qui, par cette signature, authentifie ces informations.
    Ce code à barre devient ainsi un sceau d'information photocopiable, imprimable, infalsifiable, lisible par un automate avec un fort taux de réussite.

    Le principal inconvénient du code barre 2D est le peu d'information que l'on peut encoder.
    l'ANTS a donc standardisé cette information sur le principe :
    • d'un entête de type nomenclature à tiroir
    • d'un corps de message de type liste de paires clés/valeurs en normalisant les clés, le type des valeurs.
    • d'une signature des informations
    sans y stocker le certificat qu'il faut donc récupérer par soi-même pour vérifier le code-barre.

    Les informations 2DDOC sont compatibles avec les types de l'iso 20022 et les relevés d'identité bancaire et les relevés d'identité SEPAmail (RIS) sont des documents reconnus par le standard.

    Ainsi, le RIS peut être encodé comme un 2DDOC : il s'appelle alors un RIS2D.

    Voici mon RIS2D 2DDoc de test avec lequel vous pouvez essayer de m'envoyer un message SEPAmail.

    Quels sont les avantages ?


    Ils sont nombreux :
    • la fraude par retouche infographique est difficile
    • l'échange d'identifiant authentifié est automatisable et plutôt ergonomique avec un smartphone
    • le standard propose une structuration des documents et des informations sensibles
    • la vérification peut-être déshumanisée, ce qui peut augmenter la sécurité pour les agents
    • la photocopie de l'identifiant authentifiable est possible
    L'authentification documentaire est un premier pas vers la vulgarisation de l'authentification et la distinction essentielle entre l'authentification d'une personne, d'un document, à distance, en présence.

    Quels sont les inconvénients ?

    L'un des plus gros inconvénients, selon moi, tient dans un des avantages.
    A ne plus pouvoir frauder par la retouche graphique, la fraude interne aux producteurs privés et publics de justificatifs va devenir visible.

    Est-ce qu'un opérateur d'énergie ou de téléphonie va vraiment vouloir faire plus qu'authentifier un document et un montant et devenir responsable, sous son sceau et son organisation, de l'authentification d'une personne, d'une domiciliation, d'une date de naissance ?

    On peut reprocher aussi au standard de ne pas expliciter suffisamment les limites d'utilisation d'une clé privée, notamment l'usure de la clé utilisée par rapport à l'usage.

    Pour ceux qui liront la spécification technique, ils verront qu'il n'est pas possible de donner autre chose qu'une date limite d'utilisation, ce qui n'est pas très international. La norme possède également une limite intrinsèque liée au nombre maximum de jours depuis le 1er janvier 2000, à savoir 65535 jours donc elle ne sera plus valable en 2180 !

    Enfin, par manque de place, il n'a pas été prévu de pouvoir insérer une clé publique liée à l'identifiant, ce qui aurait résolu nombre de difficultés cryptographiques d'inscription, notamment pour les relevés d'identité bancaire.

    Pour aller plus loin

    dimanche 24 mars 2013

    SEPAmail au coeur d'une solution pour remplacer les espaces clients "non markettés"

    Il y a de nombreux espaces clients virtuels

    De nombreux espaces clients virtuels se sont mis en place au fil des années, la plupart sur les modèles des boutiques eCommerce et marketés selon les mêmes principes.

    Ainsi, aujourd'hui, chacun d'entre nous peut :
    • voir ses remboursements de sécurité sociale sur son espace dédié de la CPAM, RAM, MSA etc...
    • déclarer et consulter ses impôts
    • récupérer ses remboursements de mutuelle
    • déclarer ses emplois à domicile
    • consulter ses déclarations CAF
    • etc...
    De même, les entreprises ont un espace de consultation et de déclaration pour :
    • le RSI URSSAF
    • le RSI RAM
    • les impots
    • les caisses de retraites
    • les organismes de formation
    • etc...
    Tous ces espaces sont opérés et édités à grands frais par les institutions avec des critères de sécurités pas forcément homogènes, une authentification dédiée, des alertes par courriel avec des informations non anonymes.

    Le papier a été remplacé par des documents numériques dans autant d'espaces que d'éditeurs de documents, avec une logique de stockage assuré et financé par l'éditeur au lieu et place du destinataire.

    Le principe sous-jacent peut s'énoncer ainsi :
    "Nous, les éditeurs de papier, nous avons intérêt à dématérialiser pour notamment faire des économies. Nous sommes prêts à financer des espaces de stockage pour nos destinataires car cela nous coutera moins cher, même si, avec ce service, nous changeons totalement les usages, la structure de coûts et les responsabilités autour du stockage, de la preuve et de la sécurité."

    Ce principe n'est pas très efficace car il change fondamentalement les règles de confiance entre les expéditeurs et les destinataires de ces documents; alors même que cette confiance repose depuis des siècles sur le pair à pair et le rebond de l'authentification.

    La confiance est primordiale.

    Or, la confiance est primordiale dans les relations entre les entités économiques et il est important de ne pas déresponsabiliser l'utilisateur et le bénéficiaire des services collectifs.

    Avec SEPAmail, l'approche de la dématérialisation et de l'automatisation est différente.
    SEPAmail sécurise l'échange d'informations sans changer la nature et l'enjeu des stockages existants ou à venir.

    Ainsi, un particulier peut choisir de matérialiser tous les documents qui lui arrivent ou les stocker de façon sécurisée ou non, dans en endroit unique ou non, il reste responsable et maître du stockage des documents.

    Il ne dépend pas de nombreux éditeurs et de chacune des implémentations en terme de lecture de document, d'espaces de stockage et de sécurité de ses informations.

    Le destinataire doit rester maitre à bord de son système d'information.

    L'utilisateur reste le maitre à bord, quelque soit l'expéditeur du document.
    Ainsi, l'utilisateur peut s'organiser de façon durable et personnalisée, comme autrefois pour son organisation de courriers.
     
    Qu'en est-il des espaces clients des nombreux fournisseurs de services, espaces largement marketés ?



    Les usages du web et la création de compte deviennent la norme... au risque de perdre toute confiance avec son client.

    J'ai lu récemment un billet sur la promotion des commandes en ligne sans création de compte client... grand bonheur de l'acheteur soucieux de ne pas être une cible marketting ou publicitaire de plus.

    Les stratégies sont difficiles pour ces utilisateurs, car ce sont plutôt les usages du web commercial qui s'imposent même dans la vie physique et pour la plupart des actes de la vie réelle... Aujourd'hui, on vous demande souvent de créer, de temps en temps à votre insu, un compte client pour pouvoir vous atteindre, vous segmenter...

    Là encore, SEPAmail permet facilement le paiement sans création de compte avec les applications RUBIS et GEMME, tout simplement car SEPAmail met en avant un adressage mondial des entités économiques protégé par le réseau des banques des utilisateurs.

    Avec des coûts annoncés très faibles et un spam difficile sans se griller définitivement sur le réseau, SEPAmail est sûrement un moyen efficace de communiquer avec son client en toute confiance et authentification avec un ré-équilibrage de la relation par la possibilité pour chaque client de décider de ce qu'il reçoit, et de qui il le reçoit.

    L'important pour la confiance numérique de demain, c'est de pouvoir informer et vendre le meilleur produit pour son client... en toute responsabilité et toute transparence.

    Pour aller plus loin

    Je suis intéressé par vos remarques sur ce sujet et les développements d'usages que permet la notion de messagerie sécurisée, comme SEPAmail.

    vendredi 15 mars 2013

    En marge de SEPAmail : SAPPhire, prometteur

    Au fil du projet SEPAmail, il y a des idées (portées par des hommes) qui sont simples et réalisables... moins brillantes peut-être que les dogmes de quelques experts mais elles m'ont séduit car je crois en leur potentiel de métamorphose du sujet qu'elle traite.

    Je démarre avec une idée conjointe d'Alain Mazieras et Cyril Vignet : SAPPhire pour Standard pour une Authentification des Personnes et des Programmes, Haute interopérabilité et ré-utilisation en Extension (en français) ou Standard Authentication Persons & Programs High Interoperability and ReUse Extension (en anglais).


    Le constat vient de le la nature même de l'authentification des êtres humains à distance.
    Difficile, elle fait beaucoup parler les experts mais reste obscure pour les utilisateurs. Elle est notamment dangereuse car incomprise.

    SAPPhire amène deux idées simples :
    • idée 1 : on ne traite pas tous les cas mais seulement les trois principaux, ceux les plus utilisés et on les classe en trois niveaux
    • idée 2 : on met en avant un fondamental de sécurité : l'authentification par rebond
    Détaillons un peu ces deux idées.

    Les niveaux SAPPhire orientés usages


    Les usages nécessitant une authentification à distance déclarée sont :
    • la consultation
    • l'action
    • la signature
    • les autres cas (pour ne pas oublier !)
    SAPPhire propose trois niveaux correspondant aux trois premiers cas:
    • SAPPhire 1 : les conditons de la consultation
    • SAPPhire 2 : les conditions de l'action
    • SAPPhire 3 : les conditions de la signature numérique
    auxquels on pourrait rajouter, pour être clair :
    • SAPPhire 0 : les conditions de la non authentification
    Pour prendre un exemple concret : quand vous vous connectez à votre webmail favori:
    • pour consulter vos mail, vous êtes en SAPPhire 1
    • pour écrire un mail, vous êtes en SAPPhire 2
    • pour signer un contrat, vous êtes en SAPPhire 3
    On voit que ce genre d'approche tient pour les usages courants depuis quelques dizaines d'années et peut durer encore quelques dizaines d'années.

    Comment se décline techniquement ces niveaux ?

    C'est bien entendu la question de SAPPhire. SAPPhire répond en fonction de l'état de l'art du moment. En ce moment, nos experts parleront de scoring et de cryptographie... jusqu'à ce que ces technologies soient dépassées ou passées de mode.

    Les niveaux SAPPhire résisteront aux changements de mode puisqu'ils sont orientés usages et non techno.

    L'authentification par rebond



    Pour faire simple, l'authentification (en présence ou à distance) repose toujours sur un rapprochement entre des identifiants connus et des identifiants présentés.
    Pour authentifier sereinement, il faut sécuriser ces trois points :
    • les identifiants connus
    • le rapprochement
    • la présentation des identifiants à rapprocher
    On en vient vite à un problème qui boucle sur lui-même, ce qui n'aide pas la sérénité.

    Il est d'usage, pour éviter ces bouclages, de rebondir sur du connu :
    • quelques personnes connues se portent garant de vous
    • vous présentez une identification standard pour vous authentifier (par exemple une pièce d'identité)
    SAPPhire propose un mécanisme d'inscription au service reposant :
    • soit sur un rebond après, en validant une inscription a posteriori sur un canal sécurisé (par exemple un distributeur automatique de billet)
    • soit sur un rebond avant, en validant une inscription a priori avec un authentifieur sécurisé (par exemple une clé ebics)
    • soit sur un rebond réseau, en validant une inscription à l'aide de personnes authentifiées d'un réseau validant l'authentification avec leur propres critères et s'engageant sur cette authentification

    Que faut-il a SAPPhire pour devenir un standard ?


    SEPAmail fait la promotion de SAPPhire pour l'inscription au service sur le canal courriel sécurisé ou application mobile.

    Cependant, SEPAmail ne suffira pas à généraliser SAPPhire. Il faudrait que les concepteurs de SAPPhire ou des volontaires, proposent une formalisation de ces deux principes au sein d'une RFC pour l'ietf par exemple ou encore qu'une institution comme l'Europe décide d'inclure ce type d'approche dans son référentiel de sécurité.

    Avec l'avènement de sociétés gigantesques auto-proclamées tiers de confiance et de la cacophonie qu'elles proposent autour de l'indexation des populations, gageons que cette normalisation (ou une équivalente) va devenir nécessaire rapidement.

    Pour aller plus loin

    dimanche 24 février 2013

    Communauté SEPAmail : SMETH, l'extension thunderbird

    SMETH est l'acronyme de SepaMail Extension THunderbird.

    A quoi cela sert ?


    SMETH est une extension thunderbird qui permet de recevoir et d'envoyer dans son client de messagerie habituel un message SEPAmail avec une ergonomie proche de celle d'un mail classique.

    SMETH met en forme automatiquement le xml sous forme de formulaire et extrait automatiquement les contenus binaires sous une forme ressemblant aux pièces jointes SMTP.

    SMETH permet trois usages différents :
    • client de messagerie SEPAmail
    • plateforme de test du mode canonique
    • conception de nouvelles applications de SEPAmail

    Où le trouver ?


    SMETH a été publié sur la plateforme de code google, sous le nom de code sepamail-smeth.
    La page du projet se trouve ici.

    Les spécifications fonctionnelles sont ici.
    Le code source du projet est ici.


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


    Le logiciel a été développé en langage javascript+xul+xsl sous une licence d'utilisation open source (GPLv3).
    Il utilise des composants et des bibliothèques qui sont toutes sous une licence open source.

    Tout le monde peut donc utiliser tout ou partie de SMETH sous les conditions des licences d'utilisation, notamment en respectant le droit des auteurs.


    Ce composant fait-il partie du standard de SEPAmail ?


    Le standard n'a pas vocation à inclure des implémentations logicielles.
    Donc ce composant ne fait pas partie du standard.

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


    Oui.

    • SMURF est un composant permettant de publiposter des missives SEPAmail depuis un système d'information d'entreprise.
    • SMOC est un composant qui constitue une enveloppe SEPAmail, l'envoie et se synchronise avec un compte IMAP
    • SMIC est un composant qui permet d'implémenter une conversion entre le format PDF et le format XML
    • SMAC est un composant qui permet de passer du mode d'échange canonique au mode flash.
    • SMACK est un composant qui met en œuvre l'acquittement de SEPAmail de façon automatique
    • SMITE est un jeu de données de test partagé

    mercredi 20 février 2013

    Communauté SEPAmail : Syrtal

    Nous continuons notre tour des entreprises de la communauté SEPAmail avec le groupe Syrtals.

    J'ai rencontré et interrogé Laurent Rouillac, pdg de Syrtals System integration.

    Quand a été créé Syrtals, dans quel contexte ?


    SYRTALS a été créé en 1997 par des experts Cash Management et Moyens de paiement Bancaire et Corporate sur la base de la difficulté récurrente des métiers de faire évoluer les processus et les offres notamment Informatiques dans le sens de leurs besoins et de ceux de leurs clientèles.

    Le métier de SYRTALS au travers ses 60 consultants est de conduire le changement dans ces domaines du Cash and Payment, du conseil à la mise en marché en mobilisant des profils de différents niveaux de séniorité qui vont du Directeur d'activité au chef de projet junior.
    Tous les livrables qui vont de l'étude stratégique, étude d'opportunité, cahiers des charges, expression de besoins spécifications fonctionnelles stratégies de recette, organisation, formation (nous sommes organisme agrée) etc.. sont produits par nos soins auprès de la quasi-totalité des banques en France et des grands Corporates avec un certain nombre d'incursions auprès de banques dans d'autres pays de la zone.

    Quelles sont vos spécificités ?


    Une des particularités de SYRTALS est d'intervenir auprès de tous les acteurs des processus Cash et payment et de disposer au travers de ses offres d'une couverture totale de ces métiers : Les activités sont structurées suivies et animées en terme de formation interne et externe, marketing, en domaines :
    • Gestion de trésorerie
    • Moyens de Paiement (Cartes, MDP électronique, NSP etc.)
    • Trade Finance(Credoc garantie cautions )
    • Dématérialisation (Web Banking - canaux - Factures - relevés - contrats - signature etc.)
     

    Quelle est votre implication dans la communauté SEPAmail ? Quelle évolution pour la suite ?

    Nous sommes très impliqués dans Sepamail sur tous les plans marketing technique et expérimentation, c'est un des sujets d'avenir pour le domaine des Moyens de paiements et nous disposons d'un volume d'expertise en consultant très important sur ce sujet.


    Références webographiques de Syrtals sur le sujet SEPAmail

    dimanche 17 février 2013

    Humeur : le besoin d'un message sécurisé entre pairs

    Une fois ne sera pas coutume, un petit billet d'humeur, à l'attention de Cyril, l'inventeur de SEPAmail, qui m'a permis de voir de l'indicible.


    Au début était le verbe au sein de petits groupes d'individus.

    Puis la lettre qui permit :
    • au verbe de transcender le groupe, les dimensions temps et espace,
    • à la confiance de se médiatiser sur un support.
    La vitrine matérialise cette transparence entre le dehors et le dedans, espace de service, mais aussi de convoitise.

    Internet généralise une numérisation (pas si dématérialisée) et se cristallise en un univers (couteux en énergie et en infrastructure) permettant de rapprocher des individus distants connus et inconnus. La confiance se virtualise en propos d'experts incompréhensibles sans incarnation partagée.

    La multiplication des extranets réglementaires ou commerciaux emprisonne de plus en plus l'utilisateur devenu produit. Ces extranets sont autant de naufrages de sécurité pour des utilisateurs sollicités sur des identifiants et des mots de passe, comme au temps de leurs jeux guerriers et enfantins.

    Le message pair à pair sur internet est le plus souvent insécurisé et insécurisant... qu'il soit chat, mur ou courriel, il est instantané, public, écrit , souvent polluant et tout sauf authentique.

    Nous avons besoin d'un message sécurisé entre pairs pour réincarner de la confiance, le socle indéniable de nos sociétés humaines.

    jeudi 7 février 2013

    Communauté SEPAmail : ASTEK

    J'ai interrogé Lionel Chemla, de la société ASTEK, qui accompagne depuis 2011 la moa BPCE dans son expérimentation, le suivi de l'éditeur et l'intégration de SEPAmail dans le système d'information de la Banque.

    Fort de cette expérience, ASTEK a constitué une équipe SEPAmail et assiste aujourd'hui d'autres banques.

    Quand a été créé ASTEK, dans quel contexte ?


    Créé en 1988, Astek est un groupe français indépendant, devenu un acteur majeur du service informatique. Réunissant plus de 2900 collaborateurs, Astek réalise un chiffre d'affaires de 205 MEuros. Les expertises techniques et fonctionnelles du groupe s'articulent autour de quatre grands métiers :
    • Conseil
    • Systèmes d?information
    • Ingénierie scientifique et technique
    • Infogérance

    Positionné sur l'innovation technologique, Astek a gagné la confiance de ses clients en intégrant avec succès, sur le long terme, leurs enjeux business et les technologies

    Quelles sont vos spécificités ?



    Depuis sa création en 1988, Astek a toujours bousculé les référentiels avec comme objectifs : servir les clients, trouver les meilleures solutions, grandir et prendre du plaisir au challenge. Cette culture a déterminé trois des cinq valeurs fondatrices du groupe : l’audace, la satisfaction client et l’engagement. Deux autres valeurs fondamentales viennent compléter notre ADN : technologie et capital humain.

    Technologie parce qu’innover aujourd’hui est essentiel aux entreprises dans leur recherche de compétitivité. Celles-ci font davantage confiance aux technologies pour innover et leurs consacrent une grande part de leurs investissements. Elles ont besoin de prestataires de service innovants et agiles pour les aider à tirer parti des progrès technologiques.

    Capital humain, car pour servir les entreprises en créant de la valeur, il faut disposer des meilleures compétences. Astek sait attirer en permanence de nouveaux talents et les guider vers l’excellence.

    Nos enjeux d’aujourd’hui sont triples : conjuguer service et industrialisation, accompagner nos clients là où ils sont, conquérir des marchés émergents ou fortement concurrentiels, notamment par la réussite de projets réalisés en méthodologie agile avec un retour sur investissement rapide.

    Nous atteignons ces objectifs tout en maintenant la relation personnelle avec nos clients. C’est indispensable pour leur apporter la compétence, l’expérience, la créativité et une organisation adaptée : dispositif de proximité (20 implantations en France), capacité de production élargie en offshore (6 implantations) et un développement international sur 11 pays (UK, Pologne, Suisse, Espagne, Tunisie, Chine, Brésil, Mexique, Vietnam, Maurice, Brésil).


    Quel est le profil de vos clients, quelles sont vos références ? 


    Nous intervenons dans les secteurs d’activité suivants suivant les proportions indiquées entre parenthèses :
    • Transports (29%),
    • Télécom (20%),
    • Défense, Aéronautique & Spatial (15%),
    • Industries & Services (15%),
    • Banque & Assurance (10%),
    • Energie (6%),
    • Secteur Public (5%).

    Nos domaines d’expertise sont schématisés par notre pyramide des offres ci-dessous :

    Quelle est votre implication dans la communauté SEPAmail ? Quelle évolution pour la suite ?


    Astek a conçu une proposition de valeur autour de SEPAmail, que l'on retrouve sur le schéma ci-dessous :


    mardi 29 janvier 2013

    Communauté SEPAmail : AriadNext

    Nous continuons notre tour d'horizon de membres de la communauté SEPAmail avec la société AriadNext, contribuant depuis 2009 notamment pour des applications entre l'adhérent et son client, l'utilisateur.

    Marc, Guillaume et Tristan ont répondu à nos questions.

    Quand a été créé AriadNEXT et dans quel contexte ?


    AriadNEXT est avant tout issue de la rencontre au sein de SFR entre deux personnes : Guillaume DESPAGNE et Marc NORLAIN. Alors que le premier, spécialiste de l’organisation de la distribution, cherchait des moyens de simplifier le processus d’enrôlement en point de vente, le deuxième, expert en lutte contre la fraude, voulait sécuriser ce même processus d’enrôlement. En dépit de l’apparente contradiction entre leurs problématiques, Guillaume et Marc ont décidé de travailler conjointement sur ces sujets et ont finalement mis au point une solution originale et efficace permettant d’optimiser l’enrôlement en point de vente.

    Lauréate de plusieurs concours d’innovation, cette solution a rencontré un réel succès qui a incité SFR à externaliser le projet. En 2010, AriadNEXT est ainsi créée dans le but de développer et commercialiser la solution d’optimisation de l’enrôlement.

    Combien de collaborateurs, quels sont leurs profils et leurs fonctions ?

    AriadNEXT compte aujourd’hui 22 collaborateurs, essentiellement des ingénieurs et docteurs en informatique. De par la nature des produits développées par AriadNEXT, nous avons la spécificité de compter parmi nous à la fois des profils spécialisés en conception matérielle (mécanique et électronique), des experts en système d’exploitation et des ingénieurs en développement logiciel (sécurité, systèmes d’information, analyse d’image, applications mobiles).

    Nous attachons une grande importance au fait que chaque collaborateur soit affecté à la fois à des tâches de R&D avancée et de déploiement ou de maintenance des solutions AriadNEXT.

    Quels sont les principaux produits ou services développés et vendus ?


    Le produit phare d’AriadNEXT est le S<CUBE. Il s’agit de la réponse concrète aux deux problématiques initiales : la simplification du processus d'enrôlement couplée à la lutte contre la fraude.

    Ce terminal, déployé dans un millier de points de vente, permet de scanner des pièces justificatives (carte d’identité, chèque, …) tout en vérifiant leur authenticité. Cela sécurise et facilite le processus de souscription puisque les informations extraites des pièces justificatives sont utilisées pour pré-remplir le contrat du client. Le terminal est également utilisé pour effectuer une signature électronique qualifiée du contrat et ainsi donc dématérialiser totalement la souscription tout en conservant une valeur légale similaire à un processus manuel.

    En outre, AriadNEXT offre plusieurs services pour répondre efficacement aux problématiques de dématérialisation et de lutte contre la fraude comme: 2D-Doc, S<MARTSTAMP, S<MARTCAM, ICheckItAU… avec une attention particulière portée aux applications mobiles de dématérialisation, de contrôle de pièces et de signature électronique.

    Quel est le profil de vos clients, quelles sont vos références ?

    Nous travaillons essentiellement aujourd’hui avec des opérateurs en téléphonie mobile, mais notre solution en point de vente est applicable à un grand nombre de situation d'enrôlement client et de signature de contrat.

    Pour nos solutions d’apposition de code sécurisés 2D-Doc, nous sommes également amenés à travailler avec différents émetteurs de factures, RIB ou autres documents à sécuriser.

    Nous travaillons aujourd’hui notamment avec SFR qui a déployé notre S<CUBE dans plus de 900 points de vente et appose aujourd’hui plus de 5 millions de 2D-Doc mensuellement. Virgin Mobile et Auchan commencent également à équiper leurs boutiques de S<CUBEs

    Nous fournissons également des applications mobiles à destination du grand public pour le contrôle de pièces d'identité ou la dématérialisation des pièces justificatives lors de souscriptions en ligne.

    Quelles sont vos spécificités ?

    La spécificité d’AriadNEXT est d’avoir fait de la gestion de l’enrôlement une thématique à part entière pouvant tirer partie de nombreuses technologies : acquisition et contrôle de pièces justificatives, dématérialisation, archivage, signature électronique, ... 

    De plus, AriadNEXT développe ses solutions avec une approche orientée service : les briques technologiques listées ci-dessus sont implémentées comme des services indépendants et sont combinées pour s’adapter à des besoins et contextes spécifiques.

    Quel est votre lien à SEPAmail ?

    Dans le cadre de la dématérialisation de la souscription de contrats en point de vente, la question de la prise en charge des autorisations de prélèvement s’est rapidement posée. En effet, s’il n’y a plus de contrat papier, comment demander à un client de transmettre une autorisation de prélèvement à sa banque ? Dès 2008, Guillaume DESPAGNE a discuté de ce sujet avec Cyril VIGNET et a contribué à la définition des besoins de SEPAmail.  Par la suite, AriadNEXT a développé un connecteur permettant à un créancier d’émettre et recevoir des missives SEPAmail.

    SFR, via le connecteur AriadNEXT, a donc été le premier utilisateur de l’application GEMME et, aujourd’hui, c’est plus de 40 000 autorisations de prélèvement qui ont été dématérialisées avec SEPAmail.

    Suite à ce succès, AriadNEXT s’est imposé comme un partenaire naturel du projet SEPAmail et a développé plusieurs logiciels, notamment un client SEPAmail pour Android et un serveur SEPAmail utilisé dans le cadre de la démonstration e-commerce menée par SEPAmail.eu.

    Quel est votre implication dans la communauté SEPAmail ?

    Nous avons un double rôle au sein de la communauté : d’une part nous sommes éditeurs de logiciels SEPAmail à part entière, comme expliqué précédemment. D’autre part, nous communiquons auprès de nos clients (grands créanciers et services publics) sur les opportunités offertes par SEPAmail.

    A ce propos, nous préparons une matinale autour de ce sujet le 27 mars prochain. L’objectif de cette matinale est double : montrer les opportunités que représentent SEPAmail pour les créanciers et les e-commerçants puis détailler l’offre SEPAmail d’AriadNEXT. Les personnes qui le souhaitent peuvent demander une invitation en envoyant un email à sepamail _at_ ariadnext.com.

    Quelle évolution pour la suite ?


    L’année 2013 devrait permettre à AriadNEXT de s’affirmer en tant qu’éditeur de logiciels SEPAmail. Cela va passer par le renforcement de l’offre pour les créanciers (connecteur SEPAmail en mode hébergé) mais également par l’ouverture d’un service à destination des banques. Ce projet en cours de finalisation permettra aux banques non encore rattachées au réseau SEPAmail de se connecter simplement, sans faire d’évolutions lourdes dans leur infrastructure.

    A plus long terme, le but d’AriadNEXT est de contribuer au développement durable de SEPAmail pour pouvoir ensuite construire par dessus des services liés au coeur de métier d’AriadNEXT : vérification de coordonnées bancaires, dématérialisation de mandats SEPA, ...

    mercredi 23 janvier 2013

    SEPAmail et les wallets : comment est-ce que cela s'articule ?

    Le wallet


    Un porte-feuille électronique (ou wallet) est un stockage virtuel d'identifiants bancaires permettant d'initier des paiements de type électronique.

    Le wallet est donc une fonctionnalité orientée stockage.

    Plutôt que d'avoir sur vous votre chéquier, un porte-feuille contenant des billets et des pièces ou un porte-carte contenant de nombreuses cartes bancaires ou autre, le wallet vous propose de dématérialiser tout cela en un seul stockage virtuel pouvant être accédé par une application de votre téléphone portable ou votre ordinateur.

    L'intérêt est évident car cela évite d'avoir toutes ses cartes dans son portefeuille physique, voir d'avoir un portefeuille... Le wallet peut en interface avec certains sites douteux générer un code de carte (PAN) unique afin de ne pas corrompre les identifiants bancaires... On peut même imaginer qu'il n'y ait plus de cartes bancaires physiques.

    La sécurité de ce stockage et de votre authentification sont garantis, la plupart du temps par des techniques de cryptographie et une bonne assurance de l'éditeur de la solution.
    Il faut en effet sécuriser :
    • votre authentification sur votre terminal (smartphone ou pc)
    • votre espace virtuel dans le cloud, hébergé par votre éditeur, contenant vos identifiants bancaires et les fonctions pour les transmettre à un tiers
    • votre terminal (smartphone ou pc), dit environnement local de confiance qui réalise les opérations de cryptographie et qui est souvent le point faible du dispositif
    • la liaison entre votre smartphone et le terminal de paiement, souvent sans contact
    Toutes les techniques nécessaires sont connues pour cette sécurisation ainsi que de nombreuses failles. Peu d'acteurs communiquent dessus. Je vous renvoie à mon billet sur la cryptographie pour comprendre comment certains experts plutôt dogmatiques mettent en avant des systèmes qui seraient ultimes. Cela rassure et cela s'assure...
    Le portefeuille électronique est donc la combinaison de deux modules
    • le cœur du métier d'une application de paiement et de consultation
    • un espace de stockage numérique (on pourrait dire dématérialisé pour l'utilisateur)http://sepamail.blogspot.fr/2012/07/sapphire.html
    Entre les deux, les flux sont le plus souvent propriétaires en mode client/serveur sans interopérabilité annoncée entre les différentes solutions
    du marché.

    SEPAmail


    SEPAmail est un standard d'échange de données sécurisé, ouvert et structuré.

    SEPAmail codifie des fonctionnalités orientées flux.

    SEPAmail permet le transport de toutes sortes de messages et de réaliser toutes formes de dialogues, du moment que le contenu du message et la séquence du dialogue sont structurés et prédéfinis.

    Par exemple, SEPAmail permet d'échanger une demande de paiement et son refus/acceptation entre deux personnes, quelques soient les applications utilisées, les canaux d'initiation du paiement, les banques, les supports sécurisés des identifiants bancaire etc.
    Les banquiers expérimentent une application utilisant SEPAmail qui s'appelle RUBIS. Elle permet cet échange d'information d'une demande de règlement entre leur clients, qu'ils soient particuliers, entreprises ou institutions.

    SEPAmail permet d'inventer des dialogues divers. Plusieurs ont déjà été proposés à la communauté :
    • autour de la demande de règlement (application RUBIS),
    • autour de la signature de document (application JASPE)
    • autour du mandat de prélèvement (application GEMME)
    • autour de l'avis de règlement (application JADE)
    • autour de la transmission de facture complexe (application IOLITE)
    • autour du simple courriel ou du sms (application AGATE)
    • autour de la vérification d'identifiant bancaire (application DIAMOND)
    SEPAmail n'est donc pas un moyen de paiement; Il dit comment codifier un échange d'information qui permet éventuellement d'articuler une initiation de paiement et donc un paiement.

    SEPAmail et les wallets


    SEPAmail étant orienté flux, il permet de rendre interopérables des modules fonctionnels entre eux, relevant d'authentification différentes.

    Cela pourrait être notamment :
    • un wallet et un coffre-fort électronique,
    • un wallet et un site eCommerce,
    • un wallet et un système d'information bancaire
    • un wallet et un DAB (Distributeur automatique de billet)
    • un wallet et une caisse/tpe
    Le site eCommerce est un bon candidat pour mettre en oeuvre SEPAmail avec les wallets car aujourd'hui l'éditeur du site est innondé d'offres de paiements diverses qui lui demandent de gérer une page de paiement illisible pour son client, des connexions concurrentes à d’innombrables interfaces propriétaires (API).

    Si on prend le parallèle avec le point de vente physique, on est à l'époque où chacun proposait un terminal de paiement électronique (tpe) différent.
    Imaginez le commerçant avec un TPE différent pour visa, mastercard, l'american express etc...

    Il est vrai que, dans le domaine domestique, les téléspectateurs ont bien accepté depuis plus de 10 ans d'avoir 2 à cinq télécommandes dans les mains.

    L'avenir nous dira si les éditeurs de boutiques e-Commerce acceptent de développer N prises de paiement à des wallets ou, comme beaucoup d'entre eux, s'ils préfèrent faire faire le travail par un intermédiant comme ogone, system-pay, paybox, etc... et les réactions de ces intermédiants à la multiplication des prises de paiement.

    SEPAmail permet-il de sécuriser l'authentification des personnes  pour le wallet ?


    Oui et Non.

    Oui, car SEPAmail ne peut être mis en œuvre que dans des conditions d'authentification des personnes garanties par le fournisseur de l'accès à SEPAmail (adhérent du réseau).

    Oui, car SEPAmail permet de transporter les éléments sécurisés nécessaires aux techniques de cryptographie.

    Non, car SEPAmail ne codifie rien sur la nature de cette authentification, laissant l'adhérent mettre en œuvre sa solution vis à vis de ces clients.

    Par contre, SEPAmail propose de généraliser un autre protocole qui pourrait faire référence dans ce domaine s'il venait à être généralisé: SAPPhire.

    Avec SAPPhire + SEPAmail, n'importe quel wallet est interopérable avec application mobile, boutique e-commerce et module fonctionnel en général.

    Gageons que les quelques acteurs monopolistiques qui essaient d'occuper 80% du marché vont se faire tirer l'oreille par les nombreux utilisateurs des moyens de paiements électroniques.