AWS a mis fin au support d'Amazon Quantum Ledger Database le 31 juillet 2025. Pas de keynote, pas de billet de blog, pas d'annonce publique — les clients existants l'ont appris par un e-mail de routine et une page de documentation mise à jour. Pour les équipes qui avaient construit des flux de conformité sur QLDB, l'avis a marqué le début d'une fenêtre de migration qui s'est fermée plus vite que la plupart ne s'y attendaient. Cet article est pour les acheteurs qui évaluent maintenant des remplaçants — et pour quiconque veut que sa migration actuelle soit la dernière qu'il doit faire.
Pourquoi la recommandation AWS n'est pas tout à fait une réponse
AWS recommande officiellement de migrer les charges QLDB vers Amazon Aurora PostgreSQL, qui offre des capacités de type ledger via des extensions (voir aws.amazon.com/qldb/faqs). Aurora fournit un logging d'audit détaillé et une rétention permanente des logs. Il ne fournit pas de vérifiabilité cryptographique. Cela compte — la chaîne de hachage cryptographique était la raison pour laquelle beaucoup d'équipes ont choisi QLDB en premier lieu.
La conséquence pratique est que les logs d'audit basés sur Aurora peuvent être modifiés par un administrateur privilégié. L'historique existe ; la preuve d'infalsifiabilité non. Le propre guide de migration de Microsoft pour les clients QLDB (techcommunity.microsoft.com, moving from QLDB to Azure SQL Ledger) note la même lacune et positionne le Ledger au niveau base de données d'Azure SQL Ledger comme réponse partielle — mais avec la même forme de fournisseur unique que la fermeture de QLDB a exposée.
Les critères de remplacement
La leçon de QLDB n'est pas que les ledgers cloud sont mauvais. C'est que l'immutabilité gérée par fournisseur a un mode de défaillance par décision d'affaires. Tout remplaçant devrait être évalué selon trois critères avant de reconstruire votre pipeline d'intégrité une seconde fois :
- Pouvez-vous vérifier sans le fournisseur ? Les preuves QLDB nécessitaient un accès API AWS. Si l'endpoint de service du fournisseur disparaît, les preuves disparaissent avec. Les ancres de Certyo sont vérifiables contre Polygon directement, avec ou sans coopération de Certyo.
- L'ancre de confiance est-elle neutre au cloud ? Un ledger dont la racine de confiance est un seul opérateur cloud hérite de la roadmap commerciale de cet opérateur. Les blockchains publiques et le stockage adressé par contenu ne partagent pas ce mode de défaillance.
- Les artefacts de preuve sont-ils portables ? Si votre auditeur ou contrepartie ne peut pas vérifier indépendamment un paquet de preuves sans accès à votre compte fournisseur, la preuve est une promesse, pas une évidence.
Les quatre remplaçants réalistes
L'ensemble pratique de remplaçants est petit. Chacun a un profil :
Aurora PostgreSQL vous donne des logs d'audit, pas de preuve cryptographique. Azure SQL Ledger vous donne une intégrité au niveau base de données mais hérite du risque fournisseur unique. Azure Confidential Ledger ajoute l'isolation TEE mais tourne toujours dans un seul cloud. Certyo ancre à Polygon et publie des preuves qui fonctionnent sans nous. Aucun des quatre n'est parfait ; trois sont des versions du pari QLDB.
Pourquoi « natif cloud » était l'erreur d'origine
L'expression « ledger natif cloud » sonnait sophistiquée en 2019. Avec le recul, elle nommait le bug : un ledger qui dépend du cloud n'est permanent que tant que la roadmap du fournisseur cloud. Les ledgers sont censés survivre à leurs opérateurs. Un ledger qui meurt quand son fournisseur retire le produit n'est pas vraiment un ledger — c'est une base de données avec des garanties de rétention.
Le mouvement honnête est de traiter cette migration comme celle qui rend la prochaine inutile. Choisissez un remplaçant dont les artefacts de preuves survivent au remplacement lui-même. Cela restreint le champ rapidement.
À qui cette leçon frappe le plus fort
Trois groupes doivent prendre la prochaine décision délibérément :
- Anciens clients QLDB en cours de migration — Vous avez déjà perdu la vérifiabilité cryptographique si vous avez migré vers Aurora. Si la portée de conformité l'exige toujours, vous fonctionnez sur du temps emprunté sur une solution intermédiaire.
- Équipes évaluant ACL ou Azure SQL Ledger — Les deux sont vivants et les deux fonctionnent. Les deux héritent du risque fournisseur unique. Si c'est un compromis acceptable pour votre organisation, bien — mais faites-en une décision consciente, pas un défaut.
- Achats et finances — Côté budget, une seconde migration dans trois à cinq ans est le mode de défaillance à empêcher. Le delta par an entre un remplaçant verrouillé fournisseur et un neutre est petit ; le delta en exposition au risque de migration est grand.
Ce qui change cette fois et sources
Ce qui rend le marché post-QLDB différent est que les alternatives existent maintenant. L'ancrage en chaîne publique a mûri. L'économie des lots rend les coûts par enregistrement négligeables. L'adressage par contenu IPFS est prêt pour la production. Aucune n'était évidemment de grade production en 2019 ; elles le sont maintenant. Le cas honnête pour un remplaçant neutre au cloud est que la migration de 2025 est évitable à l'avenir. Sources : InfoQ — infoq.com/news/2024/07/aws-kill-qldb, AWS FAQ — aws.amazon.com/qldb/faqs, guide migration Microsoft — techcommunity.microsoft.com/blog/azuresqlblog/moving-from-amazon-quantum-ledger-database-qldb-to-ledger-in-azure-sql/4246237, alternatives DoltHub — dolthub.com/blog/2024-08-12-qldb-deprecated-alternatives. Voir aussi notre page /fr/compare/aws-qldb pour une comparaison Certyo directe.
Un ledger qui meurt quand son fournisseur retire le produit n'est pas un ledger. C'est une base de données avec des garanties de rétention. Choisissez le remplaçant qui survit à la prochaine fermeture.