Construire une application Web3 : architecture, stacks et intégration wallet

Créer une application Web3 ne signifie pas tout décentraliser. C'est choisir intelligemment quelles parties bénéficient de la blockchain — et lesquelles restent sur une infrastructure Web2 classique. La majorité des DApps qui fonctionnent bien aujourd'hui sont des hybrides : un frontend hébergé normalement, des smart contracts pour la logique critique, et du stockage décentralisé pour les assets.

Ce guide est double : les concepts sont là pour les entrepreneurs qui veulent comprendre ce qu'ils construisent, et les checklists techniques pour les développeurs qui mettent les mains dans le code. Tu peux lire les deux — ça prend 15 minutes et ça change la façon dont tu supervises ou contribues à un projet Web3.

Si tu débarques dans l'univers Web3, commence d'abord par [comprendre ce qu'est vraiment le Web3](/web3/web3-definition) avant d'attaquer l'architecture.

L'architecture d'une DApp — ce qui se passe sous le capot

Avant d'écrire une seule ligne de code ou de briefer ton équipe, il faut comprendre en quoi une application décentralisée diffère structurellement d'une app classique.

Web2 vs Web3 : deux modèles de fond

Dans une application Web2 traditionnelle, le schéma est simple et linéaire :

Frontend → Backend → Base de données centralisée

L'utilisateur interagit avec une interface, qui appelle un serveur, qui lit et écrit dans une base de données que toi ou ton fournisseur cloud contrôlez. Rapide, connu, maîtrisé — mais centralisé. Si le serveur tombe, l'app tombe. Si la base de données est compromise, les données sont compromises.

Dans une application Web3, le modèle est différent :

Frontend → Smart contracts (blockchain) + Backend optionnel + Stockage décentralisé

La logique métier critique vit sur la blockchain sous forme de smart contracts. Le backend traditionnel peut encore exister — pour l'indexation, les notifications, les fonctions qui n'ont pas besoin de blockchain. Le stockage des fichiers lourds (images, metadata) va sur IPFS ou Arweave plutôt qu'un S3.

Les 4 composantes d'une DApp

1. Le frontend — l'interface utilisateur. Techniquement, rien ne change par rapport au Web2 : React, Vue, Next.js. La différence, c'est que le frontend interagit avec des smart contracts via des bibliothèques spécialisées, pas avec une API REST classique.

2. Les smart contracts — la logique métier sur la blockchain. C'est là que résident les règles qui ne peuvent pas être modifiées unilatéralement après déploiement : transferts de tokens, conditions de paiement, droits de propriété NFT. Solidity pour les blockchains compatibles EVM (Ethereum, Polygon, Arbitrum, Base), Rust pour Solana.

3. La connexion wallet — la bibliothèque qui fait le pont entre le frontend et le wallet de l'utilisateur. C'est ce qui remplace le système login/mot de passe classique. Le wallet devient l'identité de l'utilisateur.

4. Le stockage décentralisé — IPFS, Arweave — pour les fichiers volumineux ou qui doivent être immuablement accessibles. Les images NFT et leurs metadata ne vont pas sur la blockchain (trop cher), elles vont sur IPFS avec un hash stocké dans le smart contract.

Quand utiliser la blockchain ?

La question que tout entrepreneur devrait se poser en premier : est-ce que la décentralisation, la transparence ou la propriété apportent une vraie valeur ici ? Si la réponse est non, reste en Web2.

La blockchain est pertinente pour : les transferts de valeur sans intermédiaire, la propriété vérifiable d'un actif numérique, les règles d'un protocole que personne ne doit pouvoir modifier seul, la transparence publique des transactions.

La blockchain n'est pas pertinente pour : stocker des données utilisateurs classiques, les fonctions nécessitant une rapidité extrême, les systèmes où la confidentialité prime absolument.

Les stacks populaires en 2025

Voici ce que les équipes sérieuses utilisent aujourd'hui, par écosystème.

Pour les applications EVM (Ethereum, Polygon, Arbitrum, Base)

Hardhat vs Foundry en détail :

Hardhat est le framework historique, avec un écosystème de plugins très riche, une documentation abondante et une adoption massive. Si ton équipe a de l'expérience ou que tu recrutes des devs, Hardhat reste une valeur sûre.

Foundry est plus récent, plus rapide à l'exécution, et permet d'écrire les tests directement en Solidity plutôt qu'en JavaScript. C'est la tendance chez les devs expérimentés et les protocoles DeFi sérieux. Les tests de fuzz intégrés sont un vrai avantage pour la sécurité.

Ethers.js vs Viem en détail :

Ethers.js est la bibliothèque qui a dominé le développement frontend Web3 pendant des années. Stable, documentée, avec une large communauté.

Viem est TypeScript-first dès sa conception, plus modulaire, avec des performances améliorées et une API plus cohérente. Les nouveaux projets qui partent de zéro choisissent majoritairement Viem en 2025. Wagmi v2 est construit sur Viem.

Pour Solana

• Anchor : le framework de référence pour écrire des programs (smart contracts) en Rust avec des bindings TypeScript. Réduit considérablement la complexité par rapport au Rust natif.
• @solana/web3.js : le SDK JavaScript officiel pour interagir avec le réseau Solana depuis le frontend.
• Wallet Adapter : la solution standard pour connecter Phantom, Solflare, Backpack et les autres wallets Solana à ta DApp.

Frontend et déploiement

Next.js est devenu le framework React recommandé pour les DApps, et ce pour de bonnes raisons : le SSR (Server-Side Rendering) améliore le SEO, les API Routes permettent de gérer des logiques backend légères sans déployer un serveur séparé, et l'intégration avec Vercel est sans friction.

Vercel pour le déploiement frontend : gratuit pour commencer, scalable, avec des previews automatiques sur chaque PR. Difficile de faire mieux pour lancer rapidement.

IPFS via Pinata ou nft.storage pour les assets décentralisés. Pinata offre une API simple avec un dashboard, nft.storage est gratuit pour les NFTs. Pour les projets en production avec beaucoup d'assets, Pinata est plus robuste.

Pour aller plus loin sur l'écosystème DeFi qui tourne sur ces stacks, consulte [notre guide complet sur la DeFi](/defi/defi-cest-quoi).

L'UX wallet — le plus grand défi du Web3

Tu peux avoir les meilleurs smart contracts du monde, si l'UX de connexion est frustrante, tu perds tes utilisateurs. L'intégration wallet est l'étape qui génère le plus d'abandons chez les utilisateurs non-crypto.

Le problème structurel

Pour un utilisateur habitué au Web2, "connecte ton wallet" est une phrase étrange. Il faut d'abord installer une extension, créer un wallet, sécuriser une seed phrase, acheter des tokens pour les gas fees... avant même d'utiliser ton application. C'est un funnel d'acquisition catastrophique comparé à un simple "s'inscrire avec Google".

C'est précisément là que l'Account Abstraction change la donne — mais on y vient.

Bonnes pratiques UX à implémenter maintenant

Rends la connexion optionnelle à l'entrée. Montre ce que l'application fait avant de demander une connexion. Les utilisateurs qui comprennent la valeur connectent leur wallet. Les autres auraient de toute façon abandonné.

Supporte plusieurs wallets. Avec RainbowKit ou ConnectKit + Wagmi, tu obtiens gratuitement la compatibilité avec MetaMask, WalletConnect, Coinbase Wallet, Rainbow et bien d'autres. Ne force pas MetaMask uniquement — une part croissante des utilisateurs est sur mobile.

Explique chaque signature. Ne demande jamais une signature sans expliquer ce qu'elle implique. "Signe ce message pour prouver que tu possèdes ce wallet" est acceptable. Une signature obscure avec des paramètres hexadécimaux fait fuir même les utilisateurs expérimentés.

Affiche le réseau connecté en permanence. Et alerte immédiatement si l'utilisateur est sur le mauvais réseau avec un bouton pour basculer automatiquement. Rien de plus frustrant qu'une transaction qui échoue sans raison apparente.

Gère tous les états wallet explicitement :

• Non connecté → invite claire à connecter
• Connexion en cours → feedback visuel
• Connecté → adresse affichée (raccourcie), réseau visible
• Mauvais réseau → bannière d'alerte + action corrective
• Transaction en cours → spinner + hash de transaction cliquable
• Transaction confirmée → feedback de succès

WalletConnect : le protocole universel

WalletConnect est le protocole qui permet à n'importe quel wallet mobile de se connecter à n'importe quelle DApp, via un QR code ou un lien deep link. C'est devenu indispensable : une large portion des utilisateurs crypto est sur mobile avec Phantom, Rainbow ou Trust Wallet, pas sur desktop avec MetaMask.

Account Abstraction (ERC-4337) : le futur de l'onboarding

L'Account Abstraction est la réponse structurelle aux problèmes d'UX du Web3. Au lieu d'un wallet classique (Externally Owned Account), l'utilisateur interagit avec un smart contract wallet qui permet :

• Pas de seed phrase : récupération de compte par email, 2FA ou social recovery
• Sponsoring des gas fees : ton application peut payer les gas fees pour l'utilisateur (gas abstraction)
• Sessions temporaires : autoriser une application pour une durée limitée sans signer chaque transaction
• Batching : regrouper plusieurs transactions en une seule

En 2025, l'Account Abstraction est encore en phase de déploiement progressif — des solutions comme Safe, ZeroDev, Biconomy et Alchemy's Account Kit commencent à être utilisées en production. C'est l'avenir de l'onboarding Web3.

Sécurité des smart contracts — checklist développeur

Un smart contract déployé est immutable. Une faille dans le code devient une faille permanente — à moins d'avoir prévu un mécanisme d'upgrade. Avant tout déploiement sur mainnet, passe cette checklist point par point.

Checklist sécurité — 10 points critiques

• [ ] Tests unitaires exhaustifs : couverture 100% des fonctions critiques avec Hardhat ou Foundry. Pas de déploiement sans tests verts.
• [ ] Tests de fuzz (Foundry) : génère automatiquement des milliers d'inputs aléatoires pour détecter les edge cases que les tests manuels ne couvrent pas.
• [ ] Protection reentrancy : implémenter le pattern checks-effects-interactions (vérifications → modifications d'état → interactions externes) ou utiliser ReentrancyGuard d'OpenZeppelin. La faille reentrancy a causé le hack du DAO en 2016 et continue de faire des victimes.
• [ ] Access control strict : documenter et vérifier qui peut appeler chaque fonction. Utiliser Ownable pour les permissions simples, AccessControl d'OpenZeppelin pour les systèmes multi-rôles.
• [ ] Pas de block.timestamp pour les décisions critiques : les miners peuvent manipuler le timestamp à la marge. Pour les timeouts critiques ou les randomness, chercher une alternative (Chainlink VRF pour le random).
• [ ] Vérification integer overflow : Solidity 0.8+ protège nativement contre les overflows, mais vérifier les bibliothèques custom et les opérations unchecked explicites dans le code.
• [ ] Audit externe avant déploiement avec des fonds réels. Code4rena (contests communautaires), Trail of Bits, OpenZeppelin, Spearbit — le choix dépend du budget. Un audit d'un projet sérieux coûte entre 10k et 100k$. Coûteux, mais moins que de perdre les fonds des utilisateurs.
• [ ] Bug bounty via Immunefi après le lancement. Offrir une récompense aux whitehats qui trouvent des failles incite les chercheurs en sécurité à auditer le code en continu plutôt qu'à l'exploiter.
• [ ] Timelock sur les fonctions admin : toute fonction critique (upgrade du contrat, pause, changement de paramètres économiques) doit passer par un timelock de 24h à 72h minimum. Les utilisateurs ont le temps de réagir si une action suspecte est déclenchée.
• [ ] Déploiement sur testnet en premier : Sepolia pour Ethereum, Mumbai pour Polygon. Tests exhaustifs avec des scénarios réels avant de toucher au mainnet. Jamais de "test rapide" directement en production.

Pour aller plus loin sur ce sujet critique, consulte [notre guide complet sur l'audit de smart contracts](/securite/audit-smart-contract).

Pour les entrepreneurs non-techniques — les questions à poser à ton équipe

Tu n'as pas besoin de lire du Solidity pour superviser correctement le développement d'une DApp. Tu as besoin de poser les bonnes questions et de comprendre les réponses.

### Encadré : 5 questions à poser à ton équipe technique

1. La logique critique est-elle vraiment sur la blockchain ?

Demande à ton équipe de justifier ce qui est on-chain vs off-chain. Trop de code on-chain = gas fees élevés. Pas assez = centralisation cachée qui détruit la proposition de valeur Web3.

2. Qui a écrit les smart contracts, et ont-ils de l'expérience en sécurité ?

Écrire du Solidity qui fonctionne est facile. Écrire du Solidity qui résiste aux attaques est une spécialité. Vérifie les projets précédents, les audits passés, la participation à des programmes de bug bounty.

3. Où sont stockées les données sensibles des utilisateurs ?

La blockchain est publique et permanente. Les emails, KYC, données personnelles ne vont jamais on-chain. Si ton équipe ne sait pas répondre à cette question immédiatement, c'est un signal d'alarme.

4. Quel est le plan de réponse à une faille post-lancement ?

Est-ce que le contrat est upgradeable ? Y a-t-il un mécanisme de pause d'urgence ? Qui a le pouvoir de l'activer et en combien de temps ? Le bug bounty est-il en place ? Un protocole sans plan de réponse aux incidents n'est pas prêt pour la production.

5. Combien coûtent les gas fees pour l'utilisateur en pratique ?

Fais simuler des scénarios réels. Sur Ethereum mainnet, une interaction avec un smart contract complexe peut coûter 10$ à 50$+ en gas lors des pics de congestion. C'est un deal-breaker pour l'UX. Si les fees sont trop élevés, explore un déploiement sur Arbitrum, Base ou Polygon.

Bonus : la question de la vraie décentralisation

Pose-toi cette question honnêtement : est-ce que l'application peut fonctionner si votre frontend est hors ligne ?

Si la réponse est non, l'application n'est pas vraiment décentralisée — c'est une interface centralisée devant des smart contracts. Ce n'est pas forcément un problème pour ton modèle business, mais ça doit être assumé et communiqué clairement aux utilisateurs. La vraie décentralisation implique que le frontend soit lui-même sur IPFS ou Arweave, accessible même si le domaine principal est coupé.

Pour une vision complète de ce que la gouvernance décentralisée implique, consulte [notre guide sur les DAOs](/web3/dao-guide).

Ce qu'il faut retenir

Construire une application Web3 en 2025 est techniquement accessible avec les bons outils : Next.js + Wagmi + Viem + Foundry + OpenZeppelin couvre 80% des besoins d'une DApp EVM sérieuse. Le stack est mature, la documentation est là, la communauté est active.

Mais la technique n'est que la moitié du problème. L'UX wallet reste le plus grand frein à l'adoption : chaque friction dans le flow de connexion ou de transaction coûte des utilisateurs. L'Account Abstraction va progressivement résoudre ces problèmes structurels — intègre dès maintenant une architecture compatible.

Et la sécurité n'est pas optionnelle. Un smart contract mal audité avec des fonds utilisateurs est une bombe à retardement. Coûte que coûte, fais auditer avant de mettre des fonds réels en jeu.

Prochaines lectures recommandées :

• [Guide complet sur les DAOs et la gouvernance décentralisée →](/web3/dao-guide)
• [Audit de smart contracts : comment ça marche et pourquoi c'est indispensable →](/securite/audit-smart-contract)
• [L'identité décentralisée (DID) : le futur du login Web3 →](/web3/identite-decentralisee)
• [DeFi : comprendre les protocoles qui tournent sur ces stacks →](/defi/defi-cest-quoi)