L by LCL

J'interviens sur des produits que la réglementation encadre étroitement. Mon travail consiste à concevoir un produit qui respecte ces règles et qui reste simple à utiliser.

La squad s'appelle « Équipement ». Sa mission consiste à équiper le professionnel directement dans l'application de la banque. Équiper veut dire deux choses. La squad donne au professionnel des outils pour facturer et pour encaisser. Elle protège aussi son activité et ses moyens de paiement par l'assurance. Les clients visés sont des indépendants et de très petites entreprises, souvent de moins de vingt salariés.

Sur ce terrain, la réglementation s'applique à chaque produit, sous plusieurs formes. Le secret bancaire interdit à la banque de divulguer les informations de ses clients. Le RGPD (le règlement européen sur la protection des données personnelles) encadre l'usage de ces données. Les réseaux de cartes (les organismes qui gèrent les paiements par carte) fixent leurs propres règles. Le devoir de conseil en assurance oblige à proposer un contrat adapté à la situation du client. La facturation électronique devient obligatoire. Chaque décision se prend avec le juridique, la conformité et la lutte anti-fraude. Les chapitres qui suivent reprennent mes trois registres de travail, puis l'usage de l'IA dans le quotidien de l'équipe produit.

L'objectif principal de la mission était de cadrer de zéro l'encaissement par carte directement sur smartphone, sans terminal de paiement. Cette technologie s'appelle softPOS, ou Tap-to-Pay : le téléphone du commerçant reçoit lui-même le paiement sans contact. Les clients visés sont des micro-marchands, des artisans et des indépendants qui encaissent en déplacement. J'ai pris en charge le cadrage : les segments cibles, les cas d'usage, la proposition de valeur et le périmètre de la première version.

Le cadrage a commencé par un benchmark (une comparaison des offres existantes). Les néobanques et les fintechs de référence intègrent l'encaissement directement dans l'application bancaire, et l'activation se fait en temps réel. J'ai retenu ce parti pris pour une raison concrète. Le professionnel est déjà client de la banque, donc la banque a déjà vérifié son identité (KYC, le contrôle d'identité obligatoire du client). L'essentiel de l'enrôlement du marchand (son inscription comme commerçant qui accepte la carte) est donc déjà fait. L'activation devient quasi immédiate et l'onboarding (l'entrée du client dans le service) coûte moins cher. J'ai ensuite conçu le parcours de bout en bout : la souscription, l'accès, l'activation, puis l'encaissement lui-même. Un espace marchand permet au professionnel de retrouver ses transactions.

La principale difficulté venait du nombre d'acteurs. Encaisser une carte sur un simple téléphone fait intervenir plusieurs acteurs : la banque acquéreur (la banque qui reçoit les paiements par carte pour le compte du commerçant), les réseaux de cartes et leurs règles, le fournisseur de la technologie softPOS, l'éditeur du système d'exploitation du téléphone pour la certification, et la conformité en matière de paiement. Chaque acteur a ses propres contraintes, et les flux de données passent de l'un à l'autre. L'essentiel du cadrage a consisté à décrire cette architecture acteur par acteur, puis à ordonner ce qui pouvait entrer dans la première version.

Ce cadrage a produit deux arbitrages qui structurent le produit. Le premier concerne la conformité. Le cadre interne de la banque ne couvrait pas encore l'encaissement en présentiel sur téléphone. Ce manque était déjà identifié à mon arrivée. Il fallait faire définir ce cadre avant de construire, ce qui économise des mois. J'ai suivi cette définition avec la conformité et je l'ai inscrite au cadrage du produit. Le second arbitrage concerne la plateforme : la première version sort d'abord sur Android, parce que le Tap-to-Pay sur iOS dépend d'un programme de licence propre à l'éditeur du système. Un troisième point concernait l'éligibilité des commerçants. Les réseaux de cartes conditionnent l'encaissement au MCC (Merchant Category Code, le code qui classe le commerçant par activité), et la banque ne disposait pas de cette donnée. La banque connaît le code NAF de chaque entreprise (le code d'activité attribué par l'INSEE). Nous avons conçu une table de correspondance qui déduit le MCC du code NAF et détermine ainsi l'éligibilité automatiquement.

