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