← Tous les articles

12 min de lecture

Utiliser CardanoWall sans passer par le site web

Le site web n'est qu'une interface, pas le produit tout entier. Vous pouvez publier et vérifier des records Label 309 via une CLI, des SDK, une API de gateway, une application de bureau ou votre propre service.

Vous pouvez utiliser CardanoWall sans jamais ouvrir le site web. Les mêmes records de preuve d'existence peuvent être créés, publiés et vérifiés depuis un outil en ligne de commande, un SDK intégré au code de votre application, une API de gateway, une application de bureau ou un service que vous exploitez vous-même. Le site web n'est qu'une interface posée sur un standard ouvert — Label 309 —, et c'est le standard qui compte vraiment.

Cette distinction est tout l'enjeu. La preuve d'existence n'est souvent pas un geste humain isolé. Elle a sa place au sein d'un pipeline de build, d'une routine de conformité, d'un système de provenance pour l'IA, d'un workflow de preuve juridique, ou d'un produit conçu par quelqu'un d'autre. Aucun de ces cas ne devrait exiger qu'une personne navigue dans une seule interface web.

Que fait réellement le site web ?

Le site web rend la preuve d'existence accessible. Il vous offre un composer visuel, une vue du compte et du solde, des pages de record, la gestion des identités, un flux d'upload et une publication guidée. Pour la plupart des gens, c'est le bon point de départ.

Mais il ne devrait pas être l'unique façon d'utiliser le standard. Si une preuve ne fonctionne que lorsqu'un humain navigue dans une interface, elle ne peut pas devenir une infrastructure. Les entreprises ont besoin d'automatisation. Les développeurs ont besoin d'API et de SDK. Les équipes opérationnelles et de sécurité ont besoin de workflows reproductibles et scriptables. Certains utilisateurs veulent leurs records et leurs fichiers sur leur propre machine. Certains opérateurs veulent exécuter eux-mêmes l'ensemble du pipeline.

L'application web est la porte d'entrée. Ce n'est pas le bâtiment tout entier.

Quelles sont les autres façons de l'utiliser ?

Il en existe plusieurs, et elles convergent toutes vers le même artefact — un record Label 309 standard, ancré sur Cardano, que chacun peut vérifier de façon indépendante :

  • l'application web CardanoWall ;
  • l'outil en ligne de commande open source cardanowall ;
  • les SDK officiels (TypeScript, Python, Rust) pour le code applicatif ;
  • une API de gateway Label 309, accessible avec un token par compte ;
  • CardanoWall Desktop, le client open source local-first ;
  • un gateway que vous hébergez vous-même ;
  • votre propre produit bâti sur un gateway.

L'interface peut changer. Le format de la preuve, non. Tout ce code est open source sur github.com/cardanowall, sous licence Apache-2.0, avec le texte de la spécification sous CC-BY-4.0.

Quand devrais-je utiliser l'API de gateway ?

Utilisez l'API lorsque la publication ou la lecture de preuves doit s'intégrer à un système plutôt que rester une étape manuelle. Par exemple :

  • un produit SaaS crée une preuve pour chaque document client ;
  • un pipeline de build publie des preuves de version après chaque build ;
  • une plateforme d'IA ancre des lots de sorties générées ;
  • un système de conformité publie un instantané de contrôle quotidien ;
  • un workflow scelle des pièces à l'intention de destinataires précis ;
  • un tableau de bord interne lit le statut de publication et le solde du compte ;
  • une intégration partenaire soumet des records sans toucher à l'interface de CardanoWall.

La voie de l'API permet à votre logiciel d'appeler directement un gateway tout en conservant votre propre expérience utilisateur. L'application web et le worker de CardanoWall atteignent le gateway exactement par ces endpoints publics — il n'y a pas de porte privée, donc tout ce que le produit de référence sait faire, vous pouvez le faire aussi. Pour approfondir le sujet, consultez bâtir sur l'API CardanoWall.

Comment fonctionnent les tokens d'API et les scopes ?

Un gateway distingue deux types de credential, et les garder séparés est la chose la plus importante à réussir.

Les tokens de compte agissent comme l'un de vos utilisateurs. Votre backend émet un token éphémère pour un compte donné, et l'appel s'effectue sous ce token : demander un devis, uploader du contenu, publier, lire le solde de ce compte. Ce sont ces tokens — et les clés d'API construites sur le même modèle — qui ont leur place dans les scripts, les jobs de CI et les intégrations. Ils sont délibérément restreints. L'ensemble des scopes actuels est réduit et taillé pour un usage précis :

  • poe:create — demander des devis, uploader du contenu, publier des records ;
  • poe:read — lire les records et le statut de publication ;
  • inbox:read — lire le marque-page de synchronisation chiffré de la boîte de réception ;
  • account:read — lire le solde du compte.

