Qu’est-ce qu’une DApp ?

Une application décentralisée (decentralized application, DApp) est une application qui confie une partie de ses règles ou de son état essentiels — soldes, propriété, enregistrements d’autorisation, par exemple — à un réseau décentralisé comme une blockchain, qui les exécute et les conserve. Les utilisateurs continuent généralement de passer par une interface web ou mobile, mais les résultats clés peuvent être validés par plusieurs participants du réseau selon des règles communes, au lieu de dépendre d’une seule base de données détenue par l’exploitant de l’application.

« Décentralisé » décrit la répartition du contrôle et des dépendances d’une application ; ce n’est pas une étiquette obtenue automatiquement. Une DApp peut faire tourner ses contrats principaux en chaîne tout en dépendant d’un site unique, d’une interface de données, d’une clé d’administration ou d’un serveur hors chaîne. Juger une DApp suppose donc d’examiner couche par couche de quoi elle est faite et qui contrôle chaque couche.

De quoi une DApp est généralement composée

Une DApp n’est généralement pas un contrat intelligent isolé, mais une expérience complète fournie par plusieurs composants :

• Interface utilisateur : application web ou mobile qui affiche les informations et reçoit les actions ;
• Portefeuille : conserve ou mobilise la capacité de signature de l’utilisateur, qui confirme ainsi les connexions de compte et les transactions ;
• Programmes en chaîne : contrats intelligents ou programmes du réseau qui traitent transferts, autorisations et mises à jour d’état selon leur code ;
• Services de connexion réseau : transmettent requêtes et transactions signées aux nœuds de la blockchain ;
• Services hors chaîne : peuvent assurer la recherche, l’indexation, les notifications, le stockage d’images ou la fourniture de données externes.

La présentation des DApps par Ethereum considère les contrats intelligents et une interface frontale comme la combinaison courante. D’autres réseaux peuvent employer des modèles de programmes et de comptes différents. Solana, par exemple, sépare les programmes exécutables des comptes qui conservent les données modifiables. Les implémentations diffèrent, mais le lecteur peut examiner une application avec les mêmes questions : interface, autorisation, exécution par le réseau et provenance des données.

Les étapes principales d’une opération

Après l’ouverture d’une DApp, l’interface peut d’abord lire des informations publiques — un solde, une cotation ou un enregistrement en chaîne précis — via un nœud ou via un service d’indexation (un indexeur) qui organise les données en chaîne pour les rendre interrogeables. Ces lectures ne modifient généralement pas l’état de la blockchain et n’exigent pas que l’utilisateur signe chaque requête ; l’affichage dépend toutefois des données renvoyées par le service connecté et du moment de la requête.

Lorsque l’utilisateur lance une opération qui modifiera l’état, la DApp construit une demande de transaction et la transmet au portefeuille. Celui-ci doit montrer le réseau, l’adresse de destination, le contenu de l’autorisation et les frais susceptibles d’être engagés ; après confirmation, le portefeuille signe la transaction avec la capacité de signature du compte concerné.

La transaction signée est ensuite envoyée aux nœuds de la blockchain. Les nœuds contrôlent la signature et le format de la transaction selon le protocole, et exécutent le programme visé lors de la construction ou de la validation d’un bloc candidat. Une fois la transaction incluse dans un bloc valide, le résultat de l’exécution devient partie de l’état de cette chaîne et peut être recalculé et lu par d’autres nœuds. En cas d’échec de l’exécution, l’interface doit également se mettre à jour selon le résultat réel de la transaction, et non se contenter d’indiquer qu’une demande a été envoyée.

Entrer dans un bloc valide n’équivaut pas nécessairement à une confirmation finale immédiate. Une transaction peut devoir attendre davantage de confirmations, et dans certaines conditions de réseau l’historique des blocs peut aussi être réorganisé. Le moment où quelque chose peut être considéré comme définitif dépend du mécanisme de consensus du réseau concerné.

Ce déroulement montre que la page web elle-même ne modifie généralement pas directement la blockchain. L’interface prépare et affiche les demandes, le portefeuille gère l’autorisation de l’utilisateur, et le réseau avec les programmes en chaîne déterminent si l’état change conformément aux règles.

Connecter un portefeuille n’est pas approuver une transaction

Connecter un portefeuille permet généralement seulement à une DApp de savoir quelle adresse publique l’utilisateur a choisie, et lui ouvre un canal pour envoyer des demandes au portefeuille. Les comptes que l’application peut voir et les demandes qu’elle peut formuler dépendent du portefeuille et du standard de connexion utilisé. Se connecter ne doit pas équivaloir à remettre une clé privée, et cela ne signifie pas que l’utilisateur a approuvé un quelconque transfert d’actifs.

Les demandes suivantes peuvent remplir des rôles différents :

