Développement d'applications décentralisées (dApps) : des applications Web3 où chacun sait ce qu'il signe et ce qui est enregistré.
Une dApp est d'abord une application que l'on utilise.
Parcours, écrans, signatures, attentes et confirmations : nous concevons et développons l'application qui relie vos utilisateurs à vos smart contracts, en leur expliquant chaque étape.
Illustration : l'écran d'une application d'achats fictive. L'acheteur examine les conditions de la commande PX-2041, confirme la réception, signe dans son portefeuille ; la confirmation est envoyée au réseau, attend sa confirmation, puis l'écran affiche la réception confirmée et le paiement libéré. Sous l'écran, les coulisses : vérifier, préparer, demander la signature, soumettre, attendre, réconcilier l'affichage avec l'événement confirmé.
L'application visible, en six étapes
Une dApp, c'est d'abord une application, avec une partie de ses règles sur la blockchain.
Une application décentralisée a des écrans, des comptes, des notifications et un service client, comme toute application web. Ce qui change : certaines actions sont exécutées par un smart contract et enregistrées sur une blockchain, où chacun peut les vérifier.
Ce qui change
- Certaines actions sont enregistrées sur la blockchain et ne s'effacent pas.
- L'utilisateur autorise ces actions par une signature.
- La confirmation prend un délai variable, et peut échouer.
- Chacun peut vérifier ce qui a été enregistré.
Ce qui ne change pas
- L'application a toujours des serveurs : affichage, recherche, notifications, documents.
- La plupart des actions (consulter, filtrer, préparer, échanger) ne passent pas par la blockchain.
- L'expérience, l'accessibilité et le support restent à concevoir.
- Une dApp n'est pas plus sûre par nature : sa sécurité dépend de ses contrats, de ses serveurs et de ses parcours.
Ce qu'une application décentralisée permet de faire, quand chaque partie doit pouvoir vérifier.
Une application décentralisée a du sens quand plusieurs parties doivent agir ensemble et vérifier ce qui a été fait, sans dépendre d'un seul registre.
Engagements entre parties
Une étape validée par l'un déclenche ce que le contrat prévoit pour l'autre : c'est l'exemple de la confirmation de réception, plus haut.
Historique vérifiable
Documents, attestations ou étapes de traçabilité, consultables par les parties autorisées, par exemple dans le luxe ou la santé.
Accès à des droits ou à des actifs
Consulter ses droits, les transférer selon les règles prévues : l'interface de ce que décrit la tokenisation d'actifs.
Participation et votes
Des propositions et des décisions dont le résultat est enregistré, et que chaque participant peut retrouver.
Si une seule organisation garde la main sur toutes les données, une application classique est souvent plus simple : nous vous le dirons.
Une transaction, plusieurs états : l'écran dit ce qui se passe vraiment, à chaque instant.
Choisissez un scénario, puis parcourez ses étapes. D'un côté, ce que voit l'utilisateur ; de l'autre, ce que fait le système. Scénario fictif : la confirmation d'une livraison qui libère un paiement prévu au contrat. Aucun paiement ni aucune transaction réels.
État 1 sur 5Préparation
Ce que voit l'utilisateur
Vérifiez avant de confirmer
Votre confirmation libérera le paiement réservé pour Atelier Delta. Rien n'est encore enregistré : vous pouvez annuler.
- Paiement prévu
- réservé, non libéré
- Historique
- aucune opération
- Confirmer la réception
- Annuler
Ce que fait le système
- Vérification : faitdroits et conditions vérifiés
- Préparation : en courstransaction en préparation
- Signature : pas encorepas encore
- Soumission : pas encorepas encore
- Attente : pas encorepas encore
- Résultat : pas encorepas encore
- Synchronisation : pas encorepas encore
La règle de conception
Avant la signature, rien n'est enregistré : l'utilisateur peut annuler sans conséquence, et sait ce que son action déclenchera.
Les quatre scénarios, état par état :
Succès
- 1. Vérifiez avant de confirmer Votre confirmation libérera le paiement réservé pour Atelier Delta. Rien n'est encore enregistré : vous pouvez annuler. Avant la signature, rien n'est enregistré : l'utilisateur peut annuler sans conséquence, et sait ce que son action déclenchera.
- 2. Signature demandée Votre portefeuille vous demande d'autoriser cette opération. Rien n'est envoyé avant votre signature. La demande de signature décrit l'opération en clair. Elle est une étape du parcours, pas tout le parcours.
- 3. Envoyée au réseau Votre confirmation est envoyée. Elle n'est pas encore confirmée par le réseau. Soumise ne veut pas dire confirmée. Le bouton reste désactivé, pour éviter un second envoi de la même opération.
- 4. En attente de confirmation Le réseau n'a pas encore confirmé. Vous pouvez quitter la page : l'état sera mis à jour. En attente n'est pas un succès : aucun paiement n'est présenté comme libéré tant que le réseau n'a pas confirmé.
- 5. Réception confirmée Le paiement prévu au contrat est libéré pour Atelier Delta. La preuve figure dans votre historique vérifiable. L'écran n'annonce le succès qu'après l'événement confirmé, et une fois l'affichage synchronisé avec lui.
Signature refusée
- 1. Vérifiez avant de confirmer Votre confirmation libérera le paiement réservé pour Atelier Delta. Rien n'est encore enregistré : vous pouvez annuler. Avant la signature, rien n'est enregistré : l'utilisateur peut annuler sans conséquence, et sait ce que son action déclenchera.
- 2. Signature demandée Votre portefeuille vous demande d'autoriser cette opération. Rien n'est envoyé avant votre signature. La demande de signature décrit l'opération en clair. Elle est une étape du parcours, pas tout le parcours.
- 3. Vous n'avez pas signé Rien n'a été envoyé, rien n'a changé. La commande attend toujours votre confirmation. Un refus de signature n'est pas une panne : pas de message d'erreur réseau, pas d'opération en cours. L'utilisateur reprend où il en était.
Attente prolongée
- 1. Vérifiez avant de confirmer Votre confirmation libérera le paiement réservé pour Atelier Delta. Rien n'est encore enregistré : vous pouvez annuler. Avant la signature, rien n'est enregistré : l'utilisateur peut annuler sans conséquence, et sait ce que son action déclenchera.
- 2. Signature demandée Votre portefeuille vous demande d'autoriser cette opération. Rien n'est envoyé avant votre signature. La demande de signature décrit l'opération en clair. Elle est une étape du parcours, pas tout le parcours.
- 3. Envoyée au réseau Votre confirmation est envoyée. Elle n'est pas encore confirmée par le réseau. Soumise ne veut pas dire confirmée. Le bouton reste désactivé, pour éviter un second envoi de la même opération.
- 4. En attente de confirmation Le réseau n'a pas encore confirmé. Vous pouvez quitter la page : l'état sera mis à jour. En attente n'est pas un succès : aucun paiement n'est présenté comme libéré tant que le réseau n'a pas confirmé.
- 5. Confirmation plus longue que d'habitude Le réseau est encombré ; votre opération reste en file. Aucune action n'est nécessaire : vous serez prévenu dès qu'elle sera confirmée. Une attente longue s'explique. Elle ne se résout pas en renvoyant l'opération : renvoyer créerait un doublon.
Échec
- 1. Vérifiez avant de confirmer Votre confirmation libérera le paiement réservé pour Atelier Delta. Rien n'est encore enregistré : vous pouvez annuler. Avant la signature, rien n'est enregistré : l'utilisateur peut annuler sans conséquence, et sait ce que son action déclenchera.
- 2. Signature demandée Votre portefeuille vous demande d'autoriser cette opération. Rien n'est envoyé avant votre signature. La demande de signature décrit l'opération en clair. Elle est une étape du parcours, pas tout le parcours.
- 3. Envoyée au réseau Votre confirmation est envoyée. Elle n'est pas encore confirmée par le réseau. Soumise ne veut pas dire confirmée. Le bouton reste désactivé, pour éviter un second envoi de la même opération.
- 4. En attente de confirmation Le réseau n'a pas encore confirmé. Vous pouvez quitter la page : l'état sera mis à jour. En attente n'est pas un succès : aucun paiement n'est présenté comme libéré tant que le réseau n'a pas confirmé.
- 5. Opération non exécutée Le contrat a refusé l'opération : la date limite de confirmation était dépassée. Aucun paiement n'a été libéré ; des frais de réseau ont pu être prélevés. Un échec n'est jamais présenté comme un succès. « Réessayer » n'apparaît que si la cause est temporaire, comme un réseau indisponible avant l'envoi ; ici, la date est dépassée : on oriente vers le bon interlocuteur.
Ce que vérifie le contrat fictif
Au moment de la confirmation, le contrat revérifie lui-même ces six conditions ; les vérifications de l'application ne font pas foi.
- la commande existe et le paiement est toujours réservé
- le fournisseur a déclaré la livraison
- la confirmation vient de l'acheteur rattaché à la commande
- l'échéance de confirmation n'est pas dépassée
- la commande n'est ni déjà confirmée, ni en litige, ni annulée
- le contrat n'est pas suspendu par son administration
Signatures et confirmations : demander moins, expliquer mieux.
La signature est le moment où l'utilisateur engage sa responsabilité. Nous la réservons aux actions qui le justifient, et nous l'expliquons avant de la demander.
Signer seulement ce qui compte.
Consulter, préparer ou filtrer ne demandent jamais de signature.
Dire ce que l'on signe, avant.
Le récapitulatif de l'application, en langage clair, précède la demande du portefeuille.
Annoncer les frais.
Quand des frais de réseau s'appliquent, l'utilisateur les voit avant de signer.
Refuser sans risque.
Un refus ramène l'utilisateur où il était, sans message d'erreur.
Proposer le portefeuille au bon moment.
Découvrir l'application ou consulter ne demandent pas toujours de portefeuille ; il est proposé quand une action doit être signée.
Le choix des portefeuilles, leur connexion et les autres modalités de signature envisageables relèvent des wallets et intégrations Web3 ; elles s'étudient projet par projet.
Ce que l'application relie, pour qu'elle s'insère dans votre fonctionnement.
Une dApp ne vit pas seule. Elle relie des contrats, des services et vos logiciels.
Les smart contracts
L'application appelle les contrats, affiche leurs états et réagit à leurs événements. Leurs règles relèvent de la conception des smart contracts.
Les services hors chaîne
Indexation pour afficher vite, stockage des documents, notifications, comptes applicatifs. Le schéma d'ensemble relève de l'architecture blockchain. Les données venues de l'extérieur passent par des oracles.
Vos logiciels existants
CRM, ERP, outils métier : l'application échange avec eux, ou s'intègre à une plateforme métier.
L'administration
Tableaux de bord, suspension d'une fonction, journal des actions, support. Les droits d'administration relèvent de la sécurité et de la gouvernance.
Notre démarche, de la maquette au réseau de test, puis à la mise en ligne.
Chaque étape produit quelque chose que vous pouvez voir, essayer et valider.
Parcours
Utilisateurs, actions, moments de signature.
Maquettes
Écrans, états, erreurs, mobile.
Prototype sur réseau de test
Les vrais délais et les vrais refus, sans valeur réelle.
Développement
Interface, services, raccordement aux contrats.
Tests utilisateurs et accessibilité
Clavier, lecteurs d'écran, compréhension des états.
Mise en ligne et évolutions
Suivi, corrections, nouvelles fonctions, selon le périmètre convenu.
Questions fréquentes
Ce que l'on nous demande avant de concevoir une application décentralisée.
Qu'est-ce qu'une application décentralisée ?
Une application dont une partie des règles est exécutée par des smart contracts sur une blockchain. L'utilisateur y retrouve des écrans, des comptes et des notifications ; certaines de ses actions sont enregistrées et vérifiables par les parties concernées.
Toutes les actions d'une dApp passent-elles par la blockchain ?
Non. Consulter, rechercher, préparer ou échanger des documents se fait hors chaîne. Seules les actions qui doivent être vérifiables ou exécutées par le contrat y sont enregistrées : c'est un choix de conception, fait action par action.
Faut-il obligatoirement connecter un portefeuille pour utiliser une dApp ?
Pas toujours. Découvrir l'application ou consulter peut souvent se faire sans. Le portefeuille est demandé quand une action doit être signée. Les modalités de connexion et de signature se choisissent selon le projet, en tenant compte de leurs conséquences de sécurité et de responsabilité.
Que voit l'utilisateur quand une transaction est en attente ou échoue ?
Un état clair : envoyée, en attente, confirmée, refusée ou échouée, avec ce qu'il peut faire ensuite. Une attente ne s'affiche jamais comme un succès, et un échec explique sa cause et la bonne démarche. Le suivi technique de la transaction relève de l'architecture blockchain.
Une dApp peut-elle s'adresser à des utilisateurs qui ne connaissent pas la blockchain ?
Oui, si le vocabulaire et les parcours sont pensés pour eux : des mots de leur métier, des signatures limitées aux actions importantes, des états expliqués. Nous testons les parcours avec des utilisateurs représentatifs.
Comment faire évoluer une dApp après sa mise en ligne ?
L'interface et les services hors chaîne évoluent comme toute application. Les smart contracts déjà déployés se modifient plus difficilement ; leurs évolutions se prévoient dès la conception. Le suivi et les évolutions se font selon le périmètre convenu.
Nous concevons votre application Web3 écran par écran, pour que vos utilisateurs avancent sans hésiter.
Le dossier de conception d'expériencehuit planches, chacune répond à une question
Utilisateurs et profils
Qui utilise l'application, et que sait chacun de la blockchain ?
Actions principales
Quelles actions comptent, et lesquelles demandent vraiment une signature ?
Informations affichées
Que faut-il voir pour décider en confiance, au bon moment ?
Opérations blockchain
Qu'est-ce qui est enregistré sur la blockchain, et qu'est-ce qui reste hors chaîne ?
États et erreurs
Que dit l'écran pendant l'attente, après un refus, après un échec ?
Administration
Qui pilote, suspend ou corrige, et avec quelles traces ?
Systèmes existants
Quels logiciels, comptes et données l'application doit-elle rejoindre ?
Contraintes de déploiement
Sur quels appareils, avec quelles exigences d'accessibilité et de mise en ligne ?
Avant la première ligne de code, ce dossier fixe ce que l'application montre et ce qu'elle fait en coulisses.
Il sert de base au développement, aux tests sur réseau de test et aux échanges avec vos équipes métier, techniques et juridiques.
Étudions votre application Web3Un premier échange suffit pour situer votre projet : décrivez vos utilisateurs et l'action principale de l'application.