Le modèle phygital, et ce que la blockchain garantit vraiment


Parler de blockchain dans le vin déclenche deux réflexes opposés. Certains entendent “preuve absolue”. D’autres entendent “gadget”. Cav:Chain essaie d’éviter les deux, en posant une règle simple : la technologie n’est utile que si l’on sait exactement ce qu’elle garantit, et exactement ce qu’elle ne garantit pas.

Ce que Cav:Chain appelle phygital

Phygital n’est pas ici un mot de vitrine. C’est une articulation explicite entre un objet physique et un dossier numérique, avec un principe directeur : l’unité numérique doit rester cohérente avec l’unité physique de référence.

Concrètement, Cav:Chain associe des produits physiques réels à des certificats numériques ou NFT utilitaires, intégrés de manière transparente dans le parcours d’achat, puis dans la vie du produit (transfert, ouverture, consommation, bascule en Souvenir).

Le point important est la continuité. La chaîne ne s’arrête pas à la vente, ni à l’ouverture. Elle change d’échelle et de régime, jusqu’au Souvenir, sans destruction du passé.

Ce que la blockchain garantit réellement

La blockchain ne garantit pas « la vérité » d’un produit. Elle garantit l’intégrité d’un registre d’événements, selon les règles du système.

Dit autrement, elle permet de prouver trois choses très précises :

  • qu’un événement a été enregistré à une date donnée
  • qu’il a été attribué à un acteur identifié (selon le dispositif d’identification retenu)
  • que l’historique enregistré conserve son intégrité selon les règles du système, sans réécriture discrète

C’est déjà beaucoup, à condition de rester lucide sur le périmètre : on prouve la continuité des événements documentés, pas ce qui s’est passé entre eux, ni l’état physique du produit sans contrôle.

Ce que la blockchain ne garantit jamais

Il faut le dire sans détour, parce que c’est là que naissent les contresens.

La blockchain ne peut pas prouver :

  • la qualité intrinsèque d’un vin ou d’un spiritueux
  • l’absence totale de fraude hors du périmètre documenté
  • la conservation matérielle parfaite sans dispositifs et contrôles physiques
  • l’état réel d’un flacon si personne ne l’observe et ne le documente

Le livre blanc liste d’ailleurs des risques très concrets du monde physique, comme un QR/NFC endommagé ou une défaillance logistique. Ce sont des risques phygitaux. Aucune blockchain ne les efface.

Pourquoi Polygon, et pourquoi des standards simples

Cav:Chain verrouille un choix de blockchain de référence sur la trajectoire V1 à V4 : Polygon. Ce choix est considéré stable, sauf contrainte réglementaire majeure.

Ce verrou n’est pas un fétichisme technique. Il sert la soutenabilité et la répétabilité : des opérations fréquentes (événements, mint, transferts, transformations) doivent rester économiquement tenables et opérables sans stress. La roadmap technique insiste sur une politique explicite de maîtrise des coûts, et sur l’idée que le mint (création du NFT) ne doit jamais bloquer une vente.

Sur les standards, la logique est identique : ERC-721 et ERC-1155 (ou combinaison) sont figés pour V2, les contrats sont versionnés, documentés, et conçus pour rester compatibles avec les versions ultérieures sans migration structurelle.

Dans les billets Cav:Chain, on parlera parfois de deux standards techniques : ERC-721 et ERC-1155. Sans entrer dans la mécanique : ERC-721 sert à représenter un objet unique (un flacon unique, ou une caisse considérée comme une entité), et ERC-1155 sert à représenter une série d’unités liées à un même ensemble (par exemple, les bouteilles issues d’une caisse, suivies individuellement).

On-chain, off-chain : une séparation assumée, pas un compromis honteux

Pour le dire simplement : on-chain, c’est ce qui est inscrit dans un registre public et vérifiable, comme un journal d’événements. Off-chain, c’est ce qui reste hors de ce registre, dans un dossier associé, souvent nécessaire pour respecter la vie privée, corriger une erreur humaine, ou stocker des médias (photos, documents) sans les exposer à tous.

Une autre confusion fréquente consiste à croire que “tout doit être on-chain”. En pratique, ce serait souvent une mauvaise idée.

La roadmap technique prévoit une répartition on-chain / off-chain des métadonnées et des médias, avec des principes explicites :

  • identifiants stables
  • possibilité de rectification des données off-chain
  • respect strict du RGPD
  • absence de données personnelles sensibles par défaut

Cette architecture sert le réel : certaines informations doivent être immuables (les repères de continuité), d’autres doivent pouvoir être corrigées (erreurs humaines, évolutions contractuelles, données à caractère personnel). Le phygital sérieux n’est pas l’obsession de l’immutabilité. C’est la maîtrise de ce qui doit l’être, et de ce qui ne doit pas l’être.

Pourquoi un minting custodial au départ

Le mot “custodial” fait parfois peur, parce qu’il est souvent associé à la garde d’actifs. Ici, il faut être précis.

Ici, “custodial” signifie simplement : au début, la plateforme opère certaines actions techniques pour le compte du client, afin que l’expérience reste simple, sans exiger que chacun maîtrise immédiatement la gestion de clés privées

En V2, le minting est réalisé par un wallet (portefeuille numérique) opéré par la plateforme, avec une gouvernance formalisée : sécurisation des clés, séparation des responsabilités, journalisation, limitation des droits par rôle.

Ce choix est d’abord opérationnel : il permet un parcours simple, sans exiger d’emblée que chaque client soit à l’aise avec des clés privées. Et il est borné : une option “wallet propriétaire” est envisagée comme extension conditionnelle, jamais bloquante.

Et surtout, cela ne transforme pas Cav:Chain en service de garde. Le cadre juridique insiste : la plateforme n’exerce pas d’activité de conservation ou de garde d’actifs numériques pour compte de tiers, et les mécanismes techniques éventuels (portefeuille d’exécution, compte d’attente transactionnel) sont strictement limités à l’exécution des transactions.

Le bon test : “qu’est-ce que je peux prouver demain matin ?”

Un bon modèle phygital ne se juge pas à ses schémas. Il se juge à sa capacité à produire une preuve lisible, demain matin, quand quelqu’un pose une question simple.

Exemple : “qui a eu cette caisse, et quand a-t-elle été ouverte ?”
Si les événements sont structurés, attribués, et non altérés, la plateforme peut fournir une lecture stable : ce qui est établi, ce qui est déclaré, ce qui est corroboré, et ce qui reste inconnu.

C’est exactement le type de lisibilité que vise la V3 : passer d’un outil qui fonctionne à un dispositif qui rassure, capable d’expliquer ce que Cav:Chain fait, prouve, et ne fait pas, sans jargon ni promesse excessive, à partir de cas réels.