Voilà toute la surface programmatique, et elle est scopée à dessein. Un widget de tableau de bord en lecture seule n'a besoin que de account:read. Un job de publication a besoin de poe:create. Ni l'un ni l'autre n'a besoin du scope de l'autre. Il n'existe volontairement aucun scope de déchiffrement côté serveur : le scellement et le descellement sont des opérations côté client, si bien que les clés privées des destinataires n'atteignent jamais un gateway et qu'aucune clé d'API ne pourrait autoriser le serveur à lire pour vous un contenu scellé. De la même façon, un job de CI ne devrait jamais détenir la graine d'identité d'un utilisateur, à moins que la signature locale ne soit un choix délibéré de votre propre conception, sous vos propres contrôles — les graines et les clés privées restent sur le client par conception, et un gateway ne les voit jamais.

Les credentials d'opérateur constituent le second type, et ce ne sont pas des clés d'API. Ils autorisent le plan de contrôle — provisionner des comptes, appliquer des ajustements de solde lorsque votre facturation encaisse de l'argent, définir des marges, émettre les tokens de compte évoqués plus haut. Ils ne doivent résider que sur un backend de confiance, jamais dans un navigateur, une application mobile ou un script. La fuite d'un token de compte devrait n'être qu'une gêne passagère ; la fuite d'un credential d'opérateur serait un véritable incident.

La règle d'or : confiez aux clients le token restreint, limité au compte, dont ils ont besoin, et gardez l'autorité d'opérateur derrière votre propre backend.

Quand devrais-je utiliser la CLI ?

Utilisez l'outil en ligne de commande lorsqu'une preuve a sa place dans un script. Le binaire cardanowall est indépendant du gateway et privilégie les graines brutes, ce qui en fait un choix naturel pour :

  • vérifier un record en local, sans ouvrir aucun site web ;
  • construire et contrôler des preuves Merkle sur de nombreux fichiers ;
  • signer des records ;
  • soumettre des records depuis l'automatisation ;
  • synchroniser la boîte de réception et déchiffrer à l'essai depuis le terminal.

La CLI a son importance avant tout parce qu'elle garde la preuve d'existence au plus près des systèmes qui produisent les artefacts. Un pipeline de build peut hacher ses sorties et publier un record dans le cadre de la version. Un job de conformité peut s'engager sur un manifeste quotidien. Un utilisateur local peut vérifier un record hors ligne. Le site web est excellent pour les personnes ; la CLI est excellente pour les opérations reproductibles. Pour des modèles d'usage et des exemples, consultez utiliser la CLI dans l'automatisation.

Quand devrais-je utiliser un SDK ?

Utilisez un SDK lorsque Label 309 doit faire partie de votre application. Les SDK TypeScript, Python et Rust aident à construire des records, hacher du contenu, vérifier des transactions, signer hors hôte, sceller et déchiffrer des contenus, dériver une identité à partir d'une graine et dialoguer avec n'importe quel gateway.

L'intérêt de disposer de trois SDK n'est pas la commodité — c'est l'interopérabilité. Ce sont des jumeaux identiques au bit près, validés contre les mêmes vecteurs de test canoniques, de sorte qu'un record publié ou signé par l'un se vérifie à l'identique sous les autres. C'est ainsi qu'un standard ouvert reste un standard ouvert plutôt que de se fragmenter en formats « compatibles » mutuellement incompatibles. Une propriété utile mérite d'être soulignée : le vérificateur autonome n'a besoin que des métadonnées de la transaction, éventuellement des octets du contenu, et d'un explorateur Cardano public — aucun serveur d'émetteur ne se trouve sur le chemin de confiance.

Quand devrais-je utiliser Desktop plutôt que le site web ?

Utilisez l'application de bureau lorsque la possession locale compte. CardanoWall Desktop est un client open source, multiplateforme et offline-first, conçu en Rust avec Tauri par-dessus le SDK Rust ; il fonctionne comme un client de messagerie : il vous offre

  • des coffres d'identité locaux et chiffrés ;
  • un accès hors ligne à tout ce qui est déjà synchronisé ;
  • la découverte de la boîte de réception scellée et la mise en cache du texte chiffré sur votre propre machine ;
  • une recherche locale sur l'index public des records ;
  • plusieurs identités et le choix de votre fournisseur de gateway.

Le site web reste rapide et pratique, tandis que l'application de bureau est le meilleur choix lorsque vous voulez que vos records, vos identités et vos fichiers en cache résident en local et continuent de fonctionner sans réseau. Pour beaucoup de gens, la réponse sera : les deux. On en dit davantage sur la conception dans CardanoWall Desktop et les preuves hors ligne.

Quand devrais-je héberger moi-même un gateway ?

Hébergez-le vous-même lorsque vous voulez exploiter le pipeline de publication par vos propres moyens — pour la conformité, la structure de coûts, le volume, la politique de traitement des données, le contrôle de l'infrastructure ou la stratégie produit.

