Chaque grand fournisseur cloud a tenté de vous vendre un service de ledger managé. AWS avait QLDB (désormais mort). Microsoft a Azure Confidential Ledger. Le discours est toujours le même : nous gérons la cryptographie, vous obtenez des enregistrements inviolables. Cela ressemble à un problème résolu. Mais il y a un piège enfoui dans l'architecture — et il ne devient visible que lorsque vous essayez d'utiliser ces preuves en dehors du cloud qui les a créées.
La promesse vs les petits caractères
Les ledgers cloud managés fournissent effectivement une intégrité cryptographique authentique. Ils hachent vos données, chaînent les blocs ensemble et émettent des reçus. Les mathématiques sont réelles. Mais le chemin de vérification passe par l'API du fournisseur cloud. Votre preuve n'est accessible que tant que le point de terminaison du fournisseur l'est.
Quand un auditeur demande des preuves, vous ne pouvez pas lui remettre un reçu et dire « vérifiez vous-même ». Vous devez dire : « Connectez-vous à notre portail Azure, naviguez vers ce point de terminaison, authentifiez-vous avec ces identifiants et appelez cette API. » Ce n'est pas une vérification indépendante — c'est une vérification médiatisée par le fournisseur.
Trois façons dont le verrouillage sape l'intégrité
Le problème de verrouillage se manifeste de trois manières concrètes qui érodent la proposition de valeur des ledgers managés :
- Dépendance de vérification : les auditeurs tiers, régulateurs et partenaires ont besoin d'identifiants cloud pour valider vos données. Cela crée des frictions, des préoccupations de sécurité et un point de défaillance unique.
- Risque d'arrêt de service : AWS a arrêté QLDB après 6 ans. Chaque ledger managé porte ce risque. Quand le service meurt, vos preuves deviennent inaccessibles — potentiellement au moment où vous en avez le plus besoin.
- Impossibilité multi-cloud : si vous opérez sur AWS et Azure (comme beaucoup d'entreprises), aucun ledger cloud unique ne couvre les deux. Vous vous retrouvez avec une intégrité fragmentée — certains enregistrements prouvables sur un cloud, d'autres sur un autre, aucun universellement vérifiable.
Le coût réel de la vérification opaque
Le problème de verrouillage n'est pas seulement architectural — il a des coûts commerciaux directs. Quand la vérification nécessite un accès à la plateforme, chaque contrôle d'intégrité devient une chaîne de dépendances : authentification, connectivité réseau, disponibilité de l'API et statut de l'abonnement.
En réponse à un incident, résolution de litige ou examen réglementaire, cette chaîne de dépendances introduit de la latence et du risque au pire moment. La question passe de « pouvons-nous prouver que ces données n'ont pas été altérées » à « pouvons-nous faire authentifier tout le monde sur la bonne plateforme pour vérifier ».
À quoi ressemble la vérification indépendante du fournisseur
L'alternative est une preuve qui réside sur une infrastructure qu'aucune entreprise ne contrôle. Les blockchains publiques fournissent cela : une fois qu'une racine Merkle est ancrée on-chain, elle est vérifiable par quiconque possède un navigateur et un explorateur de blocs.
Combiné au stockage adressé par contenu comme IPFS pour les manifestes et les métadonnées, cela crée un chemin de vérification qui ne dépend de l'API, de l'abonnement ou de l'existence continue d'aucun fournisseur. La preuve est la preuve — pas un pointeur vers le service d'un fournisseur.
Quand le verrouillage compte le plus
Le verrouillage des ledgers cloud est particulièrement dangereux dans ces scénarios :
- Examens réglementaires — Quand un régulateur exige une preuve d'intégrité des données, la preuve doit être vérifiable indépendamment — pas dépendante de l'activité de votre abonnement cloud et de la validité de vos clés API.
- Litiges multi-parties — Quand deux parties sont en désaccord sur le contenu d'un enregistrement, la preuve doit être neutre. Si elle réside dans le compte cloud d'une partie, l'autre n'a aucune raison de lui faire confiance.
- Archivage à long terme — Les exigences réglementaires de conservation s'étendent sur 7 à 10+ ans. Aucun service cloud n'a un historique de disponibilité garantie sur cette durée. QLDB a duré 6 ans.
Choisir l'intégrité plutôt que la commodité
Les ledgers cloud managés sont commodes. Ils s'intègrent proprement à l'infrastructure cloud existante. Mais la commodité n'est pas la bonne optimisation pour l'intégrité. Le principe même des enregistrements inviolables est que la preuve doit survivre à des conditions adverses — y compris la condition où le fournisseur de services quitte le marché. Si votre preuve d'intégrité nécessite la coopération continue d'un tiers, ce n'est pas réellement une preuve. C'est une promesse.
Si votre preuve d'intégrité des données nécessite que l'API du fournisseur fonctionne, ce n'est pas une preuve — c'est une promesse. Les promesses expirent. Les mathématiques non.