Construire une plateforme de tokenisation : les 8 briques techniques

1. La question qui revient à chaque échange

Quand un opérateur immobilier nous appelle pour explorer la tokenisation, l'une des premières questions qui revient souvent en deuxième ou troisième échange c'est : « et si on construisait ça en interne ? »

C'est une question légitime, et elle mérite une réponse sérieuse. Pas une réponse marketing. Une réponse d'ingénieur qui décompose ce qu'il faut construire, ce que ça coûte réellement, et où sont les pièges qu'on ne voit pas avant d'y être.

Cet article décompose les huit briques techniques qu'une plateforme de tokenisation immobilière doit fournir pour passer en production. Pour chaque brique : ce qu'elle fait, ce qu'elle coûte à construire correctement, et les écueils les plus fréquents et la plupart qu'on a traversés chez Fraktion en construisant la nôtre.

2. Les huit briques d'une plateforme de tokenisation immobilière

Pour émettre, distribuer et administrer un actif immobilier tokenisé de bout en bout, voici ce qu'une plateforme doit savoir faire :

1. Le socle blockchain : le registre distribué sur lequel sont inscrits les tokens et leurs mouvements.
2. Le moteur de smart contracts : le code qui régit l'émission, les transferts, les restrictions et le cycle de vie des tokens.
3. Le KYC/AML industriel : l'identification et la qualification des investisseurs, multi-juridictionnel, avec piste d'audit.
4. La gestion du véhicule juridique : l'articulation entre le SPV ou le fonds (monde papier) et le registre tokenisé (monde on-chain).
5. L'onboarding investisseur : le parcours complet de souscription, du formulaire à l'attribution des tokens.
6. La distribution multi-canal : direct, CGP, family offices, plateformes partenaires.
7. Le lifecycle du token : corporate actions, dividendes, votes, reporting, marché secondaire.
8. Le règlement : l'acheminement des flux financiers en lien avec les mouvements de tokens.

Chacune de ces briques est non-optionnelle. Si une seule manque, la chaîne n'est pas complète, et le projet ne peut pas passer en production.

À fin 2025, quatre infrastructures intégrées de ce type désignées DLT Trading and Settlement Systems dans le cadre européen ont été autorisées par les régulateurs nationaux : 21X en Allemagne, Axiology DLT en Lituanie, LISE en France, et Securitize Europe en Espagne. Chacune a construit son propre stack technique. C'est à la fois la preuve que les huit briques sont reproductibles, et le rappel que chaque acteur a dû réinventer plusieurs de ces briques en interne. Le coût accumulé de cette duplication, à l'échelle d'un marché qui démarre, est précisément ce qu'une infrastructure mutualisable vient adresser.

Une plateforme de tokenisation, ce n'est pas un produit. C'est une chaîne. Et une chaîne se brise sur son maillon le plus faible.

3. Les briques où le build est massivement sous-estimé

Trois briques concentrent l'essentiel du coût caché d'un build interne.

Le socle blockchain. Le premier réflexe d'une équipe qui démarre, c'est Ethereum mainnet par défaut, parce que c'est le plus connu. C'est aussi le plus cher à l'usage : les frais de transaction peuvent atteindre plusieurs dizaines d'euros par opération en période de congestion réseau. Pour une plateforme qui doit gérer des milliers de souscriptions, ce coût devient prohibitif. Les alternatives sérieuses - Polygon, Avalanche, Tezos, Stellar - ont chacune leurs trade-offs en termes de gouvernance, d'écosystème régulatoire, de standards de tokens supportés, et de stabilité des coûts. Chez Fraktion, nous avons retenu Tezos pour des raisons d'alignement avec les exigences des opérateurs régulés : coût de transaction stable et prédictible (de l'ordre du centime par opération), gouvernance on-chain ouverte et formellement vérifiable, écosystème européen actif. Faire ce choix correctement demande d'évaluer une dizaine de critères techniques et de comprendre la trajectoire de chaque écosystème un travail de plusieurs semaines pour une équipe qui découvre le sujet.

Le moteur de smart contracts. Les standards de security token existent : ERC-1400 sur Ethereum, FA2 sur Tezos. Mais implémenter un smart contract conforme à ces standards, c'est une chose. L'auditer pour qu'il soit déployable en production avec de l'argent réel, c'en est une autre. Un audit de smart contract sérieux par un cabinet reconnu coûte entre 30 000 € et 80 000 € par contrat, demande deux à trois mois, et doit être refait à chaque évolution majeure. Sur un projet qui en compte typiquement cinq ou six (token principal, contrôles d'accès, transferts restrictifs, dividendes, vote, registre de cap table), c'est rapidement un budget à six chiffres pour la seule sécurité du code sans compter le coût de développement.

