#2 DÉFINIR POURQUOI L’ARCHITECTURE MACH S’ADAPTE BIEN À L’ECOMMERCE
#2 DÉFINIR POURQUOI L’ARCHITECTURE MACH S’ADAPTE BIEN À L'E COMMERCE
3 juin 2024
Architecture
Erik Zanga
Manager Architecture
L’architecture MACH convient-elle à tous les métiers et cas d’usages, ou existe-t-il des situations où elle est plus avantageuse et d’autres où elle est moins adaptée ?
Pour répondre à cette question nous allons à nouveau décomposer ce style d’architecture dans ses 4 briques essentielles : Microservices, API First, Cloud First et Headless.
La lettre M : Micro-services
C’est probablement ce premier point qui dirige notre choix de partir vers une architecture MACH vs aller chercher ailleurs.
Nous pourrions presque dire que si l’architecture s’adapte à un découpage en Micro-services, le MACH est servi.
Pour aller un peu plus dans le détail, nous allons introduire le concept de “point de bascule” dans le parcours utilisateur. Nous définissons “point de bascule”, dans un processus, chaque étape qui permet de passer d’une donnée à une autre, ou d’un cycle de vie de la donnée à une autre.
Une première analyse pour comprendre si notre architecture s’adapte ou pas à une architecture MACH, est d’établir si dans le parcours utilisateur nous pouvons introduire ces points de bascule, qui permettent de découper l’architecture des front-end et back-end en micro front-end et micro-services.
Un processus eCommerce par exemple s’adapte bien à ce type de raisonnement. Les étapes sont souvent découpée en :
Recherche dans le catalogue
Mise en panier
Confirmation
Paiement
Gestion de la livraison
Ces 5 étapes traitent les données de façon séparée, et sont donc adaptées à un découpage en Micro-services.
Résultat : Le “M” de MACH et l’efficacité de cette architecture est fortement liée au cas d’usage et au domaine d’application.
La lettre A : API-First
Qui parle web a forcément dû penser aux APIs, dans le sens de Rest API, pour garantir la communication entre front-end et back-end.
Pas de surprise que cela s’adapte à pas mal de solutions, car la communication entre le front-end (navigateur) et le back-end (application) se base sur le protocole HTTP et donc très adapté à ce type d’interface.
Nous ajoutons à tout ça le fait que la création d’un Micro-services et d’un Micro front-end, avec un découpage vertical sur les données traitées, implique naturellement la mise en place d’APIs et ressources spécifiques à chaque étape du parcours client.
Le contexte eCommerce, encore une fois, est bien adapté à ce cas de figure. Les étapes de parcours dont nous avons parlé avant s’inscrivent dans une logique d’APIsation, avec pour chacune d’entre elles une API dédiée.
Recherche dans le catalogue : adresser une API produits
Mise en panier : adresser une API panier ou devis
Confirmation : adresser une API commande
Paiement : adresser les APIs de paiement d’un prestataire (PSP, orchéstrateur de paiement, etc.)
Gestion de la livraison : adresser une API livraison
Résultat : Le “A” de MACH impacte moins que le “M” dans le choix de l’architecture mais épouse bien les concepts définis dans le “M”. Il est donc également très approprié pour un contexte eCommerce.
Pexels – ThisIsEngineering
La lettre “C” : Cloud-Native
Ce cas est probablement le plus simple : les seules raisons qui nous poussent à rester chez soi (infrastructure on premise), à ne pas s’ouvrir au cloud aujourd’hui sont de l’ordre de la sécurité, de l’accès et de la confidentialité de nos données (éviter le Cloud Act, etc.).
Au-delà de ces considérations, le passage au Cloud est une décision d’entreprise plus dans une optique d’optimisation de l’infrastructure que dans le cadre d’un cas d’usage, de processus spécifiques.
Résultat : Le “C” de MACH n’est pas d’un point de vue architectural pure une variante forte.
Néanmoins si nous regardons le cas d’usage cité auparavant, eCommerce, les restrictions sont levées car qui parle eCommerce parle naturellement d’ouverture, de mise à disposition sur le web, d’élasticité, concepts bien adaptés au contexte Cloud.
La lettre “H” : Headless
L’approche Headless convient particulièrement aux entreprises qui recherchent une personnalisation poussée de l’expérience utilisateur et qui ont la capacité de gérer plusieurs interfaces utilisateur en parallèle.
C’est le cas pour du eCommerce, où l’évolution rapide, le time to market et la réactivité au changements du marché peuvent influencer l’appétence, le ciblage du besoin client et le taux de conversion.
Résultat : Le « H » de MACH souligne l’importance de l’expérience utilisateur et de la flexibilité dans la conception des interfaces. Il est particulièrement avantageux dans les contextes où la personnalisation et l’innovation de l’interface utilisateur sont prioritaires. Cependant, il nécessite une réflexion stratégique sur la gestion des ressources et des compétences au sein de l’équipe de développement.
En somme, l’architecture MACH offre une grande flexibilité, évolutivité, et permet une innovation rapide, ce qui la rend particulièrement adaptée aux entreprises qui évoluent dans des environnements dynamiques et qui ont besoin de s’adapter rapidement aux changements du marché. Les secteurs tels que l’e-commerce, les services financiers, et les médias, où les besoins en personnalisation et en évolutivité sont élevés, peuvent particulièrement bénéficier de cette approche.
Cependant, l’adoption de l’architecture MACH peut représenter un défi pour les organisations avec des contraintes fortes en termes de sécurité et de confidentialité des données, ou pour celles qui n’ont pas la structure ou la culture nécessaires pour gérer la complexité d’un écosystème distribué. De même, pour les projets plus petits ou moins complexes, l’approche traditionnelle monolithique pourrait s’avérer plus simple et plus économique à gérer.
En définitive, la décision d’adopter une architecture MACH doit être prise après une évaluation minutieuse des besoins spécifiques de l’entreprise, de ses capacités techniques, et de ses objectifs à long terme.
L’architecture MACH, de par son acronyme, regroupe quatre pratiques courantes et actuelles dans le développement d’applications web.
C’est quoi Architecture MACH ?
Dans ce premier volet, nous allons nous concentrer sur les concepts fondamentaux qui composent ce concept : Microservices, API First, Cloud First, Headless, afin d’adresser l’objectif de chacun.
Tout d’abord un avis personnel, le fait de mettre ces concepts ensemble découle du bon sens : ce type d’architecture est considéré comme simple, efficace, intuitive, bien structurée, modularisée, bref… un travail que les vrais architectes doivent forcément apprécier !
Quid d’Amazon annonçant faire marche arrière pour Prime Video car la mise en application des micro-services implique un nombre d’orchestrations élevées ?
Les Micro-services, tels qu’expliqués dans d’autres articles (voir article micro-services), sont dans notre vision très fortement liés à un découpage DDD (Domain Driven Design).
Dans notre conception un micro-service définit un composant, dérivé d’un découpage métier et fonctionnel, agissant sur une donnée définie.
Le micro-service ne se limite pas uniquement à la partie back-end. Dans un contexte d’architecture web, il peut s’appliquer également au front-end.
Le Micro front-end et le Micro back-end se retrouvent intimement liés par une logique “composant d’affichage” et “composant qui traite applicativement la donnée affichée”.
Une architecture micro-services implique donc une certaine verticalité affichage, traitement et data.
API-First
C’est presque logique, on fait communiquer les différents composants par APIs.
Être API-first signifie d’intégrer la conception des APIs au cœur du processus de conception globale de l’application. Un peu comme si les APIs étaient le produit final.
Attention par contre, autant nous allons retenir l’API entre micro front end et micro back end, autant ce principe n’est pas partagé avec la communication entre le micro-service et d’autres composants du SI.
Une étude des différents patterns d’échange et un choix judicieux entre des méthodes synchrones et asynchrones est très importante pour éviter de mettre des contraintes fortes là où nous n’en avons pas besoin : pour partager une donnée avec les applications back office, tels qu’une confirmation de prise de commande avec un SAP, nous n’avons pas toujours besoin de désigner des flux synchrones ou API, nous pouvons par exemple découpler avec une logique de messaging, le cas d’usage nous le dira !
Cloud-First
Une vraie prédilection pour le Cloud, que du buzzword ?
En réalité, le fait de mettre en avant du Cloud dans cette démarche n’est que du bon sens.
Nous pouvons mettre en place une architecture on premise, pourquoi pas, mais dans certains cas il s’agit d’un vrai challenge : mise en place des serveurs, déploiement de la couche OS, des services, de la partie VM ou Container, etc.
Le Cloud First des architecture MACH vise la puissance des services managés, rapides de déploiement, scalables et élastiques, sur lesquels le déploiement en serverless ou en conteneur et la mise en place des chaînes CI/CD sont en pratique les seules choses à maîtriser, le reste étant fourni dans le package des fournisseurs de services cloud !
HEADLESS
Le Headless représente une tendance croissante dans le développement web et mobile. Cette approche met l’accent sur la séparation entre la couche de présentation, ou « front-end », et la logique métier, ou « back-end ». Cette séparation permet une plus grande flexibilité dans la manière dont le contenu est présenté et consommé. Elle offre ainsi une liberté de création sans précédent aux concepteurs d’expérience utilisateur et aux développeurs front-end.
Dans un contexte Headless, les front-ends peuvent être développés de manière indépendante. Les développeurs peuvent utiliser les meilleures technologies adaptées à chaque plateforme. Cela s’applique au web, aux applications mobiles, aux assistants vocaux, et à tout autre dispositif connecté. Cette approche favorise une innovation rapide. Cela permet aux entreprises de déployer ou de mettre à jour leurs interfaces utilisateur sans avoir à toucher à la logique métier sous-jacente.
La question qui nous vient à l’esprit maintenant est :
Ce type d’architecture s’applique à tout cas d’usage ? Certains sont plus réceptifs que d’autres de par leur configuration, gestion du parcours utilisateur ?
A notre niveau de cabinet de conseil et d’architecture des SI, il nous paraît indispensable d’ajouter notre pierre à cet édifice. D’autant que les précités n’ont pas tout dit…
Le Numérique Durable: pourquoi faire ?
On le dit et le redit et c’est bien le sous titre de notre travail : L’architecture est “Green by design”. En effet, depuis longtemps les architectes construisent des SI solides, non redondants donc sobres en fait…
Sans compter le temps passé à challenger les métiers sur leurs besoins. Et à éviter les travaux inutiles… Faire et défaire c’est du travail inutile et si on peut éviter c’est toujours ça d’économisé…
4 grands thèmes qui ne sont pas propres à l’architecture
Nous avons voulu que notre travail puisse être adapté en tant que guide à beaucoup d’expertise en plus de l’architecture :
Gouverner et former : qu’est ce que votre expertise / discipline / domaine de compétences peut mettre en place dans sa gouvernance et dans la formation des personnes pour intégrer les dimensions de responsable et de durable ?
Mesurer et montrer : que va-t-on pouvoir mesurer dans votre discipline et quels résultats va-t-on pouvoir montrer ?
Challenger : quels sont les thèmes ou autres domaines sur lesquels vous allez pouvoir challenger pour aller vers la diffusion des bonnes pratiques ?
Concevoir : quelles sont les bonnes pratiques lors de vos travaux de conception qui peuvent permettre d’aller vers plus de durabilité ?
Les architectes au coeur du Système d’Information
Le travail des architectes est on le rappelle ci-dessous :
L’Architecture d’Entreprise organise le dialogue entre les différents corps de métier pour définir une vision commune de l’entreprise de demain et de son SI, ainsi que la trajectoire pour y parvenir. Elle met en œuvre les approches nécessaires pour assurer la connaissance, la gouvernance et le pilotage opérationnel du SI.
A ce titre, les architectes sont au coeur des SI et des transformations et doivent donc jouer un rôle d’influenceur dans la direction du Numérique Durable. Ce guide est là pour fournir des clés à cette population particulière.
Nous l’avons vu dans les deux premiers articles de cette trilogie: la question du libre accès à l’information date d’avant l’ère informatique. Cette question, qui s’est transformée en obligation pour les acteurs ayant trait au service public, doit bénéficier d’une réponse adaptée. En France, la plateforme “data.gouv.fr” joue un rôle central en permettant aux administrations de publier et de partager leurs données de manière transparente avec le public. Cependant, pour garantir une publication de qualité et exploitable, les contributeurs doivent entre autres suivre trois étapes importantes.
Midjourney, prompt : A technical drawing of a computers and databases network. A pole with a French flag is located in the middle.
Étape 1 : Mise en gouvernance des données et des produits
La première étape du processus consiste à identifier les ensembles de données à publier, ou plutôt, vu que la règle est la publication, et l’exception est la rétention, identifier quelles données ne pas publier.
Cela suggère un prérequis important : Connaitre son patrimoine des données. Dans ce cas de figure, être capable de déterminer exhaustivement et explicitement quelles données possèdent des caractéristiques empêchant leur publication en open data (telles que des données personnelles ou des atteintes à la sûreté de l’État).
Un autre sujet important est celui de la connaissance et de la maitrise du cycle de vie des données. Où la donnée est-elle créée dans le Système d’Informations ? Où la récupérer dans son état le plus consolidé et certifié en termes de qualité ? A quelle fréquence la donnée devient-elle obsolète ?
Enfin, et sujet tout aussi majeur : quelle est la notion « Métier » (Ou « Réelle ») portée par cette donnée ? Quelle information interprétable et exploitable dans différents cas d’usages recouvre-t-elle ? En somme, quelle est sa définition ?
Afin d’arriver à cette connaissance et cette gestion systématique et qualitative des données, c’est toute une organisation qui doit être transformée, dotée de rôles et de processus adéquats. Et si l’Open Data est une bonne raison de se lancer dans une telle démarche, de nombreuses externalités positives (Par exemple, fiabilisation d’indicateurs, réduction du temps de traitement/recherches de données) sont à anticiper pour l’ensemble de ses usages basés sur les données, donc pour l’activité de la structure.
Enfin, un angle pertinent pour amorcer une transformation peut être de considérer le jeu de données à publier comme un « Data Product ». Même s’il n’y a pas de finalité financière directe attendue de la publication en open data, il est bénéfique de penser au jeu de données comme un produit. Responsabiliser des collaborateurs, tels que des Data Product Managers, autour de leur conception ou de leur suivi, au-delà des données qui les composent, permet d’aller vers une véritable gestion d’un portefeuille open data. La structure peut alors traiter les données comme un actif, et les produits qui en résultent permettent d’activer leur valeur.
Midjourney, prompt : An orchestra conductor in front of a computer assembly
Étape 2 : Préparer son jeu de données
Nous identifions les données, assurons leur qualité et déterminons leur point d’accès. C’est un bon début, mais il reste encore quelques étapes techniques avant de procéder au chargement des données.
Une des obligations légales de l’Open Data est de proposer un format exploitable par machine.
Data.gouv.fr détaille la liste des formats de fichier adéquats :
Formatage des Données : Les données doivent être formatées de manière à être facilement accessibles et exploitables par le public. Il est recommandé d’utiliser des formats ouverts et standardisés tels que CSV, JSON ou XML. Les données doivent également être bien structurées, avec des en-têtes explicites pour chaque information.
Documentation des Métadonnées : Nous devons accompagner chaque ensemble de données de métadonnées détaillées. Les métadonnées fournissent des informations essentielles sur les données, telles que la description de l’ensemble de données, la source, la fréquence de mise à jour, les licences d’utilisation, et les balises (tags). Ces informations, qui décrivent les données que l’on veut publier, permettent d’en assurer le suivi, la traçabilité, et de faciliter leur recherche, consultation, et réutilisation.
Organisation et Schémas de données : En parallèle de ces aspects techniques, les notions d’organisation et de schéma sont importantes à prendre en compte pour assurer une publication de qualité. L’organisation va permettre d’identifier un acteur (Une personne morale, une entreprise, un service de l’état), et de publier des jeux de données depuis plusieurs comptes « en son nom ».
La proposition et l’adoption d’une nomenclature particulière pour un type de données qui sera fréquemment mis à jour ou régulièrement complété par d’autres acteurs constituent le schéma de données. Par exemple, si des communes commencent à publier des jeux de données sur l’installation de défibrillateurs dans les lieux public, il existe un grand intérêt à converger vers un schéma de données commun afin de valoriser l’information.
Étape 3 : Publication des Données sur Data.gouv.fr et suivi
En fonction du type de données, de leur taille, de la fréquence de mise à jour de l’informations, il existe plusieurs possibilités pour les publier.
Du dépôt manuel de données à la mise à disposition par API , ou à l’import automatique en moissonnage, ces différents itinéraires techniques sont à examiner pour chaque situation, avec possibilité de consulter les collaborateurs administrateurs de datagouv.fr
En première partie, nous avons vu que dès les premières réflexions et bien en amont de la première publication, il est essentiel de penser à l’aspect « pérenne » d’un jeu de données, en commençant par une démarche de gouvernance des données. Il existe cependant un suivi possible à postériori, sur l’utilisation et la réutilisation des jeux de données. Là encore la plateforme datagouv.fr permet aux organisations d’accéder à des statistiques sur l’exploitation des données qu’elles mettent en Open Data.
Midjourney, prompt : A golden and shiny computer
Encore récent, et pour l’instant souvent « contraint », le sujet de l’Open Data pourrait voir un basculement de paradigme dans les années à venir. L’ensemble des acteurs socio-économiques pourraient s’engager à partager des connaissances, ce qui pourrait être inscrit comme un objectif RSE. Et au-delà de penser l’open data comme un centre de coût du fait de l’activité nécessaire à la mise à disposition des jeux de données, les acteurs économiques légalement contraints à la publication pourraient également en faire un centre de profit en tant que ré-utilisateurs.
Mobile Money : Business Model, pourquoi & comment ?
Mobile Money : Business Models, pourquoi & comment ?
Les marchands (B2C ou B2B2C) non habitués aux systèmes de paiement pan-africains sont souvent perdus devant les offres Mobile Banking. Le premier challenge devient donc de savoir et de comprendre comment choisir la bonne offre et le bon prestataire. Mais aussi, de rapidement poser les bonnes questions.
Dans l’article relatif au choix du prestataire Mobile Money, nous explorions les contraintes entre opérateurs Mobile Money et utilisateurs de ces services. Il s’agissait là d’un parti pris car, comme rappelé plusieurs fois, le Mobile Banking est avant tout … un service financier orienté client. Mais, les problèmes des clients s’appliquent aussi aux marchands.
En effet, en Afrique Sub-saharienne, adopter un business model rentable devient rapidement clé de par la complexité de se faire payer la bonne somme en temps et en heure. A cela s’ajoutent la stratégie commerciale de l’entreprise et la tarification de l’offre de paiement pour le client final. En ce qui concerne ce dernier, un autre élément peut semer le trouble pour certains marchands : la bonne identification du payeur.
Ces différents éléments rappellent une notion connue de tous les comptables : la réconciliation. Qu’elle soit quotidienne, hebdomadaire ou mensuelle, c’est cette opération de rapprochement entre les ventes supposées et les ventes remises en banque qui aide une entreprise à vérifier que sa santé financière est sur le bon chemin (ou pas…).
Après les précédents articles – davantage orientés « théories » – je vous propose d’appuyer cet article d’exemples concrets. Ce, en espérant arriver à vous les présenter le mieux possible.
Mobile Money pour Marchand : Conditions d’accès, Utilisation et Spécificités
Nous avons abordé la création et l’utilisation d’un compte Mobile Money sous le prisme du client. Mais qu’en est il des entreprises ?
La taille de votre business n’influe pas sur le processus de création d’un compte Marchand B2B Mobile Money. En effet, en fonction de la géographie, un processus de Know Your Agent (KYA) ou de Know Your Business (KYB) vous sera demandé. Le bon accomplissement de cette procédure est crucial et critique avant de pouvoir commencer à encaisser quoique ce soit, de qui que ce soit.
Sous couvert de la régulation en vigueur (Banque centrale), l’opérateur Mobile Banking doit être capable de justifier pour le compte de qui il s’apprête à enregistrer des opérations de paiements électroniques. Qu’il s’agisse d’encaissements (Cash-in, Paiement marchand) ou de décaissements (Cash-out, Bulk Disbursment…).
Ainsi, pourront vous être demandés plusieurs documents administratifs tels que :
Pièce d’identité des investisseurs (Ultimate Beneficial Owner ou #UBO) et/ou du dirigeant de l’entreprise (obligatoire)
Certificat et numéro d’enregistrement de l’entreprise au registre du commerce et de l’industrie national (ou local) (obligatoire)
Descriptif de l’actionnariat (obligatoire)
Numéro de taxe et/ou d’imposition
Descriptif de votre business et de votre business model
Relevé d’Identité Bancaire (RIB – obligatoire)
…
Ces documents seront étudiés, validés et stockés par les équipes compliances de votre (ou de vos) opérateur Mobile Money. Les procédures peuvent varier d’un opérateur à l’autre au sein d’un même pays mais, restent généralement plutôt uniformes.
Une fois cette procédure validée, un numéro ou un code marchand vous sera attribué. A partir de là, vos opérations en monnaie électronique sont sur le point de débuter!
Note : il est ici question de « Marchand » mais il s’agit en vérité d’un terme générique utilisé par les opérateurs Mobile Money pour une activité d’entreprise. Ainsi, la même logique s’appliquera que vous soyez une ONG, une Association, un entrepreneur, une multi-nationale… Si vous exercez une activité dite professionnelle, ce statut est fait pour vous ! La réflexion autour de la structure de compte reste à décider.
Au cours de mes précédentes expériences, j’ai eu l’occasion de rencontrer des marchands qui recevaient des paiements Mobile Money sous le couvercle de « transfert d’argent de personne à personne » (#P2P). Cela est en effet une possibilité pour éviter d’avoir à passer une procédure KYA/KYB. Cependant, plusieurs limites et risques sont à prévoir :
KYC vs. KYA/KYB : l’utilisation d’un compte client Mobile Money classique est à restreindre voire exclure car le détenteur d’un compte Mobile Money est alors une personne physique et non plus une personne morale. Les mêmes garanties et protections ne s’appliquent donc pas ;
Limité vs. illimité : un compte Mobile Money « Marchand » n’a en général aucune limite en termes de solde. Si vous vous souvenez de mes précédents articles, vous savez qu’à l’inverse un compte client normal a une limite (définie par l’autorité de régulation en vigueur – Banque centrale etc.) ;
Téléphone vs. plateforme : avec un compte marchand, l’opérateur vous donnera accès (un ou plusieurs) à une plateforme de monitoring en ligne de vos opérations. #Cashin / #Cashout, tout est tracé instantanément. A l’inverse, avec un compte Mobile Money classique, votre seul outil de suivi sera votre téléphone mobile (peu pratique…) ;
Service P2P vs. Paiement Marchand : les deux services ne sont pas identiques. Outre la technicité de leur réalisation, ces opérations risquent de vous coûter cher à vous et surtout à vos clients ;
Un par Un vs. Bulk : un compte Mobile Money « professionnel » vous permettra d’envoyer de l’argent à plusieurs personnes à un prix contractuel fixé avec votre opérateur Mobile Money (ex: dons, remboursement par vague, paiement de salaires…). En revanche, un compte client classique ne vous permettra d’effectuer que des transferts unitaires à prix variables.
D’autres différences existent mais celles susmentionnées sont selon moi les principales à retenir. En gardant en tête l’expérience du client final, permettez moi également de vous inviter à bien challenger un prestataire (autre qu’un Opérateur) vous proposant des services Mobile Money. Certains vous proposeront des cinématiques clients B2C et non pas B2B. Résultat ? vous en paierez les frais
Mauvaise expérience client
Mauvaise tarification
…
Cas d’usage du Mobile Money, GSMA, SOTIR 2022
Votre business model, quelle importance ?
Comme évoqué précédemment, il est possible de distinguer deux grandes typologies de paiement client : l’achat ponctuel et la souscription. La toute première différence entre ces deux modèles réside, selon moi, dans la temporalité des encaissements pour un compte marchand.
Dans le cadre d’un business organisé autour de paiements ponctuels, les paiements sont ponctuels et plus ou moins réguliers (ex: supermarché). La collecte des paiements sera fonction du taux de fréquentation de l’établissement ;
A l’inverse, dans le cadre d’un business organisé autour de l’abonnement / de la souscription, la réception de paiement est attendue sur une période connue à l’avance (ex: Paiement de facture).
Cependant, là aussi, des différences sont notables entre modèle occidental et modèle continental.
Note: les opérateurs de MobileMoney et MobileBanking africains étant bien au fait des besoins marchands/professionnels autour de l’abonnement, des services de « Virement automatique » (à la main du client) ou de « débit automatique » (mandat) voient le jour. Ces innovations vont aider l’ensemble de l’écosystème à continuer d’avancer dans le sens qui est le sien.
Outre le QUAND de l’encaissement de paiements, les marchands sont aussi sujets à des frais contractuels avec leurs prestataires. Ces frais sont généralement négociés et définis lors de la signature du contrat. Ils ont bien évidemment un impact direct sur la structure de coûts et combien le paiement Mobile Money coûtera aux clients.
Ces propositions tarifaires dépendent de plusieurs facteurs qui dépassent parfois les objectifs commerciaux des opérateurs. En effet, en fonction de la stratégie numérique et économique du gouvernement en place, de la pertinence et de la puissance du partenaire, le Mobile Money peut voir sa mission devenir sociétale.
Quelques bons exemples seraient :
L’assainissement des finances publiques et le gain de points de PIB grâce à la digitalisation des paiements de vignettes automobiles – service souvent régalien ;
La digitalisation et la simplification du paiement de facture d’eau et d’électricité ;
Aide à la digitalisation de la chaîne de valeur des offres de panneaux solaire (paiement des installateurs, schéma économique de paiement à la demande ou de souscription)
…
En fonction du côté de la barrière où l’on se situe, les stratégies en matière de grille tarifaire ne sont pas les mêmes.
Côté client : On distingue principalement 4 grands types de modèle tarifaire proposés aux utilisateurs par les opérateurs Mobile Money et leurs partenaires. Comme présenté ci-dessous, l’aspect marketing n’est pas à négliger pour amener vos clients à digitaliser leurs paiements.
Pour rappel, l’enjeu autour du cash est important dans les pays en voie de développement. Selon la Banque Mondiale plus de 60% à 70% des emplois relèvent de l’économie informelle. L’adage anglais prend donc tout son sens : « Cash Is King! ». Sans la compréhension du contexte client et l’adaptation aux principales sensibilités marketing, un marchand ne saurait exploiter les bienfaits du Mobile Money.
Conditions tarifaires – Tarification Client – Mobile Money
Côté Marchand : Il existe principalement deux (2) modèles tarifaires Marchand en Mobile Money, tous deux très fiables !
Comme vu, le choix d’une politique tarifaire peut davantage impacter l’expérience client. Bien la penser s’inscrit dans une logique gagnant-gagnant pour l’opérateur Mobile Money et le Marchand.
Peu importe que l’opérateur soit le premier sur le marché ou non, l’important est de choisir le prestataire qui saura cerner au mieux ce qui amènera les clients à changer leurs habitudes de paiement.
De plus, le cash-flow est un élément critique pour la survie d’un marchand. Si les achats ponctuels permettent d’assurer un fond de roulement, il n’en résulte pas moins que la fréquence de ces paiements définit la profondeur de ce fond.
Par exemple, un supermarché encaisse de manière quotidienne des paiements clients. En revanche, un service d’Eau et d’Électricité en Afrique Sub-saharienne verra une vague de fonds arriver plutôt en début de mois.
La profondeur, ou la volumétrie du cash-flow peut aussi impacter les délais de reversement par l’opérateur Mobile Money. Ces reversements sont principalement faits par virement bancaire et leurs coûts peuvent rapidement être importants (si trop fréquents, si montants élevés, etc.).
Conditions tarifaires – Contrat Marchand – Mobile Money
Le Mobile Money, un cercle vertueux ?
Oui, c’est un cercle vertueux tant sur le fond que sur la forme:
Si réaliser une opération/action financière est dangereux ou coûteux en temps et en énergie, le Mobile Money viendra s’inscrire comme une solution pragmatique et intéressante ;
Mais, si son coût financier est trop compliqué – aussi bien pour le client que pour le Marchand – alors la digitalisation de l’opération ne prendra pas ;
Un pan de l’économie qui peine à se digitaliser est potentiellement un pan qui restera aux mains de l’économie informelle et ainsi … une économie qui aura du mal à s’assainir dans le temps.
La politique tarifaire EST une composante essentielle de l’expérience client. Plus que ce que l’utilisateur voit comme écrans USSD sur son téléphone, si cela lui revient trop cher (à lui ou au bénéficiaire de l’opération) alors cela aura du mal à marcher.
Plus de 60 initiatives dans un environnement stimulant
Dans un monde où la tokenisation des actifs financiers et le développement des infrastructures de type blockchain révolutionnent les échanges, les monnaies numériques de Banques Centrales (MNBC) se positionnent en acteurs clés. Nées dans les turbulences de la fin des années 2010, elles symbolisent la réponse des banques centrales à la menace sur leur souveraineté monétaire posée par l’émergence des crypto-monnaies privées.
Les big techs, avec des projets tels que Diem (ex-Libra) de Meta (anciennement Facebook) annoncé en 2019, ont bousculé le paysage financier. Ce projet ambitieux, prévoyant l’émission de stablecoins basés sur plusieurs devises, promettait des solutions de paiement à faible coût et une inclusion financière étendue. Cependant, il a été stoppé net par des risques de stabilité financière et des obstacles réglementaires. Parallèlement, la diminution des paiements en espèces s’est accentuée, favorisée par une généralisation des paiements par carte bancaire, représentant 28 % des transactions en point de vente selon la Banque de France.
La technologie Blockchain ou DLT (Distributed Ledger Technologies) a prouvé sa solidité et sa résilience en tant qu’infrastructure de transactions depuis plus d’une décennie. Cette robustesse remet en question le monopole des banques centrales et des institutions sur le contrôle des transactions, ouvrant la voie à l’exploration de technologies innovantes. C’est dans ce contexte qu’en 2020, un programme d’expérimentation ambitieux sur les MNBC a été lancé. La Banque de France a pris les devants, collaborant avec divers acteurs du marché, publics et privés, dans une démarche d’apprentissage par la pratique.
Une étude de la Banque des Règlements Internationaux (BRI) en 2021 a mis en lumière l’engagement de plus de 60 banques centrales dans des programmes de MNBC, voyant dans ces dernières une opportunité d’améliorer les paiements transfrontaliers. Hervé Sitruk, président du France Payment Forum et expert des initiatives interbancaires, a brillamment résumé ce changement de paradigme : » Avec cette nouvelle monnaie numérique, les banques centrales européennes dament le pion aux banques, en réalisant un ‘full’ : un espace unique de paiement avec une monnaie physique et une monnaie numérique uniques ayant cours légal, acceptée partout et sur tous les canaux, et couvrant toute l’Europe. » Il y entrevoit l’avènement du “SCEPA (Single Central Euro Payments Area)”, où les banques seraient réduites à des rôles de distributeurs, la production et la gestion des flux de paiement étant centralisées à la Banque centrale.
Un écosystème diversifié que SWIFT se charge de rendre interopérable
Les MNBC ne se cantonnent pas à un modèle unique : elles s’adaptent aux besoins spécifiques de chaque pays. Dans les économies développées, elles offrent une alternative au cash, tandis que dans les régions moins bancarisées, elles promettent une inclusion financière accrue, notamment via les smartphones. Les MNBC pourraient ainsi répondre à des enjeux divers : protection des données, développement du commerce transfrontalier, traçabilité accrue des échanges domestiques, accélération des paiements et transparence renforcée.
Fabio Panetta, membre du directoire de la BCE et président du groupe de travail de haut niveau sur un euro numérique a souligné : « Nous sommes de plus en plus nombreux à nous tourner vers les paiements numériques, et nous devrions donc nous préparer à émettre un euro numérique parallèlement aux espèces. Un euro numérique renforcerait l’efficacité des paiements européens et contribuerait à l’autonomie stratégique de l’Europe. »
Au-delà des frontières de l’Euro numérique, Swift se positionne comme un hub central de l’écosystème mondial des MNBC. Tom Zschach, directeur de l’innovation chez Swift, insiste sur l’importance de l’interopérabilité : «Nous nous concentrons sur l’interopérabilité en veillant à ce que les nouvelles monnaies numériques puissent coexister de manière transparente entre elles mais aussi avec les monnaies fiduciaires et les systèmes de paiement actuels. La communauté financière a déjà reconnu le fort potentiel de nos innovations MNBC pour prévenir les îlots numériques tout en reliant en toute sécurité les systèmes de paiement d’aujourd’hui et de demain. Cette prochaine phase de tests et d’exploration nous aidera à affiner davantage la solution pour garantir qu’elle est aussi efficace que possible et à grande échelle.»
En 2022, SWIFT a démontré sa capacité à interconnecter techniquement les écosystèmes MNBC entre eux comme le définit la BRI dans son modèle 2 (Interlinked CBDC systems). SWIFT a mis en place un “bac à sable” pour permettre aux 18 banques centrales et commerciales d’effectuer des tests. Parmi elles : la Banque de France, la Deutsche Bank et BNP Paribas. La solution s’appuie sur les blockchain Quorum et Corda et sur un simulateur des systèmes de paiements traditionnels. Cette configuration a été capable de simuler des cas d’usage liés à des MNBC aussi bien interbancaires que commerciales.
De nombreux défis encore à surmonter
Cependant, les MNBC ne sont pas sans défis. En Europe, leur attractivité pourrait être limitée par des enjeux de sécurité, de confidentialité, d’hyper-fragmentation du marché, de complexité technologique et de coûts. La transition vers les MNBC pourrait également se heurter à des résistances culturelles, nécessitant des efforts de communication de la part des banques centrales.
Dans l’éventualité d’une adoption massive des MNBC, les Prestataires de Services de Paiement (PSP) pourraient subir une concurrence accrue des banques centrales. Des exemples concrets d’adoption des MNBC se trouvent en Chine avec le e-Yuan, en Uruguay avec le e-Pesos, aux Bahamas avec le Sand Dollar, et au Nigeria avec le eNaira, montrant que ces monnaies visent à faciliter les échanges quotidiens tout en offrant un contrôle accru sur les transactions aux autorités.
Au-delà de ces enjeux et défis, la MNBC offre également une opportunité unique pour les États de repenser leurs stratégies monétaires à l’ère du numérique, en tirant parti des avantages de la technologie blockchain et en présentant de nouvelles alternatives à leurs citoyens. Dans ce contexte, la MNBC pourrait potentiellement incarner le futur de la monnaie, permettant aux États d’harmoniser souveraineté monétaire et innovation financière à l’échelle mondiale. L’impact d’un euro numérique dépendra de nombreux facteurs, dont un ajustement étayé contribuera à garantir la stabilité financière européenne et la pérennité des banques commerciales.
Swift a fait le pari d’être la plateforme de l’interopérabilité, Il existe aussi d’autres projets à l’initiative des acteurs de la crypto-économie comme stellar.org.
Annexe
Qu’est ce qu’une MNBC ou une CBDC?
Une Monnaie Numérique de Banque Centrale est une forme de monnaie numérique émise et garantie par une banque centrale nationale. Contrairement aux crypto-monnaies comme le Bitcoin, qui sont des monnaies privées dont la valeur n’est pas assurée par un Etat, les MNBC sont une forme de monnaie fiat.
Avec cette nouvelle monnaie numérique, il existerait un espace unique de paiement où existerait une monnaie physique et une monnaie numérique uniques, acceptée partout à travers de multiples canaux, et couvrant toute l’Europe. Avec un instrument numérique unique, et un scheme unique pour toute l’Europe et toutes les transactions à distance, en plus de l’acceptation renforcée par une unification du « cours légal » de l’euro.
les MNBC de gros ou interbancaire (Wholesale CBDC): elles sont destinées aux transactions interbancaires et aux marchés financiers. Elles sont conçues pour faciliter les opérations de paiement et de règlement. Leur objectif est de faciliter un transfert entre un expéditeur et un destinataire sans avoir recours à des intermédiaires.
les MNBC de détail (Retail CBDC): elles visent à faciliter les transactions courantes pour le grand public.
Les MNBC comme pour les crypto-actifs s’appuient sur la DLT pour pouvoir véhiculer.
Qu’est ce que la Blockchain ou DLT (Distributed Ledger Technologies)?
La mission d’information commune de l’Assemblée Nationale sur les usages des chaînes de blocs et autres technologies de certification de registre donne la définition suivante de la technologie Blockchain :
“Une blockchain est un registre, une grande base de données qui a la particularité d’être partagée simultanément avec tous ses utilisateurs, tous également détenteurs de ce registre, et qui ont également tous la capacité d’y inscrire des données, selon des règles spécifiques fixées par un protocole informatique très bien sécurisé grâce à la cryptographie”.
Cette technologie apporte plusieurs avantages pour les développements d’une Monnaie Numérique de Banque Centrale. Elle permet de garder la trace d’un ensemble de transactions de manière décentralisée car l’autorité centrale ne contrôle pas le réseau, éliminant le risque de manipulation; les données sont cryptées et sécurisées à l’aide de mécanismes de consensus, ce qui les rend extrêmement difficiles à altérer et transparentes car toutes les transactions sont enregistrées dans un livre public et partagé visible par tous les participants.. Une fois enregistrées, les transactions ne peuvent pas être modifiées, renforçant la confiance dans l’intégrité des données.
