J’ai eu le plaisir d’introduire la table ronde « Le futur du paiement de proximité », organisée par le groupe de travail Perspectives & Innovations du France Payment Forum. J’ai présenté une synthèse des différents éléments qui pourraient favoriser la construction de nouveaux parcours utilisateurs en proximité, à commencer par l’émergence et le développement des schemes de Real Time Payment
En effet, depuis le Zengin japonais lancé en 1973, les schemes de paiement en temps réel n’ont cessé de se développer et se généraliser avec une certaine accélération sur les dernières années. Les derniers en date étant le SCT Inst en Europe en 2017, la Malaisie et la Roumanie en 2019 et le Vietnam en 2020.
Un environnement favorable
Parmi ces initiatives, les transferts de compte à compte en proximité constituent une partie significative des cas d’usage. Une analyse comparative fait apparaître des similitudes en termes d’écosystème. En effet, au-delà de l’existence d’un scheme de real time payment, nous remarquons la présence de catalyseurs tels que :
le Request to Pay sous toutes ses formes, du simple lien de paiement pré-renseigné au modèle 4 coins tel que celui développé par l’EPC
les alias afin de fluidifier la gestion des identités numériques ; pour simplifier l’expérience d’achat, les alias permettent de ne pas avoir à renseigner son IBAN ou bien celui du commerçant
les QR codes, qu’ils soient dynamiques ou non
Des API ouvertes qui favorisent les interactions entre les acteurs de l’écosystème et la construction d’expériences d’achat de plus en plus pertinentes pour des niches jusque-là non/mal servies
Les Soft POS qui démocratisent l’accès à l’expérience de paiement digital en proximité en permettant à de petits commerçants de transformer leurs smartphones ou tablettes en terminaux de paiement simplement en téléchargeant une application
Pour quels bénéfices ?
Toutefois, bien que ces catalyseurs favorisent indéniablement l’émergence de nouveaux usages, le véritable challenge reste celui de l’adhésion à la fois des consommateurs et des marchands. Pour cela, la nouvelle proposition de valeur devra résoudre un véritable pain point ou bien améliorer substantiellement un usage existant. Parmi les bénéfices attendus de la part des consommateurs, nous pouvons citer :
Régler de gros achats sans être limité par les plafonds de paiement de la carte
Améliorer la confidentialité et la sécurité des opérations en n’ayant plus à communiquer ni son PAN ni son IBAN
Disposer d’un mode de paiement alternatif pour répondre à des usages de niches
Bénéficier d’une expérience de paiement plus fluide…
Du côté des commerçants il sera important de :
Co-construire un modèle économique complémentaire qui prenne en compte les spécificités du nouveau cas d’usage et son panier moyen
Minimiser la fraude et les impayés liés aux autres moyens de paiement (chèques, carte…) et apporter une garantie d’irrévocabilité
Faciliter l’accès aux paiements digitaux à travers de nouveaux modèles d’acceptation qui minimisent les frais de mise en place
Faciliter l’automatisation de la réconciliation des paiements et le cas échéant fluidifier les opérations de remboursement…
Comment s’y prendre ?
Face à cet objectif de fluidification de l’expérience utilisateur, plusieurs approches sont envisageables. A titre d’exemple, le tableau récapitulatif présenté ci-dessous fait le parallèle entre le modèle du consortium Bizum, fruit de la coopération de 31 banques espagnoles, et celui de la FinTech (AISP/PISP) Vibe Pay.
Bien que sensiblement différents en termes de scheme sous-jacent, de stratégie de couverture et de moyen, il est à noter que les deux modèles adressent les mêmes cas d’usage, à savoir le P2P, l’e-commerce et le paiement en proximité. De ce fait, le dernier challenge à relever, et non des moindres, sera de construire une expérience d’achat unifiée sans coutures.
Pour atteindre cet objectif, il est essentiel d’intégrer le paiement bien en amont lors de la conception de l’expérience utilisateur afin qu’il se fonde dans le parcours d’achat et non pas être un nième moyen de paiement qui arriverait en bout de chaîne.
Outre l’offre bancaire classique, la France compte plus de 600 FinTechs, dont pas moins de 150 PayTechs. Bonne nouvelle au niveau de l’offre, mais comment s’y retrouver au moment du choix de solution de paiement, que l’on soit commerçant, marketplace, fournisseur de service en ligne, association…
Les critères à prendre en compte sont multiples dans le choix de son PSP. Concentrons-nous ici sur le critère économique, autour de 7 questions visant à :
Evaluer les coûts des solutions de paiement
Et s’assurer que la comparaison s’applique à des prestations comparables…
1. Quel est le positionnement du PSP ?
Derrière le check-out ou plus généralement l’ordre client, nombreux sont les intervenants dans la chaîne de paiement. Les stratégies fournisseurs varient largement :
De l’orientation one-stop-shop, intégrant des partenaires pour apporter une solution plus complète au client,
A un positionnement de spécialiste, sur un maillon de la chaîne…
Le couplage Acceptation / Acquisition illustre cette problématique de périmètre, avec ses conséquences directes sur l’analyse des coûts :
Acceptation ET Acquisition (one-stop-shop) Certains PSP proposent une prestation intégrant acceptation et acquisition. Ils s’appuient sur leurs partenaires pour l’acquisition, sélectionnés pour raisons d’appartenance au même groupe financier ou dans le cadre de négociations tarifaires massifiées.
Acceptation seule D’autres permettent au client de choisir son acquéreur. La solution de paiement intervient dans ce cas en tant que passerelle technique, routant les flux vers l’acquéreur retenu par le client. Cette configuration permet au client de conserver / renforcer sa relation avec son acquéreur, auquel il peut avoir confié d’autres prestations et négocié des conditions particulières, notamment sur les transactions On-Us…
2. Quelle est votre maîtrise de vos volumes d’opérations de paiement ?
« La prévision est difficile surtout lorsqu’elle concerne l’avenir… ». Au moment du choix d’une solution de paiement, il peut être difficile d’évaluer les volumes d’opérations, leur répartition par moyen de paiement…
S’ils sont bien maîtrisés, les propositions plus détaillées (jusqu’à 25 paramètres recensés dans notre grille d’analyse) pourront permettre d’optimiser les coûts, au prix d’un engagement dans la durée, de minima de volumes, de conditions de modification et de sortie….
Dans l’autre cas, les propositions plus flexibles et plus intégrées seront plus adaptées à un modèle économique à prouver.
3. Quelle palette de moyens de paiement ?
Les nouveaux PSP se sont d’abord développés sur le modèle de la carte, en tant que moyen de paiement privilégié des clients, en ligne et en magasin.
Les autres moyens de paiement (Virement, Prélèvement…) ont depuis commencé à percer, notamment pour des raisons de coût à la transaction.
Le Virement Instantané va contribuer à élargir cette palette, en concurrence directe avec la carte, à la fois au niveau des coûts, mais aussi pour des paiements supérieurs aux plafonds cartes.
Au niveau de la comparaison des coûts, les PSP proposant ces différents moyens de paiement bénéficieront de coûts moyens inférieurs aux pure-players de la carte.
4. Faut-il prévoir des coûts complémentaires pour les retries, rejets, chargebacks, reporting… ?
Au-delà du traitement nominal des opérations, il est important d’intégrer aussi les cas d’exception (trop nombreux d’ailleurs, pour être qualifiés d’exceptions…).
Là encore, les PSP se distinguent entre :
Ceux qui considèrent ces services comme indissociables du paiement ; dans une logique de cas d’usage (vision client) familière aux FinTechs, il est naturel d’intégrer ces services dans l’offre globale, sans surcoût / option spécifique ;
Ceux qui les considèrent comme des services supplémentaires, dans une vision orientée fournisseur, considérant la rentabilité de chaque service qu’il propose et les coûts externes (interbancaire, schemes…) générés par chacun.
5. Quel impact sur la fraude et les charges internes ?
La fraude intervient dans la comparaison économique des PSP à 2 niveaux :
D’abord dans l’efficacité de la gestion du risque que le PSP peut proposer, avec une performance à évaluer en matière de faux positifs / négatifs et dans la gestion de l’authentification forte (mode frictionless…). L’enjeu se mesure directement dans la perte de Chiffre d’Affaires et le montant des impayés.
Ensuite, dans les moyens mis en œuvre pour la gestion des litiges et la relance pour impayé. Le service peut être proposé par le PSP ou assuré en interne par le Client, à prendre en compte dans la comparaison des coûts.
Outre la fraude, d’autres postes de charge interne sont touchés par le choix du PSP :
Réconciliation & Reporting : les ressources dédiées au rapprochement des commandes et des règlements dépendent fortement de la qualité du reporting fourni par le PSP ;
Traçabilité : la capacité offerte par un PSP d’accéder directement au statut d’un paiement dans la chaîne de traitement permet d’éviter les multiples échanges téléphoniques… ;
Gestion des retries : la délégation au PSP de la représentation des paiements en échec peut libérer des ressources au sein de l’entreprise. Au-delà de l’existant, les opportunités d’optimisation ne manquent pas, dans la digitalisation des processus internes, comme la gestion des factures fournisseurs, la gestion des salaires… les fournisseurs spécialisés se développent en complément des éditeurs de solutions de comptabilité, paie… Le choix du PSP peut impacter ce potentiel d’optimisation, selon sa capacité à s’interfacer avec ces solutions, via ses API et les partenariats noués avec ces fournisseurs spécialisés.
6. Encaissement direct ou reversement ?
Au-delà des coûts de transaction, les offres des PSP peuvent aussi impacter la trésorerie. Deux modèles coexistent :
Encaissement direct : Le client reçoit directement les fonds sur son compte ;
Reversement : Les fonds sont collectés par le PSP, qui les reverse au Client selon des conditions de fréquence, montant minimum…, avec des délais jusqu’à 30 jours…
7. Quels coûts de mise en œuvre de la solution de paiement ?
Au-delà des coûts de fonctionnement traités plus haut, les coûts de mise en œuvre peuvent aussi varier :
Les principales solutions du marché (CMS e-commerce) proposent des extensions ou plug-ins, à télécharger par le client, avec un support léger pour le paramétrage. Les coûts de projet sont négligeables dans ce cas.
Dans d’autres cas, le déploiement donne lieu à un véritable projet, avec les ressources mobilisées côté client, auxquelles peuvent éventuellement s’ajouter des frais d’installation (set-up) facturés par le PSP.
En conclusion, la multiplication des PSP a apporté une plus grande richesse des services de paiement. Elle a aussi rendu plus complexe la comparaison des offres, au moment du choix du Prestataire de Services de Paiement.
Rien que sur le critère des coûts, la comparaison nécessite de prendre en compte le modèle économique du PSP, sa position dans la chaîne de bout en bout, la palette de moyens de paiement supportés, la fraude, les optimisations possibles sur les charges internes et les opportunités des solutions de digitalisation dans l’entreprise…
En rappelant toutefois que l’équation économique repose avant tout sur le taux de transformation client et que la fluidité du parcours de paiement proposé par le PSP précède la question du coût !
Alors, rendez-vous sur nos prochains articles sur le choix des solutions de paiement pour éclairer l’ensemble de ces critères.
Les données sont partout et nulle part et sont bien souvent intangibles. Notre quotidien devient petit à petit un flot permanent de données générées, collectées et traitées. Elles sont cependant un moyen pour atteindre des objectifs et non une finalité.
Les entreprises doivent donc avoir la capacité à naviguer vers leurs objectifs business, sur une rivière qui deviendra vite un océan de données. L’important maintenant est donc de savoir si elles ont les moyens de braver les éléments.
Les ‘éléments’ auxquels il faut faire face
1. L’obligation de la donnée
La donnée est omniprésente. Données personnelles, confidentielles, de navigation, de consentement, data science, data platform, data visualization, chief data officer font partie d’une longue liste de termes qui font le quotidien des experts mais aussi du client consommateur. Les données sont aujourd’hui un asset reconnu et à forte valeur ajoutée (1). Elles sont aussi un asset pérenne du fait des usages numériques et des opportunités business qui se réinventent tous les jours.
Premier constat donc, l’obligation de la donnée. Elle est un passage obligatoire pour mieux connaître les consommateurs, répondre à leurs nouveaux besoins et être innovant.
2. La surabondance
La digitalisation croissante dans tous les secteurs, les réseaux sociaux, l’IOT, la mobilité, l’utilisation croissante des smartphones sont des exemples qui provoquent une forte augmentation de la génération de données. Les sources se multiplient, les besoins en stockage également (2). Par conséquent, nous sommes vite confrontés à une problématique grandissante : comment maîtriser toutes ces données ? Comment faire face à ce flot surabondant ? Et comment en tirer des informations utiles sans être noyé ?
Les prévisions (3) tablent en effet sur une multiplication par trois ou quatre du volume annuel de données créées tous les cinq ans. Les chiffres sont implacables.
Le deuxième constat est donc la surabondance. Un océan numérique déferle et chaque entreprise, peu importe sa taille, devra y faire face.
3. L’éphémère
Le numérique génère de nouvelles habitudes chez le consommateur : l’instantanéité, le choix abondant et la rapidité de changement. (offre, prix, produit, etc.). Ces habitudes se traduisent par des besoins de plus en plus éphémères. Elles raccourcissent les durées de vie des produits et des services, ou imposent de continuellement se renouveler pour se différencier. Les opportunités marchés sont nombreuses et il faut aller vite pour les saisir le premier. Être le premier est ainsi souvent synonyme de leadership sur le marché. (exemple : Tesla, Airbnb, Uber) L’éphémérité des besoins impose donc d’accélérer en permanence tous les processus internes, métier et SI.
Le troisième constat est donc l’éphémère (besoin, produits, services) qui devient de plus en plus présent. Il est ainsi nécessaire d’être de plus en plus réactif pour s’adapter et évoluer rapidement face à ces changements permanents.
4. L’innovation permanente
Le numérique engendre aussi une accélération de l’innovation. Il rend accessible au plus grand nombre la possibilité de réinventer son quotidien. Cette accélération permanente rend plus rapidement obsolète l’invention d’hier.
Qui aurait en effet pensé que nous allions pouvoir partager nos appartements il y a 10 ans ? Qui aurait pensé que payer sa place de parking se ferait sur son téléphone ? Et surtout qui aurait pensé qu’un téléphone deviendrait l’accès privilégié à toutes nos innovations de demain ?
Le dernier constat est donc l’innovation permanente. Comme pour l’instantanéité, cela génère un besoin de flexibilité et de rapidité fort pour pouvoir suivre le rythme d’innovations imposé par le monde digital.
5. La capillarité de la donnée
Quel est le point commun aux constats précédents ? La donnée. La donnée est présente dans tous les processus et tous les usages en contact ou non avec le client. Ainsi la donnée, par nature, telle la propagation d’un liquide sur une surface, oblige à s’interroger sur les briques du SI qui l’utilisent pendant ces processus et ces usages : c’est la capillarité des données.
Ensuite avec de l’expertise et de la méthodologie, tout s’enchaîne! La définition des besoins et la conception fonctionnelle au travers du prisme “donnée” dans une vision d’ensemble, feront que naturellement par capillarité, vous adresserez le cycle de vie de la donnée, sa valeur et l’architecture de votre SI pour répondre à ces besoins.
Survivre grâce au SI Data Centric
Dans ce contexte de surabondance, d’éphémérité et d’innovation permanente, comment alors maîtriser son patrimoine de données ? Il s’agit de raisonner données et non plus SI. L’objectif devient la gestion de la donnée. Se poser la question de comment gérer des données permet en effet d’adresser ces changements détaillés précédemment et par capillarité, le SI. Un SI centré sur les données est donc le moyen d’adresser ces vagues de changements et de résister aux éléments. En effet, gérer les données impliquent des notions d’unicité, de qualité, de volumétrie, de performance, de confidentialité, d’échanges, de réglementations. L’amélioration de la conception du SI pour faire face à ce nouveau contexte est donc immédiate.
Les fonctions à adresser par le SI, qu’elles soient métiers ou techniques, et la gouvernance nécessaire à la gestion des données vont soulever des questions qui permettront d’adresser ce nouveau contexte d’éphémérité et de surabondance. L’innovation permanente oblige, elle, à industrialiser la livraison des nouvelles fonctionnalités de ce SI centré sur les données. Le SI se construit ainsi autour de la donnée : flexible, modulaire, et industrialisé. Par exemple des référentiels (produits, clients, fournisseurs, etc.) sont mis en place, garantissant la qualité et la mise à jour des données utilisées par toute l’entreprise. Un autre exemple est que les données collectées sont conservées à un seul endroit brutes puis standardisées pour identifier les relations entre elles. Ou encore des outils permettant d’avoir la définition, le cycle de vie et le propriétaire de chaque donnée sont déployés. Le SI devient ainsi un SI centré sur les données. (“Data Centric”).
Il s’adaptera donc naturellement aux futurs changements du marché grâce à tout ce qu’implique la donnée. Il devient un socle solide adressant différents usages sans forcément avoir besoin de transformation en profondeur, longue et coûteuse. Pourquoi ? Car encore une fois, gérer une donnée et faire en sorte qu’elle soit collectée, de qualité, sous contrôle, disponible partout en temps réel et en unitaire ou en masse, intégrées aux processus cœur de métier de l’entreprise, est universel et adaptable à tout usage.
Intrinsèquement la donnée est agnostique de l’usage qu’elle sert. C’est le SI Data Centric qui garantit cette fonction, et assure la survie de l’entreprise dans la jungle digitale.
Conclusion
S’impliquer fortement dans l’évolution du SI est donc nécessaire. L’objectif est de commencer petit mais de commencer Data Centric. Usage après usage, votre SI se construit toujours plus résilient aux différentes vagues de cet océan de données. Un autre bénéfice, et non des moindres : l’innovation des équipes n’étant plus ralentie par le SI, elle s’en trouve ainsi décuplée.
Construire un SI Data Centric, c’est la garantie d’avoir un SI modulaire et adaptable qui répond aux enjeux d’aujourd’hui et de demain. Il est ainsi une base solide sur laquelle construire la pérennité de l’entreprise dans ce nouveau contexte.
Nous aurions pu dresser ici un panorama des technologies, mais mis à part l’intérêt artistique de la présentation, même si l’analyse de notre exemple est très pertinente, sa plus-value en termes d’architecture s’en serait trouvée limitée (1).
Certains proposent une vision basée sur les prérogatives technologiques.
Cette approche (2) oublie la finalité du stockage de la donnée et ne propose qu’un nombre limité de solutions. Nous préférons donc proposer une approche axée sur l’usage de la donnée et sur le besoin utilisateur…
Faisons un rapide tour d’horizon des technologies
Aujourd’hui lorsque nous parlons de data stores, plusieurs familles sont représentées :
Les bases de données relationnelles : Oracle, SQLServeur, MySQL, PostgreSQL, …
D’autres technologies (de stockage ou autres) qui, même si elles permettent de répondre à certains besoins, ne sont pas réellement des bases de données : AWS S3, Azure Blobstorage, Stockage HDFS, Elastic Search, …
Bref, plus de 350 bases de données sont répertoriées à ce jour. Certaines sont uniquement disponibles en PaaS, d’autres sont hybrides et certaines plus traditionnelles ne sont pas éligibles au Cloud(3). Il est donc indispensable de construire une méthodologie qui permette de choisir la technologie qui réponde au besoin.
Pas facile de faire son choix !
Répondre à notre question initiale est bien plus complexe aujourd’hui qu’il y a quelques années, tant les usages ont évolués et les technologies se sont multipliées.
Toutefois pour ne pas se tromper, les bonnes questions à adresser en amont sont les suivantes :
De quelle manière l’application va-t-elle consommer les données : via des appels directs, une couche d’API, des requêtes GraphQL ?
Est-ce que les fonctionnalités attendues doivent être portées uniquement par la base de données ? Ou est-ce que des composants supplémentaires sont nécessaires ?
Est-ce que les transactions doivent être ACID (4) ?
A quelles contraintes du théorème CAP(Consistency, Availability, Partition tolerance) (5) la base de données doit-elle répondre en priorité ?
Quelles structures ou formats de données se prêtent le mieux à l’usage demandé : clé/valeur, colonne, document ou encore graph ?
Quelle va être la volumétrie de ces données ? Quels sont les besoins en termes de performances, de résilience ?
Pour quel type d’usage ? (Décisionnel ? Transactionnel ? Événementiel ?)
Pour quelle nature de données ? (IoT ? Géographiques ? Coordonnées GPS ? Données chronologiques ? Spatio-temporelles ?)
D’autres considérations doivent également être prisent en compte :
Quel sera l’écosystème dans lequel va être hébergée mon application (Cloud ou On Premise) ?
Y a t’il besoin d’accéder aux données lorsque l’application est déconnectée de la base de données ?
Est-ce que je souhaite m’inscrire dans un écosystème intégré (certains éditeurs fournissent des composants qui n’ont plus rien à voir avec le stockage de la données (6)) ?
Quel est le niveau de maturité des équipes de développement, des équipes chargées d’assurer le RUN et l’assistance technique ?
Quel est le niveau de sécurité à appliquer pour protéger les données ?
Au cas par cas, suivant l’usage qui sera fait des données, selon le type des données, selon le niveau de protection nécessaire, nous vous conseillons de construire un arbre de décision cohérent avec l’ensemble des contraintes à appliquer.
Dans certains cas, la solution pour simplifier la spécialisation du stockage sera complétée par une orientation microservice. Cette approche permettra d’exposer et de consommer les données de manière beaucoup plus souple qu’avec l’approche monolithique traditionnelle (un seul data store pour toutes vos données).
Pour en savoir plus sur ces sujets, nous vous invitons à consulter nos articles dédiés :
La solution, concentrez-vous sur le besoin initial
Que l’on se le dise, il n’y aura pas de solution permettant de répondre à l’ensemble des besoins. Les projets qui réussissent sont ceux qui se concentrent sur le besoin initial, prennent en compte le savoir-faire de l’équipe en charge du projet et qui, lorsque le besoin évolue, complètent leur architecture en restant concentrés sur le besoin métier.
En conclusion, la solution de stockage ne doit pas être choisie uniquement en fonction des contraintes technologiques, mais bien en fonction de l’usage qui sera fait de la donnée.
Nous le constatons encore aujourd’hui, certains projets n’aboutissent jamais, ou alors après des mois voire des années de mise en œuvre et sont boudés par les utilisateurs.
Malgré une gestion des changements, la plateforme n’est jamais utilisée et l’application meurt (on l’espère rapidement) sans jamais rencontrer ses utilisateurs.
Dans certains cas, le projet “stratégique” a été validé par la Direction, la technologie en haut à droite du cadran du Gartner a bien été déployée, mais au final les cas d’usage sont beaucoup trop compliqués à intégrer sur la plateforme. Ces projets finissent souvent en échec, les ressources ont été gaspillées et l’image de la DSI en pâtit.
Enfin, dans d’autres cas, l’étude s’éternise pour concevoir, et planifier l’architecture qui répondra à l’ensemble des cas d’usages et qui permettra de résorber la dette technologique. Ces cas de figure trop fréquents partent malheureusement de bonnes intentions. Il s’agissait de couvrir l’ensemble des besoins existants et d’absorber les besoins qui ne manqueront pas d’arriver à court et moyen terme.
Une approche frugale
La meilleure solution consiste à se concentrer sur quelques utilisateurs clés pour prendre en compte des fonctionnalités précises qui peuvent être implémentés sous forme de MVP en quelques sprints et le faire évoluer pour prendre en compte les nouveaux besoins.
L’architecture de la solution devra rester souple et prévoir “by design” de pouvoir intégrer de nouveaux composants et technologies qui répondront demain à des nouveaux besoins.
Pour réussir cette mise en œuvre, il faut donc réunir une équipe pluridisciplinaire qui sera en charge de :
Collecter et analyser les besoins des utilisateurs
Définir l’architecture fonctionnelle et de données
Définir l’architecture technique
Constituer et suivre la backlog
Concevoir et mettre en œuvre les développements
Déployer l’architecture technique
Au démarrage du projet il faudra donc :
un Product Owner
un architecte en charge des aspects fonctionnel, applicatifs et data
un architecte technique
un scrum master
un ou plusieurs développeurs spécialisés sur les stacks à mettre en oeuvre
un cloud-ops
Un Business Analyste
Une organisation efficiente
Cette organisation s’inspire des Pizza Teams (l’ensemble des membres d’une équipe doit pouvoir se nourrir sur une Pizza Américaine). Elle vise à simplifier la communication au sein d’une équipe. En effet, le nombre de liens entre les personnes d’une équipe peut être calculé avec la formule suivante (1) :
( N x (N -1 ) )/ 2
Où N est égale au nombre de personnes dans l’équipe.
Plus le nombre de personnes est important plus les échanges sont importants et les risques et le temps consacrés aux échanges sont importants.
La mobilisation de l’équipe permettra de produire au fil des sprints des versions de plus en plus abouties, revues régulièrement par les utilisateurs.
En quelques semaines, une première version pourra être déployée en production sur le périmètre jugé prioritaire par les utilisateurs.
L’adoption ne sera plus un problème, car les utilisateurs auront participé à la conception de leur outil et remonteront directement les fonctionnalités prioritaires.
Au fil des évolutions, l’équipe pourra être élargie pour prendre en compte des besoins impliquant des nouvelles briques d’architecture et de nouvelles technologies. Il faudra toutefois rester vigilant afin de ne pas dépasser le nombre critique de membres dans l’équipe.
Une dynamique dès le cadrage
Un cadrage initial est indispensable avant de lancer le projet. Certes l’organisation projet et le user-centrisme sont des facilitateurs, mais la clef dans le succès de la démarche se trouve en amont. Si au lieu de demander aux utilisateurs quels sont leurs besoins et de les hiérarchiser par priorités, nous leur demandions leurs envies ?
Les utilisateurs vont être concentrés sur ce qui est vraiment important dans leur travail et ce qui va leur simplifier la vie. Si l’application a de multiples utilisateurs, il faudra les amener à trouver un consensus et à présenter une liste commune. Cette liste sera la base de la backlog projet et devra être affinée afin de la rendre implémentable.
Faire adhérer les décideurs
Cette approche projet nécessite de rassurer les décideurs. En cela la méthode agile est insuffisante. Le burn out chart ou les autres indicateurs sont utiles au pilotage agile des projets, mais suffisent rarement à rassurer les décideurs sur les aspects coûts / délais / valeur ajoutée des projets.
Il faut donc trouver des indicateurs complémentaires, aptes à rendre compte de l’avancement des sprints, mais qui permettent aussi d’apporter de la visibilité aux décideurs qui n’ont que faire des points de complexités et autres idiomes agiles.
Revoir la méthode
La réussite des projets passe par une remise en question profonde de nos méthodes d’architecture. Le framework TOGAF nous donne de bonnes bases, mais elles sont loin d’être suffisantes pour aller vers de l’architecture SI agile.
Les évolutions de l’architecture découlant des besoins métiers et non plus d’une planification détaillée réalisée en début de projet et implémentée dans un cycle de plusieurs mois ou années, cela nous amène à adresser des problématiques qui remettent en cause nos méthodes de travail :
Les projets font de plus en plus souvent appel à de l’expérimentation. Les composants sont testés sur des calendriers resserrés et suivant l’adéquation par rapport au besoin, sont adoptés ou abandonnés.
Les schémas d’architecture initiaux sont vite obsolètes et ne seront maintenus qu’en contrepartie d’un investissement conséquent à faible valeur ajoutée pour l’utilisateur.
Les technologies évoluent (trop) vite, la maîtrise des technologies par les équipes de support et d’exploitation prend beaucoup plus de temps.
Les utilisateurs ne comprennent plus que l’informatique professionnelle soit décorrélées des technologies mises à dispositions par les GAFA.
Les projets sur plusieurs années sont obsolètes avant d’être ouverts aux utilisateurs.
Pourtant des méthodes et outils inspirés du design thinking, du Lean ou du manifeste agile sont là pour nous aider avec par exemple :
La méthode sprint pour l’expérimentation ;
Des outils de documentation automatique des architectures qui garantissent des schémas toujours à jour (2) ;
Une organisation devops et une automatisation du traitement des incidents ;
Une approche itérative des projets, pour apporter de la valeur aux utilisateurs de manière linéaire sans sacrifier la qualité.
Certains argumentent que ces transformations sont réalisables à l’échelle des startups ou de compagnies digital natives, mais c’est oublier que le dev-ops tire son origine du monde industriel, certes beaucoup moins souple que l’IT, mais où la transformation vers le lean a été une condition de survie. The phoenix project (3) illustre très bien les parallèles entre le monde industriel et l’agilité , plus proche de notre quotidien, la gestion des maintenances des TGV est opérée par la SNCF via des tableaux agiles où l’ensemble des bonnes pratiques sont respectées.
Se transformer pour survivre
Les architectes n’auront bientôt plus le choix, les projets planifiés à plusieurs années induisent trop de risques :
tant sur le budget (il est de plus en plus difficile d’obtenir un budget pluriannuel pour un projet qui délivrera dans un futur éloigné)
que sur l’adoption utilisateur : la solution prévue ne correspondra plus aux priorités du business lorsqu’elle aboutira.
L’architecte doit donc à la fois porter une vision à long terme permettant de respecter les règles de l’entreprise, garantissant l’exploitabilité de l’application et être capable de faire opérer des changements d’architecture pour répondre aux priorités métier à court terme.
Un changement de paradigme est nécessaire pour passer d’une organisation ou les technologies sont des capacités de soutien qui fournissent des services, des plates-formes ou des outils spécifiques au reste de l’organisation, tels que définis par les priorités, les ressources et le budget, à une organisation ou les technologies sont parfaitement intégrées et au cœur de tous les aspects de l’organisation en tant que moyen de libérer de la valeur et de permettre des réactions rapides aux besoins des entreprises et des parties prenantes (4).
Il nous faut nous habituer à la distribution de valeur dès le début du projet et nous préparer à prendre en compte les nouveaux besoins à chaque nouveaux sprints.
Les utilisateurs doivent se sentir impliqués, considérés. Leurs remarques doivent être valorisées afin de rentrer dans un cercle vertueux qui permettra de délivrer de l’expérience utilisateur de qualité en continu.
Le succès des projets dépend maintenant de la capacité des architectes à prendre en compte les besoins des utilisateurs, afin de toujours pouvoir s’adapter aux priorités métier et délivrer de la valeur au plus près des enjeux business. Ces changements bousculent certainement les habitudes ancrées dans la DSI, mais la valeur dispensée aux utilisateurs justifiera l’investissement à apporter dans ces changements.
Du 30 mai au 5 juin 2016, Rhapsodies Conseil a célébré pour la 1ère fois la Semaine Européenne du Développement Durable. Plusieurs animations ont été proposées afin d’offrir aux collaborateurs l’occasion de découvrir certains enjeux du Développement Durable, des solutions concrètes pour agir et des comportements responsables à adopter, avec notamment :
Un atelier sur le tri sélectif
Avec pour soucis de sensibiliser les collaborateurs à l’économie circulaire, cet atelier a été l’occasion de proposer des informations sur les enjeux du recyclage des déchets produits (en entreprise et à la maison) et des modes de consommation moins générateurs de déchets, ainsi qu’un challenge collectif sur les bonnes pratiques de tri.
Un déjeuner bio » title
Sur le thème d’une alimentation saine et équilibrée, un déjeuner d’équipe a été organisé au Café Lémoni (http://www.lemonicafe.fr/). Ce moment convivial a permis de partager une cuisine basée sur des ingrédients biologiques et d’échanger sur les enjeux d’une alimentation plus respectueuse des corps et de la planète.
Une collecte solidaire et favorisant la réutilisation
Les collaborateurs ont été invités à donner leurs tenues professionnelles pour leur offrir une seconde vie et contribuer à l’action de l’association La Cravate Solidaire http://lacravatesolidaire.org/. Leur générosité a ainsi permis de collecter plus d’une soixantaine d’articles qui bénéficieront à des candidats en insertion professionnelle.
L’événement a suscité beaucoup d’intérêts auprès des collaborateurs et RDV est donné en juin 2017 pour découvrir de nouveaux enjeux de la Responsabilité Sociétale d’Entreprise.
