Cloudflare R2 : indexer des fichiers sans extension dans AI Search

Cloudflare R2 : ce qui change réellement

Cloudflare AI Search est un service managé qui permet d’effectuer des recherches dans vos propres contenus. L’une des sources possibles est un bucket R2, le stockage objet de Cloudflare. AI Search parcourt le bucket, convertit les documents compatibles en texte interrogeable et construit l’index sollicité par votre application lors d’une requête.

Avant cette mise à jour, la méthode de détection la plus sûre reposait sur l’extension du nom de fichier. Une clé comme manual.pdf indique à l’indexeur le format du document. Une clé stable telle que documents/manual-alpha, elle, ne fournit aucun indice.

AI Search peut maintenant s’appuyer sur le Content-Type HTTP ordinaire d’un objet sans extension. application/pdf signale que les octets correspondent à un PDF ; text/markdown, à un document Markdown. Cloudflare cite également text/plain, application/json, text/html et text/csv parmi les types pris en charge.

Les extensions de fichier ne disparaissent pas pour autant. Cloudflare continue de présenter une extension reconnue comme la voie de détection privilégiée et la plus rapide. La nouvelle méthode devient utile lorsque modifier la clé casserait des URL, des références en base de données, des associations de tenants, des signatures ou un contrat d’upload déjà en production.

Une distinction est essentielle. Content-Type est une métadonnée HTTP attachée à l’objet R2. Ce n’est pas la métadonnée personnalisée qu’AI Search exploite pour filtrer par catégorie, client ou statut du document. Ces champs personnalisés passent par des en-têtes x-amz-meta-* et nécessitent un schéma dans AI Search. Ajouter x-amz-meta-content-type ne remplace donc pas le véritable champ HTTP.

Cette évolution concerne l’ingestion de la source, autrement dit le point d’entrée du document dans l’index. Elle ne change pas le modèle qui rédige une réponse après la récupération des résultats. La mise à jour GLM-5.3 Flash intervient à cette étape ultérieure de génération.

Le vrai gain : un système de nommage en moins

Les clés opaques sont courantes, et pour de bonnes raisons. Un produit peut utiliser un identifiant de base de données stable comme clé R2 afin que l’objet évolue sans changer d’adresse. Un service documentaire peut vouloir masquer le nom de fichier d’origine d’un client. Une URL signée peut aussi dépendre de la clé exacte.

Jusqu’ici, le contournement consistait à attribuer un nom avec extension à la copie destinée à la recherche, ou à ajouter une étape de renommage avant qu’AI Search ne voie l’objet. Il fallait alors stocker, rapprocher et nettoyer une identité supplémentaire.

La mise à jour permet de conserver la clé d’origine lorsque ses métadonnées HTTP sont déjà correctes. C’est là que le workflow s’allège réellement.

Voici une estimation du travail d’ingestion avant et après la mise à jour. Il s’agit d’un modèle de processus, pas d’un benchmark mesuré ni d’une économie garantie.

Ce tableau ne prétend volontairement pas chiffrer une économie. Cloudflare n’a publié aucun gain de temps pour cette fonctionnalité, et la mise à jour ne réécrit pas vos métadonnées existantes.

Combien coûte le travail qui reste ?

AI Search est gratuit pendant sa bêta ouverte, dans les limites de votre offre Workers. Le stockage et l’indexation vectorielle sont inclus. L’usage de Workers AI et d’AI Gateway peut toujours être facturé séparément, mais cette modification de l’ingestion ne change pas leurs tarifs.

La correction des métadonnées peut, en revanche, peser sur la facture R2. ListObjects, PutObject et CopyObject sont comptabilisés comme des opérations de classe A. HeadObject et GetObject, qu’un outil de correction peut utiliser pour inspecter ou lire un objet, relèvent de la classe B.

Avec le stockage Standard, les requêtes de classe A coûtent $4.50 par million après le quota mensuel gratuit de 1 million. Infrequent Access n’inclut aucun quota gratuit et facture $9.00 par million de requêtes de classe A. Cette classe de stockage peut aussi facturer $0.01 par GB lors de la lecture ou de la copie d’objets.

La règle budgétaire est donc simple. Un objet doté du bon Content-Type ne nécessite aucune correction liée au renommage. Si la valeur est erronée, une écriture ou une copie peut encore être nécessaire selon l’outil choisi. Comptez ces opérations avant de programmer une remise en état de tout le bucket.

Le volume compte également côté AI Search. La limite par instance est de 100,000 fichiers avec Workers Free. Workers Paid autorise 1 million de fichiers, ou 500,000 lorsque la recherche hybride est activée. La limite de 4 MB par fichier reste identique pour les deux offres.

Qui peut en profiter dès demain ?

Un fondateur SaaS solo qui utilise des identifiants d’upload stables

Conservez la clé R2 déjà enregistrée dans votre base de données, puis faites en sorte que l’outil d’upload associe le véritable type MIME lorsqu’il écrit l’objet. Votre moteur de recherche pour le support peut alors ingérer ce même objet sans deuxième colonne de nom de fichier ni traitement batch créant des copies pour la recherche.

Le bénéfice : moins d’identités à rapprocher lorsqu’un client remplace, supprime ou déplace un document. Le système d’upload doit toujours refuser un type binaire générique si l’objet est destiné à devenir interrogeable.

Un ingénieur plateforme face à un bucket historique