Le KYC industriel. L'erreur classique consiste à penser qu'on peut intégrer un provider externe (Sumsub, Onfido, Veriff sont les références du marché) et que c'est fait. C'est faux. Le KYC, dans le contexte d'une émission tokenisée, doit gérer plusieurs typologies d'investisseurs (particulier, professionnel, qualifié) avec des règles différentes, plusieurs juridictions, des contrôles d'adéquation aux produits, et surtout une piste d'audit complète qui résiste à une revue d'un commissaire aux comptes ou d'un régulateur. Le provider externe gère une partie du flux : la vérification d'identité. Tout le reste, c'est du code et de la donnée à structurer en interne. Construire cette couche proprement, c'est six à neuf mois de développement et une compétence compliance/produit qu'on trouve rarement dans une équipe immobilière.

4. Les briques où le build crée de la dette technique

Quatre autres briques sont moins exotiques sur le plan tech, mais créent une dette qui se paye sur le long terme typiquement six à douze mois après la première opération en production.

La gestion du véhicule juridique. Le SPV ou le fonds est créé en dehors de la plateforme, par un avocat ou un notaire. Mais son cycle de vie, augmentations de capital, sorties d'investisseurs, distributions, modifications statutaires doit être tracé et relié aux mouvements on-chain. C'est un travail de cohérence permanente entre le registre légal et le registre tokenisé. Si la plateforme ne gère pas ce lien proprement, l'opérateur se retrouve avec un risque de divergence entre la réalité juridique et la réalité on-chain qui se découvre en général au pire moment pendant un audit.

L'onboarding investisseur. L'UX de souscription est un sujet apparemment cosmétique qui détermine en pratique le taux de conversion. Sur une opération de levée à plusieurs millions d'euros, un parcours mal conçu coûte facilement 30 à 50 % de signatures perdues à mi-chemin. Construire un parcours fluide qui intègre KYC, signature électronique, paiement, et qui fonctionne correctement sur mobile autant que sur desktop, c'est un vrai métier, pas seulement du dev frontend. Et c'est itératif : la version 1 est rarement la bonne, les vraies optimisations viennent après les premières centaines de souscriptions réelles.

La distribution multi-canal. Un opérateur qui distribue uniquement en direct est rare. La plupart passent par des CGP, des family offices, des plateformes partenaires. Chaque canal a ses spécificités : un CGP veut un espace dédié pour suivre les souscriptions de ses clients et son commissionnement ; un family office veut un parcours plus institutionnel avec une attention particulière au mandat ; une plateforme partenaire veut une intégration API. Servir tous ces canaux demande de penser l'architecture de la plateforme de manière modulaire dès le départ ce qui multiplie le coût initial mais évite une réécriture quand on ajoute le deuxième canal.

Le lifecycle du token. Une fois émis, le token vit. Dividendes à distribuer, votes à organiser, corporate actions à enregistrer (split, regroupement, augmentation), marché secondaire éventuel à animer. Cette couche est rarement priorisée au moment du build, on pense d'abord à l'émission, qui est la phase visible. Et c'est précisément ce qui crée la dette technique : douze à dix-huit mois après la première opération, l'équipe découvre qu'elle doit redévelopper la moitié de la plateforme pour gérer ce qui aurait dû être pensé dès l'architecture initiale.

5. Le règlement, la brique qui change tout

La huitième brique mérite un traitement à part. Le règlement, c'est-à-dire l'acheminement des flux financiers en parallèle des mouvements de tokens a longtemps été le point faible de toute la chaîne.

Le scénario idéal, c'est l'atomic settlement : un investisseur envoie de l'argent, reçoit ses tokens, et tout se déroule en une seule transaction garantie sur le registre. C'est techniquement possible avec une forme de cash numérique acceptable institutionnellement, stablecoin réglementé, dépôt bancaire tokenisé, ou monnaie de banque centrale numérique de gros. Plusieurs initiatives ouvrent la voie. En Europe, le programme Pontes Pilot de la Banque de France et d'Euroclear teste depuis 2025 le règlement de transactions tokenisées en monnaie de banque centrale numérique de gros, avec un lancement opérationnel prévu en 2026. Aux États-Unis, la plateforme Kinexys de J.P. Morgan permet déjà des opérations de prêts garantis et d'échanges d'actifs avec règlement quasi instantané. Et en France, LISE, la première DLT TSS française autorisée par l'AMF en octobre 2025 opère son propre règlement-livraison sur monnaie de banque commerciale tokenisée, par dérogation au règlement CSDR dans le cadre du Régime pilote.

Tant qu'un instrument de cash numérique n'est pas opérationnel à l'échelle pour l'ensemble des opérateurs, le règlement reste articulé entre virements SEPA classiques (avec leur délai de validation interbancaire) et émission de tokens (immédiate sur la chaîne). Ce décalage technique impose à la plateforme de gérer la réconciliation, le verrouillage temporaire des tokens en attente de validation du virement, la levée du verrouillage à réception, et la gestion des cas limites virement non reçu, refus de la banque, rejet KYC après émission. Autant de scénarios qu'un projet en build interne découvre rarement avant la première opération réelle.

Le règlement est le maillon où, historiquement, beaucoup de projets de tokenisation se sont arrêtés. Gweltaz Le Coz, Fraktion

6. Le coût réel du build interne

