Unité 4.2 : Intégration du stockage d'objets

Introduction

TaskBoard permet aux utilisateurs de joindre des fichiers à des tâches : captures d'écran, PDF, maquettes de conception, et parfois des vidéos de plusieurs gigaoctets. Vous ne souhaitez pas que ces octets transitent par votre processus API. Ils consomment de la mémoire, bloquent les threads de travail et transforment une API sans état en goulot d'étranglement. La solution est IONOS Cloud Object Storage avec des URL présignées : le navigateur communique directement avec Object Storage, et votre API ne traite que de petits enregistrements de métadonnées.

Dans cette unité, vous connectez l'API TaskBoard à Object Storage via l'API compatible S3 à l'aide de boto3. Le point le plus important à assimiler dès le départ : Object Storage n'utilise pas votre jeton bearer IONOS CLOUD. Il s'authentifie avec une paire distincte de clé d'accès et de clé secrète, exactement comme AWS S3. Vous configurerez le client, générerez des URL présignées pour les téléversements et les téléchargements, gérerez les fichiers volumineux avec le téléversement multipart, et appliquerez des règles de cycle de vie afin que les téléversements abandonnés n'engendrent pas de coûts permanents.

1. Authentification et connexion avec boto3

Object Storage expose une surface d'API AWS S3 v2, de sorte que les SDK AWS standard fonctionnent avec celui-ci. Ce qui change, c'est le point d'accès et les identifiants. Vous devez transmettre un endpoint_url explicite (le SDK utilise AWS par défaut, et non IONOS CLOUD) ainsi qu'une paire Access Key + Secret Key. Ces clés ne sont pas votre jeton bearer Cloud API et ne sont pas un rôle IAM. Elles sont générées séparément et authentifient chaque requête S3 via AWS Signature.

Object Storage authentifie les utilisateurs à l'aide d'une paire de clés : une Access Key et une Secret Key. Une clé doit être générée manuellement, soit dans le DCD sous Object Storage Credentials and Management, soit via l'API de gestion Object Storage. La longueur actuelle de l'Access Key est de 92 caractères et la longueur de la Secret Key est de 64 caractères, il ne faut donc pas coder en dur des hypothèses sur la largeur des champs issues des anciens formats de 20/40 caractères. Chaque utilisateur peut détenir jusqu'à 5 clés d'accès.

1.1 Création du client S3

Avant d'écrire tout code client, verrouillez la version de boto3 : boto3 1.36.0 et les versions ultérieures échouent pour chaque appel PutObject contre IONOS CLOUD Object Storage avec InvalidTrailer (« Invalid trailing header names in x-amz-trailer »), car IONOS CLOUD ne prend pas en charge l'extension AWS trailing-checksum que boto3 a introduite à partir de la version 1.36.0. Installez boto3<=1.35.99, ou, si vous avez besoin d'une version plus récente de boto3, définissez les variables d'environnement AWS_REQUEST_CHECKSUM_CALCULATION=when_required et AWS_RESPONSE_CHECKSUM_VALIDATION=when_required avant chaque chemin de téléversement de cette unité (PUT présignés, upload_file, upload_fileobj, multipart) pour que cela fonctionne.

Choisissez le point d'accès de la région où se trouve votre bucket. Le nom d'hôte du point d'accès encode la région, et le SDK en dérive la région de signature, de sorte que vous pouvez laisser region_name minimal et laisser le point d'accès piloter l'acheminement.

import boto3
from botocore.config import Config

s3 = boto3.client(
    "s3",
    endpoint_url="https://s3.eu-central-1.ionoscloud.com",  # Frankfurt (de)
    aws_access_key_id="YOUR_ACCESS_KEY",       # 92-char Object Storage key
    aws_secret_access_key="YOUR_SECRET_KEY",   # 64-char Object Storage secret
    region_name="eu-central-1",
    config=Config(signature_version="s3v4"),
)

# Smoke test: list buckets you own
for b in s3.list_buckets()["Buckets"]:
    print(b["Name"], b["CreationDate"])