• Signer un message : prouve que le compte a signé un texte ou une donnée précis, sans produire nécessairement de transaction en chaîne ;
• Envoyer une transaction : demande au réseau d’exécuter un transfert ou un appel de contrat ;
• Autorisation de tokens : permet à une adresse ou à un programme de déplacer des tokens dans une limite définie ;
• Changer de réseau : fait basculer le portefeuille vers une autre blockchain ou un réseau de test.

L’utilisateur doit voir clairement le contenu réel de chaque demande. Se déconnecter d’un site ferme généralement la session en cours ; cela ne révoque pas automatiquement les autorisations de tokens ou autres droits déjà inscrits en chaîne.

Règles en chaîne et interfaces hors chaîne

Ce dont les programmes en chaîne ont la charge peut être contrôlé conjointement par les participants du réseau, mais la page web vue par l’utilisateur peut rester hébergée par une équipe donnée. Un site peut être mis à jour, fermé, soumis à des restrictions d’accès ou afficher des informations erronées, alors qu’un contrat déjà déployé peut continuer d’exister.

Qu’un contrat soit toujours en chaîne ne signifie pas que les utilisateurs ordinaires peuvent continuer à l’utiliser facilement. Il leur faut aussi une interface fonctionnelle, la bonne adresse de contrat, une connexion à un nœud et l’interprétation nécessaire des données. Des utilisateurs techniquement à l’aise peuvent passer par une autre interface ou appeler le contrat directement, mais cela dépend de l’existence d’un point d’entrée adapté et augmente la difficulté de l’opération.

À l’inverse, une interface au code source ouvert ou à l’hébergement distribué ne permet pas d’établir que le programme en chaîne n’a aucun droit d’administration. Apprécier une structure de contrôle suppose de vérifier séparément le mode de publication du frontend, les droits de mise à niveau des contrats, les droits de suspension, les droits sur les fonds et les dépendances externes.

Les données ne sont pas forcément toutes stockées en chaîne

Une blockchain convient à l’état qui doit être validé conjointement, mais y stocker directement de gros volumes d’images, de vidéos ou de données de recherche peut coûter cher. Les DApps conservent donc souvent les soldes et les droits essentiels en chaîne, en plaçant le reste sur des serveurs ordinaires ou des réseaux de fichiers distribués.

Prenons l’InterPlanetary File System (IPFS), un protocole de fichiers distribué qui localise les données par leur contenu plutôt que par un emplacement de serveur fixe. IPFS génère pour le contenu un identifiant de données vérifiable. Cela aide le lecteur à contrôler si le contenu reçu correspond à l’identifiant, mais ne garantit pas que quelqu’un soit toujours en ligne pour fournir le fichier, et n’établit pas que son contenu soit véridique.

Inscrire en chaîne un lien web ou un identifiant de contenu établit seulement que l’application a conservé cette référence. L’accessibilité de la cible, son mainteneur, la possibilité de la remplacer et sa durée de conservation restent à vérifier dans le dispositif concerné.

Le degré de décentralisation s’apprécie couche par couche

Plutôt que de demander si une DApp est « totalement décentralisée », il est plus utile de contrôler chaque couche :

• Exécution : les règles principales sont-elles exécutées conjointement par plusieurs nœuds, ou décidées par un serveur unique ?
• État : où se trouvent les soldes et droits essentiels, et qui peut les modifier ?
• Mises à niveau : les contrats peuvent-ils être mis à niveau, et quelle approbation cela exige-t-il ?
• Interface : n’existe-t-il qu’un point d’entrée officiel, et d’autres peuvent-ils déployer une interface alternative ?
• Données : l’application dépend-elle d’un service de nœud, d’un indexeur, d’un oracle ou d’un serveur de fichiers unique ?
• Gouvernance : qui est responsable de la suspension, de l’ajustement des paramètres et de la gestion des fonds ?

Des réponses différentes produisent des structures de contrôle différentes. Exiger plusieurs signatures conjointes, prévoir un délai avant l’entrée en vigueur d’une modification ou décider par un vote public répartissent chacun une partie des droits, sans supprimer automatiquement toute dépendance concentrée ; de même, conserver une suspension d’urgence peut être un choix délibéré de maîtrise des risques. Un article doit indiquer le dispositif réel plutôt que conclure à partir du nom « DApp ».

Différence entre une DApp et une application ordinaire

Les deux types d’application peuvent avoir pages web, comptes et services côté serveur. La différence porte surtout sur qui confirme l’état et les règles essentiels.

Une application ordinaire fait généralement recevoir les requêtes par les serveurs de l’exploitant, qui modifie une base de données et décide de la version logicielle. Les utilisateurs doivent faire confiance à l’exploitant pour conserver correctement les données, et n’accèdent généralement au service que par les interfaces qu’il fournit.

