Architecture et infrastructures blockchain : le bon réseau, les bonnes données sur la chaîne, et un système qui fonctionne de bout en bout.
Un projet blockchain ne se résume pas à un smart contract.
L'architecture relie vos utilisateurs, vos applications, vos services métier, vos données et le réseau. Choix du réseau, données sur la chaîne et hors chaîne, transactions, liens avec vos logiciels : nous concevons l'ensemble, puis le mettons en œuvre selon le périmètre convenu.
Suivre une opération · Plan complet
Le plan complet d'une opération. Choisissez une étape ou lancez la lecture pour la suivre.
Plan d'architecture · registre partagé entre partenaires · scénario fictif
AUtilisateur
- Collaboratrice d'un partenairevalide un document
- Portefeuille de signaturesi elle signe elle-même ; sinon, un compte de service
BApplication et services · hors chaîne
- Interface webaffiche l'état de l'opération
- Service métierdroits, règles, préparation de la transaction
- Stockage des documentsle document reste hors chaîne
- Base applicativemise à jour d'après les événements confirmés
- Logiciels existantsERP, gestion documentaire : échanges par API
CAccès au réseau
- Service d'accès au réseaunœud dédié ou service externe, selon l'architecture
- Indexation des événementsrelaie ce que le réseau a confirmé
- Exploitationenvironnements, supervision, erreurs : selon le périmètre convenu
DRegistre et confirmations · sur la chaîne
- Smart contract du registreinscrit l'empreinte et le statut
- Blocs et confirmationsdélais et frais variables selon le réseau
Cycle d'une transaction · étapes 3 à 6
- Préparée
- Signée
- Soumise
- En attente
- Confirmée, puis : État de l'application synchronisé
- Échouée, puis : Aucune mise à jour : nouvelle tentative ou alerte
Ou échec : transaction rejetée ou expirée. Aucune mise à jour ; nouvelle tentative ou alerte, prévues à la conception.
- Étape 1 : La collaboratrice valide un document dans l'interface.
- Étape 2 : Le service métier vérifie ses droits et prépare la transaction : l'empreinte du document, pas le document.
- Étape 3 : La transaction est signée, par son portefeuille ou par un compte de service, selon l'architecture retenue.
- Étape 4 : Elle est soumise au réseau par le service d'accès : elle est alors en attente.
- Étape 5 : Le smart contract l'inscrit ; elle est confirmée après un délai variable, ou elle échoue.
- Étape 6 : Seul un événement confirmé, relayé par l'indexation, met à jour la base puis l'interface.
Un réseau existant, un réseau restreint ou une infrastructure dédiée : choisir selon le besoin.
Une architecture blockchain n'implique pas de créer une blockchain. Le plus souvent, le projet s'appuie sur un réseau qui existe déjà.
Un réseau public existant
- Ce qu'il apporte
- Ouverture, vérification possible par des tiers.
- Ce qu'il demande
- Des transactions visibles et payantes, des frais variables.
- Quand il convient
- Des tiers doivent vérifier sans dépendre de vous.
Un réseau à accès restreint
- Ce qu'il apporte
- Des participants connus, une lecture limitée aux membres.
- Ce qu'il demande
- Des nœuds à faire fonctionner, une gouvernance entre partenaires.
- Quand il convient
- Un groupe de partenaires défini, des données à ne pas diffuser.
Une infrastructure dédiée
- Ce qu'il apporte
- La maîtrise des règles et des performances.
- Ce qu'il demande
- Toute l'exploitation, et la confiance des participants à obtenir.
- Quand il convient
- Rarement : des contraintes que les autres options ne couvrent pas.
Parfois, une base de données partagée suffit : si la blockchain n'apporte rien au projet, nous le disons. Pour la question de départ, voyez ce qu'une blockchain apporte, et quand elle n'est pas nécessaire ; pour aller plus loin, créer sa propre blockchain.
Une solution blockchain, ce sont des composants qui travaillent ensemble.
Chaque composant a une responsabilité. Les comprendre ensemble évite qu'un seul, le smart contract, porte tout.
Interface
Ce que voient et utilisent les personnes : parcours, états, messages.
Ce qu'il faut décider : Ses parcours relèvent des applications décentralisées.
Services métier
Règles, droits, préparation des opérations, échanges avec vos outils.
Ce qu'il faut décider : Ce qui reste dans l'application, hors de la chaîne.
Smart contracts
Les règles qui doivent s'exécuter sur la chaîne, à l'identique pour tous.
Ce qu'il faut décider : Leur conception et leur vérification : smart contracts.
Accès au réseau
Soumettre les transactions et lire la chaîne, par un nœud dédié ou un service d'accès externe.
Ce qu'il faut décider : Dépendance à un fournisseur, coûts, disponibilité ; un nœud dédié s'expose comme tout serveur, ce que traite la sécurisation des infrastructures web.
Indexation des événements
Relayer à l'application ce que le réseau a confirmé.
Ce qu'il faut décider : Ce qu'il faut suivre ; les données venues d'autres réseaux ou sources relèvent des oracles et de l'interopérabilité.
Stockage des données
Documents et données hors chaîne, dans un stockage adapté.
Ce qu'il faut décider : Emplacement, accès, sauvegardes.
Exploitation
Environnements, supervision, gestion des erreurs et des évolutions.
Ce qu'il faut décider : Son périmètre, défini au contrat.
Les mêmes composants servent des cas d'usage très différents : la tokenisation d'actifs, la traçabilité dans le luxe, des opérations immobilières ou des protocoles de finance décentralisée.
Qui peut administrer un contrat, faire évoluer une règle ou suspendre une opération se décide dès la conception. Le détail relève de la sécurité et de la gouvernance.
Une décision d'architecture change tout : ce que le registre coûte, expose et permet de corriger.
Scénario fictif : un fabricant publie des attestations de conformité ; ses partenaires vérifient qu'une attestation est authentique et toujours valide. Le besoin est le même ; comparez deux façons de construire le registre.
Données du registre
Réseau
A · Tout sur la chaîne, réseau public · 4 points d'attention, 2 adaptés
A · Tout sur la chaîne, réseau public. 4 points d'attention, 2 adaptés.
Où vit chaque donnée
Hors chaîne · stockage et base de l'application
Aucune donnée du registre : l'application garde seulement ses comptes et ses réglages.
Sur la chaîne · réseau public
- Attestation complètele document PDF
- Émetteur, date, produitinformations descriptives
- Nom du signatairedonnée personnelle
- Statutvalide, remplacée ou révoquée
Le registre conserve tout, document et nom compris, dans un historique partagé.
- Réseau public
- Accès ouvert : toute personne peut lire le registre ; chaque inscription paie des frais au réseau.
- Les règles du réseau ne dépendent ni de vous ni de vos partenaires.
Conséquences pour ce registre
- Lecture, point d'attentionToute personne peut lire le registre, sans limite de durée : le document et le nom du signataire compris.
- Coût, point d'attentionDes frais de réseau à chaque inscription, d'autant plus élevés que les données sont volumineuses, et variables dans le temps.
- Correction, point d'attentionUne nouvelle inscription corrige ; la version erronée reste lisible dans l'historique.
- Effacement, point d'attentionUne donnée inscrite reste dans l'historique de la chaîne : l'effacer n'est en général pas possible. Les données personnelles demandent une analyse avant toute inscription.
- Vérification, adaptéLe partenaire lit l'attestation et son statut sur la chaîne. L'inscription montre ce qui a été inscrit et quand, pas que c'est exact.
- Exploitation, adaptéL'application et l'accès au réseau.
Ce choix convient quand les données sont peu nombreuses, non personnelles, et doivent rester lisibles sur la chaîne sans dépendre d'un autre stockage.
Ce qu'une inscription ne prouve pas. Une empreinte, calculée selon une méthode connue, aide à vérifier qu'un document est identique à celui enregistré, et depuis quand. Elle ne prouve à elle seule ni son authenticité, ni sa provenance, ni l'exactitude de son contenu, ni sa valeur juridique.
- point d'attention
- à organiser
- adapté
Scénario fictif : aucun réseau ni stockage réel interrogé, aucun token créé. Aucun choix n'est meilleur dans l'absolu : il dépend des données, des participants, des coûts acceptables et de vos obligations.
Ce qui va sur la chaîne, ce qui reste à côté : des données à leur juste place.
Ce qui est inscrit sur une blockchain est durable, partagé et souvent public. On n'y met que ce qui doit l'être.
Souvent sur la chaîne
- Empreintes de documents
- Statuts
- Opérations à rendre vérifiables
- Règles exécutées par les contrats
Souvent hors chaîne
- Documents
- Données personnelles
- Données volumineuses
- Données qui changent souvent
- Une empreinte aide à vérifier qu'un document est identique à celui enregistré. Elle ne prouve ni que son contenu est exact, ni qui l'a rédigé, ni sa valeur juridique.
- Les données hors chaîne ne se synchronisent pas d'elles-mêmes avec la chaîne : l'application suit les événements confirmés, par un traitement prévu à cet effet.
- Les données personnelles, les documents confidentiels et les données de santé restent hors chaîne.
Relier la blockchain à vos logiciels, sans fragiliser ce qui fonctionne.
Une application blockchain dépend presque toujours de services classiques : une interface hébergée, des services, une base, des échanges avec vos logiciels.
Les échanges avec vos outils
ERP, gestion documentaire et outils métier échangent avec la solution par API, dans le sens utile. Le back-office et les écrans de gestion relèvent d'une plateforme métier ; les connexions entre logiciels, des API et intégrations.
Les transactions et leurs confirmations
Préparation, signature lorsque nécessaire (wallets et intégrations Web3), soumission, attente, confirmation ou échec, puis synchronisation de l'état de l'application. Une transaction n'est pas définitive dès son envoi : les délais et les frais varient selon le réseau, et une transaction peut échouer. Nouvelles tentatives, alertes et messages aux utilisateurs se prévoient à la conception.
Les protections de l'application et de ses API relèvent de la cybersécurité.
Dessiner, prototyper, mettre en œuvre, puis faire fonctionner dans la durée.
Chaque étape se termine par une décision écrite, pour que l'architecture reste compréhensible par vos équipes.
Cadrage
Objectif, utilisateurs, données, logiciels, contraintes : le périmètre est écrit avec vous.
Architecture
Réseau, répartition des données et composants, décrits et justifiés.
Prototype
Sur un réseau de test : le trajet complet d'une opération, essayé.
Mise en œuvre
Services, smart contracts, intégrations.
Mise en service
Environnements, accès au réseau, supervision prévue.
Exploitation et évolutions
Si vous le souhaitez, selon un périmètre défini au contrat : hébergement des composants hors chaîne, surveillance des services, incidents relevant de la prestation, évolutions.
L'hébergement, la supervision et la maintenance ne sont pas inclus d'office dans un développement : leur périmètre est écrit au devis. Voir aussi l'hébergement, la maintenance et l'infogérance. Nous n'exploitons pas de réseau blockchain en permanence pour votre compte.
Questions fréquentes sur l'architecture blockchain
Les questions qui reviennent avant de concevoir l'architecture d'un projet.
Faut-il créer sa propre blockchain pour lancer un projet ?
Rarement. La plupart des projets s'appuient sur un réseau existant, public ou à accès restreint, et concentrent l'effort sur les contrats, les services et l'intégration. Créer un réseau, c'est faire fonctionner des nœuds, des règles de consensus et une gouvernance dans la durée : cela ne se justifie que par des contraintes que les réseaux existants ne couvrent pas. Pour la démarche elle-même : créer sa propre blockchain.
Un réseau à accès restreint est-il plus sûr qu'un réseau public ?
Pas en soi. Il limite qui peut lire et écrire, ce qui sert la confidentialité, mais repose sur un petit nombre de participants qui font fonctionner les nœuds et doivent se faire confiance. Un réseau public est ouvert et vérifiable par tous, mais tout y est visible. Dans les deux cas, la sécurité dépend aussi des contrats, des clés et des accès d'administration.
Quelles données faut-il conserver hors chaîne ?
Les documents, les données personnelles, les données volumineuses ou qui changent souvent restent en général hors chaîne, dans un stockage adapté et sauvegardé. Sur la chaîne, on inscrit ce qui doit être vérifiable : une empreinte, un statut, une opération. Une empreinte aide à vérifier qu'un document est identique à celui enregistré, pas que son contenu est exact.
Une application blockchain a-t-elle besoin d'un serveur ?
Presque toujours. L'interface doit être hébergée, et des services préparent les opérations, suivent les événements du réseau, stockent les documents, envoient les notifications et échangent avec vos logiciels. Même une application décentralisée dépend de services classiques : ils se conçoivent, s'hébergent et se surveillent comme le reste du système.
Comment l'application suit-elle une transaction jusqu'à sa confirmation ?
Elle la prépare, la fait signer lorsque c'est nécessaire, la soumet au réseau, puis suit son état : en attente, confirmée ou échouée. Les délais et les frais varient selon le réseau. L'application ne considère l'opération comme acquise qu'après confirmation, met alors à jour ses propres données et prévoit, en cas d'échec, une nouvelle tentative ou un message clair à l'utilisateur.
Quels coûts techniques prévoir après la mise en ligne ?
Selon l'architecture : les frais du réseau à chaque transaction, variables sur un réseau public ; l'accès au réseau, par un service externe ou des nœuds à faire fonctionner ; l'hébergement des services et du stockage ; la supervision et les évolutions. Ces postes s'estiment dès le cadrage, à partir des volumes prévus : aucun montant n'est fixé avant d'avoir décrit le projet.
Dessinons le système avant de le construire.
Avant la première ligne de code, un dossier de cadrage technique répond aux questions qui fixent l'architecture. Nous l'établissons avec vous, planche par planche.
Dossier de cadrage technique
nomenclature des planches
- 01Objectif métierQue doit permettre le système, et pour qui ?à établir
- 02Utilisateurs et rôlesQui consulte, qui inscrit, qui administre ?à établir
- 03Systèmes existantsQuels logiciels doivent échanger avec la solution ?à établir
- 04Données et confidentialitéQu'est-ce qui va sur la chaîne, qu'est-ce qui reste hors chaîne ?à établir
- 05RéseauUn réseau existant suffit-il ? Public ou à accès restreint ?à établir
- 06Transactions et confirmationsQui signe, qui paie les frais, que faire d'une transaction en attente ou échouée ?à établir
- 07Exploitation et maintenanceQui fait fonctionner quoi, et dans quel périmètre ?à établir
- 08ÉvolutionsComment le système changera-t-il sans tout reconstruire ?à établir
Dossier de cadrage · votre projetIndice 0 · à établir ensembleBase de l'architecture retenue
Un premier échange sert à choisir une architecture proportionnée à votre projet.
Parfois un réseau existant suffit ; parfois la blockchain n'apporte rien, et nous vous le disons. Vous repartez avec une première orientation : réseau, répartition des données, composants nécessaires et ce qui relève de l'exploitation.