Dans le développement cloud, nous traitons souvent le stockage comme infini. Chaque journal, sauvegarde ou jeu de données que nous créons est conservé indéfiniment — pas parce que c’est toujours utile, mais parce que supprimer semble risqué. Pourtant, cet état d’esprit augmente silencieusement à la fois les coûts et l’impact carbone.
La vérité est : la plupart des objets stockés ne devraient pas vivre éternellement. Des artefacts de build temporaires aux exports éphémères en passant par les jeux de données analytiques de courte durée, une grande partie des données que nous produisons a une durée de vie naturelle. Le défi consiste à aligner ce cycle de vie avec nos systèmes.
Chez DownToZero.Cloud, nous avons conçu DTZ ObjectStore autour de ce principe. Il ne s’agit pas seulement de stocker les données efficacement — il s’agit de les stocker responsablement.
Chaque objet dans le cloud consomme plus que de l’espace disque. Il utilise :
Cette activité continue subsiste même pour des données qui ne sont plus jamais consultées. En substance, notre stockage a une ombre carbone — et des cycles de vie de données non gérés la font croître au fil du temps.
Un des principaux Green Software Patterns est la gestion du cycle de vie des données — s’assurer que les ressources numériques correspondent à leur pertinence réelle.
En pratique, cela signifie :
Lorsque vous appliquez ce pattern, les bénéfices dépassent la durabilité :
Le service DTZ ObjectStore est construit avec la gestion du cycle de vie au cœur. Contrairement aux systèmes de stockage traditionnels où les TTL sont une réflexion secondaire, DTZ intègre cette capacité dans le flux de création d’objets.
Attachez un TTL lors de l’upload. Utilisez soit une durée relative (X-DTZ-EXPIRE-IN) soit un horodatage absolu (X-DTZ-EXPIRE-AT). Fournissez votre clé API comme X-API-KEY.
Base URL:
https://objectstore.dtz.rocks/api/2022-11-28
Upload with a 24-hour TTL (duration):
curl -X PUT \
"https://objectstore.dtz.rocks/api/2022-11-28/obj/logs/builds/2025-11-05.json" \
-H "X-API-KEY: $DTZ_API_KEY" \
-H "X-DTZ-EXPIRE-IN: P1D" \
--data-binary @build-output.json
Upload that expires at a fixed time (RFC-3339):
curl -X PUT \
"https://objectstore.dtz.rocks/api/2022-11-28/obj/exports/report.csv" \
-H "X-API-KEY: $DTZ_API_KEY" \
-H "X-DTZ-EXPIRE-AT: 2025-12-01T00:00:00Z" \
--data-binary @report.csv
Download an object:
curl -s \
"https://objectstore.dtz.rocks/api/2022-11-28/obj/exports/report.csv" \
-H "X-API-KEY: $DTZ_API_KEY" -o report.csv
Check metadata (including server-computed expiration):
curl -I \
"https://objectstore.dtz.rocks/api/2022-11-28/obj/exports/report.csv" \
-H "X-API-KEY: $DTZ_API_KEY"
# Look for headers like:
# X-DTZ-EXPIRATION: 2025-12-01T00:00:00Z
List objects by prefix:
curl -s \
"https://objectstore.dtz.rocks/api/2022-11-28/obj/?prefix=logs/builds/" \
-H "X-API-KEY: $DTZ_API_KEY" \
| jq .
# Response includes per-object fields like key, size, lastModified, and expiration.
Delete early (if needed):
curl -X DELETE \
"https://objectstore.dtz.rocks/api/2022-11-28/obj/exports/report.csv" \
-H "X-API-KEY: $DTZ_API_KEY"
La suppression de chaque objet est divisée en deux phases. Lorsqu’un objet atteint son temps d’expiration, il n’est plus accessible via l’API, mais il reste présent dans le système de stockage (et il n’est pas facturé à ce stade). La suppression réelle est planifiée par lots pendant des fenêtres horaires à faible empreinte carbone afin de minimiser l’impact des tâches d’arrière-plan - transformant l’application des cycles de vie en un levier de durabilité, pas seulement en une tâche d’exploitation.
Le cycle de vie ne consiste pas à supprimer de manière irréfléchie — il s’agit de concevoir avec un objectif. Les patterns qui fonctionnent bien :
Définissez les règles une fois et laissez le système s’optimiser en continu — en consommant moins, en coûtant moins et en accomplissant plus avec la même enveloppe énergétique.
La gestion du cycle de vie des objets reflète directement l’éthique Green Software : supprimer les ressources de stockage inutilisées et définir des politiques de rétention par défaut — un petit acte intentionnel de gestion qui devient à grande échelle.
Chez DownToZero.Cloud, c’est là où bonne ingénierie rime avec bonne citoyenneté. Notre mission est d’autonomiser les développeurs pour concevoir en vue du zéro gaspillage — où les données vivent seulement aussi longtemps que nécessaire, et pas plus.
La gestion du cycle de vie des objets s’intègre parfaitement aux pipelines CI/CD. DTZ fournit des GitHub Actions dédiées pour téléverser et télécharger des objets avec prise en charge intégrée de l’expiration :
Example: Upload a build artifact with 30-day expiration
- name: Upload build artifact
uses: DownToZero-Cloud/objectstore-upload@main
with:
api_key: ${{ secrets.DTZ_API_KEY }}
name: build.zip
expiration: P30D
Cela rend facile l’application des politiques de cycle de vie directement dans vos workflows de déploiement — garantissant que les artefacts temporaires ne s’accumulent pas indéfiniment.
Le stockage devrait être dynamique, pas statique.
En intégrant la conscience du cycle de vie dans votre architecture, vous réduisez le gaspillage cloud et adoptez un pattern de conception durable qui profite à la planète, à votre plateforme et à vos utilisateurs.
DTZ ObjectStore transforme ce principe en pratique — donnant à chaque objet une histoire, un objectif et, surtout, une fin.