N'insérez jamais de données d'identification en ligne dans le code source. Récupérez-les à partir de variables d'environnement ou d'un gestionnaire de secrets. Dans TaskBoard, la clé d'accès et la clé secrète proviennent de l'état Terraform (la ressource ionoscloud_s3_key de l'Unité 2.4) et sont injectées en tant que secrets Kubernetes.

import os

s3 = boto3.client(
    "s3",
    endpoint_url=os.environ["OBJSTORAGE_ENDPOINT"],
    aws_access_key_id=os.environ["OBJSTORAGE_ACCESS_KEY"],
    aws_secret_access_key=os.environ["OBJSTORAGE_SECRET_KEY"],
    region_name=os.environ.get("OBJSTORAGE_REGION", "eu-central-1"),
    config=Config(signature_version="s3v4"),
)

1.2 Choisir le bon point d'accès régional

Le point d'accès n'est pas interchangeable. Un seau existe dans exactement une région, et vous devez y accéder via le point d'accès de cette région. Object Storage est disponible à Berlin, Francfort, Logroño et Lenexa. Le tableau suivant associe les centres de données à leurs régions et points d'accès S3 :

Choisissez une région proche de votre application et de vos utilisateurs pour réduire la latence, et une région géographiquement distincte pour les sauvegardes, afin qu'une panne locale n'entraîne pas la perte de vos données principales. Notez les deux types de seaux : les seaux appartenant à l'utilisateur sont situés dans de, eu-central-2 et eu-south-2, tandis que les seaux appartenant au contrat sont situés dans eu-central-4, eu-central-3 et us-central-1. Les limites varient selon le type : un utilisateur peut détenir jusqu'à 500 seaux appartenant à l'utilisateur et jusqu'à 1000 seaux appartenant au contrat. La limite de téléchargement par requête unique est de 4,65 Gio pour les seaux appartenant à l'utilisateur et de 5 Gio pour les seaux appartenant au contrat, ce qui constitue le déclencheur pratique pour le téléchargement multipartiel abordé à la section 3.

2. Opérations sur les buckets et URL présignées

Une fois le client en main, les opérations quotidiennes sont celles de S3 standard : créer un bucket, lister les objets, configurer les ACL et générer des URL présignées. Pour TaskBoard, les URL présignées sont l'élément central. Elles permettent au navigateur de téléverser et de télécharger des pièces jointes directement vers Object Storage, de sorte que votre API ne transmet jamais les octets.

Par défaut, les objets sont privés et seul le propriétaire du bucket peut y accéder. Une URL présignée accorde un accès à durée limitée à un objet unique, sans modifier les autorisations de l'objet et sans partager vos clés. Le propriétaire signe l'URL, la transmet au client, et le client l'utilise jusqu'à son expiration.

2.1 Création de buckets et liste des objets

Les noms de buckets sont uniques au niveau global dans l'ensemble d'Object Storage, doivent comporter entre 3 et 63 caractères et respecter les règles de nommage DNS. Les clés d'objet peuvent comporter jusqu'à 1024 caractères.

bucket = "taskboard-attachments-prod"

# Create the bucket (idempotent-ish: catch the "already owned" case)
try:
    s3.create_bucket(Bucket=bucket)
except s3.exceptions.BucketAlreadyOwnedByYou:
    pass

# List objects under a prefix, paginated (collections can be huge)
paginator = s3.get_paginator("list_objects_v2")
for page in paginator.paginate(Bucket=bucket, Prefix="task-42/"):
    for obj in page.get("Contents", []):
        print(obj["Key"], obj["Size"])

Effectuez toujours la pagination des listes. Un seul bucket peut contenir jusqu'à 200 000 000 objets dans le cas non versionné, de sorte qu'une liste non paginée sera silencieusement tronquée à la première page.

2.2 URL de téléchargement et d'envoi pré-signées

Générez une URL PUT pré-signée afin que le navigateur téléverse le fichier directement. Votre API renvoie l'URL et la clé de l'objet ; elle ne voit jamais le contenu du fichier.

def presign_upload(key: str, content_type: str, expires: int = 900) -> str:
    return s3.generate_presigned_url(
        "put_object",
        Params={"Bucket": bucket, "Key": key, "ContentType": content_type},
        ExpiresIn=expires,  # seconds; keep short for uploads
    )

def presign_download(key: str, expires: int = 300) -> str:
    return s3.generate_presigned_url(
        "get_object",
        Params={"Bucket": bucket, "Key": key},
        ExpiresIn=expires,
    )

Le navigateur effectue ensuite le téléchargement vers l'URL signée à l'aide d'une requête HTTP simple. Le Content-Type doit correspondre à ce qui a été signé, sinon la vérification de la signature échoue :

await fetch(presignedUrl, {
  method: "PUT",
  headers: { "Content-Type": file.type },
  body: file,
});

Les URL présignées sont idéales pour permettre à d'autres utilisateurs de téléverser des objets directement dans votre bucket sans jamais leur communiquer votre Access Key et votre Secret Key. Elles constituent également le bon outil pour partager un objet privé avec une personne qui n'a pas de compte IONOS CLOUD : l'URL fonctionne pendant la fenêtre configurée, puis expire. Les Signature v2 et v4 sont prises en charge ; utilisez v4.

3. Modèles de téléversement et de téléchargement de fichiers

Les pièces jointes de petite taille correspondent à un seul put_object. Les pièces jointes de grande taille nécessitent le téléversement multipart, à la fois pour dépasser la limite de taille par requête unique et pour téléverser les parties en parallèle afin d'augmenter la vitesse. Un objet individuel peut atteindre 5 To (5 497 558 138 880 octets).

3.1 Téléversement multipart pour les fichiers de grande taille

La limite de téléversement par requête unique est de 4,65 Gio (propriété de l'utilisateur) ou de 5 Gio (propriété du contrat). Au-delà de cette limite, vous devez utiliser l'API de téléversement multipart. Les fonctions de haut niveau boto3, upload_file et upload_fileobj gèrent automatiquement le téléversement multipart dès qu'un fichier dépasse le seuil configuré, ce qui constitue la voie de production.

from boto3.s3.transfer import TransferConfig

# Switch to multipart above 100 MB, 8 MB parts, up to 4 parallel uploads
transfer_cfg = TransferConfig(
    multipart_threshold=100 * 1024 * 1024,
    multipart_chunksize=8 * 1024 * 1024,
    max_concurrency=4,
)

s3.upload_file(
    Filename="/tmp/build-artifact.zip",
    Bucket=bucket,
    Key="task-42/build-artifact.zip",
    Config=transfer_cfg,
    ExtraArgs={"ContentType": "application/zip"},
)

La mise en charge multipartite divise un objet volumineux en parties plus petites et les téléverse en parallèle, maximisant ainsi le débit. Elle est disponible via l'API et les SDK, mais pas via l'interface web DCD. Si une mise en charge multipartite est abandonnée, les parties téléversées persistent et génèrent des coûts de stockage jusqu'à ce que vous les supprimiez, ce que la règle de cycle de vie de la section 4 gère précisément.

3.2 Téléchargements en flux et Content-Type

Pour les téléchargements, transmettez le corps de la réponse en flux plutôt que de charger l'objet entier en mémoire. Le corps de la réponse est un flux de type fichier que vous pouvez parcourir par lots.

resp = s3.get_object(Bucket=bucket, Key="task-42/report.pdf")
content_type = resp["ContentType"]  # set at upload time

with open("/tmp/report.pdf", "wb") as f:
    for chunk in resp["Body"].iter_chunks(chunk_size=1024 * 1024):
        f.write(chunk)

Définissez ContentType explicitement lors de la mise en ligne. Si vous l'omettez, les téléchargements utilisent par défaut un type binaire générique et les navigateurs proposent une invite de téléchargement au lieu d'afficher le fichier en ligne.

4. Politiques de cycle de vie et contrôle des coûts

Object Storage facture les données stockées. Les objets orphelins et les téléchargements multipart abandonnés constituent donc une fuite de coûts progressive. Les règles de cycle de vie permettent d'expirer automatiquement les objets et de nettoyer les téléchargements inachevés. Vous les configurez via l'API S3.

Une configuration de cycle de vie prend en charge les actions suivantes : expirer les versions actuelles, supprimer définitivement les versions non actuelles, supprimer les marqueurs de suppression expirés des objets, et supprimer les téléchargements multipart inachevés. Vous pouvez définir jusqu'à 1000 règles dans une configuration. Chaque règle s'applique à un préfixe d'objet différent, et vous ne pouvez pas définir plus d'une règle pour le même préfixe.

4.1 Expiration des objets et nettoyage des téléchargements multipart

Cette configuration expire les téléchargements temporaires après 7 jours et annule les téléchargements multipart inachevés après 1 jour :

s3.put_bucket_lifecycle_configuration(
    Bucket=bucket,
    LifecycleConfiguration={
        "Rules": [
            {
                "ID": "expire-temp-uploads",
                "Filter": {"Prefix": "tmp/"},
                "Status": "Enabled",
                "Expiration": {"Days": 7},
            },
            {
                "ID": "abort-incomplete-multipart",
                "Filter": {"Prefix": ""},
                "Status": "Enabled",
                "AbortIncompleteMultipartUpload": {"DaysAfterInitiation": 1},
            },
        ]
    },
)

Object Storage prend actuellement en charge uniquement la classe de stockage STANDARD, il est donc impossible d'utiliser des règles de cycle de vie pour faire passer les objets vers un niveau plus froid. Les seules actions disponibles sont l'expiration et le nettoyage. Si un bucket utilise Object Lock, les versions non actuelles ne peuvent pas être supprimées avant la fin de leur période de rétention.

5. Compatibilité S3 : ce qui est pris en charge et ce qui ne l'est pas

Object Storage offre l'un des niveaux de prise en charge de l'API S3 les plus élevés, mais il ne présente pas une parité à 100 % avec AWS. Vérifiez une fonctionnalité avant de vous y fier, plutôt que de supposer qu'elle se comporte exactement comme AWS S3. Le tableau suivant résume la prise en charge des fonctionnalités clés :

Quelques contraintes à prendre en compte dans le code. La copie d'objets ne prend pas en charge les copies inter-régions, de sorte qu'une opération de « déplacement d'un bucket vers une autre région » consiste en un téléchargement suivi d'une mise en ligne, et non en une copie côté serveur. Object Lock (modes GOVERNANCE et COMPLIANCE) ne peut être activé qu'au moment de la création du bucket, et ne peut jamais être ajouté rétroactivement à un bucket existant. Bucket Policy utilise du JSON standard avec un Version de 2012-10-17. Le chiffrement en transit est TLS 1.2 ou 1.3.

5.1 CORS pour les téléversements navigateur

Étant donné que les téléversements navigateur de TaskBoard sont effectués directement vers Object Storage via des URL pré-signées, le bucket nécessite une configuration CORS qui autorise PUT depuis votre origine web. Sans cela, le navigateur bloque la requête inter-origines avant qu'elle n'atteigne Object Storage.

s3.put_bucket_cors(
    Bucket=bucket,
    CORSConfiguration={
        "CORSRules": [
            {
                "AllowedOrigins": ["https://app.taskboard.example"],
                "AllowedMethods": ["PUT", "GET"],
                "AllowedHeaders": ["*"],
                "MaxAgeSeconds": 3000,
            }
        ]
    },
)

La référence officielle de l'API S3 se trouve à https://api.ionos.com/docs/s3/v2/, et l'API de gestion des clés/buckets est documentée à https://api.ionos.com/docs/s3-management/v1/. En cas de doute sur une fonctionnalité, consultez ces ressources avant d'écrire du code qui en dépend.

Fiche de référence rapide de l'API

Opérations S3 principales pour Object Storage (via boto3 ou HTTP signé) :

Point de terminaison : https://s3.<region>.ionoscloud.com (par exemple, s3.eu-central-1.ionoscloud.com) Authentification : AWS Signature v4 avec Access Key + Secret Key (et non un jeton bearer)

Atelier de code

Objectif : Téléverser et récupérer une pièce jointe de TaskBoard via boto3 en utilisant des URL présignées et le téléchargement multipart, en confirmant l'authentification par Access Key + Secret Key.

Prérequis :

• Un compte IONOS CLOUD avec une Access Key + Secret Key Object Storage générée
• Python 3.9 ou supérieur avec une version compatible de boto3 installée (pip install "boto3<=1.35.99") ; les versions 1.36.0 et ultérieures de boto3 échouent à chaque appel PutObject vers IONOS CLOUD Object Storage avec InvalidTrailer car IONOS CLOUD ne prend pas en charge l'extension AWS trailing-checksum introduite dans cette version ; il convient donc de figer la version ou de définir AWS_REQUEST_CHECKSUM_CALCULATION=when_required et AWS_RESPONSE_CHECKSUM_VALIDATION=when_required si vous devez utiliser une version plus récente de boto3
• Un point d'accès de région sélectionné (cet atelier utilise Francfort de / eu-central-1)

Étape 1 : Exporter les identifiants

export OBJSTORAGE_ENDPOINT="https://s3.eu-central-1.ionoscloud.com"
export OBJSTORAGE_ACCESS_KEY="<your-92-char-access-key>"
export OBJSTORAGE_SECRET_KEY="<your-64-char-secret-key>"
export OBJSTORAGE_REGION="eu-central-1"

Sortie attendue :

(no output; variables set)

Étape 2 : Créer le client et le seau

import os, boto3
from botocore.config import Config

s3 = boto3.client("s3",
    endpoint_url=os.environ["OBJSTORAGE_ENDPOINT"],
    aws_access_key_id=os.environ["OBJSTORAGE_ACCESS_KEY"],
    aws_secret_access_key=os.environ["OBJSTORAGE_SECRET_KEY"],
    region_name=os.environ["OBJSTORAGE_REGION"],
    config=Config(signature_version="s3v4"))

bucket = "taskboard-lab-<your-initials>"
s3.create_bucket(Bucket=bucket)
print("created", bucket)

Sortie attendue :

created taskboard-lab-ct

Étape 3 : Générer une URL de téléversement présignée

url = s3.generate_presigned_url("put_object",
    Params={"Bucket": bucket, "Key": "task-1/note.txt", "ContentType": "text/plain"},
    ExpiresIn=900)
print(url)

Sortie attendue :

https://s3.eu-central-1.ionoscloud.com/taskboard-lab-ct/task-1/note.txt?X-Amz-Algorithm=...

Étape 4 : Téléversement via l'URL présignée à l'aide de curl

echo "hello taskboard" > note.txt
curl -X PUT -H "Content-Type: text/plain" --upload-file note.txt "<PASTE_PRESIGNED_URL>"

Sortie attendue :

(HTTP 200, empty body)

Étape 5 : Téléversement multipart d'un fichier volumineux

from boto3.s3.transfer import TransferConfig
cfg = TransferConfig(multipart_threshold=5*1024*1024, multipart_chunksize=5*1024*1024)
s3.upload_file("bigfile.bin", bucket, "task-1/bigfile.bin", Config=cfg,
               ExtraArgs={"ContentType": "application/octet-stream"})
print("uploaded large file")

Sortie attendue :

uploaded large file

Étape 6 : Téléchargement via une URL GET présignée

get_url = s3.generate_presigned_url("get_object",
    Params={"Bucket": bucket, "Key": "task-1/note.txt"}, ExpiresIn=300)
import urllib.request
print(urllib.request.urlopen(get_url).read().decode())

Sortie attendue :

hello taskboard

Étape 7 : Ajouter une règle de cycle de vie pour nettoyer les téléversements incomplets

s3.put_bucket_lifecycle_configuration(Bucket=bucket,
    LifecycleConfiguration={"Rules": [{
        "ID": "abort-mpu", "Filter": {"Prefix": ""}, "Status": "Enabled",
        "AbortIncompleteMultipartUpload": {"DaysAfterInitiation": 1}}]})
print("lifecycle set")

Sortie attendue :

lifecycle set

Liste de contrôle de validation :

• [ ] Seau créé et visible dans s3.list_buckets()
• [ ] Fichier téléversé et téléchargé via des URL présignées
• [ ] Téléversement multipart d'un fichier de grande taille réussi
• [ ] Règle de cycle de vie appliquée sans erreur

Nettoyage :

for obj in s3.list_objects_v2(Bucket=bucket).get("Contents", []):
    s3.delete_object(Bucket=bucket, Key=obj["Key"])
s3.delete_bucket(Bucket=bucket)
print("cleaned up")

Erreurs courantes

Erreurs de développement à éviter lors de l'intégration avec Object Storage :

1. Tentative d'authentification avec le jeton bearer de l'API Cloud

   • Problème : Chaque requête S3 renvoie 403 SignatureDoesNotMatch ou InvalidAccessKeyId.
   • Cause : Object Storage utilise la signature AWS avec une paire Access Key + Secret Key, et non le jeton bearer IONOS CLOUD utilisé par le reste de l'API, ni les rôles IAM. Il s'agit de systèmes de credentials entièrement distincts.
   • Correction : Générez une clé Object Storage dédiée (DCD ou API de gestion) et transmettez-la sous forme de aws_access_key_id / aws_secret_access_key. Les clés actuelles comportent 92 et 64 caractères ; rejetez les hypothèses basées sur les anciennes longueurs de 20/40 caractères.

2. Omission de endpoint_url et connexion à AWS à la place

   • Problème : Les requêtes expirient, échouent au niveau du DNS ou aboutissent sur AWS S3 réel.
   • Cause : boto3 pointe par défaut vers les points d'accès AWS. Sans endpoint_url, le SDK ne communique jamais avec IONOS CLOUD.
   • Correction : Transmettez toujours le point d'accès spécifique à la région, par exemple endpoint_url="https://s3.eu-central-1.ionoscloud.com", et alignez region_name sur la région de ce point d'accès.

3. Incompatibilité de Content-Type rompant les téléversements présignés

   • Problème : La PUT du navigateur vers une URL présignée renvoie 403 SignatureDoesNotMatch.
   • Cause : Le Content-Type a été inclus lors de la signature de l'URL, mais le client a envoyé un Content-Type différent (ou aucun). Les en-têtes signés doivent correspondre exactement.
   • Correction : Signez avec le type de contenu exact et envoyez l'en-tête identique depuis le client, ou omettez ContentType de Params entièrement afin qu'il ne fasse pas partie de la signature.

Résumé

Vous pouvez désormais intégrer IONOS Cloud Object Storage dans le code applicatif via son API compatible S3. Vous configurez un client boto3 avec le point d'accès régional approprié et une authentification par Access Key + Secret Key, vous déplacez les octets des fichiers hors de votre chemin d'API à l'aide d'URL présignées pour le téléversement et le téléchargement, vous gérez les fichiers volumineux par téléversement multipart, vous effectuez des téléchargements en flux continu et vous appliquez des règles de cycle de vie pour maîtriser les coûts de stockage. Le flux de pièces jointes de TaskBoard permet désormais aux navigateurs de téléverser directement vers Object Storage, tandis que l'API ne fait que consigner les métadonnées.

Points clés :

• Object Storage s'authentifie à l'aide d'une Access Key de 92 caractères et d'une Secret Key de 64 caractères via AWS Signature v4, et non par le jeton bearer de l'API Cloud ou les rôles IAM
• Transmettez toujours un endpoint_url explicite correspondant à la région du bucket ; les noms de bucket sont uniques au niveau mondial et comptent de 3 à 63 caractères
• Les URL présignées accordent un accès limité dans le temps et sans identifiants, permettant aux clients de téléverser et de télécharger directement auprès d'Object Storage
• Utilisez le téléversement multipart pour les fichiers dépassant la limite de demande unique (4,65 Go pour les buckets appartenant à l'utilisateur, 5 Go pour les buckets contractuels) ; les objets peuvent atteindre 5 To
• Object Storage offre une forte compatibilité S3, mais pas une parité complète : la copie inter-régions n'est pas prise en charge, Object Lock n'est disponible qu'au moment de la création, et seule la classe de stockage STANDARD existe

Terminologie importante :

• Access Key / Secret Key : La paire d'identifiants S3 (92 et 64 caractères) qui authentifie chaque requête Object Storage via AWS Signature.
• URL présignée : Une URL signée et limitée dans le temps qui accorde l'accès à un objet unique sans partager de clés ni modifier les autorisations ; elle constitue la base des téléversements et téléchargements directs depuis le navigateur.
• Téléversement multipart : Découpage d'un objet volumineux en parties téléversées en parallèle ; obligatoire au-delà de la limite de taille de demande unique, et nettoyé via des règles de cycle de vie.
• Règle de cycle de vie : Une configuration de bucket (jusqu'à 1000 règles) qui expire les objets et annule automatiquement les téléversements multipart incomplets.
• Type de bucket : Buckets appartenant à l'utilisateur par opposition aux buckets contractuels, qui diffèrent par la disponibilité régionale, les limites de buckets par utilisateur et les plafonds de téléversement par demande unique.

Prochaines étapes

Continuer à apprendre : Unité 4.3 : Intégration du flux d'événements

Sujets connexes :

• Unité 2.4 : Provisionnement du stockage en tant que code
• Unité 4.1 : Intégration de la base de données et de la mise en cache