BC Expertise · mandat de 3 mois et plus
Blockchain Engineering & Architecture
Systèmes blockchain où l’état partagé, la programmabilité ou la vérification tierce justifient la complexité.
De l’architecture aux smart contracts et produits on-chain, avec une spécialisation en systèmes vérifiables, identité, gouvernance des clés et ZK/ZKML.
Cinq fois plus d’actifs tokenisés sur blockchains publiques en un an : assez tôt pour que l’architecture se décide encore, plutôt qu’elle se rattrape.1 Voir les preuves
Le moment où ça devient un sujet
Vous reconnaissez l’un de ces moments, ou ce n’est pas encore le sujet.
Ce sont des situations datables, pas des symptômes généraux. Si aucune ne vous parle, cette page peut se refermer ici.
-
Plusieurs organisations doivent partager un état ou exécuter les mêmes règles sans dépendre d’un opérateur unique.2
-
Un produit doit intégrer des smart contracts, un wallet ou des flux on-chain sans figer trop tôt les choix d’architecture.
-
Un contrat est prêt à être déployé et les permissions, upgrades, clés ou procédures de reprise ne sont pas encore gouvernés.
-
Un tiers doit vérifier une affirmation ou un état sans obtenir un accès complet aux données ou aux systèmes internes.
Aucune de ces situations n’est urgente en soi. Chacune le devient à une date connue d’avance.
Ce que ça coûte si rien ne change
Trois blocages, et le contournement qui ne les réduit pas.
Chaque blocage reçoit une réponse plus bas — dans les offres, le déroulé ou les engagements. Aucun n’est laissé ouvert.
La frontière du système n’est pas écrite
État partagé, données privées, règles exécutables et preuves finissent dans le même mécanisme. Le coût et le risque augmentent parce que personne n’a séparé ce qui doit être stocké, exécuté, attesté ou vérifié.
Le contournement habituel, et sa limite
Le contournement habituel est d’empiler base de données, exports signés et composants on-chain. Vérifier qu’un enregistrement figure dans un journal append-only coûte 0,000035 s : le calcul n’est pas le problème. Le problème est l’absence d’une frontière explicite entre source, état, exécution et preuve.3
La blockchain est choisie avant le problème
Une DLT n’est pas automatiquement une meilleure base de données : à charge cible égale, la voie base de données a délivré environ 4,22× plus de débit brut. L’overhead d’un registre programmable ne se défend donc pas par la performance, mais par le travail qu’il fait disparaître entre organisations — messaging, réconciliation, interventions manuelles.45
Le contournement habituel, et sa limite
Ajouter une preuve cryptographique à une donnée que personne ne conteste ne crée aucune valeur : elle déplace le coût sans lever de doute.
La gouvernance des contrats et des clés n’est pas écrite
Qui peut appeler, mettre à niveau, signer, révoquer ou récupérer : ces réponses arrivent souvent après le déploiement, lorsque les changer exige une migration. Et « récupérer » peut signifier reconstruire une clé, la réémettre, migrer l’autorité ou transférer les actifs.6
Le contournement habituel, et sa limite
Le multisig règle un seuil de signatures, pas à lui seul l’autorité, l’upgrade ou la reprise. Sur les transactions d’autorisation observées, plus de 63 % étaient associées à des attaques : permissions, révocation et procédures de reprise doivent être écrites avant le déploiement.7
Pour qui, et sous quelle pression
Le décideur qui achète ce mandat, et ce qui pèse sur lui.
Responsable innovation / architecte blockchain
Élodie Marchand
Aujourd’hui
Le besoin est réel, mais architecture, smart contracts, données off-chain, wallets, gouvernance et niveau de vérifiabilité restent entremêlés.
Après le mandat
Une architecture bornée, des composants livrables et des critères d’acceptation explicites — avec vérification indépendante uniquement là où elle apporte une propriété utile.
Un avatar de décision sert à clarifier le problème et le résultat attendu. Il reste à valider avec vos entretiens et les comportements que vous observez. Les avatars, en entier
Avant de réserver quoi que ce soit
Quatre conditions d’entrée, quatre motifs de refus.
Elles sont écrites ici plutôt que découvertes au devis. La colonne de droite a le même poids que celle de gauche.
C’est le bon mandat si
- Une décision réelle est en jeu : une promotion en production, un audit, un renouvellement, un lancement ou un remplacement de système.
- Un sponsor nommé peut arbitrer le périmètre et signer la recette.
- L’accès aux systèmes, aux données ou aux documents nécessaires est possible sous NDA dans les trois premières semaines.
- Le système doit fournir une propriété vérifiable par un tiers sans lui exposer l’ensemble des données ou des systèmes.
Ce n’est pas le bon mandat si
- Vous cherchez un panorama de tendances ou une veille : le format court de la clinique de décision coûte moins cher et répond mieux.
- Le résultat attendu dépend d’une signature réglementaire que seul un rôle statutaire de votre organisation peut porter.
- Aucun accès aux preuves n’est possible : sans données, sans journaux et sans documents, il n’y a rien à rendre défendable.
- Le besoin est seulement un registre interne ou une automatisation centralisée : une base de données auditée ou un service classique coûtera moins cher et se maintiendra mieux.
Un « non » dit à cette étape coûte vingt minutes. Dit après le devis, il coûte un trimestre à tout le monde.
L’état d’arrivée
Ce que le mandat déplace.
un besoin blockchain décrit par des technologies
une architecture bornée, livrable et testable
Chaque composant a une fonction explicite : stocker, partager un état, exécuter une règle, gouverner une autorité ou permettre une vérification indépendante. La technologie suit cette fonction ; elle ne la précède pas.9
Axe par axe, avant et après
Trois axes, et ce qui change sur chacun.
Un axe par ligne, comparé des deux côtés. Une colonne de frustrations face à une colonne de fonctionnalités ne serait pas une comparaison.
Architecture
Aujourd’hui
La chaîne, les contrats ou le wallet sont choisis avant la frontière du système
Après
Chaque composant on-chain répond à un besoin explicite et documenté
Exécution
Aujourd’hui
Contrats et intégrations fonctionnent, mais leurs invariants et modes d’échec restent implicites
Après
Contrats, tests et critères d’acceptation décrivent ce que le système doit garantir
Gouvernance et vérification
Aujourd’hui
Permissions, clés et preuves reposent sur des pratiques implicites
Après
Autorité, reprise et vérification sont écrites et testables lorsqu’elles sont requises
Ce qui est visé, et de quel type
Deux critères de recette, un exemple déjà construit, aucun résultat observé.
Chaque ligne indique son statut : critère de recette, estimation modélisée, ou exemple déjà construit.
-
Visé — critère de recette
L’acceptation repose sur une architecture documentée et des critères testables, pas sur la confiance dans un outil ou un fournisseur unique.10
Critère de recette : frontières, invariants et flux critiques peuvent être revus ou reproduits indépendamment.
-
Visé — critère de recette
Permissions, upgrades et gouvernance des clés sont écrits et testés avant déploiement11
Perte, révocation, départ et changement d’autorité sont rejoués avant la mise en production.
-
Exemple — déjà construit
dApp de loterie et backend de vote tokenisé, audités par provenance
Dépôts publics, contribution attestée commit par commit : 26 commits sur 29 sur le premier.
Aucun de ces résultats n’est présenté comme mesuré chez un client : les métriques de production sont sous NDA sur chaque mandat. Reste la question qui suit — sur quoi ces engagements reposent-ils ?
Ce sur quoi ça repose, et ce que ça ne prouve pas
Des preuves proportionnées à la promesse.
Lottery dApp, backend de vote tokenisé, Folder Mapper en Rust et piste Encode Club : preuves publiques distinctes pour exécution on-chain, intégration, tooling et systèmes vérifiables.
Projet public
Lottery dApp (Solidity · EVM · TypeScript)
ERC-20, rounds temporisés, sélection du gagnant. 26 commits sur 29 attribués. • Capability demonstrated : Smart-contract engineering — logique on-chain, invariants et tests de contrat.
Examiner la preuveProjet public
Tokenized Voting Backend (NestJS · ethers · Sepolia)
Supply, balances, mint, délégation, voting power et vote sur Sepolia. 4 commits, tous attribués. • Capability demonstrated : On-chain product integration — backend reliant logique applicative et état blockchain.
Examiner la preuveCertificats
Encode Club — Solidity expert · ZK · ZKML · Solana
Bootcamps avancés en smart contracts, preuves à divulgation nulle, ZKML (EZKL, GKR) et développement Solana. • Capability demonstrated : Verifiable systems — connaissance des mécanismes de preuve et protocoles de vérification.
Distinction
EthCC Hacker House — Best Implementation, Threshold Network
Meilleure implémentation sur la piste Threshold Network (intitulé officiel à confirmer avant publication). • Capability demonstrated : Protocol implementation — intégration reconnue sur la piste Threshold Network.
Manquant
Cas d'usage client sous NDA
Les déploiements on-chain de clients réglementés sont décrits au niveau architecture sous NDA. Aucune référence client ou métrique de production n'est publiable tant que le mandat n'est pas clos.
Sources & méthodes 16 placements · 11 unités de preuve
Chaque marqueur numéroté renvoie à une observation bornée : ce qui a été mesuré, sur quelle population, sur quelle période, et ce que le chiffre n’établit pas. Une affirmation qui ne peut pas être adossée à une de ces unités perd son marqueur — elle n’est pas rattachée à une source plus vague.
-
La BCE observe 4,7 Md€ d’actifs traditionnels tokenisés sur blockchains publiques au T1 2025, et 23,3 Md€ au T1 2026 — tout en décrivant ce marché comme encore petit face aux marchés mondiaux.
Actifs traditionnels tokenisés enregistrés sur blockchains publiques, périmètre de la source BCE. T1 2025 et T1 2026
Ce que ce chiffre n’établit pas Deux points de valeur de marché observés. Aucune causalité, aucune prévision, et aucune conclusion sur la qualité d’une architecture : c’est un contexte de calendrier, pas un argument de conception.
From vision to delivery: building Europe’s tokenised financial market · European Central Bank, 2026
-
Une preuve zero-knowledge validait un programme de 2 000 lignes en 1,4 ms de vérification, sans révéler le programme.
Prototype de recherche, programme de 2 000 lignes. 2021
Ce que ce chiffre n’établit pas Prototype de recherche : la vérification tient en 1,4 ms, mais la génération de la preuve a demandé environ 1 738 s. Le coût est déplacé vers le prouveur, il n’est pas supprimé.
Zero-knowledge proofs for program correctness · ACM CCS 2021
-
Une vérification d’inclusion sur des journaux append-only a été mesurée à 0,000035 s par enregistrement.
Jeux de 10³ à 10⁵ logs, 50 répétitions, une architecture de journal. 2026
Ce que ce chiffre n’établit pas Une seule architecture de journal. La mesure porte sur le coût de vérification, pas sur la solidité du schéma d’engagement ni sur la disponibilité du journal.
Saengthong et al., append-only log verification · IEEE Open Journal of the Computer Society, 2026
-
Sous une charge cible de 1 000 TPS, la voie base de données a délivré 924,79 TPS contre 219,23 TPS pour l’endpoint adossé à un ledger — environ 4,22× plus de débit brut.
Un prototype SSO/TOTP à deux organisations, même charge cible sur les deux voies. 2026
Ce que ce chiffre n’établit pas Un seul prototype. Ce n’est pas un ratio universel base de données contre DLT, et cela ne classe aucune architecture : cela borne la question à « quelle coordination justifie cet overhead ? ».
Yangeç, database-backed versus ledger-backed throughput · Wiley / CCPE, 2026
-
La BCE décrit, sur une plateforme de repo programmable, une substitution de collatéral, une gestion d’appels de marge et un retour de collatéral largement automatisables par smart contracts — réduisant messaging, réconciliation et interventions manuelles entre institutions.
Processus du cycle de vie repo, entre plusieurs institutions et infrastructures financières. Discours BCE du 28 août 2026
Ce que ce chiffre n’établit pas Preuve de mécanisme uniquement. Aucun effet chiffré n’est établi sur les coûts, les effectifs ou la vitesse de règlement : cela explique pourquoi la coordination peut justifier l’overhead, pas de combien.
-
Une synthèse de 77 systèmes retenus parmi 118 travaux sépare la reprise en quatre opérations distinctes : reconstruire une clé, la réémettre, migrer l’autorité, transférer les actifs.
77 systèmes retenus sur 118 travaux découverts. 2026
Ce que ce chiffre n’établit pas Une taxonomie de mécanismes de reprise, pas une mesure de fréquence de perte de clé ni une recommandation d’un mécanisme sur un autre.
-
Plus de 63 % des transactions d’autorisation EIP-7702 observées étaient associées à des attaques ciblant des comptes EOA.
Transactions d’autorisation EIP-7702 observées sur sept blockchains. 2026
Ce que ce chiffre n’établit pas Jeu de données EIP-7702 uniquement. Ce chiffre ne dit rien d’un taux de compromission des multisigs, et ne mesure pas la qualité d’une gouvernance de clés écrite.
Huang et al., EIP-7702 authorization attacks · USENIX Security 2026
-
La vérification d’une preuve à divulgation sélective s’exécute en moins de 95 ms dans l’architecture de credentials mesurée.
Benchmark de credentials préservant la confidentialité, jusqu’à 33 attributs. 2024
Ce que ce chiffre n’établit pas Un benchmark de credentials borné à 33 attributs. La latence de vérification ne dit rien du coût de génération ni du choix on-chain / off-chain, qui reste à décider par le besoin de vérification.
-
Trois détecteurs complémentaires couvraient jusqu’à 76,78 % des vulnérabilités annotées ; aucun outil seul ne couvrait toutes les classes.
2 182 instances annotées manuellement, outillage Solidity. 2026
Ce que ce chiffre n’établit pas Borné au jeu de données et aux versions d’outils évaluées. Une couverture de 76,78 % n’est pas une garantie d’exhaustivité d’audit : elle motive une chaîne de vérification documentée plutôt que la confiance dans un outil.
Salzano et al., complementary smart-contract detectors · Empirical Software Engineering, 2026
-
Un dictionnaire transparent configuré pour 1 milliard d’entrées se vérifie en environ 35 ms sur un ordinateur portable grand public, avec des preuves de moins de 8 kB.
Construction à engagement polynomial, dictionnaire transparent d’un milliard d’entrées. 2026
Ce que ce chiffre n’établit pas Une construction et un benchmark spécifiques. Ce n’est pas une garantie de performance pour un registre quelconque, et cela ne dit rien du coût de production des preuves ni de la disponibilité du service qui les sert.
IRONDICT, transparent dictionaries at scale · USENIX Security 2026
-
222 études de haute qualité ont permis de cataloguer 192 vulnérabilités en 13 catégories, 219 outils et 133 benchmarks.
Revue systématique de la littérature sur la sécurité des smart contracts. 2026
Ce que ce chiffre n’établit pas L’étendue d’une taxonomie n’est pas le risque d’un contrat donné. Cela borne ce qu’un engagement cryptographique prouve — une propriété — sans remplacer l’analyse de surface d’attaque ni l’audit.
Iuliano and Di Nucci, smart-contract security taxonomy · Journal of Systems and Software, 2026
Chaque élément indique sa nature et son niveau de provenance. Les limites sont affichées au même titre que les réalisations. Le registre complet des projets et de leur provenance
Évaluer la missionCe qui est dedans, ce qui n’y est pas
Le périmètre, ses exclusions et ses dépendances.
Dans le périmètre
- Qualification du besoin blockchain, frontière on-chain/off-chain et choix du mécanisme, y compris le refus motivé.
- Architecture et implémentation de smart contracts, composants d’intégration, identité, permissions et gouvernance multisignature selon le périmètre.
- Attestations, divulgation sélective ou outil de vérification exécutable par un tiers lorsque le cas l’exige.
Hors périmètre, explicitement
- Audit de sécurité formel de smart contract par un tiers agréé.
- Conception de tokenomics ou d’un modèle économique.
- Qualification réglementaire d’un actif : c’est un avis juridique, pas technique.
Ce qui dépend de vous
- Un sponsor joignable qui tranche un arbitrage de périmètre en moins d’une semaine.
- L’accès aux systèmes, journaux ou documents concernés, sous NDA.
- Une ou deux personnes de votre équipe disponibles pour la phase de passation — sans elles, le mandat produit une dépendance au lieu d’une capacité.
Format 3–12 mois · architecture, R&D appliquée et delivery
Le déroulé, et où l’on peut s’arrêter
Quatre phases, quatre sorties possibles.
Chaque phase se termine par un artefact et une décision. Vous pouvez vous arrêter à la fin de n’importe laquelle avec quelque chose entre les mains.
-
Qualification & architecture
Le besoin, les acteurs, les frontières de confiance et la raison d’utiliser — ou non — une blockchain.
Sortie de phase Note d’opportunité et décision d’architecture.
-
Conception
État on-chain/off-chain, interfaces, permissions, invariants, clés et mécanismes de vérification nécessaires.
Sortie de phase Architecture cible et spécification des composants.
-
Implémentation
Contrats, tests, scripts et composants d’intégration nécessaires au flux retenu.
Sortie de phase Composants testés et package de recette.
-
Passation
Les flux critiques, permissions, procédures de clés et vérifications spécialisées sont rejoués avant transfert.
Sortie de phase Procédure d’exploitation, recette et handover.
Les blocs de travail
Quatre blocs, activables séparément et dans n’importe quel ordre.
Engagement
Frontière on-chain/off-chain, état partagé, dépendances, trust boundaries et choix du mécanisme minimal.
Smart contracts & intégration
Contrats, tests, backend, scripts et flux wallet nécessaires au comportement on-chain retenu.12
Identité, permissions & clés
Rôles, signataires, seuils, upgrades, révocation, perte, départ et account abstraction.13
Systèmes vérifiables
Attestations, engagements, divulgation sélective, vérification tierce et recherche ZK/ZKML lorsque le besoin l’exige.14
Un bloc que vous tenez déjà sort du périmètre et du devis. C’est la première chose qu’on regarde à l’appel de qualification.
Ce qui est garanti, et ce qui ne peut pas l’être
Ce qui est garanti est le produit de travail, jamais le résultat d’une autorité.
Périmètre écrit avant facturation
Le périmètre, les exclusions, les dépendances et les critères de recette sont écrits et acceptés avant le premier jour facturé. Un changement de périmètre est un avenant, pas une surprise en fin de mission.
Livrables complets ou repris
Un livrable qui ne satisfait pas ses critères de recette est repris jusqu’à ce qu’il les satisfasse, sans facturation supplémentaire. Les critères sont écrits avant de produire, pas après.
Réversibilité à la sortie
Code, données, schémas, décisions et journaux vous appartiennent et partent avec vous. Aucun composant propriétaire, aucune licence, aucun hébergement dont dépendrait la suite du travail.
Frontière de confidentialité
Tout livrable ou exercice qui manipule vos données porte une classification et une règle explicite : autorisé, anonymisé, synthétique ou interdit. La règle est écrite avant la manipulation, pas constatée après.
Frontière de décision humaine
Chaque cas traité indique où l’assistance automatique s’arrête et où une validation humaine est obligatoire. Un système qui décide sans que la limite soit écrite n’est pas livré.
Noyau neutre vis-à-vis des outils
Objectifs, critères de recette et preuves sont écrits indépendamment d’un fournisseur ou d’un modèle donné. Un changement d’outil est un avenant, jamais une reprise à zéro de l’investissement.
Ce qui n’est pas garanti, et ne peut pas l’être honnêtement
- L’implémentation et les tests ne remplacent pas un audit de sécurité indépendant. Smart contracts, intégrations, permissions et mécanismes cryptographiques sont livrés pour être auditables ; la revue tierce reste séparée de l’auteur du code.15
- Aucune transaction n’est diffusée depuis mon poste ni depuis un système de build.
Les conditions contractuelles complètes — acompte, préavis, propriété intellectuelle, confidentialité — sont publiées et ne sont pas reformulées ici. Lire les conditions
Ce qui reste à lever
Quatre questions, avec la réponse et sa raison.
Les questions qui changent le périmètre, le prix ou la responsabilité sont déjà répondues plus haut. Ici, le reste.
Intervenez-vous seulement sur des projets centrés sur la vérifiabilité ?
Non. L’offre couvre architecture blockchain, smart contracts, composants on-chain, intégrations wallet, identité et gouvernance. La vérifiabilité — attestations, divulgation sélective ou ZK — est une spécialisation activée seulement lorsque le cas l’exige.
Faut-il utiliser du zero-knowledge pour rendre un système vérifiable ?
Non. Selon la propriété recherchée, un journal append-only, une signature, un engagement, une attestation ou une preuve d’appartenance peut suffire. ZK/ZKML reste un mécanisme spécialisé, annoncé comme tel.16
Et si l’architecture conclut qu’il ne faut pas de blockchain ?
C’est un résultat acceptable et documenté. La note d’opportunité motive le refus et propose l’alternative technique la plus simple compatible avec le besoin.
Qui audite les contrats livrés ?
Un tiers agréé, et le budget doit le prévoir. Les contrats sont livrés testés et documentés pour être auditables ; l’audit lui-même n’est jamais fait par celui qui a écrit le code.
La prochaine étape, en entier
Évaluer la mission en 20 minutes
Le premier échange sert à décider s’il y a un mandat, pas à le vendre. S’il n’y en a pas, vous repartez avec la raison.
- 20 minutes, en visio ou au téléphone.
- Vous, le sponsor si ce n’est pas vous, et moi. Pas de commercial : il n’y en a pas.
- On y regarde le contexte, la décision en jeu, le niveau de risque et les preuves accessibles.
- Vous repartez avec un avis fit / no-fit motivé et, si c’est fit, le périmètre et la fourchette de la première étape.
Le bon format d’intervention, avant le premier rendez-vous.
Décrivez la décision à prendre — pas votre budget. Vous repartez avec le format d’intervention adapté et les ressources qui y mènent.
Cette expertise appliquée à votre cas : quatre écrans, une lecture gratuite, et l’offre qu’elle désigne.
Preuve