Ma mission a couvert le cadrage complet de la fonctionnalité, puis sa livraison (la phase de développement), jusqu'à sa reprise par un autre Product Manager. Le produit n'était pas lancé à la fin de ma mission. Il était en phase finale de construction. Ses principaux risques étaient identifiés et traités, et l'équipe en partageait une définition commune. Il n'existe donc pas encore de données d'usage.

La facturation est le deuxième registre de ma mission. Cette fonctionnalité est intégrée à l'application bancaire et proposée par un partenariat avec une fintech. Elle m'a été confiée en cours de mission, bloquée. Elle était entièrement développée, parcours compris. La conformité n'avait jamais validé sa mise en production. Elle avait été construite sans Product Manager. Tout le travail amont de cadrage et de conformité restait donc à faire. L'enjeu était réel : la facturation électronique devient obligatoire pour les entreprises assujetties à la TVA. Offrir cette fonctionnalité met nos clients en conformité, à condition que la banque soit elle-même en conformité.

Le parcours d'éligibilité interroge le partenaire par API (une interface qui permet à deux logiciels d'échanger des données) et renvoie immédiatement l'un de quatre verdicts. Le client est éligible. Le client possède déjà un compte chez le partenaire : ce compte est à réconcilier (à relier, sans en créer un second) et peut basculer sur l'offre gratuite. Le client est inéligible parce qu'il détient déjà une offre supérieure. Le client est inéligible parce qu'il gère plusieurs entreprises. J'ai repris ce parcours et refondu les cas de refus.

Le problème principal se situait en amont du parcours. Dans le montage d'origine, le produit créait un compte chez le partenaire dès l'entrée en relation (l'ouverture du compte bancaire). L'utilisateur n'était pas encore informé, et le partage de ses données n'était pas cadré. Ce montage posait un problème de secret bancaire et de RGPD, et il bloquait la mise en production. J'ai retravaillé le dispositif avec la conformité et je l'ai découpé en deux temps, pour que le produit applique lui-même la règle. Au premier temps, l'utilisateur signe dès l'entrée en relation les conditions qui l'informent d'un partage possible de ses données. Au second temps, la transmission des données et la création du compte partenaire se déclenchent seulement quand l'utilisateur active lui-même la fonctionnalité. Le consentement est recueilli avant tout partage, et la transmission concerne uniquement les clients qui activent. La fonctionnalité est passée en production. Une fois en ligne, j'ai piloté la migration de l'ensemble des clients déjà actifs par l'API du partenaire. Chaque client a été réconcilié avec son compte existant, ou a reçu un nouveau compte, au cas par cas.

La gamme d'assurance pour les professionnels se souscrit en ligne dans l'application, avec une signature électronique et une validation d'identité. Elle est distribuée avec des assureurs partenaires. J'ai structuré et documenté cette offre pour la squad, sous deux formes : un référentiel produit (le document de référence qui décrit l'offre) et une grille de réponses pour le support. Je suis reparti des contrats et des parcours réels.

La cartographie du parcours d'assurance a montré un décalage dans le temps. Le besoin d'assurance responsabilité civile professionnelle (l'assurance qui couvre les dommages causés à des tiers dans l'exercice de l'activité) est le plus fort au moment de la création de l'entreprise. La souscription arrive après ce moment. De plus, le parcours de création d'entreprise est capté par un acteur tiers, en amont de la banque. Le pic de besoin se situe donc hors du périmètre de la banque. J'ai étayé ce constat par la donnée et je l'ai apporté aux discussions de roadmap (le plan des évolutions du produit) et de positionnement.

Au-delà du produit, nous avons outillé le quotidien de l'équipe produit avec l'IA, sur les tâches où elle fait gagner du temps.

Les retours clients arrivaient par Crisp (l'outil de messagerie du support client), en flux continu et sans traitement. Nous avons monté une chaîne qui collecte ces messages, les synthétise avec l'IA et les trie vers les équipes concernées. Elle produit un récapitulatif hebdomadaire sourcé : chaque point renvoie au message d'origine. L'équipe dispose ainsi d'une liste de sujets qu'elle peut prioriser.