Solana Blinks

/14 oct. 2025

Points clés

• Les Blinks transforment les liens en actions on-chain accessibles depuis n'importe quelle plateforme.

• Ils améliorent l'expérience utilisateur en réduisant les étapes nécessaires pour effectuer une transaction.

• Les développeurs peuvent intégrer facilement des actions on-chain sans créer de dapps complètes.

Les Blinks Solana représentent l'une des avancées UX les plus intéressantes issues de l'écosystème Solana au cours de l'année écoulée. Abréviation de "Blockchain Links", les Blinks transforment n'importe quelle URL ordinaire en une action on-chain qui peut être prévisualisée et exécutée directement là où les utilisateurs se trouvent déjà : flux sociaux, applications de chat, résultats de recherche, blogs ou e-mails. Combinés aux Actions Solana (une norme pour décrire et servir ces points d'accès off-chain), les Blinks rendent les interactions crypto aussi fluides que de cliquer sur un lien.

Si le dernier cycle a porté sur l'intégration via les portefeuilles et les dapps, les Blinks visent à rencontrer les utilisateurs là où ils passent déjà leur temps. Ce changement est important pour la conversion, l'éducation et l'adoption généralisée. Solana Labs et les équipes communautaires ont introduit les Actions et les Blinks à la mi-2024, et l'élan s'est poursuivi en 2025 avec de plus en plus de développeurs expérimentant les paiements, les abonnements, les NFT et les flux DeFi activés depuis le web ouvert. Pour plus d'informations générales et de mises à jour, consultez le hub Solana News et le portail développeur sur le site officiel de Solana (la couverture des Actions Solana se trouve dans la section Actualités) et les guides développeurs sous Solana Developers.

Vue d'ensemble et ressources développeurs : Solana News et Solana Developers
Documentation de Dialect pour les Actions et les Blinks : Documentation Dialect

Ce qui suit est un guide concis destiné aux équipes produit, aux développeurs et aux utilisateurs avancés qui souhaitent comprendre ce que sont les Blinks, comment ils fonctionnent et ce qu'il faut surveiller lors de leur intégration en production.

Que sont les Blinks ?

Un Blink est un lien partageable qui représente une intention on-chain concrète : donner 0,01 SOL, mint un NFT, échanger un token, s'abonner à une adhésion, faire un don à une DAO, ou même exécuter un stake ou un vote. Lorsqu'un Blink est partagé, les clients compatibles peuvent afficher un aperçu riche avec un bouton d'appel à l'action (par exemple, "Donner", "Mint", "Échanger"). Cliquer sur le bouton lance le flux du portefeuille et signe la transaction contre le programme cible sur Solana.

Techniquement, les Blinks sont alimentés par des "Actions", qui sont des points d'accès HTTP renvoyant des métadonnées structurées sur ce que fait un utilisateur, ce qu'il va signer, et comment le simuler en toute sécurité. Ces métadonnées alimentent à la fois l'interface utilisateur de prévisualisation et la demande du portefeuille. Cette approche permet d'initier des actions on-chain depuis n'importe où pouvant afficher un aperçu de lien, en tirant parti des normes du web ouvert comme Open Graph pour fournir un contexte sûr et lisible par l'homme. Voir le protocole Open Graph pour savoir comment les aperçus sont couramment générés sur le web.

Modèle de transaction : Transactions et instructions Solana
Primitives de tokens utilisées par de nombreuses Actions : Programme de tokens SPL

Pourquoi les Blinks sont importants

Conversion sans friction : Réduit les étapes entre la découverte et la transaction. Pas besoin de naviguer dans une dapp, de se connecter et de chercher le bon bouton : un lien, une intention.
Composabilité et portabilité : Le même Blink fonctionne sur les flux, la messagerie, les blogs et la recherche, avec des métadonnées qui peuvent être vérifiées et simulées.
Expérience utilisateur plus sûre par défaut : Les points d'accès structurés permettent aux fournisseurs de portefeuilles de simuler, décoder et afficher ce qui va se passer avant une signature, facilitant ainsi la détection des effets secondaires néfastes.
Nouveaux canaux de croissance : Les équipes marketing, communautaires et de croissance peuvent intégrer des actions on-chain dans du contenu sans avoir à reconstruire des dapps complètes pour chaque surface.

Comment fonctionnent les Blinks en coulisses

Points d'accès d'Action : Les développeurs hébergent des points d'accès qui se conforment à la spécification des Actions (par exemple, GET pour la prévisualisation, POST pour assembler la charge utile de la transaction). La réponse inclut un titre descriptif, une icône, les coûts attendus, et la transaction sérialisée ou les instructions pour en construire une côté client. Référence : Documentation Dialect.
Cartes de prévisualisation : Lorsqu'un lien est partagé, les plateformes génèrent des aperçus de liens à l'aide des métadonnées Open Graph, de sorte que les utilisateurs voient un titre, une image et un appel à l'action fiables avant de cliquer. Référence : Protocole Open Graph.
Flux du portefeuille : Cliquer sur le Blink transfère le contrôle à un portefeuille (ordinateur, mobile ou intégré) pour simulation, affichage et signature. Les adaptateurs de portefeuille et les liens profonds rendent cette interopérabilité possible. Référence : Adaptateur de portefeuille Solana.
Exécution : Après la signature, la transaction est soumise à un RPC Solana et traitée on-chain avec une faible latence et de faibles frais. Référence : API JSON-RPC Solana.

Étant donné que les Actions renvoient des données lisibles par machine, les portefeuilles peuvent simuler et décoder la transaction avant que l'utilisateur ne signe – ce qui est utile pour afficher clairement les mouvements de tokens et les changements de compte. En savoir plus sur le modèle de transaction dans la documentation Solana.

Transactions Solana : Transactions et le modèle de programmation
Détails RPC et simulation : API JSON-RPC

Cas d'utilisation clés en 2025

Pourboires instantanés et micro-commerce : Les créateurs peuvent attacher un Blink à leurs publications qui invite à des pourboires en SOL ou en tokens SPL, avec un flux tenant compte des frais et optimisé pour les petits montants.
Aperçus de mint NFT : Partagez un Blink de mint avec des informations sur le stock restant, le prix et les métadonnées de la collection directement dans l'aperçu. Un clic ouvre le flux de mint.
"Actions rapides" DeFi : Proposez un lien vers un échange de tokens, un dépôt de coffre-fort, ou un ordre limite. L'aperçu peut montrer les tokens entrants/sortants attendus et les frais estimés.
Abonnements et adhésions : Créez des achats d'adhésion récurrents ou ponctuels en utilisant un Blink lié à un programme qui gère les droits d'accès.
Dons et financement de biens publics : Les DAOs et les organisations à but non lucratif peuvent intégrer des boutons de don partout où des liens peuvent aller.

Pour les développeurs axés sur les paiements, les modèles Solana Pay et les flux marchands restent pertinents et complémentaires aux Blinks, en particulier pour les flux de point de vente et QR. Référence : Solana Pay.

Modèle de sécurité et de confiance

Les Blinks étendent la distribution, ils doivent donc également élever la barre en matière de sécurité :

Confiance d'origine : Traitez le point d'accès Action comme une API à laquelle vous devez faire confiance. Utilisez HTTPS avec TLS moderne, appliquez des politiques CORS strictes et une limitation de débit, et publiez un domaine clair et vérifiable. Référence : Transport Layer Security sur MDN.
Simulation avant signature : Assurez-vous que les flux du portefeuille simulent et décodent toujours la transaction, en affichant les mouvements de tokens, les identifiants de programme, et les impacts de location/frais sous une forme lisible par l'homme.
Listes blanches et provenance : Les applications qui rendent automatiquement les aperçus de Blinks devraient autoriser les domaines réputés et afficher clairement l'URL sous-jacente pour que les utilisateurs puissent la vérifier.
Principe du moindre privilège : Créez des Actions qui ne demandent que les comptes et les autorités nécessaires pour une intention unique. Évitez les approbations trop larges ou les transferts cachés.
Contre-mesures de phishing : Encouragez les utilisateurs à vérifier les domaines, à ne jamais signer à l'aveugle, et à s'appuyer sur la signature matérielle pour les actions de grande valeur.

Checklist d'intégration pour les développeurs

Définissez votre intention : Quelle action on-chain le Blink déclenche-t-il ? Pourboire, mint, échange, stake, don, ou appel à programme personnalisé.
Créez le point d'accès Action : Implémentez les points d'accès de prévisualisation et de construction qui renvoient des métadonnées structurées et l'ensemble de transactions ou d'instructions.
Ajoutez de bons aperçus : Fournissez des titres, des icônes et des descriptions précis via Open Graph. Divulguez les frais et les flux de tokens dans l'aperçu si possible.
Simulez et vérifiez : Utilisez la simulation côté serveur et portefeuille pour détecter les échecs et les instructions risquées avant de demander des signatures.
Prenez en charge le mobile et le bureau : Intégrez les liens profonds et l'adaptateur de portefeuille Solana pour une large compatibilité avec les portefeuilles.
Surveillez et itérez : Suivez les taux de complétion et d'abandon ; optimisez les textes, les icônes et la gestion des frais pour la conversion.

Ressources utiles :

Portail Solana Developers pour les guides et références
Vue d'ensemble des Actions et Blinks par Dialect
Modèle de transaction Solana
API JSON-RPC
Programme de tokens SPL

Considérations pratiques

Frais et priorisation : Même les actions de faible valeur bénéficient d'une estimation dynamique des frais. Les marchés de frais de Solana et les frais de priorité aident à garantir des confirmations rapides sans payer trop cher. Voir l'API JSON-RPC Solana pour les points d'accès aux frais et à la simulation.
Limitation de débit et abus : Les Blinks populaires peuvent devenir des points d'accès surchargés. Protégez avec des vérifications de bots, des quotas de requêtes et de la mise en cache.
Internationalisation : Les aperçus sont textuels ; localisez les titres et les descriptions si possible pour augmenter la conversion par marché.
Gestion des liens : Si vous faites pivoter les domaines ou migrez les points d'accès, mettez en place des redirections appropriées pour éviter de casser les anciens Blinks.
Conformité : Pour le commerce et les dons, intégrez les flux standard de KYC/AML et de reporting fiscal si requis par votre juridiction.

Pour les utilisateurs : comment utiliser les Blinks en toute sécurité

Vérifiez le domaine avant de cliquer et avant de signer.
Lisez l'aperçu et la sortie de simulation du portefeuille ; confirmez que le programme et les flux de tokens correspondent à votre intention.
Utilisez la signature matérielle pour les actions importantes afin d'atténuer les risques de compromission de l'appareil.

Pourquoi un portefeuille matériel aide ici

Les Blinks rendent la tâche facile pour lancer une transaction depuis n'importe où sur le web, mais cette même commodité devrait être associée à une protection solide des clés. Un portefeuille matériel isole les clés privées de vos appareils connectés et garantit que les invites de transaction sont examinées sur un écran de confiance avant la signature.

Si vous utilisez Solana régulièrement – en particulier pour les échanges DeFi, les mint NFT, ou les paiements aux créateurs initiés via les Blinks – envisagez d'associer votre flux de portefeuille quotidien à OneKey. Les portefeuilles matériels de OneKey sont conçus pour :

Garder les clés privées hors ligne pendant que vous interagissez avec les Blinks dans votre navigateur ou application mobile
Afficher les détails clairs de la transaction sur un écran sécurisé avant approbation
S'intégrer aux principaux adaptateurs de portefeuille Solana pour une expérience de signature fluide sur ordinateur et mobile

Cette combinaison préserve l'UX fluide que les Blinks permettent, tout en ajoutant une couche de protection robuste pour les actifs à long terme et les actions de grande valeur.

Références et lectures complémentaires :