Le développement logiciel fintech se chiffre et se planifie comme du développement logiciel ordinaire, jusqu’au moment précis où quelqu’un demande qui est autorisé à détenir l’argent. À partir de là, le projet cesse d’être un exercice d’ingénierie pour devenir un exercice réglementaire assorti d’une composante technique, et le calendrier que vous aviez en tête n’est plus tenable.
La technique est rarement la partie difficile. Déplacer de l’argent est un problème résolu, avec des prestataires matures, des interfaces documentées et des environnements de test disponibles dès le premier jour. Ce qui allonge un projet fintech, c’est la situation au regard de l’agrément, les obligations de piste d’audit, et le fait que plusieurs décisions d’architecture sont déjà prises par celui qui détient la licence.
La question qui fixe votre calendrier : êtes-vous agréé, travaillez-vous comme agent sous les permissions d’un tiers, ou évitez-vous entièrement l’activité réglementée ? Ces trois réponses produisent des projets de durées radicalement différentes, et l’écart se mesure en mois d’attente plutôt qu’en semaines de construction. Répondez avant de cadrer quoi que ce soit.
L’agrément FCA est le chemin critique
Si vous avez besoin d’un agrément direct, c’est cette procédure, et non la construction, qui détermine votre date de lancement.
Le régulateur britannique, la FCA, a l’obligation légale de statuer sur les demandes dans des délais fixes, et ces délais ont changé récemment. Depuis janvier 2026, la FCA a réduit ses délais légaux pour les nouveaux agréments et les extensions de permissions à 4 mois pour un dossier complet et 10 mois pour un dossier incomplet, contre 6 et 12 auparavant. Pour les extensions étroitement alignées sur un modèle d’affaires existant, elle s’engage sur 3 mois en cas de dossier complet et 6 en cas de dossier incomplet. Pour les dirigeants soumis à approbation, elle vise au moins la moitié des dossiers en 35 jours. Ce sont des délais du régulateur britannique, applicables aux seuls projets relevant de ce régime.
Deux conséquences. Le compteur démarre lorsque le dossier est complet, pas lorsque vous le déposez pour la première fois : une demande comportant des lacunes est de fait suspendue tant que vous ne les comblez pas, et chaque question sur le plan d’affaires ou les fonds propres coûte des semaines. Ensuite, même les 4 mois améliorés dépassent la durée de la plupart des MVP : l’ordre raisonnable consiste donc à lancer le travail d’agrément en premier et à construire en parallèle, plutôt que de construire puis de déposer.
La plupart des jeunes fintechs évitent tout cela en opérant comme agent d’une entreprise agréée ou en s’appuyant sur un prestataire qui détient déjà les permissions. C’est une voie légitime et très répandue, et elle raccourcit nettement le délai de mise sur le marché. C’est aussi une dépendance commerciale : votre produit vit à l’intérieur de l’appétit pour le risque d’un tiers, et son équipe conformité peut modifier votre feuille de route.
Le développement logiciel fintech commence par les rails
Le rail que vous retenez n’est pas un détail d’implémentation : il détermine votre modèle de données, votre gestion des échecs et votre charge de rapprochement.
Les paiements par carte s’intègrent vite et amènent les impayés contestés, ce qui impose d’avoir un cycle de vie du litige dans le modèle de données dès le premier jour, et non greffé plus tard. Faster Payments règle en quelques secondes mais fonctionne uniquement en poussée, donc encaisser exige que le payeur agisse et votre système doit gérer cette attente. Le prélèvement encaisse de façon fiable selon un calendrier et amène la gestion des mandats, les échecs de collecte et le mécanisme de garantie. L’open banking offre l’initiation de paiement et l’information sur les comptes, avec authentification forte et un consentement qui expire, que votre système doit suivre et renouveler.
La plupart des produits finissent avec deux rails ou plus, et c’est là que se loge le coût d’ingénierie. Rapprocher un rail est simple. En rapprocher trois, chacun avec son propre calendrier de règlement, ses modes de défaillance et ses identifiants, constitue un sous-système considérable que personne ne budgète parce qu’il est invisible de l’extérieur. Il faut y ajouter le traitement des fichiers de règlement quotidiens, le rattachement des commissions et des impayés à la transaction d’origine, et une procédure pour les montants qui ne se rattachent à rien.
Partez du principe que le règlement est asynchrone et que le rapprochement est une fonctionnalité à part entière. Les systèmes qui modélisent un paiement comme une requête synchrone qui réussit ou échoue doivent être refaits dès le premier règlement tardif.
Ce qu’un logiciel réglementé ajoute au chantier
Quatre obligations que le logiciel ordinaire ne porte pas.
Une piste d’audit inaltérable. Chaque changement d’état sur un enregistrement financier doit être consigné avec le qui, le quoi, le quand et le pourquoi, sous une forme que personne ne peut modifier discrètement. Cela impose une conception en ajout seul plutôt que la mise à jour des lignes en place, et cela façonne le schéma.
La séparation des fonds clients, si vous détenez des fonds. Les règles sont strictes et le reporting est précis. Les entreprises sous-estiment généralement le reporting plutôt que la ségrégation elle-même.
Les contrôles de criminalité financière. Vérification d’identité, filtrage des sanctions et surveillance des activités suspectes. L’essentiel s’achète plutôt qu’il ne se construit, mais l’intégration, le circuit de traitement des dossiers et la traçabilité des décisions restent à votre charge.
Une protection des données plus exigeante. Les données financières sont sensibles, les durées de conservation sont fixées par la réglementation et non par préférence, et les demandes d’effacement entrent en tension avec les obligations légales d’archivage d’une manière qu’il faut trancher tôt. Notre guide sur la conformité technique au RGPD en détaille la mécanique.
Rien de tout cela n’est de l’ingénierie exotique. Tout cela prend du temps, et tout cela doit pouvoir être démontré à quelqu’un qui le demandera.
Ce que cela coûte au Royaume-Uni
| Configuration | Fourchette habituelle | Durée |
|---|---|---|
| Modèle d’agent, un seul rail, sans agrément direct | £60 000 à £120 000 | 3 à 5 mois |
| Permissions propres, deux rails, contrôles criminalité financière | £150 000 à £400 000 | 6 à 12 mois |
| Plateforme multi-rails, fonds clients, reporting | à partir de £400 000 | 12 mois et plus |
Ce sont des coûts de construction. L’agrément entraîne ses propres dépenses juridiques et de conseil, et la période d’attente consomme de la trésorerie, que quelqu’un écrive du code ou non. Notre guide des coûts du développement logiciel sur mesure couvre les fourchettes générales, et le logiciel de santé au Royaume-Uni montre le même schéma dans un autre secteur réglementé.
La fourchette qui surprend est celle du milieu. Ajouter vos propres permissions et un second rail double à peu près un projet, et presque rien de cette hausse n’est visible pour l’utilisateur.
Comment ordonner le chantier
Réglez d’abord la question réglementaire, par écrit, avec quelqu’un de qualifié. Tout le reste en dépend et la réponse change l’architecture.
Construisez ensuite la plus petite chose qui déplace de l’argent réel sur un seul rail, car le second rail devient bien plus simple une fois le rapprochement en place. Traitez la piste d’audit et le rapprochement comme des fonctionnalités dotées de critères d’acceptation, et non comme une infrastructure à ajouter plus tard, car greffer un historique en ajout seul sur un système qui met les lignes à jour revient presque à tout réécrire.
Mecanik construit des logiciels financiers réglementés au sein de son équipe de développement logiciel , y compris les parties sur lesquelles les auditeurs posent des questions. Si votre calendrier fintech suppose que la construction est le chemin le plus long, la situation au regard de l’agrément mérite d’être vérifiée avant de vous engager sur une date.
Articles en relation: Développement de MVP : périmètre, coût et délai , Développement logiciel sur mesure UK - Guide de l’acheteur , Comment créer une application web en 2026 , Agents IA en entreprise : coûts et échecs .
Questions fréquentes
Combien de temps prend un agrément FCA ? Depuis janvier 2026, les délais légaux du régulateur britannique sont de 4 mois pour un dossier complet et 10 mois pour un dossier incomplet, contre 6 et 12 auparavant. Les extensions étroitement alignées sur un modèle d’affaires existant visent 3 mois en dossier complet et 6 en dossier incomplet. Le compteur démarre à la complétude du dossier, pas au premier dépôt, donc les lacunes le suspendent de fait.
Combien coûte le développement logiciel fintech au Royaume-Uni ? Un produit en modèle d’agent sur un seul rail, sans agrément direct, se situe généralement entre £60 000 et £120 000 sur 3 à 5 mois. Ajouter vos propres permissions, un second rail et des contrôles de criminalité financière porte le total entre £150 000 et £400 000 sur 6 à 12 mois. Les plateformes multi-rails détenant des fonds clients démarrent autour de £400 000.
Faut-il un agrément FCA pour construire un produit fintech ? Pas toujours. Beaucoup de produits en phase initiale opèrent comme agent d’une entreprise agréée ou s’appuient sur un prestataire qui détient déjà les permissions, ce qui évite entièrement l’attente. La contrepartie est une dépendance commerciale : votre produit fonctionne dans l’appétit pour le risque d’une autre entreprise, dont les décisions de conformité peuvent changer votre feuille de route.
Quel rail de paiement une fintech britannique doit-elle utiliser ? Cela dépend du sens et du calendrier des flux. Les cartes s’intègrent vite et amènent les impayés contestés. Faster Payments règle en secondes mais fonctionne en poussée, donc l’encaissement exige que le payeur agisse. Le prélèvement encaisse selon un calendrier et amène la gestion des mandats. L’open banking offre l’initiation de paiement avec un consentement qui expire et que votre système doit suivre.
Que réclame un logiciel réglementé qu’un logiciel ordinaire ne réclame pas ? Une piste d’audit inaltérable enregistrant chaque changement d’état d’un enregistrement financier, la séparation des fonds clients et son reporting si vous détenez des fonds, des contrôles de criminalité financière couvrant la vérification d’identité et le filtrage des sanctions, et une protection des données dont les durées de conservation sont fixées par la réglementation. Rien n’est exotique, mais tout doit être démontrable.
Commentaires