Sippy : examiner une migration de stockage progressive
Des objets copiés à la demande
Le 24 juillet 2026, Cloudflare étend Sippy à Azure Blob Storage et aux fournisseurs compatibles S3. Le mécanisme copie les objets vers R2 au fil des demandes de l’application.
Le chemin de lecture devient décisif
Notre lecture : une migration progressive doit être examinée avec les habitudes d’accès du projet. Une médiathèque consultée chaque jour et une archive rarement ouverte ne présentent pas le même profil. Le rythme de consultation devient donc une information utile pour planifier les essais.
Nous préparerions plusieurs catégories d’objets : souvent lus, rarement lus, volumineux et absents. Pour chacune, il faut vérifier le contenu retourné, les métadonnées nécessaires et le comportement lors d’une indisponibilité de la source. Comparer seulement le nombre de fichiers ne prouve pas que les usages fonctionnent.
Préparer la fin de la transition
Il faut aussi définir le critère qui autorisera un arrêt de l’ancien stockage. Nous recommandons un inventaire contrôlable et une vérification des objets importants, avec un plan de retour documenté. Le coût doit être étudié sur les lectures et les opérations réellement facturées, sans déduire un prix global d’une seule annonce.
Veille rétrospective — juillet 2026.