Développer ou acheter : le coût réel d'un système de core banking

Tôt ou tard, tout fondateur de fintech chiffre la même décision : développer le core banking en interne, ou en licencier un et le configurer. La comparaison naïve — une licence d'un côté, quelques salaires de développeurs de l'autre — est presque toujours fausse, car les deux colonnes ne contiennent pas les mêmes choses.

La comparaison honnête, c'est le coût total de possession sur la durée de vie du produit : la construction, la maintenance permanente, l'entretien de la sécurité et de la conformité, et les revenus que vous ne générez pas pendant que vous développez. Nous concevons des logiciels de core banking, nous avons donc évidemment une position — mais le calcul ci-dessous est celui que nous voudrions voir si nous étions les acheteurs.

Ce qu'un « système de core banking » recouvre vraiment

La plupart des estimations développer-ou-acheter déraillent avant même d'écrire le premier chiffre, parce que le périmètre est sous-estimé. L'application bancaire que voient vos clients est la fraction visible du système. Un core prêt pour la production, ce sont quatre produits en un :

• Le cœur transactionnel : un grand livre en partie double qui reste équilibré sous charge concurrente, où chaque solde est dérivé du grand livre et rapproché chaque jour de chaque prestataire.
• Le produit client : l'application bancaire elle-même, l'onboarding avec niveaux KYC et KYB, les comptes multidevises, les virements, les cartes — et, de plus en plus, des wallets crypto avec une vraie conservation des clés derrière.
• Le second produit que personne ne budgète : un back-office opérations pour les files de conformité, la surveillance des transactions, la configuration des frais, le reporting et des rôles staff granulaires.
• La couche invisible : une piste d'audit en append-only, des parcours de double authentification au-delà du login, le rate limiting, l'empreinte d'appareil, et une gestion des clés qui garde les secrets hors du code et de la base de données.

La voie du développement : ce que contient vraiment le budget

Un développement interne réaliste exige des ingénieurs backend seniors expérimentés en systèmes financiers, des ingénieurs frontend, du DevOps et de la sécurité, de la QA, et une coordination produit qui comprend la conformité. Les équipes qui atteignent une qualité de production descendent rarement sous six à dix profils seniors — et le profil rare, l'ingénieur qui a déjà opéré grands livres et conservation en production, est précisément le plus difficile à recruter et à retenir.

Côté délais, le schéma est constant : un à deux ans pour atteindre ce qu'une plateforme mature offre dès le premier jour. Le temps ne part pas dans les écrans ; il part dans la justesse du grand livre sous concurrence, dans des intégrations de prestataires qui apportent chacune leurs particularités de sandbox et leurs étapes de certification, dans le durcissement sécurité, et dans la longue traîne de cas limites qui n'apparaissent qu'avec de vrais clients et de l'argent réel.

Et les dépenses ne s'arrêtent pas au lancement. Les prestataires changent leurs APIs, les réseaux blockchain évoluent, la réglementation bouge, les dépendances vieillissent. Un core interne n'est pas un projet qui se termine ; c'est une équipe permanente que vous vous engagez à financer tant que le produit existe.

Les coûts qui n'apparaissent jamais dans le tableur

• Le coût d'opportunité : chaque mois passé à construire le grand livre est un mois où le produit n'est pas sur le marché. Les concurrents qui ont licencié leur core recrutent des clients et itèrent sur leurs prix pendant que vous intégrez encore des prestataires.
• Le risque de recrutement : le plan suppose que l'équipe qui commence le chantier le termine. Perdre l'un des deux ingénieurs qui comprennent le grand livre en cours de route est un événement de calendrier qui se mesure en mois.
• La traîne de la justesse : un grand livre juste à 99 % n'est pas presque terminé — c'est un générateur de tickets de support, d'écarts de rapprochement et d'incidents réglementaires. Le dernier 1 % coûte plus cher que les premiers 99 %.
• La sécurité comme opération : tests d'intrusion, rotation des clés, réponse aux incidents, surveillance et alertes — des coûts récurrents qui existent même quand tout va bien.
• L'entretien de la conformité : expiration des documents KYC, règles sur les crypto-actifs en évolution, nouvelles obligations déclaratives. Le travail revient chaque année et ne peut pas être différé.
• Le back-office : les développements internes traitent systématiquement l'outillage du staff comme une réflexion tardive, et l'équipe opérations hérite d'une console SQL. Chaque régulateur ou auditeur qui verra cela vous fera le reconstruire correctement.
• La localisation : livrer dans de nombreuses langues avec une vraie prise en charge du RTL coûte peu quand c'est prévu dès le premier jour, et cher à rattraper une fois le produit construit.

