Guide d'achat des plateformes de néobanque en marque blanche

Une plateforme de néobanque en marque blanche est un logiciel auquel vous apposez votre marque pour lancer une application de type bancaire (comptes, cartes, virements, parfois crypto) sans construire le cœur de zéro. En acheter une, c'est en réalité acheter deux choses faciles à confondre : le cœur qui fait circuler l'argent, et la couche applicative que voient vos clients. Ce guide aide à les distinguer avant de signer, car presque toutes les questions difficiles sur une plateforme en marque blanche reviennent à savoir où passent ses coutures. Le travail d'un éditeur est de brouiller cette ligne, celui de l'acheteur est de la trouver.

Cinq distinctions valent la peine d'être faites avant de vous engager : cœur contre couche applicative, emplacement de la licence, profondeur du design system, livraison autonome ou embarquée, et l'arbitrage build ou buy qui sous-tend le tout. Prenons-les dans l'ordre.

Première distinction : le cœur et la couche applicative

La ligne la plus utile à tracer sépare ce qui doit être correct de ce qui doit être à vous. Le cœur coûte cher s'il est faux : grand livre en partie double, comptes et soldes, KYC et onboarding, émission et traitement des cartes, rails crypto et stablecoins, et la console opérateur qui pilote le tout. La couche applicative est ce que le client touche : la marque, les écrans, l'architecture de l'information, le sous-ensemble de fonctionnalités activées. Une plateforme qui mérite d'être achetée partage un seul cœur entre toutes les marques et configure l'application par tenant. Évaluez les deux sur des axes différents : jugez le cœur sur sa justesse (le grand livre est-il vraiment en partie double, le rapprochement tient-il, les opérateurs peuvent-ils réellement l'exploiter) et la couche applicative sur sa flexibilité, c'est-à-dire jusqu'où une marque peut s'écarter avant qu'il faille forker.

Où se situe la licence, et si elle est dissociable

L'autorisation de détenir ou de transférer des fonds est réglementée, et ce n'est pas le même achat que le logiciel. Demandez clairement si la plateforme inclut une autorisation réglementaire ou si vous devez apporter la vôtre. Si elle en inclut une, de qui est la licence, dans quels pays, et êtes-vous son client direct ou son agent ? Pour l'acheteur, tout se joue sur la séparation : une plateforme qui soude son logiciel à une licence unique que vous ne pouvez pas remplacer a discrètement choisi à votre place votre juridiction et votre partenaire, tandis qu'une plateforme qui traite la licence comme un rail que vous apportez vous laisse choisir l'autorisation indépendamment et en changer plus tard. Aucun des deux n'est une erreur, mais vous devez savoir lequel vous achetez. Protocore Pay (/products/pay) est la couche logicielle seule : elle s'appuie sur les rails réglementés que vous apportez, et aucun logiciel n'est une licence. Les notions que vous rencontrerez dans cette discussion (EMI, établissement de paiement, agent, banque sponsor) sont expliquées dans le /glossary.

Quelle profondeur pour le design system

Toute la promesse de la marque blanche est que l'application ait l'air d'être la vôtre, et non un simple habillage de la démo de l'éditeur, et cette promesse n'a que la profondeur du design system qui la porte. Un système superficiel permet de changer un logo et une couleur d'accent. Un système profond expose le vrai vocabulaire (couleur, typographie, rayon des angles, espacement, densité, animation) sous forme de tokens lus par chaque écran, de sorte qu'une marque est un ensemble de surcharges plutôt qu'un fork. Demandez combien il y a de tokens et ce qu'ils couvrent, si les mêmes tokens sont émis pour le web, le natif et le desktop afin qu'une couleur soit la même partout, et si un designer peut éloigner un tenant de la version de référence sans toucher au code. Le design system de Protocore (/products/pds) en est une réponse concrète (144 tokens et 889 classes utilitaires, dark-first, rayon à zéro par défaut, émis pour le web, .NET et le natif), mais la question de l'acheteur est plus générale : la couche de design est-elle un vrai système de tokens, ou une couche de peinture sur une application figée ?

Application autonome ou couche embarquée