Une DApp peut placer une partie des règles et de l’état dans un réseau blockchain, exécuté par les nœuds selon le protocole. Les utilisateurs signent les transactions avec leurs propres comptes, et d’autres interfaces peuvent appeler les mêmes programmes en chaîne. Cette vérifiabilité va toutefois de pair avec des contreparties : frais, état public, attente de confirmation, failles de contrat et coordination des mises à niveau.

Une DApp n’est donc pas « une application sans équipe de développement ni serveurs ». Elle déplace certaines décisions d’un back-end unique vers un réseau commun, tout en conservant éventuellement des composants hors chaîne.

DApps, contrats intelligents et organisations en chaîne

Un contrat intelligent est du code exécuté en chaîne ; une DApp est l’application complète tournée vers l’utilisateur, comprenant généralement des contrats intelligents, une interface et d’autres services. Un même contrat peut être utilisé par plusieurs DApps, et une même DApp peut appeler plusieurs contrats.

Une organisation autonome décentralisée (decentralized autonomous organization, DAO) est un mode d’organisation qui utilise des règles en chaîne, des votes ou des droits multipartites pour coordonner décisions et ressources. Une DAO peut proposer une interface de vote au travers d’une DApp, mais une DApp n’est pas nécessairement une DAO et n’a pas à émettre de token de gouvernance.

De même, le fait qu’une application ait un token ne la rend pas automatiquement décentralisée. Répartition du token, droits d’administration, mises à niveau des contrats et contrôle de l’interface restent à vérifier séparément.

Principales limites et risques

Les risques d’une DApp peuvent venir de chaque couche :

• le code du contrat intelligent comporte des failles, ou les droits d’administration dépassent ce que les utilisateurs anticipent ;
• l’interface est altérée et pousse les utilisateurs à signer une mauvaise transaction ;
• le portefeuille n’affiche pas clairement ce qui est appelé ;
• un nœud ou un service d’indexation renvoie des données obsolètes, erronées ou incomplètes ;
• un service qui transmet des informations externes en chaîne fournit des données inexactes ;
• fichiers, nom de domaine ou point d’entrée officiel cessent de fonctionner ;
• le réseau sous-jacent se congestionne, voit ses frais varier ou connaît une panne.

Qu’une transaction s’exécute avec succès sur une blockchain montre seulement qu’elle respectait les règles du réseau et du contrat à ce moment-là. Cela n’établit pas que l’utilisateur avait compris la demande, ni que les informations hors chaîne fournies par l’application étaient exactes.

FAQ

Une DApp doit-elle avoir son propre token ?

Non. Un token peut servir au paiement, aux droits ou à la gouvernance, mais ce n’est pas une condition nécessaire pour qu’une application soit une DApp.

Toutes les données d’une DApp sont-elles publiques ?

Pas nécessairement. Les transactions et l’état d’une blockchain publique peuvent généralement être lus, mais une application peut aussi utiliser des bases de données hors chaîne, des données chiffrées ou des techniques de confidentialité. Le périmètre réellement visible dépend du réseau et de la conception.

Une DApp reste-t-elle utilisable après la fermeture du site officiel ?

Les programmes en chaîne peuvent continuer d’exister, mais il faut aussi aux utilisateurs une interface alternative, une connexion à un nœud et les bonnes informations de contrat. La poursuite de l’usage dépend du caractère ouvert et disponible de chaque composant.

La clé privée est-elle remise au site lors de l’utilisation d’une DApp ?

Une interaction normale avec un portefeuille n’exige pas de remettre la clé privée à un site. Le portefeuille signe dans son propre périmètre de sécurité, puis transmet la signature ou la transaction signée à l’application. Les utilisateurs doivent néanmoins se méfier des interfaces qui réclament une phrase de récupération ou une clé privée, ou qui les incitent à signer des demandes dangereuses.

Une DApp est-elle forcément sans administrateur ?

Pas nécessairement. Un contrat peut conserver des droits de mise à niveau, de suspension, d’ajustement de paramètres ou de gestion des fonds. Il faut consulter le code et les droits effectifs plutôt que s’en tenir au nom de l’application.

Concepts associés

Poursuis avec contrat intelligent, Ethereum, l’EVM, portefeuille non custodial et blockchain, ou reviens au glossaire des cryptomonnaies.

Sources

• Ethereum.org : introduction aux dapps — relation de base entre un frontend, les contrats intelligents et un réseau décentralisé.
• Ethereum.org : introduction aux contrats intelligents — déploiement, appels et limites d’exécution des programmes en chaîne.
• IPFS Docs : how IPFS works — adressage par contenu, identifiants de données, routage et transfert de fichiers.
• Solana Docs : programs — exemple d’implémentation séparant programmes exécutables et comptes de données autonomes.