La voie de l'achat : ce que vous payez et ce qui reste à vous

Côté achat, la colonne technologie est explicite : une licence ou une location de la plateforme — les éditeurs sérieux tarifient modules, blockchains et langues individuellement, si bien que la facture suit ce que vous activez réellement — plus l'infrastructure sur laquelle tourne l'instance. Ce que l'achat ne supprime pas : vos licences réglementaires ou accords de partenariat, vos contrats commerciaux avec les prestataires, votre équipe d'exploitation, votre distribution. Ces coûts appartiennent à l'opérateur sur les deux voies — acheter supprime la montagne d'ingénierie, pas le métier.

Les coûts honnêtes de l'achat ont la forme d'une dépendance : la feuille de route ne vous appartient pas entièrement, et la plateforme ne vaut que ce que vaut son plus mauvais module. Les parades se vérifient avant de signer : une instance dédiée avec votre propre base de données et vos propres secrets chiffrés, pour que quitter l'éditeur soit une migration et non une négociation d'otages ; des intégrations de prestataires derrière une couche d'abstraction, pour que les accords restent les vôtres et que les prestataires soient remplaçables ; une licence modulaire, pour ne payer que ce que vous activez ; et la preuve que la plateforme a traité de vrais clients et de l'argent réel.

Quand développer en interne est le bon choix

Développer ou acheter n'est pas une question rhétorique à réponse préétablie. Développer est le bon choix quand au moins l'une de ces conditions est vraie :

• L'infrastructure est le produit : vous vendez le grand livre, la conservation ou la capacité de banking-as-a-service elle-même ; en être propriétaire est le métier.
• Votre différenciation tient à des exigences qu'aucun éditeur ne couvre — non pas des fonctionnalités qui manquent à un éditeur ce trimestre, mais des capacités structurellement hors du champ des plateformes.
• Vous disposez déjà d'une équipe senior avec une expérience du core banking en production, et de la trésorerie pour la financer pendant des années sans revenus.
• Un régulateur ou une maison mère impose le contrôle interne complet de la stack comme une condition non négociable.

Une grille de cinq questions

• Différenciation : un client vous choisira-t-il un jour parce que votre grand livre est fait maison ? Si votre avantage tient au produit, à la distribution ou au prix, le core est de la plomberie — essentielle, mais pas à réinventer.
• Délais : l'entreprise peut-elle absorber un à deux ans sans revenus pendant la construction du core, sur un marché qui n'attend pas ?
• Équipe : avez-vous, ou pouvez-vous raisonnablement recruter et retenir, des ingénieurs qui ont opéré en production des systèmes qui déplacent de l'argent ?
• Coût à trois ans : comparez le coût de construction plus une équipe de maintenance permanente à la licence plus les modules activés sur trois ans — jamais coût de lancement contre coût de lancement.
• Sortie : à quoi ressemble le départ sur chaque voie ? En interne, le risque est de voir partir les personnes clés avec le savoir. Avec un éditeur, exigez une instance dédiée, votre propre base de données et vos propres clés : la sortie devient une migration.

Où se situe Coreza dans cette décision

Coreza est la colonne achat, construite pour passer la checklist ci-dessus : chaque client exploite une instance dédiée sur AWS avec sa propre base de données et ses propres secrets chiffrés, chaque module — blockchains, langues et tokens compris — est licencié individuellement pour que le prix suive ce que vous activez, et les intégrations de prestataires vivent derrière une couche d'abstraction pour que les accords commerciaux restent les vôtres.

Une version de ce core tourne en production chez une fintech européenne régulée depuis 2024, et une nouvelle instance se déploie en quelques semaines : marque, modules, langues et blockchains sont de la configuration, pas de l'ingénierie. Si vous êtes en train de faire les calculs développer-ou-acheter, c'est la comparaison que nous vous invitons à faire — coût à trois ans contre coût à trois ans, avec la colonne cachée remplie.