La livraison prend deux formes. Une application autonome est une application bancaire complète que vous habillez à votre marque et diffusez sous votre nom : vos clients téléchargent votre banque. Une couche embarquée est un ensemble de composants et de parcours que vous intégrez à un produit existant : paiements et soldes au sein de votre application actuelle. Le choix ne porte pas sur la qualité, mais sur l'endroit où l'expérience financière a sa place. Si la banque est votre produit, il vous faut la version autonome. Si la banque est une fonctionnalité d'un produit plus large (une place de marché qui paie ses vendeurs, une plateforme qui offre un wallet à ses utilisateurs), il vous faut la voie embarquée, pour que l'argent vive là où sont déjà vos clients. Une plateforme qui mérite d'être achetée sait faire les deux à partir d'un seul cœur, car le cœur se moque que son front-end soit une application autonome ou un panneau dans le produit d'un autre.

Build ou buy : l'arbitrage, en toute franchise

Construire le cœur soi-même donne le contrôle et coûte des années. Un grand livre correct, le traitement des cartes, le KYC, le rapprochement et une console opérateur sont chacun un projet, et tous sont un ticket d'entrée à franchir avant d'avoir livré la moindre fonctionnalité que le client remarque. Acheter le cœur rachète ces années et coûte un peu de souveraineté : vous héritez du modèle de compte, de plafond et de règlement de quelqu'un d'autre. La bonne façon de décider est de se demander quelles parties sont votre produit et lesquelles sont de la plomberie. La plomberie (règlement, rapprochement, outils de conformité) est à peu près la même pour tout le monde et rarement là où l'on gagne : achetez-la. Les parties pour lesquelles vos clients vous choisissent vraiment (les parcours, la marque, la seule chose que vous faites mieux que l'acteur en place) sont celles où vos propres ingénieurs doivent passer leur vie. Acheter une plateforme, c'est parier que le cœur est de la plomberie et que votre différenciation se situe au-dessus.

On n'achète jamais une néobanque. On achète un cœur dont on espère qu'il n'est que de la plomberie et une couche applicative que l'on compte rendre sienne, et toute l'évaluation consiste à déterminer si l'éditeur a tracé cette ligne là où vous l'auriez tracée.

Cinq directions, pas cinq produits

Demandez des exemples à un éditeur et on vous montrera souvent une poignée d'applications abouties. Lisez-les correctement : ce sont des directions que le même cœur peut prendre, pas un menu où choisir un seul plat. Le cœur de référence d'une plateforme peut alimenter une exchange épurée (Halcyon : sobre, le trade au premier plan), une super-app orientée chat (Lumen : l'argent circule dans la conversation), une application centrée sur les virements (Fern : paiements groupés et conversion par règles d'abord), une version stablecoin en dark (Volt : un trieur de salaire et des cartes d'équipe) et un compte multidevise (Meridian : un solde EUR à côté d'USDC, et un compte BTC où atterrissent les récompenses de carte). Cinq marques, cinq architectures de l'information, cinq combinaisons de fonctionnalités : un seul grand livre, un seul KYC, un seul processeur de cartes sous chacune d'elles. Le nombre qui compte n'est pas cinq, mais le nombre de tenants que le cœur peut porter. Un éditeur qui vous dit que le produit, ce sont cinq applications a mal compris son propre produit ; celui qui vous en montre cinq pour prouver que la sixième est triviale l'a compris.

Les questions qui départagent les fournisseurs

Une courte liste suffit à désamorcer la plupart des présentations commerciales. Le cœur est-il un système partagé ou un fork par client — et quand un bug est corrigé, le correctif atteint-il tous les tenants en même temps ? La couche design expose-t-elle de vrais tokens, ou juste un emplacement pour un logo ? La plateforme inclut-elle une autorisation réglementée, ou dois-je apporter la mienne — et pourrai-je la remplacer plus tard ? Le même cœur peut-il livrer à la fois une app autonome et une couche embarquée ? Qu'est-ce que vous considérez comme de la plomberie, et qu'attendez-vous que je construise moi-même ? Les réponses situent un fournisseur sur la carte que ce guide a tracée : cœur partagé ou ferme de forks, système de tokens ou simple peinture, logiciel plus ma propre licence ou bundle soudé, une seule forme de livraison ou deux. Le démontage complet d'un de ces cœurs — les cinq directions, l'app de référence et la console opérateur qui les pilote — est sur /products/pay, le design system sous-jacent sur /products/pds, et les termes sont dans le /glossary.