Listez les objets sans extension et leurs métadonnées HTTP, comparez chaque valeur aux types MIME pris en charge par Cloudflare, puis isolez les échecs. Corrigez d’abord un petit échantillon avant d’intervenir sur l’ensemble du bucket.

Le bénéfice : une migration maîtrisée. Le budget de correction ne s’applique qu’aux objets qui en ont besoin ; ceux dont les métadonnées sont valides passent directement à la synchronisation et à la vérification.

Une équipe produit multi-tenant

Conservez des clés d’objet opaques qui ne révèlent pas les noms de fichiers d’origine, puis définissez Content-Type à partir d’un contrôle serveur fiable au moment de l’upload. Gérez séparément les filtres de chemin ou les préfixes AI Search lorsque chaque tenant doit disposer de son propre périmètre d’indexation.

Le bénéfice : une architecture cohérente. L’identité de stockage reste indépendante de la présentation du fichier, tandis que l’indexeur reçoit toujours un type qu’il peut valider.

Une agence qui exploite les bases de connaissances de ses clients

Distinguez clairement les deux rôles des métadonnées dans votre procédure. Le Content-Type HTTP détermine si un fichier sans extension peut être ingéré. Les champs personnalisés x-amz-meta-* déterminent comment filtrer les résultats indexés, une fois leur schéma défini.

Le bénéfice : un diagnostic plus lisible. Lorsqu’un document manque, l’équipe vérifie les métadonnées d’ingestion avant de modifier les règles de filtrage ou le modèle de réponse.

Indexer un objet sans extension dans Cloudflare R2

L’API R2 pour Workers accepte les en-têtes de la requête via httpMetadata. Le Worker suivant conserve le chemin de la requête comme clé de l’objet et refuse les uploads dépourvus de Content-Type.

Associez un bucket R2 sous le nom DOCS dans wrangler.jsonc :

{
  "$schema": "./node_modules/wrangler/config-schema.json",
  "name": "r2-document-upload",
  "main": "src/index.ts",
  "compatibility_date": "2026-09-11",
  "r2_buckets": [
    {
      "binding": "DOCS",
      "bucket_name": "your-bucket"
    }
  ]
}

Utilisez ensuite ce Worker :

interface Env {
  DOCS: R2Bucket;
}

export default {
  async fetch(request, env): Promise<Response> {
    if (request.method !== "PUT") {
      return new Response("Method Not Allowed", { status: 405 });
    }

    const key = new URL(request.url).pathname.replace(/^\//, "");
    const contentType = request.headers.get("content-type");

    if (!key || !contentType) {
      return new Response("Key and Content-Type are required");
    }

    await env.DOCS.put(key, request.body, {
      httpMetadata: request.headers,
    });

    return new Response(`Stored ${key}`);
  },
} satisfies ExportedHandler<Env>;

Lancez npx wrangler dev, affectez à WORKER_URL l’adresse locale affichée par Wrangler, puis envoyez un PDF local vers une destination sans extension :

curl "$WORKER_URL/documents/manual-alpha" \
  --request PUT \
  --header "Content-Type: application/pdf" \
  --data-binary @manual.pdf

Cet exemple valide uniquement la partie stockage, pas l’indexation. En production, ajoutez une authentification, déduisez le type d’une inspection fiable plutôt que du seul nom fourni par l’utilisateur, puis confrontez-le à la liste des formats pris en charge par Cloudflare.

Un upload réussi ne garantit pas un fichier interrogeable

Les écritures R2 bénéficient d’une cohérence forte : après une écriture réussie, l’objet et ses métadonnées sont visibles. L’indexation par AI Search reste toutefois une tâche asynchrone distincte. Une demande de synchronisation peut être acceptée alors que l’élément échouera plus tard.

Les instances adossées à R2 se synchronisent toutes les 6 heures par défaut. Vous pouvez choisir un intervalle de 1, 2, 4, 6, 12 ou 24 heures, ou lancer vous-même une tâche :

npx wrangler ai-search jobs create <INSTANCE_NAME>

Les synchronisations manuelles d’une source peuvent s’exécuter au maximum une fois toutes les 30 secondes. Multiplier les tentatives ne corrige pas de mauvaises métadonnées.

Une fois la tâche terminée, consultez les logs des éléments, leur fiche détaillée ou les statistiques de l’instance. L’erreur unsupported_type apparaît au niveau de l’élément lorsqu’AI Search refuse le format détecté. Corrigez l’objet, puis synchronisez à nouveau cet élément ou la source.

Vous n’êtes pas concerné si toutes vos clés R2 portent déjà une extension reconnue. Vous ne l’êtes pas non plus si votre source AI Search est un site web ou le stockage intégré, et non un bucket R2 externe. Cette évolution ne rend indexable ni un format non pris en charge ni un fichier trop volumineux.

Le plan d’action pour lundi

Commencez par un audit, pas par une réécriture en masse.

Agissez cette semaine si des clés R2 stables ou opaques vous obligent à maintenir un deuxième circuit de nommage pour AI Search. Attendez si vos objets actuels ne disposent pas d’informations de type fiables : vous avez besoin d’un plan de classification avant toute réécriture. Ne changez rien si des extensions reconnues assurent déjà correctement votre ingestion.

Pour recevoir la prochaine évolution d’une plateforme avec une lecture directement exploitable, abonnez-vous à la newsletter.