Un gateway auto-hébergé publie toujours des records Label 309 standard ; la différence, c'est que c'est vous qui exploitez le service qui établit les devis, uploade, soumet, confirme, indexe et tient la comptabilité de la publication. Le gateway est un binaire Rust unique open source accompagné de Postgres, doté de son propre constructeur de transactions Cardano qui construit, soumet, confirme, gère les réorganisations de chaîne et rembourse automatiquement en cas d'échec définitif.

L'auto-hébergement n'est pas « gratuit ». Vous payez toujours les coûts sous-jacents de Cardano et d'Arweave, et vous assumez la responsabilité opérationnelle de son exploitation. Ce que vous supprimez, c'est toute dépendance à un gateway CardanoWall hébergé pour publier. Consultez exploiter votre propre gateway et qu'est-ce qu'un gateway Label 309 ?.

Puis-je bâtir mon propre produit sur un gateway ?

Oui — et cette séparation est précisément la raison pour laquelle le gateway constitue sa propre couche, distincte de l'application web. Vous pouvez bâtir un produit de notarisation, un portail de preuves, une archive de conformité, un outil de publication, un service de provenance pour l'IA ou un tableau de bord interne par-dessus un gateway Label 309.

Le gateway possède le plan de base : la chaîne, le stockage, la tarification, l'index partagé des records sur la chaîne, les soldes et le statut de publication. Votre produit possède le plan fournisseur : les utilisateurs, la facturation, l'interface, les workflows, les notifications, le support et tout le sens propre à votre produit que vous posez par-dessus les records. Cela permet à bien plus de produits de partager un seul standard de preuve sans que chaque équipe ait à devenir un opérateur de transactions et de stockage Cardano. La marche à suivre se trouve dans bâtir sur un gateway Label 309.

Puis-je vérifier sans CardanoWall du tout ?

C'est l'objectif, et c'est la raison la plus forte de l'existence du reste. La vérification ne doit pas dépendre du site web CardanoWall. Chacun devrait pouvoir lire les métadonnées de la transaction, reconstruire le record Label 309, valider sa structure, contrôler d'éventuelles signatures de record, recalculer l'empreinte du contenu et — avec la bonne clé — déchiffrer un record scellé en local.

Une preuve qu'un seul site web peut vérifier est une preuve faible. Des SDK ouverts, une CLI ouverte et une spécification ouverte sont ce qui rend une preuve Label 309 vérifiable par n'importe qui, y compris des tiers qui ne touchent jamais à CardanoWall. Si vous voulez le faire vous-même, commencez par vérifier un record Label 309.

Et la tarification ?

Changer d'interface ne supprime pas le coût sous-jacent. Que vous publiiez depuis le site web, l'application de bureau, la CLI, l'API ou votre propre produit, quelqu'un paie toujours de vrais frais de transaction Cardano, plus le stockage utilisé pour les fichiers ou le texte chiffré. Un gateway hébergé ajoute une marge par-dessus pour couvrir l'exploitation, le financement, l'infrastructure et le support : le prix correspond donc au coût répercuté plus cette marge.

Si vous utilisez le gateway hébergé de CardanoWall, vous utilisez son modèle de solde prépayé et de tarification. Si vous l'hébergez vous-même, vous exploitez et financez directement votre propre gateway. Dans les deux cas, le standard rend le record portable — il ne rend pas les blockchains ni le stockage gratuits. Le raisonnement est détaillé dans pourquoi publier a un prix.

Une limite importante

Une preuve Label 309 montre que des octets précis existaient à une date publique précise, et qu'ils n'ont pas changé depuis. Elle ne prouve pas qui a rédigé le contenu, qui le possède, s'il est vrai, ni si quiconque détient des droits dessus. Un record scellé garde son texte en clair lisible uniquement par les détenteurs de clé prévus, mais il ne peut garantir l'anonymat ni empêcher un destinataire de divulguer le texte en clair une fois qu'il l'a déchiffré. Gardez cette frontière à l'esprit, quelle que soit l'interface depuis laquelle vous publiez.

En bref

CardanoWall n'est pas seulement un site web. Le site web est l'interface humaine la plus simple ; le gateway est la couche de publication ; la CLI et les SDK sont les surfaces destinées aux développeurs ; l'application de bureau est le client local et offline-first ; l'auto-hébergement est la voie de l'opérateur. Toutes produisent la même chose : un record Label 309 standard, vérifiable en dehors de l'interface qui l'a créé.

Choisissez l'interface qui correspond au travail à faire. Utilisez le site web pour les personnes, la CLI pour les scripts, les SDK pour les produits, l'API pour les systèmes, et un gateway auto-hébergé lorsque c'est l'indépendance vis-à-vis du fournisseur ou le contrôle opérationnel qu'il vous faut.

Pour aller plus loin

developersapigatewayself-hosting