En cumulant les huit briques, voici l'ordre de grandeur honnête pour un build interne sérieux destiné à une mise en production :

• Une équipe minimale de cinq à sept personnes pendant douze à dix-huit mois : trois ingénieurs avec une vraie compétence blockchain (profils rares, salaire chargé autour de 110 à 140 k€ par an sur le marché européen), un product manager, un architecte technique, un responsable conformité, et idéalement un designer UX dédié.
• Un investissement initial entre 400 k€ et 1 M€ pour atteindre le MVP, en fonction du périmètre et de la qualité visée.
• Un coût récurrent entre 200 k€ et 400 k€ par an pour la maintenance, les audits réguliers de smart contracts, l'évolution des intégrations, et la veille réglementaire.
• Un coût d'opportunité difficile à quantifier mais réel : l'équipe technique mobilisée sur le sujet ne travaille pas sur ce qui fait la valeur ajoutée d'opérateur immobilier, la sélection d'actifs, la gestion de portefeuille, la relation investisseurs.

Ces chiffres ne sont pas marketing. Ils correspondent à ce qu'on observe quand on parle avec les équipes qui ont tenté le build et fait demi-tour. La majorité des projets de build internes engagés depuis 2020 dans l'écosystème immobilier européen ont soit été arrêtés, soit recadrés sur un périmètre beaucoup plus étroit que ce qui était prévu en lancement.

7. Quand le build se justifie quand même

Le build interne reste pertinent dans quelques cas précis, et il serait malhonnête de ne pas les nommer.

Le build se défend si vous prévoyez un volume très élevé d'opérations (typiquement plus d'une émission tokenisée par mois sur la durée), ce qui amortit le coût fixe d'infrastructure. Il se défend également si vous avez besoin d'une personnalisation produit que les infrastructures standardisées ne peuvent pas couvrir, c'est rare mais ça existe sur des produits structurés très spécifiques. Il se défend si vous avez déjà en interne une équipe ingénieur blockchain solide (compétence rare dans le secteur immobilier classique). Et il se défend si vous acceptez un retard de mise sur le marché de douze à dix-huit mois ce qui suppose que le timing n'est pas un facteur compétitif sur votre marché.

En dehors de ces cas, intégrer une infrastructure existante est presque toujours la meilleure décision, non pas parce qu'on vend cette infrastructure chez Fraktion, mais parce que la complexité accumulée des huit briques dépasse rarement le retour sur investissement pour un opérateur dont la valeur principale est ailleurs que dans le code.

8. Notre approche chez Fraktion

Chez Fraktion, nous avons construit les huit briques de manière intégrée : blockchain Tezos pour le socle, smart contracts au standard FA2, KYC industrialisé connecté à plusieurs providers du marché, gestion native du véhicule juridique en lien avec le conseil juridique du client, onboarding mobile-first conçu pour les opérations de plusieurs millions, distribution CGP native, lifecycle complet (corporate actions, dividendes, reporting), et règlement compatible SEPA aujourd'hui, prêt à intégrer un stablecoin euro institutionnel quand il sera opérationnel à l'échelle.

Notre objectif n'est pas de remplacer votre cabinet juridique ni votre stratégie d'investissement, c'est de vous éviter de reconstruire ce qui est une infrastructure mutualisable, et de vous faire gagner les douze à dix-huit mois qu'aurait coûté un build interne.

Si vous êtes en cours d'arbitrage entre construire en interne et intégrer une infrastructure, nous sommes disponibles pour partager notre retour d'expérience sur les briques où le build se révèle particulièrement coûteux et celles où, dans certains cas, il peut garder un sens.

Sources et lectures complémentaires

• AMF, Rapport annuel 2025, Autorité des marchés financiers (publié mai 2026) — chapitre sur le Régime pilote, la première autorisation française LISE, et les conclusions du groupe de travail AMF-ACPR sur la certification des smart contracts.
• France FinTech & Sopra Steria, Tokenisation en Europe : Le Nouvel Ordre du Post-Marché (livre blanc, mai 2026) — analyse complète de la chaîne de valeur post-marché et des trajectoires d'industrialisation.
• ESMA, Authorised DLT Market Infrastructures — registre officiel des plateformes DLT TSS, DLT MTF et DLT SS autorisées en Europe.
• Commission européenne, Market Integration Package, 4 décembre 2025 — proposition d'élargissement du Régime pilote DLT.

Lire aussi

• Tokenisation des actifs réels en France : pourquoi 2026 marque la bascule pour les opérateurs
• Tokeniser un actif immobilier : les 6 étapes opérationnelles d'un projet
• Le non coté a besoin d'infrastructures et les CGP en pâtissent en premier
• Réseaux de CGP : pourquoi la consolidation ne résout pas le problème d'infrastructure
• Fraktion — logiciel de gestion club deal et levée de fonds
• Notre solution pour les sociétés de gestion et SCPI
• Glossaire : Security Token
• Glossaire : Smart Contract
• Glossaire : SPV (Special Purpose Vehicle)