Prendre RDV
May 18, 2026
Philippe est COO de Matters. En huit ans, il a contribué à construire près de dix produits fintech dans des environnements très différents : banques traditionnelles, grande distribution, assurance, énergie, venture capital. Certains ont très bien marché. D'autres moins. Tous ont rencontré des obstacles qu'il a fallu surmonter. C'est ce terrain-là qui nourrit cet article.
Le secteur fintech a beaucoup mûri ces dernières années. Les solutions BaaS (Banking-as-a-Service) ont démocratisé l'accès aux infrastructures bancaires, et les apps sortent plus vite qu'avant. Mais cette accessibilité technique crée parfois une illusion : celle qu’il ne reste plus qu'à construire le produit pour se lancer. Pourtant, sur la plupart des projets fintech, le développement du produit ne représente qu’une partie du coût réel. Le reste, on va vous expliquer où il se cache.
Sur un projet d'application fintech à fort enjeu social que nous avons accompagné, les contraintes réglementaires ont été intégrées dès la conception : hébergement de données sensibles, gestion de droits différenciés pour des comptes liés à des personnes vulnérables, validation juridique des parcours. En traitant ces enjeux comme des dimensions produit, on évite des ajustements tardifs qui impactent directement les coûts et les délais de mise sur le marché. Avec l’expérience de nombreuses fintech lancées, Matters intègre les équipes en charge de la compliance dès la conception. On parle de "Compliance-by-Design" : des parcours conçus en chambre sans expertise réglementaire ou juridique, c’est l’assurance de devoir les reprendre plus tard, avec parfois de lourds impacts sur les coûts et le calendrier.
Ainsi, une question centrale doit être clarifiée très tôt : à qui, au sein de l'équipe, incombe la responsabilité de garantir, dans la durée, l’adéquation du produit avec les contraintes réglementaires ?
Ce retour d’expérience illustre une réalité plus large : en fintech, la compliance n’est pas une étape ponctuelle. KYC (vérification d'identité), LCB-FT (lutte contre le blanchiment et le financement du terrorisme), reportings : ces obligations mobilisent des ressources tout au long du cycle de vie produit, et évoluent régulièrement.
Une dimension complémentaire reste rarement intégrée correctement dès le départ : le juridique et l’éditorial. En fintech, les mots ont une valeur légale.
Conditions générales d’utilisation, libellés d’action, mentions liées au découvert ou aux garanties… chaque élément doit être validé, cohérent avec le produit, et maintenu à jour.
Une nouvelle feature peut ainsi déclencher des impacts en cascade : mise à jour juridique, revue des parcours, voire notification aux régulateurs. La compliance est donc bien un coût de fonctionnement, pas juste de lancement.
La question n’est pas uniquement “combien coûte d’implémenter la conformité ? mais plutôt “comment intégrer durablement la compliance dans le fonctionnement du produit dès le départ ?”
Par exemple, devoir retravailler un parcours d’onboarding pour des raisons réglementaires plusieurs mois après sa conception conduit à des ajustements tardifs, des cycles d’itération non planifiés et entraîne des risques opérationnels et de cohérence produit.
Pour résumer, lors des cycles de conception produit, assurez-vous d'avoir répondu à ces deux enjeux stratégiques :
Sur un projet de mise en place de cashback instantané avec Carrefour, la réconciliation comptable quotidienne avec des exigences précises de la direction financière avait été cadrée dès le départ. Dans ce cas, l’anticipation a été le vrai levier : moins de dette opérationnelle post-lancement, peu de surprises durant le bêta test, et des cycles de validation qui ont pu être écourtés.
Notre rôle est justement de visibiliser et d’orchestrer ces dépendances dès le départ pour éviter qu’elles ne deviennent des points de blocage en fin de projet.
Sur un projet récent de lancement d’application bancaire B2B, l’intégration de plusieurs partenaires (BaaS, KYC, émission de cartes, anti-fraude, …) a été planifiée dès la conception. Les phases de contractualisation ont été anticipées, et les parcours utilisateurs conçus pour absorber les contraintes de chaque acteur. Plusieurs scénarios de croissance ont également été projetés afin d’anticiper les coûts réels et d’étudier différentes hypothèses de rentabilité.
Résultat : moins de surprises en fin de chaîne, et des phases de bêta test plus courtes et plus fluides.
Dans les faits, avant même d’écrire une ligne de code, une première couche de complexité apparaît. Les acteurs du BaaS (Skaleet, Swan, Treezor, Paymentology, Pismo…) ou du KYC (Checkout, Sumsub, Entrust…) ont chacun leur propre cycle de contractualisation et de mise en place : validation KYB du porteur de projet, négociation des conditions tarifaires et des SLAs, setup initial… Ces délais, ainsi que leur séquencement, échappent en grande partie à l’équipe produit.
Autre dimension structurante : la tarification. La majorité de ces services fonctionne à l’usage : chaque vérification d’identité, chaque opération financière a un coût variable selon les volumes et les niveaux de contrôle. Certaines grilles ne sont d’ailleurs pas publiques, et se négocient projet par projet, et parfois les coûts sont très complexes à projeter. Une souscription utilisateur complète, de l’inscription à l'émission d’une carte, en passant par la vérification d’identité, peut coûter jusqu'à 15€ en frais de services tiers.
Dans ce contexte, des arbitrages fonctionnels peuvent avoir un impact direct sur les marges. Par exemple : déclencher un KYC complet uniquement au moment où il devient réglementairement nécessaire, plutôt qu’en début de parcours.
D’un point de vue fonctionnel, les flux standards sont généralement bien gérés par les BaaS. Les difficultés apparaissent ailleurs : dans les cas aux limites, ceux qui touchent directement l’expérience utilisateur.
A titre d’exemple : un utilisateur qui change de téléphone en plein parcours KYC : peut-il reprendre sans recommencer une vérification coûteuse ? un virement rejeté avec un code technique : comment le traduire en message compréhensible sans générer d’inquiétude inutile ? un compte suspendu pour suspicion de fraude : quel parcours de déblocage pour éviter une perception de fermeture définitive ?
Ces situations arrivent très rapidement en production, parfois dès les premières semaines.
Dernier point rarement traité en amont : la fermeture de compte ou offboarding.
Comment un utilisateur quitte-t-il le service ? Comment récupère-t-il ses fonds ? Quels délais réglementaires s’appliquent ?
La complexité juridique et technique de l’offboarding est à prendre en compte dès la conception, et elle surprend presque toujours les équipes. Un offboarding négligé est un risque de réputation immédiat ainsi qu’un gouffre opérationnel pour votre service client.
Pour résumer, à cette étape, assurez-vous d'avoir anticipé l'impact financier des prestataires : les coûts associés à chaque étape du parcours utilisateur ont-ils été chiffrés ? Lesquels sont optimisables, par exemple en modifiant une fonctionnalité, ou en adaptant sa position dans un parcours ? Formalisez des scénarios en fonction de la tarification des prestataires et de vos hypothèses de croissance, afin de comprendre en amont vos coûts réels.
En fintech, le réflexe habituel tend à optimiser la fluidité d’usage à tout prix. Moins de clics, moins d'étapes, moins de friction. Sauf que dans un produit financier, trop de fluidité peut inquiéter l'utilisateur. Pas d'étape de confirmation visible ? Pas de signal de sécurité explicite ? Ça ressemble à une erreur, pas à une fonctionnalité.
L'enjeu n'est pas de supprimer la friction, c'est de la calibrer au bon endroit. Ce travail demande de la recherche utilisateur : tester différents niveaux de réassurance, observer les points d'abandon, comprendre ce qui génère de la confiance versus de l'anxiété. Un tunnel d'onboarding mal calibré peut doubler le coût d'acquisition, simplement parce que les utilisateurs partent à la moindre incertitude. Ce travail est presque toujours invisible dans les premiers chiffrages.
Sur une nouvelle venture lancée par une grande banque française pour un public peu familier avec les produits financiers digitaux, trouver le bon curseur a nécessité plusieurs cycles de tests utilisateurs. Trop fluide, le parcours suscitait de la méfiance. Trop structuré, il créait de la perte en route.
L’enjeu a donc été d’ajuster finement les moments de réassurance et de validation jusqu’à trouver un équilibre stable, accepté par les utilisateurs. Ce travail d’itération entre prototypage, observation et ajustements des parcours, représente un temps de prototypage significatif, rarement intégré dans les estimations initiales.
C'est souvent le dernier sujet abordé, et pourtant il amplifie tout le reste. Un projet fintech qui prend quelques mois de retard, ce sont des prévisions de chiffre d'affaires décalées et, dans un marché très mature, parfois une fenêtre business qui se referme.
Les causes sont connues : contractualisation BaaS plus longue que prévue, exigences de conformité qui évoluent en cours de route, cycles de test qui s’étirent. Mais une contrainte surprend régulièrement les équipes : les partenaires BaaS imposent souvent une phase de bêta fermée à volume limité, afin de valider l’ensemble des capacités du produit en conditions réelles.
Concrètement, cela signifie que le produit ne peut pas être lancé à grande échelle dès le départ. Le nombre d’utilisateurs est plafonné, souvent sur plusieurs semaines, ou jusqu'à l'atteinte d’objectifs prédéterminés par le BaaS. Résultat : impossible de générer du revenu à pleine capacité, acquisition bridée, feedback marché partiel, et surtout, un décalage entre le moment où le produit est “prêt” techniquement et celui où il peut réellement performer commercialement. À cela s’ajoutent des audits de sécurité indépendants, qui prolongent encore cette phase avant un lancement complet.
Point d'attention : Assurez-vous que l'échéancier reflète bien les réalités techniques du BaaS, de la gestion des accès limités (bêta) jusqu'à la validation des audits obligatoires.
Les zones de friction évoquées tout au long de cet article ne sont pas des imprévus isolés : ce sont des invariants du secteur fintech.
Les découvrir tard, c’est en payer le prix deux fois : le coût de la surprise, puis le coût de la réparation.
Travailler avec des partenaires qui ont déjà traversé ces sujets sur des projets comparables, c'est raccourcir la courbe d'apprentissage. Pas parce que les problèmes disparaissent, mais parce qu'on sait les anticiper, les budgéter, et les résoudre sans repartir de zéro.
Chez Matters, nous accompagnons les équipes produit et tech sur ces problématiques dès les premières phases de réflexion. Si vous souhaitez mettre votre stratégie à l'épreuve (coûts, partenaires, conformité), échangeons dès maintenant !
Matters accompagne les startups et scale-ups à développer des solutions vertueuses pour l'environnement et la société. Nous organisons régulièrement des meetups et des conférences au cours desquelles les intervenants partagent leurs expériences sur des thématiques dédiées. Pour être informé.e de nos prochains événements, inscrivez-vous à notre Newsletter ou suivez-nous sur Linkedin.
