Compatible S3, vraiment

« Compatible S3 » est imprimé sur chaque page de stockage objet d’internet. Et ça ne vous apprend presque rien. La vraie question n’est pas de savoir si vous pouvez faire un PutObject — c’est de savoir si vous pourrez un jour récupérer tous vos objets et partir.

C’est précisément la partie que personne n’écrit sur sa page marketing. Alors parlons-en.

L’API S3 est le standard, et c’est très bien

Il n’existe pas de comité ISO pour le stockage objet. Ce qui s’est passé, c’est plutôt qu’Amazon a livré une API HTTP en 2006, que tout le monde a écrit des clients pour elle, et que l’API est devenue le standard de facto par simple force gravitationnelle. aws s3, boto3, s3cmd, rclone, mc, les SDK Go, Rust et JS — ils parlent tous le même dialecte. Pointez-les vers un autre endpoint et, la plupart du temps, ça marche.

C’est une excellente issue. Un protocole filaire stable, ciblé par une douzaine d’implémentations indépendantes, c’est exactement la base sur laquelle repose la portabilité. Quand quelqu’un dit « compatible S3 », il promet d’honorer ce contrat.

Le problème, c’est que le contrat est vaste, et que le mot « compatible » porte beaucoup de non-dits.

Ce que signifie vraiment la compatibilité

N’importe qui peut implémenter GET, PUT et DELETE sur un bucket. C’est le minimum vital, pas la compatibilité. Les fonctionnalités qui décident si vous pouvez réellement déménager sont les plus ennuyeuses :

• Clients et signatures. L’authentification SigV4 fonctionne-t-elle avec les SDK standards, sans modification, en se contentant de changer l’URL de l’endpoint ? Ou faut-il un fork maison de l’éditeur ?
• URL signées. Les URL GET/PUT pré-signées, c’est par elles que la moitié du web téléverse des fichiers. Si elles ne sont pas implémentées de la même façon, chaque formulaire d’upload que vous avez écrit casse à la migration.
• Versioning. Si votre application s’appuie sur les versions d’objets et que le nouvel endroit ne les expose pas, vous ne faites pas que déplacer des données — vous perdez l’historique.
• Règles de cycle de vie. Expiration, transitions, abort-incomplete-multipart. Tout ça encode de la vraie logique métier. Si ça ne se transfère pas, vous réécrivez vos politiques à la main.
• Uploads multipart. Les gros objets en dépendent. De subtiles différences sur les limites de taille de parts ou sur le comportement des ETag se manifestent en fichiers corrompus à 3 h du matin.

La compatibilité, c’est toute la surface que votre code touche déjà — pas les trois verbes de la démo.

Comment la portabilité devient discrètement une prise d’otage

Voici la manœuvre. Un fournisseur parle assez bien S3 pour vous faire entrer. Puis il greffe par-dessus des fonctionnalités propriétaires « à valeur ajoutée » — une couche de requêtes maison, un pipeline d’événements spécial, une extension de SDK, un gadget de cycle de vie accessible uniquement depuis la console — et vous encourage à construire dessus. Chacune est sincèrement pratique. Chacune est aussi un fil qui vous coud à ce fournisseur.

Vous ne le remarquez pas avant d’essayer de partir. Vos buckets sont toujours « compatibles S3 », d’accord. Mais votre application dépend désormais de trois choses qui n’existent que là.

Et puis il y a le vrai piège : les frais de sortie (egress). Vos données sont entrées pour pas cher. Les relire vers ailleurs coûte de l’argent au gigaoctet. Plus votre jeu de données a grossi, plus la sortie devient chère — soit exactement l’inverse de ce qu’un accord équitable devrait être. Une portabilité que vous ne pouvez pas vous offrir n’est pas de la portabilité. C’est une prise d’otage polie.

Une portabilité que vous pouvez tester, pas seulement croire sur parole

Nous avons conçu le stockage objet de Kaligon Cloud pour être ennuyeux là où ça compte. Il parle l’API S3. Pointez n’importe quel client S3 vers l’endpoint — aws-cli, rclone, boto3, ce que vous avez déjà — et ça marche. Le versioning, les règles de cycle de vie et les URL signées se comportent comme le standard l’exige, parce que le standard est le produit, pas une case à cocher marketing.

Ce qui rend la portabilité réelle : aucun frais de sortie entre les ressources Kaligon d’une même région, et un tarif forfaitaire unique pour la sortie internet sortante. Déplacer des données entre vos propres buckets et instances ne coûte rien. Partir ne devient pas plus cher à mesure que vos données grossissent. La tarification, c’est un prix forfaitaire unique par ressource — pas de paliers d’engagement qui font monter en douce le coût d’un changement d’avis. Tout est visible sur la page tarifs.

Alors ne nous croyez pas sur parole — testez-nous. Lancez un rclone copy entre un bucket Kaligon et celui d’un concurrent, dans les deux sens, et regardez le compteur. Tout l’intérêt d’un standard, c’est que vous ne devriez avoir à croire personne sur parole.