On profite du nouveau plan d’intéressement de RC et des choix de supports financiers dans lesquels vous allez pouvoir investir votre épargne salariale, pour vous parler de l’épargne responsable.
Le saviez-vous ?
La première empreinte carbone individuelle, sans qu’on le sache, c’est notre compte en banque. Notre argent n’est pas du tout neutre vis-à-vis du climat.
Quand l’empreinte carbone annuelle moyenne d’un Français en 2020 est de 11,2 tonnes équivalent CO2 (eqCO2) par an, celle de son épargne grimperait à 16 tonnes eqCO2 par an pour 25.000 euros placés à la Société Générale,15 tonnes eqCO2 chez BNP Paribas, 11 tonnes au Crédit Agricole… contre 8,8 tonnes à La Banque Postale, calcule Oxfam.
Choisir une banque plus responsable peut donc être une action, placer son épargne salariale de façon plus responsable en constitue une autre.
Alors c’est quoi l’épargne responsable et pourquoi ?
L’épargne responsable a pour objectif d’allier à la fois le rendement financier et l’impact positif sur la société et/ou l’environnement, en prenant en compte des critères « extra-financiers » pour sélectionner les entreprises dans lesquelles investir. On les appelle « critères ESG ».
Cette approche permet de mieux comprendre les stratégies des entreprises sur le long terme et de mesurer leur capacité à faire face aux grands enjeux de société présents et à venir. Autrement dit, les risques et opportunités sont identifiés de façon plus exhaustive. Cette même approche est appliquée aux obligations des États et des collectivités publiques.
La recherche de performance et l’épargne responsable sont parfaitement compatibles : les études académiques montrent que statistiquement l’épargne responsable est, au moins, aussi performante que celle sans critères ESG.
Concrètement comment faire ?
Vous entendez parler d’ISR, d’ESG, d’éthique, de bas carbone, de supports verts… Comment s’y retrouver ?
Investir dans des fonds responsables
Il existe un certain nombre de pratiques et de labels qui vous permettent de savoir si le produit d’épargne ou les supports que vous choisissez ont un objectif responsable ou intégrent des critères ESG :
En examinant la documentation pré-contractuelle (DIC document d’informations clés) fournie par votre conseiller, vous pouvez :
– Consulter la liste des supports disponibles qui soutiennent des causes environnementales et sociales, ou qui ont pour objectif l’investissement durable.
– Vérifier les stratégies d’investissement décrites dans ce document :
Bien qu’il existe plusieurs stratégies, 3 stratégies se distinguent des autres.
Les stratégies dites « Best » consistent à sélectionner les entreprises les mieux notées selon les critères ESG. On en trouve 3 variantes en fonction des secteurs d’activité concernés et de l’évolution de la prise en compte des critères ESG par les entreprises qui composent le fonds
Les stratégies d’exclusion désignentle fait d’exclure par principe certaines sociétés parce que leur chiffre d’affaires provient d’activités considérées comme néfastes pour la société ou contraire à l’éthique (par exemple le tabac, les jeux d’argent), ou parce qu’elles ne respectent pas certaines normes internationales (par exemple la Déclaration universelle des droits de l’homme)
Les approches thématiques consistent, elles, à identifier les entreprises de secteurs d’activité précis liés au développement durable ou à la transition énergétique. Par exemple la gestion de l’eau, l’alimentation durable, etc.
– Vous aider des informations réglementaires :
Règlement SFDR : Depuis 2021, la réglementation européenne permet d’identifier les fonds qui ont des critères ESG.
Les institutions financières (banques, assurances, sociétés de gestion) doivent désormais classer leurs fonds en fonction de différents critères. L’objectif est de fournir des informations claires et comparables sur la durabilité de leurs fonds, selon la classification suivante :
Règlement Taxonomie Verte Européenne : Cette réglementation classe les activités économiques considérées durables selon 6 grands objectifs et des principes. Un % d’alignement à la taxonomie verte indique à quel point le placement peut être considéré comme durable.
En consultant les labels accordés par des organismes indépendants, vous pouvez vérifier que le support répond à certains critères de financement d’activités responsables :
Les différents labels français
– Le label ISR : Créé par l’État français, le label Investissement Socialement Responsable identifie les fonds intégrant une dimension responsable dans la gestion de leurs investissements. Cette dimension responsable englobe la prise en compte de critères ESG dans le processus d’investissement.
– Le label Relance : Mis en place par l’État français suite à la crise liée à la pandémie de Covid-19, le label Relance répond aux besoins de financement des entreprises françaises en mobilisant l’épargne pour relancer l’économie, tout en respectant des critères ESG.
– Finansol : Attribué par l’association FAIR, le label Finansol vise à promouvoir les fonds adoptant une démarche solidaire et inclusive, notamment en soutenant l’insertion, le logement social et le commerce équitable.
– Greenfin : Créé par l’État français en faveur de la transition énergétique et écologique, le label Greenfin assure la qualité écologique des fonds d’investissement.
Investir directement dans des entreprises ou des projets
Si vous souhaitez épargner de façon responsable, vous n’êtes pas obligés d’investir au travers d’un fonds. Vous pouvez aussi sélectionner vous-même des actions d’entreprises en fonction des informations extra-financières disponibles. Certaines sociétés ont même l’obligation de publier ce type d’informations au travers de la déclaration de performance extra-financière (DPEF)
Quels sont les bons réflexes pour investir de façon responsable ?
Avant de se lancer dans l’investissement responsable, il est important de s’interroger de la même manière que pour un investissement classique (objectif, durée de placement, épargne de précaution, frais, etc.).
Et n’hésitez pas à questionner votre conseiller bancaire ou d’épargne pour en savoir plus sur l’épargne responsable.
Afin de vous aider votre dans votre prise de décision, vous pouvez consulter ces ressources complémentaires :
– Connaître l’empreinte écologique de votre épargne https://agirpourlatransition.ademe.fr/particuliers/finances/finance-durable/rift-outil-pour-connaitre-impact-ecologique-epargne
#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.
Articles qui pourraient vous intéresser
#1 DÉFINIR RAPIDEMENT L’ARCHITECTURE MACH ET POURQUOI ON EN PARLE
#1 DÉFINIR RAPIDEMENT L’ARCHITECTURE MACH ET POURQUOI ON EN PARLE
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 ?
Un exemple dans le prochain épisode !
Articles qui pourraient vous intéresser
Mettre ses données en Open Data : Prérequis et Perspectives – PARTIE 3
Mettre ses données en Open Data : Prérequis et Perspectives - PARTIE 3
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.
Impulsées par l’avènement du Cloud et du DevOps, les mouvances “as Code” et “Software Defined X” ont grandement amélioré la gestion du cycle de vie des assets informatiques (infrastructure, middleware, serveur d’application, …) avec principalement :
L’Infrastructure as Code (IaC),
La Configuration as Code,
Nous détaillerons dans un futur article le positionnement de chacun et les grands paradigmes en présence (procédurale vs déclaratif), qui reposent sur une caractéristique commune: l’utilisation de template/playbook au format normalisé (HCL, YAML, …) décrivant l’état final à atteindre ou le moyen d’y aller.
Même si la syntaxe est Human Readable, il peut être fastidieux à l’échelle d’un SI enperpétuelle évolution d’écrire et de mettre à jour ces fichiers de description.
Bien qu’il existe de plus en plus de plateformes simplifiant la création de ceux-ci sur base de conception visuelle en LowCode/NoCode ou de schématisation…Que diriez-vous de troquer d’un point de vue utilisateur le ”as Code” par du ‘as Prompt” ?
#GenAI à la rescousse
Le terrain de jeux des Large Language Models (LLM) et de la GenAI ne cesse de croître, en n’oubliant pas au passage l’ingénierie logicielle.
Imaginez pouvoir simplement demander “Provisionne un cluster de VM EC2 avec NGINX en exposition publique ainsi qu’une base Elasticache” pour voir votre souhait exaucé instantanément.
D’ailleurs, n’imaginez plus, car l’Infrastructure as Prompt (IaP) est déjà proposée par Pulumi AI, et bien d’autres en cours (depX) ou à venir.
Ce positionnement et les avancées rapides et significatives dans ce domaine ne sont pas étonnantes car nous sommes en plein dans le domaine de prédilection des LLMs: les langages.
Qu’ils s’agissent de langages parlés (Français, Anglais, …), de langages de programmation (Python, JavaScript, Rust), de langage de description (HCL, YAML, …), ils ont tous deux concepts fondamentaux:
Un dictionnaire, un vocabulaire, une liste de mots avec une (plusieurs) signification(s) connue(s),
Une grammaire et des règles syntaxiques plus ou moins strictes donnant un sens particulier à la suite de mots d’une phrase ou d’une ligne de fichier de configuration.
Plus le dictionnaire et la grammaire d’un langage sont dépourvus d’ambiguïtés, plus le degré de maturité et la mise en application de la GenAI et des LLMs sur celui-ci peut-être rapide.
L’Infrastructure as Prompt n’est pas une rupture totale avec le “as Code”, simplement une modernisation de l’interface “Homme-Clavier”.
En effet, peu importe le moyen (création manuelle, auto-génération via prompt) l’aboutissement de cette première étape est la disponibilité du fichier de description.
Le cœur du réacteur, à savoir la traduction du <fichier de conf> en actions pour <provisionner et configurer les ressources>, est toujours nécessaire.
A l’avenir elle pourra se révéler un parfait assistant pour faire des recommandations et propositions d’ajustement vis-a-vis de la demande initiale pour optimiser l’architecture à déployer:
Prioriser les services managés,
Prioriser le serverless,
Etre compliant avec les best practices des frameworks d’architecture des Clouders (AWS Well Architected Framework, …),
Security By Design,
RIght sizing de l’infrastructure,
Opter pour des ressources ayant une empreinte carbone et environnementale optimisées.
#La confiance n’exclut pas le contrôle
Bien que la baguette magique qu’apporte cette surcouche soit alléchante, nous ne pouvons qu’abonder les paroles de Benjamin Bayard dans son interview Thinkerview Intelligence artificielle, bullsh*t, pipotron ? (25min) : “tous les systèmes de production de contenus si ce n’est pas à destination d’un spécialiste du domaine qui va relire le truc, c’est dangereux.” Dans un avenir proche l’Infrastructure as Prompt // la Configuration as Prompt n’est pas à mettre dans les mains de Madame Michu (que nous respectons par ailleurs) qui ne saura pas vérifier et corriger le contenu de Provisioning, de Configuration ou de Change qui a été automatiquement généré. Nous vous laissons imaginer les effets de bords potentiels en cas de mauvaise configuration (impact production, impact financier, …) dont le responsable ne serait autre que la Personne ayant validé le déploiement. Impossible de se dédouaner avec un sinistre “c’est de la faute du as Prompt”.
Vous l’avez compris, la déferlante LLM et GenAI continue de gagner du terrain dans l’IT, le potentiel est énorme mais ne remplace en rien la nécessité d’avoir des experts du domaine. Le “as Prompt” se révèle être un énorme accélérateur pour l’apprentissage du sujet, ou dans le quotidien de l’expert .. qui devra avoir une recrudescence de prudence quant aux configurations qui ont été automatiquement générées.
Articles qui pourraient vous intéresser
Mobile Money : Business Model, pourquoi & comment ?
Mobile Money : Business Models, pourquoi & comment ?
Les marchands 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.
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.
